Pi IIC API hardware Support?

I need to ask this to save myself a lot of digging to find an answer.

Although the answer is probably “yes”, does the HAL support low and high level SWIs for the IIC bus?

Does the HAL support the Pi IIC hardware or does it bit bang pins?

Knowing these will save me a lot of time. I started writing an IIC API to go along with my GPIO stuff, but would rather do it via the HAL than bare metal, especially if it does support the rather useful BCM IIC controllers.

AFAIK all hardware platforms supported by RISC OS support in their HAL I2C SWI’s¹. One issue to be aware of is that which I2C bus is used varies from platform to platform and that the Original Pi and and the Pi 1 Rev1.2 used different buses. The software we wrote to control our Power Control module is the same (apart from the bus number) For PandaBoard, Pi and IGEPv5

We’ve documented the API of our module here

IIRC there is an old deprecated SWI

OS_IICOp is the SWI to use for new code. IIC_Control is the deprecated SWI that Chris mentions.

As far as OS_IICOp is concerned, there’s only one IIC bus on the Pi, and the HAL makes sure that it gets mapped to the right physical bus for the board in use.

I just wanted to say thanks. Sorry I haven’t replied earlier. I haven’t had a chance to try it out yet.
There is something I would like a bit of clarification on if possible.
I’m looking at the StrongHelp OS SWIs manual. It seems to say that OS_IICOp supports multiple busses. Has this been implemented?

Chris. You have touched on a bit of a sticking point for me. You say different systems use different busses. Is there any reliable way to work out what the system is without resorting to tricks? If there is I can’t find it! OS_ReadSysInfo was useless. Even if I could find out the amount of RAM I’d be halfway there.
What I’m writing is Pi specific, because that’s what I have. However It would be immensely useful to know what model it is for reasons like this, and because I’m talking to the GPIO hardware directly where it can’t be avoided. I’ve seen some weird things happen when I accidentally run a program compiled for the wrong model. Most notable was once only the lowest level child directory windows I had open were all closed. Rebooting seemed the smart thing to do.

Even if I could find out the amount of RAM I’d be halfway there.

OS_Memory. Read the number of pages of RAM, the page size, then multiply one by the other. Sometimes a bit of lateral thinking is required. ;-)

It seems to say that OS_IICOp supports multiple busses. Has this been implemented?

Yes, OS_IICOp supports multiple busses. But for the Pi only one bus is supported (the other bus is used by the GPU, I believe). All you need to do is specify bus number zero and the HAL will make sure the correct physical bus is used based on the board type.

I think that for all the other modern machines the HAL & OS_IICOp support multiple busses (you can get the number of busses via OS_ReadSysInfo 14). But there’s no standard way of mapping logical busses to physical busses, so some care is needed when writing software that’s intended to work with different machines.

Is there any reliable way to work out what the system is without resorting to tricks?

Not at the moment, no.

Is there any reliable way to work out what the system is without resorting to tricks?

No, but the utility !ScrHelp (available from !Store) may give you some ideas (it’s written in BASIC) but it is definitely resorting to tricks and will not be future-proof.

Rick, your solution seems to be good enough to get it working. My code now rather shoddily auto detects 512Mb and 1024MB systems and assigns them to one of two system types. It’ll do for now. I haven’t been able to work on this for a week or two. I’ve lost track. Wasn’t exactly in good health. I knew I wrote some SWI based serial stuff but it took me an hour to find it lol! Apparently I wrote it in Code::Blocks on the PC.
I still need to work out IIC. I’ve spent a lot of time staring at the PRMs but haven’t quite worked it out yet.

I still need to work out IIC. I’ve spent a lot of time staring at the PRMs but haven’t quite worked it out yet.

At what level? Hardware bit transitions or SWI interface?

To be honest, when in writing code to talk to IIC devices, I mostly still use the IIC_Control SWI as it is a lot simpler to use.

Each IIC device has an address (1-126; IIRC 0 and 127 are special). Usually the address is fixed in hardware but there may be a link or two to alter the address slightly to permit two of the same device on the same bus.

Take the address and shift it one place to the left. Bit zero is then used as a flag to specify a read or write operation. That’s R0. R1 is a pointer to a buffer. R2 is how many bytes to send/receive.
Simple!

The apparent drawback of the older IIC SWI is that every IIC transaction is self contained and atonic. That is to say, at protocol level, reading a register is START, device address, write register number, STOP (end of first SWI) START, device address, read register contents, STOP (end of second SWI). The IIC bus can do it in one transaction by omitting the first STOP and just repeating START to switch transfer direction. So the newer SWI can be more optimised. To a degree, many devices can mitigate this by having automatic register increment, for example when reading frames of teletext I would set the start address and then just read the entire buffer in one SWI call. With each byte read, the internal address would +1 so there was no need to change the address manually in order to read the contents. A datasheet for your IIC device will tell you more, but it’d be unusual if this was not the case.

