Skip to content
max mc costa edited this page Oct 19, 2015 · 15 revisions

Welcome to the RA8875 wiki!

Here's a list of Pros and Cons that will help you to decide if this if what you are looking for...

PROS

  • All drawing functions accellerated
  • Internal font handling
  • Many communication protocols
  • Internal matrix keyscan support
  • Internal resistive touch support
  • External optional Font Rom support
  • External SPI Flash for fast image reading support
  • 256 CGRAM locations for custom simbols
  • It uses his own RAM, not needed shadowing display in MCU
  • Patterns support
  • DMA support
  • BTE fast graphic operation support
  • Layers support (limited to 256 colors for screens > 480x272).
  • Hardware scroll
  • 800x480 support even with 8 bit MCU
  • Configurable INT features
  • 2 x internal PWM generators
  • 2 x GPIO (extendable to 4)
  • Internal hardware accellerated 16bit color conversion to 8bit.
  • It's the only way to use a tiny MCU with big screens! And you get touch support too!

CONS

  • Documentation it's nearly a nightmare, the code examples are almost useless.
  • The BTE engine it's a mess, fast but needs months to be understood.
  • Communication can be slow! remember that it's hardware accellerated so this doesn't mean slow display.
  • No Arc drawing macro! RAiO forget this, too bad...
  • Weird FLASH SPI chip access, you need to program the optional flash chip before solder it!
  • At 800x480, 65K color --> limited Layer support (you can still using it at 8 bit).
  • No continuous command-data streaming, you need to trigger CS after every command.
  • No image-buffer support (at list I cannot find one), it uses chip internal image-buffer and write at pixel level big screen it's extremely slow so not usable for frame buffering or video, loading images from SD card, etc., maybe can be solved by using 16 bit mode instead SPI.
  • Works in SPImode3 so it's prone to create problems with other SPI devices non SPImode3 on the same line.
  • Has internal pullup in MISO output! You are forced to add some external stuff for share SPI with other devices.
  • The SPI lines are generally weak, very noisy sensitives, pay big attention to wires lenght, etc.
  • The RA8875 has tons of hardware bugs, I spent a lot of time going around.

About RA8875 chip

This is amazing device, if you read the capabilities you will shocked but all come at a price...
It cannot act as framebuffer device so forget video and fast loading images even using it's 16 bit bus, it have almost every drawing functions internally hardware accellerated so it's perfectly suitable for drawing interfaces and text mixed to graphics fast and without using cpu resources.
Since all drawing commands are mostly macros, it has a MASSIVE amount of registers, prolly one of the most complicated macro drived chip I ever see, hudge and oscure datasheet, for sure not a weekend project.
Do you think that driving with 8 or 16 bit interface will be much faster than Serial? I really don't think so! This chip needs time to perform a command, you send macro but you have to wait he completed operation. In brief, the scenario it's something like this:
You tell it to draw a rect by send rect macros command and colors, the chip starts it's job but you cannot send another command until has finished so you have to check it's register or the WAIT pin before send another command, and this almost for every command.
Drawing bitmap images it's a slow job, there's not a way to send big chunks of data (only lines), at list I haven't find a working way! I think the only fast way to get a picture fast on screen is use internal DMA and a optional SPI Flash memory pre-programmed and controlled directly by the chip but you need to program Flash chip in advance separately and then solder it, not very practical.
Since nobody will sacrifice 8/16 datalines plus some other wire to drive this chip (and get almost 0 speed increase) the best way it's use the SPI bus, 4 wires plus another for INT.
I started this library as weekend project but early discovered that was a mistake, I don't know how many version I published before have something usable, my goal it's have a stable library, easy to use, scalable in complexity (so you can use basic commands first and then discover more during time) with logical commands that can mimic the most popular ones, working with many MCU's, fast and full featured, I hope I almost got it!