On the raspberry pi 3 all GPIO pins are powered up with a direction of "input". Each pin has a pull-up and a pull-down resistor associated with it. The status of these resistors is preserved through power loss or reset. (This is why there is no way to read the status of these resistors because they may not be known after a reset.)
I wrote a program that forces all the pull resistors to disabled so that nothing is pulling the lines high or low and then rebooted. /sys/class/gpio/*/direction and values all indicate success.
After reset, all pins came up in the input direction and without pull resistors enabled except for:
GPIO2: pulled-up (No problem, due to externally soldered i2c pull-up
resistor)
GPIO3: pulled-up (No problem, due to externally soldered i2c pull-up resistor)
GPIO14: (TXD0) pull-down resistor has been re-enabled somehow!
GPIO15: (RXD0) pull-up resistor has been re-enabled somehow!
I have already previously used raspi-config to disable both the serial console logging and the serial uart. So I would think nothing in the boot process should alter the peripheral registers controlling GPIO14 and GPIO15.
What in the boot process is reconfiguring the GPIO15(RXD0) and GPIO14(TXD0) pins to have their pull-up/down resistors enabled and how to I stop it?
One thing I found out:
The pull-up/down resistor configurations on the broadcom chipset are non-volatile. (This is actually why you can't query what their status is in anyway; because the chip doesn't know what they are from boot time and can't query them itself. The CPU can only set them.)
So, if you turn off all the pull-up/down resistors the raspian distribution boots with all pins in the output/high-z configuration except for GPIO2 and 3 because these are the I2C pins with physical pull-up resistors soldered on board. The Tx GPIO pin also reads high but I think it due to the bluetooth system being initialized in the kernel and I don't know how to disable that.
So if you set all the pins to input/hi-z and disable pull-up/pull-down it will come up that way after reboot (unless you've enable something in the kernel or otherwise changed them after power-up)
Related
What I've been trying to do is send UART communications from an STM32 L152RE Nucleo board to an ESP32, however when I attempt to send these communications I get nothing on the ESP serial monitor. What I am able to see is the STM32 sending messages to its own serial monitor which is great but not what I want.
What I've read so far is that UART 2 is connected to ST-Link so that it can do specifically what I've been witnessing and it explains how this can be reconfigured to allow for the messages to be sent to a peripheral UART device but I'm not sure exactly how to do that.
So in the picture below it says to do this I need to "turn off" SB13 and SB14 and "turn on" SB62 and SB63. I don't really understand how to interpret that, other than to mean "remove resistors from SB13 and SB14 and Place them on SB62 and SB63", is this correct?
I know there are another set of UART pins on the board, can I use those instead somehow?
Your guess ist correct. "SB" means "Solder Bridge". It is just a pair of pads which can be connected with a solder ball, like a simple jumper. Setting SB13 to ON means to connect the pads with a solder ball, setting SB62 to OFF means to remove an existing solder ball connection.
Using a different USART is even easier. Have a look at the STM32L151xE Datasheet to find out that e.g. USART1 is available on pins PA9 (TX) and PA10 (RX). According to user manual of the NUCLEO-L152RE board these pins are available on the ST morpho connector CN10: PA9 at Pin 21 and PA10 at Pin 33.
I have been working for quite some time on Nucleo boards. I am used to configure the printf to output on the virtual com port.
However I couldn't make it work on STM32H73I-EVAL2. I know that the setting is different since it uses USART1 to connect to STLink and of course different GPIOs. I checked ST example code and the board user manual to know these differences. I also noticed that some jumpers JP7 and JP8 have to be switched in order to output USART1 signals on STLink instead of physical RS232 connector.
Here are the points I checked:
- GPIOs setting (pins, pullups, speed, etc...)
- USART1 setting (clock enable, clock selection...)
- COM port setting (baudrate, parity, etc...)
- Jumpers on the board
- Putty setting on my PC
I also tried through physical RS232.
Is there any trick or specificity on this board ?
I want to add external push button to Parallella's GPIO pins.
Is it correct to connect push button just like the users did for Raspberry pi boards?
enter image description here
if it's working, what resistor should I use? and if it's not correct, what schematic should I follow to connect push-button to one of the GPIOs?
I just had a quick look at the Parallella schematic. It is 17 pages with rather a lot of connections so I can't do a full analysis in a few minutes. (I would also need to work through the datasheet)
You must check which voltage your I/O pin is operating at. If it is 3V3 you can use the schematic as-is. If it is a different voltage you have to replace the 3V3
with whatever the I/O voltage is. For the rest the principle is OK: Pull the port low with a resistor and use a push button to the selected voltage to make it active high.
If you don't know which voltage to use set the pin in output mode and output a 'high' Then measure which voltage appears.
Note that in general it is safer way to use a resistor (e.g. 50KOhm) to tie the pin to the I/O voltage. Then use a push button to pull the pin low. If you make a mistake, the pin is more likely to survive as the resistor limits the current.
Is it possible to query serial port tx (send) pin status if it is active or not ?
For example when issuin break command (SetCommBreak) tx pin is set to active (low). I'd like to know when it is active or not. Thanks.
No. (at least not likely)
If you are using the "16550" family of UARTs, then I am confident that you can not query the serial port tx pin status. Of course, if you are using some new version or other UART family, maybe.
You can assume that the TX pin is in the SPACE state ('0', +Volts) whilst performing SetCommBreak(), but I suspect that is not enough for you.
If you are look to debug your code to know if a break occurred, you can short pins 2 & 3 on a 9-pin D-sub, thus loop backing the transmit to the receive. A paper clip will do. Your receive code would detect the incoming BREAK. Shorting to the incorrect pin does not cause a lasting problem with a conforming serial port, but be careful. Try this first with simple data, before testing BREAK condition.
If you have a "16550"-like UART.
You can put the UART into loop-back mode and see if you receiving you own outgoing BREAK signal. Its somewhat complicated in current PCs. Other UART type may support loop-back.
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!