RA8876LiteTeensy For Teensy T36 and T40

In the middle of another project but will give it a try and let you know what i find - too many PRs. :)
 
I ported "uncanny eyes" over to the RA8876 library. I'm running two eyes on a 10" screen with a Teensy 3.6. I tried the 128x128 version of the eyes and got about 50 frames a second. I had some artifacts at the bottom of each eye, so added "#undef SPI_HAS_TRANSFER_ASYNC" right after including SPI.h. That got rid of the artifacts but dropped the frame rate to ~45 frames a second.
I next tried 240x240 eyes, which dropped the frame rate to ~20 frames a second. I didn't think they looked good so I switched back to 128x128.

I re-enabled async transfers and started investigating the artifacts. The "uncanny eyes" code does a Serial.println() once a second to report the frame rate. The artifacts in the display coincided with the println() call. I got rid of the artifacts by adding a "while(tft.activeDMA) ;" loop just before the Serial.println() call.

I'm now trying to incorporate the eyes into my Literary Clock (see post #34 in this thread). I'm having some problems with the external font ROM, has anyone gotten it to work?
 
I ported "uncanny eyes" over to the RA8876 library. I'm running two eyes on a 10" screen with a Teensy 3.6. I tried the 128x128 version of the eyes and got about 50 frames a second. I had some artifacts at the bottom of each eye, so added "#undef SPI_HAS_TRANSFER_ASYNC" right after including SPI.h. That got rid of the artifacts but dropped the frame rate to ~45 frames a second.
I next tried 240x240 eyes, which dropped the frame rate to ~20 frames a second. I didn't think they looked good so I switched back to 128x128.

I re-enabled async transfers and started investigating the artifacts. The "uncanny eyes" code does a Serial.println() once a second to report the frame rate. The artifacts in the display coincided with the println() call. I got rid of the artifacts by adding a "while(tft.activeDMA) ;" loop just before the Serial.println() call.

I'm now trying to incorporate the eyes into my Literary Clock (see post #34 in this thread). I'm having some problems with the external font ROM, has anyone gotten it to work?

I played with that when I first got my BuyDisplay 10.1" TFT. It seemed to work ok, Not sure what kind of problems you are having but the external font ROM is setup in the buildTextScreen() function in RA8876_t3.cpp starting at line #1862. The defines used start at line #666 in RA8876Registers.h. In the buildTextScreen() function line #1883 and #1884 are where you set all of the parameters for using the external font ROM including the which font ROM you have.
Hope this helps.

EDIT:
The RA8876.pdf ref manual explains a lot of this. You have to set external ROM use with RA8876_SELECT_EXTERNAL_CGROM. As it is accessed through an SPI port in the RA8878 chip you can select the SPI transfer speed. The default divide ratio is RA8876_SPI_DIV4 as defined in line #1891.
 
Last edited:
Hello,
I'm starting a new project : an automotive race dashboard.
My knowledge is all with engine control unit and I'm not familiar with LCD and GUI.

So I'd like to get thoughts and advices about the way I should go and the path I should follow.

The goal is to have something like these different examples (but not exactly the same of course) :

https://www.aemelectronics.com/sites/default/files/cd-5-straight-18.jpg

https://www.rbracing-rsr.com/turbo/sq6m_webpage/icd_display_03.jpg

https://www.msar.co.uk/user/products/large/aim-strada-mxs-s-i-odb11-msar.jpg

http://0.s3.envato.com/files/142124.png

https://i.ytimg.com/vi/wtXcwcOjaF0/maxresdefault.jpg

https://www.aimtechnologies.com/wp-content/uploads/2018/06/Monitoring-1.jpg

https://www.merlinmotorsport.co.uk/...g?cachebreak=309a7b281d803334380c44e191d9b41a

And so on...

Ideal size will be 6" or 7" with many pixels.

My main interrogation is : is a display with a specific IC like RA8876 is suitable for this kind of project ? If yes, what will be the more efficient way to drive the IC (spi, 8080, etc).

I'd like to stick with teensy 4.1 because I know it well and used teensy since years for many projects.

Any input is welcome.

Thank you,
Manu
 
Hello,
My main interrogation is : is a display with a specific IC like RA8876 is suitable for this kind of project ? If yes, what will be the more efficient way to drive the IC (spi, 8080, etc).

