Jordan Ford

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

8 years, 6 months ago.

Serial readable() never returning 1 after first byte??

I'm using the uLCD-144-G2 LCD with the mbed, and I need to use the read_pixel function from this library.

The code in the published library has a bug which I already fixed. In the original code, this line

color = ((response[0] << 8) | response[1]);

needs to be

color = ((response[1] << 8) | response[2]);

Otherwise, you get the ack byte and the MSB instead of the MSB and the LSB.

Now, the problem I'm having is that _cmd.readable() in the receive while loop never evaluates to true after receiving the first (ACK) byte. Can anyone help me figure out why???

WHY DOESN'T THIS WORK!!!

int uLCD_4DGL :: read_pixel(int x, int y)   // read screen info and populate data
{

    char command[6]= "";
    command[0] = 0xFF;
    command[1] = READPIXEL;

    command[2] = (x >> 8) & 0xFF;
    command[3] = x & 0xFF;

    command[4] = (y >> 8) & 0xFF;
    command[5] = y & 0xFF;

    int i, temp = 0, color = 0, resp = 0;
    char response[3] = "";

    freeBUFFER();

    for (i = 0; i < 6; i++) {                   // send all chars to serial port
        writeBYTE(command[i]);
    }

    while (!_cmd.readable());// wait_ms(TEMPO);    // wait for screen answer

    // WHY DOES _cmd.readable() NEVER EVALUATE TO 1 AFTER IT RECEIVES 0x60 (THE ACK)???
    while (_cmd.readable() && resp < ARRAY_SIZE(response)) {
        temp = _cmd.getc();
        response[resp++] = (char)temp;
    }

    color = ((response[1] << 8) | response[2]);

    return color; // WARNING : this is 16bits color, not 24bits... need to be fixed
}

You made it such that only Adam Green can answer the question.

Anyway, you need to take into account that Serial is really slow compared to the speed of an MCU: After it receives the ACK, it handles your loop once, and next time it isn't readable YET. Since the next byte has not arrived yet. So you need to do something else to make sure you wait until you got all bytes. I don't know the used protocol, but you could maybe simply read the number of bytes you expect. Using a simple Timer you can if you want place a timeout on it to prevent it locking forever if for whatever reason less than the expected number of bytes arrive.

posted by Erik - 25 Oct 2015

Oops. Sorry. It won't let me unassign it either :\ I tried something like this...

while (resp < ARRAY_SIZE(response)) {
	while(!_cmd.readable());    //Spin while we wait.

        temp = _cmd.getc();
        response[resp++] = (char)temp;
}

and it does weird things. When I scan across the screen and read out the pixel values, I get the same color every time even though the colors are not the same :(

posted by Jordan Ford 25 Oct 2015

resp is reset everytie before it enters that loop?

posted by Erik - 25 Oct 2015

At the low default baud rate on the uLCD , try turning on debugmode in uLCD_4DGL.h to get more info on what exactly is going on. That makes it send all of the uLCD command characters and the response to the USB serial port 115200 baud for debugging. A few of the uLCD commands needed a wait. Keep in mind that mbed is faster than the uLCD controller micro. It is possible that it is an issue with the firmware in the uLCD or something off in the manual entry for the read pixel serial command. I did find a manual typo on one command as I recall from a couple years ago.

posted by jim hamblen 25 Oct 2015

Fixed it! Thanks for the help guys. I had a problem in my code where I wasn't reading the pixels I thought I was reading. Duh!

posted by Jordan Ford 27 Oct 2015
Be the first to answer this question.

Assigned to Jordan Ford 8 years, 6 months ago.

This means that the question has been accepted and is being worked on.