Yeah that Display has an esp32 built in to do all the grunt work. Still might be a challenge getting it to work? Worth the effort IMHO.
1 Like
I donāt think I am. I am probably just bouncing between too many things, and then not offering sufficient context switching warning! Apologies.
Yes, I understand that. Thank you for this idea. I did acknowledge this, but I said that since it will probably involve soldering, it is not a path I wish to go down, at least for now.
Yep, hence my linking to the PDF - either for future-me, or future-someone-else, who is daft enough to try creating the I2C commands themselves. {grin}
I linked to this as I may just use the returns policy to send back my current widgets, and use the M5stick instead.
Indeed. The image from the root of that repo implied (at least to me) that SPI was available over the USB interface, coming from a PC. But I would do more research on that prior to buying, given that I may find another gotcha once the parcel has come through the door!
(I await guidance from Support on the cable and feasibility question on the components I have).
Ah, I just spotted something I should clarify - the protocol spec PDF is provided for the m5stick. But this device uses the same LCD panel as the one I have had delivered, as far as I can tell, and I think the PDF was written by the LCD manufacturer (Sitronix), not m5stack. It just so happens that m5stack have put it on their website.
Well, I now have the right cable, and my computer, I2C board, and LCD panel, are set up in the intended chain.
Iāve tried a fair few drivers, and each seem to have their problems unrelated to the LCD panel. I have found one though, based on PHP 7.4, which is showing signs of progress.
I had originally assumed this display was āraw I2Cā, but in fact it has ESP32 built in (see here). I think this means that the command primitives will be less cumbersome to work with. I am hoping to use these commands, which are basically reads and writes of byte sequences.
However I have run an i2cdetect -y <bus> and found six different addressable devices, none of which corresponds to the 0x3E I was hoping to find for the panel. The panel does do a start-up graphic display, so I am fairly sure it is working (and Iāve not bricked it yet!).
I have some code to send byte sequences to an existent address, and to receive byte sequences. The first one produces intelligible results (though I donāt know what they mean yet) and the others seem to produce 0x00 or 0xff sequences. The second one caused my monitor to blank, which was a bit of a worry - my research indicates that a dud command sequence can brick an EEPROM. I was initially experimenting on an expensive laptop, and for safety I have now transferred to a Pi!
However, it occurs to me that the MCP2221 is an intermediate device, and I have to address that, not the LCD panel. This spec PDF seems to agree - there is an I2C command to send an IC2 write command - yikes! So I can send 0x90 (I2C Write Data) via I2C, using the address of the MCP2221, and this contains a payload containing the address of the LCD panel, plus any data to forward on.
Some of the Linux-level documentation indicate that when addressing a device via I2C, you donāt just need to specify a device and an address, but a āregisterā as well. My testing so far indicates, at least with the MCP2221, that this integer value makes no difference.
š¾ š Success! š š¾
Using this Python library I have been able to send graphics primitives to the LCD screen. Itās very low-level, but at least it works. I was barking entirely up the wrong tree earlier - using on-board I2C wonāt work. One has to use USB primitives to talk to the adaptor, which then converts the data to I2C on the callerās behalf (and this library simplifies that a great deal).
Now for fonts, graphics shapes, animationsā¦ š
I now have a simple image rendering system on this device chain:
Per my last post, the USB driver is in Python. Rather than doing anything complicated here, I have merely got it to render an image. The USB-I2C bus is pretty slow, so a whole 240x135 screen takes about four seconds to draw (but I have speeded it up, see below).
Presently what is on the LCD panel is created in GIMP, and is hardwired for mock-up purposes. But getting this information from a running Linux machine should be straightforward. I currently have:
- Now playing artist (bold font)
- Now playing track (normal font)
- Service status icons (failures would be in red with a different icon)
I might add album count, track count, current track position, box IP address, etc.
The panel itself is great. The display of fonts is crisp and readable, even at small font sizes. I suspect this is due to the anti-aliasing added by GIMP. The ārealā renderer will be programmatic, but will do the same thing.
Once this is installed on the target box, Python will just accept a string of raw image data as a console parameter, and render it on the screen. This will allow me to write the image renderer code in PHP, which I prefer (I like semi-colons). The original image data is 24-bit, but this is down-scaled to 8-bit colour for speed (the panel supports 8, 16, and 24 bit colour - even 32 bit with an alpha channel).
Smoother anti-aliasing would likely be achieving by using the expanded colour palettes, but I assume these would be slower to draw. Iāve not tried them yet, but might do.
To speed things up further, I have compressed the raw 8-bit colour using the simple RLE system, which brings the render time for a full screen draw to about 2.5 seconds. Itās not enough for animation, but for status panels it is fine.
Further speed-ups would be possible by drawing screen sections independently, and only updating the part of the screen that needs to change. But I am not sure that is worth the extra effort for my use-case.
1 Like