[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [uracoli-devel] radio_set_state(): how long to wait?
From: |
uracolix |
Subject: |
Re: [uracoli-devel] radio_set_state(): how long to wait? |
Date: |
Sun, 29 Nov 2009 22:18:45 +0100 |
User-agent: |
KMail/1.9.9 |
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.