Monthly Archives: December 2010

FreeRTOS on the Renesas RDK

via Brewbot Mk2

In my last post about bringing up and building for the RDK using a Linux host, I mentioned that I easily got FreeRTOS building under Linux.

And it worked great first time. I checked the  doco and found out where the IP config was stored and was able to connect to web server over ethernet and see all the demo tasks running.

The FreeRTOS demo code talks about LED5 blinking at a 5 second interval when all the demo/tests are running fine, and a 200ms rate when one of them fails.

https://github.com/Zizzle/FreeRTOS-RDK-demo/blob/master/Demo/RX600_RX62N-RDK_GNURX/RTOSDemo/main-full.c#L412

Now the LEDs on the RDK have a silk-screened number next to them. And LED5 as marked on the board was clearly blinking faster than 5 seconds.

So I was worried that one of the tests/demos was failing. Maybe the port wasn't working 100%?

I could see that it was creating a string with a message about the failing task:

https://github.com/Zizzle/FreeRTOS-RDK-demo/blob/master/Demo/RX600_RX62N-RDK_GNURX/RTOSDemo/main-full.c#L341

Unfortunately the FreeRTOS demo doesn't drive the LCD on the RDK, so I couldn't easily display the message.


So I quickly included the code I wrote to drive the LCD and had it output the error messages generated in the demo test code.

The LCD was showing no error. What is going wrong? I added some code to have it display when all the tests were OK. Running that showed that everything was happy.

So what was going on with the LED?

It turns out some arbitrary mapping between the "LED5" describe in the FreeRTOS demo code and the LEDs on the board.


If you check the code ParTest.c#L102 you can see that LED5 is mapped to LED9!

That explains it. Why they did that I don't know. It certainly is confusing.

But it looks like the port is running happily.

As part of my fiddling, as well as adding an LCD driver, I also removed the Windows toolchain blobs, and code for all the other platform ports, just to make my greps more relevant.

You can find this code here:

https://github.com/Zizzle/FreeRTOS-RDK-demo

It would be good to get the LCD driver included in the FreeRTOS upstream.

Next steps, more work on the hardware, and get some FreeRTOS tasks talking to the DS18S20 temperature sensor.

Renesas RDK bring up

via Brewbot Mk2

I'm a free software junky. Have been since the late 1990's. I run Linux on all my machines. I wouldn't have it any other way.

Which can pose a problem in the embedded space. Nearly all tools are highly Windows centric.

With the RDK, things are even worse, in that they are pushing a proprietary RTOS, Toolchain, and Debug environment. I think as also is typical, most are restricted in some way. A drug dealer approach to getting you to cough up some cash. Just a taste.

As as Engineer and tinkerer, I like to understand how things work, to have a chance to be able to fix bugs.

"If you can't change it, you don't own it." - DJ Delorie

What I find incredible that so many hackers types, who like to dismantle, re-purpose and build things, are happy to be closed off to this whole world by using highly restricted OSes and tools. It seems like a contradiction.

Anyway, there is no coincidence with the above quote, luckily for the RDK, free software hero DJ Delorie has done a lot of the heavy lifting for us Linux users.

I started here: http://www.renesasrulz.com/thread/3137

To shortcut bring up a little, I went and got the precompiled GCC binaries from kpitgnutools

The blinky example worked first go, yay!

For my application, I was initially planning on skipping using an OS entirely (due to the proprietary nature of the one that comes with the kit) and just coding to the hardware directly.

First step would be to get an on board timer running and generating interrupts... the heart beat of the application.

Plus blinking LEDs are pretty boring when you have an LCD sitting there.

So I set about modifying the blinky example from DJ to be timer and interrupt driven and also use the LCD.

The result is here: https://github.com/Zizzle/blinky2

Since getting that running I discovered that FreeRTOS looks good and is easy to build under Linux and run thanks again DJ.

http://www.renesasrulz.com/thread/3109

http://interactive.freertos.org/entries/308741-makefile-for-linux-hosted-demo-build-on-144-pin-rx-62n-board

So I may end up using FreeRTOS for my brewbot. Subject of another post I guess.

Brewbot Mk2 beginings

via Brewbot Mk2

I recently entered this design contest with the intention of creating a new brewbot.

http://www.renesasrulz.com/community/rx-contest

Kelly has lots of recipe ideas she wants to try with some off center ingredients, so wants to start doing small batches.

At this point I'm thinking MK2 would be somewhat of a departure from the original brewbot.

