[libopenstm32-devel] sbrk_r write_r open_r, et al, buffered uart, printf
Status: Inactive
Brought to you by:
uh1763
From: Marko K. <ma...@el...> - 2011-09-17 12:14:02
|
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 |