Of course I`m willing to keep testing and if I can I will help to isolate this Bug.
It does not change, in both cases TeensyMonitor: /dev/cu.usbmodem2397461........ is written in the title bar.
Attachment 12172
Attachment 12173
Of course I`m willing to keep testing and if I can I will help to isolate this Bug.
It does not change, in both cases TeensyMonitor: /dev/cu.usbmodem2397461........ is written in the title bar.
Attachment 12172
Attachment 12173
Last edited by PeterG.; 12-06-2017 at 10:31 PM.
i have now not only restarted the Serial monitor, but also restarted the Arduino IDE.
now the Titlebar looks like you said, only "/dev/cu.usbmodem2397461 (Teensy)"
Still the same Problem..
Hmmm... ok, looks like the project is somewhere in the IDE, Java or JSSC.
I'm out of guesses for the moment, but I'll be thinking on this.....
Arduino switched from RXTX to JSSC a couple years ago. As I recall, they've since had to patch or maintain JSSC, though I don't recall the details. It's all buried somewhere on the old github issues.
PeterG - prior post had link to old TyCommander - it moved to github - between working with Paul if you want to see if this works - to find a solution to show your machine can be usable. The link updated in prior post is : github.com/Koromix/tytools/releases. Version is 0.8.8-11 - I wondered why I linked to something like 0.8.0![]()
Awesome - It seems: "You have shown your machine to be usable"
> Awkward wording to avoid pointing any fingers ... - Showing it wasn't some hardware problem causing the trouble or an id10t error - but a failure from the software at hand where functionality is possible.
When using BOTH - only one can claim the USB 'port' of course. That applies to Teensy Loader too - you may also see contention with Teensy Loader if both are loaded - you certainly need to click the blue 'Serial' icon to gray it to allow upload. I assume on MAC the 'Tools / Integrate to Arduino' will take Teensy Loader out of the picture ( when closed ) it will have the IDE defer to TyCommander to perform the upload and coordinate with the Serial connect of course since it is the self same program.
not true, Xport can split a com port so two devices can connect
used this back in carPC days to use a single GPS bluetooth to feed both speedometer and nmea data for two different apps..
Dual connect isn't standard on Windows - and never looked for it. One connection gets it - the other cannot. I wonder if that is behind the earlier issues?
tonton81 - have you tried TyCommander? You noted (on other thread IIRC) buffers get too large with SerMon - TyCommander allows limiting their size so they don't get out of hand. Also it used to be faster than SerMon - but last I saw they were in the same magnitude.
normally this is not possible on OSX. Well ofcourse with special Soft- or Hardware it is.
What makes it even more funny is that I not only can Read simultaneously, it is also possible to send Serial commands simultaneously! :-)
not yet, i dont seem to have issues with teensy and sermon even when flooding it in a tight loop, i figure usb speed is fast enough to cope, doing it with an esp8266 for example would lock up the IDE itself within seconds, requiring the user to force close via task manager :P
Grasping ...
1) looking for other processes using USB port: with serial monitor open, do: lsof | grep modem
2) when just printing value of i in loop, if you switch from monitor to "Serial Plotter" in IDE, i presume you still have missing values?
3) you said you switched languages, but seems like i've read about arduino IDE problems that were sensitive to language ??? IDE has language preference, as does MAC OS
4) do you have UNO or non-teensy arduino MCU you can test
1) only Arduino is connected to the USB port.
2) Yes same error.
3) i have not switched! I have tried different Languages to find out if there is an connection between the error and the Language.
I have changed System Language, and Arduino Language, I have done an OSX update, an Arduino and Teensyduino update & downgrade, I have updated JS.
I have disconnected Bluetooth stuff, mouse, Trackpad, Keyboard, etc. Nothing else connected to The iMac at all.
I have tried with and with out WLan...... and many more.
4) Arduino Nano no problems tried it many times!
Teensy LC Same Problem!
![]()
I was going to suggest trying Arduino 1.0.6. That old version uses RXTX instead of JSSC. But perhaps 1.0.6 can't even run on modern Macs?
Can you try adding "Serial.send_now();" after each Serial.print() ?
From what I allow to deduce that it's neither an Arduino IDE, nor a Teensyduino, nor a Teensy loader issue. Which means that the OSX / macOS installation might be corrupted by whatever not correctly functioning kext module which under several conditions might interfere with the serial communication.
Any chance to reboot your Mac in safe mode with only the strict minimum of drivers and background tasks loaded?
Ok, here's a new theory. Maybe the data loss is somehow happening inside Arduino when the raw incoming data is getting translated to unicode?
I'm not sure how to test this theory (well, "guess" would be a better word). Maybe try using the "defaults" command which was the workaround for the High Sierra non-US menu bug before Arduino 1.8.5.
https://blog.arduino.cc/2017/10/02/a...-sierra-users/
For a copy of Arduino that has Teensyduino installed, you'll probably need to use this command:
But I must admit, how Java really handles the language settings isn't something I really know. It could be other settings that influence how bytes are turned into unicode chars.Code:defaults write cc.arduino.Arduino.teensyduino AppleLanguages '(en)'
The Java code in question, where I think this data loss might be happening, is serialEvent() at line 174 in arduino-core/src/processing/app/Serial.java.
https://github.com/arduino/Arduino/b...rial.java#L174
At line 177, data is obtained from JSSC as an array of 8 bit bytes. It seems the bytes are copied to a byte buffer, though I'm not sure what the "ByteBuffer" object really does. At line 186, the data gets converted from bytes to chars. I believe Java is using 16 bits for char, but again I'm not 100% sure on that. My guess is there many be some sort of bug at this point. Really, what we want to know is whether that byte array really is receiving the missing messages.
Maybe the next step, if fiddling with language settings is fruitless, might involve me compiling some copies of arduino-core.jar with verbose debug info printed from that function. On a Mac, you'd need to dig into the app bundle (control-click on Arduino and "Show Package Contents") and replace the jar file. This might also cause Mac Gatekeeper to get upset, so you may have to control-click to run Arduino, or somehow disable Gatekeeper (Apple has made this harder to do recently).
Hey Paul, do you sometimes sleep too? :-)
I will try this tomorrow or later this day... it is 2am here in Switzerland...Code:defaults write cc.arduino.Arduino.teensyduino AppleLanguages '(en)'
English system language had no positive effect. I had already tested that.
Gatekeeper should not be a problem.
In any case many thanks for your efforts!!!
Ok then, let's try digging deeper to see where the problem is really happening.
Here's a copy of arduino-core.jar which prints the number of bytes it's actually getting for each serial event.
https://www.pjrc.com/teensy/beta/arduino-core.jar
MD5 = 32c3ae4c34c320b0d16f2ba16738568d
Here's how it looks when I run it.
To use this, download the JAR file. I recommend running "md5 arduino-core.jar" in a Terminal window, to make sure you have the right file.
Quit Arduino, if it's running. Control-click Arduino and click "Show Package Contents". Then navigate to Contexts/Java. Replace the copy of arduino-core.jar with this one.
When you run Arduino again and open the serial monitor, you should see the messages printing in the console panel. The big question is whether Arduino on your Mac really is receiving all the incoming bytes and somehow losing them internally, or perhaps they're not ever coming into the serial event handler. This test should let us know.