RTEMS SMP Exploration #1

Many of you know that I have been working on an SMP design for RTEMS for a couple of years now as a background activity. This has been a slow project and I have been wanting to work on it more but it has been almost entirely volunteer activity on my part. But recently, the activity level has picked up. Gedare Bloom's GSOC proposal Modular SuperCore Scheduler Manager will make a significant dent in the work required to support SMP. Currently, there is no discrete Scheduler component in the RTEMS SuperCore and a big part of supporting SMP is to have a single processor and an SMP-aware scheduler. To properly support this, there has to be a discrete Scheduler component in the SuperCore and a mechanism to select alternate schedulers. Gedare's project is to refactor the existing code base and provide a SuperCore Scheduler Handler along with the configuration required. Gedare has previously implemented an Earliest Deadline First (EDF) Scheduler for RTEMS and we are planning for this to be available as one of the alternative schedulers. Tiny/RTEMS may even benefit because it may make sense to have a light-weight scheduler algorithm for lower end target processors.

With Gedare focusing on refactoring the Scheduler, I have felt free to focus on the process of initializing a multicore processor, interprocessor interrupts, spinlocks, and transferring control to the first thread on a secondary core. I have succeeded in demonstrating these on pc386 with up to 32 cores and on SPARC/LEON3 with four cores. This work has let me work through the definition of a per CPU OS structure as well as the BSP/RTEMS SMP Interface. If you are interested in experimenting with this on another architecture, let me know.

I am looking forward to working this summer with Gedare and seeing how close we get to SMP RTEMS support before the 2010 Summer of Code is over.

Google Summer of Code 2010

It has been a while since I posted but life and RTEMS have been busy. The past few weeks have been a blur as GSoC 2010 approached. The UT Chattanooga IEEE-CS student chapter visited NASA's Marshall Space Flight Center here in Huntsville and OAR hosted them for lunch. Some Asterisk developers joined us and we presented GSoC, RTEMS and Asterisk to them. Earlier in the year, I had put together a cool double-sided flyer with RTEMS GSOC on one side and the general GSoC information on the other. Both sides had tear-offs which aligned close enough where you get the general and RTEMS specific GSoC URLs. For this visit, I put together a new flyer with the list of all participating organizations. I think it is important to let students know about all the cool organizations that participate.

The past couple of weeks have been hectic. I had work deadlines looming, one of my sons had H1N1, and RTEMS had more students than ever asking questions and submitting proposals for review. I had to update the VirtualBox image of Fedora 12 with RTEMS tools for the i386 and sparc pre-installed and make the torrent available. We had more students complete the hello world requirement and have proposals to review before the web app opened than we did all of last year!! We ask them to put their proposal into Google Docs and let mentors insert comments into that. We have so many students, I created a Google Docs Spreadsheet to track when each mentor had read the proposal and whether the student had submitted the official application. I spent this weekend ensuring I had read all of the proposals in hand.

Overall, I am thrilled with this year's crop of proposals and the number of cross-project proposals. We have students interested in Go on RTEMS, Parrot on RTEMS, and RTEMS support for the MilkyMist board. On top of that, we have students interested in adding a pluggable scheduler capability and EDF scheduler, coverage improvements, adding POSIX asynchronous and list IO, and much more. And two students from last year are back in a mentoring capacity. With a week to go before the student application deadline, I expect we will see more proposals and hope we are able to do a good job reviewing those. I know we will try to do so and be fair to all students making proposals. I am excited and hope we get enough slots to take on the students with quality, well thought out projects.

Ramblings From Radiology

As I have mentioned to many of you, I had an excess of protein in my urine and have had to have a number of medical tests. Today I am at Huntsville Hospital and just got back from a kidney biopsy. I have to get another scan in a few hours to ensure I am not bleeding internally. What does this have to do with RTEMS you ask? Well, nothing directly. But being bored and surrounded by medical devices made me remember some of the RTEMS based medical devices people have told me about over the years.

The first device I heard of was an HP (now Philips) Criticare heart monitor. Philips/HP Criticare equipment is common in our area but I don't know if I have actually ever seen one of these.

I assisted in the development of a BSP for what was going to be a blood analyser for Roche. I recall it be m683xx-based but do not know exactly it tested for.

The AMV Technic I is a certified syringe pump for sale in a number of European countries. It uses RTEMS on an ARM CPU and we have information in the RTEMS Wiki. It uses Microwindows to provide the graphical user interface.

There are also RTEMS based intercom systems which are used by patients to summon or talk to a floor nurse. This product is ARM based and is on its second generation of hardware using RTEMS. Seeing a user build multiple product generations on RTEMS is personally very satisfying. It makes me know they are pleased with RTEMS.

There may well be other medical devices out there, but I don't know about them. Unfortunately, many people do not tell us about their application. I don't know how to change this but will continue to beg for marketing literature from RTEMS based products. Please save me from begging! Just send me the information.

NASA Solar Dynamic Observatory Launched

The NASA Solar Dynamic Observatory (SDO) was successfully launched this morning. The SDO satellite includes 5 Radiation Hardened Coldfire CPUs running RTEMS. The Coldfire/RTEMS computers run many of the I/O functions and one of the instruments. A very nice graphic of the mission is here. The following is the description of the project from the SDO Project Site:

SDO: The Solar Dynamics Observatory is the first mission to be launched for NASA's Living With a Star (LWS) Program, a program designed to understand the causes of solar variability and its impacts on Earth. SDO is designed to help us understand the Sun's influence on Earth and Near-Earth space by studying the solar atmosphere on small scales of space and time and in many wavelengths simultaneously.

SDO's goal is to understand, driving towards a predictive capability, the solar variations that influence life on Earth and humanity's technological systems by determining

