use of stdin

This is a discussion on use of stdin within the C Programming forums, part of the General Programming Boards category; Hi, I was reading this article http://cboard.cprogramming.com/showp...37&postcount=9 about using fgets and scanf to read output, and suggests using fgets with ...

  1. #1
    Embedded in C...
    Join Date
    Sep 2008
    Location
    Basingstoke, Hampshire
    Posts
    83

    use of stdin

    Hi,

    I was reading this article

    Need help with altering info on a txt file

    about using fgets and scanf to read output, and suggests using fgets with stdin as an argument stating that stdin takes input from the keyboard by default.

    How would you change this default behaviour to read input from a microcontroller UART, for example ?

    Is this something in the C code, or should I be looking more toward the microcontroller specification?

    --dave

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Embedded in C...
    Join Date
    Sep 2008
    Location
    Basingstoke, Hampshire
    Posts
    83
    That makes complete sense, thanks - I will look at my microcontroller spec and see how to implement it

    --dave

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by droseman View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Registered User
    Join Date
    Sep 2008
    Location
    Toronto, Canada
    Posts
    1,832
    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.

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by nonoob View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Embedded in C...
    Join Date
    Sep 2008
    Location
    Basingstoke, Hampshire
    Posts
    83
    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
    Last edited by droseman; 09-26-2008 at 08:58 AM.

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by droseman View Post
    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
    Last edited by matsp; 09-26-2008 at 09:23 AM.
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Registered User
    Join Date
    Sep 2008
    Location
    Toronto, Canada
    Posts
    1,832
    I see I'm going to have trouble with matsp. ;-)

    Other than command line piping from/to CON, PRN, or who knows what else is in vogue these days, which redirects standard input & output, (or fancy "reopen" to override default IO handles), and barring any complications in setting up a microcontroller's UART (you have to do that someplace by golly), then I don't see how one can leave any of the standard I/O functions in place. And why do so? 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.

  10. #10
    Jack of many languages Dino's Avatar
    Join Date
    Nov 2007
    Location
    Katy, Texas
    Posts
    2,309
    Quote Originally Posted by nonoob View Post
    I see I'm going to have trouble with matsp. ;-)
    CAT FIGHT!
    Mac and Windows cross platform programmer. Ruby lover.

    Quote of the Day
    12/20: Mario F.:I never was, am not, and never will be, one to shut up in the face of something I think is fundamentally wrong.

    Amen brother!

  11. #11
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by nonoob View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  12. #12
    Registered User
    Join Date
    Sep 2008
    Location
    Toronto, Canada
    Posts
    1,832
    Not yet, Dino.

    I'm only going from what I've done in the past. Either use printf if screen output (or piped output to a file) is OK,

    OR

    if you want to use a UART then roll-your-own functions where you can have full reign of flow-control, buffering, toggling other indicators when interfacing to external hardware, setting up oddball baud rates, etc. I was not aware that you can use all the usual stdio functions and somehow sneak in a low-level layer someplace. I think I would have used that if it existed at the time.

  13. #13
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  14. #14
    Registered User
    Join Date
    Sep 2008
    Location
    Toronto, Canada
    Posts
    1,832
    That's a very good summarization. droseman being a hardware engineer will probably appreciate that... Both your and my explanations have "met in the middle" so to speak.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Checking stdin for input
    By hawaiian robots in forum C Programming
    Replies: 7
    Last Post: 05-19-2009, 10:06 AM
  2. Another syntax error
    By caldeira in forum C Programming
    Replies: 31
    Last Post: 09-05-2008, 02:01 AM
  3. Replies: 2
    Last Post: 07-12-2008, 01:00 PM
  4. value of stdin (not zero?)
    By taisao in forum Linux Programming
    Replies: 3
    Last Post: 05-27-2007, 09:14 AM
  5. stdin question
    By oomen3 in forum C Programming
    Replies: 6
    Last Post: 02-19-2003, 02:52 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21