Rick's b.log - 2012/10/27
It is the 21st of November 2024 You are 52.15.37.74, pleased to meet you!

What I've been up to

What I have been doing, asides from watching animé and grumbling because I have yet another sodding cold... is some development work.

It is an extension of my BeagLEDs project, to control an LED (that is to say, optionally one or two LEDs) to flicker in sync with file accesses. One the one-LED version of the expension board, it'll be one LED flickering for all file activity. But on the two-LED version, it'll be a red LED for write activity and a green LED for read activity. The version visible in the video is the two-LED board.

The board itself is being made for CJE Micro's (sic - so please don't comment about the unexpected apostrophe!) who plan to offer a complete RaspberryPi "solution" to rival the likes of the ARMini (which is based around a Beagleboard and sells for a pound under six hundred).
CJE plans to put together a Pi package with case, power supply, keyboard, mouse, software, RISC OS... basically all you need to do is plug in all the bits and then push the power button.

The RaspberryPi is currently "on loan", until I decide to purchase it or send it back. It was sent to me because the little expansion board isn't compatible with the Beagle.
It was actually a little bit hairy doing the development; something wasn't quite right in the controller module so it was crashing a Pi with a Data Abort error, but I wasn't able to track this down using the emulator because of subtle differences between emulation and reality. The Pi arrived Friday morning. I had to do a quick hardware mod to get the expansion board working (as I am running the Pi from a USB lead). Then to load up the emulator on the eeePC and the boot the Pi and then swap a USB key around god knows how many times to test the module, developed on the emulator, on a live system. Phew!
The module was fixed pretty quickly once I could see and feel the problem on real hardware, but it still wasn't quite right. A bit of tweaking and shuffling stuff around and looking at minor optimisation, and then... there it was. I think I uploaded the module to Chris at about 1am, and he would have picked it up for the show in London today at around 6am. Damn, that's a tight deadline! ☺

