What is the serial monitor actually doing?

Ok, read an old thread. Going to try NewSoftwareSerial. Will post new code when I finish.

NewSoftwareSerial is SoftwareSerial in the new 1.0 IDE and included.

Just be sure: your LED display is controlled by a UART interface? You don't mix up SPI and UART, do you?

If you wanna put the TX line high during startup of the display move Serial.begin() down after that startup happened.

  pinMode(1,OUTPUT);
  digitalWrite(1, HIGH); //set high as per the data sheet recommendation to mitigate spurious data
  delay(1000);
  Serial.begin(9600);

No, I don't think I've mixed up SPI. There is no clock for the display to read, so I don't think it can be SPI.

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3); // RX, TX
uint8_t arr[]={0x42, 0x10, 0xcc};
uint8_t new_arr[]={0x43,0x50,0x3F,0x22,0x00,0x1F};
uint8_t autobaud[]={0x55};
void setup()
{
  pinMode(2, INPUT);
  pinMode(3, OUTPUT);
  digitalWrite(3, HIGH); //set high as per the data sheet recommendation to mitigate spurious data
  delay(1000);
//  pinMode(8,OUTPUT);
//  digitalWrite(8,HIGH);
//  delay(20);
//  digitalWrite(8,LOW);

    Serial.begin(9600);
  mySerial.begin(9600);
//  UCSR0C = UCSR0C | B00000110;
      delay(1000);
      dostuff(autobaud, sizeof(autobaud));
      dostuff(arr, sizeof(arr)); // the name of an array points to the array & you are passing 10 values
      dostuff(new_arr, sizeof(new_arr)); // the name of an array points to the array & you are passing 10 values
}

void loop()
{

}


void dostuff(uint8_t *buffer, int len)
{
  mySerial.write(buffer, len);  // Serial.write wants the array pointer and the number of elements
  /*more stuff*/
  serial_response();
 // memset(&a, 0, BUF);
}

void  serial_response(){
 // delay(1);
//    int incomingByte=0;
//      if (Serial.available() > 0) {
//      // read the incoming byte:
//      incomingByte = Serial.read();
//
//      if (incomingByte = 0x15)
//      return;
//     
//    //   Serial.print("I received: ");
//      Serial.println(incomingByte, HEX);
//      }

  if (mySerial.available()>0){
  Serial.println(mySerial.read());
 }
 }

Implemented softwareserial, now none of my code works :confused: on the bright side, I can flash the arduino now without having to unplug the display.

SoftwareSerial mySerial(2, 3); // RX, TX

You told the SoftwareSerial instance that it owns pins 2 and 3.

  pinMode(2, INPUT);
  pinMode(3, OUTPUT);
  digitalWrite(3, HIGH); //set high as per the data sheet recommendation to mitigate spurious data

Then you go messing with them. Why? What data sheet are you talking about? The SoftwareSerial instance should be doing this, if it is necessary.

  mySerial.write(buffer, len);  // Serial.write wants the array pointer and the number of elements

