How to do things with the beaglebone
A scratchpad. At some point these may have their own pages.
Beaglebone
Work with an EEPROM
cd /sys/bus/i2c/devices/i2c-2/ echo 24c01 0x54 > /sys/bus/i2c/devices/i2c-2/new_device -bash: echo: write error: Device or resource busy dmesg tail -n 1: 919.609895] i2c i2c-2: Failed to register i2c client 24c256 at 0x54 (-16) echo 24c01 0x50 > /sys/bus/i2c/devices/i2c-2/new_device dmesg: [ 933.505690] at24 2-0050: supply vcc not found, using dummy regulator [ 933.513194] at24 2-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write [ 933.513451] i2c i2c-2: new_device: Instantiated device 24c256 at 0x50 root@BeagleBone:~# echo 24c01 0x50 > /sys/bus/i2c/devices/i2c-2/new_device
A few tips. 1) Make sure you have the right type of EEPROM. If you get the size wrong, it will not write correctly, and reading the eeprom file by sysfs will give garbage data. 2) i2cset and i2cset can be used, but only when you haven't instantiated a kernel driver. 3) There is an eeprom kernel module, an at24 kernel module (the one i used), and there is also flashrom (a program) which usually operates over SPI but also has parallel and i2c support (though it might not have support for your eeprom. Check before using). 4) Verify what EEPROM you have (again point #1), and look at the ic silkscreen, as the schematic might be wrong compared to the actual chip on board. 5) The kernel will let you instantiate the wrong device if you are not careful (and it just won't work) so double check that the new_device command above is correct. 6) Don't necessarily believe what dmesg tells you. In my case, it thought the EEPROM was a 24C256, but that was false. 7) EEPROMs may be listed in bits, not bytes. So don't confuse a 24C01 1K thinking it's 1K Bytes, when in fact it's 1K Bits (128 bytes). Double check the data sheet. 8) There are other things to consider that I didn't list here. Such as underlying hardware issues (chip is write protected, or the protocol is not supported by default).
dd EEPROM
root@BeagleBone:~# dd if=image.png of=/sys/bus/i2c/devices/2-0050/eeprom count=128 bs=1 or root@BeagleBone:~# echo "my text" | dd of=/sys/bus/i2c/devices/2-0050/eeprom count=7 bs=1 seek=10
dd is a good program to verify the eeprom is working correctly in sysfs. You can use either approach above, and verify with hexdump -C -v. Note the following: bs must be used, or else you will likely get an error. With small eeproms (I have one that is 128 bytes) you can go over, (what I think) is the default bs (byte size) of 512 bytes. If you have duplicate data in the eeprom (i.e. you write to it with /dev/zero you must use the -v flag in hexdump, otherwise it will omit duplicate data (rtfm).
root@BeagleBone:~/eeprom_dir/2-0050# hexdump -C -v eeprom 00000000 72 69 67 68 74 32 0a 74 68 69 73 20 69 73 20 6d |right2.this is m| 00000010 79 20 73 65 6e 74 65 6e 63 65 20 6f 66 20 74 65 |y sentence of te| 00000020 78 74 2e 0a 00 00 00 00 00 00 00 00 00 00 00 00 |xt..............| 00000030 00 00 74 65 73 74 20 0a 00 00 00 00 00 00 00 00 |..test .........| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000080 root@BeagleBone:~/eeprom_dir/2-0050# echo "okrightwhatever" | dd of=./eeprom seek=100 bs=1 16+0 records in 16+0 records out 16 bytes copied, 0.0722206 s, 0.2 kB/s root@BeagleBone:~/eeprom_dir/2-0050# hexdump -C -v eeprom 00000000 72 69 67 68 74 32 0a 74 68 69 73 20 69 73 20 6d |right2.this is m| 00000010 79 20 73 65 6e 74 65 6e 63 65 20 6f 66 20 74 65 |y sentence of te| 00000020 78 74 2e 0a 00 00 00 00 00 00 00 00 00 00 00 00 |xt..............| 00000030 00 00 74 65 73 74 20 0a 00 00 00 00 00 00 00 00 |..test .........| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 6f 6b 72 69 67 68 74 77 68 61 74 65 |....okrightwhate| 00000070 76 65 72 0a 00 00 00 00 00 00 00 00 00 00 00 00 |ver.............| 00000080
i2cset and i2cget
example:
root@BeagleBone:~# echo 0x50 > /sys/bus/i2c/devices/i2c-2/delete_device (can't have it in sysfs and use i2cset/i2cget) root@BeagleBone:~# i2cset -y 2 0x50 0x04 0xFE root@BeagleBone:~# i2cget -y 2 0x50 0x04 0xfe
Pocket Beagle
Output Text to TFT
This assumes you have the game boy tft shield. Although others that are supported and detected will likely work similarly.
echo "hello" > /dev/tty0
to output to your ssh session, try
echo "hello" > /dev/tty
These are serial output or char devices (as opposed to block which would be HDDs/flash (see a unix book)).
Access the char devices in /sys/dev/char These will be the same devices as in /dev but if you ls -l on /sys/dev/char you can get the path to the control / metadata of a given device. Such as you would expect to see when flashing a LED on/off via sys/fs. ref: https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED#Setup and https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED#Checking_.2Fsys.2Fclass.2Fleds
Going to /sys/dev/char is intuitive, and more so than /sys/class/whatever. But /sys/class has things that dev does not have, so you must remember /sys/dev/char and /sys/class for starters. This will get you access to hw control, afaik.
Output Video to TFT
Download video from somewhere. Resize/scale to small enough resolution (NOTE: this resolution is 128x96, from book Ffmpeg Basics by Korbel)
ffmpeg -i video.mp4 -s sqcif outputsmall.mp4 mplayer -loop 0 -vo fbdev2 outputsmall.mp4
Video should output direct on /dev/tty0
Framebuffer settings:
cd /sys find . -print | grep fb0
There should be an fb0 (graphics) and fbcon (text console) e.g.
root@beaglebone:/sys/class/graphics# ls fb0 fbcon
ref: https://unix.stackexchange.com/questions/342815/how-to-send-ffmpeg-output-to-framebuffer
| ||||||||||||||||||