The kit impressed the Pi People (by that I mean Liz and Eben), and the board got its own tweet on the RPi ... whatever Twitter calls a "thread".
[ https://twitter.com/Raspberry_Pi/status/262224653387440128

The board actually does a bunch of other things besides flash an LED. There is an RTC (something I'm missing from the Beagle due to lack of a titchy battery), there is a controller for the power supply and reset (ultimately intending to offer optional abilities such as a quick-press of the power button to instruct the operating system to do a 'tidy' power down, you know, close applications and dismount discs etc). It was more this functionality that was concentrated on at the show, rather than a flashing LED, but I'm kind of proud to have been a part if it.

Now, I need to go through the code and do a proper analysis and optimisation (with lots of testing, of course!). The current version is suitable for demonstration and, while it is something that could be released (i.e. it works), I would prefer for the actual release to be as good as it can be. A polishing off, if you will. I have a little bit of time in hand, for the other aspects of the expansion board are being developed as well, so it isn't as if they'll be waiting on me.

Sorry, I don't have any information on time frames if you are interested in this. I'd hope it would be in time for Christmas, as a RISC OS Pi system would be a nice idea for the Geek@♥ - so keep your eyes on CJE's website: http://cjemicros.co.uk/

The RaspberryPi

First up, boot speed. SIXTEEN SECONDS. Remember this when your mobile phone takes over a minute to get itself going on hardware twice as powerful.
Don't take my word for it, watch it yourself:

Secondly, it is kinda of cool that the Broadcom chip treats the composite video output as a scaled version of the main video display (that's why the fancy boot screen is unreadable, it is, I think, Full HD resolution scaled down). One of the problems with the Beagle's OMAP3 is that the TV output seems to be an actual different display which works in subtly different ways (hence colours are messed up in 16m colour modes). On the flip side, I guess this implies the OMAP could display different things on a monitor and on the TV-out; while the Pi perhaps cannot?
The resolution you can see in the picture is sucky for two reasons. Firstly composite video will look more rubbish than s-video because computer displays tend to be contrasty and we're shoving all the video information down one wire; remember composite is only a step up from using a UHF modulator! Additionally, the thing seems to be working in NTSC mode right now (so limited vertical resolution). This should be tweakable using the config.txt file on the DOS partition of the SD card.

In benchmarking on the RISC OS Open forums, the Beagle got its ass kicked by the Pi on FP ops. The Beagle (clocking 1GHz) is going to be faster at raw number crunching than the Pi (clocking around 700MHz, I think?); however the Pi's VFP unit is a lot faster than the OMAP3. To be fair, however, the OMAP3 comes with two FP units. The OMAP3 VFP is a precise, fully IEEE conformant floating point unit that uses double-precision internally, and takes something like 27 cycles to perform a multiply-accumulate. The flip side of the coin is that the OMAP3 also contains the NEON floating point unit, which is not IEEE compliant, only works with single-precision numbers, and can do a multiply-accumulate at a rate of around two per cycle. I think the OMAP3 can seriously outperform the Pi's Broadcom chip, but it needs software written specifically for it; generic FP software will use the standard VFP and it will seem less impressive.

In use, however, I can't detect any differences other than memory - the Pi offers RISC OS 128MiB after claiming 128MiB for the GPU (this ought to be likewise configurable, something to look into), while the Beagle xM offers 512MiB minus around 16MiB for the GPU. If I am running many many tasks or looking at huge webpages, this might become an issue. However, my RiscPC has only 32MiB installed and it never seemed like a tiny amount.
The system is startlingly responsive - both on the Beagle and the Pi. I could quite easily see myself listening to AnimeNFO via Shoutcast, writing a user guide in OvationPro for something I had written in the DDE; all with plenty of memory to spare.

I would like to be able to consider watching animé within RISC OS, but the platform does not have GPU access yet. The Tōkyō Sky Tree video (AVC1, 400×300) plays reasonably smoothly on the Beagle but is quite jerky on the Pi (as can be seen in the top video). This is because the RISC OS version of MPlayer is using software decode with no assistance from hardware. The snippet of Kara no Kyōkai that I tested (XviD, 720×480) was very jerky on the xM so I didn't bother trying it on the Pi. Maybe in time GPU support will come. Perhaps now that the Pi's interfacing code has been open sourced (even if it is little more than a bunch of veneers), something might develop from that?

I am impressed that the Pi powered itself from my eeePC's USB port. The Beagle was somwhat fussier about its power source, not to mention power hungry. The power input to the Pi is, interestingly, protected by a thing called a "polyfuse". If the power input is two high, a dodah will detect this and effectively crowbar the power input which will "blow" the polyfuse. This is a chemical-process thing which goes open circuit when blown, and will recover in time (although something as severe as a crowbar (that is, shorting the +ve to ground) may take several days for the polyfuse to be restored). Interesting concept, the polyfuse.

I believe that RISC OS itself is a good educational exercise. While the arrangement of the code is a bit messy (inherited from Acorn; it really needs a clear index as to what is where, especially around the kernel), the system is fundamentally fairly simple. Unlike the likes of Linux which is wrapped in layers of protocol and obscurity-through-complexity, RISC OS is more akin to "the BBC MOS with heaps of bells on top". For a budding ARM programmer, it may be possible to fairly quickly understand how it all fits together, how the parts interact, and perhaps to even specialise in a specific area such as the kernel or the Wimp. A brainiac could take on the entirety of RISC OS. The only complication is that much of the core is written in pure assembler with Acorn's own macro assembler; but once you gain experience in reading ARM code, you'll see how pleasurable it is (and you'll forever curse the abomination that is x86 code!). Once you understand RISC OS, either as a user or as a programmer, you can start to bash on hardware. Play with GPIO. Play with the stuff on-board. RISC OS has very loose restrictions, so you can fiddle hardware or fiddle bits of the OS itself. While this lack of protection makes it pretty easy to trash the OS, it also makes it equally easy to get on with doing the fun stuff poking hardware. You don't need to jump through hoops to write a driver that the kernel might decide to reject...

With the Beagle and the Pi side by side, I do not have a preference. My initial Beagle experience suffered a rather unfortunate setback, however I have a replacement now. I can see a strong point for the Pi in its ease of powering it, but on the other hand the Beagle's four USB ports means I can have a keyboard, a mouse, and a USB memory device attached at the same time. This isn't so with the Pi where I needed to swap out the keyboard for the USB key. So in a way both devices offer good features and quirks. And, for general everyday use, they are both sufficiently specified (a reasonable amount of memory and a reasonably fast processor) that RISC OS will feel suitably responsive. When running RISC OS and RISC OS applications, both seem to be good at what they offer; though due to the use of low-band analogue video signals, I have not used either as much as I would have liked. I hope (fingers crossed!) to pick up a smallish TV with HDMI input sometime in the new year. It won't be a perfect display device, but it'll be better than what I'm doing right now. Then, perhaps, I can experiment with the two a lot more. In the back of my head, there's some stuff I want to do to/with RISC OS.

All in all, it has been quite pleasurable writing this little module of mine. I've not really done so much for RISC OS in recent times (I'm writing this in Metapad on the eeePC, for instance), and I hadn't done much in the way of ARM coding either; so it was nice to get back into the swing of that.

Your comments:

No comments yet...