SSD1306 driver with big fonts issues

[adcor]

I am having issues with the driver big fonts for PIC24FJ128GB202 / 5.080 compiler. While the normal fonts work, when I use OLED_Bigtext() function it shows a white rectangle size based on the number of characters and font size. Also sprintf(&text,"123.4%c%c",DEGREE,LETTC) does not show anything. All variables are unsigned and I do not know where else to look. If someone has any ideas please share. Thanks

[Ttelmah]

The extended characters are only available from the num12 font, not courier.
OLED_btext, only uses the courier font. You need to be using the OLED_bnum function to access these.

But, you also need to load them. You need:
"#define BIG_PLUS" in your code _before_ loading the num12 include file, to enable these. This is in the example, but you have missed it.

[adcor]

thanks, Ttelmath. Actually my #define BIG_PLUS was included in the driver file ...but after the NUM12.h.
I moved it before NUM12.h but still no go. Strangely enough , the same code/driver works on a 24FJ64GA004, except the sprintf which I have not tested yet. So are the processors somehow different? Both functions OLED_Bnum and OLED_Btext works on GA004 but not on GB202. The standard library functions work on both. I even went back to 5.078 but no luck.

[Ttelmah]

Gets interesting...

I'm running the code on a 24FJ256GA702, and a 24FJ256GB106 without issues. I can't think of any likely differences to your processor. There are a lot of errata on this chip for I2C, but most are only for slave, so shouldn't apply. There is one change that might apply though, they updated the baud rate calculation formula. Try just turning the I2C speed down a little and see if it has an effect. It might by that the compiler is not aware of this change, and is working the baud rate out wrong...
I must admit on recent code, I have been using PSV, and just changed all the font and initialisation arrays to const, and the pointer declarations in the functions from rom BYTE * to just BYTE *. This was giving major issues with 5.078, but has been fixed in 5.081. With this your ROM constants are physically located into the primary data memory at 0x8000 and upwards so you can generate normal pointers to these. A nice ability on the DsPIC's. It does slightly improve performance.

I notice the PIC24FJ64GA004 is one of the ones with a built in voltage regulator, so has a significantly slower 'start up' time on boot, You might just try lengthening the delay after boot a little on the other chip, since it could cause issues if the config is sent before the display is ready. With a processor that starts at 2v, depending on the rise time of your supply, the PIC could be running a long time before the display is 'ready to roll'...

[adcor]

I tried to lower the speed but it does not work, and it does not make sense in this case because OLED_text(text,strlen(text)) works on GB202. It is only OLED_BigText functions which display a white strip sized by the font's count and size selection.

[Ttelmah]

The big text routine does relatively fast font I/O.

However the continuous white sounds like the font is being read as all 1's. I'll try compiling for your chip and see if I can see any issues with the generated code.

UPDATE:

Can confirm. It is returning all of the data from the 'big' fonts as 0xFF on this chip same code compiled on a different PIC returns the data correctly!...

[adcor]

wow, thanks for your effort. Do you think is a compiler bug? or a weird chip?

I wonder if it is the extra crypto engine from this chip which is the culprit in manipulating the data somehow, although it should not interfere as it is stated it is a separate entity.

[Ttelmah]

A compiler bug with this chip.
Memory management for rom pointers is quite complex, since these have three bytes per instruction word, then a byte gap. Getting this right is quite complex.

There is (I Think) a relatively easy work around.

In the SSD include file you have, three routines use rom * in their declarations. Just remove the word 'rom' from all three of these (only the function declarations not data declarations).

Then at the top of your file immediately after including the processor file, add the line:

#DEVICE PSV=16

This enables a mode where the chip will map 32K or the ROM actually into the RAM address space. Allows normal RAM pointers to be used to access the ROM.
It comes at a slight 'cost' the data stored to be used this way has to only use the low 16bits of each word.
I did a quick re-compile with these changes, and it was returning something more like data. No guarantees, since it it difficult to run this in the emulator with all the I2C I/O!...
It's worth sending the sample code to CCS, since it suggests something in the memory map on the chip is causing an issue with ROM pointers. Funnily I had some similar and worse problems a few months ago on another chip...

I've updated the SSD1306 driver to include an option to automatically make the changes needed, and a note about this at the end of the driver entry in the code library.

[adcor]

Yes, it worked. You are the expert !
thank you very much!

[Ttelmah]

Yes, unfortunately, ROM pointers on PCD, seem to have some issues. Using PSV is a much tidier way to go on these chips. Neat thing is with this enabled, you can use a const string or const data in general, just as if it is in RAM!...
Very powerful feature provided you don't want more than 32K of constants!...

[MikeW]

I just wanted to praise Ttelmah for his support and effort.

You are a superstar

Mike

[Ttelmah]

Thanks Mike. I just enjoy getting my head round problems!...