I2C Driver for Raspberry Pi programmer needed

Now that the RISC OS port is well under way. Is there anyone out there wanting to take on the I2C driver?
I have a vested interest as we have an I2C Real Time Clock and/or Temperature Sensor module.
I have sent one of the modules to ROOL but they are very busy and I suspect that the I2C module is something that someone else could do. If you could help, drop me an email (chris@cjemicros.co.uk) and I can send you the hardware.
AIUI the necessary I2C documentation is in the issued BCM2835 data sheet. The RTC chip we use is compatible with the RTC chip in the Iyonix (DS1307) and the temperature sensor is compatible with the ThermIC RISC OS software. So AIUI only the I2C module needs written and the sources set to include the existing DS1307 diver.

Hi Chris. I handed the sample you gave me over to Ben this evening. I doubt he’ll be able to work on the driver with other stuff at a higher priority on his ToDo list, but it does mean we’re in a position to potentially test anything that someone else writes.

Just an implementation note: there’s no need to work on the IIC module – these days it’s a veneer onto the kernel SWI OS_IICOp. The reason for this is that the kernel needs to access the I2C bus to access RTC and non-volatile RAM chips. It can’t call out to the IIC module for these, because it needs to access these before the ROM module chain has been initialised. Instead, you should be implementing the HAL I2C API as described here:

https://www.riscosopen.org/wiki/documentation/show/HAL%20IIC%20API

(Historically, before RISC OS 5, there were actually two completely separate implementations of an I2C driver, in the kernel and in the IIC module – this wasn’t great for maintainability or portability. Having the code in one location has also made it possible for it to be called re-entrantly.)

I’m volunteering for this one.

It’s showing signs of life already. Early days yet, though.

The IIC APIs are at a very low level.

The device calling SWI_IICOp has to know all the hardware details of the device, notably the size of the address field within the device, and the page size for writing. All the operations have to be decomposed into idiot-level operations prior to calling SWI_IICOp.

As an example, I’m using an AT24C32D for experiments. This has a 2 byte intra-device address field (it’s 32 kib, i.e. 4 kiB, so it has a 12 bit address field) in addition to the single byte device address, and a page size of 32 bytes. Any multi-byte write operations must be decomposed into page writes that must not cross a page boundary.

It’s not pretty – although I have to admit that there is no way to read these parameters from a device, so the caller cannot escape the need to know the parameters.

However, I can envisage a better high level call, where the breaks into page writes are handled by the cleverer version of OS_IICOp.

At a lower level: it isn’t possible, or reasonable, to know or to set the states of the SCL and SDA lines of the Raspberry pi. The API was devised for bit-banging. HAL_IICSetLines will have to be a no-op, but I don’t know what it or HAL_IICReadLines should return.

At a lower level: it isn’t possible, or reasonable, to know or to set the states of the SCL and SDA lines of the Raspberry pi. The API was devised for bit-banging. HAL_IICSetLines will have to be a no-op, but I don’t know what it or HAL_IICReadLines should return.

I was going to point you towards the docs on the wiki, but it looks like they aren’t quite as clear on the subject as I thought. But basically all that’s required is that you should implement only one of the two APIs (the high-level HAL_IICTransfer one or the low-level HAL_IICReadLines/HAL_IICSetLines one). HAL_IICType should indicate to the OS which API is implemented, and then the OS will stick to only using the calls appropriate to that API.

So in your case you can just leave HAL_IICReadLines and HAL_IICSetLines as no-ops (i.e. NullEntry’s in the HAL entry table), and implement all the others. If in doubt, you can always check the OMAP or Tungsten HALs, as they both use the high-level interface.

Jeffrey beat me to pointing at the fact that there are two different HAL APIs for I2C, depending upon whether the hardware has a dedicated I2C controller or just has to do it by bit-banging.

On the high-level interface, by all means add an even higher-level interface (perhaps an additional SWI in the IIC module would be the place to put it?) but be aware that not all I2C devices use the 256 × 8-bit register model that you’re probably familiar with from EEPROMs where you write a byte containing the register number and then read or write one or more register values. (I’m assuming that’s what you’re thinking of?)

be aware that not all I2C devices use the 256 × 8-bit register model that you’re probably familiar with from EEPROMs where you write a byte containing the register number and then read or write one or more register values. (I’m assuming that’s what you’re thinking of?)

