next topic »

[on:]

I'm running into some challenges reading pin status with firmata.  I am currently using Firmata.net, which looks like a nice clean and functional client.   I've also tried a couple of different firmata clients, including the firmata test application from firmata.org, without any luck.

I have also made sure I've updated the library with the latest firmata source and sketches.  I am running the StandardFirmata sketch. 

I am able to turn the LED on and off using digitalwrite, but I am getting the value zero for both analog and digital reads.  It appears to be sending the analog data back in the main loop when I view it in serial monitor

Any hints?

[Reply #1 on:]

Any hints?

Perhaps someone from the Firmata team will be along to answer your question. It hasn't happened yet, but there is always hope.

[Reply #2 on:]

If your heart isn't set on Firmata, you could try Bitlash + Bitlash Commander:

https://github.com/billroy/bitlash-commander
https://github.com/billroy/bitlash

-br

[Reply #3 on:]

I have tinkered with bitlash. Firmata's protocol is far better for my proposes.  (And I'm not implying bitlash actually has a protocol..) 

If your heart isn't set on Firmata, you could try Bitlash + Bitlash Commander:

https://github.com/billroy/bitlash-commander
https://github.com/billroy/bitlash

-br

[Reply #4 on:]

Any hints?

Perhaps someone from the Firmata team will be along to answer your question. It hasn't happened yet, but there is always hope.

What are people using then?  I haven't found anything buy firmata in the .NET world that has a remotely complete client api to call functions on the board.   It looks like a great fit, conceptually.

[Reply #5 on:]

It looks like a great fit, conceptually.

Then use it, conceptually.

The problem is that no one is maintaining firmata for the Arduino, making it handle new boards and new USB-to-serial chips.

What most people are doing is putting the intelligence on the Arduino. After all, that's why most people bought an Arduino. Not because they need to attach peripherals to the PC. If you still need to do that, develop and implement your own protocol. It is pretty easy to send something like "R,D,12" to the Arduino, and have it figure out that you want it to read digital pin 12. "S,4,0" to set pin 4 to LOW. "S,5,156" to set the PWM value of pin 5. "R,A,3" to read analog pin 3.

The advantage is that you can do things like "P,6" to read the PING sensor on pin 6, which you can't even think about doing with Firmata. Plus, your protocol will expand to additional boards and USB-to-serial chips.

You can even add error checking, so that "R,A,42" or "S,134,2903" returns an error message, instead of a meaningless number.

[Reply #6 on:]

Of course, you could write the code to parse and execute Paul's proposed command language.

Or you could install Bitlash and have the same commands already available, and readable by humans:

Code:

print d12
a5=156
print a3

Then, when you add your ping sensor, you can add a little C code to the project to extend the language by adding the new function "ping", so you can say:

Code:

print ping()

Which is more important for your project, I wonder: the protocol, or working code?

Cheers all,

-br

[Reply #7 on:]

Despite all the high horsepower technical problem solving occurring here, I did manage to get this work, more than conceptually. 

For other folks benefit, change the sketch variables to analogInputsToReport and sampingInterval to a good starting point (1 and 50 in my case), so the client has a reasonable chance to attach and start monitoring without too much noise.  Other than that i have been able to put the firmata sketch through its paces on the leonardo and it looks fairly solid.  No changes other than the above.   Unfortunately, the same cannot be said of the .NET clients out there...  I ended up writing my own which is frustrating. 

PS:  Ping is trivial with an additional call back.  So is just about any other library call within the context of firmata, so I am struggling with all the bashing.  The protocol is solid, the sketch looks good, I don't see any limitations in terms of extending it.  The problem is there aren't any decent clients in the .NET world.

[Reply #8 on:]

PS:  Ping is trivial with an additional call back.  So is just about any other library call within the context of firmata, so I am struggling with all the bashing.

You want to explain how you got ping() to work? Plenty of other people want to use ping sensors with Firmata.

[Reply #9 on:]

PS:  Ping is trivial with an additional call back.  So is just about any other library call within the context of firmata, so I am struggling with all the bashing.

You want to explain how you got ping() to work? Plenty of other people want to use ping sensors with Firmata.

Really?  Did anyone look at http://www.firmata.org/wiki/Proposals?  All three are a very very simple extension of sysex.  An example below as modifications to standard firmata.  This is just illustrative and has not been tested on anything real. An alternative approach is to use a new top level command and firmata.attach() to it.  Also note, this would require client changes to deal with the new custom sysex message type and ascii conversion from println etc.

Code:

...
#include <Ping.h>
....
#define SYSEX_PING    0x67 // kev_rm's new ping protocol command
....
void sysexCallback(byte command, byte argc, byte *argv)
{
..
switch(command) {
..
case SYSEX_PING:  
   Serial.write(START_SYSEX);
   Serial.write(SYSEX_PING);
   Ping ping = Ping(argc,0,0);
// put responses from all three methods in the sysex message
   Serial.println(ping.microseconds());
   Serial.println(ping.inches());
  Serial.println(ping.centimeters());
  Serial.write(END_SYSEX);
  break;
...
}