First Time Embedded Linux Development

theawddone

Member
Sep 1, 2006
55
0
0
I am a 4th year computer engineering student and I have been heavily involved with a campus project for the past year and a half building CubeSats (cubesat.org if you are curious, but they are basically 10cm cube satellites that generally have a 1W power footprint). We have been using PIC18's since our inception basically (they are on at least 6 of our satellites) and really hate the MPLAB IDE software, and the PIC's general lack of efficiency; yes, we know there are other alternatives out there, but we've already made our decision to move on past it, we can take that to another thread if you wish.

Anyway, we are moving on to a Embedded Linux platform on a super low-power ARM architecture chip and I am in charge of the software side of things. Right now, we run a system that is essentially a really simple (and I use the word lightly) "RTOS" based around a while(1) loop; there are a few different tasks that are run based on timers, and then most everything else is event-based (i.e. ground communications). We already have a large code base from the previous satellites and so my general approach for this quarter is going to be to create a hardware abstraction layer, so that we can get rid of PIC specific code, and then start porting the code to Linux processes. Also, I am planning to utilize the distribution that is specifically for the class of processors I am using (the SAM9), hopefully meaning I shouldn't need to write any I/O specific drivers (i2c, spi), but will need to write drivers for some of our H/W components like transceiver and other unique components.

I've only taken one systems programming class and one subsequent "OS" class, but that was over a year now so I've definitely got my work cut out for me and therefore I am trying to do some research before diving in completely. My primary resources so far have been an article from Linux Journal (Porting RTOS Devices Drivers to Embedded Linux), but some of the stuff they mention, I am not entirely sure how to start on (i.e. writing "a Linux driver to handle interrupt processing at kernel level"). Something I've spent a little more time on is the O'Reilly book: "Building Embedded Linux Systems". A lot of the stuff covered in this book seems good to know, but I've realized a few issues with their approach versus what I need to accomplish: a) this book seems to be mostly for people starting from scratch and who want to do a full-custom type design b) doing the aforementioned type of design would easily exceed the desired time frame of development (we want to have a prototype by June) c) the book continually reiterates that it is likely to be out-of-date by the time I read it.

I know that a lot of the stuff I need to do, can be found by looking at regular Linux books/tutorials/etc, but this system I develop should be used for many years to come after I leave and I want to do it right. So, in a nut-shell what I am asking is: can anyone either provide some first-hand experience/lessons learned from a similar project or perhaps some other literature that may be suited to what I am trying to achieve?
 

Modelworks

Lifer
Feb 22, 2007
16,240
7
76
I have used pics for a number of years and they can be frustrating at times. Each pic has its own quirks to work around and there really is no standard way to develop for it. MPlab is great if you like assembly but for C there is hi-tech and lots of others all with various different issues.

Some lessons I learned, make sure, 110% that any parts you use have easily accessible documentation. You do not want to have to program for something that has lines in the documentation like "contact sales for more info" . If the manufacturer is not willing to provide the source of what you are using then consider using something else.

You really should know assembly language to work with embedded platforms. You can squeak by sometimes, but the people that have that knowledge and understand things like the registers and instructions used on the target device will always have an advantage. So if it were me I would get the SAM9 documentation and read it until I could almost quote it, people tend to gloss over technical specs because it does get boring, but writing drivers requires you to know it. Look at how things like i2c , spi, i/o lines are done with the current drivers to see how they did it. Hopefully there is source code for those drivers, if not, then I would be very careful in using them for something like this. Embedded projects have a way of having things happen in code that people never see on a pc.

If you study the data sheets and architecture of the processor you should begin to understand how to write the drivers. The best book to read is the data sheets.
 

theawddone

Member
Sep 1, 2006
55
0
0
Some lessons I learned, make sure, 110% that any parts you use have easily accessible documentation. You do not want to have to program for something that has lines in the documentation like "contact sales for more info" . If the manufacturer is not willing to provide the source of what you are using then consider using something else.

You really should know assembly language to work with embedded platforms. You can squeak by sometimes, but the people that have that knowledge and understand things like the registers and instructions used on the target device will always have an advantage. So if it were me I would get the SAM9 documentation and read it until I could almost quote it, people tend to gloss over technical specs because it does get boring, but writing drivers requires you to know it. Look at how things like i2c , spi, i/o lines are done with the current drivers to see how they did it. Hopefully there is source code for those drivers, if not, then I would be very careful in using them for something like this. Embedded projects have a way of having things happen in code that people never see on a pc.

If you study the data sheets and architecture of the processor you should begin to understand how to write the drivers. The best book to read is the data sheets.

I really appreciate the advice, and having gone a few design cycles with the PICs I am intimately familiar with documentation and data-sheets. Unfortunately, that isn't really the issue I am facing right now. My primary concern is getting a development environment set up and choosing a distribution. On that note, I have found two different 'open source' distributions that may or may not (which is my problem--how do I find spec sheets to give me some details for each distro?) meet our needs. For those curious and/or those that may be able to help with this question: http://www.kaeilos.com/ and http://www.angstrom-distribution.org/.