C 'desktop' programmer needs advice on how to code embedded C on a micro controller.

Hi Group,

Intro
I've  been programming for a long time (to long to mention!), but 99%
of my programming has been for 'desktop' PCs under DOS and UNIX using
C. I've rarely had to worry about interrupts, watchdogs etc. Well now
I have to! The target will be a Radio with an 8-bit NEC Micro
controller (non-RTOS). My initial task is to Tx/Rx data over serial
comms (again, I hope in  C). The data may be short (so I thought
interrupts would be ok), but can also be 'streaming', which I'm
guessing means the comms module can't run off interrupts? This will be
one of several functions the radio will need to perform, so again I
guess some overall control will need to be implemented to get all the
tasks done.

The Help I would like.
1 - Recommended resources (books, websites) that will help me with the
fundamentals.
2 - Recommend resources on embedded serial comms (with coding examples
if possible).

TIA.

Roger Walker wrote:
> Hi Group,
> 
> Intro
> I've  been programming for a long time (to long to mention!), but 99%
> of my programming has been for 'desktop' PCs under DOS and UNIX using
> C. I've rarely had to worry about interrupts, watchdogs etc. Well now
> I have to! The target will be a Radio with an 8-bit NEC Micro
> controller (non-RTOS). My initial task is to Tx/Rx data over serial
> comms (again, I hope in  C). The data may be short (so I thought
> interrupts would be ok), but can also be 'streaming', which I'm
> guessing means the comms module can't run off interrupts? This will be
> one of several functions the radio will need to perform, so again I
> guess some overall control will need to be implemented to get all the
> tasks done.
> 
> The Help I would like.
> 1 - Recommended resources (books, websites) that will help me with the
> fundamentals.
> 2 - Recommend resources on embedded serial comms (with coding examples
> if possible).
> 
> TIA.
> 
Why no RTOS?  There are very small real-time kernels that work just fine 
on 8-bit processors, and will simplify your life if your code needs to 
do more than one or two things at once.

I'm not sure what you mean by 'streaming', but using interrupts on 
serial data is often a very good way to go.  You set up your main-body 
code to consume received data from a queue, and to write transmit data 
to another queue, then you set up your ISR to service the queues.

I learned embedded system design by osmosis, so I don't have direct 
experience with the books.  Jack Ganssel's embedded book is a classic; 
one hopes that means it's worth while.  Lewin Edwards has one out on 
becoming an embedded engineer -- I don't know if he speaks to technical 
issues or just the office politics peculiar to embedded software, though.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

"Roger Walker" <nil@nil.com> wrote in message 
news:3c2d13tlrmpb2jipnesb4rjuotrlo8jtk0@4ax.com...
> Hi Group,
>
> Intro
> I've  been programming for a long time (to long to mention!), but 99%
> of my programming has been for 'desktop' PCs under DOS and UNIX using
> C. I've rarely had to worry about interrupts, watchdogs etc. Well now
> I have to! The target will be a Radio with an 8-bit NEC Micro
> controller (non-RTOS). My initial task is to Tx/Rx data over serial
> comms (again, I hope in  C). The data may be short (so I thought
> interrupts would be ok), but can also be 'streaming', which I'm
> guessing means the comms module can't run off interrupts? This will be
> one of several functions the radio will need to perform, so again I
> guess some overall control will need to be implemented to get all the
> tasks done.
>
> The Help I would like.
> 1 - Recommended resources (books, websites) that will help me with the
> fundamentals.
> 2 - Recommend resources on embedded serial comms (with coding examples
> if possible).
>
> TIA.


You might like to check out the source code for DZComm -
http://dzcomm.sourceforge.net/

This is a freeware RS232 driver for DOS and Linux.  It is based on the 16550 
UART and is probably much more comprehensive than you need for an 8bit 
micro, but you can cut out great chunks to be left with the basic buffered 
driver.

-- 
Regards,
Richard.

+ http://www.FreeRTOS.org
A free real time kernel for 8, 16 and 32bit systems.

+ http://www.SafeRTOS.com
An IEC 61508 compliant real time kernel for safety related systems.

In article <3c2d13tlrmpb2jipnesb4rjuotrlo8jtk0@4ax.com>, Roger Walker 
says...
> Hi Group,
> 
> Intro
> I've  been programming for a long time (to long to mention!), but 99%
> of my programming has been for 'desktop' PCs under DOS and UNIX using
> C. I've rarely had to worry about interrupts, watchdogs etc. Well now
> I have to! The target will be a Radio with an 8-bit NEC Micro
> controller (non-RTOS). My initial task is to Tx/Rx data over serial
> comms (again, I hope in  C). The data may be short (so I thought
> interrupts would be ok), but can also be 'streaming', which I'm
> guessing means the comms module can't run off interrupts? 

