Software "Burst Transfer" I2C

[Pete Smith]

Hi all.

A quick question, before I spend an evening re-inventing the wheel. Is there any code available which will allow me to do as-fast-as-possible burst transfers over I2C?

I'm using a RAMTRON FRAM device which will work up to 1MHz on the I2C interface.

I'm using software I2C on a 16LF876A, which will work at 100KHz.

I'd like the data transfer rate to be as quick as possible.

I've got some SPI "fast" code (simply set the clock low, high, read data, repeat), but I'd now like something similar for I2C.

There's no need to worry about start/stop conditions. All the setting up will be done using the standard CCS I2C functions, but to do burst transfers, I'd like something a bit quicker.

Has someone already written this code, so I can be lazy, and re-use it, rather than writing my own?

FWIW, I'm building a display, using one of the Nokia 3310 screens I got from Sweden (thanks to a posting on this board). I'm using a 16kbit FRAM device as a frame buffer, because the screen is write only, so I write to the buffer, and then dump the buffer to the screen.

Thanks,

Pete.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516883

[PCM programmer]

:=Hi all.
:=
:=A quick question, before I spend an evening re-inventing the wheel. Is there any code available which will allow me to do as-fast-as-possible burst transfers over I2C?
:=
:=I'm using a RAMTRON FRAM device which will work up to 1MHz on the I2C interface.
:=
:=I'm using software I2C on a 16LF876A, which will work at 100KHz.
:=
:=I'd like the data transfer rate to be as quick as possible.
--------------------------------------------------------------

Can you use the hardware i2c module ? Then you can set
the i2c clock speed by writing directly to the SSPADD register.

I did a project about 3 years ago, using a 16F876 and a FM24C64.
At that time, there was a bug in the hardware i2c module of
the PIC, such that the i2c clock waveform had an inverted duty
cycle, compared to the examples shown in various i2c chip data
sheets. That worried me, so I reduced the frequency of the
clock, so that the high and low times would meet the minimums
specifed in the FM24C64 data sheet. I think it still worked
at full speed in the lab, but I wasn't willing to risk it
in production. It wouldn't surprise me if Microchip still has
that bug. I emailed them about it years and I don't remember
getting a reply.


This sample code shows how to write to SSPADD. (This code
uses macros for the H/W i2c because it was written before CCS
added support for that).
<a href="http://www.ccsinfo.com/wwwboard/messages/725.html" TARGET="_blank">http://www.ccsinfo.com/wwwboard/messages/725.html</a>

With respect to sending data at the highest possible burst rate:
I remember going through this whole problem, because on my data
logger, I wanted to be able to finish writing data before the
power was shut off, in case that happened. I remember studying
various methods while looking at the results on a logic analyzer. I think my solution was just to use H/W i2c (and
unfortunately, to reduce the clock rate from the optimum,
as detailed above), and to use the following code:

<PRE>
mssp_start();
mssp_send(FRAM_I2C_WRITE_ADDR);
mssp_send(gc_fram_addr_msb); // Send msb first
mssp_send(gc_fram_addr_lsb); // Then send lsb
<BR>
for(i = 0; i < block_len; i++)
mssp_send(gca_mssp_buffer[i]);
mssp_stop();
</PRE>

It looks like I'm just using the equivalent of i2c_write(),
and I'm fetching the bytes from a global array.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516890

[Pete Smith]

:=:=Hi all.
:=:=
:=:=A quick question, before I spend an evening re-inventing the wheel. Is there any code available which will allow me to do as-fast-as-possible burst transfers over I2C?
:=:=
:=:=I'm using a RAMTRON FRAM device which will work up to 1MHz on the I2C interface.
:=:=
:=:=I'm using software I2C on a 16LF876A, which will work at 100KHz.
:=:=
:=:=I'd like the data transfer rate to be as quick as possible.
:=--------------------------------------------------------------
:=
:=Can you use the hardware i2c module ? Then you can set
:=the i2c clock speed by writing directly to the SSPADD register.

