Subj : Re: Need to write putchar for embedded system
To   : comp.lang.c,comp.programming
From : Old Wolf
Date : Sat Jul 09 2005 03:52 pm

Confused User wrote:
> 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?

The C standard allows for embedded systems (aka. freestanding
implementations), and they aren't required to implement
any of the I/O functions in the C library.

>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.

68HC16s don't know anything about serial ports, so why would
they bother?

You should write your data to a buffer with sprintf or some other
method, and then send that buffer to the serial port, using a
function specifically designed for writing to serial ports.

> I noticed from looking around that putchar returns EOF if unsuccessful. E=
OF
> 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?
> 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.

getchar and putchar work with unsigned values (ie. the range 0-255,
if you have 8-bit chars). You should cast signed chars to unsigned
before passing them to 'putchar', eg:

  char *p, *str =3D "h=E9llo";
  for (p =3D str; *p; ++p)
     putchar( (unsigned char) *p );


> As an embedded programmer, I am not real familiar with what normal pass/f=
ail
> return codes should be.

Use your serial port functions, rather than trying to muck around
with someone else's standard library. Who knows, the next version of
your compiler might change something internally that will render
your customised putchar useless.

> 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.

Embedded compilers try to comply with the C standard for
freestanding implementations. Read it, if you have a few spare hours.

.