Write a bunch of stuff to the serial port. OK.

  if (mySerial.available()>0){
  Serial.println(mySerial.read());

Immediately, expect a one character response. Why?

Well, I'm waiting?

C'mon. Hurry up.

I'm not a patient type, either.

PaulS:

  if (mySerial.available()>0){

Serial.println(mySerial.read());



Immediately, expect a one character response. Why?

Well, I'm waiting?

C'mon. Hurry up.

I'm not a patient type, either.

I am guessing you are referring to status registers? I need to wait until TX/RX is complete? I found a website on that subject that seems informative. I'll have to refresh myself.

Can I write the status registers directly into the IDE?

PearlRock:
I am guessing you are referring to status registers?

No, I believe PaulS is referring to the fact that in the real world there will be a significant delay between sending a message out, and having the response available to you. Your sketch makes no allowance for that and assumes that the response will be available instantly.

oh ok. I think I understand now. So the code goes to that function, and can potentially immediately evaluate false (or true), even though it may not actually be false (or true), and the program will then continue on.

I think I understand, but I am having difficulty coming up with the logic.

basically I want to loop until I get a handshake of "0x06"=good or a "0x15"=bad. so my response function needs to loop until it receives a response for each command transmitted. I have something written, but it's poor form. If the unit doesn't send a response, then the code goes into an infinite loop.....lol

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3); // RX, TX
uint8_t arr[]={0x42, 0x10, 0xcc};
uint8_t new_arr[]={0x43,0x50,0x3F,0x22,0x00,0x1F};
uint8_t autobaud[]={0x55};

void setup()
{
  Serial.begin(9600);
    mySerial.begin(9600);
      delay(1000);
      dostuff(autobaud, sizeof(autobaud));
      dostuff(arr, sizeof(arr));
      dostuff(new_arr, sizeof(new_arr));
}

void loop()
{
}

void dostuff(uint8_t *buffer, int len)
{
  mySerial.write(buffer, len);  // Serial.write wants the array pointer and the number of elements
  Serial.print("Command: ");
  Serial.write(buffer, len);
  Serial.println("|");
  serial_response();
}

void  serial_response(){
  
int incomingByte=0;
    if (mySerial.available()>0){
       incomingByte = mySerial.read();
       Serial.print("Response: ");
       Serial.print(incomingByte, HEX);
       Serial.println("|");
     }
    else{
       serial_response(); 
    }
 }

the output is:

Command: U|
Response: 0|
Command: B Ì|
Response: 0|
Command: CP?" |
Response: 0|

I'm not sure why the code is printing zeros, because....the only response should be 0x06 or 0x15 as far as I know. The display is doing nothing.....it's just black. So if the display is not responding at all, I'm not sure why the code prints any response at all.

I'll have to look at the datasheet again when I get back. I'm still not sure if I'm supposed to get a response for every byte, or every command. It's every command.

So, you are sending magic numbers to a mystery device which may or may not be responding to one or more of those magic numbers. You are expecting some sort of output from that mystery device but you are not getting that output and you can't figure out why.

You are the one who knows what the mystery device is, what information you are supposed to send it, and how it is supposed to respond but you can't determine why it isn't working the way you think it should. We know nothing about your mystery device except that it is some sort of serial LED display. How do you expect us to help?

Don

floresta:
So, you are sending magic numbers to a mystery device which may or may not be responding to one or more of those magic numbers. You are expecting some sort of output from that mystery device but you are not getting that output and you can't figure out why.

You are the one who knows what the mystery device is, what information you are supposed to send it, and how it is supposed to respond but you can't determine why it isn't working the way you think it should. We know nothing about your mystery device except that it is some sort of serial LED display. How do you expect us to help?

Don

Well, basic UART should be pretty universal amongst all devices. You send data, you wait for the response back. What my mystery device is really shouldn't matter too much, assuming the call and response information I have provided is correct. People have made suggestions which made me re-examine the way I have my code structured. that is helpful to me, and what I am really looking for in terms of help. Other then that, there really isnt much else you can do unless you want want to start reading through the datasheet(s) themselves. I'm learning, so I want to handle the datasheet business myself. The device is a 4D uOLED-160-G1. The datasheet I am primarily referencing is here

void  serial_response()
{
   int incomingByte=0;
   if (mySerial.available()>0)
   {
      incomingByte = mySerial.read();
      Serial.print("Response: ");
      Serial.print(incomingByte, HEX);
      Serial.println("|");
   }
   else
   {
      serial_response(); 
   }
 }

If there is no data yet, make a recursive call to this function. Nope, not going to work.

You need to learn about while loops! While there is no serial data, sit on your hands and do NOTHING!

You have not mentioned anything about seeing, or not seeing, the splash screen. Could you comment on this and also answer the following questions based on your original post? (Some of these questions would not be necessary if you had properly commented your code, specifically if you had identified what the magic numbers are supposed to do.)

I am sending 2 commands to the slave device, but only the first command appears to be read.

What makes you think that the command 'appears' to be read?
-- What command are you sending?
-- What response do you expect to get?
-- What response do you actually get?

The second command executes, albeit appears to execute incorrectly ... It's kind of doing what I want.....but not quite.

What makes you think that the command 'appears' to execute and why do you think that it is incorrect?
-- What command are you sending?
-- What response do you expect to get?
-- What response do you actually get?

... only when I open the serial monitor....

--What happens, or does not happen, before you open the serial monitor?
--What happens, or does not happen, after you open the serial monitor?

I'm not even sure the first command is quite right.

-- What command are you referring to?
-- What response do you expect to get?
-- What response do you actually get?

It goes kinda slow ... Maybe that command is supposed to be slower. It's hard to say.

What do you mean by slow? Do you mean there is a delay before you start to see something, or do you mean it takes a long time between the time it starts to do what ever it is doing and the time it finishes?

but idk.

I am a native English speaker but many of the contributors to this forum, even in this English language section, are not. Also many of us are more than 14 years old. You are severely limiting the number of people who can help you what you include abbreviations such as this.

Don

You are severely limiting the number of people who can help you what you include abbreviations such as this.

Or at least those that want to.

floresta:
You have not mentioned anything about seeing, or not seeing, the splash screen. Could you comment on this and also answer the following questions based on your original post? (Some of these questions would not be necessary if you had properly commented your code, specifically if you had identified what the magic numbers are supposed to do.)

I am sending 2 commands to the slave device, but only the first command appears to be read.

What makes you think that the command 'appears' to be read?
-- What command are you sending?
-- What response do you expect to get?
-- What response do you actually get?

The second command executes, albeit appears to execute incorrectly ... It's kind of doing what I want.....but not quite.

What makes you think that the command 'appears' to execute and why do you think that it is incorrect?
-- What command are you sending?
-- What response do you expect to get?
-- What response do you actually get?

... only when I open the serial monitor....

--What happens, or does not happen, before you open the serial monitor?
--What happens, or does not happen, after you open the serial monitor?

I'm not even sure the first command is quite right.

-- What command are you referring to?
-- What response do you expect to get?
-- What response do you actually get?

It goes kinda slow ... Maybe that command is supposed to be slower. It's hard to say.

What do you mean by slow? Do you mean there is a delay before you start to see something, or do you mean it takes a long time between the time it starts to do what ever it is doing and the time it finishes?

Ah, well that was all from before I switched to software serial. Some strange things were happening with the monitor, and I wasn't able to program the arduino and have my device plugged in at the same time, so that wasn't very useful. That was the reason I switched to software serial. HOWEVER, I know I was sending 3 commands to the device, and I know those 3 commands were being executed: (0x55) Splash screen didn't display; autobaud seemed to be fine. The background changed colors, but it wasn't an instantaneous change, it was a slow change from black to blue from top down (not sure if the speed is normal or not). and I know the last command executed, because a white circle was showing up. There was some strange color distortions going on as well. Something was not right. Anyway, I've switched to software serial. I havent gotten software serial to display anything yet, but I need to sit down and take a look at it again today. In fact, I'm not even sure the splash screen is doing anything as of the last code change, so I need to make sure I am initializing properly since I've made the switch to software serial.

floresta:

but idk.

I am a native English speaker but many of the contributors to this forum, even in this English language section, are not. Also many of us are more than 14 years old. You are severely limiting the number of people who can help you what you include abbreviations such as this.

Don

Oh sorry, I get carried away with my internet jargon sometimes. I'll try to stop. Idk is usually an acronym for 'i don't know'. I don't know if a slow background color change is normal.

I'll post another update to the code with hopefully a revised method of waiting for the data, and with more comments. I have to leave right now. I lost my wretched wallet this weekend. -_- Have to get that straightened out today.

As I interpret the datasheet the splash screen will automatically show up if the device does not receive the Auto-Baud character. Since you do not see the splash screen this means that the device did receive the Auto-Baud character. This means that the device would have sent an 'ACK' response back but your software is not recognizing that this has occurred.

I think that you should simplify your program and concentrate on getting this preliminary handshaking to work. I would do away with the serial monitor and use some LEDs for feedback. Perhaps a green LED for ACK and a red LED for NACK. Now you can use the hardware UART to communicate with your display, but make sure that you disconnect the display while you download your sketch. I would also try to simplify the serial communications as much as possible, perhaps by doing away with the arrays.

Remember that after the initial ACK (for the AutoBaud) the device does not respond until it has received what it perceives to be a complete command. If you send it a magic 0x42 it expects two more bytes. If you mistakenly send it three bytes it will respond after the second one (but you may not be looking for the response yet) and it will treat your third byte as the beginning of its next command. At this point you are waiting for an ACK and it is waiting for the rest of it's next command. I believe that the hardware serial may be better at sorting this type of problem out than the software serial.

Don

I did have some success yesterday. I saw the background color change with software serial, but i don't know how it happened. It happened 2 or 3 times, but I wasn't able to continuously reproduce it. I think it has something to do with the time I plug the device in, which makes this very frustrating to work with. I don't have any LED's with me right now, so what I tried instead was reading the board LED.

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3); // RX, TX