I _could_, but I think that would actually be _slower_ than my best transfer rate.

What I could do, is use the hardware SPI and hardware I2C cranked up to the max, but, I was trying to be clever.

All I want to do is dump 504 bytes, as fast as I can, to the screen.

I reconed the fastest way I could do is is to setup the screen, setup the I2C, and then do a software burst transfer, whereby I set the I2C data pin to the level that gets it ready for data, set the SPI pin to the level that gets it ready for data. I'd then change the I2C clock level, shift the data from the I2C to SPI data pins, and then toggle the SPI.

At present, I'm doing it the "slow" way, where I read a byte from I2C, and then write it to the screen.

I'm getting all the nuts & bolts done before I decided to make writing as fast as possible :-)

Once it's all done, I've just got to find an application for this really cool screen :-)

Pete.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516911

[R.J.Hamlett]

:=:=:=Hi all.
:=:=:=
:=:=:=A quick question, before I spend an evening re-inventing the wheel. Is there any code available which will allow me to do as-fast-as-possible burst transfers over I2C?
:=:=:=
:=:=:=I'm using a RAMTRON FRAM device which will work up to 1MHz on the I2C interface.
:=:=:=
:=:=:=I'm using software I2C on a 16LF876A, which will work at 100KHz.
:=:=:=
:=:=:=I'd like the data transfer rate to be as quick as possible.
:=:=--------------------------------------------------------------
:=:=
:=:=Can you use the hardware i2c module ? Then you can set
:=:=the i2c clock speed by writing directly to the SSPADD register.
:=
:=I _could_, but I think that would actually be _slower_ than my best transfer rate.
:=
Er. Why do you think this?......
The clock rate available from the I2C port, is defined as:
Fosc/(4*(SSPADD+1))

Hence if you put '0' into SSPADD, it will clock at FOSC/4, sending one bit for every single instruction clock time. You cannot match this with software (since at the very minimum, the software solution will require a shift, and a loop). With a 4MHz processor clock, data can be clocked out at up to 1Mbps, while at 20MHz, you can get output at up to 5Mbps. The hardware port is _fast_.

:=What I could do, is use the hardware SPI and hardware I2C cranked up to the max, but, I was trying to be clever.
:=
Why bother. The I2C port can allready go to any practical speed. :-)

:=All I want to do is dump 504 bytes, as fast as I can, to the screen.
:=
:=I reconed the fastest way I could do is is to setup the screen, setup the I2C, and then do a software burst transfer, whereby I set the I2C data pin to the level that gets it ready for data, set the SPI pin to the level that gets it ready for data. I'd then change the I2C clock level, shift the data from the I2C to SPI data pins, and then toggle the SPI.
:=
:=At present, I'm doing it the "slow" way, where I read a byte from I2C, and then write it to the screen.
:=
:=I'm getting all the nuts & bolts done before I decided to make writing as fast as possible :-)
:=
:=Once it's all done, I've just got to find an application for this really cool screen :-)
:=
:=Pete.
Remember as a 'caveat', that with I2C, the bus is driven by a 'pull down' driver. The rate at which the signal can recover, is limited by the pull up resistor present, and the capacitance of the connection. If the pull up resistor drops too low, then the actual pull-down FET, will start to take significant time as well. The maximum rate you can send data, will depend massively on how low you can keep the bus capacitance. You will need to look at this very hard if it is more than a few inches long, and you try to push to the highest possible rates...

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516914

[Pete Smith]

:=:=:=:=Hi all.
:=:=:=:=
:=:=:=:=A quick question, before I spend an evening re-inventing the wheel. Is there any code available which will allow me to do as-fast-as-possible burst transfers over I2C?
:=:=:=:=
:=:=:=:=I'm using a RAMTRON FRAM device which will work up to 1MHz on the I2C interface.
:=:=:=:=
:=:=:=:=I'm using software I2C on a 16LF876A, which will work at 100KHz.
:=:=:=:=
:=:=:=:=I'd like the data transfer rate to be as quick as possible.
:=:=:=--------------------------------------------------------------
:=:=:=
:=:=:=Can you use the hardware i2c module ? Then you can set
:=:=:=the i2c clock speed by writing directly to the SSPADD register.
:=:=
:=:=I _could_, but I think that would actually be _slower_ than my best transfer rate.
:=:=
:=Er. Why do you think this?......
:=The clock rate available from the I2C port, is defined as:
:=Fosc/(4*(SSPADD+1))

