[En-Nut-Discussion] Correction to previous post and more info

[Harald Kipp]

Kyle,

Sorry for the late response.

Regarding your earlier post:

>   size_t retVal;

...

>     retVal = fread(&cptr[numRead], 1, size - numRead, fp);
>
>     if(retVal < 0)
>       return(retVal);

If I'm not wrong, the if condition is always false,
because retVal's type of size_t is unsigned and
thus retVal can never be lower than zero.

You also mentioned, that you do never expect fread()
to fail with an error. This assumption is wrong.
Running out of memory may be one cause to let this
(and most other functions) fail.

Furthermore, fread() will never return -1. In case of
an error it returns 0. The lower level _read() function
used by fread() may return -1, in which case fread()
returns 0.

In general it is very difficult to determine, wether the
problem is caused by Nut/OS or your application code.
The AVRs do not provide memory protection. Your code
may destroy part of the RAM used by the system, what
makes the system look like faulty, but actually the
application caused this trouble.

If you assume an API problem, it's always a good idea
to create a bare minimum code sample and post it
completely. Like with your example, I do not know anything
about dihPtr.

Another cause may be lack of stack space. It may work
hundreds of times and suddenly fail, because an interrupt
routine uses 20 Bytes of stack, when nothing is available.
This problem is discussed in
http://www.ethernut.de/pdf/enmem100.pdf

Following your later post, I don't agree that fread is
prepared to be called with a NULL buffer pointer. At
least checking fread.c, I can see, that any pending
unget would write to the NULL pointer. This will overwrite
the ATmega registers due to the special memory structure of
the AVRs. The compiler's runtime library expects R1 filled
with zero, all the time. Strange things will happen if R1
receives any other value.

Indeed _read(fd, 0, 0) will flush the input buffer. This
is some kind of hack and incompatible with other runtime
libraries. Unfortunately Nut/OS's fflush() does work on
output only. Something has to be done here.

Finally, no one can guarantee, that the serial driver is
free of bugs. But we are extensively using it in several
applications without any problem. So it is very likely,
that your problems are caused by side effects from other
parts of the application (or system).

Your opinions and questions are most welcome.

Harald