Yes and no. We use the RA8876 type chips because it lets us control thousands of pixels on the screen without using thousands of bytes of memory on our main processor. It also allows us to control those thousands of pixels with only 3 or 4 pins on the main processor. The RA8876 does have exceptionally fast SPI but that's still not fast enough for updating large sections of the screen at reasonable frame rates.

An example of a "large section of the screen" is the digits displaying RPM or MPH. Look at how much of the screen is dedicated to those. You might have an area 200 pixels wide by 100 pixels tall. That's 20,000 pixels. Then you want to send pretty colors, so multiply by 3 to get 3 bytes of RGB color data. Now you're sending 60,000 bytes to the screen just to update those numbers. You probably want to do that 10 times per second and at 8 bits per byte, you're sending 4.8 million bits to the screen per second. You will need to dedicate 5MHz of the available SPI bandwidth to this simple task alone. More complex animations, even something as simple as a "fade" effect, will need higher frame rates and probably want to update every pixel on the screen.

One way that the RA8876 cuts down on the bandwidth is by using drawing commands. "Draw a rectangle 200 wide, 100 tall" is a lot more efficient than sending 20,000 pixels of color data. But this is not appropriate for most of the examples you showed. The graphics have smooth edges, which can't be done with simple drawing commands like squares and triangles. You need a lot more control and much more sophisticated drawing commands than what the RA88765 offers. If you can live with hard-edge graphics, like your last example, then the RA8876 may be appropriate.

The processor inside the Teensy 4 has dedicated hardware for sending bulk data to LCD screens. On the Teensy 4.1, there are enough pins available to make that possible. You can use the 16-bit 8080 interface on the RA8876 to send many megabytes per second to the screen. With the dedicated hardware, you don't need to spend a lot of your program cycles on managing that. But it does mean you need to have enough memory to hold the entire screen in memory all at once. I played with this idea but never actually built the circuit to test it with the RA8876.
 
Thank you for this clarifications. I was afraid about getting this king of answer, but I was sure to get it.

I'll have a look at teensy 4.1 dedicated hardware and see if can be used with the actual teensy 4.1 form factor.

Or maybe switch to another MCU if not (I have a spare ST32F469I disco board somewhere, if I can get my hand on it)
 