Whether you can get away with polling depends on how long you will be 
between checking the serial peripheral in comparison the the character 
time.

> This will be
> one of several functions the radio will need to perform, so again I
> guess some overall control will need to be implemented to get all the
> tasks done.
> 
> The Help I would like.
> 1 - Recommended resources (books, websites) that will help me with the
> fundamentals.
> 2 - Recommend resources on embedded serial comms (with coding examples
> if possible).

An older book actually meant for DOS rather than embedded 

"C Programmer's Guide to Serial Communications" - Joe Campbell

The problem might be finding a copy.

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com

On Fri, 06 Apr 2007 11:52:18 -0700, Tim Wescott <tim@seemywebsite.com>
wrote:

>Roger Walker wrote:
SNIP
>Why no RTOS?  There are very small real-time kernels that work just fine 
>on 8-bit processors, and will simplify your life if your code needs to 
>do more than one or two things at once.
RTOS  is probably (from my very limited knowledge of this) the way
forward, alas if we can 'fudge' something I think we'll have to fudge
(for now at least).
>
>I'm not sure what you mean by 'streaming'
One device will be transmitting (possibly) constantly (GPS device). I
know I only want one of the various data strings, and that only every
1/4s max. That's is why I thought with that sort of 'streaming' data
maybe I wouldn't want to tie the CPU up not only having to get all the
data but having to compare it to see if it's the data needed, only to
find that I  possibly do not need it. 

How I envisage it working (in my sequential mind!) is that I would:-

i)	Receive any data sent over serial link (Interrupt driven?)
(Only receive xbit(s)/byte(s) at a time to allow CPU to do other
things - not sure if this means I could loose data, don't even know if
an interrupt is raised for every bit received on serial line!!).
ii)	Compare received data to see if it's one I'm interested in.
Not sure how I would call this routine. I believe data 'sentences' are
terminated with a CR/LF. So perhaps raise my own interrupt from (i) to
call this routine.
iii)	IF it is data I want store it in memory until it is
overwritten. Maybe raise an interrupt to tell whatever that update
data is available. Or just let the required software grab it when it
needs it (but what happens if that memory location is being written to
as it's being read)

And  I'm not even thinking about what I have  to do to with the data
now that I've got it (that's the next stage!!!)

I think this is why I need to understand alot more about the basics of
embedded coding!!!!

>, but using interrupts on 
>serial data is often a very good way to go.  You set up your main-body 
>code to consume received data from a queue, and to write transmit data 
>to another queue, then you set up your ISR to service the queues.
>
>I learned embedded system design by osmosis, so I don't have direct 
>experience with the books.  Jack Ganssel's embedded book is a classic; 
>one hopes that means it's worth while.  Lewin Edwards has one out on 
>becoming an embedded engineer -- I don't know if he speaks to technical 
>issues or just the office politics peculiar to embedded software, though.


Thanks for your help!

Roger Walker wrote:

> My initial task is to Tx/Rx data over serial
> comms (again, I hope in  C). 

"Initial" task? This begs a question that you should ask yourself before 
going on: what is the actual "final" task?

You need to at least roughly know the whole scale of the project before 
you can go into details of designing individual aspects of it.

 > The data may be short (so I thought
> interrupts would be ok), but can also be 'streaming', which I'm
> guessing means the comms module can't run off interrupts? 

Actually, it often means you *must* run the comms off interrupts, 
because the rest of the program will be so busy doing other things that 
you can't afford polling for new data on the serial ports.  You'll 
typically need some circular buffering between the serial ports and the 
main application.

Polling only really works well if the program does not much else than 
handle communication.  If it's supposed to also get some "real" work 
done on the side, polling tends to turn into an excessive burden.

> 1 - Recommended resources (books, websites) that will help me with the
> fundamentals.

It doesn't directly match your choice of CPU (who made that for you, 
anyway?), but I consider Michael J. Pont's book "Patterns for 
Time-Triggered Embedded Systems" a good first choice.  It starts all the 
way down at the basics (what's a port pin, and how should I use it), and 
goes quite a long way from there.  Applying what you find in this book 
to this non-8051 micro might even provide extra didactic value.

On Fri, 06 Apr 2007 20:49:17 GMT, Roger Walker <nil@nil.com> wrote:

>On Fri, 06 Apr 2007 11:52:18 -0700, Tim Wescott <tim@seemywebsite.com>
>wrote:
>
>>Roger Walker wrote:
>SNIP
>>Why no RTOS?  There are very small real-time kernels that work just fine 
>>on 8-bit processors, and will simplify your life if your code needs to 
>>do more than one or two things at once.
>RTOS  is probably (from my very limited knowledge of this) the way
>forward, alas if we can 'fudge' something I think we'll have to fudge
>(for now at least).

A lightweight operating system (not necessarily real-time) or a
foreground/background design would both work fine here.

>>I'm not sure what you mean by 'streaming'
>One device will be transmitting (possibly) constantly (GPS device). I
>know I only want one of the various data strings, and that only every
>1/4s max. That's is why I thought with that sort of 'streaming' data
>maybe I wouldn't want to tie the CPU up not only having to get all the
>data but having to compare it to see if it's the data needed, only to
>find that I  possibly do not need it. 
>
>How I envisage it working (in my sequential mind!) is that I would:-
>
>i)	Receive any data sent over serial link (Interrupt driven?)
>(Only receive xbit(s)/byte(s) at a time to allow CPU to do other
>things - not sure if this means I could loose data, don't even know if
>an interrupt is raised for every bit received on serial line!!).

