Subj : Re: Need to write putchar for embedded system
To   : comp.lang.c,comp.programming
From : gordonb.bd89v
Date : Fri Jul 01 2005 03:35 am

>I am working on device that utilizes a Motorola 68HC16 microcontroller. I am
>using an old unsupported piece of crap Whitesmith's / Intermetrics / Tasking
>compiler. The embedded compiler business was quite insestual for while
>wasn't it? I need to write putchar so that printf can function properly.

>Anyway, the compiler comes with just a shell of a putchar routine. It
>literally returns the character you passed to it and nothing else. That is
>not why it's a piece of crap, although they could have at least supplied
>something that writes to the serial port.

Well, that assumes that everyone uses the serial port and not, for
example, a keypad and 8-character LCD display, which I suppose
someone could attach to this thing if, for example, it's going to
run a microwave oven.

>So, I already have a serial port interrupt routing with circular buffers
>(in/out) and a function call (SendData()) that copies a data from a pointer
>argument and manages the circular buffer. So, I want to have my putchar
>routine call SendData.

>I noticed from looking around that putchar returns EOF if unsuccessful. EOF
>is defined as -1 in the compiler header file. Therefore, it occurs to me
>that putchar can only be used for ASCII data. This is OK, I just need to
>make sure I have that right. Because, binary data could include -1 right?

putchar() can return -1 for EOF and (unsigned char)c for a character.
Assuming that an int (must be at least 16 bits) has more bits than
a char (must be at least 8 bits, but could be 16 or 32), there is
no ambiguity here.  Oh, yes, hardly anyone bothers to look at the
return value of putchar() anyway.

>That means I should never use it alone to send binary data. If so, is this
>true for the PC? After all, it's counterpart, getchar retrives binary scan
>codes from the keyboard unless they have already been converted to ASCII
>characters before they get to that level.

I don't know of any implementation in which getchar() returns scan
codes unless you do something system-dependent, non-default, and
obnoxious to cause that.  Scan codes aren't characters.  You need
to combine the scan code(s) with shift states to get actual characters.

>I would guess the only time getchar should return EOF is if the transmit
>buffer is full. 

No.  getchar() should return EOF if the implementation-defined
end-of-file character is typed, if there even is such a character.
Or perhaps if DCD drops.  Depending on what you are using it for,
a version of getchar() which *NEVER* returns EOF could be fine.

putchar() should return EOF, well, almost never.  Maybe if CTS
drops.  It should NOT return EOF because the program is sending
data faster than you can get it out the serial port.  In that
situation it should WAIT.  This could get complicated in a multi-tasking
system where an interrupt that there is space in the buffer causes
a thread/process/whatever to wake up.  In a uni-tasking situation
it's easy:  busy wait for the buffer to become free, then send the
character.

>My SendData() function already is set to return a fail code
>if the buffer is full. putchar can pass this on to printf (of course I have
>to change SendData() to use EOF as a fail code).

No, you don't have to change SendData() to use EOF as a buffer-full code.
In putchar():
	if (SendData(foo) == ERROR_BUFFER_FULL) return EOF;

Buffer full is not an error condition.  Assuming you've got a
processor that's less slow than pitiful for 20 years ago (e.g.
100*K*Hz), any attempts to send a line of data bigger than the
buffer size (16 characters?) is going to fill the buffer almost
immediately.

>As an embedded programmer, I am not real familiar with what normal pass/fail
>return codes should be. The high level languages were developed around full
>OS systems (Unix etc.) and then seem to have migrated to the embedded world
>leaving some us without familiarity of conventions.
>
>Enough rambling.... Just looking for any constructive input.

ANSI/ISO C does not have non-blocking I/O.  That means you can't, using
standard routines, wait to output something while scanning for input
on something else.  You might end up needing non-standard non-blocking
routines for the serial port, depending on what you need to do.
(SendData() might serve this purpose well as-is).

It also means that getchar() and putchar() need to be written as
blocking.

						Gordon L. Burditt

.