FIXED:Large messages via Serial Dat get broken up on 099MAC

VIDEO:
[url]https://drive.google.com/file/d/0B_UvHEiMhbn9UGNrVnUyclU0TFU/view[/url]

  • This is in reference to controlling leds on a teensy arduino by the way.
  • The following works as expected on 099 for windows.
  • Can confirm, that this result is repeatable and has happened on more than 1 mac.

So, I have a .toe sending 3600 bytes per message via serial, and having the teensy/arduino print back how many bytes it received. The resulting number seems random and chaotic and is no where near the message length.

If the number of bytes being sent is set to 450, this problem goes away. the leds display the correct pattern.

My initial reaction was that maybe this is an OSX limitation of overall serial message length… However that does not seem to be the case as I can drive the full number of leds and far more actually from Processing for example and it receives the full message with out issues.

Is this a bug? or an intended feature/limitation of 099 on osx? Or something else entirely perhaps?

Thanks!

Hi.
We haven’t found anything specific yet, but are still looking.
My question is: Since serial data is streamed, how does the arduino delineate between sets of data?
Even if you sent 3600 bytes, they’re not guaranteed to arrive in one block at the destination.
Is the arduino looking for a specific delimiter?

Would it still have received more bytes after the initial 450 detected?

Does it report the correct number received when operating at a low baud for testing?

Thanks,
Rob

Hi Rob,

My arduino code is incredibly simple, and admittedly not really smart enough to catch exceptions like incorrect packet length, header, array offsets etc. It basically waits until a packet however long arrives, then iterates over that as a frame.

While on windows for several years this has never even once caused a glitch or offset that didn’t start off with some chop length changing in TD. I’m a bit surprised at this as well.

However this same code when receiving from OSX gets packets in a variety of lengths. Very inconsistent.

This same arduino code though can receive full length packets from Processing and the code has definitely worked flawlessly on past projects with large led counts so I do know it works past and current.


For reference, here’s my teensy/arduino code:

[code]// Lucas Morgan - www.enviral-design.com //

#define USE_OCTOWS2811
#include<OctoWS2811.h>
#include<FastLED.h>

// ------------ Change these as neccesary -----------//
#define NUM_LEDS_PER_STRIP 480
#define NUM_STRIPS 8

CRGB leds[NUM_STRIPS * NUM_LEDS_PER_STRIP];
const int numOfBytes = NUM_LEDS_PER_STRIP * NUM_STRIPS * 3;
const int numLeds = NUM_LEDS_PER_STRIP * NUM_STRIPS;
char inputBuffer[numOfBytes];

// ------------------- Setup -------------------- //
void setup() {
LEDS.addLeds(leds, NUM_LEDS_PER_STRIP);
LEDS.setBrightness(255);
delay(500);
Serial.begin(115200);
Serial.setTimeout(500);
LEDS.show();
}

// ------------------- Main Loop -------------------- //
void loop() {
if(Serial.available() > 0) {
Serial.readBytes(inputBuffer, numOfBytes);
}
for (int j = 0; j < numLeds; j++) {
leds[j] = CRGB(inputBuffer[(j3)],inputBuffer[(j3)+1],inputBuffer[(j*3)+2]);
}
LEDS.show();
}[/code]

Wondering if you’ll have better luck with the following:

if(Serial.available() >= numOfBytes) {
Serial.readBytes(inputBuffer, numOfBytes)

That is, wait until all the bytes have arrived before reading them.
Right now, it will send a whole LED packet for as little as one byte received.

Im guessing the readBytes parameter may actually be timing out periodically (500ms) if things aren’t framed right?

I don’t have direct access to OSX but will give this a go through a friend and see what they say!

This did not work for me… I am getting USB Received: 0 for bytes in serial1 whereas the original code delivers all 124 bytes. I guess the issue lies else where.

I am attempting to install Windows 10 on Bootcamp to see if it might be anything hardware specific rather than OS.

Bit confused why it would claim 0 bytes.
But please keep us posted

I checked it out with a logic analyzer, it seems that the outgoing message length from touch is capped at 1024 bytes.

Hi, is there anything new on this topic? because i have the same problems with serial and the teensy led control.

Apologies for this one getting lost.
Great tip about the logic analyzer.
We are having a closer look now.
-Rob

Alright this will now be fixed in the next posted experimental, 2018.22930 or later.
Thanks for your patience!

Rob

Build 2018.23080 with a fix for this is now available.

Download