Hi - in older revisions of libopenstm32, use of some functions would
call these [sbrk_r, open_r, read_r, write_r and so on], which would then
fail as they were undefined.
The other day I upgraded to current rev, and things that call these (in
my case gmtime_r() ) no longer fail on compile - but they still don't
work. I didn't have debug, but the MCU became non-responsive as soon as
it hit the call. grepping the source didn't seem to give me any clues
where they were defined - any ideas?
Also recently, I wrote up a bit of code that buffers the UARTs, both
send and receive. There are routines to fill/pull data from the
ringbuffers, and the UART side is all interrupt driven. I got the idea
from a similar library I had used on AVRs in the past. I can clean it up
and submit it if anyone is interested.
Now, at this point I decided to upgrade to trunk, as mentioned earlier.
Of course I then saw the new example usart_irq_printf, which was
basically what I was going for in the above (although I don't think it
buffered RX)... All this seemed to do for me (compiled for the
stm32vl-discovery) was hang and use ungodly amounts of flash, something
like 30k IIRC. (I'm presuming this is related to heavyweight printf, and
sbrk_r or whatever it calls, which goes back to the start of this post).
Perhaps someone who has ran this on a F103 as the example can give me a
hint.
In my past experience with AVR GCC, they have a file stream setup, and
stripped down printf functions, so you can fprintf to fd, which I could
link to my uart deal above. I guess I could look into porting some of
that, I'm not sure how involved it is.
I'm just looking for comments about whether such functions are
worthwhile for the project - I can't see myself being the only one that
would like them, but you never know. And some ideas on implementation
would be nice. Or, if someone has already worked along similar lines,
there's no sense in me doing so.
Thanks guys, keep up the good work... :)
mark
|
