| View previous topic :: View next topic |
| Author |
Message |
Manu59114
Joined: 22 Jan 2018
Posts: 34
Location: North of France
|
| ssd1306 less ram and CCS 5.096 |
 Posted: Tue Nov 10, 2020 10:01 am |
 |
|
Hello to all
i just updated my compiler version CCS 5.092 to 5.096 and i have a problem on my OLED display. I use the Ttelmah "Less ram driver".
Today, when i compile with the 5.096 version some character are missing on the display.
With 5.092 and old compiler
With 5.096
I don't understand why.... only the Ttelmah driver seems to be affected!
All other serial communication are ok (UART1 UART2)
Thank you for your help
Have a nice day
Best regards
Manu
_________________
CCS + ICD3 + PIC18F46K80 |
|
 |
jeremiah
Joined: 20 Jul 2010
Posts: 1315
|
|
| Posted: Tue Nov 10, 2020 11:20 am |
|
|
Well you don't provide your code for how you write your text out, so it's really hard to say. I doubt the driver itself has big issues. It's more likely that you have a bug like array overrun and changing compiler versions changed how that bug was affected.
Can you post code for where you store all the above strings and where you print them?
Also a link to Ttelmah's driver so we can once over it as well. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Nov 10, 2020 12:42 pm |
|
|
I assume your PIC is the 18F46K80 as shown in your sig line.
Also post
1. The PIC's oscillator frequency.
2. The Vdd voltage for the PIC on your board. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Tue Nov 10, 2020 12:44 pm |
|
|
What chip are you using?.
There is an updated version for the DSPIC's that defaults to 'signed' .
Now I notice there is a fix in 5.096 for arithmetic wrapping. Might be worth
trying the version that is designed for the DSPIC's. It may be that this
fix means you now have to use this version.
I haven't upgraded yet, so can't test. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Wed Nov 11, 2020 5:25 am |
|
|
What's 'interesting' to me is that between screen #1 and #3, is that 'device #(4680) and big V (1.14) are the same, the rest is wrong.
To me that looks like some data pointer for the 'bad' data has not been properly allocated or setup.
Maybe a 'bank boundary' error ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Fri Nov 13, 2020 3:45 am |
|
|
Trying to find a project of mine that uses this driver on a PIC18. Having
hassle doing so!...
The ones using PIC24's, all work OK with the new compiler. So will have
to dig for an old prototype. 
Looking at what you show, how are the strings being built?.
If you look, the V1.14, displays correctly. Is this a RAM string created
by sprintf?. Are the ones that fail standard constants?. "Fred" etc.?.
Wondering if it is the behaviour of 'pass_strings' that has changed. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Fri Nov 13, 2020 1:38 pm |
|
|
OK. I've put together a board with an 18LFs5K22, and a SSD1306 board,
it is constant strings that cause the problem. Will investigate and see if I
can see what is actually happening....
Exactly the same display routine called with a RAM string works, but with
a constant string only displays the first character and a few other bits. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Sat Nov 14, 2020 4:04 am |
|
|
OK.
It's not something that can be fixed in the OLED code. It is a compiler issue,
and quite a major one. So use 5.094 to fix it.
I'm reporting it to CCS.
What is happening is that the address used to access the data from the
incoming constant, gets overwritten when I access a constant inside the
routine. Result the next character is read from the wrong location.
On the test string from my example code:
printf(OLED_putc,"\f12345\n\r67890\n\r");
The first character gets sent correctly, and things don't go wrong (since this
doesn't actually access the ROM). But then the second character does
(the '1''), and after this the compiler forgets where it was in the source
string....
Other things don't go wrong, unless they access a ROM pointer inside the
putc. However I've managed to generate the same problem on another
graphic routine that also uses ROM * access.....  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Sun Nov 15, 2020 8:01 am |
|
|
Though I said I'd not fix the function, and this is not a 'fix', but a bodge,
I've determined that the registers not being correctly restored are the
pointer held in 0xFF6 & 0xFF7. In the older compilers these are restored
whenever a function uses them. On the new compiler, it instead enters
the routine using them on the next instruction and they get lost....
| Code: |
//Bodge to save and restore the pointer reg1sters
#word REG1=0xFF6
//Fastest text mode. No support for any control. Standard font only.
void OLED_text(unsigned int8 * text, unsigned int8 number)
{
unsigned int8 inc_col;
unsigned int16 temp;
int16 regtemp;
regtemp=REG1;// save the pointer register
//size allows double height & double width
//Here double height/width
//for this I have to do two transfers each of double the amount of data
//and reposition between each
if (size & DOUBLE_WIDTH)
{
inc_col=2;
}
else
{
inc_col=1;
}
do {
temp=(*text)-32;
if (temp>108)
temp=0; //block illegal characters
temp=((unsigned int16)temp*2)+((unsigned int16)temp*4); //efficient *6
FONT_line(&font[temp],6); //six characters from the font
//Now because I'll be in the wrong position (may be one line down)
//have to re-locate
O_current_col+=inc_col;
OLED_address((unsigned int16)O_current_col*4+O_current_col*2,O_current_row); //ready for next character
text++; //and select the next character
} while (--number); //and on to the next character
REG1=regtemp; //and restore the pointer
}
|
This should not be used unless you specifically 'must' use 5.096....
Hopefully CCS will have fixed this very soon. |
|
|
Manu59114
Joined: 22 Jan 2018
Posts: 34
Location: North of France
|
|
| Posted: Mon Nov 16, 2020 12:53 pm |
|
|
Thank you very much Ttelmah for your help, your time and you excellent full explanation!
Best regards
_________________
CCS + ICD3 + PIC18F46K80 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Tue Nov 17, 2020 10:20 am |
|
|
CCS have just emailed me to say this will be fixed in the next compiler
release. So a little in the future, but when this comes out the problem
should disappear. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Tue Nov 17, 2020 10:28 am |
|
|
re: but when this comes out the problem
should disappear.
and....
3 more 'minor' bugs will appear...
just the natural order of things.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Wed Nov 18, 2020 8:00 am |
|
|
Can confirm this is fixed in 5.097.
What the new bus are I haven't yet worked out. |
|
|
Manu59114
Joined: 22 Jan 2018
Posts: 34
Location: North of France
|
|
| Posted: Wed Nov 18, 2020 11:35 am |
|
|
Yes!! i can confirm that is solved!!
Thanks to all,
_________________
CCS + ICD3 + PIC18F46K80 |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
