[En-Nut-Discussion] Dual rs232<->Ethernet

[Ulrich Prinz]

Hi!

Only had a short look into your code:

You should set NutThreadSetPriority() inside the Threads. Probably the 
same priority for all of them. You should not rise the main() routines 
priority to 128. Background is, that NutThreadSetPriority() sets the 
priority of the task it is called from. And calling it in main will 
modify the prio of the main task, that is doing nothing in your application.

So delete line 143 and do a NutSleep(5000), or if you have a blinking 
LED for giving an 'alive' signal, toggle it there and do a NutSleep( 
1000) there.
Insert NutThreadSetPriority(50) in the two tasks before going into the 
main loop of the task ( i.e. for(;;) {) at lines 54 and 74.
So all four tasks have same priority and are called round and round.

You're using NutThreadYeald() so, if this function is reached, the 
thread releases the CPU to the next waiting thread. This will normally 
lead to the same result than giving all tasks the same priority. 
Remember that if there is only one thread with a higher priority, it 
will always be the next called every NutThreadYeald(). Therefore it is 
better to actively set priorities.

You do not do any buffer checking. So if one of the receiving or sending 
queues is running out of buffer, you have no chance to react.
To find out, what is happening on the crashes, you should enable some 
debug and may be constantly printf your free memory.
You could add a line of code in StreamCopy() to check if the 
buff=malloc() did return something != NULL, as NULL means that there was 
not enough memory to reserve as requested.
Put a debug inside to see if that condition happens.

And, I think, if a free(NULL) is issued, something crashes. I am not 
sure, but put that while(){} loop inside an:
if( buff) {
   loop
}
else {
   Debug() <- could be printf("No MEM!\n")
   free(buff)
}

If the debug comes, you know two things:
1) You run into conditions, where no memory is available anymore
2) I was was wrong and the free(buff) can be called when the malloc 
failed and buff is NULL.

If it still crashes, and there is only a part of the debug or no debug, 
add a
fflush( stdout) behind the debug and try again.
If now the debug comes, you put free(buff) out of else into if and if 
now debug works you have only one problem left:
You need to find out, why now the system does not crash, but looses data 
cause there are no buffers available.

Please check the behavior of fread. I am mixing that up often, but there 
are functions that _wait_ for data to arrive and have a timeout and are 
blocking and there are ones that take what is available and do not block 
if there is no data available.
So if you use one of the blocking ones to read from usart or network, 
the buffer of the other thread may fill up, while the thread is waiting, 
blocked by the active thread.
It is better to use the non-blocking function or set a timeout of a very 
low to nothing value for the blocking ones. So you will more often 
switch from one task to the other but you work with smaller buffers and 
higher 'sampling' of data to transfer.

Best regards
Ulrich

asdus schrieb:
> Hi all!
> After some tries I'm get fully workable code. You can see that here:
> http://pastebin.mozilla-russia.org/102504
> 
> But I still have rare freezes, and need to manually reset my device.
> Have a chance to resolve this?
> 
> 2009/10/27 asdus <asdusik at gmail.com>:
>> Hi all.
>> For my home automation i need to use 2 rs232<->ethernet converters
>> I'm buy Ethernut V 1.3 H board and try to make it, using rs232d, Basic
>> TCP Server and Serial Port Monitor examples.
>> Using that i need to do this in dedicated threads, because i'm use
>> other ethernut's digital pins to get home events. All my tries fails,
>> i have lags using my remote rs232's.
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion