Hangs on setting the output pins.

[nathanieles]

Tried to set this up using your example, the script seems to hang during setting the output pin.

board.output(13)

[HashNuke]

That's right MeediMusic. Someone else reported this issue by mail a few days ago. And he had this problem on a Mac. I have no problems here on an Ubuntu 10.10 machine.

Anyway, I'm going to start working on Firmata support. Once that's done these problems should disappear.

[dreamcat4]

I also have a mac and can report the same issue. Another thing you mention is wanting to add Firmata support to your gem. But that is already provided by another gem:

https://github.com/chrismetcalf/ruby-firmata

I think your arduino gem here is good to keep small, because the StandardFirmata (2.2) PDE uses ~9K. Wheras your smaller PDE uses only ~3K and provides similar features.

Here is a link to other known working Firmata source code (C++):

https://gist.github.com/831971

[HashNuke]

Can confirm this problem to exist on Ubuntu 10.10 But it happens only when you connect to the board the second time (ex: run the blink program once again). It seems to require a disconnect and reconnect after every program. Weird problem.

Spent 2 days investigating and trying to solve this with no luck. Spent a few hours today reading about firmata protocol. Ruby-firmata project on the other hand doesn't have digital_read working (in both the main repo and the fork). Which means that's broken too. Ruby-firmata seems to be a line-to-line port of python-firmata. If that was working atleast would have forked it to wrap arduino gem around it.

Whatever! tomorrow there's gonna be a fix for this arduino gem.

P

[dreamcat4]

Right!

Since yesterday I have been trying to add STRING_DATA support to ruby-firmata. For sending / recieving string data. I have an arduino UNO. Things were going well for a while... but gave up after running into this problem:

It almost seems as if the main Process() loop (when expressed in the Ruby language) is kinnda too slow to loop around. And therefore misses / skips / munges the serial buffer as its reading it. I looked at reducing the Baud rate a lot.

At 57600 baud: bad output / stalls immediately
At  9600 baud: worked for a little while.
At   600 baud: kept working for even longer.

https://gist.github.com/834031

I dont understand why because we would expect that the ruby serialport library we call to just buffer the input in our PC in a nice large buffer. So the findings seem rather strange to me. I dont know whats wrong - if its a communication setting or something else to do with Ruby.

With firmata_test (the wxwidgets C++ example) - the serial port communication speed can be much faster with no missed bytes or corrupt data.

You might want to consider implementing at least the main receive loop in C (as a Ruby 'C' extension). For ruby-firmata its calling parse() from within the looping run() function.

Here is a resource for serial port communication in C

http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/

[HashNuke]

Thanks for the link to the blog post. I've been giving serious thoughts to write a Ruby C extension and tomorrow's the day (now 1.14am here).

I dug into the code of the ruby-serialport library (https://github.com/hparra/ruby-serialport). It sounds like it was tailored to be ruby style instead of what it should have been (with raw data manipulation support). And the close method isn't hooked to a C-based serialport function but instead uses Ruby's IO class's close method. Please correct me if I'm wrong, I don't understand Ruby's C API, but I could identify the functions being hooked in the ruby-serialport repo's ext/native/serialport.h file

Anyhow, thanks god for opensource and github, we know when a library was last maintained and write/fork it :)

[dreamcat4]

Or if you dont mind ditching Firmata, then CmdMessenger is really the best thing to use over the serial port. Just forked it here:

https://github.com/dreamcat4/CmdMessenger

CmdMessenger is just ASCII messages. They then provided the necessary callback / message handler framework in the example .pde file.

IMHO you only really need Firmata if you want your Arduino to talk to other MIDI devices. In Firmata you send a byte - its split into 2 7-bit bytes to conform to the MIDI protocol. Which is more of a hinderance than a help!

CmdMessenger everything is 8-bit ASCII bytes stream with a user-definable seperator between cmds (eg CR or ';'). Therefore Serial communications are much easier to debug and theres even a hack to use the Arduino IDE's Serial Monitor.

So in CmdMessenger you'd just send a string:

<CMD_BYTE><LEN><DATA_BYTE_ARRAY><CMD_END>
for example command 'a', send n chars
a3DDD;
for example command 'b' send 1 digital value (0-255)
bX;  # (where X=ascii byte)

[HashNuke]

I've actually figured out that there are no problems with the current custom protocol that the library is using. Firmata seems like an overload with event listeners, etc. It's the ruby's serialport library doing the dirty job. I'm going to spend a day trying to fix it. Or else just write a new one. I'm diving into some neck deep ruby in my leisure time in the next few days to make ruby better for electronics (altho i'm a web dev). At some point of time, yes, firmata maybe be the way to go. But not now with these problems with ruby.

[HashNuke]

I went searching if serial commands can be issued via bash and be run via ruby's system() method. That way ruby's serialport library can be benched in the game. But it sounds like a bad hack since the windows guys will have to be sacrificed :)

CmdMessenger sounds interesting. I just skimmed thru the readme in your repo. I can use that as a reference to implement the serial stuff as C Ruby extention.

[dreamcat4]

CmdMessenger has been extensively updated since we last spoke. Details for version 2.0 are in the readme.

To use just upload the example sketch and try typing some commands in Arduino Serial Monitor. Example commands can be found at the bottom of sketch file.

[kirai]

I have the same problem on a Mac but it gets solved reseting :)

[HashNuke]

Ok I've switched from Ubuntu to Mac since developing this library. So I'll take a look and report back too.