Strange loop behaviour with bridge.get on yun

Hi guys,

I’m trying to get the communication going between linino and the mc.

A python script waits for a message being send to it.
It then send this message to the mc by means of bridge.put.

The sketch does a bridge.get and compares it to a few strings.
Depending on the script it should do some actions and return data to the python script.

Here is the sketch

#include <Bridge.h>

char command[20];

void display(char s[])
{
        Serial.println(s);
        Bridge.put("antwoord",s);
        
}

void status()
{
	display("Status gevraagd");
}

void ls_aan()
{
	display("ls aan");
}
void ls_uit()
{
	display("Uitzetten...");
}

void o_o()
{
	display("Oeioei...");
}


void setup() 
{
   // Initialize Console and wait for port to open:
   Bridge.begin();
   
} 

void loop() 
{
    Bridge.get("ardev",command,6);
    delay(100);
    if ( command[0]!=0 )
    {  
      if (!strcmp(command,"STATUS")) { status(); };
      if (!strcmp(command,"LS_AAN")) { ls_aan(); };
      if (!strcmp(command,"LS_UIT")) { ls_uit(); };
      if (!strcmp(command,"REBOOT")) { o_o(); };
      command[0]=0;
    }
}

The python script reads:

#!/usr/bin/python
import socket
import sys
import time

sys.path.insert(0, '/usr/lib/python2.7/bridge/')
from bridgeclient import BridgeClient as bridgeclient
bc = bridgeclient()

print "starten"
UDP_PORT = 8887
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # UDP
#sock.settimeout(1)
sock.bind(("",UDP_PORT))
print "socket created"

recvmsg=sock.recv(1024)
print recvmsg
bc.put("ardev",recvmsg)

time.sleep(1)

r=bc.get("antwoord")
print "antw=",r

The python script finishes after 1 received message.
This is just for testing.

If I send STAT to linino, I get the right answer from the mc.
However, the serial.println generates a lot of lines with “status gevraagd”

And that’s what I don’t understand.

I changed the python script by adding a line bc.put(“ardev”,dummy)

In this case I get around 12 lines with “status gevraagd” before it stops.

So, am I on the edge of becoming crazy or is there something else I should have done ?

TIA,

Frank.

Small typo made : of course I'm sending STATUS instead of STAT.

Frank_K: Small typo made : of course I'm sending STATUS instead of STAT.

It was actually a big typo. You typed the whole thing into the wrong part of the forum. There is a section dedicated to the Yun where you belong.

The key ardev continues existing after you use the get function. So even if you put command[0] to 0 at the end of the if you will read again STATUS when your loop restart and you will print again the status string.

Also you do a time.sleep(1) in your script, so the loop code is executed about 10 times before you change the string into something else.

Put/get are better suited for reporting status, not commands. As Angelo said, once set, the value remains until it is set to something else. In addition, if the same "command" is put() again, the get() code will not be able to tell that it happened. Think of get/put as a way of accessing variables that are shared between the two processors, not as a message passing mechanism.

You could get around this by having the sketch put() an empty value in once it used get() to read a value, but this won't be reliable, it will be very easy to miss commands unless they come in very slowly.

I haven't played with it yet, but it seems like the Mailbox feature of the bridge may be more appropriate to what you want to do: http://arduino.cc/en/Reference/YunMailboxConstructor

I'm sorry I posted it in he wrong forum. I hope you forgive this as I'm new to the arduino and thereby new to the forums.

After looking at Anelo's reply,I'm wondering what the purpose of put en get are. It seems unreliable because this way of communicating can fail very easy because of i.e. wrong timing issues. Why would some want to "save" a key ?

And as Shapeshifter is telling me, Mailbox might be the right solution because the yun will be processing a lot of messages.

Thanks a lot guys, you're pointing me to a solution of my problem.

Thanks.

Frank.

Frank_K: After looking at Anelo's reply,I'm wondering what the purpose of put en get are. It seems unreliable because this way of communicating can fail very easy because of i.e. wrong timing issues. Why would some want to "save" a key ?

It is unsuitable as a message passing mechanism, for the reasons you mention. But it is still very useful for reporting status values and state commands. As a simple example, consider a thermostat: you give it a set point: 70 degrees F, a control mode: Heat; and a fan mode: Auto. The thermostat reports the actual temperature and a status of whether it is currently heating. These command and status values are ideal for a scenario as this: there are no worries about timing, no worries about missed messages (since the latest values are always available to both sides) and no need to remember the last reported command or status. It's completely asynchronous. It gets better when you consider that these values can be set or read directly using REST API calls with no code needed on the Linux side.

If you are dealing with a strictly message based system, get/put is not what you want. For example: if you insisted that the thermostat accept temperature up/down commands and it respond with the current set point. But if you can rework the interface to eliminate the messaging requirement as above, then get/put has some interesting advantages. But it's not applicable to all situations.

Hi ShapeShifter ,

I see your point. However, as the yun is not yet supporting UDP with the mailbox, Ill stick to the bridge for now. My whole network ( microchip controllers, raspberrys, windows (argh),ubuntu and now the yun) are broadcasting over UDP.

And mimicking a queue can easyly be done in Python.

Thanks for your thoughts !