Yes - the only thing I know about kernel and spi is the param in /boot/config.txt:
dtparam=spi=on
Never heard of spi-dev, but I keep the whole concept of the Linux kernel, and that even more obscure thing the Broadcom firmware, as the other black boxes for other people to worry about.
When I mentioned back dating the kernel to fix the garbled sound, it may have actually been the Broadcom firmware I had to back date - I just don’t remember, but now when I try something and hear garbled text-to-speech, I back out the update and clamp down the system with multiple backups.
Ah yes, ROS - the “Robot Obfuscation System” we are looking to for enlightened robots.
Have you solved how to make bootable hot backups of Finmark?
I can shut down Dave and dd a backup on my Mac, but would like to not have to unplug and reinsert that SDcard.
Carl has this neat program “rpi-clone” that he uses to make bootable hot backups of Raspbian For Robots (or PiOS), but so far I haven’t had success on Dave cloning Ubuntu 20.04.
Update: Looks like the secret is to flash the target backup card first with Ubuntu 20.04, then rpi-clone to the target.
Current Raspberry Pi design allows you to set special “bit flags” on the board to select boot priority and fail-over policy if booting from a particular device fails.
(AFAIK) The default setting is to give boot priority to the SD card and fail-over to USB if a SD card is not there.
I believe you can set it to give boot priority to USB, and fail-over to the SD card.
You can load up a R4R image on a small thumb-drive and insert that when you want to make a backup.
Or, you can place a small partition on the SD card itself and jumper select booting to the “backup” OS the way I do.
I deliberately moved to a larger SSD, USB booting, and the ability to multi-boot different operating systems to avoid just that problem.
. . . . That is, after I split a fifth SD card in half that contained an irreplaceable image of Charlie’s OS while trying to swap SD cards!
Needless to say, it cost me about $70 each for several SSD drives, (not to mention the window next to me after I melted it swearing a blue streak!)
However, I now have a method for making fully restorable images of any OS on the drive and I don’t have to mess with fussy little micro-SD cards!
That’s a great sounding platitude, but “True [robot] enlightenment” will be neither simple nor elegantly simple.
Or in hardware terms, a computer is a totally fixed complex organization of a billion elegantly simple electron junctions that require an equally complex organization of the three elegantly simple atomic functions (set, test, jump) to be useful for any truly usable task.
Perhaps joy is found in elegant simplicity, but reality is complex, messy, and anything but simple.
I found something that actually works with the GoPiGo-3!
One of my long-time desires was to have some kind of “secondary” display for Charlie where I could send important messages that are important even if the 'bot is running headless.
The people at WaveShare, (www.waveshare.com), have a series of e-Ink displays.
I bought a 2.13" two color, (red and black), e-Ink hat for Charlie:
This allows me to post a “message to myself” about the configuration and other essential details.
Hopefully I will find out a way to make it more relevant.
One thing I do notice is that, occasionally, the display will update with a vertical-bar display artifact that I suspect is caused by contention on the SPI buss. There’s probably a mutex I have to invoke somewhere to keep east and west separate.
P.S.
This message tells me:
I am running GPGOS 3.0.1, (instead of 3.0.0)
That I have fully updated the operating system and all the packages via apt-get.
That the running kernel is a 32 bit kernel (instead of a 64 bit kernel - that’s one of my dip-switch selections) and that as a consequence Dex’s eyes are GREEN. (They’re blue if 64 bit)
AND! When I did the apt-get upgrade, I specifically excluded, (via an “apt-mark hold”) the pigpio packages.
This way, each operating system is self-describing on boot-up.
The original display is the display from the prior session. e-Ink displays do not change unless explicitly commanded to change - even if power is lost.
The first event is the initial “initialize and clear the screen” event.
The second event puts the first part of the message on the screen.
The third event adds the last line.
Each message is like updating a graphical display - you build a buffer that gets rasterized and “blitted” to the display.
If you accidentally put something where something else is, they’re combined, overwriting each other.
I suspect that all the flashing and blinking is the controller resetting all the dot elements to a known state, then blitting in the buffer.
Very cool.
I’m a little bit familiar with a board from AdaFruit that also has an e-ink display. That board has a sleep state which is VERY low power - the board will wake on a signal, or after a certain amount of time has passed (and will run a specific program when it wakes). Does your board do something like that?
/K
This board also has a very-low-power sleep state, but for an e-ink display it borders on being an oxymoron - e-ink doesn’t draw power unless it’s being changed.
If I remember rightly, the quiescent current borders on microscopic and the sleep current is infinitesimal. I really didn’t see the reason to put it to sleep, as the steady-state current of everything else is so much larger by comparison, it seemed pointless. . . .
The audio, if you can hear it, has me “start!”(ing) the script at about four seconds into the video. The display script has ended when the pan-and-tilt servos begin moving, so I used that to indicate end-of-script.
Total time from clicking on the script to servo movement was about 30 seconds.
