Forum Rule: Always post complete source code & details to reproduce any issue!
Page 14 of 14 FirstFirst ... 4 12 13 14
Results 326 to 337 of 337

Thread: RA8876LiteTeensy For Teensy T36 and T40

  1. #326
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,967
    In the middle of another project but will give it a try and let you know what i find - too many PRs.

  2. #327
    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?

  3. #328
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    426
    Quote Originally Posted by dundakitty View Post
    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 by wwatson; 10-31-2020 at 01:02 AM.

  4. #329
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    145
    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...traight-18.jpg

    https://www.rbracing-rsr.com/turbo/s...display_03.jpg

    https://www.msar.co.uk/user/products...odb11-msar.jpg

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

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

    https://www.aimtechnologies.com/wp-c...nitoring-1.jpg

    https://www.merlinmotorsport.co.uk/f...0c44e191d9b41a

    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

  5. #330
    Member MorganS's Avatar
    Join Date
    Apr 2015
    Location
    Northern Nevada
    Posts
    64
    Quote Originally Posted by Manu View Post
    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.

  6. #331
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    145
    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)

  7. #332
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    145
    Quote Originally Posted by Manu View Post
    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.
    OK, not possible with current form factor as some required pins are already used for other purpose. I find this :

    https://www.nxp.com/design/developme...T1060-EVK#t768

    Do you think it's possible to use this as an teensy (but with other accessible pins) ?

    thank you

  8. #333
    Junior Member
    Join Date
    Jan 2021
    Posts
    2
    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 !

  9. #334
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,000
    Quote Originally Posted by joffie View Post
    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.

  10. #335
    Junior Member
    Join Date
    Jan 2021
    Posts
    2
    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 Click image for larger version. 

Name:	pfd1.JPG 
Views:	17 
Size:	54.2 KB 
ID:	23324

  11. #336
    Junior Member
    Join Date
    Apr 2021
    Posts
    2

    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.

    Click image for larger version. 

Name:	20210410_211709.jpg 
Views:	17 
Size:	116.8 KB 
ID:	24494

  12. #337
    Junior Member
    Join Date
    Oct 2014
    Posts
    2
    I'm one of the guys building one of these radios. I thought it might be a good idea to post a video of how the display actually works. No audio other than me bumping the mic ;-)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •