but AM does not necessarily send packets in the order at which you submit
them :
does this apply even when I give the next send in the send-done event
of the first call ?
I'm aksing this bcos I want some kind of time-stamping to go with the
msgs ...that is I want to read the msgs at the time in which they were
ready( I basically want to time the various processes) and thats what
the listener is supposed to do, receive msg that the processes send
and print the msg at the time @ which it received it thereby telling
me how long each of the processes took to get done
I guess if i implement it in the Q way the listener is going to just
print the msgs sequentially from the Q, say with a time delay of one
second and so the actual timing of the processes wld be lost( since
i'm printing time in the listener window)
I tried appending time-information(of the local system) in the msgs,
somehow that didnt seem to work properly for me and thats why the
time-setting is in Listener
If i can get to do this, then I can use the Q way i guess
and I was still stumped why the listener didnt get any packet even
when i was doing only one send from SerialAmSenderC or AmSenderC
it worked perfectly with the testserial app, the only difference i cld
see was in my program they were in boot call and in Test app in the
timer call
I'm also unable to use TestSerial.h or even my own pre-defined header
file for the timing data structure in any other component : got a
syntax error for the typedef calls inside them
Thanks
Bhuvana
On 3/27/07, Philip Levis <[EMAIL PROTECTED]> wrote:
On Mar 27, 2007, at 12:15 PM, Bhuvaneswari Ramkumar wrote:
> I do want it in a queue but i guess I cant use the ForwardEngine
> component
> what this one seems to be doing is take pre-determined packets from a
> queue and send them in FIFO order
You probably don't want to use this exact component; I just suggested
it as an example of how you can manage a send queue (which is what
you want).
>
> what I want is some function calls to be executed and a send to be
> done after every few of them are done , transmitting as a message the
> result of the function call itself
> so the second send should actually wait for the packet to be filled
> with the result of the process say P2 and not as in ForwardEngine
> where the packets are there and need to be just queued for sending
> bcos funtion call P2 depends on P1 , P3 on P2 ( just the process P2 ,
> not its send )
> that is these are all dependent processes, taking as its input the
> result of the previous process execution( & not its transmission or
> reception )
>
> so i dont know if i have a choice other than using multipe send
> instances
> what I think i should be doing is some thing like this :
>
> event 1
> {
> process P1
> send P1
> }
>
> P1.senddone
> {
>
> process P2
> send p2
> }
>
> P2.sendone
> {
> process P3
> send P3
> }
>
> and so on sequentially
>
> I'm not sure if i have a choice here
Of course you do. Try this:
taskA {
process P1
put P1 in the queue
post taskB
}
taskB {
process P2
put P2 in the queue
post taskC
}
task C{
process P3
put P3 in the queue
}
put in queue function:
put(m) {
if queue empty
post send task
queue.append(m)
}
sendTask {
m = queue.getNext();
call Send.send(m)
}
sendDone {
if queue not empty
m = queue.getNext()
call Send.send(m)
}
The tasks A, B, and C are so you don't run too long and make TinyOS
unhappy (I have no idea how long your P1, P2, P3 are).
I mean, if you instantiate three senders, then all the AM layer is
doing is allocating three entries in its own send queue... but AM
does not necessarily send packets in the order at which you submit
them, so if you have an ordering requirement just instantiating three
AMSenderC components may cause you trouble.
Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