* small batch machine: ~4-5 litre batch size. Maybe keep the ability to upgrade to 5 gallon batches.
* single vessel BIAB design (rigid stainless mesh for the "bag")
* automate cleaning where possible, otherwise optimize/minimize manual cleaning
* possible pump-less design, or cheap pump only used for CIP
* possible integrated no-chill vessel / fermenter (mainly for CIP circulation access)
* Small cheap Chinese servos for hop dropper
* No automated valves
* integrated mash stirrer instead of recirculation
* 240V "cloths drier" 30A outlet as the power source

Some elements would be similar:
* No chiller, just run into a sealed vessel for cooling (we already do this)
* Conductivity based water level probes
* Car windscreen wiper motors for the electro-mechanical parts
* Electric water heater element for the heat source

Budget of under $500.

This blog is to be the build log for the project.

Housing and heat

via Brewbot Mk2

First purchases were a cheap aluminium brew pot, some timber and hot water element.

I wanted a stainless steel pot, but could not find one I liked of the right size locally. I will order one online, but to get me started I will use the aluminium pot.

Here I'm using a Home Depot pre made 30A drier lead on a hot water system 240V 3500W element. I got a small galvanized electrical connection box, and did a cut-n-shut to make it smaller. I miss my MIG welder, I'm justing using a small MAPP gas torch to braze the two parts together here.

I tapped some M3 threads in the outer part of the element to mount the gal box.



Here you can see the inside of the pot. The long loop is the heating element. I have a 1" stainless steel socket holding in it place. I will cut it in half (the line marked) and silver solder this into my stainless steel brew pot when I get it. The other half I may eventually solder into our 8-gallon brew pot for mounting an element there.

Above that you can see the stainless steel thermowell. I also plan to silver solder a socket in for that.


The main housing is made out of 3/4" hardwood ply. Here you can see some ball bearing draw slides mounted on the back of it. On this will run another piece of ply for the crane part of the bag lifting piece. These are rated to 75lbs.

You will notice I didn't mount them both on the same side. This is so that neither of them has to take all the weight at full extension.


The crane slide works well enough.

I will be using a wiper motor and some 3/8" threaded rod as a lead screw to move it.

You can just make out the micro switches at the limits of the slide.



The power electrics are nearly done. Pretty straight forward. Two sturdy gal power boxes brazed together to form one bigger box.

One 40A SSR in line with the element mounted inside the lid. The 3500W element should only be drawing 15A, so hopefully the SSR can handle it. The only issue is power dissipation. SSRs can drop 1.6V, which will mean 24W of heat to dissipate. I have chunky PC CPU heatsink/fan combo to go on there which it why I mounted it inside the lid. And probably won't be running the element at 100% duty cycle.

The main black box is just a 240V 30A socket. The lead plugged into it a 30A pre-made one that goes straight to the pot.

You can just make out a black bot inside the gal box. That is a $10 12V 6A ebay LCD power supply. This will be used for running the motors and the main CPU.


Starting to put together the electronics.
The breadboard is soldered to a header that plugs directly into the board. Unfortunately that does not give enough I/O pins, so I have the flying lead down to other header on the bottom of the board.

Next will be to populate some driver transistors and connectors.

There is a DS1820 dangling that I have used to bring up the code for talking to that.

I'm hoping to get a free wifi adapter as part of the design contest. It plugs into the header just left of the breadboard which is why I didn't touch that connector.


I'm sure many of you can see where I'm going with the design. Essentially Brew-In-A-Bag. A simple crane for automated lift-and-move of a pot with main holes in it (the "bag"). A mash stirrer will run on top of this "bag".

I initially started with a design of the pot moving from out under the "bag", but I think the off the shelf ball bearing draw slides makes viable the crane part moving.

The real challenge for me is that I'm away from my usual tools and home workshop. I'm slowly building up a new set of tools here, but am particularly missing my MIG welder, grinder and drill press.

I'm still not sure where to mount the CPU board yet as the LCD needs to visible, and yet out of the way of steam/water. The hop dropper could also be tricky to place. It needs to not interfere with the crane and bag.

Next I really need to get a hold of some wiper motors to do the lifting and moving.

Brewbot Mk2 beginings

via Brewbot Mk2

I recently entered this design contest with the intention of creating a new brewbot.

http://www.renesasrulz.com/community/rx-contest

Kelly has lots of recipe ideas she wants to try with some off center ingredients, so wants to start doing small batches.

At this point I'm thinking MK2 would be somewhat of a departure from the original brewbot.