Hello, did somebody succesfully implemented / used the user-defined characters feature on the ER-TFTM101-1 ( 1024x600 dots 10.1 "color tft lcd display with RA8876 ) ? I'm struggling to get this working ... I'm using the CGRAM_initial code, however without succes sofar .... would be great if somebody can share a complete working example. Thanks in advance !
 
Hello, did somebody succesfully implemented / used the user-defined characters feature on the ER-TFTM101-1 ( 1024x600 dots 10.1 "color tft lcd display with RA8876 ) ? I'm struggling to get this working ... I'm using the CGRAM_initial code, however without succes sofar .... would be great if somebody can share a complete working example. Thanks in advance !

Hopefully someone one will be able to help you here. I personally have not tried any of the RA8875/76 custom font stuff, nor any of their ROM chips.

What we have done when we were playing with supporting drivers for some of these displays was to add the ability to use the Software Fonts that we have support for in other drivers. This includes all of the Adafruit fonts as well as our ILI9341_t3 like fonts.

Not sure if that would help you or not.
 
Thanks Kurt, I'll have a look ... where are those fonts stored then ? .. I assume just in code space and they are send to the display via program code ... I think this way is 'much' slower then using the char generator. I'm working on some TFT for my 737 Flight sim and am exploring the fastest way to update for example the speed & altitude on the PFD screen pfd1.JPG
 
SDR with Spectrum Display with T4 and RA8875 & RA8876

Just to let you know I have been working on a Teensy 4 based SDR project and leverage the BTE feature heavily to do my FFT spectrum draw and the waterfall scrolling. I have this working on both the RA8875 4.3" and RA8876 7.0", both with capacitive touch screen.

I used the RA8875 included ringMeter for a multi-function meter. For the RA8876_t3 lib, it does not have that so I pulled form various places and now have a relatively non-display specific ringMeter feature working both the RA8876 and RA8875 (for coding ease).

I was not happy with gesture support in the FT5206 driver. Pinch and an occasional swipe would register. Up to 5 touchpoints registered and tracked well though. So I created my own gesture engine. I am happy to report it is working quite well and I am using long press, press, swipe up, down, left and right, drag up, down, left and right, and ping in and out. Also have 3 finger swipe but that takes practice. This works for either display. I recently added touch rotation #define.

Here is what the current version (April 19, 2021) looks like so far. Here it is working as a Panadapter for a Elecraft K3 radio with output at 8.215Mhz with a CAT serial port connection to sync data with the radio including spectrum signal alignments. Teensy 4.1 with PJRC audio card and OpenAudio_Library running the new 32bit floating point versions, here with 4096 I & Q FFT at 102Khsz sample rate. The 7" RA8876 is 1024x800 and the FFT bins are mapped 1:1 so only viewing 1/4 of the info. Peak signal power frequency detection is indicated in the spectrum area. You can swipe to TouchTune, drag to tune or change ref level, swipe to change bands, plus several more gestures. RX board is a QRP-Labs RX module with Si5351A PLL board. In radio RX mode I am using the SV1AFN preselector (Bandpass filter) board which also switches in and out a PE4302 digital step attenuator and a HF preamp. Also supported are Duppa.com I2C encoder modules to daisy chain all the encoders you like. I am using the RGB LED version encoders with translucent knobs that change color when pressed or when turning and you reach a value range limit. For the ringMeter, you can touch or long press the S-meter for RF and AF gain. In TX it shows power or ALC..

Thought you might like to see the result of your library efforts! A number of us have or are building these.

20210410_211709.jpg
 
Another ER-TFTM0784-1 black screen - gotchas?

Interloper here from ESP32-land! I've got one of these 1280x400 displays (ER-TFTM0784-1) that I'm having trouble getting working at all, and the folks here seem to be most experienced with it, so hope you don't mind me joining the conversation...

I've tried various drivers but for now am starting with https://github.com/caiannello/ER-TFTM0784-1 since the Due code is the easiest to adapt (and largely the same as BuyDisplay's demo code) - I'm using Arduino framework so only minor mods needed to SPI.

Checklist:

  • Ordered 4-wire SPI, 5v, no touch screen - all jumpers seem in order
  • Using USB power into VSS and VDD, rest of pins (and extra ground) direct from MCU (ESP32 is 3.3v)
  • Board comes as default with external PWM control, so commented out the PWM code - driving this directly, and I see the backlight
  • Serial debug confirms the RA8876 is initialising - eg LCD_StatusRead() shows 01010000 before RA8876_SDRAM_initail(), then 01010100 after it
  • So my SPI seems working (testing @ 10Mhz)
  • Double/triple checked my wiring/pins for the SSD2828 (using pins 31/32/34/35 on the display)

But I just get a black (with backlight) screen (although serial reports back the demo stages progressing). Bad hardware seems unlikely given both the backlight and RA8876 seem to be working?

I'm guessing something up with the SSD2828 side - since it's just one way I don't know if it's working. The bit-banged SPI calls spi_delay() - this calls nop, unsure if this would be any different on ESP32, I've tried it with eg delayMicroseconds(10) instead but still no luck.

Any gotchas from anyone who has this working?

Failing that, can you point me (a teensy novice) to a) the minimum Teensy needed for the current library, and the current branch/version that supports this specific display so I can try the display with a known working setup?
 
Last edited:
So... ignore the above... after spending the entire weekend on this, finally found the missing piece! Some more obtuse searching eventually found this post: https://groups.io/g/keithsdr/topic/success_with_7_8in_400x1280/82704422

The basic gist is that there are 2 differing bytes in the SSD2828 code:

Or if you want to manually make the changes yourself simply search this file (in your Arduino/libraries) for SPI_WriteCmd(0xBA) and change the SPI_WiteData immediately following it from 0x20 to 0x25

Changing this has Craig's port of the BuyDisplay demo working, and also the RAIO RA8876_Lite library (with the SSD2828 init added). Now I have that working I'll take a look at the Teensy version, which seems to be enhanced, to see how easily I can port it.

I note the "incorrect" version is in the libraries@
https://github.com/blackketter/Ra8876LiteTeensy
https://github.com/wwatson4506/Ra8876LiteTeensy/tree/Ra8876LiteTeensy-ER-TFTM0874

