I am planning to create a driver for this device. What is the nearest SPI drivers included in CCS C compiler to start the development?

I saw from the included drivers folder, the device 9356SPI.

Thanks.

Ttelmah

Joined: 11 Mar 2010Posts: 12736

Posted: Fri Oct 20, 2017 1:40 am

Any of the standard SPI drivers.

All of these recent EEPROM's, use a common signalling standard. The only things you have to change are the sizes of numbers fed to them. The nearest is actually the 25640 for example, just requiring one extra address byte added, and tweaks to the maximum size etc...
This is a better fit than the 241025 driver, where there is a bank switching bit added into the command.

valkyrie.wing

Joined: 12 Oct 2017Posts: 10

Posted: Fri Oct 20, 2017 8:25 pm

Hi Ttelmah,

I checked the sample source code of 25640 and yes they are similar to AT25M02 though the implementation is I think software SPI.

I will try this one although my final implementation will be using hardware SPI on PIC18F8722.

Thanks.

Ttelmah

Joined: 11 Mar 2010Posts: 12736

Posted: Sat Oct 21, 2017 12:32 am

Yes.
I think these examples were written to be 'generic', so usable on just about any PIC without SPI hardware. Done before #USE SPI, gave the option to use hardware or software SPI existed. This makes it much easier.

valkyrie.wing

Joined: 12 Oct 2017Posts: 10

Posted: Sat Oct 21, 2017 9:25 pm

Hi Ttelmah,

I ended up writing a HW-based implementation driver for AT25M02. Although I am not quite sure if I done it correctly. I just read the MSSP chapter of PIC18F8722 and the AT25M02 datasheet. I will be testing this on my coming Monday.

I have not use any interrupt #int_ssp coz I think the PIC is a master while the EEPROM is a slave would not need any interrupt handling unless I am wrong with my assumption.

Btw, I am also planning to create a routine for page_write and page_read with a boundary of 256Bytes per EEPROM datasheet. I might also create block_write and block_read with a boundary of 1KB which is a multiple of 256Bytes.

All you need to do is to remove all the actual data transfers from the existing code, and for each byte replace this with xpi_xfer. It accepts mode 0 or 3.
It'll then work with different chips without having to change settings.

I remember some other EEPROM's proving more reliable with Mode3, than Mode0. On the basis of this I went with Mode3.

The manual does tell you about spi_xfer. It can be programmed in the #USE to transfer a specific number of bits, but defaults to allowing up to 32. When setup like this, you can then specify how many bits to send with the xfer.

SPI by default always transfers stuff MSB/MSb first. So if you look at the data sheet for the chip it shows 32bits being clocked to it, comprising the command, and then 24bits of address. I decided to just do this as one transfer. It'd actually be fractionally simpler to define the commands as 32bit values, so 0x02000000 for example, but the compiler is 'smart' here and if you specify a constant value like this and then rotate it three bytes, it only takes the low one and transfers it directly into the high byte of the result, so 'nothing lost'.

It may well be wrong, as I said, not at a computer with the compiler at present, so typed it directly from your code, but it should be very close.

valkyrie.wing

Joined: 12 Oct 2017Posts: 10

Posted: Wed Oct 25, 2017 5:16 pm

Hi Ttelmah,

Already tested the code and it works perfectly. Thank you for that clever suggestions.

ece_jm

Joined: 13 Feb 2018Posts: 1

Posted: Tue Feb 13, 2018 6:23 pm

Thanks for this. I am working on the same chips PIC18F8722 and AT25M02 memory chip. What is the final test code that worked?

valkyrie.wing

Joined: 12 Oct 2017Posts: 10

Posted: Sat Mar 03, 2018 2:23 am

The project was continued by my colleague and I do not know her progress while I was transferred to another project.