pi zero "microcontroller" behavior

[fractured_one]

I've seen a few of the posts discussing the potential of pi zero as a micro-controller. I'd like to do that as well, however, I don't want to give up the linux environment. Without going into too many details, suffice to say that I would like a hybrid system.

One thought I had was to sort of black box the OS itself and put bare-metal type code in front of it that essentially allowed linux to be fed time-slices as the time-sensitive portions of the application deemed suitable. This seems particularly attractive because it does not involve maintaining a special version of raspian. The tricky part is that I'd want to use the linux to to manage the controller (start, stop, update, communicate changes in user settings, etc).

Has anybody explored any hybrid approaches like this, or have any suggestions on it?

Cheers!

[stderr]

One thought I had was to sort of black box the OS itself and put bare-metal type code in front of it that essentially allowed linux to be fed time-slices as the time-sensitive portions of the application deemed suitable.

Perhaps I'm not following you, but doesn't this require some real low level control of a running linux kernel? I've wondered about adding something to the initial ram file system that did some simple stuff right away, say turned on or off a relay, then went on to the complete boot. The idea would be that the system needed to do this simple things, which might be turn on a light as quickly as possible after being turned on by a light switch, but then a few more seconds would be available for a complete boot and other features like dimming, motion detection, or whatever. But it seems like you want the low level stuff happening all the time.

The pi zero doesn't have wifi or ethernet, so it might be hard to argue against the hybrid approach of adding a zero to something like an esp8266. The 8266 boots fast and has wifi, the zero could take over the more complex chores once it is ready. So they could work together well.

[Gavinmc42]

The Pi is bit more than a micro, but the closest way to use it as one without loosing most of the nice extra stuff is via Ultibo.
https://ultibo.org/
This gives you multitasking and multi-core without a lot of the pain of having to do it all yourself.

Another option is run Linux on the Arm and a RTOS on the VC4, which is how Raspbian works with the VideoCore doing the graphics stuff via a ThreadX RTOS.
If you don't need HDMI output or Camera stuff on the Zero then the VC is free to do other stuff.
The fft demo uses some of the VC QPU slices, still some left.

You will need to suck up all the info on the baremetal forum and then some.
There are reverse engineered assemblers/compilers for the VC4.
Using the Arm for Linux and the VC for a RT microcontroller is possible, just not mainstreamed yet?

Useful applications would be 3D printers and CNC machines.
Use some of the VC4 QPUs for simple hdmi console, Linux on the Arm and one QPU for 4 axis stepper motor control.

There is also supposed to be a DSP in the Pi somewhere too.
Still much to learn about these Pi's.

Personally I am hoping someone can figure out how to make a Pascal compiler for the videocore, then the Ultibo toolset can be used to do everything. Or maybe Arduino can be expanded to do Pi's+VC4.

[Burngate]

Does it have to be a Zero?
If you allow the use of a 3B (or sometime in the future a Zero with 3's SoC ) you could allocate three cores to Linux and reserve the fourth for bare-metal.
I've been trying to do this for some time, but not so far got anywhere ... but it should be possible.

[Gavinmc42]

Have not seen a Linux multi-core example with one core running realtime stuff yet.
But in baremetal the first examples are out.
https://ultibo.org/forum/viewtopic.php?f=10&t=292

Off topic for a Zero unless you consider a Zero an Arm micro with 16 extra cpu's. The original Videocore's did not have Linux or an ARM cpu and ran an RTOS.

you could allocate three cores to Linux and reserve the fourth for bare-metal.

Or one to Linux and 3 to baremetal?
One Arm to Linux, 3 ARM and 4 QPU's to baremetal.
Each QPU has 4 slices, can a RTOS be run in one slice?

Doing it with a Zero? 1GHz microcontroller on a $5 pcb.
"More please sir":P
Let's see what we can do with a Zero.

[fractured_one]

I've got two projects going on. One is a cnc table. I've been leaning towards using my 2B and seeing if I could get away with core lock/priority boost approach. At least initially, I have no need to push things speed-wise and I'll be using feedback so jitter-proofing stuff shouldn't be too hard if I have too.

The other project, however, is more along the lines of mesh network sensors / controllers. I've been collecting pi zeros and I can get them up and running with wi-fi using those edimax nanos (and that hack to keep them always on: viewtopic.php?t=61665). The idea there is to use SSH as the "back door" so that I could develop/manage the devices in situ .

Two things in the replies that stuck with me:

1) I noticed yesterday when reading the boot sequence that the VC seemed like a viable computational resource esp. when you don't care about video at all. I haven't even cracked the books on that whole side of things. More cores? Yes please.