uint8_t autobaud[]={0x55}; //command 1 autobaud
uint8_t arr[]={0x42, 0x10, 0xCC}; //command 2 change background to color 0x10CC
uint8_t new_arr[]={0x43,0x50,0x3F,0x22,0x00,0x1F}; // command 3 draw a circle at x= 0x50 y=0x3F radius=0x22 color=0x001F

void setup()
{
  pinMode(13, OUTPUT);
  Serial.begin(9600);
  mySerial.begin(9600);
  delay(1000);
      dostuff(autobaud, sizeof(autobaud));
      dostuff(arr, sizeof(arr));
      dostuff(new_arr, sizeof(new_arr));
}

void loop()
{
  serial_response();
}

void dostuff(uint8_t *buffer, int len)
{
  mySerial.write(buffer, len);  // Serial.write wants the array pointer and the number of elements
 // Serial.print("Command: ");
 // Serial.write(buffer, len);
 // Serial.println("|");
  serial_response();
}

void  serial_response(){
    while(mySerial.available() == 0); //Do nothing until there are bytes to be read. 
   //    Serial.print("Response: ");
  
//    Serial.print(mySerial.read()); //when there are bytes, print them to the monitor. 
   digitalWrite(13, HIGH);
   delay(500);
   digitalWrite(13, LOW);
   delay(500);
 }

