Skip to content

mprintf: a simple thread safe printf for DuinoOS Part A: Getting a thread safe printf to work

Monday, January 11, 2010

There are lots of ways to implement a thread safe printf for DuinOS (or free RTOS). The following is a version that renames printf as mprintf. Like an fprintf function, mprintf has a leading parameter which must be passed with the rest of the printf variables. This implementation exposes the methodology used to make printf thread safe. A future version will incorporate the methodology and hide the implementation details from the user.

There are 3 steps to make mprintf available for use:

  1. Enable MUTEX semaphores in our DuinOS (or freeRTOS)
  2. Create an mprintf variadic macro.
  3. Initialize the MUTEX to be used in your program when calling mprintf

Enabling MUTEX capabilities in your DuinOS.

Mutexs come disabled in the DuinOS. You must find the freeRTOSConfig.h file in your installation. Usually located at

~/arduino-0017/hardware/cores/arduino.DuinOS

directory. Open this file in your favorite text editor and add the following line (if not already there):

#define configUSE_MUTEXES 1

A good place to add this line is after the

#define INCLUDE_vTaskDelay 1

line. Your sketches and programs will no compile with MUTEXES enabled.

Building the variadic macro.

First, be sure to add the following #includes to the top of your sketch/program:

#include <cserial.h>
#include “DuinOS/FreeRTOS.h”
#include “DuinOS/semphr.h”
#include “DuinOS/queue.h”

I’m not going to go into how variadic macros work. It’s safe to say that they do work and they allow us to define a macro that looks like a function which can have a varying number of parameter. This is required because printf support varying numbers of parameters. Place the following code at the beginning of your sketch/program but after your includes:

#define mprintf(xM,…) while (xSemaphoreTake(xM,1000)==pdTRUE) {}\
printf(__VA_ARGS__);\
xSemaphoreGive(xM);\

The back slashes are required and no, they are not comments. They are used to extend the #define as if it were a single line.

Initialize the MUTEX.

The mutex to be used must be global as we will be using mprintf in any of our sketch or program functions. Some where after the #includes at the top of of our sketch/program, place the following line:

xSemaphoreHandle pMutex;

We can use any Mutex name you like. Here I use pMutex.

Next add the following lines at the beginning of your setup() function:

pMutex = xSemaphoreCreateMutex();

if( pMutex != NULL ) {
// The semaphore was created successfully.
printf(“could create pMutex semaphore\n”);
// The semaphore can now be used.
}

Note, I use printf here rather then mprintf. Why? because pMutex, which we will use as the first parameter in mprintf, must be used within one of the tasks in DuinOS. As we have not launched any tasks yet, the scheduler has not started so no mutex checks will be made (bad thing), however, no threads have started so no one else will be calling printf (good thing).