Folks earlier in this thread seem to have this working - so I wonder if perhaps the TFT got updated sometime requiring this change?

Anyway, hopefully this helps the next person searching for this. I can't figure out how to reply on groups.io :| so Dave, if you are here, many thanks :)
 
Yesterday, I pulled out my RA8876 7" display, for the first time in awhile to play with our run amuck ;) Picture Viewer with MTP

Note with this display, that it is setup, I need to add: tft.backlight(true);

to make it work otherwise black screen...

But was wondering has anyone had luck with their 7" display with capactive touch on getting that to work.

I tried the FT5... library, no luck.

I have also copied the support from our updates to RA8875 version of library and that code works on my 4.3" display which as far as I can tell has identical pinout as the RA8876.

I verified that the RA8876 appears to be talking over wire as we are getting acks on the transfers.
screenshot.jpg

But the CTP/ISR pin always stays high.

Again same setup works on the other display.

So again wondering if anyone has had any luck? I probably asked this before, but...
 
I'm using both the 7", and the 10" RA8876 with CTP from BuyDisplay in several setups both with Teensy 3,6 and 4.1.
I usually redirect SPI SCK to pin 14, and use a 33Ohm resistor in series of the SCK line.
Most project is using ZIF cable to custom PCB, other have PCB and display "stacked" on top of each other.
I cant get the attach photo to work here, else i would have shown some photos.
I use the Lib discussed in this thread since it can do rotate, and I use a DIY mix of the original Lib from BuyDisplay and xlatb a frend made for me.

I do have purchased the two of 7.84" streched TFT modules also, but have never tried it.

/Gigabyte
 
Thanks Gigabyte - The code works on @mjs513... I think I may simply have faulty CTP controller... Ordered another display... But don't really need it, but simply doing as to play with
and hopefully improve a few of the libraries...
 
On the touch stuff, as I mentioned, I ordered another display... Now that CNY is I think over, hopefully should ship soon.

On a different front, while I have some free time, while waiting for some ideas of which way to go on things with MTP and MSC, thought I would play some more with the
picture viewer that allows you to download pictures using MTP...

We have it working with ILI9341 both my library (_t3n) with frame buffer support and yesterday added code to emulate frame buffer for _t3. Works also with out St7735/89 library and ILI9488...

But have also now been playing with the RA8876 and right now in particular to try to use offsecreen memory to update such that you don't see the window painting slowly over several seconds...

Have a version of it now that works with t4.1 with extmem, where I generate a full frame, and then send the whole frame
The update code now looks like:
Code:
    tft.useCanvas();
    tft.putPicture_16bpp(0, 0, g_tft_width, g_tft_height);
    tft.startSend();
    SPI.transfer(RA8876_SPI_DATAWRITE);
    SPI.transfer((uint8_t*)g_frame_buffer, NULL, g_tft_width*g_tft_height*2);
    tft.endSend(true);

    //tft.putPicture_16bppData8(0, 0, g_tft_width, g_tft_height, (uint8_t*)g_frame_buffer);
    tft.updateScreen();
Sort of hacky... was using the commented out function, which is outputting one byte at a time using transfer.
This cut the time down from over 7 seconds to about 3.5...

screenshot.jpg
Can cut this down also by seeing if I can get enough functions working with the canvas like idea such that I only actually upload the image... The background cleared by faster transfer...

Now back to playing.
 
On the touch stuff, as I mentioned, I ordered another display... Now that CNY is I think over, hopefully should ship soon.

On a different front, while I have some free time, while waiting for some ideas of which way to go on things with MTP and MSC, thought I would play some more with the
picture viewer that allows you to download pictures using MTP...

We have it working with ILI9341 both my library (_t3n) with frame buffer support and yesterday added code to emulate frame buffer for _t3. Works also with out St7735/89 library and ILI9488...

But have also now been playing with the RA8876 and right now in particular to try to use offsecreen memory to update such that you don't see the window painting slowly over several seconds...

Have a version of it now that works with t4.1 with extmem, where I generate a full frame, and then send the whole frame
The update code now looks like:
Code:
    tft.useCanvas();
    tft.putPicture_16bpp(0, 0, g_tft_width, g_tft_height);
    tft.startSend();
    SPI.transfer(RA8876_SPI_DATAWRITE);
    SPI.transfer((uint8_t*)g_frame_buffer, NULL, g_tft_width*g_tft_height*2);
    tft.endSend(true);

    //tft.putPicture_16bppData8(0, 0, g_tft_width, g_tft_height, (uint8_t*)g_frame_buffer);
    tft.updateScreen();