In general, a hardware UART _will_ be faster than a software one, purely for data transfer in/out of a PIC, but I need to get the data back out again, on another serial line.

I used a confusing term "faster". I meant as an overall way of getting data from the FRAM to the screen, not just out of the FRAM.

I suppose if the FRAM was driven hard enough (the lines are only very short), it could be getting the next byte in the background while I'm sending the previous byte out on a software port.

Is there a "convenient" way of forcing the CCS I2C routines to run flat out, or is PCMProgrammers link (above) the best way of doing it?

Pete.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516915

[R.J.Hamlett]

:=:=:=:=:=Hi all.
:=:=:=:=:=
:=:=:=:=:=A quick question, before I spend an evening re-inventing the wheel. Is there any code available which will allow me to do as-fast-as-possible burst transfers over I2C?
:=:=:=:=:=
:=:=:=:=:=I'm using a RAMTRON FRAM device which will work up to 1MHz on the I2C interface.
:=:=:=:=:=
:=:=:=:=:=I'm using software I2C on a 16LF876A, which will work at 100KHz.
:=:=:=:=:=
:=:=:=:=:=I'd like the data transfer rate to be as quick as possible.
:=:=:=:=--------------------------------------------------------------
:=:=:=:=
:=:=:=:=Can you use the hardware i2c module ? Then you can set
:=:=:=:=the i2c clock speed by writing directly to the SSPADD register.
:=:=:=
:=:=:=I _could_, but I think that would actually be _slower_ than my best transfer rate.
:=:=:=
:=:=Er. Why do you think this?......
:=:=The clock rate available from the I2C port, is defined as:
:=:=Fosc/(4*(SSPADD+1))
:=
:=In general, a hardware UART _will_ be faster than a software one, purely for data transfer in/out of a PIC, but I need to get the data back out again, on another serial line.
:=
:=I used a confusing term "faster". I meant as an overall way of getting data from the FRAM to the screen, not just out of the FRAM.
:=
:=I suppose if the FRAM was driven hard enough (the lines are only very short), it could be getting the next byte in the background while I'm sending the previous byte out on a software port.
:=
:=Is there a "convenient" way of forcing the CCS I2C routines to run flat out, or is PCMProgrammers link (above) the best way of doing it?
:=
:=Pete.
There is nothing 'inconvenient' with just putting a number into the SSPADD register. All that is needed is:
#define SPEED_REQD (1000000l)
#byte SSPADD=0x93

Then when you want to change the value, put:

SSPADD=((getenv("CLOCK")/SPEED_REQD)-1);

This will automatically set SSPADD to the value needed for a 1MHz output (assuming you have #use delay' defined). You can change the constant used (1000000 here), to give any speed you require. :-)
You don't really want 'flat out', if your clock rate is above 4MHz, since the memory chip only supports 1MHz.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516916

[Pete Smith]

:=:=I suppose if the FRAM was driven hard enough (the lines are only very short), it could be getting the next byte in the background while I'm sending the previous byte out on a software port.
:=:=
:=:=Is there a "convenient" way of forcing the CCS I2C routines to run flat out, or is PCMProgrammers link (above) the best way of doing it?
:=:=
:=:=Pete.
:=There is nothing 'inconvenient' with just putting a number into the SSPADD register. All that is needed is:
:=#define SPEED_REQD (1000000l)
:=#byte SSPADD=0x93

This is good. I didn't know if the CCS routines re-wrote the SSPADD register every time they issued a I2C command or not.

I'll have a play with this, and see what i can do.

Many thanks,

Pete.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516919