Clearly, i don't understand what my own code is doing, because I was certain the code would do this:

Send 1 command
wait for a response
Flash LED when there is a response.

this should repeat 3 times, once for each command.

But that's not what happens. The LED just keeps blinking indefinitely. Why does the LED keep blinking?????????? That makes no sense at all.

After the last command, the code should enter void loop, go into serial_response and stop at this line: while(mySerial.available() == 0); because nothing is being sent, and therefore the display shouldn't be sending anything back as far as I am aware.

Nothing is being printed to any serial port. Not software serial or the hardware serial port.

Hmmm, I changed this:
while(mySerial.available() == 0);

to this:
while(mySerial.available() <= 0);

now I'm getting blue backgrounds repeatedly.
Still no white circles.

But it should also be noted that the board LED is still flashing even when the display is unplugged :unsure:

EDIT: interesting, I got the circle to show after i added a 2 second delay after the line, dostuff(arr, sizeof(arr));

recall the background function seems to take a while to execute for whatever reason. So I added a delay to give the function some time to complete, and then the circle seemed to execute just fine. i suppose that thoroughly means my response function doesn't work at all.

EDIT2: I was having some issues with color distortion,but according to here that happens with high contrast (blue background white circle) Hopefully, that will go away when i start using regular images beyond just tests.