* small batch machine: ~4-5 litre batch size. Maybe keep the ability to upgrade to 5 gallon batches.
* single vessel BIAB design (rigid stainless mesh for the "bag")
* automate cleaning where possible, otherwise optimize/minimize manual cleaning
* possible pump-less design, or cheap pump only used for CIP
* possible integrated no-chill vessel / fermenter (mainly for CIP circulation access)
* Small cheap Chinese servos for hop dropper
* No automated valves
* integrated mash stirrer instead of recirculation
* 240V "cloths drier" 30A outlet as the power source

Some elements would be similar:
* No chiller, just run into a sealed vessel for cooling (we already do this)
* Conductivity based water level probes
* Car windscreen wiper motors for the electro-mechanical parts
* Electric water heater element for the heat source

Budget of under $500.

This blog is to be the build log for the project.

Learning (BBC, Tinker London)

via OSHUG

The ability to study and improve the design of open source hardware is a core principle and it follows therefore that as a methodology it is well suited to learning environments. Community, collaboration and ecosystem are also central open source hardware, however, ambitious projects that embraced these principles existed long before its advent.

At the seventh OSHUG meeting we'll be hearing from ex-BBC employees that were intimately involved in the BBC's Computer Literacy Project, the creation of the BBC Micro and the Domesday project. First hand experiences from that heady time during the 1980s when the UK was at the forefront of microcomputer development will frame the opportunity that faces us once again. Whereas lessons learnt will help us to build on these experiences and to strive to ensure that pitfalls are avoided.

We will also be hearing from Tinker London about experiences of teaching open source technologies and how this differs from more traditional approaches to learning.

Kindly hosted by BBC Learning Development.

The BBC Computer Literacy Project

Why did the BBC embark on one of its most ambitious projects - the Computer Literacy Project - in 1982? What was the scene like then and how successful was the enterprise. What technical issues were involved? 85% of schools used BBC Micros and millions were sold, along with best selling books and software, including 'telesoftware'. What is the legacy - if at all? How did the work then benefit BBC technology now?