You now can add an mprintf call to one of your tasks or routines called by your tasks (note: you MUST use mprintf from within a task environment or you will get unpredictable results. Add a line that looks like this to one of your t asks:

mprintf(pMutex,”%s\n”,”Hello World”);

If all goes well (you have implemented unthread safe printf and thread safe mprintf) the message will be sent out the hardware serial port.

Good luck and have fun!

Paula


Filed in tronics | Tagged , , , | Comments (1)

Trees blocking traffic light at Folsom and 14th

Monday, January 11, 2010

Can you see the traffic light in this photo?  I’m on my motorcycle here and about 50 feet away from the traffic controlled interesection.  The light on the right hand side is completely obstructed by the trees.  The light on the left hand side is barely 8 feet off the ground and is easily obstructed by big rigs and box vans.    There are no overhead traffic lights at this intersection, although, just a few blocks further north the city has installed lots of overhead lights where there are no trees!  I’ve seen people run this light without even knowing.  I hate to admit it, but I mistakenly rolled through this light as it was changing from yellow to red because I had no indication that the light was yellow until I was within 40 feet of the intesection.  It is not possible to stop a motorcyle from 25 MPH to zero without losing control of the bike (locking up the only two wheels you have is not an option).  I hope someone doesn’t get hurt or killed here.

Paula

Trees blocking traffic light at Folsom and 14th

Trees blocking traffic light at Folsom and 14th

Filed in Announces | | Comments (0)

mprintf: a simple thread safe printf for DuinoOS Part A: Getting non threaded printf to work

Sunday, January 10, 2010

I thought it best that I document how I got printf to work and how I made it thread safe for DuinoOS (or freeRTOS for that matter)

Getting non threaded printf to work.

printf makes use of a file handle called stdout. This file handle is null unless we do something to change its value. the stdio library provides us with a method to initialize its value. We, however, must initialize the serial port and provide a function for stdio to use when it needs to send a character to stdio.

The stdio routine we use to initialize stdout is: fdevopen(<function name>,NULL).

update 20100320:  Daniel Haney, std@salversan.org provided the following comment and improvement which I have implemented.  The latest cserial.cpp file contains the needed changes.

<<<<<<<<<<<<<<<<<snip>>>>>>>>>>>>>

Thanks for your wonderfully concise code for redefining stdout. Reading through stdio.h for avr-gcc, they say fdevopen() implicitly calls malloc, which is problematic given the Arduino’s small memory.
They recommend using fdev_setup_stream(). It works and I seem to gain ~200 bytes.

<<<<<<<<<<<<<<<<end snip>>>>>>>>>>>

We need to create two routines. One that we use as a call back function to be passed into the fdevopen routine and one that we will use in our sketch or c/c++ code to initialize our port and initialized fdevopen. We will use two files. ‘cserial.cpp’ file and a ‘cserial.h’ file. The ‘cserial.h’ file will be included in our sketch/c/c++ file so that we have access to call the initialization routine. The source of the two files are located at the bottom of this blog entry

These two files must be placed into ~/arduino-0017/hardware/libraries/cserial directory or equivalent. We may need to create this directory.

We can now use the initialization routine: serial_stdout_init(<speed>) in our sketches (or c or c++) setup function. Add a line that looks like this:

serial_stdout_init(9600);

Don’t forget to add the cserial.h include file at the top of your the sketch (or program)

We can now use the non-threaded version of printf which should be fine using the standard Arduino. Next, how to make a thread safe version..

———————– files——————-

cserial.h

<<<<<<<<<<<<<<<<snip>>>>>>>>>>>>>>>

#ifndef cserial_h
#define cserial_h

#include <stdio.h>

static int serial_write(char,FILE);
void serial_stdout_init(long);

#endif

<<<<<<<<<<<<<<<end snip>>>>>>>>>>>>>>>>>

cserial.cpp

<<<<<<<<<<<<<<snip>>>>>>>>>>>>>>>>>>>>>

/* cserial.cpp */
// these two c functions are required so that
// stdout can be initialized for the stdio library
// This binds the printf function to the hardware serial port

#include “cserial.h”
#include “wiring_private.h”

static int serial_write(char c, FILE *f) {

/* Wait for transmit buffer to be empty */
while ((UCSR0A & _BV(UDRE0)) == 0)
;

/* Put byte into transmit buffer */
UDR0 = c;

return 0;
}

static FILE sio_stdout = {0} ;                           /* added to support the DH mod eliminating stdio malloc requirements */

void serial_stdout_init (long speed) {
/* Set baud rate */
uint16_t factor = (F_CPU / 16 + speed / 2) / speed – 1;
UBRR0H = factor >> 8;
UBRR0L = factor;

/* Set format (8N1) */
UCSR0C = 3 << UCSZ00;

/* Enable transmitter */

UCSR0B = _BV(TXEN0);

/* Set up stdout to write to the serial port */
/* stdout = fdevopen (serial_write, NULL);  replaced with the following care of DH */

fdev_setup_stream(&sio_stdout, serial_write, NULL,_FDEV_SETUP_WRITE);
stdout = &sio_stdout ;

}

<<<<<<<<<<<<<<<<<<end snip>>>>>>>>>

Filed in tronics | Tagged , , | Comments (1)

Radio and electronics

Sunday, December 13, 2009

Radio and electronics has such a nice ring to it.  I remember being shown by my grandmother, how to tune this giant radio she had.  It was in a huge cabinet and at my eye level I could look right at the big semi circle dial with lots of lines.  There was a knob that I could turn and it would move a needle behind the dial.   There was another knob that clicked and turned on a light inside the box, then, sounds would come from the box.  Sometimes I could make music come from the box, other times it would just hiss or crackle and then there were people talking that I couldn’t understand.  Weirdest of all were these tones that would come on and off, sometime really fast, sometimes slow.   I wanted to know lots more about this box!

Years later, I had a transistor radio and I of course dropped it and broke it. I opened it up and inside was a universe of little things mounted on a board.  Back I went to the library and learned how to recognized the resistors, capacitors, transistors, loop antenna, rheostat, tuning capacitor and had no idea how it all worked together but I did know everything had to be connected.  The broken radio had a loose wire on the antenna loop and I could see where it was suppose to be connected.  Pop had an old soldering iron made to solder tin together so I asked Pop to take me to a radio store where I could get a smaller soldering iron.  He took me to this giant warehouse on Commonwealth ave in Boston called Radio Shack.  Back in those days, Radio Shack was an electronics surplus house with bags of surplus electronics.  Think American Akihabara.  I got my soldering iron and fixed my little radio.  I was 10, it was 1962.

A couple of years later during winter I had health problems that required a traumatic stay in a hospital just before Christmas.  I would be out of school for several weeks in the new year and forced to stay off my feet.   That year, I got my first shortwave radio receiver.  It was a Heath GR-91 kit that I would have to build myself!  Dad set up a card table in my bedroom with a chair so I could get up, work on my kit for a while, then crawl back into bed.  I had the kit built in less then two weeks.  The moment had come to plug it into the wall and see if it lit up or (horror) smoked.  My very first smoke test!  The radios back in those days (early 60′s) were tube based so they literally did ‘light up’  with a warm orange glow.  One tube had a beautiful purple glow and was marked as a ‘rectifier’ in the kit instructions.  A hiss came from the speaker I had wired up to the headphone jack (the speaker was pulled out of my transistor radio).  Tuning across the band and twiddling the rf gain knob, I heard my first stations.  Mostly local broadcast stations and Voice of America (the US shortwave propaganda broadcast).  I did hear a few faint tones that made up dots and dashes.  The instructions suggested using some test equipment to improve the sensitivity so I asked Dad if he knew anyone who had that kind of equipment.

Dad brought me one of his accounting clients (Dad was an accountant and did small jobs for little companies on the side).  This fellow was in Harvard Square.  He had a drug store with a soda fountain and made great grilled cheeses and lived above the store in a small apartment.  The apartment and drug store was across the street from the Harvard Square Gulf Station (which was a famous landmark torn down in 1989)   He was a lonely guy but seemed pretty happy.  On one end of his living room, near some windows, he had a bench with lots of electronic boxes on it.  He had a big chair centered in front of the boxes and the boxes formed a sort of semicircle facing the chair.  There was a microphone, and a funny paddle that looked like it had a metal bug attached to it.  Dad told him I was interested in radios and that I had just build a Heathkit.  Wow did this guys eyes light up.  He said:  “Let me show you something!”.

Elmer (can’t remember his name right now but he was my Elmer!)  started turning knobs.  Dials began lighting up, the cabinets began to show a faint glow from within.  The room all of a sudden seemed warmer.  As he tuned the radio dial strange sounds would come out of the big speaker (which was also in a nice cabinet).  When he had a station tuned just right, we could hear a man speaking, talking about the weather, where he was (this one was in Florida!).  When he tuned past the station the sound seemed to warp out, sounding like Mickey Mouse then disappear into the crackly background.  Another sound would come in, starting like low grunts then rising in tenor to a point where it was a voice again.  This time the man on the radio was saying ‘CQ’ over and over.  Elmer said, lets see if we can talk to him.  After the guy on the radio said ‘over’ Elmer pressed a button on the microphone, said some letters and number and then ‘over’.  The guy on the radio came back and said the same numbers and letters, told us his name (we’ll use George)  and where he was located (this time it was Georgia) said the weather was clear and cool then the letters and numbers again and ‘back to you’.  Elmer pressed a button and started talking about the weather, his location and this youngster in his ‘shack’ that had just built a Heathkit and would like to say a few words!   Yikes!  I was suppose to say something into this metal thing called a microphone!  “Hi!  I’m Paula.  I’m 11 years old and I’m interested in radios”  Dah, gosh did I mumble, did he hear me?  (Elmer sez say ‘over).  Oh, over?.  The George in Georgia sez ‘hello Paula, nice to meet you!  So you built a Heathkit?  Are you going to get your ham license? over. (Oh gosh, he heard me!  Now I have to say something back?  What did he say?  Heathkit?  ham license?  What do I say?   And so I made my first contact when I was 11.  (Elmer, opened up the heathkit, set some knobs on his station, turned a knob on my Heathkit and reached in side with a little plastic screw driver).  Soon lots of stations started coming out of the speaker hooked to my Heathkit.

This Ham stuff seemed interesting.  Someone like me could have a transmitter hooked to an antenna and electromagnetic waves would jump off the antenna, bounce around in the sky and be heard by someone else.   In the early 60s this was way cool stuff!  I wanted to build one of these transmitter boxes and get a ham license!  Elmer had given me a spare copy of the Amateur Radio Handbook by the ARRL and I had already flipped through every page.  Most of it was un-intelligable to me but some of it made sense.  My big break through was reading the section on how vacuum tubes worked.  There were diodes, triodes, tetrodes, pentodes and on.  The triode was the real key.  The basic element (I really liked dealing with canonical things) that let electrons flow through a single grid (like a bug screen on a window) where the electron stream would vary based on a small change in the charge (voltage) of the grid.  Easy stuff.  I came across a really simple transmitter circuit (in the new 1966 hand book dad got me) that I actually could understand and explain.  I decided that I’d ask Dad if I could build one and enter it into the science fair at my junior high school.  Dad took me to Demambro’s in Boston and I showed them my list of parts.  They didn’t have all of them so we had to go to an electronic junk store to find the others.  The junk store guy explained how sometimes you couldn’t get the exact part but another part would be really close, so I had some substitution parts.  Building the transmitter was really hard.  Well, at least cutting the holes in the chassis was really hard.  Once I had all the holes cut and drilled it was easy.  Soon, I was wiring up the parts.  During this same time I was studying for my Novice Amateur Radio License.  I wanted to pass the test before the science fair because I wanted to be legally on the air!  And then there were the poster boards for the Science Fair.  Giant versions of the schematics with descriptions of all the key parts.

A couple of weeks before the science fair, Dad took me to Elmer’s house.  He was quite serious this day.  Sitting me down at his kitchen table and asking me to sign a paper before he opened up the Novice test folder. The directions said I had to copy a steady 5 wpm of Morse Code before I took the written test and if I failed I would have to wait two weeks before taking it again.  Elmer sat down with a practice key and asked if I was ready.  Pencil in hand, paper on the table I said yup…  Five minutes later it was over and I had passed with flying colors.  Now it was time to take the written test.  A series of multiple choice questions.  I finished in about 15 minutes.  Elmer reviewed it and said it looked good but we wouldn’t know for six weeks as that’s how long the FCC took to check the answers and get back to us.   That was a pretty stressful afternoon.  Elmer asked if I wanted to operated his Colins station.  I said no, that I was pretty tired and wanted to go home.

Back home, I was just finishing up my transmitter.  I plugged in the transmitter and with a long stick flicked the on/off switch to the on position.  The rectifiers glowed purple for a second and went out.  I shut the switch off.   Opened up the ARHB and read through the project instructions.  No joy.  I checked all my wiring, everything looked pretty good.  Only thing that I wasn’t sure about was the two different symbols for ‘ground’  One was a sort or rake, the other was an arrow pointing down.  Turns out, that was my problem.  Mom had a niece who was married to a TV repair man so she gave him a call and asked him to come over and take a look.  He told me that I had to connect those two grounds together.  With a tiny piece of wire and solder I hooked the wire ground to chassis ground and we turned on the switch.  A beautiful purple glow came from the rectifiers.  I hooked up a Morse code key and pressed the key.  The light bulb I had hooked up to the transmitter output glowed bright with each key stroke.  Wow!  I’m transmitting.

The science fair came and went, I got an honorable mention since I didn’t do anything original.  .  It was one of two science fairs I entered during junior high and high school where students were rewarded if they kept good statistics on rats eating Cheerios but were not rewarded for demonstrating and understanding abstract concepts.  I’ll digress a bit here and talk about the great Science Fair Fix.  The second  science fair I was in I did a demonstration of various oscillators that used un marked transistors I had picked up.  It required characterizing the unknown transistors and designing an appropriate circuit that would make use of the unique characteristics of that transistor.  I had three separate single band tunable oscillators.  One of the three judges understood what I had done (he was an MIT professor and a ham radio operator) the other two were down right nasty to me, claiming all I did was copy some equations out of a text book.   I didn’t get an honorable mention and was hurt by these adults that said I somehow cheated.  The last science fair in high school I was warned by my physics professor not to enter because no one would understand.  It demonstrated the technique and use of modulating two different colored light sources, combining them sending them down a glass tube, un combining them demodulating and hearing the separate sources at the other end.  We call it wdm or wave devision multiplexing and its how most of Internet traffic is run through fiber optics.  Sadly, only those that were the teachers favorites got the awards, scholarships and went on to the big name schools.

A few weeks after the science fair I got a letter in the mail from the FCC.  It was my Novice class license! Call sign and all!  A real official recognition of my accomplishments.  I was now WN1GRX and could transmit on the novice bands.   Back in those days, the novice class license was only good for one year and it was not renewable so I had to immediately start studying for my General class license.  A much harder test and much faster code (13 wpm).

I was on my way to a career in electronics, computers, graphics, high speed processing, networks, data analysis and more.

Filed in My Engineering autobiography | Tagged , , , | Comments (5)

How does an Atmega boot?

Wednesday, December 9, 2009

The bootloader (stk500) used by arduino and other atmega vendors allows for self modifying code.  Normaly not a good idea, however, being able to use your atmega to load code onto the very same chip is extremely handy (think, in the field re-programming and programming your chip without a flash burner) So, how does all this work?

It took some digging around and the most obvious search turned out to be the best (google atmega boot block).  A very nice white paper by atmega makes it quite clear.  In a nut shell, the atmega chip can change its interupt vector table and boot vector locations to either an ‘application’ section flash or a ‘bootloader’ section flash.  As expected, there are lots of options but it does explain how a boot loader running on a machine can load an entire program that is expecting to start at 0000 followed by interrupt vectors and not over write the bootloader!  Very cool stuff.  (here)

Filed in tronics | Tagged , , , | Comments (0)

The devil is in the details: Atmega startup to freertos

Sunday, November 15, 2009

Figuring out why something breaks usually involves understanding how it is supposed to work.  Sure, it was easy getting my first Atmega328 code running using Arduino.  Getting the DuinOS version of freeRTOS was a little bit more of a challenge but ran remarkably well given its alpha state.  Getting a printf function to work using some avr-libc utilities (that map a routine to a file handle like stdout) was a bit more of a stretch, and discovering that printf in the avr-libc was not thread safe, requiring a fancy macro using a Variadic Macro (google that one) to wrap the printf in a Mutex semaphore did stretch things a bit, along with finding how to turn Mutexes on in the DuinOS version of free RTOS.

All of this was for not though, when my benchmark program using ThreadX failed to even run.  Chasing that problem lead me to a realization that I had no_idea how a main() starts on an Atmega after being loaded by the bootloader and no idea how freeRTOS gets its kick start.  To that end, I write this little blurb to remind me that the devil is in the details.

Digging around on the net has uncovered some interesting tid bits about the Atmega 8 MC family.   At the same time, I started fingering (with vim and egrep) the freeRTOS sources to get a feel for how things get underway.

First a bit about the Atmega.  It’s got lots and lots of goodies.  My focus is on what happens when you reset this little puppy.  Well, as expected, it starts from location 0000.  But which 0000, there are three different memory spaces (or more).  Fortunately the processor block diagram provides a hint.  EEPROM memory, as it turns out, is the usually starting point, but, an io port can be hit to move the starting point to FLASH where programs are loaded by the boot loader.  So, we start at 0000 in FLASH (at least for the turnkey setups on the Arduino boards).  What happens next?  Magic happens in the linker when the program code is built.  The linker puts a jump instruction at 0000 to the first location after all the interrupt vectors that come right after the 0000 and 0001 location.  The linker also adds a bit of asm code to initialize the stack pointer to the top of memory in ram space (usually a strange address, as the Atmega IO space is allocated the lowest locations in that volatile address space) causing ram to start at some higher location).  The asm code then jumps to the main() routine where, one more time, a small amount of code (not seen in your main c code) is plugged in by the linker (or compiler) to initialize the stack pointer again and set some io bits.  Then, finally, recognizable code that you have written in your main routine shows up.  There you have it.  A readers digest version of an Atmega starting up.

It should be possible, with a bare bones enough interface to the hardware serial port, to read the just initialized stack pointer to verify this little aspect.  It should also be possible to find the lowest ram location that is above all theconstant and non constant allocated variable space.  Still looking for the gcc-avr system variable or define that tells me that.  Would be useful for the next step:  Understanding how freeRTOS gets started.

freeRTOS gets itself started when the first task is created.  The task creation routine detects that the first task is being requested and initializes the heap to be used by the scheduler. The task creation routine only does this once then does normal task initialization.   Once initialized the scheduler can allocate stack space for the idle loop and stack space for the first task then, based on priority, return control to the task with the higher priority (usually the first task created, not the idle loop) and off it goes.  Stack space is user definable on a task by task basis at creation time.  To get a feel for how well the tasks are using their compute assets, we need some instrumentation (dah).  Useful data would be, how much stack space is consumed, how much is left and how much cpu time has the task eaten.  There is some instumenation delivered with freeRTOS but it seems pretty heavy weight and does not give the simple details that tell so much.  This is probably my next steps (including the main() report of first data location and first stack location).  I’m thinking I should have something that looks like this:

mBottom=[], mSP=[]

These could be dumped when main() is entered.

rHBottom=[];rHTop=[]

These could be dumped on the initial startup of the scheduleer

rHTop=[],rSPidleTop=[],rSPidleCurr=[],rSPbottom=[]

rHTop=[],rSP1Top=[],rSP1Curr=[],rSP1bottom=[]

….

This could be run inside the scheduler and dumped to the hardware uart.

need some uart code

Filed in tronics | Tagged , , , , | Comments (7)

DTN (Delay Tolerant Network Architectures)

Friday, November 13, 2009

Here is a link to a good DTN paper

Here is a working group

Another paper here discussing DTN2 implementation

Discussion of DTN2, DTNLite and Contiki here

DTN-Lite on TinyOS here

Filed in tronics | | Comments (0)

RTOS for Arduino

Friday, November 13, 2009

Before I hang my hat on an RTOS for my Atmega projects I wanted to know what was out there and how popular the various rtos platforms were. Here is a summary (original list from here). As of this writing, FreeRTOS for DuinOS is a hands down winner.

Update: 20100112: DuinOS : DuinOS is a port of freeRTOS on Arduino that tries to preserve the development environment by hiding much of the freeRTOS fundamentals as possible. I have mixed feelings on this and have been reverse engineering my sketches to expose as much of freeRTOS as possible.

Update 2010112: AVRx: Although not actively expanding, there seems to be a yahoogroup, avrx, that is active. This is worth a second look at.

Update 2010112: TinyOS: This is an OS for a sensor networks.  There is mixed information on how actively supported and used this OS is. Still researching.

FreeRTOS: A Free RTOS for microcontrollers Currently very active. There is an interesting fork called DuinOS for use with the Arduino IDE that works very nicely. Can be found here and a discussion can be found here. I’ve done this fork on the Arduino Duiemonolove and peeled back the covers. TBD in another section of this blog with performance metrics.

AvrX: Real-Time Kernel for AVR processors Not very active. the 2.6 version compiled from C looks interesting. The yahoogroup for discussing AvrX is moderately active

YAVRTOS: Yet Another Atmel AVR Real-Time Operating System Just what it sez, yet another RTOS. Self described as a project and not a product. Not regourisly tested.

AVRAsmOS: A tiny OS for small AVRs V1.0 active November 9,2009. No web page or documenation.

pc/OS RTOS Kernel (for larger AVR processors >= mega128) There is some activity. Documentation is sparse. No porting or installation guidance. Based on a 1992 rtos

uSmartX: Non-Preemptive Priority-based Multitask RTOS Not active

COMATOS Not active.

Task dispatcher Is what it is, a dispather. Not an RTOS

Opex A simple scheduler, not an RTOS

mthreads Another thread only library, not really an rtos

RTK low activity. Nice starting point for someone interested in creating their own RTOS.

csRTOS not active

Adam Dunkel’s Protothreads Fairly old simple threading code. Not really an RTOS. Last updated in 2005.

Femto OS Active, looks interesting but the license is restrictive and requires all of your application IP to be freely distributed.  Lays claim to your IP (intellectual property) because your code gets embedded with femto OS. If you think what you are creating is every commercially viable you probably do not want to use this.

TinyOS Spotty activity, supposedly for sensor networks, site links are old or not active, forum and wiki seems to have been compromised with spam, look at them on your own risk. Best link I have found is here

Contiki Heavy on the TCP/IP requires 2k ram 40k rom

pico OS not active

scmRTOS: a C++ cooperative OS with Mit license Last updated by author 2006

iRTOS: a C preemptive OS with LGPL license

Filed in tronics | Tagged , , , , , , , | Comments (7)

piece parts

Monday, November 2, 2009

avrdude: http://www.bsdhome.com/avrdude/ This is the application that loads a program onto the atmega328.  It has two modes, a direct program mode and ‘special’ mode that makes use of an on board (the atmega chip) boot loader.

example of a command line avrdude that loads a hex file using the arduino bootloader

This works from the command line on my system (dell laptop, usb port connected to Arduino Duemilanove, Ubunu 9.04)

avrdude -C /etc/avrdude.conf -b 57600 -p atmega328p -c stk500 -P /dev/ttyUSB0 -U flash:w:HelloWorld.cpp.hex

***note*** be sure that you use the arduino avrdude and avrdude.conf files located in the arduino-0017/hardware/tools directory (I used soft links to keep the original paths installed by gcc-avr.

More documentation here

Filed in tronics | Tagged , , , , | Comments (0)

Its alive!

Sunday, November 1, 2009

Blink

Okay,  I am impressed.  Scrounging around my cable box I found a compatible USB cable.  I started up the Arduino dev environment, loaded the ‘blink’ sketch (some ‘c’ code that defines the setup() and loop() functions for blinking an on board led).  Compiled the code and got a result indicating 836 bytes (seems like a lot of code to blink an led).  I plugged in the Arduino board to my laptop.  The Arduino dev env found the tty usb port so I selected that and hit upload.  Magic.  The tx/rx leds on the Arduino board blinked frantically and the blink program began running, blinking once per second.

Okay, how do I know its my program?  I change the delays to 1/5 of a second, recompile, re upload and poofoh, the led blinks lots faster.

End to end with validation test in under 2 minutes!   I might be able to make this work!

Minimum compile

So how much overhead is there with setup() and loop()?

There seems to be 436 bytes of code in an empty program

Serial port communications

Lets start with the ‘hello world’ script.  It works (dah)

How about a key board echo… (need to write some code!).  Works but the tty monitor gets in the way of cr/lf so only the readable text entered is sent

Filed in tronics | | Comments (0)