IIC usage problem

I am trying to use the IIC bus in an rPi and getting confused.
The device concerned is an IIC to 1-wire interface chip, Maxim DS2482-100. It has an address of 18 hex. I’m programming in BASIC.
I tried using OS_IICOp and got highly confused about which part of the data structure was for the interface and which part was to be passed through, so I tried the simpler IIC_Control SWI. In both cases I hit the same problem.
If I use address &30 (i.e. &18 shifted left one bit, and read/write bit set to write) I always get “No response from IIC device”.
If I use address &31 (i.e. read) then it returns &1A. The default is to read the status register on the interface device. This indicates that the last thing done was a reset (at power on) and there was an 1-wire device present. With no device present at power-up, i get &18 instead, as expected.

I expected I should use the write version of the address to send commands to the interface, or to send data to be transferred to the 1-wire bus. Have I got this wrong, and if so, why?

I’ve now modified my code to test all 256 addresses (128 read and 128 write) and report responses.
I changed the address jumpers on the interface unit so that AD0 and AD1 are both 1.

DIM data% 20
DIM errblock% 256
FOR I%=0 TO255
SYS “XIIC_Control”,I%,data%,16 TO errblock%;flags%
IF (flags%AND1) <> 1 THEN
A%=I%>>1
readflag%=I%AND1
PRINT "ADDRESS " + STR$~A% + " is valid";
IF readflag% THEN PRINT " for read" ELSE PRINT " for write"
ENDIF
NEXT

This returns address 1B valid for read, as expected, no address is valid for write.

I’ve tried various values in data% and for the number of bytes there, and get no difference.

I’m wondering whether there is a fault in the hardware – it’s an interface board from Sheepwalk Electronics. They only supply software for Linux, and setting that up is more than i want to attempt at the moment.

I’m reading Maxim’s data sheet for the DS2482-100.

If you’ve set AD0 and AD1 both high, the addresses it should respond to are &37 for read and &36 for write, when considered as a byte on the IIC bus – these are of course &1B when shifted right 1.

If you request 16 bytes from the read address, is there anything to generate them – or does this leave the DS2482-100 busy, in which case it should not generate an ACK?

Also: “The DS2482-100 acknowledges valid command codes and expected/valid command parameters. Additional bytes or invalid command parameters are never acknowledged.”

Looking at the Communication Examples from the data sheet, I don’t think there is ever a case when you can send 16 bytes to the DS2482-100. The operation will always fail with no ACK, it seems to me.

Thanks for the reply, Dave. My main confusion was that stuffing values into the parameter block, I automatically assumed word sizes, so put the command in byte 0, parameter in byte 4, and said 8 bytes were present. Fixing that has allowed me to scan the addresses successfully, and get at least partway to reading the data register. I’ll start trying to get valid data into that register tomorrow.

(Incidentally I am editing the code on the ARMX6, copying it over sharefs to the rpi, and running it via Avalanche. All fine, except when I inadvertently double-click the copy on the ARMX6. So far it doesn’t seem to have upset the ARMX6, which does have several working addresses on IIC bus 0. More care needed I think.)

The code so far is:
ON ERROR PROCerror

SYS “OS_ReadSysInfo”,14 TO busses
PRINT busses
REM addresses for interface
readaddr%=(&1B<<1) +1
writeaddr%=(&1B<<1)

REM commands for interface
iic_reset%=&F0
iic_setreadptr%=&E1
iic_writeconfig%=&D2
iic_1_wirereset%=&B4
iic_1_wiresinglebit%=&87
iic_1_wirewritebyte%=&A5
iic_1_wirereadbyte%=&96
iic_1_wiretriplet%=&78

REM interface registers
statusreg%=&F0
datareg%=&E1
configreg%=&C3

REM commands for 1-wire bus
matchrom%=&55
skiprom%=&CC
searchrom%=&F0
readscratch%=&BE
readrom%=&33
convert%=&44

DIM data% 20
DIM errblock% 256
?data%=iic_reset%

FOR I%=0 TO255
SYS “XIIC_Control”,I%,data%,1 TO errblock%;flags%
IF (flags%AND1) <> 1 THEN
A%=I%>>1
readflag%=I%AND1
PRINT "Address " + STR$~A% + " is valid";
IF readflag% THEN PRINT " for read" ELSE PRINT " for write"
ENDIF
NEXT

PROCsend(writeaddr%,iic_setreadptr%,statusreg%,2)
PROCsend(readaddr%,&E5,&E5,0)
I%=(data%!0)
PRINT "data is "+STR$~I%

END

DEF PROCsend(address%,command%,value%,size%)
IF size%>0 THEN ?(data% + 0)=command%
IF size%>1 THEN ?(data% + 1)=value%
SYS “XIIC_Control”,address%,data%,size% TO errblock%;flags%
IF flags%AND1 THEN
PRINT “Error returned=”STR$~(errblock%!0)
ENDIF
ENDPROC

END

DEF PROCwait(secs%)
IF INKEY
ENDPROC

DEF PROCerror
ON ERROR OFF
*REPORTERROR
PRINT REPORT$ + " at line " + STR$ ERL
END
ENDPROC

