Initialization TX line uOLED-160-SGC-G1

[sopheric]

I´m going through some stange troubles while trying to drive the module with an AT32UC3C 32 bits MCU from ATMEL.

During the initialization I drive the reset line low, and then back up and finally after waiting for a second, I send the autobaud command. Unfortunately, I´m never able to properly read the first ACK.
After spending quite sometime with a digital scope I´ve noticed that after the hardware reset, the OLED TX line is just floating (high impedance). The line is not pulled up until the autobaud command has been read by the module This is means that the Micro is not able to read properly the ACK and a second autobaud has to be sent.

Is this behaviour correct, or do I have another problem somewhere else (and driving me nuts!)?
I´m using PmmC Rev 17. And I get the same behaviour no matter if the SD card is inserted or not.

Thanks in advance for your suggestions!

Eric

[ESPsupport]

You will need to wait more than a second, whilst the display initialises. (maybe a bit more than 2 without a uSD card inserted, and more again with one)

I've never particularly looked at it, but I assume you would not be able to send the autobaud until a few MS after the TX line goes high.

[sopheric]

Thank you for your quick reply.

Does this means that I can use the status of the TX line to determine when the initialization has been completed?

Best regards:

Eric

[ESPsupport]

Sort of, you may need to wait another ms or so.

And if you have a uSD you will have to wait for however long that takes to init. (be aware, different makes and models take different times, not only that but if they have been initted before without being powered down the init time will also be different)

[sopheric]

Thanks again for the support.

I will "experiment" few more scenarios and I will keep you posted with the outcome.

Best regards:

Eric

[sopheric]

Hi again,

I just want to share my conclusions on this subject in case somebody may experiment a similar situation.

So after a hardware reset the TX line of module is left floating. In my case this was causing the usart of the MCU to collect some noise and raise the RX-ready flag. But in fact the content of the RX buffer was empty (0x00) instead of the expected ACK.

Once the autobaud command (0x55) has been received and decoded by the OLED module, it takes some miliseconds for the RX line to be driven high. Finally the ACK is transmitted.

My suggestion is after a reset and once the autobaud command has been transmited, wait 5 miliseconds before enabling the reception of your usart to avoid any erroneous reception instead of the expected ACK.

Here are some of the aproximative delays you may expect before receiving the ACK:

For an Autobaud = 12,5 mS
For a clear screen = 36 mS
For some text (The lazy dog...) = 25 mS
For a solid circle (radius 20) = 7,5 mS
Sor a empty rectangle (60x60) = 1,5 mS
For a solid rectangle (60x60) = 7 mS

The worst is obvisously for the replace colour (64x64) around 180 mS !
This is a shame, because the replace command woud be ideal for a flashing cursor...

Best regards:

Eric

[ESPsupport]

Hmm, thanks for that.

I'm surprised that you are seeing the TX line floating the way you are, but then again most systems place a pullup on their RX, so if they can't 'handle' a floating RX they see it as high. The OLED has such a resistor on its RX line.

I would also have though that the OLED's TX will go high 'when it is ready' rather than have any relationship to its reception of autobaud.

We don't normally publish expected delays as there is too much variance, it is different for display models and display glass (which can change withing the same display), the options associated with the command (eg Text Size and transparency settings), and the serial latency of your system.

Modern display 'glass' does not make it easy to read video memory and this is why color replacement is so slow, the best idea is to block and redraw the character, if you known what it is; or to use a blinking underline, if you don't.