1.6.4 OS/X bridge library problem

[allairgoo]

As described here, in the arduino (Yun) forum http://forum.arduino.cc/index.php?topic=318255.new The IDE 1.6.4 on a 10.10.3 Mac

resulting sktech after compilation from the IDE (tested with 1.0.0 to 1.0.4 bridge library via the menu) is failing to start the bridge, or the bridge code is starting on the Linux side and then kill's itself.

Even sample code for bridge tests are no longer working.

[mschlenker]

Which firmware does your Yún run? (I assume you are using an Yùn and not something like http://www.arduino-hausautomation.de/nuage/)

[allairgoo]

it's a Arduino Yun running the last official distribution "Linux Arduino 3.3.8 #1 Fri Nov 14 08:57:34 CET 2014 mips GNU/Linux"

[mschlenker]

Would you take a look at /tmp/bridge.py-stderr.logon the Yún? Also after a sketch that uses Bridge.begin() was started, ps w | grep -i python should indicate python -u bridge.py. Use such a minimalist example to test:

#include <Bridge.h>
#include <Console.h>

void setup() {
  // put your setup code here, to run once:
  pinMode(13, OUTPUT);
  digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);              // wait for a second
  digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);              // wait for a second
  Bridge.begin() ; // Serial, BRIDGE_BAUDRATE);
  Console.begin();
  delay(1000);
}

void loop() {
  // put your main code here, to run repeatedly:
  Console.println("Hallo Welt!");
  digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(10);              // wait for a second
  digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);              // wait for a second
}

Since this uses the Console class you should be able to use the Serial Monitor to view the "Hello World!" issued by the sketch.

[allairgoo]

I did the test and found no /tmp/bridge.py-stderr.log file , no python process found (as specified on the arduino forum).. the LED13 flashes ONCE and.. stop.

BUT If a take your code, remove all the "bridge" calls , run the sketch.. LED13 flashes every second.

[mschlenker]

OK, would you please test with Paul Stoffregens modified version: https://github.com/PaulStoffregen/Bridge A zip file can be obtained here: http://cdprojekte.mattiasschlenker.de/nuage/Bridge-modified-1.0.2.zip

...another test for the Yún side will follow in five to ten minutes.

[mschlenker]

OK, when logged into the Yún, the command run-bridge should start the bridge. It takes over current terminal, so you cannot type anymore. Start a second SSH login to verify that the bridge is running. If this succeeds, do cat /etc/inittab. The last line should be:

ttyATH0::askfirst:/bin/ash --login

It might be quite possible that other software installed via opkg changed the inittab to enable it's own way of serial communication.

[allairgoo]

I have installer the 1.0.2 modifed lib. On the first windows : run-bridge re-upload the sketch with bridge & console. On the 2nd windows : ps show 'python -u bridge.py' running. If i run a 'telnet localhost 6571' to see the console.... 1st windows mention "Killed" , this means run-bridge has been killed

the last line of inittab is correct.

[mschlenker]

OK, so the Yún side seems to be alright. Could you know please try to compile my simple example with the modified version of the bridge and test if you are able to get a Console with this version of the library. There might be subtle differences in the way the Bridge is initialized.

[allairgoo]

indeed this was already with your simple example compiled with your modified lib

[mschlenker]

Ah, now please reboot the Yún and test again. Just one instance of the Bridge can be active at once.

[allairgoo]

Yun rebooted. Sample source sketch (Hallo Welt!) with your lib uploaded & run-bridge launched on a 2nd ssh windows

PROGRESS : telnet localhost 6571 won't crash the run-bridge. A 'python' process is seen. BUT no display 'Hallo Welt!' on the console, and Led13 is not flashing.

[mschlenker]

This time please do not do "run-bridge" in the second terminal. Reboot the Yún, reboot the 32u4 side and then try to connect either locally ( telnet localhost 6571) or remote (Serial monitor).

[allairgoo]

• Yun rebooted ( unplugged from current source)
• Hallo Welt script uploaded
• telnet localhost 6571 => 'can't connect to remote host (127.0.0.1): Connection refused' (no python launched seen in 'ps').

[mschlenker]

Did you add software to the Yún? A while ago I ran into similar problems and did a factory reset to delete all modifications I did to the Yún. In the meantime I moved to "my" Yún implementation (RPi+shield) which tends to be a bit more robust (lower baudrates, real gettys).

Is a factory reset reasonable for you?

[allairgoo]

OMG !!!! not sofware I was using a I/O shield it is supposed to be only hardware. I had it removed, and now it's working ( but my problem is different now ) : telnet localhost 6571 Hallo Welt! Hallo Welt! Hallo Welt! Hallo Welt! Hallo Welt! Hallo Welt! Hallo Welt! Hallo Welt!

[mschlenker]

Probably the IO shield used serial communication. Or tried to use....

[allairgoo]

YES he uses serial communication and it's vital for the sensor I Use. http://www.dfrobot.com/wiki/index.php/IO_Expansion_Shield_for_Arduino_V7_SKU:DFR0265

I have a sensor with serial communication on it. I did also test with a I2C device (LCD screen)

[allairgoo]

So it seems that there is incompatibility between this shield and the bridge lib of the Yun. I'm going to write a bug report to them. And It had worked a few hours until something happened.

Interresting crash with the shield

cat /tmp/bridge.py-stderr.log Traceback (most recent call last): File "bridge.py", line 87, in res = pr.process() File "/usr/lib/python2.7/bridge/packet.py", line 123, in process self.processor.run() File "bridge.py", line 49, in run runner.run() File "/usr/lib/python2.7/bridge/console.py", line 60, in run self.socket_receive(sock) File "/usr/lib/python2.7/bridge/console.py", line 78, in socket_receive chunk = client.recv(1024) socket.error: [Errno 131] Connection reset by peer

[mschlenker]

Is there an XBee plugged in?

[allairgoo]

no Xebee juste this https://www.dfrobot.com/wiki/index.php?title=PM2.5_laser_dust_sensor_SKU:SEN0177

[mschlenker]

Just this...

This is sending/receiving on the serial port making all serial communication bogus. Please move communication with this sensor to SoftwareSerial - and please leave this issue open for now: You did not ran into some bug, but a documentation issue: When using the bridge do not use serial communication to sensors or actuators on the same interface!

Maybe @00alis will take a look on this?

[allairgoo]

I have posted a bug report on DFrobot forum (vendor). What is strange is that it worked 9 hours :-/ And I use the library from the vendor https://github.com/Arduinolibrary/DFRobot_PM2.5_Sensor_module/blob/master/PM2_5SensorDemo.zip?raw=true

[mschlenker]

No it's not strange at all.

You actually can have more than two participants on a serial communication "bus" as long as the communication itself is mutually exclusive (looking at time frames) between exactly two participants. You might have modified a tiny bit of code that leads to more "traffic" thus breaking both ways of communication.

IMHO:

1. Every third party library that uses serial ports should provide a way of setting an arbitary serial port (even soft serial) before being accepted thru the library manager
2. The doc (of the bridge and the 3rd party lib as well) should hint on potential conflicts

[ffissore]

This kind of problem resembles to the Bridge library requiring exclusive usage of yun hardware serial. Please consult the yun forum for a lots of similar cases. Many of them unfortunately ended in declaring some shields incompatible with the yun: they work fine until the sketch uses the Bridge, and using a yun without using the Bridge (most of the times) is pointless