More features...

[sumotoy]

The goal for the stable beta 0.70 are:

• Stable Code
• No more changes in name functions
• Reduced public functions (no more complicated stuff)
• All RA8875 features working and kicking
• All displays and board variants initializations should work (and confirmed)
• Support for Capacitive Touch Screens
• Support for rendered fonts (in addition to internal and ROM ones)
• Examples separated for any CPU (this simplify the code examples a lot)

From the 0.70 will be safe use this library for projects (at your risk of course), was not easy to create a library for this chip, it has tons of registers and almost anything needs a special method so even create a function list was almost a nightmare, this is why I appreciate feedbacks or suggestions. I have tried to mimic the functions name used in many popular libraries so the end user doesn't have to study the entire code, I have also added a lot of examples and commented a lot. I will add a wiki page that comment any function one by one in the near future. The first stable beta it's under the corner, it's really question of days and thanks to these people that spent some time to help me out:

Christoph for point me at a solution for break the SPI speed barrier of RA8875

The Experimentalist for help me to find out the SPI pullups on MOSI and SCLK and contributed with the scroll stuff.

MorganSandercock for many bug fixes and the setRotation stuff, but also for being nice to share with everyone.

Paul Stoffregen, what I can say? He's the the marvellous gentle giant hided inside the code of almost any popular MCU's, without his SPI Transaction stuff this library cannot be here.

[twobeseen]

Hi there, I am interested in your "little" Raio driver, seems to be quite powerful. I want to display a big clock watch on my 7" TFT (don't have it yet, just planning). Is there a way to accomplish displaying large numbers / large characters? The numbers should be nearly as big as the displays height, hence if I got a 800x480 display one character/number should be 300-480 px high.

I read that you are planning rendered fonts, could that be something for my large numbers?

thanks for your hard work,

Regards, B.

[sumotoy]

yes but still have to finish the font rendering routines, actually I'm fixing and defining the overall library structure, from the 0.7 it will be enough stable to be used for any project

[MorganSandercock]

+1 for a "big numbers" font. I've done a similar job on other displays with my own hand-drawn font - embedded in the library so that it can use direct writing to the screen.

One thing I did find necessary was getting the background right. You can print a char with a transparent background which works OK to put static text onto a coloured background but it doesn't help with dynamic text where you want to replace the background where the new char doesn't overlap the previous char. If the background is generated by a function (eg. a colour gradient) then my code passes in that function as an argument for the custom-char function. That way the custom char can erase the previous char with the correct background, as required. I had a 4-bit char, so I could even anti-alias and fade the background into the edges of the char.

With the capability of the RA8875, it might be better to draw the changing characters onto the second memory page and then mix them on top of the static background with transparency. Now I think about it, that is probably the best solution for dynamic stuff. The background colour of the chars is the transparent colour so it always erases the previous.

[sumotoy]

I'm working at an font engine from a couple of weeks already, unfortunatly the RA8875 it's a bad slow boy when you try to use drawPixel and things used in other libraries like sending many pixels in a time doesn't work with RA so using external font rendering it's a challenge with this chip, so why they added a separate internal font engine and external font chip. Btw I maybe find a way by using the last possible resource that is BTE so in the next days maybe something will be enough stable to be showed.

[sumotoy]

I've added a new command that can send blocks of pixels relatively fast, it use just one addressing and doesn't need the feedback during data trasfer.
drawPixels(uint16_t * p, uint32_t count, int16_t x, int16_t y).
I think this can be a good start for custom fonts, have to avoid absolutely the drawPixel method that need an addressing for each pixel plus feedback, no good.... I'm study another method to use the BTE that should be much faster.

[sumotoy]

Last beta have a test rendering engine (alpha) to test, it's a very early beta but it's a good start to use pixels chunk transfer that I have in mind to speedup the whole thing.

[sumotoy]

Ok, now rendering has been speedup a lot, I write rows instead pixels so much less calls! The beta 0.68b28 has this feature (check the example fontRendering) but still a raw alpha feature, now have to figure out a good scaling technique and all the related stuff (background color, etc, etc,)

[MorganSandercock]

Great! Resizing is not too important to me - I want a large custom font with just numbers and a few symbols so I don't need to fit an entire ASCII font into memory. I can just store big characters at full resolution.

As soon as you go to font-size 3 then it will certainly be faster to send filled-rectangles instead of drawing pixels or rows. The font-size 2 might be faster if you do the scaling in the Arduino and send 4 16-bit pixels per source pixel but it will be much easier for the first version of this feature to use rectangles like the other common font-scaling code.

[MorganSandercock]

One possible compression method for big fonts is run-length encoding. I compressed 32x40 characters at 4 bits per pixel (640 bytes) down to 50-150 bytes by using run-length encoding. Store a colour and then how many pixels to the right of that are the same colour. This is then fast to write to the screen as you draw horizontal lines of that length. It scales up with rectangles, but I never implemented that.

[sumotoy]

Some fun with the font engine

Also a test for very large fonts

[MorganSandercock]

I've looked at your new custom font engine. I think there's a better way of doing this. I haven't tried this on this screen but I've done it on others: Set up the "Active Window" to the height and width of your font. Then just blast out the pixels. This will wrap the memory-write cursor when it gets to the right-hand edge of the window. You don't need to restart the SPI session on each line - just send 1024 pixels (or whatever) and the settings in MWCR0 will control the incrementing of the pixel position and wrapping. I think MWCR0 should be all zeros for the desired function, at least in the default rotation. See page 102 on the datasheet. I'll try this tonight; maybe set up a pull request.

[sumotoy]

Ok, try it! I'm leaved as is because I'm working at another engine that use geometric compression so I'm actually on a win application that convert the font in rect, lines, etc., more easy to say than code unfortunatly but I've done a small test with some hand designed font in this way and it's superfast. Paul Stoffregen it's working in the same direction...