Sort of hacky... was using the commented out function, which is outputting one byte at a time using transfer.
This cut the time down from over 7 seconds to about 3.5...

View attachment 27481
Can cut this down also by seeing if I can get enough functions working with the canvas like idea such that I only actually upload the image... The background cleared by faster transfer...

Now back to playing.

This is really interesting in the fact that I spent this weekend updating all of my programs to use the last version of RA8876LiteTeensy that you guy's reworked:) I am working on eliminating tft.c and tft.h completely. I had forgot how much work you guy's put into to it and did not realize how complete it is. Made it a lot easier to rework my programs. The only problem I had was with the status line usage and I only had to subtract 'STATUS_LINE_HEIGHT' from '_scrollYB' in a few places in the code. That fixed the issues. Been going through all of the examples to make sure I did not muck it up. I also had to temporarily make public instead of private a few of the variables I use in other programs until I create methods of access to them. (Unless there is another way that I do not know about to do it)
Anyway, cutting the transfer speed by halve is impressive.

For me, back to reworking and learning:)
 
I do have the picture viewer working better now on the RA8876,

I now have it uploading the pieces of the new pictures into PAGE2 and then when fully loaded I then tell it to copy the data to page 1...

screenshot.jpg

I probably need to clean it up a little, but as I said works pretty well to be able to use MTP to put in new images (bmp, png, jpeg) and does some scaling of the images to fit...
 
I do have the picture viewer working better now on the RA8876,

I now have it uploading the pieces of the new pictures into PAGE2 and then when fully loaded I then tell it to copy the data to page 1...

View attachment 27486

I probably need to clean it up a little, but as I said works pretty well to be able to use MTP to put in new images (bmp, png, jpeg) and does some scaling of the images to fit...

That sounds like maybe the best way to do it with SPI. Using a PAGE buffer in the background for transfers and then doing a BTE copy when available to display. I remember there was work on an 8080 interface with the T4.1. The Buydisplay tft's can be configured for that. Would be interesting to see if those worked together and what kind of performance could be achieved. I want to get another 10.1" display with CP touch anyway. The displays can be reconfigured with adjusting the jumpers on the control board which is not trivial as they are numerous and spread all over the board:)
 
@All - Just pushed up a minor change to RA8876_t3.cpp. In ra8876Initialize() setClipRect() must be called before first usage of fillScreen() which calls drawSquareFill(). drawSquareFill() is ineffective otherwise.
 
@KutrtE - merged the PR... Been updating all of my libraries to use the updated version of RA8876_t3. Seeing that I have a lot to figure out:)
 
RA8876 Turn On Steps, Touch operation

@KurtE

For my RA8876 I use 2 commands for internal backlight, no wire or jumpers required as I recall.
tft.backlight(true);
tft.displayOn(true);

>>But was wondering has anyone had luck with their 7" display with capactive touch on getting that to work.
>> I tried the FT5... library, no luck.

I am using the separate FT5206 touch library with my RA8876 and it has been working very well for a year now. On my 7" I operate my Teensy based SDR radio completely via touch, knobs optional. I wrote a gesture engine that allows swipes, drags, and pinch as well as a button handler and GUI control system driven by tables to place and link touch to screen objects. Works with both the RA8875 (internal library touch controller enabled) and the RA887 using the FT5206 library.

code here
 
Thanks all,

Touch - I merged in the same code as the RA8875 has for capacitive touch so did not require the other library, also if I remember correctly with this allowed different Wire objects to be used. . My issue with first board on touch was my own wiring, I had both interrupts wired to same IO pin... so removed shunt and it works.

As for 7" to work as I mentioned I now have two. They both use the ER-TFT070-6 v1.1 boards. One worked with your tft.backlight(true), the other does not.

The differences was in the soldered jumpers on the board:
When I looked at the boards, J27 and J28 were different on the two boards:
From their PDF
screenshot.jpg

On my new board I am playing with, I did route connection for the BL connection, so connected it up and told the IO pin to go HIGH and then the display worked.
This is to pin14 of the display
 
Back
Top