Go Down

Topic: Garbage using serial functions in Arduino Due (Read 8 times) previous topic - next topic

selfonlypath

I'm almost convinced there is something wrong with DUE's implementation of Serial.available() Serial.read() and so

As I've explained on some other threads this morning, I've got code running for years on MEGA, it does compile the download fine on DUE but will not work, in my case a Serial protocol called SerPro using HDLC on top of USB link. There are constant CRC errors hence the frames are rejected then re-sent, my core program
Code: [Select]
// Start of SERPRO implementation
struct SerialWrapper
{
public:
static inline void write(uint8_t v){Serial.write(v);}
static inline void write(const uint8_t *buf,int size){
int z;
for(z=0;z<size;z++) Serial.write(buf[z]);
}
static inline void flush() {}
};

struct SerProConfig {
static unsigned int const maxFunctions = MAX_SERPRO_FUNCTIONS;
static unsigned int const maxPacketSize = 32;
static unsigned int const stationId = 3;
static SerProImplementationType const implementationType = Slave;
};

DECLARE_SERPRO(SerProConfig,SerialWrapper,SerProHDLC,SerPro);

void setup()
{
// protocol initialization
  Serial.begin(BAUD_RATE);

// Testing leds
  pinMode(ledLinkUp,OUTPUT);
  pinMode(ledCRCerror,OUTPUT);
  pinMode(ledRcv,OUTPUT);
  pinMode(ledXmit,OUTPUT);
}

void loop()
{
  if (Serial.available() > 0) SerPro::processData(Serial.read() & 0xff);
}

// End of SERPRO implementation
IMPLEMENT_SERPRO(MAX_SERPRO_FUNCTIONS,SerPro,SerProHDLC);


fat16lib

#6
Dec 01, 2012, 05:01 pm Last Edit: Dec 01, 2012, 05:09 pm by fat16lib Reason: 1
Here is a sketch with a counter.  Looks like Serial has several, maybe 6, bytes of garbage input when a reset from opening a Serial monitor happens.

Load this sketch into the Due:
Code: [Select]

int n = 0;
void setup() {
 Serial.begin(115200);
}
void loop() {
 if (Serial.available()) {
   Serial.read();
   Serial.write('N');
   Serial.println(++n);
 }
}


then open a serial monitor and you get this:
Quote

þþN5
N6

Close and open the serial monitor again and you get a similar result.  Almost always ending with the "N6" line.

Adding a delay(2000) after Serial.begin seems to fix it after reload but not on a reopen of the monitor.

I tried this but still get the problem.  
Code: [Select]

while (!Serial);

So if you write for Uno, Leonardo, and Due what is the correct answer to avoid this?

fat16lib

I did more testing and the junk you get is sent to serial before the reset done by opening the serial monitor.

If you run this sketch and open a serial monitor at 115200, you will see some junk printed from loop() before the HI printed in setup().
Code: [Select]

void setup () {
  Serial.begin(115200);
  Serial.println();
  Serial.println("HI");
}
int n = 0;
void loop() {
  if (Serial.available()) {
    Serial.println();
    Serial.print(++n);
    Serial.write("c=");
    Serial.print(Serial.read(), HEX);
  }
}

output:
Quote

öþ
5c=0
6c=0
HI

This seems to indicate that when the serial monitor is opened, some junk is sent to serial, and then the reset restarts the program which prints "HI".

This can cause big problems with a sketch that tries to wait for input like this:
Code: [Select]

void setup() {
  Serial.begin(115200);
  Serial.println("Type any character to start");
  while (Serial.available() == 0) {}
}
int n = 0;
void loop() {
  Serial.println(++n);
}

The output is:
Quote

Êa
F??
1
42
j
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
ÿType any character to start

spcomputing

Does this happen at 9600?  Does "while (!Serial)" do anything?

selfonlypath

In my case, it happens at 112500 bauds. I could change easily my software which consist to make dialog a Java GUI on MacBook Air with my Mega or my Due but i don't feel loosing anymore time on this since it is obvious in this thread or other recent related threads the Serial.libs function in 1.5 IDE are the root cause of this issue... Sorry !

Go Up