Problem with compiler

[Fabri]

Hi to all,
I use PIC18F4525 with CCS V3.249 compiler. It work really fine.
Now, after compiled same code with V4.35 I found problem in I2C bus used for RTC and LCD display.
Really, I don't use "#use i2c" function but I set I2C registers manually based on my use.

Where's possible difference ?
Registers, timing and all are the same. Just changed compiler release.

Thanks for help,

Regards,
Fabrizio

[PCM programmer]

[Ttelmah]

As PCM programmer says, post the actual version number.
If it is 4.035, then 'give up'. This was before V4 started working for anything but basic operations. Good 'working' versions start around 4.07x.

However, one key 'possible difference'. Do you use pointers?.
V4, switches to the proper C syntax for these, so incrementing a pointer to an int16, increments the memory location accessed by 2. V3, used a CCS 'incorrect format', and incremented pointers by 1. So if using pointers to access bytes, you have to cast them to (char *).

Best Wishes

[Fabri]

I'm sorry, release of compiler is V4.135.

I have in the same i2c bus one display and one RTC.
Communication with RTC is ok but I have problem with slave LCD.
Slave LCD use PIC16F690.

I haven't any problem with CCS V3.249.

Regards,
Fabri

[PCM programmer]

You probably need to post the driver code for the LCD. Also post a
test program that calls the functions in the LCD. Make sure that the
posted code will compile without errors. In other words, post the LCD
driver and a test program to call it. Put in the #include for the PIC,
#fuses, and #use delay(), etc.

[Fabri]

I'll do some new test and I'll post driver.

I don't use pointer but I possible problem may be in syntax or type of variables used. I2c routine work fine with RTC. I also checked with oscilloscope I2c signal.....

Thanks for help,

Fabri

[Fabri]

Ok... I solved.
It was in firmware wrote over 5 years ago. I used "hi(data)" way to get hi side of long variable "data". In CCS V4.135 seems this doesn't work. I used "make8" function to have hi and low of variable "data".


Thanks,
Fabri

[Ttelmah]

I'd suspect the routine 'hi', used a pointer to access the high byte.
This is one of the 'standard' transition problems.
A routine like:

[Fabri]

Yes Ttelmah,

When you talk me about pointers I check variables and way of I used them.
I wrote this firmware over 5 years ago so I don't remember, and how, I decided to use tihs way to get hi side of variable.

Thanks again your precious help,

Regards,
Fabri

[Ttelmah]

Nice that the problem was (in the end), obvious, and quickly found.

The performance of the later V4 compilers is pretty good, with better handling of more complex types, and some extras over V3, and particularly support for a lot more chips, so it's worth moving forward.

Best Wishes