After being Head of Science at Beaumont and Stonyhurst Colleges, David Allen joined the BBC in 1969 as an Assistant producer/director. He became producer and then executive producer of a range of programmes. As a programme maker, he was series editor of the BBC Computer Literacy Project 1982-1986 and intimately connected with the creation of the BBC Microcomputer. He received seven awards (including the New York Film Festival, Sony Innovation awards, RTS Judges Award and Times Technology Programme of the Year two years running. With BBC R&D helped evolve radio cameras and virtual studio production. When David retired he was executive producer in Production Modernisation. He is currently making documentaries for BBC R&D and for Historic Royal Palaces.

The BBC Domesday Project - If I could Do it All Over Again

The BBC Domesday Project was an interactive media production made as part of celebrations of the 900th anniversary of William the Conqueror's Domesday Book of 1086. It was a technical triumph, combining digital data with analogue pictures, video and sound with an innovative user interface running on an 8-bit BBC Microcomputer controlling a state-of-the-art laser videodisc. 25 years later it has still not been possible to republish something that over a million people helped to make, and despite sometime heroic reclamation and preservation, it is still virtually impossible to access the original software. Andy Finney was one of the project founders and he produced some of the material in the project. He will explain the origins and technical background to the Domesday discs in the context of both it 1980s origins and how much of what it pioneered has since become commonplace.

Andy Finney started in radio and moved into television, video and interactive video within the BBC over a 21 year career. Since leaving he has concentrated on web-based technologies including databases, these days with a lean towards digital television reception. He worked with the then Public Record Office and the BBC to help preserve the audio-visual content of the Domesday discs and still keeps a fatherly eye out for re-publication.

Standing on the Shoulders of Hackers

Learning is an intrinsic aspect of open source projects. Practices such as documenting and sharing work, following one’s own interests, and ad hoc organizing open up - and complicate - opportunities for learning and teaching, especially in informal and semi-formal contexts. Drawing on his experiences teaching Arduino workshops, Daniel will talk about how both the hardware and open-source aspects of OSH affect processes and tools for learning and teaching.

Daniel Soltis is an interaction designer specializing in physical interfaces, play and games, and the rough edges where engineering, design, art, and learning meet. He has been working with Tinker London since 2008, studied physical computing and game design at NYU’s Interactive Telecommunications Program, and in prior life had various adventures in math and physics, teaching, editing, and medical writing. He has taught Arduino, Processing, and rapid prototyping for events and institutions including Thinking Digital, CIID, the V&A, and dConstruct, and has spoken about games and hardware at events including SXSW, the SIGGRAPH Video Game Symposium, Playful, and Open Hardware Camp.

Note: Please aim to arrive for 18:00 - 18:15 as the event will start at 18:30 prompt. Note also that the venue is the Media Centre at White City and not the main White City building itself! On arrival please report to reception.

Learning (BBC, Tinker London)

via OSHUG

The ability to study and improve the design of open source hardware is a core principle and it follows therefore that as a methodology it is well suited to learning environments. Community, collaboration and ecosystem are also central open source hardware, however, ambitious projects that embraced these principles existed long before its advent.

At the seventh OSHUG meeting we'll be hearing from ex-BBC employees that were intimately involved in the BBC's Computer Literacy Project, the creation of the BBC Micro and the Domesday project. First hand experiences from that heady time during the 1980s when the UK was at the forefront of microcomputer development will frame the opportunity that faces us once again. Whereas lessons learnt will help us to build on these experiences and to strive to ensure that pitfalls are avoided.

We will also be hearing from Tinker London about experiences of teaching open source technologies and how this differs from more traditional approaches to learning.

Kindly hosted by BBC Learning Development.

The BBC Computer Literacy Project

Why did the BBC embark on one of its most ambitious projects - the Computer Literacy Project - in 1982? What was the scene like then and how successful was the enterprise. What technical issues were involved? 85% of schools used BBC Micros and millions were sold, along with best selling books and software, including 'telesoftware'. What is the legacy - if at all? How did the work then benefit BBC technology now?

After being Head of Science at Beaumont and Stonyhurst Colleges, David Allen joined the BBC in 1969 as an Assistant producer/director. He became producer and then executive producer of a range of programmes. As a programme maker, he was series editor of the BBC Computer Literacy Project 1982-1986 and intimately connected with the creation of the BBC Microcomputer. He received seven awards (including the New York Film Festival, Sony Innovation awards, RTS Judges Award and Times Technology Programme of the Year two years running. With BBC R&D helped evolve radio cameras and virtual studio production. When David retired he was executive producer in Production Modernisation. He is currently making documentaries for BBC R&D and for Historic Royal Palaces.

The BBC Domesday Project - If I could Do it All Over Again

The BBC Domesday Project was an interactive media production made as part of celebrations of the 900th anniversary of William the Conqueror's Domesday Book of 1086. It was a technical triumph, combining digital data with analogue pictures, video and sound with an innovative user interface running on an 8-bit BBC Microcomputer controlling a state-of-the-art laser videodisc. 25 years later it has still not been possible to republish something that over a million people helped to make, and despite sometime heroic reclamation and preservation, it is still virtually impossible to access the original software. Andy Finney was one of the project founders and he produced some of the material in the project. He will explain the origins and technical background to the Domesday discs in the context of both it 1980s origins and how much of what it pioneered has since become commonplace.

Andy Finney started in radio and moved into television, video and interactive video within the BBC over a 21 year career. Since leaving he has concentrated on web-based technologies including databases, these days with a lean towards digital television reception. He worked with the then Public Record Office and the BBC to help preserve the audio-visual content of the Domesday discs and still keeps a fatherly eye out for re-publication.

Standing on the Shoulders of Hackers

Learning is an intrinsic aspect of open source projects. Practices such as documenting and sharing work, following one’s own interests, and ad hoc organizing open up - and complicate - opportunities for learning and teaching, especially in informal and semi-formal contexts. Drawing on his experiences teaching Arduino workshops, Daniel will talk about how both the hardware and open-source aspects of OSH affect processes and tools for learning and teaching.

Daniel Soltis is an interaction designer specializing in physical interfaces, play and games, and the rough edges where engineering, design, art, and learning meet. He has been working with Tinker London since 2008, studied physical computing and game design at NYU’s Interactive Telecommunications Program, and in prior life had various adventures in math and physics, teaching, editing, and medical writing. He has taught Arduino, Processing, and rapid prototyping for events and institutions including Thinking Digital, CIID, the V&A, and dConstruct, and has spoken about games and hardware at events including SXSW, the SIGGRAPH Video Game Symposium, Playful, and Open Hardware Camp.

Note: Please aim to arrive for 18:00 - 18:15 as the event will start at 18:30 prompt. Note also that the venue is the Media Centre at White City and not the main White City building itself! On arrival please report to reception.