Lpc2000

I'm still trying to interface a Serial RAM chip with a LPC2148 and am
making some progress.  I received some sample 'C' code from the RAM
chip manufacturer, but wanted you experts to clarify some points.

In the 'C' code, it appears that all the manipulation is done to the
SDA and SCL lines directly.  I'm assuming that all that is done
internal to the 2148 when you write START, STOP, and ACK commands
directly to the I2C registers and I don't have to mess with any of
that stuff.  Right? What I am getting at is that this code probably
won't help me any except for the procedural aspect of how to address
the chip, which appears to be correct in my case.

Another ? I have is that in the user manual, it always says 'When your
data has been sent and the acknowledgement has been received, then
....', is the ACK the SI bit?  Or do I have do anything else besides
clear the SI bit to 'get the acknowledgement'?  Not clear on that...

Sutton

Sutton

Hi Sutton


> In the 'C' code, it appears that all the manipulation is done
> to the SDA and SCL lines directly.

The example is very probably a bit-banging example for any chip, 
even without an IIC controller. Of course you can also bit bang on 
any port which can be configured as input and output - therefore the 
code will even run.

If you want to use the IIC controller in the LPC then it will only 
give you some ideas - you can use polling mode [presumably as in the 
bit-banging example] or interrupt driven with teh internal IIC 
controller.

Here's how to send (defines are hopefully logical) and it is assumed 
that the I/O lines are configured for IIC, rather than general 
purpose ports - interrupts configured and enabled.
1.     I2CONSET = (I2EN + STA); - send start condition
2. On interrupt, read I2STAT, which will read as 0x08. Now send 
I2DAT = Address_of_chip;     followed by      
I2CONCLR = (SIC);               // clear the SI bit and continue
3. When the slave sends an ACK to its address, the interrupt routine 
is called and I2STAT is 0x18.
I2DAT = ucI2CTxData;     // send the first byte of data 
I2CONCLR = (SIC + STAC);      // clear the SI bit and STA bit

4. Subsequent interrupts have the status 0x28 and the next byte of 
data can be sent using the previous sequence, until all data has 
been sent, in which case the following code is used:
I2CONCLR = (SIC + STAC);      // clear the SI bit and STA bit
I2CONSET = STO;               // set stop bit  

The transmission has now completed.

There are however a number of details which I haven't described, as 
well as the receive case. For example there can be a number of error 
interrupts such as a slave not responding and when using multi-
master it can get even more complicated.
Also some devices (possibly yours(?)) need a sequence where they are 
first addressed and then a re-start sequence is performed before the 
actual data is sent.

Therefore it is best to read through the operation of the controller 
and device, including the error conditions and get to know the 
protocol in some more detail (if multi-master mode is not required 
then just ignore its details since it is much easier then).

Perhaps this has also cleared up the SI use.

Cheers

Mark Butcher
www.mjbc.ch

> 
> Another ? I have is that in the user manual, it always says 'When 
your
> data has been sent and the acknowledgement has been received, then
> ....', is the ACK the SI bit?  Or do I have do anything else 
besides
> clear the SI bit to 'get the acknowledgement'?  Not clear on 
that...

> 
> Sutton
> 
> Sutton
>

Thanks Mark.  I think I'm on the right track.  I've gotten the 0x18
response from addressing my chip.  But, I had forgotten to set the AA
bit.  It wouldn't work until then and I kept getting 0x08.

Sutton


--- In lpc2000@yahoogroups.com, "Mark Butcher" <M_J_Butcher@...> wrote:

