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.
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 want to create a basic project in Vivado that takes a value that i input to a client, which is sent to a server I made (in C), and then the server writes that value to a peripheral in Vivado, and then that data in the peripheral is sent to an output pin that assigns to LED's, making the LED light up.
Basically I want to go from client-->server-->peripheral-->LED lights up
For example, in the client (a GUI) I want to give it a value such as 0011, which is received by the server. Then the server writes that value to the peripheral which will then make, in this case, LED0 & LED1 not light, but LED2 & LED3 will light.
I know how to make an AXI4 peripheral in Vivado, and the client-server (TCP/IP) has been made. My question is what code/design block I would need to then take the data written to the peripheral and assign it to the LED's?
Should I make the peripheral a Master or Slave? Overall confused how should i proceed from here. I am using a Red Pitaya (Xilinx Zynq 7010 SoC) connected by an Ethernet cable to my computer.
Also, I thought of running the program on the Red Pitaya by loading the bitstream on to it (using WinSCP) by running the command
cat FILE_NAME.bit > /dev/xdevcfg
in PuTTY (connected to the Pitaya by IP address), then running the server on the pitaya, and then sending the signal from the client for the server to receive. Is that the correct way of approaching it?
If my logic is off in anyway please let me know
I am somewhat thrown by your statements.
First you say "I know how to make an AXI4 peripheral in Vivado"
Next I read: "Should I make the peripheral a Master or Slave?"
Maybe I am wrong but to me it says you don't really know what you are doing.
Simplest is to:
Instance a zynq system.
Add the IP with the name "AXI GPIO". (Which, by the way, is an AXI slave.)
Run the auto connection.
Assign the right I/O pins to the GPIO port. (check your development system manual)
Build the system.
By the way you find the address of the peripheral in the address tab and it normally is 0x0080000000.
You wrote that you made a server (TCP/IP). "All" it has to do is write the received value to a register in the GPIO block. (Here I assume Xilinx has a document which describes how the GPIO block works and has example GPIO drivers.)
I just started with microchip world.
I'm about to buy a PicKit3 and i've seen it can outputs from 1.8V to 14V MCLR.
The pic i will use is the PIC16F1829 and it should work with MCLR # 5V.
In the datasheet it seems i would need a zener/shunt to limit the voltage.
First of all isn't there a board ready to play with?
Can i use LVP? If so using MPLab 8 IDE how do i change in LVP?
Is the pin connection the same?
Since i haven't bought it yet i would rather avoid burning a pic
Regards,
Notes at the bottom of page 345 in the PIC16F1829 data sheet (DS40001440E) recommends using a voltage limit circuit when using the ICD2 device programmer.
According to Microchip this is "not required" when using the PICkit3.
Get a few extra PIC16F1829 just in case.
You ask about boards ready to use, take a look at the Curisotiy Nano boards
https://www.microforum.cc/topic/9-microchip-xpress-evaluation-boards
These are ready to use and do not need any programmer. You can simply send a file to these devices over USB. They are also have debugging capability.
In terms of the 14V on MCLR, the device is designed to handle whatever pulse will be generated by the PICkit3, so you do not need any protection for the PIC against that. In fact limiting the voltage on that pin will prevent the device from programming so you definitely do not want to do that. If you are however using this pin to connect to other parts on your board the other parts probably will need protection.
You can most definitely use LVP, just be careful, it is possible to use LVP to disable LVP, and then the only way to get it back on is to use HVP!
Lastly in the IDE under programming options you can change the mode there (Use low voltage programming mode entry)
In the IDE i've set the voltage appropriately and everything went ok on its own.
I didn't have to enable anything fancy
I have been unable to find any documentation regarding using python to change the GPIO outputs, and was wondering whether there was any specific code i could use to change it or if there were any third party programs that allowed me to do so.
You cannot change the current of GPIO pin, that's not how it works.
If you want to know the maximum value of current for GPIO pins, this article says it's 16mA per pin, with maximum of 51mA for all pins.
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)