I can successfully export a GPIO pin, set both input and output directions and change the value, and apparently read in an input.
But, I’m not able to monitor the GPIO change input or output state
When I enable the GPIO sysfs, the result of # cat sys/kernel/debug/gpio is GPIO 206-255
.
I wrote a C program to enable each pin successively, and these were the following that were able to export:
207, 212, 213, 214, 216, 218, 220, 223, 224, 226, 228, 230, 233, 234,
242, 243, 244, 245 & 254.
https://dl.dropboxusercontent.com/u/5368870/gpiosysfs.jpg
Afterwards, I assigned each of the pins as an output, and attempt to toggle it. My test board has the all GPIO pins wired out to a breadboard with a +5V and GND supplying power to a transistor with an LED and the GPIO pin feeding into the base through appropriate sized resistor. As I changed the output value of any GPIO pin, my test circuit remains unchanged. I have also configured each pin as an input and fed in 5V and again, no changed in the read value.
I’m running Linux 3.10.18 on an Advantech SBC.
http://www.advantech.com/products/1-2JKD1I/PCM-9389/mod_622b1bb4-6d15-4be3-bb88-d20fe6736a1c.aspx
Any ideas what is going on?
Related
I'm trying to turn on and off the GPIO headers on the beaglebone, but i'm unable to get the physical pins to switch from high to low and vice versa. Ive written some code within my application to do this but even when I change the values in the command line I have the same issues.
Firstly, all of the pins I want to use have been correctly exported. For this example lets focus on GPIO 117. I'm able to change into /sys/class/gpio/gpio117 and when I run cat value, its in line with what I expected from my program. When I run echo 0 > value it changes to a zero and when I run echo 1 > value its a 1. Everything as expected. When I go to measure the voltage on that pin, it is always high, independent of the value.
Am I missing something here?
GPIO 117 is gpio3_21 on the "MCSAP0_AHCLKX" pin. So it is probably used by some audio device, probably HDMI. You can disable that by adding disable_uboot_overlay_audio=1 to your /boot/uEnv.txt file, see https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices
I'm working on a Linux kernel driver for the Texas Instruments tps92518-Q1 and tps92518HV-Q1. This device uses 16-bit SPI Frames (7-bit control, 9-bit data).
Command frame
1-bit command bit
5-bit Address
1-bit parity
9-bit data
Read response frame
1-bit SPI error
2-bit reserved
1-bit power cycle
1-bit LED2 BOOTUV ERROR
1-bit LED1 BOOTUV ERROR
1-bit THERMAL WARNING
9-bit data
Write response frame
1-bit SPI error
1-bit command
5-bit Address
9-bit data
The main problem here is the requirement for a parity bit on any write operation. So I need to be able to calculate the parity bit for any command frame
PARITY = XNOR(CMD, A4..A0, D8..D0)
I can define a regmap, e.g.
static struct regmap_config tps92518_regmap_config = {
.reg_bits = 6,
.pad_bits = 1, // parity bit
.val_bits = 9,
.max_register = tps92518_RESET,
};
From regmap.h it looks like I might be able to set ->reg_read() and ->reg_write() callbacks, but I don't know what I would actually have get those functions to do.
Is there another method of preprocessing any request/response?
The Linux kernel SPI documentation mentions the protocol drivers but can I see where I could specify a protocol format?
I was playing with my Raspberry Pi over the weekend. I used a tutorial from Freenove that I followed to realize a few simple circuits that are controlled by the GPIO pins on the raspberry.
The Freenove tutorial is using a deprecated library named WiringPi. Besides the fact, that its deprecated, my understanding is that WiringPi adds additional abstractions and simplifications to allow users to focus on their circuits and less on writing boilerplate code to integrate low-level (C) libraries.
Now I want to gain a better understanding about how user space applications interface with the hardware GPIO pins and I am not worried about writing boilerplate code. So I started to play with libgpiod, which has a C API that can be used to read and set GPIO pins and that works well.
One thing that is not clear to me is how I can map the physical hardware GPIO pins on the 40pin connector (which are numbered from 1 to 40) to one of the 54 internal line numbers that gpiod reports when I use the gpioinfo command.
On my Raspberry 3b+ with Raspbian 10 the gpioinfo command prints the following, with all line names showing as unnamed. The list goes on like this but I truncated it at 10 lines.
gpiochip0 - 54 lines:
line 0: unnamed unused output active-high
line 1: unnamed unused output active-high
line 2: unnamed unused output active-high
line 3: unnamed unused output active-high
line 4: unnamed unused output active-high
line 5: unnamed unused output active-high
line 6: unnamed unused output active-high
line 7: unnamed unused output active-high
line 8: unnamed unused output active-high
line 9: unnamed unused input active-high
line 10: unnamed unused input active-high
[...]
I found an issue about missing GPIO line names which discusses this problem but I do not understand the answer or why it was closed.
How am I supposed to lookup the line numbers of the chip based on a pin name such as GPIO17? I found by trial and error that GPIO17 maps to line 17, but for example CE0 maps to line 8 and SCL1 maps to line 3, which I learned by trial and error using gpioset.
I am not sure if its a good idea to hard-code this mapping into my application, or if I somehow should discover these values programmatically to make the program more portable?
I tried to use gpiod_ctxless_find_line:
gpiod_ctxless_find_line ("SCL1", configuration->chipname, configuration->chipname_length, &offset);
but even while that returns a value of 0 (OK) the resulting offset is 66796 which is not the correct value. I assume it does not return anything, because gpioinfo has no names for the lines.
If I write a C program using libgpiod, can (should?) I discover these mappings at runtime, or is it ok to simply hard-code them? Is is possible that on a future Raspberry the SCL1 will not be at physical pin 5 or map to line 3?
While I was writing this question, I found that the official Raspberry GPIO documentation has these pictures, which show the mapping, and then I realized that the yellow GPIO numbers from the second picture correspond to the libgpiod line numbers. So there is a one-to-one mapping between GPIOxx and line number:
I guess there were two confusing parts in my the learning process. The first was that WiringPi uses different GPIO terms than the Raspberry. For example, WiringPi has two blocks of GPIOs numbered as GPIO0 (wiringPi) to GPIO7 (wiringPi) followed by a gap for the special pins like SDA1 and another block numbered as GPIO21 (wiringPi) to GPIO29 (wiringPi). So the GPIO29 (wiringPi) is actually GPIO21 (raspberry) on the Raspberry.
The second part is that my breakout board shows only the semantic names for some GPIOs rather than the actual GPIO number (for example instead of GPIO 2 (SDA) it only shows SDA).
Using the pinout command one can see the official mapping of the Raspberry Pi which maps GPIOs to physical pins. The same information is present in the gpio readall command in the BMC column, but the name column shows the wiringPi GPIO names not the Raspberry pi GPIO names from the image above.
The issue you referenced about missing GPIO line names was resuscitated recently, and AFAIK has finally been resolved. The issue was that the device tree did not have gpio-line-names defined. This was corrected in the RPi 4B a while ago, but for some reason the older platforms were overlooked. I think all of the source files have been updated now - though you may still need an rpi-update for a while until the firmware is released for apt updates.
FWIW, I elected to add the gpio-line-names to my RPi 3B+ with a device tree overlay. I did this strictly as a learning exercise, but I'm not sure I learned much as device tree code seems arcane to me. Nevertheless, having finished the overlay project I do like the idea of having an overlay as it allows me to easily change the gpio-line-names to suit my preferences.
I'm having trouble loading code into my ESP8266 board. The error msg was posted below. Note that my board was working a year ago.
Arduino: 1.8.9 (Windows 10), Board: "Adafruit Feather HUZZAH ESP8266, 80 MHz, Flash, Disabled, All SSL ciphers (most compatible), 4M (1M SPIFFS), v2 Lower Memory, Disabled, None, Only Sketch, 115200"
Sketch uses 257696 bytes (24%) of program storage space. Maximum is 1044464 bytes.
Global variables use 26572 bytes (32%) of dynamic memory, leaving 55348 bytes for local variables. Maximum is 81920 bytes.
esptool.py v2.6
2.6
esptool.py v2.6
Serial port COM8
Connecting........_____....._____....._____....._____....._____....._____.....____Traceback (most recent call last):
File "C:\Users\Owen\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.2/tools/upload.py", line 25, in
esptool.main(fakeargs)
File
"C:/Users/Owen/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.5.2/tools/esptool\esptool.py", line 2653, in main
esp.connect(args.before)
File "C:/Users/Owen/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.5.2/tools/esptool\esptool.py", line 468, in connect
raise FatalError('Failed to connect to %s: %s' % (self.CHIP_NAME, last_error))
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
_
There could be many reasons for this problem.
1st proposal: the esp and the attached sensors etc. are consuming to much power. Detach the sensors and try to upload the sketch again. Or make sure, that you esp is getting enough power. (You could also try another micro-usb cable / power source)
2ns proposal: change the baudrate.
3rd proposal: If you connected an micro SD shield, detach the microSD card and try again.
These have been the cases, when I ran over this issue. I hope one of those guesses is going to help you.
I have an STM32F102 microcontroller and I want to program it via the Serial Port.
While there is a flasher available for windows, I want to do it on a Linux Machine. I tried doing it with this script
I have set BOOT0 = 1 and BOOT1 = 0, restarted the microcontroller. But it does not work. I get the following output
Can't init. Ensure BOOT0=1, BOOT1=0, and reset device
Traceback (most recent call last):
File "stm32loader.py", line 552, in <module>
bootversion = cmd.cmdGet()
File "stm32loader.py", line 140, in cmdGet
if self.cmdGeneric(0x00):
File "stm32loader.py", line 137, in cmdGeneric
return self._wait_for_ack(hex(cmd))
File "stm32loader.py", line 88, in _wait_for_ack
raise CmdException("No response to %s" % info)
__main__.CmdException: No response to 0x0
Here are a few tips:
Connect serial cable before resetting / powering up the board. Otherwise some transients can mess the serial bootloader up.
Make sure you are using a TTL level USB-to-serial converter instead of a RS-232 cable. RS-232 has inverted level, and worse still, its -15V to 15V voltage range can burn your STM32.
Make sure RX and TX are connected correctly.
Try using stm32flash instead.
Most STM32's serial bootloader does not support baud rate higher than 115200 as I remember. The bootloader can detect baud rate automatically, the one I usually use is 57600.
Some of these chips are being shipped with locked bootloaders. You will need to use STM32 Flash loader demonstrator to remove the protection. Windows only unfortunately but once it is unlocked you can use any machine.