Closed georgik closed 1 year ago
Very nice! @georgik did you also test with an actual device? Mine's currently unavailable so I want to make sure things didn't break.
Could you also please add a CHANGELOG entry?
@almindor Thank you for asking for further tests. It seems that this commit 7ac38ac8ffe7da74502ab4cdc89e67ed6820551f after tagging 0.6 introduces a problem. The screen is always blank. Tested on several ESP targets. I will investigate the issue further.
The strange thing was that simulation in Wokwi worked without problem.
After some investigation, there is an issue with the timing of commands which appears on real HW.
I've added a small delay as a workaround, and it solved the problem to init_common
:
https://github.com/georgik/mipidsi/commit/6e8487123f0384b1ed64ae0669096653e7d4ff12
This solved the problem for real HW. Do you have any opinions on this part?
In section 15.4 of the datasheets of the ILI934x controllers the minimum time to wait between releasing of the reset signal and sending the first command is specified to be 5ms. I think we should raise the delay to at least 5ms to be sure that it works reliably.
But the same section also mentions that the Sleep Out command should be send at least 120 ms after the reset, which the current code also violates. Maybe we should shuffle the init around a bit, because we already have a 120 ms delay included in the init, but after all commands have been send.
Thank you @rfuest, for the details from the datasheet. These facts also explain why mipidsi version 0.6 was not working in some cases, often after booting the device for the first time.
@rfuest I've updated delay part. What's your opinion about the solution with delays. I've run test on 11 ESP32 (including S2, S3, C3, C6) all seems to be working.
I think this should work in most cases, but I've looked at the datasheet some more and I think the init sequence still needs some tweaks to work in all cases.
The "Sleep Out" command shouldn't be issued within 120ms of the reset, if the display was already in "Seep Out" mode before the reset. Section 13.2 Power Flow Chart shows the recommended delays.
The datasheet is not very clear, but I think this should be a sequence that works in all cases:
// 15.4: It is necessary to wait 5msec after releasing RESX before sending commands.
// 8.2.2: It will be necessary to wait 5msec before sending new command following software reset.
delay.delay_us(5_000);
dcs.write_command(madctl)?;
dcs.write_raw(0xB4, &[0x0])?;
dcs.write_command(SetInvertMode(options.invert_colors))?;
dcs.write_command(SetPixelFormat::new(pixel_format))?;
dcs.write_command(EnterNormalMode)?;
// 8.2.12: It will be necessary to wait 120msec after sending Sleep In command (when in Sleep Out mode)
// before Sleep Out command can be sent.
// The reset might have implicitly called the Sleep In command if the controller is reinitialized.
delay.delay_us(120_000);
dcs.write_command(ExitSleepMode)?;
// 8.2.12: It takes 120msec to become Sleep Out mode after SLPOUT command issued.
// 13.2 Power ON Sequence: Delay should be 60ms + 80ms
delay.delay_us(140_000);
dcs.write_command(SetDisplayOn)?;
Thank you @rfuest for the suggestion. I'll do the test with the updated code.
Meanwhile, I was speaking with ESP team who is responsible for LCD packages, and they pointed me to the following esp-bsp (Board Support Package) code: https://github.com/espressif/esp-bsp/tree/master/components/lcd
They will be adding new drivers in the future, so it might be a good source for checking implementation.
The change looks good. All boards are performing well, including M5 Stack. I've run the test using the following project: https://github.com/georgik/esp32-spooky-maze-game
@almindor I've updated the CHANGELOG with topics that we've changed here
Thanks everyone this was great work!
There is a new release of Embedded Graphics 0.8. It's necessary to update the dependency on the core to 0.4.0.