Some example code to drive a 16×2 display:

   20REM Example code to use IIC bus
   30REM to talk to a 16x2 display at address &27
   40PROClcd_cmd(&33):REM first command to send
   50PROCdelay(5)
   60PROClcd_cmd(&32):REM send command 4 lines
   70PROCdelay(5)
   80REM &28 = set function(&20) + 4bitmode(0) + 2lines(8) + 5x7(0)
   90PROClcd_cmd(&28):REM send command
  100PROCdelay(5)
  110REM &0C = set entry mode(&08) + entry left(2) + shift dec(0)
  120PROClcd_cmd(&0C):REM send command
  130PROCdelay(5)
  140REM So far backlight off
  150blFlag%=8
  160REM 1 = clear screen (& backlight on)
  170PROClcd_cmd(&1):REM send command
  180PROCdelay(5)
  190REM Now send it some text
  200PROClcd_string("ABCDEFGHIJKLMNOP",1)
  210PROClcd_string("1234567890123456",2)
  220REM And then quit
  230blFlag%=0
  240PROClcd_cmd(1):REM Clear screen & backlight off
  250END
  260:
  270DEFPROClcd_cmd(byte%)
  280REM 4 is EN% (enable) 8 is backlight
  290?iic%=(byte% AND &F0) OR 4 OR blFlag%
  300REM &4E is (&27<<1)
  310iicbuf%!0=&4E
  320iicbuf%!4=iic%
  330iicbuf%!8=1
  340REM 1 is (iicbus<<24) + 1
  350SYS "OS_IICOp",iicbuf%,1
  360PROCdelay(5)
  370?iic%=(byte% AND &F0) OR blFlag%
  380iicbuf%!0=&4E
  390iicbuf%!4=iic%
  400iicbuf%!8=1
  410SYS "OS_IICOp",iicbuf%,1
  420PROCdelay(5)
  430?iic%=((byte% AND &F)<<4) OR 4 OR blFlag%
  440iicbuf%!0=&4E
  450iicbuf%!4=iic%
  460iicbuf%!8=1
  470SYS "OS_IICOp",iicbuf%,1
  480PROCdelay(5)
  490?iic%=((byte% AND &F)<<4) OR blFlag%
  500iicbuf%!0=&4E
  510iicbuf%!4=iic%
  520iicbuf%!8=1
  530SYS "OS_IICOp",iicbuf%,1
  540PROCdelay(5)
  550ENDPROC
  560:
  570DEFPROClcd_char(byte%)
  580REM 4 is EN% (enable) 8 is backlight 1 is RS%
  590?iic%=(byte% AND &F0) OR 4 OR blFlag% OR 1
  600REM &4E is (&27<<1)
  610iicbuf%!0=&4E
  620iicbuf%!4=iic%
  630iicbuf%!8=1
  640REM 1 is (iicbus<<24) + 1
  650SYS "OS_IICOp",iicbuf%,1
  660PROCdelay(5)
  670?iic%=(byte% AND &F0) OR blFlag% OR 1
  680iicbuf%!0=&4E
  690iicbuf%!4=iic%
  700iicbuf%!8=1
  710SYS "OS_IICOp",iicbuf%,1
  720PROCdelay(5)
  730?iic%=((byte% AND &F)<<4) OR blFlag% OR 4 OR 1
  740iicbuf%!0=&4E
  750iicbuf%!4=iic%
  760iicbuf%!8=1
  770SYS "OS_IICOp",iicbuf%,1
  780PROCdelay(5)
  790?iic%=((byte% AND &F)<<4) OR blFlag% OR 1
  800iicbuf%!0=&4E
  810iicbuf%!4=iic%
  820iicbuf%!8=1
  830SYS "OS_IICOp",iicbuf%,1
  840PROCdelay(5)
  850ENDPROC
  860:
  870DEFPROClcd_string(a$,line%)
  880IF line%=1 THEN PROClcd_cmd(&80 + 0)
  890IF line%=2 THEN PROClcd_cmd(&C0 + 0)
  900IF LEN(a$)>16 THEN a$=LEFT$(a$,16)
  910FOR i%=1 TO LEN(a$)
  920  PROClcd_char(ASC(MID$(a$,i%)))
  930NEXT
  940ENDPROC
  950:
  960DEFPROCdelay(z%)
  970FOR ii%=0 TO 1000*z%:NEXT
  980ENDPROC