>
> Hi Sutton
> 
> 
> > In the 'C' code, it appears that all the manipulation is done
> > to the SDA and SCL lines directly.
> 
> The example is very probably a bit-banging example for any chip, 
> even without an IIC controller. Of course you can also bit bang on 
> any port which can be configured as input and output - therefore the 
> code will even run.
> 
> If you want to use the IIC controller in the LPC then it will only 
> give you some ideas - you can use polling mode [presumably as in the 
> bit-banging example] or interrupt driven with teh internal IIC 
> controller.
> 
> Here's how to send (defines are hopefully logical) and it is assumed 
> that the I/O lines are configured for IIC, rather than general 
> purpose ports - interrupts configured and enabled.
> 1.     I2CONSET = (I2EN + STA); - send start condition
> 2. On interrupt, read I2STAT, which will read as 0x08. Now send 
> I2DAT = Address_of_chip;     followed by      
> I2CONCLR = (SIC);               // clear the SI bit and continue
> 3. When the slave sends an ACK to its address, the interrupt routine 
> is called and I2STAT is 0x18.
> I2DAT = ucI2CTxData;     // send the first byte of data 
> I2CONCLR = (SIC + STAC);      // clear the SI bit and STA bit
> 
> 4. Subsequent interrupts have the status 0x28 and the next byte of 
> data can be sent using the previous sequence, until all data has 
> been sent, in which case the following code is used:
> I2CONCLR = (SIC + STAC);      // clear the SI bit and STA bit
> I2CONSET = STO;               // set stop bit  
> 
> The transmission has now completed.
> 
> There are however a number of details which I haven't described, as 
> well as the receive case. For example there can be a number of error 
> interrupts such as a slave not responding and when using multi-
> master it can get even more complicated.
> Also some devices (possibly yours(?)) need a sequence where they are 
> first addressed and then a re-start sequence is performed before the 
> actual data is sent.
> 
> Therefore it is best to read through the operation of the controller 
> and device, including the error conditions and get to know the 
> protocol in some more detail (if multi-master mode is not required 
> then just ignore its details since it is much easier then).
> 
> Perhaps this has also cleared up the SI use.
> 
> Cheers
> 
> Mark Butcher
> www.mjbc.ch
> 
> > 
> > Another ? I have is that in the user manual, it always says 'When 
> your
> > data has been sent and the acknowledgement has been received, then
> > ....', is the ACK the SI bit?  Or do I have do anything else 
> besides
> > clear the SI bit to 'get the acknowledgement'?  Not clear on 
> that...
> > 
> > Sutton
> > 
> > Sutton
> >
>

Hi,

the LPC2148 sample software library in the files section has an
example for I2C as well and it does not just toggle the port pins. 
It is written for the ARM Real-View compiler but it should not be too
difficult to use the C-file and the H-file from the example. 

Bob

--- In lpc2000@yahoogroups.com, "Sutton Mehaffey" <sutton@...> wrote:

>
> I'm still trying to interface a Serial RAM chip with a LPC2148 and am
> making some progress.  I received some sample 'C' code from the RAM
> chip manufacturer, but wanted you experts to clarify some points.
> 
> In the 'C' code, it appears that all the manipulation is done to the
> SDA and SCL lines directly.  I'm assuming that all that is done
> internal to the 2148 when you write START, STOP, and ACK commands
> directly to the I2C registers and I don't have to mess with any of
> that stuff.  Right? What I am getting at is that this code probably
> won't help me any except for the procedural aspect of how to address
> the chip, which appears to be correct in my case.
> 
> Another ? I have is that in the user manual, it always says 'When your
> data has been sent and the acknowledgement has been received, then
> ....', is the ACK the SI bit?  Or do I have do anything else besides
> clear the SI bit to 'get the acknowledgement'?  Not clear on that...
> 
> Sutton
> 
> Sutton
>

Hi all,

> the LPC2148 sample software library in the files section has an
> example for I2C as well and it does not just toggle the port pins. 
> It is written for the ARM Real-View compiler but it should not be too
> difficult to use the C-file and the H-file from the example. 

I'm working on the same issue right now, and I got as far as that: I
can write one byte to the EEPROM an read it, except I do it
consecutively. In debug mode it works though, so I guess, I got some
timing problems. Does anybody have experiences with that?

Do you mean the sample software provided by Philips? The apppication
example is a bit tricky, because it deals with a temperature sensor
with a strange protocol and the commands are determined in the handler
it self. 

I found an application note for a LPC9XX and an I/O expander modul:

http://www.semiconductors.philips.com/acrobat_download/applicationnotes/AN10155_1.pdf

It's structured very clearly (application/driver) so I could change it
for the LPC2XXX easily following the steps Mark described.

Jan