wow, today has been a productive day.

Alright, so my program looks like this now:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3); // RX, TX

uint8_t autobaud[]={0x55}; //command 1 autobaud
uint8_t arr[]={0x42, 0x10, 0xCC}; //command 2 change background to color 0x10CC
uint8_t new_arr[]={0x00,0x00,0x00,0x00,0x00,0xFF}; // command 3 draw a circle at x= 0x50 y=0x3F radius=0x22 color=0x001F

void setup()
{
  delay(1000);
  pinMode(13, OUTPUT);
  Serial.begin(9600);
  mySerial.begin(9600);
  delay(1000);
      dostuff(autobaud, sizeof(autobaud));
      dostuff(arr, sizeof(arr));
      delay(2000);
      dostuff(new_arr, sizeof(new_arr));
}

void loop()
{
  serial_response();
}

void dostuff(uint8_t *buffer, int len)
{
  mySerial.write(buffer, len);  // Serial.write wants the array pointer and the number of elements
 // Serial.print("Command: ");
 // Serial.write(buffer, len);
 // Serial.println("|");
  serial_response();
}

void  serial_response(){
  byte incomingByte=0;
    while(mySerial.available() <= 0); //Do nothing until there are bytes to be read. 
   //    Serial.print("Response: ");
incomingByte=mySerial.read();
  if(incomingByte==0x06){
   Serial.print(incomingByte, HEX); //when there are bytes, print them to the monitor. 
   digitalWrite(13, HIGH);
   delay(500);
   digitalWrite(13, LOW);
   delay(500);
 }
   else if(incomingByte==0x15){
   Serial.println("NAK");
 }
   
   else{
   Serial.println(incomingByte, HEX);
   }
   
 }

I have intentionally put in command #3 improperly, so I could make sure I was getting 0x15, or negative acknowledgement of a bad command. The screen is doing exactly what it is supposed to, and this is the output from the monitor:

6655
FE
NAK
AB
FE

66 is confirmation of command 1 and 2.
NAK is confirmation of a bad command, command 3.
I don't know what the other junk is. Is it normal for devices like this to spit out junk data like that?

Hmmm, I changed this:
while(mySerial.available() == 0);

to this:
while(mySerial.available() <= 0);

That change had no affect at all, since the available() function returns the number of bytes in the buffer, and there can not be fewer than 0 bytes in the buffer.

I don't know what the other junk is. Is it normal for devices like this to spit out junk data like that?

Normally, devices do not spit out random junk. The data means something, even if that is not apparent to you. Try printing a space after each value, so you can see where the values break. 6655 could be 6, 6, 5, 5 or 66, 5, 5, or 6, 65, 5, or 665, 5, or a number of other combinations.

PaulS:

Hmmm, I changed this:
while(mySerial.available() == 0);

to this:
while(mySerial.available() <= 0);

That change had no affect at all, since the available() function returns the number of bytes in the buffer, and there can not be fewer than 0 bytes in the buffer.

yep, you're right. Since I was unplugging the device each time to program it, i had to plug it in at the right time in order for the display to process the data correctly. Needless to say, that produced some randomness in the 'results'. Once I determined that the device was operating with some consistency, I was able to write a few more things, so now I don't have to unplug it, and there is much less randomness in the display output :smiley:

PaulS:

I don't know what the other junk is. Is it normal for devices like this to spit out junk data like that?

Normally, devices do not spit out random junk. The data means something, even if that is not apparent to you. Try printing a space after each value, so you can see where the values break. 6655 could be 6, 6, 5, 5 or 66, 5, 5, or 6, 65, 5, or 665, 5, or a number of other combinations.

I know you saw this, but for anyone else who is watching, this discussion is becoming more and more about the logic and composition of the code. As such, I started a new thread here: http://arduino.cc/forum/index.php/topic,106427.0.html