The typical microcontroller UART doesn't have a built-in FIFO so
you'll be interrupted as each character (not bit) is received. Have
your serial ISR toss each character into a lightweight queue and the
foreground process can retrieve them as and when it needs.

>ii)	Compare received data to see if it's one I'm interested in.
>Not sure how I would call this routine. I believe data 'sentences' are
>terminated with a CR/LF. So perhaps raise my own interrupt from (i) to
>call this routine.

NMEA data is very structured, so deciding if the sentence you've just
received is one that you want isn't that hard. 

>iii)	IF it is data I want store it in memory until it is
>overwritten. Maybe raise an interrupt to tell whatever that update
>data is available. Or just let the required software grab it when it
>needs it (but what happens if that memory location is being written to
>as it's being read)

Set a sentinel or double-buffer the stored data.

On Fri, 06 Apr 2007 23:02:09 +0200, Hans-Bernhard Br�ker
<HBBroeker@t-online.de> wrote:

>Roger Walker wrote:
>
>> My initial task is to Tx/Rx data over serial
>> comms (again, I hope in  C). 
>
>"Initial" task? This begs a question that you should ask yourself before 
>going on: what is the actual "final" task?
>
>You need to at least roughly know the whole scale of the project before 
>you can go into details of designing individual aspects of it.
>
I understand and agree with you! Alas this is another 'get it working
quick' and the basic software (hacked from previous versions code
developed for previous hardware - not by me) has just been rammed in!
The initial task (for me) of getting some serial comms is going to be
another 'ramming' exercise. Then maybe a design can be put together! 
> > The data may be short (so I thought
>> interrupts would be ok), but can also be 'streaming', which I'm
>> guessing means the comms module can't run off interrupts? 
>
>Actually, it often means you *must* run the comms off interrupts, 
>because the rest of the program will be so busy doing other things that 
>you can't afford polling for new data on the serial ports.  You'll 
>typically need some circular buffering between the serial ports and the 
>main application.
>
>Polling only really works well if the program does not much else than 
>handle communication.  If it's supposed to also get some "real" work 
>done on the side, polling tends to turn into an excessive burden.
>
>> 1 - Recommended resources (books, websites) that will help me with the
>> fundamentals.
>
>It doesn't directly match your choice of CPU (who made that for you, 
>anyway?)
Don't know. Could have been someone technial, could have been the
accountant!
>, but I consider Michael J. Pont's book "Patterns for 
>Time-Triggered Embedded Systems" a good first choice.  It starts all the 
>way down at the basics (what's a port pin, and how should I use it), and 
>goes quite a long way from there.  Applying what you find in this book 
>to this non-8051 micro might even provide extra didactic value.

Thanks for your help.

On Fri, 06 Apr 2007 21:12:32 GMT, the renowned Rich Webb
<bbew.ar@mapson.nozirev.ten> wrote:

>
>The typical microcontroller UART doesn't have a built-in FIFO so
>you'll be interrupted as each character (not bit) is received. Have
>your serial ISR toss each character into a lightweight queue and the
>foreground process can retrieve them as and when it needs.

I guess you could consider it a one-level FIFO, since you typically
have until the end of the reception of the next character to remove
the character from the register (after that, data is lost). 


Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Spehro Pefhany wrote:
> On Fri, 06 Apr 2007 21:12:32 GMT, the renowned Rich Webb
> <bbew.ar@mapson.nozirev.ten> wrote:
> 
> 
>>The typical microcontroller UART doesn't have a built-in FIFO so
>>you'll be interrupted as each character (not bit) is received. Have
>>your serial ISR toss each character into a lightweight queue and the
>>foreground process can retrieve them as and when it needs.
> 
> 
> I guess you could consider it a one-level FIFO, since you typically
> have until the end of the reception of the next character to remove
> the character from the register (after that, data is lost). 
> 
> 
> Best regards, 
> Spehro Pefhany
Depends on the speed of the UART.

2400 bauds is 4 mSec between bytes. Can get a lot done in 4 mSec.

RTOS, we don't need no stink'n RTOS.

What's in the design spec ??

donald