Can I directly connect a GPIO OUTPUT and INPUT of a raspberry pi? I heard that this would be dangerous in case that both GPIOs are accidentally set as outputs and that it is better to put a resistor of at least 220 ohm in between (not to ground?). Is this really necesarry?
Related
I am trying to know the status of MCP3424, either it is connected or not to the master STM32 with defined address 0x68. The ADC module gets connected with the Arduino in same address but using STM32, I am not able to get connected with the following code:
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
if((HAL_I2C_IsDeviceReady(&hi2c1, 0x68 << 1, 100, 1000))==HAL_OK){
HAL_UART_Transmit(&huart2, "device connected\r\n", 10, 10);
}
else{
HAL_UART_Transmit(&huart2, "no device\r\n", 100, 10);
}
}
Is there any mistake that I have done in this code by chance or any other way there is to deal with MCP3424 ADC module specifically? Please suggest me.
I believe your problem lies with voltage levels: your STM32 functions with 3.3V, while MCP3424 is powered from 5V. Let's open the datasheet of the MCP3424, page 6:
High level input voltage is 0.7Vdd, which is 0.7V*5V=3.5V, which means your A/D can't detect "1" on the line. It sees the line as always "0", even when STM32 MCU outputs HIGH (3.3V).
Possible solutions:
Logic level conversion (various ways). A circuit between A/D IC and MCU to convert 3.3V levels into 5V levels. There are dedicated chips for that, there are also other approaches using resistors and mosfets. Something you may want to explore on electrical engineering stackexchange.
Check the datasheet of the MCU, find GPIO properties. It's very likely those I2C pins are in fact 5V-tolerant, meaning you can pull up I2C lines to 5V and still drive them with 3.3V STM32, and it will be within the spec of STM32 MCU. If that's the case, no extra circuit will be necessary.
I really wanted at first an rs232 8-channel relay board that I could command devices to turn on/off with a command string.
All of the ones I found online have the same deficiency in functionality for me: you can't set a subset of relays at the exact time. I can set relay 1 on, and then relay 7 on afterwards, I can set all 8 relays at once, but there is no command structure to pick out the exact leds I would like to turn on/off.
In the past I have dealt with hardware that had a bit-map of the IO pins, and a bit-map of the states and would apply all 8 settings at once. here are some examples:
to set pins 1 and 7 to on and the other pins off (8-bit binary bit-mapping,) send the following byte: in binary: 0100 0001b
to set pins 1,2,3,6 to on and the other pins off (8-bit binary bit-mapping,) send the following byte: in binary: 0010 0111b
I couldn't find any such device to do this so I thought I could make one with a raspberry pi using a simple 8-channel relay board, something like this:
https://www.amazon.com/SainSmart-101-70-102-8-Channel-Relay-Module/dp/B0057OC5WK
but on a Raspberry Pi, I'm running into the same issue: I don't see a way to set the gpio pins as a block command, only individually setting them in a for loop. I looked all morning and can see things like gpioctl, and mmio, but I can't put it all together to a simple proof of concept program on a testboard, any help would be appreciated.
I would really like a solution in C or scripting,
Thanks,
jleslie
I've got a Raspberry Pi Zero W v1.1 set up today and I've been trying GPIO's. Got them (I'll refer to GPIO #3) to output between 3.3v to 0.05v on command using echo 0 > /sys/class/gpio/gpio3/value with direction OUT and got them to read in logic 1 to 0 by connecting pin #7 (GPIO #3) to a ground (will replace with a sensor later on) with direction IN.
My question is: Would you consider this normal that the Raspberry Pi defaults to logic 1 as soon as you enable the export? echo 3 > /sys/class/gpio/export
Can somebody elaborate on why this is? Also, why is this exactly the opposite of this guy's scenario: Reading a sysfs GPIO input pin (direction as "in") always print a fixed value (0)
Kthx
You said there is nothing connected to the pin, yet you read value=1. This is due to internal bias on the input which is weak and can be over-driven by an external circuit if you were to connect something to the pin. The internal bias simply is a large (~1M ohm) resistor to the VCC, so you are reading this bias. Try connecting a 1K ohm resistor from the pin to ground and read it again. It should read value=0 as you were initially expecting.
I'm trying to talk via I2C to the gyro sensor MPU6050 which sits on a GY 521 board. But i can't get the device being detect.
I tested another i2c device (EEPROM) and got the device address detected. So i guess it has to be a hardware problem.
As far as i could find out:
RPi has a 1.8k pullup resistor on SDA and SLC already on board
my GY 521 also has also a pullup resistor (2.2k) on each line on board
Could the resistors be the problem? A good resistor value in sum would be around 5k on each line?
(The wiring should be ok, there are a lot of instructions around the net and i've checked it multiple times. I use 5v on the GY521 since it has a voltage converter)
Any help appreciated!
The problem was bad soldering.
For the record:
Using the RPi pullups in combination with the breakout board pullups works for me.
My Zynq board has SPI, I2C but does not have kernel level GPIO (The GPIO on the MIO is sent to a bunch of other things) so I can't get it from the headers. Believe me when I say this.
I need some kernel level GPIO so I can drive a touch screen interface. I need to map some GPIO to the stmpe610 touch screen driver (Device Tree compatible = "st,stmpe610"). This is all well and good. So what I want to do is somehow map the I2C to GPIO (which will be connected to the display), and pipe the driver to interface through I2C. This way I can access the GPIO pins of my i2c expander from kernel space.
I looked at the i2c-gpio driver, but it does the opposite of what I want (http://lwn.net/Articles/230571/). It takes GPIO and makes it I2C by bit-banging.
I have an i2c expander mini-board that will take I2C and spit out GPIO. So if I have a gpio-i2C that would be great.
Maybe I have wandered too afar and off the beaten path. Does the stmpe610 have an i2c driver? This would also alleviate my issue.
<<
If I have understood you correctly, you have a GPIO expansion board that you can connect to your Zync main board.
If the above assumption is correct, what you have to do is find the correct driver for your GPIO extension board. What model do you have ? What chip is there on it ? Maybe there is already a driver for it in the kernel. If so, you then just have to declare it under your I2C base controller node in your device tree so that its GPIOs can then be referenced in your device tree for your stmpe610 touchscreen node.
If the chip does not have a driver yet, you then will have to write a GPIO driver for the chip. One good example to start with is the GPIO driver for the MAX 7300, that is connected via I2C as well. Have a look at gpio-max7300.c and gpio-max730x.c