I have the following problem, my simulation results to be stuck in the while loop. In my opinion, the reason is that we cannot execute the recv_uc on mote 1.0 before the loop ends. However, is the mote 1.0 itself that calls
unicast_send(&my_conn, &addr);
which changes
value = true;
I need to avoid to be stuck in the while loop. This is the most important part of the code.
static void my_func(struct unicast_conn *c, const rimeaddr_t *addr){
value = true;
...
}
static const struct unicast_callbacks my_call = {my_func};
//only mote 1 execute recv_uc
static void recv_uc(struct unicast_conn *c, const rimeaddr_t *from)
{
my_msg_t mess_rec;
rimeaddr_t addr;
addr.u8[0]= from->u8[0];
addr.u8[1]= from->u8[1];
memcpy(&mess_rec, packetbuf_dataptr(), sizeof(mess_rec));
...
packetbuf_copyfrom(&mess_rec, 16);
unicast_send(&my_conn, &addr);
}
static const struct unicast_callbacks unicast_call = {recv_uc};
PROCESS_THREAD(sending_rand, ev, data)
{
...
PROCESS_BEGIN();
unicast_open(&unicast, 120, &unicast_call); //importante
unicast_open(&my_conn, 130, &my_call); //importante
...
addr.u8[0] = 1;
addr.u8[1] = 0;
if(!rimeaddr_cmp(&addr, &rimeaddr_node_addr)){
...
while(value == false){
packetbuf_copyfrom(&mess, 16);
unicast_send(&unicast, &addr);
}
}
PROCESS_END();
}
Thank you.
Contiki uses cooperative multithreading, so if your thread does not yield it will not be interrupted except for actual hardware interrupts. Since it is a while since I worked with Contiki I am not absolutely sure whether the network callbacks are executed in interrupt handlers or in a dedicated process in the main loop. If the latter is true this would explain why your process never left the waiting loop.
I would recommend replacing the while loop by the following:
while(value == false){
packetbuf_copyfrom(&mess, 16);
unicast_send(&unicast, &addr);
PROCESS_YIELD(); // this allows other processes to run
}
Setting a timer may also be a good idea, depending on how often you want to send.