2) I tend to agree that the idea of a microcontroller running at or near 1GHz for $5 is pretty exciting too!

I have an EE degree and have been developing low-level, high-performance software on Windows for 20 years. I also happen to have until the new year to work on these projects full time! Who knows, maybe I'll be able to contribute back! I'm a low level bit jockey at heart for sure!

So, yea, I'm learning new things like crazy right now. Currently, I'm trying to set up a cross-compilation setup on an Ubuntu VM so that I can quit compiling on my 2B and use my desktop to compile and disseminate new executables to the various pi's around the place.

Cheers!

[Gavinmc42]

Currently, I'm trying to set up a cross-compilation setup on an Ubuntu VM so that I can quit compiling on my 2B and use my desktop to compile and disseminate new executables to the various pi's around the place.

I use Ultibo on Windows at work and in Wine on Mint at home.
Cross compiles to all Pi's.
Native support can/is possible in Linux and on Pi's with some effort.
Pascal does compile faster than C.
Ultibo has no SSH yet as that requires crypto, which is still coming.
It compiles to a kernel.bin file which can be copied or booted over a network.
Full multicore support, which is why I am learning it.

But if you don't want baremetal then I suggest piCore Linux.
Based on Tinycore it is small and runs from ram.
I use it for IoT stuff and it has OpenSSH etc, some units have been running for years.

piCore OS for Linux stuff you need to do now, Ultibo for realtime multicore stuff that is hard to do when the OS gets in the way.

I don't know of any Linux OS that combines both capabilities, not sure if xenomai can do RT on another core.

[fractured_one]

something for starters

rpz0_mounted_tiny.jpg (61.97 KiB) Viewed 3106 times

Here is our subject - ready to rock. Just add 5V and he's on the LAN headless.

So, one thing that came to mind in an old trick used by console game programmers. If, for whatever reason, they can't get the game run stably through level loads they will implement a special machine reset that "continues" where it left off. It is seamless to you but the game starts with a new memory map as if it was the first level you loaded.

If we start out simply with the requirement that the system is bi-modal, then perhaps this can be accomplished by a similar strategy of altering the startup path and rebooting. To keep it easy, we could simply require that the implementation provide the "Exit RT Mode" signal. What do you think?

I did get the Visual Studio toolchain up and running today and did some remote debugging on a simple test app on my 2B. Bye-bye Ubuntu VM.

Getting it to work on a Zero and also getting my feet wet with Ultibo are next.

[DavidS]

Interesting topic. Not quite what I expected though.

As a foot note, the single Raspberry Pi's also work good to control a 3D printer, just banging GPIO and displaying some video on a composite NTSC display, with a simple keypad for control of the printer. Just add some good isolating drivers and you are good to go (I do not use motor controller IC,s as I prefer to bang my own stepper signals out. Using a 4->16 bit demux and 16 transparent latches before your driver IC's makes it easy to have up to 16 steppers taking only 8 RPi GPIO pins (4 for the current out selection, and 4 for the signal to update that output to), this leaves a lot of GPIO pins for use by stop switches, level switches, and what ever other extras your 3D printer uses.

Also note that it is very easy to write a G-Code interpreter when you have a lot of room to work with. And we have way to much with the RPi boards (my Prusa i3 controler board using a RPi B only uses about 100KB of RAM, plus the video buffer, and it does a lot of extra (like a crude rendering of the print built as it prints).

It also works well to use RISC OS in single tasking for the basis of a 3D Printer controller (and interpreted BBC BASIC V is fast enough to do the job). This is how mine began life, just a stripped down RISC OS running a BBC BASIC V program that controlled the printer and gave some graphical feadback, used the mouse to provide commands to the controller (no keyboard is attached).

Though otherwise nice use of a RPi 0.

[aaronpeacock]

there was something called "RTLinux" that ran Linux as a low-priority thread of a realtime kernel that only ran when the realtime kernel allocated timeslicing for it...

https://en.wikipedia.org/wiki/RTLinux