Re: [uracoli-devel] radio_set_state(): how long to wait?

[uracolix]

What I don't want is, to add a timer mechanism for libradio, this makes it to 
complicated for use and requires to link a part of libioutil. . I think just a 
poll function would be fine.

Am Sonntag, 29. November 2009 21:19:43 schrieb Joerg Wunsch:
> However, there's a second issue with the current code: while the code
> is aware of waiting for approximately one frame transmission
> (including the time required for the preamble), this only covers the
> basic operation mode of the transceiver.  In case the transceiver is
> currently in extended operation mode (in particular, in STATE_TXAUTO
> where the entire operation might involve several CSMA-CA backoffs and
> frame retries), it will still wait much too short.

I agree, the CSMA backoff times can get very long, up to 
(2^8 -1) * 20 * 0.4ms * CSMA_RETRY ~ 2s * CSMA_RETRY
... no way for any blocking function here.

> That's already what radio_force_state() is good for. ;-)

... oops, I have to read the documentation ... 

> > and return STATE_CHANGE_IN_PROGRESS.
> That might be an idea.
Ok, lets add this.


> I also thought about adding a timeout parameter to the function
> itself, so the user can select how long to wait.  But first, this
> would change the API, and second, it doesn't help in case of a
> library-initiated state change (in order to turn the transceiver into
> the configured "idle state").

To give a max wait time would be fine, changing the API is not that 
issue, since I believe that not many people use it till now.

>
> > Two questions now arises:
> >  - How do deal with radio_set_state(SLEEP, 0); ?
>
> Another return value indicating a state transition failure in case the
> transceiver was currently busy, i.e. could not turned into TRX_OFF
> state before trying to go asleep?

Sounds good, the usage could be so:

// wait 1ms, maybe transition happens
while(radio_set_state(SLEEP,1ms)  != SUCCESS) 
{
        // sleep a while, and have a look later
        avr_sleep(1ms);
}

>
> Thinking more about it, I think usr_radio_error() should probably not
> called by radio_set_state() itself, because the user always can verify
> the result.  usr_radio_error() is only needed for a library-initiated
> state transition.

Ok, I see, this could be the case for radio_send_frame() 

>
> >  - Does  an awake state change should wait until TRX_OFF is reached?
> Well, it depends...  For more modern transceivers, the CPU could sleep
> until the AWAKE interrupt occurs.  However, I wouldn't want to have
> radio_set_state() itself make the CPU sleep.  I've got no real idea
> for an ideal solution here.

Generally spoken, the transceivers are missing a "state change completed 
IRQ", it is the general form of the AWAKE_END_IRQ. This IRQ could save all
the polling.