I am trying to use the expansion header to control a couple motors and auxiliary task mechanism. For this I am using the appropriate pins as GPIO and merely attempting to send high or low signals as needed by the robot. (For instance, I might need the robot to move forward and so I'd send high signals on both sets of pins, whereas if I needed the robot to turn I'd send a high signal to one pin and a low to the other.)
However, the problem is that the pins will only stay high! I've followed the conventions for sysfs just via the terminal, and, although I'm able to set the "values", "active_lows", etc. to 0 or 1, I can't actually get the pins to send 0V. After checking the beagle.h file I used for u-boot it looks like the multiplexer mode is configured correctly. This is also reflected when I get the info from sys/class/gpio/gpio%/% and sys/kernel/debug/gpio. Furthermore I don't get any errors or indication from anywhere that there is something wrong...it just doesn't work!
What should I do? For the first time in my life I have seemingly exhausted the internet...
details:
Beagleboard xm rev c1
ubuntu 12.04
kernel 3.6.8-x4
Im pretty new to the beagle board and I have recently been trying to configure the GPIO pins on my classic beagleboard c4, which i believe should be fairly similar.
Half of my GPIO pins seemed to work fine and the other half seemed to remain high or low no matter what i did. Even though they were configured the same way as the working pins in /sys/class/gpio/
have you tried to use other gpio pins?
I ended up following http://labs.isee.biz/index.php/Mux_instructions
to configure the mux to 4 and now i can control the pins that were not working.
I basically used the command:
sudo echo 0x004 > /sys/kernel/debug/omap_mux/(mux 0 name)
where (mux 0 name) was the name of the subsystem for the mux 0 setting for the gpio pin you wish to configure
ie. for gpio 183 on beagleboard c4
sudo echo 0x004 > /sys/kernel/debug/omap_mux/i2c2_sda
Though I had to change permissions to modify these files
As I said I am pretty new to the beagleboard and ubuntu but this worked for me so I thought I would share it with you, I hope it is of some help.
Regards;
Paul;
It seems that the beagleboard expansion pins are numbered in alternating fashion, as clearly and professionally depicted here.
Thanks to everyone for your help. I now know way more than I should about GPIO on OMAP systems (and so do you). Good luck on finals/life!**
tl;dr I'm an idiot!
Related
Using pin 26 for ADC seems to be discouraged in Toit.
From what I can see on https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/adc.html pin 26 should have an ADC converter, so what is the reason for that?
The ESP32 is limited around ADC2:
Since the ADC2 module is also used by the Wi-Fi, only one of them could get the preemption when using together, which means the adc2_get_raw() may get blocked until Wi-Fi stops, and vice versa.
Therefore I suggest using ADC1-pins if WiFi is used for connectivity.
Since All ADC2 Pins Can't be used while using WIFI, You can use ADC1
GPIO32 ADC1_CH04
GPIO33 ADC1_CH05
GPIO34 ADC1_CH06
GPIO35 ADC1_CH07
GPIO36 ADC1_CH0
GPIO39 ADC1_CH03
Check this video to learn more about esp32 pins and assigned pirepherals:
https://www.youtube.com/watch?v=LY-1DHTxRAk&t=546s
I just installed the latest version of LIRC(0.10.1-5.2) on my Raspberry Pi 3, running Raspbian on Debian Buster.
I am trying to get my Pi to take input from an IR remote using lirc.
I have made the necessary changes to these files :
/etc/lirc/lirc_options.conf
driver = default
device = /dev/lirc0
/boot/config.txt
dtoverlay=gpio-ir,gpio_in_pin=18,gpio_out_pin=17,gpio_in_pull=up
//I set mine on up on GPIO pins 17 and 18 instead of 22 and 23
I have checked and cross-checked my circuit. Everything looks okay.
The challenge I'm facing right now is when I test my IR receiver using the following command,
mode2 -d /dev/lirc0
Nothing happens. There's no output at all. No pulses recorded.
Has anyone else experienced this issue?
Any help would be much appreciated.
After spending a great amount of time, trying to figure out how to solve this issue, I was finally able to resolve it.
So hopefully my answer will help someone else.
First things first, it's important to note that infrared device has changed from lirc-rpi to gpio-ir
Although, I already had this change in my /boot/config.txt
file,like below:
dtoverlay=gpio-ir,gpio_in_pin=18,gpio_out_pin=17,gpio_in_pull=up
// in stead of dtoverlay=lirc-rpi
I just thought it was important to point out.
Since I am trying to get my Pi to take input from an IR remote using lirc, I decided to first test my IR sensor separately, to make sure it works.
To do that, I connected up the sensor like so:
Pin 1 is the output so we wire this to a visible LED and resistor
Pin 2 is ground
Pin 3 is VCC, connect to 3v3
You can find more detailed step by step instructions from this tutorial here which also shows how to wire up your circuit as seen below.
During this test, my LED lit up each time I pointed a remote at the receiver, which gave me hope that it was working just fine.
The next step was to test the IR receiver on my raspberry pi, which is the challenge I had in the beginning.
I re-wired my circuit, this time:
Pin 1 is DATA, goes to RPi pin 12 (GPIO 18)
Pin 2 is GND, goes to RPI pin 6 (GROUND)
Pin 3 is POWER, goes RPi pin 1 (3v3)
Then I ran this command sudo /etc/init.d/lirc stop to make sure that service wasn't running.
I then ran the initial command mode2 -d /dev/lirc0 and now pressed random buttons from my remote at the receiver and violá! I could see some pulses on the screen with each button press now.
Like you I managed to get all the way to receiving pulses/data on the RPI 3, seem to have a problem with the output.
I have the USB strip light and my RPI with the IRC receiver, this is so I can monitor what data captured corresponds with the button pressed on the remote keypad. Works just fine.
However? If I push the ON button - I get data, if I push the ON button again I get another set of data. The two set of data dont match? , in both cases mode2 or mode2 -r.
I get the feeling I'm missing a method to decode the output, I've noticed there's a huge amount of companies and they all have distinct code sets.
Here is one thread that exactly matches what I have (24-Key IR remote).
http://woodsgood.ca/projects/2015/02/13/rgb-led-strip-controllers-ir-codes/
However I dont see the same set codes ???
Try to change the device to mode2 -d /dev/lirc1
I also faced this.
I have been working with ATmega128 and other such series for about 2 years and used a UART library for serial transmission. I am pretty sure the library is correct because I have used it hundreds of times but from the past few months I cannot do UART on my ATmega128. I am sure that my hardware is correct, I am sure of my code and to add to it, the same hex file runs good in other two ATmega boards but not in other boards.
PORTs are giving 5V output when all pins coded to give output.
Statements execute before any UART function occurs and after that it stops (does nothing, no UART, not even statements after UART)
I tried copy pasting UART code completely in main.c and it worked then.
Please help! I have no idea what is going on.
Well, after a lot of tussle, I finally found the problem and solved it. When I checked the fuse bits of the other microcontroller (the working one), I found Extended Fuse bits different from the not working microcontroller. I changed the Extended Fuse bits to 0xFF and problem solved.
Currently I'm trying to check the booting time of an Tixi board using systemd on a 2.6.39 linux kernel. To do so I created a service file that calls a bash script which sets and uses a gpio. The problem is that my systems is not allowing me to change the value of the gpio. I can sucessfully export it, change its direction, but NOT the value. I have connected an oscilloscope to check if the value had changed in the hardware but not updated in the file as suggested in some forums, but it was the same: the value just doesn't change!
I should also point out that the same script is working if I use system V, with exactly the same coonfiguration for the kernel, busybox and filesystem.
It is very ironic because I'm already the root of the systems, nevertheless even changing the permissions of the file, would not allow me to change its value. There is also no feedback from the kernel saying that the operation was not possible, but rather it looks as if it was possible but when I check the value, it was the same as before.
I also tried to run that in the Raspbian with a 3.12 (which I changed to systemd) and it was in fact possible to do it, just in the normal way from userspace.
I would appreciate if you have any idea oh what might be the problem since I already run out of ideas.
Thanks
PS: This is the code that should work on the bash line:
echo 0 > /sys/class/gpio/gpio104/value
more /sys/class/gpio/gpio104/value
// I get 1 not 0 as I requested
Nevertheless the same lines of code in the same board work if I use systemV but not if I use systemd
Probably cause by the lack of udev in your new setup which change the permission for those gpio in /sys/class. You might want to just put back udev to see if it fixes your problem.
I don't know your image setting, but each gpio pins needs to be exported prior to usage. Are you doing it or it's done automatically? If you have omap mux kernel switch, you do something like :
echo 0x104 > /sys/kernel/debug/omap_mux/cam_d5 (set mode 4 as stipulate in TI Sitara TRM)
echo 104 > /sys/class/gpio/export (export the pin)
echo out > /sys/class/gpio/gpio104/direction (set the pin as output)
Also do a dmesg | grep gpio and see if there's any initializing problem with the gpio mux.
Actually I've faced an issue similar to your's , ie was not able to change the value of set of gpio pin manually
Finally the result obtained was even though the name of that pin is gpio it can only be used for input only (DM3730 gpiO_114 and gpio_115).
So please refer to the datasheet and confirm it can be used for I/O operations..
I am having an odd problem with my PIC16F88. I have an EEPROM connected thru I2C and it works flawlessly until I write to portb.bit6. From that point on, I start getting garbage from my EEPROM. I tried explicitly disabling Timer 1, which uses portb.6 for oscillator-out but that did not help. I tried cutting the trace from the PIC pin (pin 12) so that there is nothing physically connected to it and that did not help. My C code is simple, either portb.6 = 0 or portb.6 = 1. Either way, reading the EEPROM thru I2C fails forever more. The generated ASM code looks fine. The problem occurs on every board that I have tried it on, so it is not localized to one PCB. I am mystified. Any suggestions?
It turns out that it is necessary to write a zero bit to the SCL and SDA pins every time before writing to any bit in portb. FWIW, I was bit-banging rather than using the SSP peripheral of the PIC16F88 for the I2C communicaitons. Thanks to the people on the Yahoo group, Electronics_101, for figuring out this puzzle.