A while ago I ordered and received a LEDBorg bright, three-colour LED for my Raspberry Pi. I wanted to have a go at writing software to drive the GPIO pins, but didn't want to go to the trouble of building my own hardware. Not only would that be fiddly, but if (when) something did not work, I would not be sure whether it was my hardware assembly or my programming which was at fault.
Since getting all excited about flashing Morse code on a on a LEDBorg, I have been wondering about how to control it to get the best out of its three LED colours.The way to do this is to individually turn up and down the brightness of the three LEDs, thus changing the proportions of the colours, and in turn changing the overall perceived colour. There is plenty of code to do this, but so far all the examples I have found, such as the ones from PiBorg, all seem to assume that the code is running under Linux. This is all well and good, but not so much use for bare-metal programming. So I have set out on a mini-adventure to discover how to do effective brightness control.
I have been spending some late nights bashing away at my Raspberry Pi these last few weeks, so I thought I'd take a break from the deep technical blog articles today. Instead I spent a few hours doing some housekeeping on this web site. I have added a few notes to some old articles, pointing at later ones on similar topics, fixed a few typos and so on.
I have also updated the Useful Resources page with a load more links. If you know of any others, of if you would like a link to your project, blog, or book about anything related to Raspberry Pi, bare metal OS or Language development, please get in touch.
A few days ago I took a few small steps toward creating a project structure and build process which would allow me to build and test the majority of my bare-metal Raspberry Pi code on my development (Windows or Linux) machine, with only the very hardware-specific bits needing to be built and tested on the Raspberry Pi itself.
After the few small steps, I kind of ran aground, unsure about what to do next, and unwilling to break a working process. This evening I obviously had a bit more enthusiasm, and set to work on re-organising the code and hammering at folders and makefiles. Eventually I have now got a build working really sweetly.
Several Posts ago, during a discussion of why I am interested in bare-metal operating systems development, I linked to Charles Moore's biography on his ColorForth.com web site. At the time I was interested in looking at a variety of stack-based languages for inspiration, including ColorForth. Sure enough, ColorForth had some interesting ideas, but what stopped me short was when I followed the link to his draft book Programming a Problem-Oriented Language.
I have already proved to myself that I can set up and control the OK LED on the Raspberry PI board from a bare-metal C program, but I didn't really feel that I entirely understood what was going on. The cop-and-paste code to set up and switch the GPIO line used for the OK LED was very specific - I would prefer to develop my own functions which will let me easily set and switch any of the GPIO pins.
So far, despite working on a variety of bare-metal software features for the Raspberry Pi, I have not managed to achieve my aim of using the principles of TDD (Test-Driven Development). In my "day job" I make a lot of use of TDD techniques, and I am convinced that this approach both greatly improves the quality of the code and de-stresses the development process. Before I go much further along the path of building an experimental operating system and its system language, I want to get my development environment set up for use with TDD.
Following my post a few days ago about high and low level languages, I received an interesting email from Paul Hammant with some astute comments. After thinking about this for a bit I'll have another go.
Note that this is a follow-up, and probably makes a bit more sense if you read the original post first.
I'll admit I got caught up in the idea of slotting languages into arbitrary levels, and did not make my basic point as clear as I might. I also omitted mention of the once-popular 1, 2, 3 and 4GL method of classification. I also didn't mention any of the very interesting work being done in the area of Behaviour-Driven Design (BDD).
As I mentioned yesterday, I now have some new Raspberry Pi boards to play with, and also some extra hardware. I had planned to spend this evening writing some GPIO code to control the colours and brightness of the LEDborg. I even got as far as plugging it in to one of the boards. Then I read the instructions. It seems that the piborg team chose to drive the LED using a GPIO pin which has changed its function between board revisions. This has resulted in a confusing mess of drivers and code.
Aha! the new toys I ordered have arrived. Two new Raspberry Pi boards, two ModMyPi gamble cases, and some miscellaneous hardware.
The two new Raspberry Pis are both 512MB "revision 2" boards with mounting holes, and I have already fixed them snugly in their new cases. The cases which arrived were black top/red bottom, and white top/blue bottom. Both look neat, especially the blue and white one, as these are the colours of our local football team.