Hi Miklos,
Thanks for the clarification !
>> Every Ieee154 user should do that manually.
I could imagine this way of managing exclusive access to the send
resource. It is now clear for me that it is up to the user code to
request and lock the send resource before Ieee154Send.send() and to
release it when appropriate.
>> I do not know what is the right solution.
I think there is no problem with the current solution if the user
knows that he *must* acquire the send resource beforehand. This is
more flexible than automatic resource allocation and gives better
control to the user/programmer.
With this in mind I go ahead with my stack implementation... Thanks
for the prompt and advised help !
Romain
On Tue, Jul 12, 2011 at 3:17 PM, Miklos Maroti <[email protected]> wrote:
> Hi Romain,
>
> That is a very good question! Ideally, a send resource should be
> acquired before your Send.send call, and therefore the stack could
> always return SUCCESS from send.Send. However, it is believed that
> that would be complicated for users. As it is now, ActiveMessageC will
> automatically acquire the resource, and Ieee154MessageC will not.
> Every Ieee154 user should do that manually. If you want to support
> auto acquire of the resource for both, then you need two instances
> which will save the message to be sent if the resource is busy. I do
> not know what is the right solution.
>
> Best,
> Miklos
>
>
> On Tue, Jul 12, 2011 at 11:47 AM, Romain Bornet <[email protected]> wrote:
>> Hi,
>>
>> As some of you on the list may already know I'm porting TinyOS to a
>> new CPU architecture and I'm currently working on the radio stack for
>> my chip. I decided to go on with the rfxlink stack and took the RF230,
>> RF212 and CC2420x as references.
>> To better understand the complete wiring of the stack I generated the
>> nesdoc for BaseStation compiled for the iris platform with default
>> build parameters (no change in Makefiles or on the build command line.
>> Simply make iris docs) and had a look at the wiring schema for
>> RF230RadioC.nc.
>>
>> In the case where both TFRAMES_ENABLED and IEEE154FRAMES_ENABLED are
>> not defined (default configuration) should we not wire
>> Ieee154MessageLayerC.SubSend to AutoResourceAcquireLayerC instead of
>> wiring it directly to the TinyosNetworkLayerC ?
>>
>> I think that with the current wiring in RF230RadioC.nc the
>> Ieee154MessageLayerC won't take part to the arbitration process...?
>> Is this correct or am I missing something ?
>>
>> Regards
>> Romain
>>
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