OK, quite a bit of success, and a brick wall.
By ensuring that all the data values were bytes (not words) and put into the buffer at one byte (not word) offsets, I’ve got communication with the DS2492 interface working. It also appears that I can send commands to the 1-wire bus via the interface.
The brick wall is attempting to read the address of the DS18b20 temperature sensors. One of the 1-wire commands I can send is a searchrom, which appears to be for getting the addresses of multiple slaves. However the data sheets aren’t helpful about what the result of the command is with respect to getting a result back (8 bytes).There’s also a readrom command which appears to read the address of a single device. This produces “not acknowledged”. For a single device there’s also a skiprom command, but trying that just returns “not acknowledged”. This suggests both the above need parameters, but no indication of what they might be.
Assuming I do manage to get the address of a slave, then I would need to use the match rom command, followed by the 8-byte address. It’s not clear how to send this (using IIC_Control). My guess would be for the data buffer passed to contain the command then 8 bytes of address. However I don’t know the address.
Part of the confusion is due to the interface – after sending the commands the interface selects the status register (so that we can poll until the bus is ready). Then we need to select the data register and perform reads – is this just reading the data register in the interface, or does it need repeated readrom commands to get the 8 bytes of returned data? Neither seem to work for me.
(The actual search for addresses is a complex process involving 1-bit reads and writes. I would have hoped that the searchrom command would perform this, since I can’t see the purpose of it otherwise, but maybe I’m mistaken, and I need to implement this in software using the 1-wire triplet command.)

More progress, and another brick wall. I’ve found a datasheet with the search algorithm in C form, and converted it to BASIC. However it starts with a 1-wire reset, and checks for Presence Pulse Detect. This fails to show up, with either of the sensors I’m working on. An Oscilloscope shows that there is activity on the 1-wire bus, but I haven’t yet got a stable enough display to measure the timings. I can say that disconnecting the sensor doesn’t seem to change the pulse pattern or widths.

Have you set Strong Pull Up?

No. The data sheet doesn’t suggest that is needed, especially as I’m using the 3-wire connection. There’s a warning against using SPU with the 1-wire-reset, as it can damage the DS2482 chip.

According to the data sheets, a reset pulse should last a minimum of 480 microsecs (uS). When I test this, the DS2482 issues a burst of activity lasting about 500uS, consisting of a low for 60 uS, high about 6uS, low 60uS, high 6uS, low 6uS, high 60uS, low 60uS, high 6uS, low 6uS, high 60uS, low 6uS, high 60uS, low 60uS, then a long period high until the next reset is sent.
Given this, I’m not surprised the temp probes don’t reply.
Ihe instructions I am giving to the DS2482 are in a BASIC loop, consisting of a 1-wire-reset command, then reads of the status register until 1-wire-busy has cleared.
The config register contains 0, i.e. no active pullup, no strong pullup, and speed 100KHz.
If I change the code to send a device reset instead, I get a different pattern of pulses, lasting around 500uS. I get 4 6uS high pulses at 70uS intervals, then a high with 4 6uS low pulses, ending at around 500uS with a steady high.
I tried setting active pullup, since the interface seems to have hardware to support this. It made no difference to the patterns in either of the above cases.

and speed 100KHz.

Given that the 3.3V IIC standard came after the 400kHz spec, and that predated the Archimedes (!)…

…would there not be an argument for finally supporting it in RISC OS?

I hacked my build of RISC OS to do this, so I can confirm it works with:

• Pi model B (2nd) default settings
• Pi2 ARMv7 default settings
• CJE RTC (DS1338)
• CJE Temperature sensor
• CJE Power control PIC thingy
• OLED controller (SSD1306)

The CJE stuff and the OLED used on both Pi models. Default settings means I’ve not messed with processor or memory speeds. Everything accessed either by RISC OS directly or via the OS’ IIC calls. As such, I find no sensible reason to keep running the IIC bus at a speed from the early eighties…

Given that the 3.3V IIC standard came after the 400kHz spec, and that predated the Archimedes (!)… …would there not be an argument for finally supporting it in RISC OS?

I would certainly support an API to permit setting bus speeds (100kHz, 400kHz, 1MHz) – but, unless and until you can prove that there is zero chance that anyone will ever use an IIC device that will not operate beyond 100kHz, I still believe that the bus speed should default to 100kHz.

is zero chance that anyone will ever use an IIC device that will not operate beyond 100kHz,

There isn’t zero chance, nor will there ever be. It’s extremely unlikely but not impossible.

However it doesn’t matter. This will only apply to those SoCs with hardware IIC controllers (not the IOMD bit bashed pins), so as long as the hardware isn’t junk, the slave device is actually able to stall the data rate using a technique called clock stretching. https://www.i2c-bus.org/clock-stretching/

Aside: Technically, none of the Acorn designed machines ever legitimately had IIC inside them, as the specification required clock stretching (for slower devices) and arbitration (for multiple masters). The implementation in RISC OS supports neither as it has always assumed it’s a single master system for talking to an RTC. It still doesn’t though I can imagine these days the HAL just passes the request on to hardware that does support these things.
For the older bit banged bus, it behaved like IIC, but it was incomplete so shouldn’t have called itself that… ;)

</pedantic>

I got a bit confused earlier. The speed change I referred to was that between standard and overdrive on the 1-wire bus. I mentioned 100KHz, bus now realise that applied to the IIC bus. As I’m having to work with both buses here, there is a lot of scope for confusion.

It doesn’t alter the fact that the IIC-to-1_wire interface isn’t creating a legal reset pulse.

The actual pulse burst is here:
http://www.adamshome.org.uk/rpi/reset-trace.html

Cracked that now. The problem was that I was sending the reset command as a data byte to the 1-wire bus. It is in fact a command to the interface which causes it to produce a reset event. It’s such fun working with two (new to me) busses at once.