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

Thread: RA8876LiteTeensy For Teensy T36 and T40

  1. #326
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,366
    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
    373
    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 02:02 AM.

  4. #329
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    135
    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
    135
    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
    135
    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
    8,499
    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:	5 
Size:	54.2 KB 
ID:	23324

Posting Permissions

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