ST7796 Teensyduino support

KenHahn said:
You really are leaving no stone unturned!
Click to expand...
I’ll probably get bored soon :rolleyes:

A lot of the motivation for that rig was getting fed up with disconnecting and reconnecting in order to try different displays, and the associated risk of damage to the kit.

That looks like a nice display, I’ll probably add one to the growing collection at some point. Part of the recent hiatus was caused by the ST7789 displays being shipped from China in anti-static bags, along with others in plastic boxes, all stuffed into a single padded envelope. Oddly enough, the unboxed ones were all broken on arrival…
 
The latest commits to the big-screen-t4 branch now have the ability to coexist with ILI9341 and GC9A01A displays on a single SPI bus, provided you also grab the linked branches for those displays. You can also have multiple ST77xx displays on one bus, of course. Each display needs its own /CS, and you need to deal with a shared /RST yourself.

I haven't ported the non-interference changes into the ILI9341 and GC9A01A drivers, mainly because it's likely to become a maintenance nightmare in very short order. (Also, the repos I've based my changes on are not actually part of Teensyduino, they're developed from it with optimisations.) It's not clear to me what the best approach might be towards trying to unify the many disparate drivers, and indeed whether it's even worth trying to continue Teensy 3.x support, given they're legacy products.
 
@h4yn0nnym0u5e - installed 1.60b5 and lost the DMA code edits.
Are they needed? Did those files change - I pulled latest display github - but didn't put in libs folders ... but just building Ken's demo failed and forced recall ...
 
@defragster - yes, they are still needed, and Paul's "DMAChannel default channel preemption settings" commit has managed to break my detection of the fully-working DMA code changes :mad:

You'll need to reinstate the edits, and add #define DMA_PREEMPTION_AVAILABLE into DMAChannel.h, and pull the latest changes from my development branch. If that's all done correctly, audio will still work; if not, it goes back to being broken.
 
h4yn0nnym0u5e said:
still needed
Click to expand...
Figured - not sure about hacking - will see. Hope the work might get incorporated in a usable fashion.

@KenHan noted even the simple PR I did wasn't included either to prevent Always breaking the transaction - even when tiny that was enough to allow clear audio in the simple cases for fonts - but just allowing the same Transaction breaks copied from another display
 
I've just pushed another change, so the check is now against #define DMACHANNEL_HAS_PREEMPTION, which is more consistent with existing macro names.

Agree, it's all a bit of a pain to have to hack on many files to make stuff work :(
 
...and again - there's now no need to #define DMACHANNEL_HAS_PREEMPTION. This is at the expense of the user sketch having no way to tell whether DMA preemption is available. If it's not, audio playback won't work.
 
FONT QUESTION:
Is it by design that there are font refs back to ILI9341 and not all changed over to the ST7735 base family? Struct and .h included?

Few are included in the beta release - there are some in a ZIP in the folder? Working on changing a touch UI from ili9341 to st7796.

Sketch at hand wants Arial__BOLD font found in the zip. It is working - though a WIP needing cleanup.

Having some grief on other than DEV machine that works - but sharing it tough and it ends up failing.
 
defragster said:
FONT QUESTION:
Is it by design that there are font refs back to ILI9341 and not all changed over to the ST7735 base family? Struct and .h included?

Few are included in the beta release - there are some in a ZIP in the folder? Working on changing a touch UI from ili9341 to st7796.

Sketch at hand wants Arial__BOLD font found in the zip. It is working - though a WIP needing cleanup.

Having some grief on other than DEV machine that works - but sharing it tough and it ends up failing.
Click to expand...
Morning Tim

All our graphics libraries using the ILI9341 font and font structure as the common denominator. You mentioned the ST7735 base family - if you look at the defined font family it references back to the ILI9341 font:
```
#ifndef _ST7735_t3_font_ComicSansMS_
#define _ST7735_t3_font_ComicSansMS_

#include "ILI9341_fonts.h"

#ifdef __cplusplus
extern "C" {
#endif

extern const ILI9341_t3_font_t ComicSansMS_8;
extern const ILI9341_t3_font_t ComicSansMS_9;
extern const ILI9341_t3_font_t ComicSansMS_10;
extern const ILI9341_t3_font_t ComicSansMS_11;
extern const ILI9341_t3_font_t ComicSansMS_12;
extern const ILI9341_t3_font_t ComicSansMS_13;
extern const ILI9341_t3_font_t ComicSansMS_14;
....
```
Doing it this way also allows for using the ILI9341_font library (https://github.com/mjs513/ILI9341_fonts).

Hope that explains it.

Mike
 
Morning all,

Might also mention, if that is not enough fonts, than most of our drivers also support using the
Adafruit GFX Fonts. (Note: ili9341_t3 does not, but ili9341_t3n does).

One nice thing of Adafruit fonts is that they are one size of character per file, so they take less room.
But a little tricky code wise as font characters can overlap...
 
mjs513 said:
ILI9341 font and font structure as the common denominator.
Click to expand...
Thanks @mjs513 and @KurtE
I thought that was the right answer - but was chasing a build problem where it was grabbing something and then left hanging and broke the build ... except on my dev machine.

As soon as I can get back to it - I'll try to clean up the mess I made chasing a phantom and post something.
 
You must log in or register to reply here.
Back
Top