I am drawn to the prop because there is no file system working in the background, and this is why I shy away from the RPi for embedded devices. I just don't know if the RPi file system will get smashed by randomly timed power-offs. I expect that the Ulitbo would minimize the file access to the application itself. ... is this correct? Is there a way to ensure safe shutdowns of a RPi ?
Thanks Heater, that may work well for the true 'embedded' projects. For others, a tiny UPiS may be a better fix. I should have been clearer though ... I know when the power will be cut, I just don't know if the RPi will be doing anything at that instant. I do Prop EEPROM writes by command, so I can avoid these problems.
Chrome 53.0.2785.143 @win8 - works
Chromium 51.0 on Raspbian/RPi3 - works
37 seems to be obsolete
That's the version in Debian Wheezy. It receives bug updates, that's all. There's no way I would want to update to a different distro version just to get a newer Chromium, so I'll simply stay away from sites that won't let me browse them.
In Ultibo "there is no file system working in the background" Ultibo will not write to SD when you don't want to. So there is normal in Ultibo (look at demo video) that you can remove your SD card when the Raspberry Pi is on.
The hardware support in Ultibo is surprisingly wide. You have graphics, usb - hub, storage, kbd, mouse, GPIO, framebuffer, don't know what else, and FAT32/NTFS/CDFS filesystems.
No sound driver now, as I can see, but there is PWM supported, so as I have some experience in writing sound driver for the Propeller, it seems I can write one for Ultibo too.
It is interesting, and looks well supported. I hit a wall with I2C though ... it looks like the RPi has a hardware flaw that interferes with clock stretching, which my project needs. Prop does it like champ though!
The hardware support in Ultibo is surprisingly wide. You have graphics, usb - hub, storage, kbd, mouse, GPIO, framebuffer, don't know what else, and FAT32/NTFS/CDFS filesystems.
Thanks for posting info about Ultibo. It may be the perfect answer to a current need. We've got some older RPi boards that would make great framebuffers for a Propeller project that could benefit from better resolution than 512x384. With Ultibo we'd avoid a metric craptonne of Linux mummery.
I am drawn to the prop because there is no file system working in the background, and this is why I shy away from the RPi for embedded devices. I just don't know if the RPi file system will get smashed by randomly timed power-offs. I expect that the Ulitbo would minimize the file access to the application itself. ... is this correct? Is there a way to ensure safe shutdowns of a RPi ?
Linux, as well as every other modern OS, uses a journaled file system, so the filesystem can't really get smashed by unexpected power losses. I have a friend who never properly shuts down his Raspberry Pi - he just always pulls the plug. He knows perfectly well how to shut it down properly and why he should, but he trusts that the journal will do its job enough that he just pulls the plug every time. AFAIK he's never had any problems. As long as you don't have a cheap SD card that lies about data being flushed in order to look faster, you can't corrupt your filesystem by pulling the plug.
For anyone who doesn't know, a filesystem journal works by keeping a journal in a special place on the filesystem of all filesystem operations about to be performed before actually performing them. That way, if e.g. power is lost after space for a file is allocated but before the file is placed in a directory, the OS will read the journal at the next mount and see that there's an entry for an operation that was only half completed, and it will finish the operation using the recorded information about the location of the allocated space (which was written before the space was actually allocated). This only protects metadata (there is also data journaling, but no one uses it since it's really slow) - if power is lost after space for a file is allocated but before the data is actually written to disk, the filesystem will be consistent after the journal replay, but your file will be left filled with junk. There are ways around this, such as creating a new file with a temporary name and (atomically) rename(2)ing it to the target file instead of truncating the target file and then writing to it.
OTOH, if you don't actually need a filesystem, then there's no reason to use one, and you should probably use a Propeller.
The sectors structure seen by the system on SD card is pure virtual. This is managed by internal SD card controller which has its own data structures saved on the same flash memory chip.
If, due to power loss when writing, these internal structures are damaged, no journal can help, the filesystem or even entire SD card is lost. There is an 8 GB SD card on my desktop waiting to be put to the trash can. It is damaged by brownout on RPi3, I can't even format it with SD Formatter.
That's right. The Raspi forum is awash with posts about SD card/fs corruption and what to do about it.
Oddly enough, whilst I had terrible trouble with SD corruption with some early Pi, to the extent that nothing could reformat them, recently this has not happened and I have been getting very casual about yanking the power willy-nilly. No idea what changed. Different cards, newer Pi, OS upgrades. Or just random chance?
User Name,
You can avoid a "metric craptonne of Linux mummery" by using Raspbian Lite. Or other minimal distribution. I would not like to give up all the tools that a Linux install offers just for the sake of saving a bit of SD card space or saving a few seconds boot time. Certainly if you just want to use the frame buffer you don't need X installed.
The magic part about using the frame buffer is that you can use opengl and get GPU acceleration. It's awesome! (As the youngsters say now a days).
To be fair, I'll state that I have no problem with ~10 second boot times and a 2GB OS - if that's what it takes to provide all the great capability and flexibility that RPi & Linux offer. In fact it's a lovely thing.
But it's also a lovely thing to have a baremetal Pi for dedicated baremetal applications. In those situations, even a 3 second boot interval is undesirable and, gratefully, unnecessary. Also, beyond just the boot time and memory savings, there is a visceral delight to be derived from simplicity.
Oh yeah, I'm definitely into the visceral delight to be derived from simplicity thing.
I leave that to the Propeller, after that it gets complicated.
I had an idea for making a really simple system. Throw away pretty much everything from the Linux world except the kernel. Have the kernel run node.js, and nothing else much. Result, nice fast boot, very easy programming.
I thought this was a crazy idea and used to mention it as a kind of joke. Except somebody has gone and done it! https://node-os.com/
Ultibo is something like OBEX: get modules you want, write your own program on top of them, then compile and run.
Linux is something like you compile all OBEX object in one kernel and voila: you have them all, you can use what you want.
Two different ways; which one is better depends on what you want to do
I keep trying to make myself buy the RPi Zero. I own the original and never use it.
Today, I decided to go ahead and purchase. I put the Pi Zero in my cart...only $5. Then I put the HDMI cable in. The T-Cobbler. The serial cable. Etc. By the time I got around to shipping, I was going to pay $30 for this $5 computer. No thanks. Not today.
I will eventually. And, I get that many of those devices are one-time purchases. I really only want the Pi Zero for the GPIO stuff.
Anyway, it's pretty hard to ignore the fact this is a 1GHz PC with (nearly) instant boot time (now) and some GPIO in a package that is pretty small. How much larger is it than a standard DIP40 package?
It's just a matter of time before these are quad cores, cost $2, etc.
This is very interesting...I really only want the Pi Zero for the GPIO stuff...some GPIO in a package that is pretty small. How much larger is it than a standard DIP40 package?
Yeah, I think there's a niche that needs to be filled: a real Linux capable processor with GPIO access in a DIP40+ form factor.
If we could just get a piZero (or even better, a C.H.I.P.) on a teensy 3.x board... and while I'm dreaming, a P2 on the same board...
There is a new Ultibo version available now. It gives a support for VC4 GPU
The video seems way back in 2016....
Are there any up to date screen shot / video examples of what this can do, and what Size Binaries & start-times result ?
"The VC4 is made up of many subsystems that perform functions ranging from 2D and 3D graphics acceleration to hardware audio, video and image encoding and decoding as well as display and camera interfaces.
This unit provides common definitions, imports and support routines needed to enable all of the VC4 functionality for use in Ultibo.
In addition to the functionality provided by this unit there are a number of drivers that implement specific parts of the control and communication such as VCHIQ, VCSM and VCCMA."
Binary file size starts at about 2.5 MB as it contains most of RTL stuff. It doesn't grow up fast, my project (over 20000 lines of code) gives still about 2.5 MB binary
The start time is about 2 seconds. Maybe 3.
New videos are available on Ultibo facebook https://www.facebook.com/ultibo
Now I have an idea to make a machine using Rpi with P1 added. The RPi has its GPIO but it is not as flexible as in P1, so the plan is to connect the Propeller to RPi/Ultibo via UART and give it some input/output task.
I haven't tinkered with my Pi in a while. I loaded the Noobs on the SD card and I added a touchscreen but still boot up on the HDMI (touch screen just too small). It's pretty cool, browser works minecraft etc. Adafruit is a good Pi resource.
Ultibo looks like a huge and impressive piece of work.
However I don't get the point.
The brilliant thing about the Pi with Raspbian is that I can do my development on the Pi itself. In whatever language I choose. I can quickly try out ideas in Javascript or Python or C or whatever. On the Pi. I get all the facilities of a modern operating system. Including security for networked applications.
I can understand wanting a fast boot time. But hey, my Pi boots in 5 seconds or so. I don't use X Windows or a GUI on there.
I can understand wanting faster, smoother access to hardware than is possible with Linux. But that is not usually a problem.
I especially don't understand the idea of giving up Linux on the Pi when one is going to attach a Propeller to do the high speed, fiddly, I/O work. Surely if one is going to do that one is going to want to develop the Propeller code on the Pi itself. With OpenSpin or PropGCC, SimpleIDE etc?
Also. I just watched the Ultibo GPIO Events video. Good grief. 120 lines of horrible looking code to do what can be done in 20 lines of Javascript under node.js on the Pi or 20 lines of Spin or PASM on the Propeller. Probably less. Crazy!
The brilliant thing about the Pi with Raspbian is that I can do my development on the Pi itself. In whatever language I choose. I can quickly try out ideas in Javascript or Python or C or whatever. On the Pi. I get all the facilities of a modern operating system. Including security for networked applications.
I can understand wanting a fast boot time. But hey, my Pi boots in 5 seconds or so. I don't use X Windows or a GUI on there.
I can understand wanting faster, smoother access to hardware than is possible with Linux. But that is not usually a problem.
Again, if the performance of Linux is tolerable, sure, why change.
This is a niche solution, for when wanting faster, smoother access to hardware than is possible with Linux matters.
Addit: Another great use for Ultibo, would be 'proof of concept experiments', which could ultimately end up in the Linux support.
eg Pushing UART and SPI Speeds right up to what the silicon can support, not what some Linux coder thought was OK, a decade ago...
I especially don't understand the idea of giving up Linux on the Pi when one is going to attach a Propeller to do the high speed, fiddly, I/O work. Surely if one is going to do that one is going to want to develop the Propeller code on the Pi itself. With OpenSpin or PropGCC, SimpleIDE etc?
Also. I just watched the Ultibo GPIO Events video. Good grief. 120 lines of horrible looking code to do what can be done in 20 lines of Javascript under node.js on the Pi or 20 lines of Spin or PASM on the Propeller. Probably less. Crazy!
'Source Code size' is always a trade off, and you need to make allowances for what else needs to be loaded, and the final speed.
I would certainly hope node.js should give simpler code, but that comes at a cost of needing node.js, and that means version control issues....
For many niche users, 120 lines of code, that always works, and have ZERO version control / Compatibility issues in the future, is the better answer.
To me, the appeal of Ultibo is that it allows users to deploy Rasp-Pi hardware, by flipping it from Microprocessor + Booted Operating System, to a high speed, well resourced Microcontroller.
Add a P2, and it is an even better resourced system, that avoids the 512k ceiling P2 alone has.
This Bare-Metal work, could actually be quite significant for P2 sales, as I'd expect someone taking the trouble to do this, is rather like someone using some ASM over C - they need the extra performance & control, and likely intend to make some volume of units, with a long design life.
A P2 code generator for Free Pascal would have real appeal to such users... I wonder how hard PropBASIC is to modify to be Pascal source/P2 out ? - PropBASIC is already written in FreePascal....
I have Ultibo instaled on Raspbian on the same RPi which then runs compiled Ultibo code.
I have a shell script which reboots the Pi to Ultibo program and then I can return from the program to Raspbian
I also have a loader which can select and run one of many Ultibo programs residing on the same SD. It can also be used to boot Raspbian - https://github.com/pik33/Ultibo-microDOS
The Ultibo samples are overinflated because (1) there are a lot of comments in them (2) there is all stuff in it which is not necessary but then the code is 100% correct, checks for all errors, cleans after itself, etc These things can be written in less correct, but much shorter code, but then these examples are written for educational purpose and that's wy this code looks like it looks.
Ultibo allow direct hardware access and asm using, even self-modyfying asm code is doable there.
I am writing a GUI/windowing system for Ultibo https://github.com/pik33/ultibo_retro_gui - alpha stage, but it also contains a working audio player. The GUI starts in 2-3 seconds, like all othre Ultibo compiled programs. This player uses a noise shaping technique which I used before on Propeller 1. As the RPi allows up to 250 MHz on PWM input, I can use 960 kHz sample rate (~300 kHz on P1) - this allows me to get an excellent sound quality from RPi audio jack. To achieve this, asm and direct hardware access to DMA channel and PWM registers was used - try to do this with Linux
If C code can be compiled to .a static library, it can be used in Ultibo. I ported MAD mp3 decoder and XMP module player to my program so I think when it is needed I can also port a spin compiler. The text editor in on its way.
Comments
Then I have all the direct access to hardware as the bare metal guys like to have.
But I have all the support infrastructure of the kernel.
And pretty fast boot times.
This is true for the Propeller as well. Except people don't generally write to the EEPROM.
It is pretty easy to use a Pi in such a way as to never write to the SD card it boots from. Thus preventing it from being "smashed by randomly timed power-offs"
https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=161416
The hardware support in Ultibo is surprisingly wide. You have graphics, usb - hub, storage, kbd, mouse, GPIO, framebuffer, don't know what else, and FAT32/NTFS/CDFS filesystems.
No sound driver now, as I can see, but there is PWM supported, so as I have some experience in writing sound driver for the Propeller, it seems I can write one for Ultibo too.
Linux, as well as every other modern OS, uses a journaled file system, so the filesystem can't really get smashed by unexpected power losses. I have a friend who never properly shuts down his Raspberry Pi - he just always pulls the plug. He knows perfectly well how to shut it down properly and why he should, but he trusts that the journal will do its job enough that he just pulls the plug every time. AFAIK he's never had any problems. As long as you don't have a cheap SD card that lies about data being flushed in order to look faster, you can't corrupt your filesystem by pulling the plug.
For anyone who doesn't know, a filesystem journal works by keeping a journal in a special place on the filesystem of all filesystem operations about to be performed before actually performing them. That way, if e.g. power is lost after space for a file is allocated but before the file is placed in a directory, the OS will read the journal at the next mount and see that there's an entry for an operation that was only half completed, and it will finish the operation using the recorded information about the location of the allocated space (which was written before the space was actually allocated). This only protects metadata (there is also data journaling, but no one uses it since it's really slow) - if power is lost after space for a file is allocated but before the data is actually written to disk, the filesystem will be consistent after the journal replay, but your file will be left filled with junk. There are ways around this, such as creating a new file with a temporary name and (atomically) rename(2)ing it to the target file instead of truncating the target file and then writing to it.
OTOH, if you don't actually need a filesystem, then there's no reason to use one, and you should probably use a Propeller.
If, due to power loss when writing, these internal structures are damaged, no journal can help, the filesystem or even entire SD card is lost. There is an 8 GB SD card on my desktop waiting to be put to the trash can. It is damaged by brownout on RPi3, I can't even format it with SD Formatter.
That's right. The Raspi forum is awash with posts about SD card/fs corruption and what to do about it.
Oddly enough, whilst I had terrible trouble with SD corruption with some early Pi, to the extent that nothing could reformat them, recently this has not happened and I have been getting very casual about yanking the power willy-nilly. No idea what changed. Different cards, newer Pi, OS upgrades. Or just random chance?
User Name,
You can avoid a "metric craptonne of Linux mummery" by using Raspbian Lite. Or other minimal distribution. I would not like to give up all the tools that a Linux install offers just for the sake of saving a bit of SD card space or saving a few seconds boot time. Certainly if you just want to use the frame buffer you don't need X installed.
The magic part about using the frame buffer is that you can use opengl and get GPU acceleration. It's awesome! (As the youngsters say now a days).
To be fair, I'll state that I have no problem with ~10 second boot times and a 2GB OS - if that's what it takes to provide all the great capability and flexibility that RPi & Linux offer. In fact it's a lovely thing.
But it's also a lovely thing to have a baremetal Pi for dedicated baremetal applications. In those situations, even a 3 second boot interval is undesirable and, gratefully, unnecessary. Also, beyond just the boot time and memory savings, there is a visceral delight to be derived from simplicity.
I leave that to the Propeller, after that it gets complicated.
I had an idea for making a really simple system. Throw away pretty much everything from the Linux world except the kernel. Have the kernel run node.js, and nothing else much. Result, nice fast boot, very easy programming.
I thought this was a crazy idea and used to mention it as a kind of joke. Except somebody has gone and done it! https://node-os.com/
Linux is something like you compile all OBEX object in one kernel and voila: you have them all, you can use what you want.
Two different ways; which one is better depends on what you want to do
I keep trying to make myself buy the RPi Zero. I own the original and never use it.
Today, I decided to go ahead and purchase. I put the Pi Zero in my cart...only $5. Then I put the HDMI cable in. The T-Cobbler. The serial cable. Etc. By the time I got around to shipping, I was going to pay $30 for this $5 computer. No thanks. Not today.
I will eventually. And, I get that many of those devices are one-time purchases. I really only want the Pi Zero for the GPIO stuff.
Anyway, it's pretty hard to ignore the fact this is a 1GHz PC with (nearly) instant boot time (now) and some GPIO in a package that is pretty small. How much larger is it than a standard DIP40 package?
It's just a matter of time before these are quad cores, cost $2, etc.
Yeah, I think there's a niche that needs to be filled: a real Linux capable processor with GPIO access in a DIP40+ form factor.
If we could just get a piZero (or even better, a C.H.I.P.) on a teensy 3.x board... and while I'm dreaming, a P2 on the same board...
The video seems way back in 2016....
Are there any up to date screen shot / video examples of what this can do, and what Size Binaries & start-times result ?
I can find this ...
https://ultibo.org/wiki/Unit_VC4
"The VC4 is made up of many subsystems that perform functions ranging from 2D and 3D graphics acceleration to hardware audio, video and image encoding and decoding as well as display and camera interfaces.
This unit provides common definitions, imports and support routines needed to enable all of the VC4 functionality for use in Ultibo.
In addition to the functionality provided by this unit there are a number of drivers that implement specific parts of the control and communication such as VCHIQ, VCSM and VCCMA."
The start time is about 2 seconds. Maybe 3.
New videos are available on Ultibo facebook https://www.facebook.com/ultibo
Now I have an idea to make a machine using Rpi with P1 added. The RPi has its GPIO but it is not as flexible as in P1, so the plan is to connect the Propeller to RPi/Ultibo via UART and give it some input/output task.
However I don't get the point.
The brilliant thing about the Pi with Raspbian is that I can do my development on the Pi itself. In whatever language I choose. I can quickly try out ideas in Javascript or Python or C or whatever. On the Pi. I get all the facilities of a modern operating system. Including security for networked applications.
I can understand wanting a fast boot time. But hey, my Pi boots in 5 seconds or so. I don't use X Windows or a GUI on there.
I can understand wanting faster, smoother access to hardware than is possible with Linux. But that is not usually a problem.
I especially don't understand the idea of giving up Linux on the Pi when one is going to attach a Propeller to do the high speed, fiddly, I/O work. Surely if one is going to do that one is going to want to develop the Propeller code on the Pi itself. With OpenSpin or PropGCC, SimpleIDE etc?
Also. I just watched the Ultibo GPIO Events video. Good grief. 120 lines of horrible looking code to do what can be done in 20 lines of Javascript under node.js on the Pi or 20 lines of Spin or PASM on the Propeller. Probably less. Crazy!
That's because you miss the point, this is not intended to replace Linux+Pi use. It is for niche users, not mainstream Linux-box use.
Again, if the performance of Linux is tolerable, sure, why change.
This is a niche solution, for when wanting faster, smoother access to hardware than is possible with Linux matters.
Addit: Another great use for Ultibo, would be 'proof of concept experiments', which could ultimately end up in the Linux support.
eg Pushing UART and SPI Speeds right up to what the silicon can support, not what some Linux coder thought was OK, a decade ago...
'Source Code size' is always a trade off, and you need to make allowances for what else needs to be loaded, and the final speed.
I would certainly hope node.js should give simpler code, but that comes at a cost of needing node.js, and that means version control issues....
For many niche users, 120 lines of code, that always works, and have ZERO version control / Compatibility issues in the future, is the better answer.
To me, the appeal of Ultibo is that it allows users to deploy Rasp-Pi hardware, by flipping it from Microprocessor + Booted Operating System, to a high speed, well resourced Microcontroller.
Add a P2, and it is an even better resourced system, that avoids the 512k ceiling P2 alone has.
This Bare-Metal work, could actually be quite significant for P2 sales, as I'd expect someone taking the trouble to do this, is rather like someone using some ASM over C - they need the extra performance & control, and likely intend to make some volume of units, with a long design life.
A P2 code generator for Free Pascal would have real appeal to such users... I wonder how hard PropBASIC is to modify to be Pascal source/P2 out ? - PropBASIC is already written in FreePascal....
I have a shell script which reboots the Pi to Ultibo program and then I can return from the program to Raspbian
I also have a loader which can select and run one of many Ultibo programs residing on the same SD. It can also be used to boot Raspbian - https://github.com/pik33/Ultibo-microDOS
The Ultibo samples are overinflated because (1) there are a lot of comments in them (2) there is all stuff in it which is not necessary but then the code is 100% correct, checks for all errors, cleans after itself, etc These things can be written in less correct, but much shorter code, but then these examples are written for educational purpose and that's wy this code looks like it looks.
Ultibo allow direct hardware access and asm using, even self-modyfying asm code is doable there.
I am writing a GUI/windowing system for Ultibo https://github.com/pik33/ultibo_retro_gui - alpha stage, but it also contains a working audio player. The GUI starts in 2-3 seconds, like all othre Ultibo compiled programs. This player uses a noise shaping technique which I used before on Propeller 1. As the RPi allows up to 250 MHz on PWM input, I can use 960 kHz sample rate (~300 kHz on P1) - this allows me to get an excellent sound quality from RPi audio jack. To achieve this, asm and direct hardware access to DMA channel and PWM registers was used - try to do this with Linux
If C code can be compiled to .a static library, it can be used in Ultibo. I ported MAD mp3 decoder and XMP module player to my program so I think when it is needed I can also port a spin compiler. The text editor in on its way.