[Tinyos-help] A question for serial stack!

Philip Levis pal at cs.stanford.edu
Fri Jul 31 14:05:36 PDT 2009


On Jul 30, 2009, at 10:00 AM, peng li wrote:

> Hi There
>
> Currently, I am testing a simulation tool , and in the testing for
> serial part, I think I met a potential problem for  
> SerialDispatcherP.nc,
> the concrete description is as follows:
>
> Since this component provides two buffering in order to make the  
> system
> not miss the incoming byte stream.
>
> 1. The initial buffer is 0, which is unlocked, then buffer 0 can  
> receive
> the byte stream successfully. Once the byte stream is end  
> successfully,
> then the buffer is switched to 1, and the handling of buffer 0 is
> postponed into a task. (Note: currently, buffer 0 is still locked,  
> once
> the task is scheduled, the lock can be released)
>
> 2. In my test, before the task for dealing with buffer 0 is scheduled,
> another byte stream is coming. Since current buffer has been  
> switched to
> Buffer 1, which is unlocked, hence buffer 1 should receive these bytes
> successfully, but in my test, it is not.
>
> Then I checked the code of SerialDispatcherP.nc, I found the function
> below seems not right:
>
> bool isCurrentBufferLocked() {
>   return (receiveState.which)? receiveState.bufZeroLocked :
> receiveState.bufOneLocked;
> }
>
> I think the zero and one branches may be backwards, going back to the
> procedure above, since receiveState.which has been set to 1, but it
> still returns the state of buffer zero and vice versa, this is the  
> cause
> why buffer 1 can not receive the byte streams.
>
> I am not very sure whether my analysis is right and reasonable, thus I
> need your help! Thanks a lot!
>
> Regards

This is worth looking at. I have a bunch of TinyOS things to look at;  
I'd hoped to this week, but other to-do items got in the way. I'll try  
to look next week.

Phil



More information about the Tinyos-help mailing list