Re: [Tinyos-help] Simple Hardware Interrupt
Strangely enough I too am "...creating a ultrasound ranger as a..." I've got a ping signal going to INT3 of a mica2 and need to figure out how to write an interrupt handler for it. I want to get one of the timers running real fast and use it to time the spacing of multiple ping interrupts to locate a mobile robot. It looks like there are two defines that get used for this TOSH_INTERRUPT and TOSH_SIGNAL examples of which can seen in, e.g.: tos\platform\mica2\HPLUART0M.nc What's the difference I have no idea yet. The actual signals and vectors are defined in: cygwin\usr\local\avr\include\avr\iom128.h Details of enabling ints on various pins is covered in the ATMEGA manual. You can see the setup for the UART pins in the HPL file. Unfortunately that's about as far as I've gotten, and I have a separate "easier" project that I can use to block any further progress, so it may stay that way for a while... For twiddling regular ATMEGA DIO pins see how these macros are used: TOSH_ASSIGN_PIN() in mica2/hardware.h: TOSH_ASSIGN_PIN(PW7, C, 7); TOSH_MAKE_PW7_OUTPUT(); and used in various places like: TOSH_CLR_PW7() or TOSH_SET_PW7() note that most of the above are generated by generated macros so you will _never_ find the actual definitions and just have to believe that they work. MS Brian Vaughan wrote: I’m creating an ultrasound ranger as part of a more complicated system. I’m creating the actual ultrasound sensor. I need to use the general purpose IO pins from the 51pin connector for two jobs. On one mote I need to send a high or low signal to one of the pins. On the second mote I need to create an interrupt on one of the pins I’m using. I searched through some of the archives and TinyOS documentation and couldn’t find much. There’s lots of support for the ADC stuff, but I don’t want to sample the port. The reaction time needs to be quick and the ADC sampler seems to only poll every 10ms. I’m using the mica2 mote and TinyOS1.15 (or something close to that, not 2.0). So, could someone show me some sample code or point me in the direction of some documentation for this? Or even just give me some keywords to Google. Thanks! ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] unsubscribe
unsubscribe ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] any command for resetting TMOTE SKY
I think you want to implement the WDT watchdog timer to reset the mote automatically after problems. See message number 10518. Regards Simon Davis ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x
On Mar 23, 2007, at 9:43 AM, Avinash Sridharan wrote: Hi Phil, By service rates of a packet I mean the service rate that the queue is giving to each packet. Since the buffer space for the clients and the forwarders are different the probability that you serve a client packet should be lower then the probability that you serve a forwarded packet (assuming both are generating packets at the same rate). Again, you're assuming that the forwarding engine is trying to achieve fairness. It's not. No fixed ratio between those two rates can provide fairness. The assumption is that if you want fairness, you have to have higher-level mechanisms/feedback/rate control/etc. If you do, then you can just control the rate at which packets enter the client queues, and so why should CTP introduce additional logic that is bloat except for this case? I agree fairness is at the flow level but the fair rates that you would calculate for each flow is closely tied to the maximum possible rate that each flow can be serviced at, which in turn is determined by the queuing dynamics. This reasoning leads to my statement " that there seems to be an inherent unfairness in the queuing dynamics ". You're assuming that rate control is independent of servicing rates. It's not. If you decrease the generation rate throughout the entire network, then you can change the ratio between local generation and forwarding. IFRC does this, after all. Also under light loads the above affects might not show up as you stated since if the average queue length of the forwarded packets is going to be close to 1 then all the above dynamics I just described wouldn't come into play. But again this would depend on what you define a "light" load as (what if the average queue length is greater than 1 ?). I mean "light loads" in the traditional sense for this sort of problem, that is, "loads low enough that you do not drop packets from your queues." If every node is generating packets at its fair rate F, and you are not dropping packets, then you have fairness. If you want to control fairness through packet drops, then generally you need to maintain per-child state. Also, given that these are nominally low power networks, the idea of rate control through wasting energy seems a bit questionable. Nevertheless, the Intercept handler allows you to tell CTP to drop packets. So you can control the generation rate, and you can drop packets from the forwarding queue. Please, if there's some piece of functionality that you think the forwarding engine needs but does not understand, state it clearly and succinctly. E.g., "I need a command that tells me the number of forwarding packets in the transmission queue." My objective here was to develop a rate control mechanism on top of the CTP framework and the rates that I was calculating was based on the notion that all flows are treated the same in the queues. However as I mentioned earlier the rates I was getting were coming out to be disproportional, but I concede that the experiments were being carried out at heavy load (all queues were almost fully loaded). Well, under light load, fairness doesn't matter/make any sense. It sounds like you wrote an algorithm that made an incorrect assumption about CTP. You should talk with Om. He is the lead person on CTP, after all, and I suspect his office is not so far from yours... he can probably answer your questions much more completely and quickly than I can. Sumit (also at USC) had a paper in SIGCOMM on fair queueing in wireless sensornets, implemented in TinyOS. You might want to talk with these people to get a sense of the scope of the problem. Phil ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Possible problem in TOSSIM (tinyos-2.x)
Greetings!
My name is Bernardo, I'm a college student and I am new to both tinyOS
and tinyOS community. I have recently tried to update some of my code to
tinyOS-2.x and I have run into a little problem in TOSSIM: no radio message
is sent! I have then started to delve the sourcecodes and after some
analisys I found out that, in TossimPacketModelP.nc, there a function named
send_backoff which might be causing the problem. Please read this function's
implementation so as to understand with more ease what comes next.
There is a function in sim_csma.c called sim_csma_set_max_iterations
which is not called in any of the modules in .../tinyos- 2.x/tos/lib/tossim
and this should initialize this max iteration numbers, which is set to 0 via
( #define SIM_CSMA_MAX_ITERATIONS 0 ). This zero value causes
a loop like that:
1. call send_backoff via event execution (when dequeuing the event)
2. evaluate that sim_csma_set_max_iterations is equal to 0 and thus
increment the backoff in the event.
(line:
else if (sim_csma_max_iterations() == 0 ||
backoffCount <= sim_csma_max_iterations()) {
)
3. enqueue event (which leads to 1 being executed again).
The backoff field is overflow-ed several times and radio communication
never works.
So, why did I comment this here? Well, it happens that I don't know what
to do with this information. I looked for "sim_csma_set_max_iterations" and
I found a CVS update which seemed to have the same problem. Apparently
movind this (sim_csma_max_iterations() == 0) to the first if clause (which
is the one where messages are effectively sent), thins seem to work - I
haven't tested enough, though.
So, what do I do?
Thank you in advance.
Best wishes,
Bernardo
P.S.: Please forgive any inconvenience; I am not used to posting into mail
lists.
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] any Data Aggregation application on Tinyos-2.x?
Hi group, I'm wondering if you know any application using data aggregation which can work on tinyos-2.x. (or can be easily ported to tinyos-2.x). Thanks, ~Hieu ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Simple Hardware Interrupt
I'm creating an ultrasound ranger as part of a more complicated system. I'm creating the actual ultrasound sensor. I need to use the general purpose IO pins from the 51pin connector for two jobs. On one mote I need to send a high or low signal to one of the pins. On the second mote I need to create an interrupt on one of the pins I'm using. I searched through some of the archives and TinyOS documentation and couldn't find much. There's lots of support for the ADC stuff, but I don't want to sample the port. The reaction time needs to be quick and the ADC sampler seems to only poll every 10ms. I'm using the mica2 mote and TinyOS1.15 (or something close to that, not 2.0). So, could someone show me some sample code or point me in the direction of some documentation for this? Or even just give me some keywords to Google. Thanks! ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x
Hi Phil, By service rates of a packet I mean the service rate that the queue is giving to each packet. Since the buffer space for the clients and the forwarders are different the probability that you serve a client packet should be lower then the probability that you serve a forwarded packet (assuming both are generating packets at the same rate). I agree fairness is at the flow level but the fair rates that you would calculate for each flow is closely tied to the maximum possible rate that each flow can be serviced at, which in turn is determined by the queuing dynamics. This reasoning leads to my statement " that there seems to be an inherent unfairness in the queuing dynamics ". Also under light loads the above affects might not show up as you stated since if the average queue length of the forwarded packets is going to be close to 1 then all the above dynamics I just described wouldn't come into play. But again this would depend on what you define a "light" load as (what if the average queue length is greater than 1 ?). My objective here was to develop a rate control mechanism on top of the CTP framework and the rates that I was calculating was based on the notion that all flows are treated the same in the queues. However as I mentioned earlier the rates I was getting were coming out to be disproportional, but I concede that the experiments were being carried out at heavy load (all queues were almost fully loaded). regards, Avinash On 3/23/07, Philip Levis <[EMAIL PROTECTED]> wrote: On Mar 23, 2007, at 9:11 AM, Avinash Sridharan wrote: > Hi Phil, > I agree that if you apply rate control to the client it would > limit the packet generation, but the reason I say the queueing > dynamics would override these affects is that rate control > algorithm assume all packets have the same service rate. I don't understand what you mean by "all packets have the same service rate." Fairness rarely operates in terms of packets; it operates in terms of flows or node pairs. I'm not sure what fair servicing on a packet basis means, as a packet is a singleton. > But since the queue is biased towards the forwarder the service > rate of a client packet will be less than the service rate of a > frowarded packet. Wouldn't the rate allocated to the client have to > take this into account ? Again, I don't understand what you're asking. Are you asking about how you would implement network fairness? Or are you commenting that the current implementation of CtpForwardingEngineP does not have commands/events which provide the information you would need to implement fairness? This latter point is true -- you need to at least see the queue depth. Rodrigo and Om are working on the implementation so it can provide this information, in order to allow transport-level fairness mechanisms (e.g., IFRC) to be built on top of a CTP topology. I don't understand what you're trying to achieve that CTP won't let you. I'll reiterate -- CTP has never claimed to provide network fairness under high load. If anything, it focuses on the much more common case in *low-power* sensornets of light load. > I agree with the point you made on the segregation of queues its > like applying a control algorithm on the queues itself. So would it > make sense to have a single queue for clients and forwarded packets > and serving them without bias (first come first serve) and allowing > rate controllers to control their rates ? Sure -- isn't that what I said originally? Phil -- Phd Dept. of Electrical Engineering University of Southern California http://www-scf.usc.edu/~asridhar ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x
On Mar 23, 2007, at 9:11 AM, Avinash Sridharan wrote: Hi Phil, I agree that if you apply rate control to the client it would limit the packet generation, but the reason I say the queueing dynamics would override these affects is that rate control algorithm assume all packets have the same service rate. I don't understand what you mean by "all packets have the same service rate." Fairness rarely operates in terms of packets; it operates in terms of flows or node pairs. I'm not sure what fair servicing on a packet basis means, as a packet is a singleton. But since the queue is biased towards the forwarder the service rate of a client packet will be less than the service rate of a frowarded packet. Wouldn't the rate allocated to the client have to take this into account ? Again, I don't understand what you're asking. Are you asking about how you would implement network fairness? Or are you commenting that the current implementation of CtpForwardingEngineP does not have commands/events which provide the information you would need to implement fairness? This latter point is true -- you need to at least see the queue depth. Rodrigo and Om are working on the implementation so it can provide this information, in order to allow transport-level fairness mechanisms (e.g., IFRC) to be built on top of a CTP topology. I don't understand what you're trying to achieve that CTP won't let you. I'll reiterate -- CTP has never claimed to provide network fairness under high load. If anything, it focuses on the much more common case in *low-power* sensornets of light load. I agree with the point you made on the segregation of queues its like applying a control algorithm on the queues itself. So would it make sense to have a single queue for clients and forwarded packets and serving them without bias (first come first serve) and allowing rate controllers to control their rates ? Sure -- isn't that what I said originally? Phil ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x
Hi Phil, I agree that if you apply rate control to the client it would limit the packet generation, but the reason I say the queueing dynamics would override these affects is that rate control algorithm assume all packets have the same service rate. But since the queue is biased towards the forwarder the service rate of a client packet will be less than the service rate of a frowarded packet. Wouldn't the rate allocated to the client have to take this into account ? I agree with the point you made on the segregation of queues its like applying a control algorithm on the queues itself. So would it make sense to have a single queue for clients and forwarded packets and serving them without bias (first come first serve) and allowing rate controllers to control their rates ? regards, Avinash On 3/23/07, Philip Levis <[EMAIL PROTECTED]> wrote: On Mar 22, 2007, at 10:35 PM, Avinash Sridharan wrote: > Hi Phil, > But even if we apply rate controllers at the sources (say for each > of the clients) the inherent unfairness in the queuing dynamics > would over ride the effects of the rate controllers to provide > fairness. If you apply rate control to packet generation, then this is going to limit how many client packets are in the queue at any one time. How would queueing dynamics override these effects? > The point I am trying to make is to make transport layers work > with the forwarding engine that can ensure fairness there should be > a fair treatment of all packets in the queue. One way I would think > this could be done is to keep the client queue segregated from the > forwarding queue, and make the send task alternate between these > queues. Alternating between the queues most certainly would not provide fairness -- you give equal weight to packets you generate and *all* packets you forward. Nodes close to the root would have a higher throughput than those far. That being said, if you had two queues, you *could* control the rate at which you service them to provide fairness. But that's not any different than controlling the rate at which packets can enter a shared queue. Phil -- Phd Dept. of Electrical Engineering University of Southern California http://www-scf.usc.edu/~asridhar ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x
On Mar 22, 2007, at 10:35 PM, Avinash Sridharan wrote: Hi Phil, But even if we apply rate controllers at the sources (say for each of the clients) the inherent unfairness in the queuing dynamics would over ride the effects of the rate controllers to provide fairness. If you apply rate control to packet generation, then this is going to limit how many client packets are in the queue at any one time. How would queueing dynamics override these effects? The point I am trying to make is to make transport layers work with the forwarding engine that can ensure fairness there should be a fair treatment of all packets in the queue. One way I would think this could be done is to keep the client queue segregated from the forwarding queue, and make the send task alternate between these queues. Alternating between the queues most certainly would not provide fairness -- you give equal weight to packets you generate and *all* packets you forward. Nodes close to the root would have a higher throughput than those far. That being said, if you had two queues, you *could* control the rate at which you service them to provide fairness. But that's not any different than controlling the rate at which packets can enter a shared queue. Phil ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Please Help Me to Continuously READ DATA FROM theEEPROM
At a quick glance, I didn't see how you write the data to flash. Are you
sure there are more than one packet of data? Mostly the reason for
inexistent data is forgetting to flush the flash buffer, which actually
burns the data to flash.
Regards,
Harri
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Thusitha Bandara
Sent: Friday, March 23, 2007 1:54 PM
To: tinyos-help@Millennium.Berkeley.EDU
Subject: [Tinyos-help] Please Help Me to Continuously READ DATA FROM
theEEPROM
Hi Hunkeler,
Yes. Your understanding is correct. This is a part of the protocol
which i am going to implement. So it needs to communicate with the Base
Station, before it broadcast its packets. So in my application:
*First Sense the Sensor Data and store them in the EEPROM as a
Packet.
*When it over the Sensing (Say 16 Time), It broadcast a request
Message to ask for its data Transfer.
*When the base Station confirms the request, it broadcast the
confirmation.
*When the Mote recieve the confirmation: It should send all its
stored data continuously.
* But the problem is that it just send the first data packet always.
Like:
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
But i want it to send the data packets one by one in its EEPROM.
Like:
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 E0 03 E4 03 E6 03 E6 03 F5 03 E7 03 EE 03 E7 03
FF FF 09 7D 12 01 00 EE 03 ED 03 ED 03 ED 03 EC 03 EC 03 EC 03 E8 03
FF FF 09 7D 12 01 00 ED 03 F0 03 E9 03 E7 03 E6 03 E2 03 DD 03 D9 03
FF FF 09 7D 12 01 00 69 03 63 03 52 03 49 03 3A 03 34 03 33 03 24 03
FF FF 09 7D 12 01 00 DE 02 DF 02 D4 02 2F 03 21 03 23 03 05 03 08 03
FF FF 09 7D 12 01 00 ED 03 EB 03 EB 03 EA 03 C7 03 C1 03 E6 03 E9 03
FF FF 09 7D 12 01 00 CB 12 83 42 69 21 9A 50 04 27 00 92 10 06 03 82
The following Code does the above communication scenario and attempt to
send the stored data.
*I can sure that my module correctly write to the EEPROM. Because it
reads correctly, when i programm this application to execute without
that request-confirmation thing.
1) So can you please analyse this code and say, what would be the
problem??
or
2) Is there any special procedure to follow when we want to make EEPROM
READ Continuously?
or
3) Is there any special procedure to follow when we want to broadcast
several packets continuously in a short interval of time??
I really need yours help.
Please help me to resolve them.
Regards,
Bandara.
// $Id: SimpleCmdM.nc,v 1.2 2003/10/07 21:44:59 idgay Exp $
includes SimpleCmdMsg;
module SimpleCmdM {
provides {
interface StdControl;
interface ProcessCmd;
interface Reading;
}
uses {
interface Leds;
interface ReceiveMsg as ReceiveCmdMsg;
interface StdControl as CommControl;
interface StdControl as RequestCommControl;
interface StdControl as SounderControl;
interface LoggerRead;
interface SendMsg as SendLogMsg;
interface ReceiveMsg as RequestReceiveMsg;
interface SendMsg as RequestSendMsg;
interface Sensing;
}
}
implementation
{
// declare module static variables here
TOS_MsgPtr cur_msg; // The current command message
TOS_Msg log_msg , request_msg; // The current log message
bool send_pending; // TRUE if a message send is pending
bool eeprom_read_pending; // TRUE if an EEPROM read is pending
TOS_Msg buf; // Free buffer for message reception
uint16_t num;
bool request_send_pending;
task void cmdInterpret() {
result_t status = SUCCESS;
if(!eeprom_read_pending){
if (call LoggerRead.readNext(((struct LogMsg *)log_msg.data)->log)) {
call Leds.yellowOn();
eeprom_read_pending = TRUE;
}
}
signal ProcessCmd.done(cur_msg, status);
}
task void cmdInterpretRepeat() {
if(!eeprom_read_pending){
call SounderControl.start();
if (call LoggerRead.readNext(((struct LogMsg *)log_msg.data)->log)) {
eeprom_read_pending = TRUE;
}
}
}
task void RequestConfirm()
{
struct RequestMsg *request = (struct RequestMsg * )request_msg.data;
result_t status = FAIL;
if(!request_send_pending)
{
/**
uint16_t sourceMoteID; uint8_t type; uint8_t sendDone;
uint16_t packetNumber; uint8_t noOfPackets; uint16_t npackets;
uint16_t token; uint8_t confirm; uint8_t channel;
**/
atomic{
request->sourceMoteID = TOS_LOCAL_ADDRESS;
}
request->type = 0;
request->sendDone = 0;
request->packetNumber = 0;
request->noOfPacke
[Tinyos-help] Re: Tinyos-help Digest, Vol 47, Issue 89
Hi Bandara,
I'm always a bit hesitant when people say that one part of their program
must be correct because of whatever reason. If what you're saying is
correct then the only difference between the two testing programs would
be that the program that doesn't wait for the confirmation just jumps to
the sending part. If this is what you think you indeed did, then the
problem must be somewhere in this difference. Why don't you modify your
program such that you only have to exchange two lines of code (comment
one, uncomment the other) to switch between the two behaviours? It
should look something like (this is not real code!):
void SensorReadingDone() {
num++;
if(num >= 16 && bcastNotStarted) {
bcastNotStarted = FALSE;
// post startBcastingResults();
post requestConfirmation();
}
}
void Confirmation.receive(..) {
post startBcastingResults();
}
task void startBcastingResults() {
readEEProm();
sendBcastWithResutls();
}
void Bcast.sendDone() {
num--;
if(num > 0) {
post startBcastingResults();
} else {
bcastNotStarted = TRUE;
}
}
You could even potentially add a delay (with a timer) to ensure that
nothing changes during the brief delay while waiting for the confirmation.
There is a bug in some versions of TinyOS (I didn't check whether this
is fixed now) where reading from the EEPROM did not result in an error
when reaching the end of the data. Instead the buffer simply wasn't
altered. With the above approach you ensure that both scenarios really
are equivalent.
***
I also see a potential concurrency problem with your code. In
LoggerRead.readDone() you start sending and also start reading from the
EEPROM before the send is completed. Theoretically it could be possible
that the read would be done before the send is done. You would then
loose one (or more) reading. However I don't think this explains your
observation.
Cheers,
Urs
Thusitha Bandara schrieb:
> Hi Hunkeler,
>
> Yes. Your understanding is correct. This is a part of the protocol which
> i am going to implement. So it needs to communicate with the Base Station,
> before it broadcast its packets. So in my application:
>
> *First Sense the Sensor Data and store them in the EEPROM as a Packet.
> *When it over the Sensing (Say 16 Time), It broadcast a request Message
> to ask for its data Transfer.
> *When the base Station confirms the request, it broadcast the
> confirmation.
> *When the Mote recieve the confirmation: It should send all its stored
> data continuously.
> * But the problem is that it just send the first data packet always. Like:
>
> FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
> FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
> FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
> FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
> FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
> FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
> FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
>
> But i want it to send the data packets one by one in its EEPROM. Like:
>
> FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
> FF FF 09 7D 12 01 00 E0 03 E4 03 E6 03 E6 03 F5 03 E7 03 EE 03 E7 03
> FF FF 09 7D 12 01 00 EE 03 ED 03 ED 03 ED 03 EC 03 EC 03 EC 03 E8 03
> FF FF 09 7D 12 01 00 ED 03 F0 03 E9 03 E7 03 E6 03 E2 03 DD 03 D9 03
> FF FF 09 7D 12 01 00 69 03 63 03 52 03 49 03 3A 03 34 03 33 03 24 03
> FF FF 09 7D 12 01 00 DE 02 DF 02 D4 02 2F 03 21 03 23 03 05 03 08 03
> FF FF 09 7D 12 01 00 ED 03 EB 03 EB 03 EA 03 C7 03 C1 03 E6 03 E9 03
> FF FF 09 7D 12 01 00 CB 12 83 42 69 21 9A 50 04 27 00 92 10 06 03 82
>
> The following Code does the above communication scenario and attempt to send
> the stored data.
>
> *I can sure that my module correctly write to the EEPROM. Because it
> reads correctly, when i programm this application to execute without that
> request-confirmation thing.
>
> 1) So can you please analyse this code and say, what would be the problem??
> or
> 2) Is there any special procedure to follow when we want to make EEPROM READ
> Continuously?
> or
> 3) Is there any special procedure to follow when we want to broadcast several
> packets continuously in a short interval of time??
>
> I really need yours help.
> Please help me to resolve them.
>
> Regards,
> Bandara.
>
>
> // $Id: SimpleCmdM.nc,v 1.2 2003/10/07 21:44:59 idgay Exp $
> includes SimpleCmdMsg;
> module SimpleCmdM {
> provides {
> interface StdControl;
> interface ProcessCmd;
> interface Reading;
> }
> uses {
> interface Leds;
> interface ReceiveMsg as ReceiveCmdMsg;
> interface StdControl as CommControl;
> interface StdControl as RequestCommControl;
> interface StdControl as SounderControl;
> int
Re: [Tinyos-help] Please Help Me to Continuously READ DATA FROM the EEPROM on a Micaz MOTE
Hi,
I didn't try it on TOSSIM. But it should work in Motes.
Regards,
Bandara.
- Original Message
From: Dasarath Weeratunge <[EMAIL PROTECTED]>
To: Thusitha Asela <[EMAIL PROTECTED]>
Sent: Friday, March 23, 2007 1:58:30 AM
Subject: Re: [Tinyos-help] Please Help Me to Continuously READ DATA FROM the
EEPROM on a Micaz MOTE
Quoting Thusitha Asela <[EMAIL PROTECTED]>:
Does your code work on TOSSIM?
--dasarath
> Dear Sir,
>
> I am a 4th Year Student at the University of Colombo School of Computing
> Sri Lanka. I am doing a Sensor Application for my 4 th Year Individual
> Project.
>
> So i tried to sample the Light Sensor data into EEPROM and then read them
> continuously.
>
> I could verify that the data is written to the EEPROM correctly.
>
> According to the following Code:
>
> I start Sense Light Reading.
> Then call a Module to make a Request for confirmation to send the Sampled
> Data.
> If Confirmation gets True:It calls a task to READ from EEPROM and
> Send Data
> Then In "SendDone() " method,
> I again call to READ FROM
> EEPROM and Send the Data.
> I do this for 4 -8 Times.
>
> ** The Problem is that in each time it gives (BCAST) only the First Data
> Packet.
>
> Is it relevant to some lack of refresh time??
>
> ** Please help me to Continuously READ DATA FROM the EEPROM on this Micaz
> MOTE.
> Or
> Can you please guide me to solve this Problem??
>
> Strongly appriciate your any commence!
>
>
> Followings are the Code. And i have Attached the full Code with this as well.
>
> Please Give me some help!!!
>
>
> Thank You!
> Regards,
> Bandara.
> (The Happy is the Goal!)
>
>
>
>
> __
>
>
> //EEPROMReadM.nc
> includes MoteMsg;
> module BusEEPROMReadM
> {
> provides interface StdControl;
> provides interface ProcessRead;
> uses
> {
> interface StdControl as DataCommControl;
> interface StdControl as SounderControl;
> interface ControlSense as RepeatControlSense; //call command start(int
> nsamples , int interval) and
> //implement event finish()
> interface Leds;
> interface SendMsg as DataSend;
> interface ReceiveMsg as DataReceive;
> interface LoggerRead;
> }
> }
> implementation
> {
> TOS_Msg data_msg;
> int no_of_packets_to_read;
> bool data_send_pending;
> bool eeprom_read_pending;
> task void readEEPROM()
> {
> result_t status = FAIL;
> call Leds.init();
> if(!eeprom_read_pending)
> {
> eeprom_read_pending = TRUE;
> if(call LoggerRead.readNext(((struct EEPROMMsg *)data_msg.data)->log))
> //readNext(uint8_t *buffer);
> {
> call Leds.greenToggle();
> status = SUCCESS;
> }
> }
> signal ProcessRead.readEEPROMDone(status);
> }
> void readEEPROMRepeat()
> {
> call Leds.init();
> if(!eeprom_read_pending)
> {
> call SounderControl.start();
> eeprom_read_pending = TRUE;
> if(call LoggerRead.readNext(((struct EEPROMMsg *)data_msg.data)->log))
> //readNext(uint8_t *buffer);
> {
> call Leds.greenToggle();
> eeprom_read_pending = TRUE;
> }
> }
> }
> command result_t StdControl.init()
> {
> no_of_packets_to_read = 0;
> data_send_pending = FALSE;
> eeprom_read_pending = FALSE;
> call SounderControl.init();
> return rcombine(call DataCommControl.init() , call Leds.init());
> }
> command result_t StdControl.start()
> {
> return SUCCESS;
> }
> command result_t StdControl.stop()
> {
> return SUCCESS;
> }
> result_t checkRepeat(uint8_t num)
> {
> call Leds.init();
> if(num>0)
> {
> call Leds.yellowToggle();
> readEEPROMRepeat();
> }
> else
> {
> call RepeatControlSense.start(32 , 500);
> }
> return SUCCESS;
> }
> command result_t ProcessRead.readEEPROM(uint8_t num)
> {
> no_of_packets_to_read = num;
> post readEEPROM();
> return SUCCESS;
> }
> event TOS_MsgPtr DataReceive.receive(TOS_MsgPtr pmsg)
> {
> return pmsg;
> }
> event result_t LoggerRead.readDone(uint8_t *buffer , result_t status)
> {
> struct EEPROMMsg *pack;
> call Leds.redToggle();
> if(status && eeprom_read_pending && !data_send_pending)
> {
> call Leds.yellowToggle();
> data_send_pending = TRUE;
> pack = (struct EEPROMMsg *)data_msg.data;
> atomic{
> pack->sourceMoteID = TOS_LOCAL_ADDRESS;
> }
> if(call DataSend.send(TOS_BCAST_ADDR , sizeof(struct EEPROMMsg ) ,&data_msg
> ))
> {
> call Leds.greenToggle();
> no_of_packets_to_read--;
> call Leds.redOn();
> }
> }
> eeprom_read_pending = FALSE;
> return SUCCESS;
> }
> event result_t DataSend.sendDone(TOS_MsgPtr pmsg , result_t status)
> {
> eeprom_read_pending = FALSE;
> data_send_pending = FALSE;
> checkRepeat(no_of_packets_to_read);
> return SUCCESS;
> }
> event result_t RepeatControlSense.finish()
> {
> return SUCCESS;
> }
> default event result_t ProcessRead.readEEPROMDone(result_t status)
> {
> result_t test=FAIL;
>
> checkRepeat(no_of_packets_to_read);
> retu
[Tinyos-help] Is there any special procedure to follow when we want to Read EEPROM or to BCast SEVERAL Packets Continuously?????
Hi Hunkeler,
Yes. Your understanding is correct. This is a part of the protocol which i
am going to implement. So it needs to communicate with the Base Station, before
it broadcast its packets. So in my application:
*First Sense the Sensor Data and store them in the EEPROM as a Packet.
*When it finishes the Sensing (Say 160 Times - this store 16 data readings
into a packet. so then it should store 10 data packets. ), It broadcast a
request Message to ask for its data to Transfer to the Base
Station.
*When the base Station confirms the request, it broadcast the confirmation.
*When the Mote recieve the confirmation: It should send its all stored data
continuously.
* But the problem is that it just send the first data packet always. Like:
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
But i want it to send the data packets one by one in its EEPROM. Like:
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 E0 03 E4 03 E6 03 E6 03 F5 03 E7 03 EE 03 E7 03
FF FF 09 7D 12 01 00 EE 03 ED 03 ED 03 ED 03 EC 03 EC 03 EC 03 E8 03
FF FF 09 7D 12 01 00 ED 03 F0 03 E9 03 E7 03 E6 03 E2 03 DD 03 D9 03
FF FF 09 7D 12 01 00 69 03 63 03 52 03 49 03 3A 03 34 03 33 03 24 03
FF FF 09 7D 12 01 00 DE 02 DF 02 D4 02 2F 03 21 03 23 03 05 03 08 03
FF FF 09 7D 12 01 00 ED 03 EB 03 EB 03 EA 03 C7 03 C1 03 E6 03 E9 03
FF FF 09 7D 12 01 00 CB 12 83 42 69 21 9A 50 04 27 00 92 10 06 03 82
FF FF 09 7D 12 01 00 CB 17 83 42 69 20 9A 50 04 27 00 02 19 06 03 80
FF FF 09 7D 12 01 00 EE C3 ED C3 ED B3 ED 03 EC B3 EC A3 EC A3 E8 13
The following Code does the above communication scenario and attempt to send
the stored data.
*I can sure that my module correctly write to the EEPROM. Because it reads
correctly, when i programm this application to execute without that
request-confirmation thing.
1) So can you please analyse this code and say, what would be the problem??
or
2) Is there any special procedure to follow when we want to make EEPROM READ
Continuously?
or
3) Is there any special procedure to follow when we want to broadcast several
packets continuously in a short interval of time??
I really need yours help.
Please help me to resolve them.
Regards,
Bandara.
// $Id: SimpleCmdM.nc,v 1.2 2003/10/07 21:44:59 idgay Exp $
includes SimpleCmdMsg;
module SimpleCmdM {
provides {
interface StdControl;
interface ProcessCmd;
interface Reading;
}
uses {
interface Leds;
interface ReceiveMsg as ReceiveCmdMsg;
interface StdControl as CommControl;
interface StdControl as RequestCommControl;
interface StdControl as SounderControl;
interface LoggerRead;
interface SendMsg as SendLogMsg;
interface ReceiveMsg as RequestReceiveMsg;
interface SendMsg as RequestSendMsg;
interface Sensing;
}
}
implementation
{
// declare module static variables here
TOS_MsgPtr cur_msg; // The current command message
TOS_Msg log_msg , request_msg; // The current log message
bool send_pending; // TRUE if a message send is pending
bool eeprom_read_pending; // TRUE if an EEPROM read is pending
TOS_Msg buf; // Free buffer for message reception
uint16_t num;
bool request_send_pending;
task void cmdInterpret() {
result_t status = SUCCESS;
if(!eeprom_read_pending){
if (call LoggerRead.readNext(((struct LogMsg *)log_msg.data)->log)) {
call Leds.yellowOn();
eeprom_read_pending = TRUE;
}
}
signal ProcessCmd.done(cur_msg, status);
}
task void cmdInterpretRepeat() {
if(!eeprom_read_pending){
call SounderControl.start();
if (call LoggerRead.readNext(((struct LogMsg *)log_msg.data)->log)) {
eeprom_read_pending = TRUE;
}
}
}
task void RequestConfirm()
{
struct RequestMsg *request = (struct RequestMsg * )request_msg.data;
result_t status = FAIL;
if(!request_send_pending)
{
/**
uint16_t sourceMoteID; uint8_t type; uint8_t sendDone;
uint16_t packetNumber; uint8_t noOfPackets; uint16_t npackets;
uint16_t token; uint8_t confirm; uint8_t channel;
**/
atomic{
request->sourceMoteID = TOS_LOCAL_ADDRESS;
}
request->type = 0;
request->sendDone = 0;
request->packetNumber = 0;
request->noOfPackets = 0;
request->npackets = 0;
request->token = 0;
request->confirm = 0;
request->channel = 0;
if(call RequestSendMsg.send(TOS_BCAST_ADDR , (sizeof(struct R
[Tinyos-help] Please Help Me to Continuously READ DATA FROM the EEPROM
Hi Hunkeler,
Yes. Your understanding is correct. This is a part of the protocol which i
am going to implement. So it needs to communicate with the Base Station, before
it broadcast its packets. So in my application:
*First Sense the Sensor Data and store them in the EEPROM as a Packet.
*When it over the Sensing (Say 16 Time), It broadcast a request Message to
ask for its data Transfer.
*When the base Station confirms the request, it broadcast the confirmation.
*When the Mote recieve the confirmation: It should send all its stored data
continuously.
* But the problem is that it just send the first data packet always. Like:
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
But i want it to send the data packets one by one in its EEPROM. Like:
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 E0 03 E4 03 E6 03 E6 03 F5 03 E7 03 EE 03 E7 03
FF FF 09 7D 12 01 00 EE 03 ED 03 ED 03 ED 03 EC 03 EC 03 EC 03 E8 03
FF FF 09 7D 12 01 00 ED 03 F0 03 E9 03 E7 03 E6 03 E2 03 DD 03 D9 03
FF FF 09 7D 12 01 00 69 03 63 03 52 03 49 03 3A 03 34 03 33 03 24 03
FF FF 09 7D 12 01 00 DE 02 DF 02 D4 02 2F 03 21 03 23 03 05 03 08 03
FF FF 09 7D 12 01 00 ED 03 EB 03 EB 03 EA 03 C7 03 C1 03 E6 03 E9 03
FF FF 09 7D 12 01 00 CB 12 83 42 69 21 9A 50 04 27 00 92 10 06 03 82
The following Code does the above communication scenario and attempt to send
the stored data.
*I can sure that my module correctly write to the EEPROM. Because it reads
correctly, when i programm this application to execute without that
request-confirmation thing.
1) So can you please analyse this code and say, what would be the problem??
or
2) Is there any special procedure to follow when we want to make EEPROM READ
Continuously?
or
3) Is there any special procedure to follow when we want to broadcast several
packets continuously in a short interval of time??
I really need yours help.
Please help me to resolve them.
Regards,
Bandara.
// $Id: SimpleCmdM.nc,v 1.2 2003/10/07 21:44:59 idgay Exp $
includes SimpleCmdMsg;
module SimpleCmdM {
provides {
interface StdControl;
interface ProcessCmd;
interface Reading;
}
uses {
interface Leds;
interface ReceiveMsg as ReceiveCmdMsg;
interface StdControl as CommControl;
interface StdControl as RequestCommControl;
interface StdControl as SounderControl;
interface LoggerRead;
interface SendMsg as SendLogMsg;
interface ReceiveMsg as RequestReceiveMsg;
interface SendMsg as RequestSendMsg;
interface Sensing;
}
}
implementation
{
// declare module static variables here
TOS_MsgPtr cur_msg; // The current command message
TOS_Msg log_msg , request_msg; // The current log message
bool send_pending; // TRUE if a message send is pending
bool eeprom_read_pending; // TRUE if an EEPROM read is pending
TOS_Msg buf; // Free buffer for message reception
uint16_t num;
bool request_send_pending;
task void cmdInterpret() {
result_t status = SUCCESS;
if(!eeprom_read_pending){
if (call LoggerRead.readNext(((struct LogMsg *)log_msg.data)->log)) {
call Leds.yellowOn();
eeprom_read_pending = TRUE;
}
}
signal ProcessCmd.done(cur_msg, status);
}
task void cmdInterpretRepeat() {
if(!eeprom_read_pending){
call SounderControl.start();
if (call LoggerRead.readNext(((struct LogMsg *)log_msg.data)->log)) {
eeprom_read_pending = TRUE;
}
}
}
task void RequestConfirm()
{
struct RequestMsg *request = (struct RequestMsg * )request_msg.data;
result_t status = FAIL;
if(!request_send_pending)
{
/**
uint16_t sourceMoteID; uint8_t type; uint8_t sendDone;
uint16_t packetNumber; uint8_t noOfPackets; uint16_t npackets;
uint16_t token; uint8_t confirm; uint8_t channel;
**/
atomic{
request->sourceMoteID = TOS_LOCAL_ADDRESS;
}
request->type = 0;
request->sendDone = 0;
request->packetNumber = 0;
request->noOfPackets = 0;
request->npackets = 0;
request->token = 0;
request->confirm = 0;
request->channel = 0;
if(call RequestSendMsg.send(TOS_BCAST_ADDR , (sizeof(struct RequestMsg)) ,
&request_msg))
{
request_send_pending = TRUE;
status = SUCCESS;
}
}
}
command result_t StdControl.init() {
cur_msg = &buf;
send_pending = FALSE;
eeprom_read_pending = FALSE;
request_send_pending = FALSE;
num = 30;
return rcombine(call CommControl.init(), call Leds.init());
}
command result_t StdControl.start(){
call Sensing.start(256, 500);
return SUCCESS;
}
command result_t StdControl.stop(){
return SUCCESS;
}
command result_t Pro
[Tinyos-help] Re: Tinyos-help Digest, Vol 47, Issue 89
Hi Hunkeler,
Yes. Your understanding is correct. This is a part of the protocol which i
am going to implement. So it needs to communicate with the Base Station, before
it broadcast its packets. So in my application:
*First Sense the Sensor Data and store them in the EEPROM as a Packet.
*When it over the Sensing (Say 16 Time), It broadcast a request Message to
ask for its data Transfer.
*When the base Station confirms the request, it broadcast the confirmation.
*When the Mote recieve the confirmation: It should send all its stored data
continuously.
* But the problem is that it just send the first data packet always. Like:
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
But i want it to send the data packets one by one in its EEPROM. Like:
FF FF 09 7D 12 01 00 F5 03 F4 03 F7 03 EE 03 F0 03 EC 03 E9 03 F2 03
FF FF 09 7D 12 01 00 E0 03 E4 03 E6 03 E6 03 F5 03 E7 03 EE 03 E7 03
FF FF 09 7D 12 01 00 EE 03 ED 03 ED 03 ED 03 EC 03 EC 03 EC 03 E8 03
FF FF 09 7D 12 01 00 ED 03 F0 03 E9 03 E7 03 E6 03 E2 03 DD 03 D9 03
FF FF 09 7D 12 01 00 69 03 63 03 52 03 49 03 3A 03 34 03 33 03 24 03
FF FF 09 7D 12 01 00 DE 02 DF 02 D4 02 2F 03 21 03 23 03 05 03 08 03
FF FF 09 7D 12 01 00 ED 03 EB 03 EB 03 EA 03 C7 03 C1 03 E6 03 E9 03
FF FF 09 7D 12 01 00 CB 12 83 42 69 21 9A 50 04 27 00 92 10 06 03 82
The following Code does the above communication scenario and attempt to send
the stored data.
*I can sure that my module correctly write to the EEPROM. Because it reads
correctly, when i programm this application to execute without that
request-confirmation thing.
1) So can you please analyse this code and say, what would be the problem??
or
2) Is there any special procedure to follow when we want to make EEPROM READ
Continuously?
or
3) Is there any special procedure to follow when we want to broadcast several
packets continuously in a short interval of time??
I really need yours help.
Please help me to resolve them.
Regards,
Bandara.
// $Id: SimpleCmdM.nc,v 1.2 2003/10/07 21:44:59 idgay Exp $
includes SimpleCmdMsg;
module SimpleCmdM {
provides {
interface StdControl;
interface ProcessCmd;
interface Reading;
}
uses {
interface Leds;
interface ReceiveMsg as ReceiveCmdMsg;
interface StdControl as CommControl;
interface StdControl as RequestCommControl;
interface StdControl as SounderControl;
interface LoggerRead;
interface SendMsg as SendLogMsg;
interface ReceiveMsg as RequestReceiveMsg;
interface SendMsg as RequestSendMsg;
interface Sensing;
}
}
implementation
{
// declare module static variables here
TOS_MsgPtr cur_msg; // The current command message
TOS_Msg log_msg , request_msg; // The current log message
bool send_pending; // TRUE if a message send is pending
bool eeprom_read_pending; // TRUE if an EEPROM read is pending
TOS_Msg buf; // Free buffer for message reception
uint16_t num;
bool request_send_pending;
task void cmdInterpret() {
result_t status = SUCCESS;
if(!eeprom_read_pending){
if (call LoggerRead.readNext(((struct LogMsg *)log_msg.data)->log)) {
call Leds.yellowOn();
eeprom_read_pending = TRUE;
}
}
signal ProcessCmd.done(cur_msg, status);
}
task void cmdInterpretRepeat() {
if(!eeprom_read_pending){
call SounderControl.start();
if (call LoggerRead.readNext(((struct LogMsg *)log_msg.data)->log)) {
eeprom_read_pending = TRUE;
}
}
}
task void RequestConfirm()
{
struct RequestMsg *request = (struct RequestMsg * )request_msg.data;
result_t status = FAIL;
if(!request_send_pending)
{
/**
uint16_t sourceMoteID; uint8_t type; uint8_t sendDone;
uint16_t packetNumber; uint8_t noOfPackets; uint16_t npackets;
uint16_t token; uint8_t confirm; uint8_t channel;
**/
atomic{
request->sourceMoteID = TOS_LOCAL_ADDRESS;
}
request->type = 0;
request->sendDone = 0;
request->packetNumber = 0;
request->noOfPackets = 0;
request->npackets = 0;
request->token = 0;
request->confirm = 0;
request->channel = 0;
if(call RequestSendMsg.send(TOS_BCAST_ADDR , (sizeof(struct RequestMsg)) ,
&request_msg))
{
request_send_pending = TRUE;
status = SUCCESS;
}
}
}
command result_t StdControl.init() {
cur_msg = &buf;
send_pending = FALSE;
eeprom_read_pending = FALSE;
request_send_pending = FALSE;
num = 30;
return rcombine(call CommControl.init(), call Leds.init());
}
command result_t StdControl.start(){
call Sensing.start(256, 500);
return SUCCESS;
}
command result_t StdControl.stop(){
return SUCCESS;
}
command result_t ProcessCmd.execut
Re: [Tinyos-help] Is it normal behaviour????
Le vendredi 23 mars 2007 08:59, Spidernet Lists a écrit :
> Hi,
> Is it normal that when i am running the "Blink" application. The Leds
> are blinking BUT does the CPU enter the "sleep mode" and never gets out
> of this. I am using GDB to debug and when i do the Run coomand,, the
> process keeps running and leds keep toggling at the specified rate. But
> if I hit the "Stop" Button, the program stops in the
> /chips/atm128/McuSleepC.nc line 119 which says:
> asm volatile ("sleep");
> Does this mean it is alright and as no other "event" is occuring in the
> "Blink" application, the controller should go to the "sleep" mode.
> Hence, the behaviour is normal
I would say that it's perfectly normal behavior. The node spends most of it's
time in sleep state, but when he is in the timer function which is switching
on/off the LEDs, which is performed very quickly. So your probability to stop
it during this timer call are very small. I would also say that if you use
gdb stepping from there you may miss some timers/interrupts (not really
shure about this ) or not enter those functions.
> OR
>
> Is there something wrong in my configuration
>
if you want to stop your program in the timer function or something else you
should use breakpoints ...
HTH,
Aurélien
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] Is it normal behaviour????
Hi,
I think it is normal. Because "hurry-up and sleep" is the main idea of
TinyOS. In 1 sec period, toggling Leds are not so long enough that you
couldn't achieve to stop the debug session in a working (awake, not
sleep) mode.
Firat TARAKTAS
Electrical&Electronics Engineer
Reseracher
GENETLAB INFORMATION TECHNOLOGIES
Kayisdagi Caddesi Kar Plaza D Blok Kat:3 34752
Icerenkoy / ISTANBUL / TURKIYE
Phone: +90 (216) 573 00 85 (int.354)
Fax: +90 (216) 469 85 07
[EMAIL PROTECTED]
www.genetlab.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Spidernet Lists
Sent: Friday, March 23, 2007 9:59 AM
To: tinyos-help@Millennium.Berkeley.EDU; Mirko Bordignon
Subject: [Tinyos-help] Is it normal behaviour
Hi,
Is it normal that when i am running the "Blink" application. The Leds
are blinking BUT does the CPU enter the "sleep mode" and never gets out
of this. I am using GDB to debug and when i do the Run coomand,, the
process keeps running and leds keep toggling at the specified rate. But
if I hit the "Stop" Button, the program stops in the
/chips/atm128/McuSleepC.nc line 119 which says:
asm volatile ("sleep");
Does this mean it is alright and as no other "event" is occuring in the
"Blink" application, the controller should go to the "sleep" mode.
Hence, the behaviour is normalOR
Is there something wrong in my configuration
Any help is appreciated
Cheers!
VJ
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-hel
p
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Please help me with this simple interface problem.
Hi Alborz,
Is there an Interface StepMotor? If so, does this interface provide a
command "init"? Otherwise in CarTowerM.nc, do you have a line like "uses
interface StdControl as StepMotor;" ?
My guess is that you want to call the init() command of the StdControl
interface of StepMotorC (StepMotorM), but that this interface is not
wired anywhere. You would probably need a line like "uses interface
StdControl as StepMotorCtrl;" in CarTowerM and then call
"StepMotorCtrl.init()". The wiring in CarTowerC would then be something
like "CT.StepMotorCtrl -> SM.StdControl;".
If this doesn't help, could you provide the configuration part of CarTowerM?
Cheers,
Urs
Alborz Sedaghat schrieb:
> Hello.
>
> I have a file named "StepMotorM.nc" and it contains "result_t command
> StdControl.init() {..."
>
> Now i want my other file which is called "CarTowerM" to be able to wire to
> the StdControl.init() in the "StepMotorM", like below.
>
> __
> module CarTowerM {...
>
> result_t command StdControl.init() {
> call StepMotor.init();
> return SUCCESS;
> }
> ___
> The CarTowerC file looks like this:
>
> configuration CarTowerC {
> provides interface CarTower;
> provides interface StdControl;
> }
> implementation {
> components CarTowerM as CT, StepMotorC as SM;
> CT.StepMotor -> SM.StepMotor;
> StdControl = CT;
> CarTower = CT;
> }
> _
> What am i doing wrong?
> I am not used to nesC, but the problem should be pretty easy to solve.
> I get this error when i try to compile the code above.
>
> In component `CarTowerM':
> CarTowerM.nc: In function `StdControl.init':
> CarTowerM.nc:55: interface has no command or event named `init'
>
>
> Any help would be appreciated.
> Thank you all
>
> Sweden - Chalmers
> /Alborz
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Please help me with this simple interface problem.
Hello.
I have a file named "StepMotorM.nc" and it contains "result_t command
StdControl.init() {..."
Now i want my other file which is called "CarTowerM" to be able to wire to
the StdControl.init() in the "StepMotorM", like below.
__
module CarTowerM {...
result_t command StdControl.init() {
call StepMotor.init();
return SUCCESS;
}
___
The CarTowerC file looks like this:
configuration CarTowerC {
provides interface CarTower;
provides interface StdControl;
}
implementation {
components CarTowerM as CT, StepMotorC as SM;
CT.StepMotor -> SM.StepMotor;
StdControl = CT;
CarTower = CT;
}
_
What am i doing wrong?
I am not used to nesC, but the problem should be pretty easy to solve.
I get this error when i try to compile the code above.
In component `CarTowerM':
CarTowerM.nc: In function `StdControl.init':
CarTowerM.nc:55: interface has no command or event named `init'
Any help would be appreciated.
Thank you all
Sweden - Chalmers
/Alborz
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Is it normal behaviour????
Hi,
Is it normal that when i am running the "Blink" application. The Leds
are blinking BUT does the CPU enter the "sleep mode" and never gets out
of this. I am using GDB to debug and when i do the Run coomand,, the
process keeps running and leds keep toggling at the specified rate. But
if I hit the "Stop" Button, the program stops in the
/chips/atm128/McuSleepC.nc line 119 which says:
asm volatile ("sleep");
Does this mean it is alright and as no other "event" is occuring in the
"Blink" application, the controller should go to the "sleep" mode.
Hence, the behaviour is normalOR
Is there something wrong in my configuration
Any help is appreciated
Cheers!
VJ
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
