AW: AW: [En-Nut-Discussion] fprintf() on streamed TCP socket

[Oliver Schulz]

Hi Dusan,

uhh, it's gona be little bit tricky now. I have the suspicion, that
something with the %P formating char in printf is wrong.
If the character output function (in this case NutTcpDeviceWrite) for the
associated device is called with parameter count set to zero, the function
perform an output buffer flush. (BTW, fflush does nothing else but calls
_write with zero length.)

I will test this now and give you results as soon as possible. Probably I
will commit a corrected crt/putf.c this evening.

Cheers,
Oliver.

> -----Ursprungliche Nachricht-----
> Von: en-nut-discussion-bounces at egnite.de
> [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von
> Dusan Ferbas
> Gesendet: Freitag, 12. Dezember 2003 14:40
> An: en-nut-discussion at egnite.de
> Betreff: Re: AW: [En-Nut-Discussion] fprintf() on streamed TCP socket
>
>
> Hi Oliver,
>
> we modified tcpsock.c to work with our values:
> #define BUF_ALLOC       (1500-40)               //buffer size
> #define BUF_LIMIT       (BUF_ALLOC/2-10)        //buffer
> creation threshold
>
> But if we are using %P result is packet shortage. Once we
> change %P to %s
> and change string placement from .progmem.data to .data
> packets are fine.
>
> Any idea ?
>
>
> Dusan
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion