I2C Driver for Raspberry Pi programmer needed

Does the driver also allow for the second I2C port to be used ?

No; RISC OS only supports one IIC bus.

No; RISC OS only supports one IIC bus.

Not any more. Sometime over a year ago I updated OS_IICOp to allow the bus number to be specified in the top byte of R1.

Sure, but anyone who wants to attempt re-use of my code should be aware that it uses programmed I/O, so any attempt to access one IIC bus under interrupt while another bus is in use, is probably going to cause a failure.

Finally got round to building an add-on board for the Pi with some GPIO I2C expanders fitted.
They are detected by the GPIO module and all seems fine…after I fixed a stacking error with the GPIO module !

Just as we get this working, Rev 2 board appears. The I2C’s have been swapped over, so I2C1 will now be on the expansion header.

I guess I’d better hurry up and make it so that the GPIO HAL device can report the board revision. Updating the IIC code to cope with the changed bus is probably also something I can do.

IIC: I’m on the case.

It would seem sensible that the HAL be able to report board revision. I’ve been able to read it, so it wouldn’t be a show-stopper if it isn’t available from the HAL, though.

Clearly the HAL must read board revision very early on; the IIC code needs its result.

Hi Dave

The HAL will be aware of the switch. Ideally the HAL code would swap things around seamlessly for the user?

Reason for swap is that the camera will flood its IIC, so the one put to GPIO is in another block.. it should actually get a look in when the camera is busy

Ideally the HAL code would swap things around seamlessly for the user?

Exactly what I am working on.

The HAL will be aware of the switch.

Yes. I was looking through the HAL documentation yesterday to see if the interface to read the board revision is there, but I couldn’t find it.

I’d be happy to provide the code for it – I’ve got it prototyped in BASIC, and anyway if the HAL doesn’t provide it for me then I have to provide it for myself. It’s not a big deal, obviously; I’d just like to follow a defined interface.

I don’t think the HAL needs to provide another call specifically for the board revision; I’m sure it could be returned as extra information in one of the existing HAL calls.

The code to swap IIC0 and IIC1 according to board revision went into CVS last night, so should be in this morning’s ROM build and source tarball. I tested it yesterday evening on a Rev 1 and a Rev 2 board, and all seems well.

Hello,
does this driver support repeated start operations? Like when you need to read a value from a register on a
I2C sensor:

Best regards,
Dan.

Yes.

Using OS_IICOp you ought to be able to do:
[start][devID/write][data][start][devID/read][nnnn][stop]

However, the easier to use IIC_Control does not, so you need to do two atomic operations:
[start][devID/write][data][stop]
[start][devID/read][nnnn][stop]
The latter case should work on most devices, as it is common to write a register that you want to read, and early (‘80s era) software often didn’t have or require the complexity to need to support repeated-start.

The IIC specification (Oct 2012, p9) says (my highlight):

START and STOP conditions are always generated by the master. The bus is considered to be busy after the START condition. The bus is considered to be free again a certain time after the STOP condition. This bus free situation is specified in Section 6.
The bus stays busy if a repeated START (Sr) is generated instead of a STOP condition. In this respect, the START (S) and repeated START (Sr) conditions are functionally identical.
For the remainder of this document, therefore, the S symbol is used as a generic term to represent both the START and repeated START conditions, unless Sr is particularly relevant.

The purpose of repeated-start is to prevent the bus being claimed by other communications in a multi-master setup. If, however, the setup is for a single master (which I think is the case in most of the dev boards; or can the GPU act as an IIC Master?) then it will suffice to use two calls to IIC_Control, one to write data, the other to read it.

References:

• IIC specification, Oct 2012
• What the repeated-start is for
• Documentation on OS_IICOp
• By contrast: IIC_Control takes R0=devID and R/W flag [(devID << 1) + 1 if read]; R1=Pointer to data/block; R2=Number of bytes to transfer

I’ve added IIC_Control to the documentation; and since the wiki uses an unholy mish-mash of Textile and Wiki syntax, I used my “person profile page” as a playpen – some of you might be amused by it. (^_^)

Thx for the quick reply.
I have a MLX90614 IR sensor that specifically expects a (repeated) START or else, if a STOP is sent after the first write, it will reset its internal state machine and return a value of 0xFFFF.

I am running Risc Os on a Raspberry Pi.

Ah… The MLX90614 is not IIC, it is SMBus.

In general the two are compatible, but note that SMBus specifies a minimum clock speed (>10kHz and no more than 100kHz) and has a 35mS timeout baked into the protocol. IIC is much looser in this respect (I “talked” to a teletext chip while single-stepping code in TurboC++’s debugger and it worked !).
Additionally, SMBus doesn’t cater for the multi-master behaviour of IIC.
Note that SMBus’ pullup/sink capabilities are tiny (100uA-350uA) compared to IIC’s 3mA. Then there’s a lot of difference between what is considered a suitable logic level.

That the two are “compatible” is good, but if an SMBus device falls over on an IIC bus (or vice versa), we probably shouldn’t be too surprised. ;-)

http://www.maximintegrated.com/app-notes/index.mvp/id/476