serial and arduino
Hi,
since OSX.9, I have many problems communicating with arduinos (diecimila) from Max with the serial object.
I'm aware of the fact Apple designed its own FTD driver, which has to be replaced with FTDI's one. The Arduino IDE does work without a problem.
With Max 6.1.9 (32bits) and previous versions, Max freezes very often (almost always) when I close serial's connection. I have to kill Max and restart my Mac, I even need to force the shutdown!
I tried with Max7, and got the same behaviour.
So I tried with jasch's good old comport object in Max6.1, which I used back in the days when there was no close message in serial.
It seems to work much better (no freeze nor crash yet). Thanks jasch, if you still read us!
So, do some you you have any experiences? I see many people speaking about arduinos, but no complains about serial's close
What about X.10's FTDI's driver?
Thanks in advance,
p
Hi Patrick,
I did almost the same tests a few days ago (Arduino Nano, 10.9, Max 6.1), and came also to the conclusion that the original FTDI driver is unsuitable with the serial object, exactly for the same reason (hangs when closing the connection or the patch). However, it seems that the Apple FTDI driver indeed works better with serial. The problem of this driver is that you cannot directly upload a compiled firmware on the arduino. However there is a trick: press the reset button of the Arduino right after the IDE starts to try uploading (http://forum.arduino.cc/index.php?topic=198539.0). This is not really convenient, especially if the board is in an enclosure, but it works for the moment for my tests.
While we are at it, I have a question for you: how do you manage to send values to the Arduino with comport? I just tested, I can receive values from the Arduino, but am unable to send anything that the board understands. I guess it has something to do with the configuration of comport, but I tried almost every combination and I'm stuck.
If it works better with comport, why don't you use it instead of serial? It may be worth refreshing the code for the newest API, especially for Max7.
Best
Alexis Baskind
Have you guys ever look into the Teensy board?
https://www.pjrc.com/teensy/
No serial in Max (which as always been unreliable for me).
You can program it with the Arduino IDE.
using Teensyduino.
With the teensy's MIDI library you can get
direct midi to [notein][noteout][ctlin][ctlout]
no [serial]
Never had crashes or freezes or anything!!
I ain't never going back to Max/Arduino combo.
phiol
In My own exp. serial object has been working great using ftdi drivers
I had problems with bluethooh via serial
this was a hardware problem and permitions
the teensy board is great option too.
but if you need wireless data you have to go via serial port with xbees or similar bugs
@Balam:
Wireless xbee: good point. Never had the situation yet.
So teensy galore!
Teensy looks indeed really interesting on the specs: 13-bit A/D instead of 10-bit for Arduino Nano, smaller than the Nano, MIDI-compatible...
The thing is that I need a hi-speed connection between the board and the computer, ideally at least 200fps, and for every frame I have to send 9 information (raw data from IMU sensor) in 10 bits (Arduino) or 13bits (Teensy). In MIDI it means 2 7-bit words pro raw data, so at least 18 MIDI information (MIDI-CC for example) each time, so the communication should run at least at 3,6kHz. MIDI is however designed only for 1kHz, even though it's sometimes possible to get much more (with virtual MIDI communication between two software for example).
Do you guys have an idea of the maximum bandwidth in MIDI mode with the teensy?
Best
Alexis
I use the teensy alot with Max and it works great both in Midi mode and serial mode, the Teensy works at 12mbps for USB communications so it's very fast. I recommend it highly.
Teensy are great indeed, but I use a lot of old arduinos (mostly diecimila) with self-made shields. Finally for my latest project I had to work with an old Mac mini, under X.6 and had no problem (I even used comport to communicate with one arduino and serial with another).
Alexis, I will try you trick as soon as I can. Not very convenient when there is no reset on the shield, but worth a try!
I used comport only to communicate from the arduino to Max, not the other way round. If I remember well (sorry, I don't have Max at hand), you can send only bytes, one by one, so the code in the arduino has to be adapted (that's one of the reason why I don't simply use comport instead of serial).
Does the serial monitor in the arduino's IDE still work with Apple's FTDI?
Any experience with X.10?
@Patrick, I have the same issue with arduino and Max: very often, Max freeze when I close the serial port, and I have to relaunch my computer to get it back to work. I tried to find a solution, but for the moment, I didn't find it.
Same problem with xBee of course because it uses the serial port as well.
I've seen that; I need to give it a try (for the moment, I did'nt get enough time to): http://cskonopka.github.io/arduivis/
For the Arduino reset button, the fact is that when you upload your code on the arduino, the arduino needs to reset to get in the bootloader and upload the code (for example, you have to do that on the Arduino Pro Mini from Sparkfun). That's all. When you know that (and when you know when you need to press the reset button), you can upload your code easily, even via xBee if you need to :-)
Not sure if the Arduino IDE works with Apple's FTDI, but should be, if you can upload your code on the Arduino. You could also check with CoolTerm; it's also a serial monitor, different from the one in Arduino IDE.
wondering how you guys use Apple’s FTDI,
driver set.
I have install the ftdi drivers from
Thanks to all for the tips, the teensy looks worth a shot, I will try it soon I guess.
@Patrick: Thanks for the info about communication from computer to arduino via comport, it confirms what I noticed (the Arduino indeed receives the info but does not understand it). I don't have 10.10 on my machine, so I haven't tried yet.
Alexis
Hi,
Some news about the "send to Arduino" problem with comport: I dived in the code, and actually it's quite normal: the object does not accept lists. So it's not a bug. I don't have an Arduino with me right now, but I guess that a simple "iter" right before comport should make him happy.
BTW I did compile successfully a x86/x64 binary of comport using the newest sdk (6.1.4), by doing slight modifications on the object declarations to make it compatible with the new class system. It loads successfully on Max 7 as well. I'll try it with the Arduino in a few days to check if it works well.
Alexis
@Alexis. I'd be happy to test your port (while you're in XCode, maybe it's time to adapt comport's interface and make it accept lists, floats, etc. ;-).
But I'd be really happy to hear some comments from c74 folks!
Hey there, I've been looking at the serial object a bit recently (mostly Windows port-discovery issues, see https://cycling74.com/forums/serial-obj-doesnt-see-dev-b-com-ports-in-windows-hc-06-bluetootharduino for updated externs). I am not aware of port-closing issues on either platform, although there have been some anecdotal reports. If you have a patcher which I can use to reproduce the issue, I'd be happy to take a look.
Jeremy
Hi Jeremy,
Thanks for your answer.
If it can help, I will send you something as soon as I can (which may unfortunately take a couple of days).
But I have crashes with very simple patches (polling the port and displaying the values) when I close the port, even when I first stop polling. I generally use high baud rates. Those crashes didn't happen when the Macs I use were still under X.6.8, it started wen I jumped to X.9 (I didn't install X.7 nor X.8). As I wrote earlier, those are not simple crashes: Max freezes, it may even be difficult to kill it, and a reboot is generally necessary to reuse the port. I use the latest FTDI driver (not Apple's)
p
Yes, that would be very helpful. Why aren't you using the built-in serial driver, if I may ask?
Thanks!
Jeremy
Hi,
Here's my port with the sources and the Xcode project, absolutely without any guarantee since I cannot test it at the moment. Making it accepts lists would be easy, but I'd prefer not to do it myself, since it's not my code (I just adapted Jasch's code for the new SDK), and also since it's not really clean to have two objects sharing the same name but with different syntaxes. And as I say, it should really not be a big deal to do that in max patching. But Patrick, what do you mean by making it accept floats? At the end it's bytes anyway, so you need to convert floats in a flow of bytes.
My main motivation to test comport instead of serial is that I read in a previous post that the timing is more accurate. The code looks however quite similar, since the timing is also done in the max scheduler, like the metro+serial combination. I'll check that when I can.
Alexis
Jeremy, I use FTDI's driver because I can't upload code from the Arduino IDE with Apple's driver. There is a discussion about that here: http://forum.arduino.cc/index.php?topic=198539.0
Honestly, I didn't try Apple's driver with Max, as I constantly change the code in the arduino.
Alexis, I'll try asap. I understand your reticence to change the functionally of comport. Didn't you notice the small smiley ;-)
OK, I'll investigate the FTDI driver when I get a sec, but please send me your materials as well.
BTW, on OSX 10.10 with Arduino 1.06, I can communicate just fine with the board via the Arduino software. I can open/close the port in Max, upload new sketches to the board, and back and forth. Not sure if this is just new as of Yosemite, though. I'm a little reluctant to install a 3rd party driver on my primary work machine, though. I'll do some research, but I hope this data point helps someone.
Jeremy
OSX 10.10.1
Max 7.0.1
I open/close the serial line to my Arduino Uno a lot. Never a hitch. I'm running the plain old vanilla Apple installation of OSX. Arduino connected to usbmodemfd131 at 57600 baud. In the example below I fetch button presses from an 8x8 matrix (yes, sort of a Monome) attached to a DIY B64 shield. No matter how often I open/close the serial port, it keeps chugging happily along.
Yep, but the Uno doesn't use a FTDI chip, so no FTDI driver is needed!
Anyway, good to know it does work!
p
this might be a bit off topic. but in general i find serial connection a bit unreliable - espescially when the connection is open for long lots of data are exchanged. some time ago i completly abandond serial connections and moved to arduino ethernet ans osc instead. works great for me...
@Jeremy, I couldn't reproduce the crashes yet (which is a very irritant feeling). AFAIK the only difference with the setup that crashed is the arduino (also a diecimila). When I got it back I'll try again…
Maybe Alexis has more luck (?) and can reproduce his crashes?
@Jan. You're right, I do that too (even without OSC) but sometimes I need 16 digital outputs from the arduino, so I need all the pins (and I'm too lasy to try to use a mux chip on my shield to drive 16 relays)
Hi all,
@Patrick: I did a large number of tests in the last days, using serial, comport (my build), Apple's FTDI driver and the FTDI driver provided by the supplier. It's quite clear from those tests that:
. the FTDI driver provided by FTDI is not stable when it's being pushed into its limits: max hangs really often especially when closing, and also the whole machine crashes from time to time. Apple's FTDI driver is definitely more reliable
. comport is really more accurate than serial for the timing. The cherry on the cake is that it supports a baudrate of 230400 bauds (though not completely tested yet)
@Jan: I don't use OSC because I need the latency to be as little as possible
Speaking about latency, I follow Phiol's tip, ordered a teensy 3.1, and received it yesterday. The results are incredibly better in terms of USB serial latency than the arduino nano. I cannot test it fully yet because I'm still waiting for other parts, but it's really promising. I did not try MIDI yet, although I'm not sure it's gonna be better than serial.
Alexis
I haven't had issues with FTDI with communication but I have had it freeze my computer several times when I'm trying to connect an XBee. Also, it froze my computer when I tried to close the serial connection (FTDI board via SparkFun) while data is flowing. Sometimes it would just freeze when I connection, pretty much immediately. I've had this happen with OSX 10.5-10.9 but I have no idea about the inner-workings of such beast.
The problems I had quite often with the FTDI non-Apple driver, when max doesn't crash, are big conflicts with the scheduler: if the data rate is too high (in my case bigger than 20000 bauds or so), all information delivered by serial is not tight any more, and slows down the GUI in a weird way: even the Max shortcuts like cmd-S, cmd-Q or cmd-W do not respond any more. And after a while the whole computer just crashes. With the driver from Apple, I did not encountered such issues. Tested on 10.9, which can explain probably why: the FTDI driver is given for 10.5-10.7.
@alexis In terms of baud, I always seem to have trouble with higher baud rates. For some reason, not sure why, 9600 has always been like a rock for me. And the speed is rather efficient too. This observation came from running 60 LED 1m strips simultaneously and 9600 ended up being the most reliable. When using higher rates, I experienced similar halting issues, the buffer is being overloaded and then it seems to permeate into other systems since its requiring so much power. I could be absolutely wrong about it since I don't know the insides but from observations, that is what I shall deduct. But this was with a Mega/Uno.
@alexis, the only difference between serial and comport (as far as timing is concerned) is probably simply that the serial object defers output to the low-priority thread (presumably to avoid interrupting the timer or audio thread with a synchronous read operation). I don't know offhand how comport works in that respect. Maybe we should make that an option, though, for folks who need it.
For higher baud rates and lots of data, you might want to investigate the "chunk" attribute to serial, which permits output of multiple values at once. You might also want to experiment with adjusting the buffer size. The object will attempt to fill its buffer (2K), and if there is a lot of data waiting, this might take longer than you'd like for your application. Reducing the size to 256 or 128 might improve responsiveness. The deferral of the output may still be an issue, though.
I don't think I have any Arduino hardware which requires a special FTDI driver (Uno and Mega256) -- is there a newer model which requires it, or is it only for the older boards? I did just find an old "Digital Arduino" with an ATMEGAB-16PU processor lying in a drawer, maybe that's worth trying.
Jeremy
For Max 7 users, here are some objects to try which (in addition to fixing the communication problems reported on Windows) implement non-deferred and polling output. See https://cycling74.com/forums/serial-obj-doesnt-see-dev-b-com-ports-in-windows-hc-06-bluetootharduino/?reply_id=314789 for more information.
Jeremy
worth to mention
for windows users
see this
Thx Jeremy, is that an official incremental update?
... oups wrong threat! - sorry!
@Jan, these are unofficial in the sense that we reserve the right to make further changes, but with that caveat, you can probably expect these fixes and features to be in 7.0.2.
The only Arduino hardware I have seen (feel free to call me out if incorrect) that needs FTDI related material is the FIO and a few others. But I had no issues installing the proper FTDI needed so I could program the board. The bluetooth connectivity stuff is cake, I made a few tutorials for it today/tonight, video in the coming days and then will do a write-up or something. I have noticed a significant increase in serial buffer crashes in Max7, I've had it crash a lot so far compared to Max6. I'd only go back to 6 exclusively for serial projects, I only had 6 crash on me a handful of times with the serial buffer.
Here is a link to the bluetooth examples. https://github.com/cskonopka/arduivis
I'm also cooking up some simple python examples for Arduino/Max and also some buffer latency patches. Also! A linesman phone patch so you can log numbers from a rotary phone.
In terms of the OSC vs Serial conversation, I personally like serial more and it can handle hours of continuous use. Not saying OSC can't, but I've seen disrupts with extended use. Wifi things are great but susceptible to atmospheric change. I've done a fair amount of performances where its cut out, not a fun time. Whereas serial is really robust and is a standard, so there is a lot of documentation on the the matter. Plus, the use of the buffer really depends on the project you are working on, so research is needed to find the right balance. When you do, you're gold and usually don't have to worry about something breaking unless there is a completely abstract hiccup. The largest system I've done so far is a 50+ serial stream (40m of LEDs) w/OSC brainwaves and jitter 3D data visualization all at once. The serial never messes up but the MindWave tends to give me issues.
I'm trying hard to streamline this process for everyone, this being said, what are you looking for in terms of serial projects?
Hi, while anecdotal reports of crashiness are better than nothing, crashlogs sent to support might actually cause something to be done about it. On OSX, there were no code changes between the serial object in Max 6/Max7 (beyond changing the function signature of main()) until the interim objects I posted yesterday (nor on Windows, but I posted some interim objects late last year to try to fix some Bluetooth enumeration problems), so I tend to believe that the reported crashiness is coming from somewhere else. But without more information, it's hard to know.
Thanks, Jeremy
@Jeremy Interesting. I will start looking back at prior projects and look to see what issues I had with the [serial] object. From there, I will try to recreate some of the issues. The FTDI issue with XBee, if you connected the network in the wrong direction or missed a step, it would freeze my entire computer. The freezing I experienced with Max7 lately is when the [serial] object is open and then I change the baud attribute within the object, [serial] freezes. I get I'm forcing it to push the envelope, but the hiccup of upwards of 5sec is something I never had in 6. Even right now when I created the [serial] object, I got a random pinwheel. Just weird. I'm not upset or anything, just confused and want to understand. Again, I will start to document hiccups between projects and will let you know. It could just be me though, I did break a MacPro Wifi card by unplugging a monitor. Makes no sense, fried the board and even the visiting tech had never heard or seen of anything like that. I throw errors, its my job and addiction.
I have been experiencing crashes with OSX 10.9.5 Max 6.1.7 Lilypad Board>>Serial 9600(Baud). However, I took a tip from the patch @HZ37 posted and added the 'autoopen 0' mechanism into my patch and now the communication seems to be relatively stable. I am now able to transmit at 38400 Baud (haven't tried any higher).
It would seem that my Max 6 didn't like having an open serial port on startup/whilst disconnecting/connecting the lilypad.
Worth a try if you're having problems.
Nick