-5

Basically, I have this code on a Bluno M3 Arduino:

#define MSG_LEN 2
unsigned char pixel;
char buff[MSG_LEN];

int i;
void setup() {
  Serial4.begin(9600); 
  pixel=0xDD;
}


void loop() {
  if(Serial4.peek() == -1){
    while(Serial4.available() < MSG_LEN);  
    Serial4.readBytes(buff, 2);


  if(buff[0] == 0xC8 && buff[1] == 0x00){ 
    //send image       
    Serial4.write(0xC7); //send Image ACK
    Serial4.flush();
    for(i=0;i<4800;i++){
      Serial4.write(pixel);
      Serial4.flush();
    }
    for(i=0;i<MSG_LEN;i++){
      buff[i]=0xFF;
    }
  }
  }else{
    while(Serial4.available()>0){
      Serial4.read();
    }
  } 
}

I'm using a PL2303 USB-Serial Adapter, Bluno M3 arduino, CoolTerm serial monitor.

And if you check this image:

image

You can see that in the data this code sends, the 0xC7 byte is mixed in with the 0xDD bytes (so called pixel bytes)

Why does that happen?

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Don Joe
  • 41
  • 1
  • The issue may be with the PL2303 or its Windows driver rather than your code or the Arduino library. Older Prolific devices have been problematic in my experience, and fake Prolific devices which are not uncommon are even worse. – Clifford Aug 07 '17 at 22:45
  • @Clifford but those problems were different – 0___________ Aug 07 '17 at 22:58
  • @PeterJ : I an not sure how you can assume to know what problems I have observed. I have seen missing and corrupted characters with such devices when streaming data. It is not that beyond possibility that this is the same issue, but made more obvious by the lack of variation in the data. – Clifford Aug 08 '17 at 07:19
  • You are not the only one,who had problems with pl... chips. And I do not think that your problems were different. – 0___________ Aug 08 '17 at 07:33

2 Answers2

0
  1. You do not assign your pixel variable and always send the same value;
  2. Flush serial only at end of the transmission. It should help. otherwise it is the bug

Do another test: instead of sending the same value increment it with every time. It will give more diagnostic data

0___________
  • 60,014
  • 4
  • 34
  • 74
  • 1
    pixel is assigned the in `setup()`. While sending the same value repeatedly may have little benefit, I am not sure that is the issue in hand - likely that is simply dummy data to illustrate the problem. While the flush is unnecessary, it is not a bug other then it defeats any benefit of buffered I/O. If anything it should guarantee sequential output even if the buffering were flawed (which seems unlikely in such widely used library code) – Clifford Aug 07 '17 at 22:38
  • @Clifford in the code presented I cant see any reason for the behaviour shown - except the bug in the library. – 0___________ Aug 07 '17 at 22:45
  • I agree, but that makes this a guess or advice at best, not an answer. A comment may have been more appropriate. – Clifford Aug 08 '17 at 07:13
0

Thanks to everyone pointing out that the issue might be the PL2303 module. From further testing I did confirm the PL2303 USB adapter is not working correctly.

The code works well when I use the same serial monitor but on the same COM port used for programming that Bluno arduino. This weird behaviour has been very frustrating but I appreciate everyone who pointed me in the right direction.

Don Joe
  • 41
  • 1