FDEV_SETUP_STREAM() and F_CPU questions

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Man,

So it's been over a year since i've used wiiAVR and so much has changed lol

anyway.. i'm freaking confused..

so i'm using winAVR.

I use to use fdevopen(); in the past to get my LCDs to work with printf.

It appears that has all changed now..

I'm looking at some sample code stdiodemo.c which comes with winAVR. i don't really understand how they're using FDEV_SETUP_STREAM.. can someone run me through this..

what is the FILE type?? why do i need that..

last..

so. if i want to use the delay library, all i have to do is set define F_CPU? is there anything else i should do aside from including the delay header??

thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Check out this thread.

FILE is really just a dummy, you don't need t worry about it except in the declaration of the parameters.

Quote:
if i want to use the delay library, all i have to do is set define F_CPU? is there anything else i should do aside from including the delay header??

No. But you should keep in mind a couple of things. You should keep the parameter of _delay_us() and _delay_ms() constants. Doing so will ensure that all the floating point math will fall out during compile time. Also pay attention to the limitations on the value. For instance, the maximum value for _delay_ms() is 262.14 ms / MHz of the cpu clock. So if you are running at 8MHz, the maximum delay is 32.767ms.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

intersting..

thanks for the reply..

do you know if it's possible to change printf at run time to work with different devices??

i don't need to do that.. but it would be cool if i coudl.. i guess the thing is.. i'm not too familiar with all this file stream stuff..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The file stream stuff is designed to emulate as much of C's standard I/O stream operation as possible, given the constraint that there really aren't any operating system services as such available to provide real "files".

It is possible to change the printf target at runtime. Keep in mind that the system has two critical FILE pointers to keep in mind when you want to redirect printf/scanf: stdin for input, and and stdout for output. Whichever stream happens to be pointed to by stdout, will be the stream that printf() will direct its output to.

You can open several streams, using several invocations of fdevopen or FDEV_SETUP_STREAM (or combinations of the two), and remember pointers to each of them; then all you need to do is re-assign stdout to point to whichever stream you want printf() to work with. Note that you cannot "close" a stream that was opened with the FDEV_SETUP_STREAM macro.

Alternatively, you can use fprintf() instead, and explicitly include a pointer to the stream you want to work with in each incovation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cool.. okay.. well you gave me some stuff to experiment with now.. thanks a lot.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finally, you could use the second (the FILE *) parameter of the output
function to differentiate between multiple different streams: that's
exactly what it has been added for. You are not supposed to
manipulate the object it is pointing to directly, but you've got the
fdev_set_udata() and fdev_get_udata() macros for that purpose.

That way, if you e. g. have two USARTs in your CPU, and want to
associate it with two stdio streams, you could use the same backend
function but make it decide which set of IO registers to use based on
the user data supplied to the FILE stream.

Of course, if one of your streams points to a USART, and another one
to an LCD, that wouldn't make much sense. You can have a look at the
stdiodemo of the library for the latter thing.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.