I know, I said I should give up buying new toys for my Raspberry Pi, and concentrate on doing interesting stuff with the bits I already have. But then I got a notification from Farnell that a stock of Pi Face boards was available. Like the GertBoard, this one has been on back-order for ages. Since I was ordering a Pi Face, and as I am supposed to be doing some sort of presentation on Tuesday to IPRUG about all things Raspberry Pi, I also ordered a few other bits.

As you may recall, if you have read a few of these blogs, ELIUS is the name I am using for the stack-based "problem-oriented language" (POL) which I plan to include as a system language for the bare-metal operating system I am building for the Raspberry Pi.

Charles Moore's POL concept, and languages based on it, tend to have very simple parsers, sometimes as simple as just separating "words" with spaces. One down side of this is that some of the words need to be special, in that they affect or override the parsing process itself. To recognize and activate such words, they must be delimited with spaces, so they can be recognized by the basic parser. This can lead to some slightly odd constructs, for example FORTH's ." hello" which prints, not  hello but just hello without the leading space. the word ." is recognized by the simple parser and executed. It's result is to use a different parsing approach until a " character is found, at which point it switches back to the regular parser.

A few days ago I complained a bit about the profusion and confusion around the Linux drivers for the PiBorg LEDBorg multi-colour LED. With a bit of renewed energy, I thought I'd have a go at improving the situation by including a test for board revisionin the driver and ensuring that the correct GPIO pins are used for the different board revisions.

I have my LEDBorg currently plugged in to my Rev 1 Raspberry Pi, so it seemed reasonable to start by downloading the Rev 2 driver with the aim of making it also work with the Rev 1 board. The source code for the driver is helpfully provided by PiBorg for download as a zip file, and the installation web site contains some instructions for how to build the driver from source.

Forth, and similar languages inspired by Charles Moore's approach to software have evolved in a particular direction. Like Donna Noble in The Doctor's Daughter, FORTH is "good with numbers", but traditionally very limited in its string processing abilities.

In Programming A Problem-Oriented-Language (POL), Moore writes:

What can you do with a character string? I've only found 2 uses. They are very similar, but part of the frustration of implementing them is to take advantage of the similarity. You can type a string, or you can move it to a character field.

After my grumpiness yesterday, I thought I'd better strike out in a different direction while I consider my options with the various sub-projects I have on the go at the moment. I have mentioned before that I am a member of local Ruby user group 'IPRUG'. This is on my mind at the moment as I have promised to give a talk about Raspberry Pi, and I need to prepare some things both to talk about and to demonstrate.

In some ways I'm surprised this hasn't happened sooner. I have been trying various things with my Raspberry Pi and with my OS and language designs on and off all day, but not made any reportable progress on any of it. The code for the FORTH-like "problem oriented language" is still flailing as I change my mind about what it should be, and so has nothing usable yet. My jiffy-bag full of expansion hardware just glowers at me, and my attempts at configuring a Linux Pi to sit on a disconnected local network are becoming very hard to test when the only way I have of logging in is by connecting it to my router. I'm also really feeling the limitation of the GPIO header only really allowing one third-party device to be plugged in at one time. As a Raspberry Pi developer community we really need to find a way to overcome this.

I have been reading about the early days of FORTH recently, and learned a lot about the ideas and philosophy behind the language and the system. In the past, when I had tried to create my own FORTH-style languages I think I was missing something important. I had been confusing the "language" of available FORTH implementations with the core concepts of FORTH itself.

Anyone who knows even a little about FORTH has seen word definitions like

Last month, when I found my Raspberry Pi again and started this blog, I had a look around the web to see what was happening in the world of Raspberry Pi. One of the things I kept bumping into was the "Gertboard" - an almost mythical input/output expansion board, named after Gert van Loo, its designer. Apparently a small number had been made available in kit form, then withdrawn while the community held its breath and waited.

The Raspberry Pi is a great little board, and it still amazes me the huge range of things you can do with it. However, it's not without its limitations. One of these limitations is that it has no "real-time" clock. Sure, it has internal counters and the like, and when running under Linux it will keep pretty good track of time, and update its internal clock using NTP (Network Time Protocol) whenever it is connected to the internet. However, if it's not connected to the internet it has no idea what the time is.

Yesterday, in my review of the LEDBorg, I wrote about how it can be inconvenient to connect two devices to the Raspberry Pi GPIO header at the same time, especially when one of them has a header which covers all the pins.

I mostly write and run my own bare-metal software on the Raspberry Pi, and as I have not got anywhere near making the major I/O (USB, ethernet, etc.) work, my only option for communicating with the Pi seems to be via the on-board mini-UART serial interface. I have that talking to a terminal emulator, and it makes it much easier to get diagnostic information so I can see what's going on.