LVGL compatible DMA enabled LCD drivers for Teensy 4.x

I understand your point of view, and I totally agree that your style makes sense given a more professional approach to product development. For myself, I had the need to support a half dozen or so devices running the same codebase on very different hardware and found the flexibility of lovyangfx made that trivial. Sure, I'm not using most of its functionality but that compiles away without burden because the performance was outstanding compared to the more basic drivers available for the platform.

I know it looks ugly, I thought so too at first but it works so much better for me in practice having that detailed definition available all in one place for reference and tweaking. It also supports an impressive list of devices, all my varied and hacked up hardware worked out of the box.

Still, horses for courses. I do like your library and look forward to trying it, it looks very neat and clever and should make for a good tight coupling with lvgl.
 
honey_the_codewitch said:
oh interesting. yeah i could make one, but i can't test it. instead, I'll leave an open offer to help should one of you decide to implement this driver using the code I provided, but i'll need your help to actually test it. I'm loath to order another screen, just because I've ordered so many that I only ever use once, it's getting ridiculous.
Click to expand...
I completely hear you on this! You don't know how many cameras, displays, joysticks, mice, keyboards, etc. I have sitting around here, mostly stuck in boxes in cabinet. And I only do this for the fun of it! And I now have 4 of the ST7796 displays (2 of each I mentioned).

Edit: At least these are reasonably cheap, as compared to ones like RA8875/RA8876.
 
I have a couple of RA8875s because we involved them with an initial prototype of a device we were building for work, so I didn't pay for them fortunately. Can't say I'm a fan of the slow speed of the chip, even with the "graphics acceleration" which is almost useless if you need something that looks modern and anti-aliased. About the only thing it really helps with, if you work at it, is displaying pngs, because of the way they decompress, it just happens to fit with the way their "graphics acceleration" works, at least for the drawing, not the decompression ofc.
 
Here's a first draft of a driver for st7796. Seems to work, I have done some limited testing over the last week. I put it on my github because I don't know how to submit a whole repository. @honey_the_codewitch feel free to take ownership.

st7796_t4

Performance is outstanding, from an average 15fps using ST7735_T3 and chugging hard at 90%+ usage to about 25fps with a much more relaxed ~80% usage when animating a fullscreen scrolling chart. Very nice!
 
What's curious to me is the 80% usage and if there's a way to get that higher. 320x240@16bpp over 1 bit SPI should net you up to about 31FPS before saturating the bus so you're close to maximum speed already if not there already. But where's that other 20% of usage getting lost? You got me curious. I'll need to get an ST7796
 
I could probably get higher, the code is still in system testing and verification phase, not yet optimized and I have delays where they probably dont belong (like the main loop). There is other stuff happening too, the sampling interrupt fires every 1100us and lasts 320us reading all the i2c registers of both shunt amplifiers at 1mhz and while recording also prepares the arrays for the real-time chart display so a fair bit of cpu is being tied up there.

Mind you the screen is running 480x320 at 80mhz (or whatever the actual frequency is you get when you use that value for SPI?) to get the quoted performance and is perfectly stable without any issue. This is in a lashup prototype without much care for the wiring.

However it was interesting to see that because the SPI is running during sampling, I was getting some slight interference in my readings corresponding to screen activity. RF noise from SPI was leaking into the shunt amplifiers. Shielding didn't help, the grounding was already good, turns out a simple snap-on balun on the i2c wires was the answer and it is only a bit above the noise floor now which seems to be about 100nA. More than sensitive enough for any practical use I will have for it.

I'm very happy. Everything is working as intended and looks great! I will end up with a very functional and stylish new bench power supply, soon I can finish this side project and finally use it to slim down my battery hungry lightning detector.
 
prickle said:
I'm very happy. Everything is working as intended and looks great! I will end up with a very functional and stylish new bench power supply, soon I can finish this side project and finally use it to slim down my battery hungry lightning detector.
Click to expand...
That's great to hear, and I'm glad the code is working out for you. Thanks for your contribution. At some point I need to go back and shore up these libs and officially release them. When I do i'll add your code to the array of supported libs and credit you. I may make small changes for naming consistency. (I know camelCase is all the rage in arduino, but most of my stuff is not limited to arduino, and my C and C++ projects tend to prefer snake casing) wars have been fought over less, I know. =) plus i may end up adding additional features such as formalizing the offset/gap spacing for X and Y positions because that's so common with displays.
 
Go for it, please take ownership and change it to suit your vision. My cut'n'paste style is simply too lazy to be consistent. Cheers!
 
You must log in or register to reply here.
Back
Top