I can't use:
Bridge.messageAvailable()
Bridge.readMessage()
Bridge.writeMessage()
why? and how do I use?
Are there some examples?
thanks
Maybe I have to wait?
Can you post your sketch?
Instead there is a reference in the web to these funtions
In fact you can't use them. Or maybe I don't know how.
this is a little sketch:
#include <Bridge.h>
#define LENG_BUFFER 200
int Buffofints[LENG_BUFFER];
int Bit = 0;
int Pin = 13;
void setup() {
pinMode(13,OUTPUT);
Serial.begin(115200); // initialize serial communication
Bridge.begin();
digitalWrite(13,Bit);
}
void loop() {
if (Bit == 1)
{
Bit = 0;
}
else
{
Bit = 1;
}
digitalWrite(13,Bit);
Bridge.readMessage(Buffofints, LENG_BUFFER);
delay(500);
}
And this is the compillation error
Arduino: 1.5.4 (Windows 7), Board: "Arduino Yún"
xxxxx.ino: In function 'void loop()':
xxxxx:24: error: 'class SerialBridgeClass' has no member named 'readMessage'
Right. The documentation is wrong. Bridge does not have readMessage, Mailbox has
Your sketch becomes
#include <Bridge.h>
#include <Mailbox.h>
#define LENG_BUFFER 200
uint8_t Buffofints[LENG_BUFFER];
int Bit = 0;
int Pin = 13;
void setup() {
pinMode(13,OUTPUT);
Serial.begin(115200); // initialize serial communication
Bridge.begin();
digitalWrite(13,Bit);
}
void loop() {
if (Bit == 1)
{
Bit = 0;
}
else
{
Bit = 1;
}
digitalWrite(13,Bit);
Mailbox.readMessage(Buffofints, LENG_BUFFER);
delay(500);
}
Will fix it asap
Thanks for the response.
Thanks for this awesome project.
And how would one solve the "Bridge.messageAvailable()" call?
I would like to get notified or have a trigger indicator when there are new values in the bridge dictionary which I can grab using Bridge.get().
BTW: Which API ist best? Bridge.get/put() or YunServer/YunClient?
mamu:
And how would one solve the "Bridge.messageAvailable()" call?
It's Mailbox.messageAvailable()
I would like to get notified or have a trigger indicator when there are new values in the bridge dictionary which I can grab using Bridge.get().
There is no such notification, you have to poll for specific keys or invent some other way. For example, someone could put associate a value to a key and the sketch could receive a message (with YunServer/YunClient) with the key to use to fetch the value
BTW: Which API ist best? Bridge.get/put() or YunServer/YunClient?
It depends: YunServer/client is for telling the sketch what to do, Bridge shared storage is for sharing data between the 32u4 and the linux (and, optionally, internet)
[quote author=Federico Fissore link=topic=192122.msg1438533#msg1438533 date=1382473644]There is no such notification, you have to poll for specific keys or invent some other way. For example, someone could put associate a value to a key and the sketch could receive a message (with YunServer/YunClient) with the key to use to fetch the value
[/quote]
But polling is not a very good solution. Maybe this could become a feature request?
Thanks for the reply.
But one could mimik the server/client by putting some special command values in the Bridge dictionary. Is there a performance or memory benefit of one over the other? Because using YunServer/YunClient does not leave that much memory for the acutal sketch.
BTW: Do you know why exactly the same sketch compiler for the Nano or Uno is 6K in size and for the Yun it is 9K?
I found some reasons when not to use YunServer/YunClient in my sketch: It consumes another 2K of the limit resource memory. So if you are memory restricted or concerned use Bridge.
And in my eyes, even Bridge is not the best solution: One as to learn a new class and is uses more memory than simple Serial.
So I would like to ask the Yun team, why don't you implement a listener on the Linino site (I would like to see node.js here using SerialPort) and on the Arduino sketch site, simply use Serial to read and write data on the wire? To me, that would be more straight forward.
Agree but you can then lose data if you're not always reading it from Serial, since its buffer is very small. Bridge avoids the problem by making your sketch to command the linux side (that has much more memory) and asking for data: it puts you in control of the data flow
Okay, regarding the current Serial implementation and its buffer size you are right.
On the other hand, Serial supports an available() function and one could change how Serial works. Why not buffer the data on the Linino site and transfer it byte by byte as Serial does the actual read?
That's exactly what Bridge does
Nope. There is another API to deal with (bridge) and no Serial <-> WebSocket support.
Sorry, are you saying bridge is not buffering data on the linino side and giving it to the sketch only when this requires it?
Sorry, my post was misleading:
I wanted to say that bridge does not react like Serial does.
It has a different kind of API and programming appeal (put/get/no available). It is a different beast 
Enabling a better buffer handling for Serial1 to fix the problems you mentioned would be a better solution, make it easier to deal with in ones sketch, and ease the migration from former sketch writing.
I frankly don't know how I could improve Serial1 buffering from the 32u4 side.
It's done by the 32u4 serial "hardware" and not by code (AFAIK, I'm not an expert). The only way I see for improving the whole communication (and avoid losing data) is to buffer data where I write it (so on the linux side) because I can accumulate data in a hand made buffer instead than just writing it to the serial channel.
I'm humbly open to any suggestions as I'm not a hardware guru