BLIT problem

[fpipatryk]

Hello,
I'm trying to display some images on the screen using Uoled 160-g2 with serial environment but I'm experiencing some problems here. I'm using "Blit Com to Display" command. First of all i specify 10 bytes array according to the manual and then write it to the display. After that I write the image array and then wait for the ACK. When I do this that way, the image on the display is deformed and I do not receive the ACK. I found out that if I put the usleep(50000) function between writing the first array with 10 bytes and the array with the image the problem disapears, image looks just fine, and ACK is read. I've also noticed that with increasing the time of sleep the image becomes less deformed, but still ACK is not returned until the sleep time is large enough. What am I doing wrong? what can cause this problem? Thanks for any suggestions.

[John Kevin]

Hi,

Welcome to the forum!
Have you tried the 'Serial Commander' present on the Workshop4 IDE? Perhaps this may give you a better idea on how it sends the serial commands on the display.

The BlitComtoDisplay command has a data format of a 16-bit pixel, so each pixel contains 2 bytes (1 word).
Is it possible that you are not sending the correct data byte which you have specified beforehand (width & height)?

Can you please add a snippet of code on how you implement it?

For reference, this is how I would implement it.

// size (w = 5, h = 2) -> (5x2)size x 2(bytes) = 20 bytes
// location (x=0, y=80) 

static const uint8_t WhiteBox1[20] = {
    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
};

    Serial.println("Sending Blit Com to Display Command");
    DisplaySerial.write(byte(0x00)); // Command(MSB)
    DisplaySerial.write(byte(0x0A)); // Command(LSB)
    DisplaySerial.write(byte(0x00)); // x(MSB)
    DisplaySerial.write(byte(0x00)); // x(LSB)
    DisplaySerial.write(byte(0x00)); // y(MSB)
    DisplaySerial.write(byte(0x50)); // y(LSB)
    DisplaySerial.write(byte(0x00)); // width(MSB)
    DisplaySerial.write(byte(0x05)); // width(LSB)
    DisplaySerial.write(byte(0x00)); // height(MSB)
    DisplaySerial.write(byte(0x02)); // height(LSB)
    delay(10);
    DisplaySerial.write(WhiteBox1,sizeof(WhiteBox1)); //where WhiteBox1 is 20 bytes (5x2)(2bytes)

Best Regards,
Kevin

[fpipatryk]

Thanks for the answer!

here is my code:

      uint8_t width = Pixels[0];
      uint8_t height = Pixels[1];
      uint8_t tosend[]={0x00,0x0A,0x00,0x00,0x00,0x00,0x00,0x28,0x00,0x1F}; //cmd, cmd, x, x, y,  y, width, width, height,  height
      port->write(tosend,10);
      usleep(50000);
      port->write(&Pixels[2],2*width*height);
      waitACK();

Pixels is an array where 2 first elements are as follows width and height and then the rest of the image data. I've checked this array once again and I'm pretty sure it is declared properly. The image I want to display is 40x31 which gives 40*31*2 = 2480 bytes. I am wondering if it isn't too much for just one write? I've also tried the 'Serial Commander' just as you suggested and my image is displayed well there but I still can't see where I make the mistake in my code.

[fpipatryk]

The whole time I've been working on 115200 baudrate. I've just changed it to 19200 and everything works fine, without using usleep() delay but it still doesn't satisfy me because the image is displayed to slow for me needs.

[ESPsupport]

With the code you have above, you should be able to lower your delay to a couple of msec. (i.e. a short delay is required after sending the 'setup parameters')

Then you should be able to send everything at even 600kbaud and nothing should be lost. (the ucam demo does this)

So, I suspect the issue is that your 115200 is not exactly 115200, as for an information burst, a slight baud rate missmatch can easily induce transmission errors.

What is your driving platform and what is its true baud rate when you specify 115200?

[fpipatryk]

I communicate with the display by PC with Linux as a guest on Windows host, so I don't think the the baud rate missmatch is the cause of the problem here. Anyway I will try to measure this true baud rate with an oscilloscope to make sure, but for now, do you have any other suggestions what can be wrong?

[ESPsupport]

Sorry, no other suggestions, and, unfortunately what you have said about being able to communicate with some other devices doesn't really prove anything, you might not be emulating the 'burst' sufficiently and/or the baud rate errors are probably different (and could be 'compatible').