CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

SSD1306 driver with big fonts issues

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
adcor



Joined: 21 Feb 2008
Posts: 31

View user's profile Send private message

SSD1306 driver with big fonts issues
PostPosted: Wed Oct 03, 2018 2:00 pm     Reply with quote

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
Code:

main.h
#include <24FJ128GB202.h>
#DEVICE CONST=READ_ONLY
#use delay(internal=32000000, USB_FULL)

#FUSES NOWDT                    //No Watch Dog Timer
#FUSES NOJTAG                   //JTAG disabled
#FUSES CKSFSM                   //Clock Switching is enabled, fail Safe clock monitor is enabled
#FUSES NOBROWNOUT               //No brownout reset
#use i2c(MASTER, I2C2, FAST=400000, stream=OLED)
#build(stack=256)

#define S_LCDWIDTH   128
#define S_LCDHEIGHT  64
#define WINDOW_WIDTH 64
#define WINDOW_HEIGHT 16
#define SSDADDR 0x78
#include <string.h>
#include "NUM12.h"
#include "courier.h"
#include "OLED_SSD1306.c" // driver file

main.c

void main()
{
   unsigned int8 ctr;
   char text[9]; //temporary text buffer
   delay_ms(250);                //OLED takes time to wake
   OLED_commands(init_sequence,sizeof(init_sequence));
   set=TRUE;
   size=NORMAL;
   OLED_CLS(); //clear the physical screen
   OLED_gotoxy(0,0);
   strcpy(text,"12345");
   OLED_text(text,strlen(text)); // This works
   delay_ms(2000);
    OLED_CLS();
    OLED_gotoxy(0,0);
    OLED_Bigtext(text,bignum,NUM_ONLY); // does not work
    delay_ms(2000);
   OLED_CLS();
    OLED_gotoxy(0,0);
   sprintf(&text,"123.4%c%c",DEGREE,LETTC); //does not work
   delay_ms(2000);
   OLED_CLS();
    OLED_gotoxy(0,0);
   OLED_Btext(text); // does not work
   while (1);
}
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Oct 03, 2018 11:02 pm     Reply with quote

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



Joined: 21 Feb 2008
Posts: 31

View user's profile Send private message

PostPosted: Thu Oct 04, 2018 12:25 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Oct 04, 2018 12:57 am     Reply with quote

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'...


Last edited by Ttelmah on Thu Oct 04, 2018 1:23 am; edited 1 time in total
adcor



Joined: 21 Feb 2008
Posts: 31

View user's profile Send private message

PostPosted: Thu Oct 04, 2018 1:17 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Oct 04, 2018 1:31 am     Reply with quote

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



Joined: 21 Feb 2008
Posts: 31

View user's profile Send private message

PostPosted: Thu Oct 04, 2018 2:30 am     Reply with quote

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.


Last edited by adcor on Thu Oct 04, 2018 2:43 am; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Oct 04, 2018 2:42 am     Reply with quote

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.


Last edited by Ttelmah on Thu Oct 04, 2018 3:06 am; edited 1 time in total
adcor



Joined: 21 Feb 2008
Posts: 31

View user's profile Send private message

PostPosted: Thu Oct 04, 2018 2:51 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Oct 04, 2018 3:13 am     Reply with quote

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



Joined: 15 Sep 2003
Posts: 184
Location: Warrington UK

View user's profile Send private message

PostPosted: Thu Oct 04, 2018 5:55 am     Reply with quote

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

You are a superstar

Mike
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Oct 04, 2018 7:43 am     Reply with quote

Thanks Mike. I just enjoy getting my head round problems!... Very Happy
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group