[libopenstm32-devel] sbrk_r write_r open_r, et al, buffered uart, printf

[Marko K. <ma...@el...>]

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