The same thing happens to me.

Greetings.

Thanks Paulino

Hi José:

I really like working with PIC16F887 and version (build_5411) works pretty well with IC2.

Anyway there are few things I hope you can help me out.

1.- I would like to use PORTB6 and PORTB7 as INPUTS. Every time I program any of those pins as inputs the program does not work at all.


2.- I would like to write and read registers larger than 255 to an I2C memory.

Greetings

Hi Angelo

PB6 and PB7 (alias ICSPDAT / ICSPCLK) may be used by your programmer to upload the program in the PIC's memory ?
That's probably why you can't use those pins ?

PB0 to PB5 are at high level by default because of internal pull-up resistors when configured as inputs.
Just modify Settings->Pull up resistors: Port-RB= 0 to disable all the pull-ups on PB.

José

OK

About RB6 and RB7 and don't know why it interferes with I2C. I don't see anything about it in I2C Library...

I'll try to have a look at I2C devices with large address spaces.

BR
José

I think it would be great too, hope it is possible

Hi Angelo

I strangely can't open your rar file with my winrar ; can you please send me in zip format, so that I can have a look at the pb ?

José

OK

There's a bug in last releases of ldmicro concerning I2C names
(between I2C and I2C1 when there's only one I2C bus) but the mains developpers don't seem to care about it.

The only known solution is to download my own build ldmicro32 on github ; I2C bus normally works, named "I2C" as in the attached example, designed and tested for PIC18F4520:

https://github.com/joegil95/LdMicro32

Now I can edit PIC18F4520 programs without any errors at all.

I just need your help in figuring out what I need to do in order to compile correctly and create .hex files.

Thank you very much in advance!



I am trying to write and/or read to an I2C lcd (PCF8574) a RTC (DS3231) and a 24C16B I2C memory.

Thank you very much José.

I will try everything you told me!!!

Dear Angelo

You're right, there's a pb with UART libraries for PIC18 (wrong files).

Please copy Uartlib.c and .h from LIBRARIES_FOR\PIC16 to LIBRARIES_FOR_PIC18 and replace old ones.

Then your project should be built OK (with some warnings but no error) ; I have tested it.

But I haven't tested if the resulting hex file works fine for lack of time ; let us know about it...

BR
José

Hi José:

I copied Uartlib.c and .h from LIBRARIES_FOR\PIC16 to LIBRARIES_FOR_PIC18 and replaced old ones. But still no working.

I even tried with Uartlib.c and .h from Build5411 (LIBRARIES_FOR\PIC16 and LIBRARIES_FOR\PIC18). And still not working. The .hex file is not generated.

I tried the 0x200 configuration but is not working.

Greetings!

Hi José:

Attached I send you a zip file.

I really appreciate your help.

Hi José:

I am reporting to you about PIC18F4520.

Now the UART instruction is working o.k. Also when I include the I2C memory sequence works o.k.

But I tried including ONOS program (this one includes a DS3231 and a LCD-PCF8574). Unfortunately it does not work at all.

The .hex file is generated but does not work (ONOS program works o.k. with a PIC16F887)

Attached I send you some pics about this.
I2C_ONE.ld DOES NOT WORK AT ALL.
I2C_ONE_MEM.ld Works partially, just the I2C memory routine works.

Truly yours
Angelo

O.K. No problem!!!

Please enjoy your holidays!!!

Hi Angelo

Here's what I can say:

- There was still a pb with my UART libraries ; pick the files in attached zip and copy them to your LIBRARIES_FOR\PIC18 and to your HTC\lib folders to replace old existing ones.
Those are temporary files working only at 9600 bauds ; I'll have to modify the code generated by ldmicro32 in next release to make something reliable.
I have tested it in a simulator (for lack of hardware on holidays) and it has worked.

- When developping the PIC18F4520 libraries I had tested I2C libraries with my DS1307 and it worked fine ; DS3231 is almost the same and should work too.

- I have verified the datasheet of your I2C memory and your operations seem to be OK

- I can't test I2C-lcd in simulation because, if I remember well, it doesn't work...

- theres's a warning in your pickit programmer about some unset config bits (config 5+6+7); the values it proposes are default ones and seem to be OK ; that's why we don't care about them.

In my ds1307 ladder I used cfg bits= 0x847406F700000200
You can test it.

To conclude, replace UART libs, and recompile + rebuild the ladder to hex file.
I'll try to make so that there are less warnings in the future, but normally it's not important.

There are now 2 cases:

1) it works fine => ok !!!

2) it still doesn't work (probably)

In this case you'll have to split your ladder into several parts to test separately DS3231 (just read seconds for instance) ; I2C memory ; I2C lcd
Then we may add UART to send debug messages...
Attached zip file also contains my I2C test programs for I2C with PIC18F4520.

I can't debug such a big program and easily know where the pb lies. And it seems that few people have tested this new target PIC18F4520, which is very interesting because pin compatible with PIC16F877.

To be continued (if you want...)
José

Dear Angelo

I'm now back home and I have made some test with my PIC18s...
And nothing works as it ought to !

I have identified the pb:
Another developper as made some changes in the source code of ldmicro (on which ldmicro32 was based) without taking any care of my developments for PIC18s or ARMs. Thus, the code to manage the main timer 0 for PIC18s is broken ans nothing can work.

As it's not the first time, it's one of the main reasons why I'll now develop ldmicro32 in an independant way.

Waiting for this new independant version, I'll tell you within a few days what to do to solve your pb. I need to test again some things that worked before...

////////////////////////////////////////////////////////////
For the time being you mays solve it by changing your ld configuration from timer 0 to timer 1, which doesn't seem to have been affected by the changes (at first glance) !!!
////////////////////////////////////////////////////////////

In computer science, when a pb is understood, it's almost solved !

BR
José

Hi José:

Improvement suggested to the I2C.

I have noticed that when the I2C is interrupted by any broken wire (by mistake or in purpose) to restore the communication it is necessary to reboot the PIC.

So maybe it could be possible to improve the I2C by avoiding this situation.

This situation does not happen with the UART communication. If for any reason the UART communication cable is disconnected, as soon as you connect it back again, the communication is restored with no need to reboot the PIC.

Hi Angelo and Paulino

I'm working on Pic18 and other targets that have been affected by the said changes...

Concerning I2C, its normal that any broken wire may lock the µC because I2C bus requires acknowledgments ; and the µC or the device can miss an ack and then wait for it forever !
There's nothing to do against it.

It doesn't occur with UART or SPI because there's no ack in those (more simple) protocols.

BR
José