Firmata is killing times in its execution, there is a lot inside and the plugin varies from version to version.
As u7angel said , I would considerate to use rs232 node with your own protocol , using bytes or osc formated messages is really more simpler, without dll fights (what the hell a dll for com with serial ports?)
Depends of your project and needs
In a rs232 com you will never have so much troubles
no i did not say “use rs232 with your own protocol” i said, if you rely on using firmata in any way and you own a UNO, you can patch the communication to firmata with RS232.
the uno Arduino can be reprogrammed to be recognized as … other USB keyboards, mouse, joystick … usually use their sensors to command … already led only with the rs232 as above…is that it uses a USB Atmel, not from FTDI that is most popular.
…making firmata probably obsolete. good point.
I think the Arduino uno is more practical in program open devices… midi, dmx, etc …
hi all.
fighting with firmata is quite a loose of time when you can communicate truth usb/serial directly with arduino. It was a good shot for music usage, but if you use it with VVVV, well fare more quicker to build your own protocol and routines than relaying on hudge developpement killing this tiny proc capabilities. As u7angel said, firmata is an obsolete manner if you are note working on musical heavy canevas.
no difference between uno and 2009 except for drivers: ftdii are used by dmx devices and some confusion may occurs for people working with enttec open AND 2009 on same computer. UNO wasnt a revolution, only a driver and license problem wich was a good choice. You can now coexist on same computer OpenDMX and UNO without fighting to know wich one is wich one.
yours ;-)
I’ve always had a problem tracking down easy to digest information of how to get multiple channels of data from vvvv (or whatever else) onto the arduino and then use that data to manipulate pins on the arduino.
I’ve recently made some advancements though and plan to upload some examples with vvvv patches for people that have also been struggling.
One issue with this as opposed to firmata is that it is not easy (at least for me) to create a dynamic system where you can configure inputs and outputs externally, as you can with the firmata plugin. This means that someone taking this approach will have to be prepared to dig in a bit and change some code to configure it to their needs. A benefit of this though is that the code stays much simpler and easier to understand, increasing the chance of learning what’s actually happening.
hi mrboni, here is my canevas for whitecat.
its the easiest way i have founded for the moment allowing a multi configurable sketches: a definition of in and out is done in the sketch.
the sketch is waiting for keywords ( SD/ ) to send its data, avoiding to pass thruth a timer in the arduino
It allows to write and read data simulteanously
here is the doc, i think this is something easely doable inside VVVV to redo this sending and listening procedure i have developped in whitecat:
http://www.le-chat-noir-numerique.fr/whitecat/dokuwiki/doku.php?id=configuration_arduino_eng
There is keywords,( 3 letters) , bytes sending ( asvalue node), and /0 to close the invoice
hope this could help you or anyone
whitecat_arduino_UNO_bret75_V1.zip (2.2 kB)
Thanks K, I’ll take a look. Sounds great.
For anyon else trying to achieve similar things themselves I found this useful - http://jhaskellsblog.blogspot.com/
hi mrboni about protocol, you need to send SD/ at the rate you want but not continuously or the serial buffer will be overloaded
code you have forward is more osc like
sketch i m proposing is made of little keywords, at beg ( SD/ DO/ PW/ AN/ ) and at end ( ED/ and /0 caractere).
in between bytes arrays with values from 1 to 255 ( 0 is outputted in my whitecat because of the lib serial i m using)
this can perhaps puzzle everyone, but I believe its more quicker, as just keyword is readen, and bytes directly interpreted from the chain. I have used it with up to 50 channels by envoice. actually configuration is at 9600 bauds, but you may want to go more quicker, especially if big arrays.
i think the drawings with sending orders would be enough to undrestand.
ok, i will release in contrib a patch wrking with this sketch. anybody around: is there need of other documentation for sketch modifications ?