frankcohen
commented
3 years ago Hi Jont, welcome to the team! The water is warm, jump right in! :-)
I don’t much like C/C++ either. I’m much happier in Java and Python. One thing you might want to consider is getting MicroPython/CircuitPython running on the EleksTubeIPS. I’d be glad to help you.
I see your question about screen width, TFT_eSPI, and ST7789 and I wish I could say I had an answer. I don’t. My experience with these TFT displays is we stream a bunch of data to the 7789 controller and it deals with byte boundaries. I have crashed the controllers by sending it data it didn’t expect, but those crashes are few and far between.
The cool thing about the TFT_eSPI driver is all of the source code is right there for your investigation. You can see what it does to decode the image data and stream it over SPI to the display controller. And, my attitude is ‘meh, if it works that’s good enough for me’. hehehe
My next steps are to fire-up the Wifi interface on the ESP32 and see if I can stream images and video from an AWS hosted Web server over HTTP to the EleksTubeIPS. I’ll have more hacking time coming up this weekend.
You may find my other nights-and-weekends project to be interesting. Reflections is at https://github.com/frankcohen/ReflectionsOS. It’s a wrist watch that lets me play videos of my kids while they were growing up on my wrist. It is distributed under a GPL v3 license. I’m hoping to provide the EleksTubeIPS hack with a Web browser interface by adapting the Reflections code.
Happy hacking!
-Frank
Frank Cohen, Founder @.*** http://www.votsh.com Phone: (408) 364-5508 USA
On May 12, 2021, at 7:33 AM, jont-studioj @.***> wrote:
Forgive me if this the wrong place / wrong way to get in touch.
I recently got the EleksTubeIPS and am interested in its hacking capability.
I have followed with interest (if not wholly absorbed) the discussion thread on Reddit.
It seems you people have already gotten a long way forward, nice work.
I am a developer - but I'm now old and my brain isn't as spritely as it once was, I'd love to contribute (and still could) but fear I may be more of a hindrance than a help (as you are about to find out!)
I have done very little in the way of dealing with micro-controller projects (I've done just one Arduino project some years back) and have little experience in dealing with interface chips / libraries etc.
Riding on the shoulders of you good folk I have managed to check out the bouncing ball project and successfully got that built, running and (most importantly) restored the clock to its original f/w, using your instructions (and the "font-editor's" copy of esptool.exe, on Windows). Phew.
Wishing to see what can be done - and as a way to familiarise myself with the environment etc - I decided to see if could hack at the bouncing ball sketch to make it do something different.
C/C++ isn't my choice language (far far from it, I've managed to avoid those throughout my career - tbh, I actively dislike them!) so this would've been some bit of a way of forcing myself to learn a bit and get more familiar. But really, I am playing and not doing anything particularly useful. Yet.
Hacking at the code I came across an issue which I am struggling to overcome (I'm not expecting anyone to hand-hold me) but this issue has prompted me to write this text now.
I was struggling with the generation of graphics and the blitting of data to the displays, via the TFT_eSPI library. After much struggling trying and failing to get colours and stuff right.. I double checked the display/interface as described on https://www.aliexpress.com/item/32564432870.html https://www.aliexpress.com/item/32564432870.html and noticed that it says "Display Color: 262K"... and after some quick investigation this lead me to believe that the display takes 6bits per colour per pixel? rrrrrrbbbbbbgggggg (or whichever way round it really is)... which makes 18bits per pixel... I then peeked into the TFT_eSPI library/headers which seemed (at least on casual reading) to suggest it deals with 1 4 or 8 bits per colour per pixel - and has nice 8bit/16bit data-size/buffer-size/boundaries for many of its functions.
Thinking that I want to send 135 pixels (a single display row) of 18 bits per pixel down to the display (or its controller chip or whatever) doesn't go nicely into any nice boundary/buffer-size of some byte/int or whatever.. hmm.. and this shows up even where I flail with c/c++! but never-mind.
( specifically a line like: tft.pushPixelsDMA(&renderbuf[bufIdx][0], SCREENWIDTH); and the preparation of said buffer etc )
It's quite possible that I am missing something.. but I wondered whether the TFT_eSPI library code is actually capable of driving this display sensibly?
Again, not familiar with how these things are done generally (or, indeed, I haven't read enough), is it the case that lots of code (including the library) can deal with nice power-of-two sized pixels/buffers (with the 6 bits of each colour padded out to a byte with zeros) and it goes all the way through that way until it reaches the actual display (or its controller)... where it is finally converted to the required 18bpp.. and that I shouldn't myself be trying to pack 3 colours of each 6-bits for a pixel spreading over a non-integer number of bytes inside buffers etc? Or is there a fundamental incompatibility between the library and the ultimate display?
Sorry for what might seem like dumb questions but I am somewhat flummoxed at the moment. Happy to delve further and work it out myself.. but not sure where I should be looking.. look harder into the library code? ..investigate the display's controller (ST7789) more? (or both, of course) - or maybe this is a genuine issue. Any clues, advice?
Regardless of whether you are able (or want) to help me, I'd like to say thank you for the work (investigation & dev) you've put in.
Many thanks in advance.
jont
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SmittyHalibut/EleksTubeHAX/issues/2, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUEWMI25NM6SEZ37T63JRTTNKGSVANCNFSM44YXMH2A.
jont-studioj
Forgive me if this the wrong place / wrong way to get in touch.
I recently got the EleksTubeIPS and am interested in its hacking capability.
I have followed with interest (if not wholly absorbed) the discussion thread on Reddit.
It seems you people have already gotten a long way forward, nice work.
I am a developer - but I'm now old and my brain isn't as spritely as it once was, I'd love to contribute (and still could) but fear I may be more of a hindrance than a help (as you are about to find out!)
I have done very little in the way of dealing with micro-controller projects (I've done just one Arduino project some years back) and have little experience in dealing with interface chips / libraries etc.
Riding on the shoulders of you good folk I have managed to check out the bouncing ball project and successfully got that built, running and (most importantly) restored the clock to its original f/w, using your instructions (and the "font-editor's" copy of esptool.exe, on Windows). Phew.
Wishing to see what can be done - and as a way to familiarise myself with the environment etc - I decided to see if could hack at the bouncing ball sketch to make it do something different.
C/C++ isn't my choice language (far far from it, I've managed to avoid those throughout my career - tbh, I actively dislike them!) so this would've been some bit of a way of forcing myself to learn a bit and get more familiar. But really, I am playing and not doing anything particularly useful. Yet.
Hacking at the code I came across an issue which I am struggling to overcome (I'm not expecting anyone to hand-hold me) but this issue has prompted me to write this text now.
I was struggling with the generation of graphics and the blitting of data to the displays, via the TFT_eSPI library. After much struggling trying and failing to get colours and stuff right.. I double checked the display/interface as described on https://www.aliexpress.com/item/32564432870.html and noticed that it says "Display Color: 262K"... and after some quick investigation this lead me to believe that the display takes 6bits per colour per pixel? rrrrrrbbbbbbgggggg (or whichever way round it really is)... which makes 18bits per pixel... I then peeked into the TFT_eSPI library/headers which seemed (at least on casual reading) to suggest it deals with 1 4 or 8 bits per colour per pixel - and has nice 8bit/16bit data-size/buffer-size/boundaries for many of its functions.
Thinking that I want to send 135 pixels (a single display row) of 18 bits per pixel down to the display (or its controller chip or whatever) doesn't go nicely into any nice boundary/buffer-size of some byte/int or whatever.. hmm.. and this shows up even where I flail with c/c++! but never-mind.
( specifically a line like:
tft.pushPixelsDMA(&renderbuf[bufIdx][0], SCREENWIDTH);and the preparation of said buffer etc )It's quite possible that I am missing something.. but I wondered whether the TFT_eSPI library code is actually capable of driving this display sensibly?
Again, not familiar with how these things are done generally (or, indeed, I haven't read enough), is it the case that lots of code (including the library) can deal with nice power-of-two sized pixels/buffers (with the 6 bits of each colour padded out to a byte with zeros) and it goes all the way through that way until it reaches the actual display (or its controller)... where it is finally converted to the required 18bpp.. and that I shouldn't myself be trying to pack 3 colours of each 6-bits for a pixel spreading over a non-integer number of bytes inside buffers etc? Or is there a fundamental incompatibility between the library and the ultimate display?
Sorry for what might seem like dumb questions but I am somewhat flummoxed at the moment. Happy to delve further and work it out myself.. but not sure where I should be looking.. look harder into the library code? ..investigate the display's controller (ST7789) more? (or both, of course) - or maybe this is a genuine issue. Any clues, advice?
Regardless of whether you are able (or want) to help me, I'd like to say thank you for the work (investigation & dev) you've put in.
Many thanks in advance.
jont