• how the Sun's magnetic field is generated and structured
• how this stored magnetic energy is converted and released into the heliosphere and geospace in the form of solar wind, energetic particles, and variations in the solar irradiance.

Congratulations to the folks at NASA Goddard on a successful launch and good luck in meeting their science goals. I look forward to the new insights we will gain into the Sun.

RTEMS Graphics Toolkit

I haven't posted since before the holidays but that doesn't mean that nothing has been going on in the land of RTEMS. I have been trying to work with Roxana Leontie to get her work merged into the Microwindows/Nano-X repository. Roxana was an RTEMS Summer of Code student. The RTEMS Project took the Google donation from the Google Summer of Code and money from OAR Corporation to fund Roxana as the inaugural RTEMS Summer of Code Student. Roxana worked to update and clean up the ancient port of Nano-X to RTEMS. Roxana did all of her work targeting the RTEMS pc386 BSP. The screenshot in the upper right is the Microwindows minesweeper demo program.

As Roxana wrapped up her work, she cooperated with a Google Summer of Student (Xi Yang) who had developed a Gumstix Connex BSP for RTEMS which ran on the Skyeye simulator. Xi implemented a frame buffer device driver for this board which worked with Nano-X. All of Xi's work was merged into the RTEMS Source Code Repository when completed.

As part of preparing her work to be merged into the Nano-X Source Code Repository, I worked with Roxana to clean up the build infrastructure and ensure that the code built easily on multiple BSPs. As part of this, we worked to port some supporting libraries to RTEMS. Before Greg Haerr had merged our work, we had created the RTEMS Graphics Toolkit (RTEMS CVS module rtems-graphics-toolkit) which includes the following libraries:

• libjpeg - (v7) http://www.ijg.org/
• libtiff - (v3.6.2) http://www.libtiff.org/
• libpng - (1.2.42) http://www.libpng.org/pub/png/libpng.html
• libfreetype - (2.3.11) http://freetype.sourceforge.net/index2.html
• libt1 - (5.1.2) http://www.t1lib.org/

This means you can decode and display JPEG, TIFF, PNG, GIF, and BMP graphics on an RTEMS system. It also means that you may have support for Adobe Type 1 TrueType fonts. The screen shot with the "Embedded with RTEMS" logo is the output of nxview running on the arm/gumstix BSP. The logo is a jpeg loaded from the RTEMS In-Memory File System (IMFS). The jpeg support library has no patches for RTEMS.


Using a build script in the top directory of this kit, you can easily build all of these packages and Nano-X (from their git repository). This includes building all demos for a specific BSP. The RTEMS Graphics Toolkit also includes the following libraries which are not currently ported but we would like to see ported.

• svgalib - (1.4.3) http://svgalib.org/
• fltk - (1.1.10) http://www.fltk.org/

Roxana is pursuing porting svgalib to bring its collection of more advanced graphics drivers to RTEMS. Interestingly, this ties in with the work of another Google Summer of Code Student, Aanjhan Ranganathan. Aanjhan's project consisted of adding MMU support to RTEMS. This includes support on some targets for the mmap() family of calls from POSIX. The svgalib package includes approximately 100 calls to members of this call family so we now have incentive for Aanjhan to get his work tidied up and merged.

FLTK is an important piece of the puzzle because it includes a GUI builder and numerous widgets. This will provide a robust foundation to build GUIs for RTEMS systems.

At this point, all Nano-X demo programs that are expected to run on RTEMS do so on both the pc386 and arm/gumstix platforms. There is obviously more to do. But it is important to emphasize that this is a major step forward for RTEMS. It makes it much easier to build GUIs for RTEMS based embedded systems.

Thanks to all the folks at Google who work so hard on the Summer of Code and the students they sponsor. This would not have happened without them. Thanks Leslie, Ellen, and Kat. :)

RTEMS Turns 21

The RTEMS ticker test (a.k.a. sp01) was the first test created during the development of RTEMS. It sets the date and time to 9:00 pm on 31 December 1988. This coincides with the earliest part of the RTEMS Project. Since there is no birth certificate, we are treating this as RTEMS birth date.

Please toast RTEMS turning 21 where ever you are.

Please don't be online -- share the New Year's Eve with loved ones. :)

Violating the Rule of Least Surprise

When you mention user interfaces, people usually think of a graphical interface with mouse and keyboard or a touchscreen. But user interfaces do not exist solely in the world of computer displays. In the world of embedded systems, a user interface can take on any number of variations. One guiding principle that particularly applies in this domain is the "Rule of Least Surprise." An example I use is that if you put someone behind the steering wheel of a vehicle of any type, they would expect that turning the wheel to the left directs the vehicle in that direction. To do anything else, would surprise even a three year old who has ridden a tricycle.

Even though I love my current car, it has two areas which violate this rule. As shown in the picture shown here (source), the instrument panel is in the center -- not directly in front of the driver. Both interface surprises stem from this placement.

The first violation is that when the lights are on at night, there is no light at all directly visible in the direct field of vision of the driver. It is very easy to forget to turn the lights on at night when in a well-lit area because you have to look to the middle to realize that the instruments are unlit. This has actually resulted in me getting pulled over by a friendly police officer to remind me to turn my lights on.

The second violation is when you turn on the turn signal to turn left. The blinking light indicating you have done so is in the right hand side of the driver's field of vision. In other vehicles, this would be in the left hand side
of your field of vision.

Neither of these is a major issue and I have grown accustomed to both. But both show how humans have expectations about how common devices operate. When your clever design changes this, users are surprised. In the end there may be a benefit, but often it is a difference just to be different. Is there a surprise in a system you are familiar with? Is it an improvement or just a difference? Share.