Thread: use of stdin

In a microcontroller system, stdin may well be (one of) the UART's. It is after all called "stdin" as in the "standard input channel", not "conin" as in "the console input channel". So it is whatever the system considers "the normal place to receive input from". In the early days of C, stdin was very likely a serial terminal connected to a Unix system, so there's absolutely nothing stopping this from a conceptual perspective.

Of course, you will need an interface between the FILE functions and the serial port driver. This is very much dependant on the OS and C runtime architecture, and thus an implementation detail.

--
Mats

Originally Posted by droseman

That makes complete sense, thanks - I will look at my microcontroller spec and see how to implement it

--dave

Your bigger part of that will be figuring out how the stdio functionality works inside the C library, I would thing. Getting a serial port working is fairly easy, but interfacing to the standard FILE I/O interface can get a bit trickier.

--
Mats

Originally Posted by nonoob

I don't think changing default behaviors of fgets and scanf is the answer. If you are looking to interface to microcontoller UART you may need to have separate functions - which in turn do some low-level tweaking of hardware registers. I may be wrong but I don't think leaving the layer of standard I/O functions in-place, and just slipping in a different low-level interface underneath them is a good idea. Who knows what sorts of buffering or rollback options they provide, which may break now. I hate working with black boxes.

But it should be perfectly possible for the C library to have a base-IO interface that can be connected to anything - in particular when the compiler is intended for a embeded market.

It should not be a case of rewriting the upper layers of stdio.h functionality, but the low-level, "behind the scenes" functions. This will of course rely on the interface of the base-IO layer being documented by the library/compiler provider.

If that isn't the case, you can write your own printf-like function using vsprintf() to produce an output string, and then send that string to your own low-level IO function.

--
Mats

But it should be perfectly possible for the C library to have a base-IO interface that can be connected to anything - in particular when the compiler is intended for a embeded market.

It is indeed an embedded compiler I will be using - the Keil compiler for the STM32 ARM cortex chip. I haven't had chance to look through that yet, still learning some language basics.

the last posts confused me, as I am just a hardware engineer still

--dave

Originally Posted by droseman

Ithe last posts confused me, as I am just a hardware engineer still

--dave

If you explain which part has you confused, I can perhaps explain more.

I had a quick look at the Keil library docs online, and it certainly looks like they have a decent set of _sys_XXXX functions to implement low-level I/O functions. It wouldn't surprise me if there is a pre-defined set that work with the serial port already, but I didn't get far enough to determine that for sure.

--
Mats

Originally Posted by nonoob

I see I'm going to have trouble with matsp. ;-)

CAT FIGHT!

Originally Posted by nonoob

Maybe to avoid needing to rewrite a lot of existing code... but then I/O of this nature should have been segregated into a special part of the code anyhow.

And how many programs have you seen that are scattered with printf, scanf, fgets, etc, etc? Many, many programs do not wrap printf with it's own wrapper, as far as I know.

Likewise for those using cout/cin.

So if you need to "port" one of these applications, then usign stdio functions is a very simple port (you just need to implement the base-IO functions to support the UART or whatever it may be - but nearly all that work has to be done anyways).

If on the other hand, you implement your own IO functions, you need to change every printf, scanf, etc to your own corresponding functions. Not only does this mean work, but you are probably also going to make mistakes when doing so, and this leads to more work in finding out why the result you print is wrong.

Having a standard library is a good thing. If you don't want to use it, fine, just use the low-level functions directly. If you want to use it, then you have all the standard functions to use. Makes life easy.

--
Mats

Well, obviously you need to have a C library that is written with the intention of interfacing to the hardware that way. But at some point or another, most stdio functions end up in something resembling Unix's open, read, write, lseek and close. There may be some stuff in between

As to setting baudrates and such (at least when using it for console operations), that's normally something you do very early on in the system initialization. You could do it as part of the opening of the console (or, if the hardware allows you to poll the serial input pin, determine the baudrate based on a lower or upper case A for example).

And of course, if you aren't using the serial port for console I/O, but for example communicating using a protocol with checksums and such things, then you would normally use a dedicated set of driver functions for that purpose. Using printf or putchar to implement a protocol is neither efficient, nor particularly practical or useful. Much better to have an interface that takes a payload and adds the packaging and then sends the packet to the serial port as one lump (of course, you may need to hold a buffer and put one or a few bytes at the time to the actual uart).

--
Mats