I’ve not heard of such a register model. What I’m familiar with is where the address within the device, for random reads and writes, occupies 1, 2 or 3 bytes that are written immediately after the device address with R/nW set to Write. Then pages can be written one at a time. The AT24C32D (merely an example) has pages of 32 bytes. The AT17C512 has a 3 byte address (it’s only 64 kiB, so you’d think it would only need 2) which enables a few more bytes to be written in order to set the reset polarity of the device, and has IIRC 256-byte pages. It’s normal for sequential reads to auto-increment the address through the devices’ entire memory map before wrapping to 0, whereas the address for sequential writes wraps within the page.

When all is said and done, the paging I’m writing about here is pretty much dedicated to EEPROMs, and won’t affect the RTCC that is most likely to interest RO Raspberry Pi users, which means that any higher level API could be introduced later – if there’s any interest at all.

Having said that, the question of address lengths is also applicable to RAM-like devices.

Where are the I/O registers when a HAL call is running? Are they always in the same place, including at initialisation time?

I need to call a bit of stuff at initialisation time (I’m calling it right after the call to Interrupt_Init) so as to set up the alternate function for the IIC pins, and to set up the IIC clock speed (by default it seems to run at about 160 kHz, which isn’t a recognised speed). I don’t know whether the I/O has been remapped at this point.

Thereafter I need to call the IIC controller for the various HAL_IIC operations, which will normally be after mapping is in place in the OS.

I haven’t found any calls within the BCM2835 code to remap anything, so I don’t know how it’s done. Even the NVMemory code in the OMAP3 branch has changed hugely, so I haven’t yet found how to use that as a reference.

The BCM2835 HAL maps in the IO space pretty early on – it couldn’t do much otherwise. It stores a pointer to the logical address of the base of IO space in its static variable “PeriBase” – search the HAL for this string and I’m sure you’ll find examples of how it’s used.

Got it, and it seems to work, thanks, Ben.

How’s this going Dave ?
Someone on the Raspberry Pi forum was trying to use the I2C bus, so I pointed him to this thread.

It’s going positively, but slower than I would like. I’ve planned a big push for this weekend.

I also have a RTC module for the Pi, looks like this:
http://www.ebay.co.uk/itm/RTC-I2C-DS1307-AT24C32-Real-Time-Clock-Module-Arduino-AVR-ARM-PIC-K-/130717065369?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1e6f582099

Can I help with any testing?

Can I help with any testing?

You will be able to, when I have anything testable. Right now the simple things (things that just return fixed values) work, but transfers don’t.

Some progress: I have single simple transfers working.

Questions about the algorithm for the checksum when only a checksum is returned. Is it a simple add in 32-bit groups, no carry involved? Are the words low-byte-in-low-address? If the buffer is not a multiple of 4, do we pad more significant bytes with zeros? Do we initialise the accumulator to 0? (I think the obvious answer to each is “yes”, but it isn’t actually specified anywhere AFAICS.)

And I presume that a request for a write with the checksum-only flag set can be faulted?

Checksum writes can be faulted, yes.

For checksum reads:

• The checksum value is stored in the 2nd word of the IIC transfer block – i.e. ontop of the data pointer
• The checksum is 32 bits wide
• You should initialise the checksum to zero
• Each received byte should be zero-extended to 32 bits and added to the checksum. I.e. just LDRB from the FIFO and ADD it on.

There’s some danger that it’s working :-)

Much more testing required now.

How does RISC OS know what kind of RTCC is connected? How does it know the address and the register layout? The old PCF8583 and the DS1338 (as used in CJE’s RTCC for the RPi) have different register layouts, for example.

AIUI the DS1307 as used in the Iyonix is software compatible with the DS1338 The only difference being support for 3v3 operation! Replacing a DS1307 in an Iyonix with a DS1338 just works.

How does RISC OS know what kind of RTCC is connected? How does it know the address and the register layout? The old PCF8583 and the DS1338 (as used in CJE’s RTCC for the RPi) have different register layouts, for example.

The kernel has code to probe for a handful of different RTC/CMOS chips. It’s fairly simple code that just looks for something that responds to specific addresses, so could easily get fooled if a new kind of chip is present. If more control is needed for a particular platform, the HAL NVRAM API & HAL RTC device API can be used to control everything.

Using latest ROM our Real Time Clock & Temperature Sensor are now working on our Pi:-)
Our thanks go to Dave Higton for doing the hard work on the driver.

In turn, my thanks go to Ben Avison for reviewing, correcting and merging my code; and to my employer for lending me a rather nice digital storage oscilloscope to check what the IIC lines were doing!

Just tested the I2C on my Pi with this device (just made the buzzer work !!)
Does the driver also allow for the second I2C port to be used ? (Its on the camera connector).