RE: Newlib : stdio : fprintf and sprintf - not faulty - buffer-based pipes needed.

["Bin Cheng" <bin dot cheng at arm dot com>]

> -----Original Message-----
> From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org] On
> Behalf Of J.B.W.Webber
> Sent: Wednesday, June 12, 2013 6:45 PM
> To: newlib@sourceware.org
> Subject: RE: Newlib : stdio : fprintf and sprintf - not faulty -
buffer-based
> pipes needed.
> 
> My apologies,
> I have no idea at the moment why fprintf was not outputting, in the
Parallella
> e-run simulator, for Parallella-Linux generated code for the Epiphany.
> 
> However sprint in the code, run actually on the Epiphany cores, does
output
> fine, correctly outputting to the communication buffer. i.e. :
>   0: Message from eCore 0x8ca ( 3, 2): "some text Qsome text 1 2 3 4 5 6 7
8 9
>  45
> "
>   1: Message from eCore 0x84b ( 1, 3): "some text Qsome text 1 2 3 4 5 6 7
8 9
>  45
> "
> Etc.
> The problem was a too-short delay before the Linux host read the buffer.
It is
> a very crude temporary interface.
> 
> Thus this aplc APL to C code translator is at least partially ported to
the
> Parallella and Epiphany cores.
> 
> If anyone knows how to create Std-in Std-out (and generic pipes) based on
> buffers on the Epiphany chip, with proper synchronisation, I would much
> appreciate receiving comments, examples or working code. This exceeds my
> remaining knowledge of c (~1980 - ~1990) or my understanding of newlib.

Hi,
Both the problem and system are beyond my knowledge and I don't have answer
for it.  Maybe you can re-build newlib (even with -O0) and debug it along
with your application.  I have much confidence in fprintf implementation of
newlib (since it works elsewhere), so I suspect the problem might be in
application-library interface or something like that.

Thanks.
bin