next topic »

[on:]

Hi,

I'm trying to use firmata to send and receive information from processing. I'm using arduino mega.
I built an interface with 26 buttons (digital input), 7 knobs (anolog input) and a RGB LED (PWM): http://ligalingha.blogspot.com/2011/11/construcao-da-interface.html

The problem is that when I upload the 'allinputsfirmata' skecth I receive all the buttons and knobs, but analogwrite (LED) doesn't work.
when I use 'standardfirmata' the knobs and LEDs work and the buttons that are located at pins 22-46 stop working.

Is there a solution for that? Is there any other way to send and receive information from processing?

thanks,
1mpar

[Reply #1 on:]

Is there any other way to send and receive information from processing?

Of course there is. Ditch the unsupported Firmata crap and write your own protocol and implement it.

[Reply #2 on:]

@PaulS:
oh yeah??!!!
and writing a protocol replacement for firmata is Trivial ...right?... it will only take you just about 6 months......!!!?????

[Reply #3 on:]

and writing a protocol replacement for firmata is Trivial ...right?

Relatively speaking, yes.

it will only take you just about 6 months......!!!?????

6 hours would include time for a nap.

[Reply #4 on:]

Wow.....prove it I challenge you to do it in 6 hours  Let's see

[Reply #5 on:]

Challenge yourself. It isn't that hard. Start with one switch, get that working, then extend.

[Reply #6 on:]

Let's see

Firmata implements a protocol. A protocol is an agreed upon method of exchanging data. If the sender and the receiver agree that <R,D,4> means that the packet starts with < and ends with >, that R means read, that D means digital, and the the value is the pin number to read, then reading the serial data is trivial. I've posted code to read start- and end-of-packet delimited code many times.

Parsing the serial data is trivial, too, since there is a consistent delimiter between tokens. I've posted code many times that illustrates how to use strtok() to parse data.

A simple if statement comparing the first token (the what to do command) to R is trivial. If the command is not R, then an else if to deal with S (set) is trivial.

The pin type and value need to be parsed, if the command is R, or the pin number and value need to be parsed, if the command is S. Trivial.

Having the pin type defines whether to call analogRead() or digitalRead(), if the command is R. The pin number to read is known. The return type is int, in both cases, so returning a value is the same in both cases.

If the command is S, the pin number (and a knowledge of the board) defines whether to call digitalWrite() or analogWrite(). Removing the knowledge of the board from the equation would be simple. Add another command, A, for analogWrite() and leave S strictly for digitalWrite(). Neither analogWrite() or digitalWrite() return a value, so there is nothing to return to the caller.

Actually putting this together in code is trivial.

One could decide that S for set is not a good idea, because S should be for servo. OK. So change S for set to W for write, and make S stand for servo.

So, now we have a 4 commands - R (read), W (write digital), A (write analog), and S (servo N to position P). Each is followed by two arguments - pin type and pin number or pin number and value. As illustrated, implementation is pretty easy.

What else would you want a PC application to be able to make the Arduino do?

Actually doing the implementation of the Arduino code could be done, and tested, in 30 minutes.

A drink and a nap, and then we'll tackle the PC side. That won't take but about 10 minutes.

[Reply #7 on:]

I expected more fundamental stuff from a guy like yourself. if I recall we are talking of replacing the Firmata protocol all together. then to that invovles two things:

- The PC side which you mentionned
- The Arduino Side which means that you will replace the FirmataStandard Library

I expected you to mention stuff like:

- Hardware Abstraction Layer that will support all atmege devices
- Backward compatibility with previous and current devices
- Writing your own Libraries for accessing low level register for atmega
- Not reusing any of the firmata libraries that you called 'crap' in your previous post

I guess I expected way more than what you have thought of that is why you 6 hours won;t even be enough to even think about any of the items that I oulined above

[Reply #8 on:]

I expected you to mention stuff like:

- Hardware Abstraction Layer that will support all atmege devices
- Backward compatibility with previous and current devices
- Writing your own Libraries for accessing low level register for atmega
- Not reusing any of the firmata libraries that you called 'crap' in your previous post

The reason they are not mentioned, is that they are not required. No complex HAL is needed. The Arduino isn't a PC, so there aren't a million different hardware configurations to support. There are some digital pins (some of which support PWM), some analogue input pins, some serial ports etc. Firmata holds this information in a header file (Boards.h), the IDE does the same (pins_arduino.h). You tell the IDE which Arduino you have, it knows what to do, and you can get the information in your sketch. Same for Backward compatibility, the IDE contains config data for all current and previous supported devices. And the same for the low level registers. The IDE uses avr-gcc and avr-libc, both ported specifically for Atmel AVR processors, and fully aware of the architecture.

You have access to the Firmata source code. Take a look at it. It doesn't do a HAL, or backward compatibility, or low level access any differently than a sketch that you write yourself. It does what Paul's code would do. It reads from the serial port, interprets what is sent and acts on it.

There is a place for Firmata. It's for those people that are prepared to put up with it's limitations, and don't want to learn some fairly simple coding.

[Reply #9 on:]

There are some digital pins (some of which support PWM), some analogue input pins, some serial ports etc. Firmata holds this information in a header file (Boards.h), the IDE does the same (pins_arduino.h). You tell the IDE which Arduino you have, it knows what to do, and you can get the information in your sketch.

Firmata doesn't work all that well on a Mega. It knows about the pins that do certain things only because you call the functions with the specific pin to use. It doesn't know that a Mega has more pins, or that certain of those pins are specific purpose.

If you want, in your PC application, to read from pin 47 on a UNO, Firmata will happily accept that command, and return crap because it can't actually read pin 47.

If you want, in your PC application, to PWM pin 18, Firmata is happy to apply that command. Nothing will happen, but Firmata won't scold you for it.

If you are writing an application on a PC to talk to an Arduino, I assume, and Firmata does to, that you can look at the Arduino, count the pins, and pay attention to whether a specific pin exists and has the capabilities to perform the task that you are setting for that pin.

Making the Arduino call you a doofus if you pass it an invalid pin number, or try to perform PWM on a non-PWM pin, or try to analog read a digital pin is all possible. But, Firmata doesn't, and I don't think that it is part of the protocol to perform that checking.

After all, the definition of protocol does not include error checking. A protocol simply defines a set of commands that both sides understand. Part of that understanding is knowing when to use each command.

It's for those people that are prepared to put up with it's limitations, and don't want to learn some fairly simple coding.

Exactly. It isn't rocket surgery to replace Firmata with a protocol that works. That it is not universal, or means little to anyone else, is not a reason for not defining your own for your use.

If you want to publish a protocol, and support it, you (or I) are free to do so. If you do, I would expect you to support it. The biggest problem with Firmata, in my opinion, is that it is not supported.

It is delivered with the Arduino IDE but there is no active support for it that I have seen.