Service_IIC documentation

An update went in yesterday that mentions sending Service_IIC around to get an IIC device’s name. Is this a new Service addition as I can’t find any documentation for it.

I may as well add support for it to my pi-top driver, whilst I’m adding the speaker driver.

The log says “New command *IICDevices probes each bus and reports what it finds.”

How does one probe devices on a bus with no defined probe capability?

And whose devices do not identify themselves with a name in any way?

I suspect it will just be able to say at which addresses it gets an ACK rather than an error?

…which may be an unwise thing to do without knowing if a read (you’re probably going to try reading) has side effects.

Perhaps the best way to handle this is to issue a ServiceCall and let device drivers that have already loaded and probed for their specific devices (CJELED and OLED in my case) return an information structure announcing the device, rather than explicitly searching for devices?

The log says “New command *IICDevices probes each bus and reports what it finds.”
How does one probe devices on a bus with no defined probe capability?

I might have the wrong end of the stick here, I’m not technical, but isn’t this roughly the same as the i2c-detect command in Linux which has been around for ages? Presumably that works?

I might have the wrong end of the stick here, I’m not technical, but isn’t this roughly the same as the i2c-detect command in Linux which has been around for ages? Presumably that works?

The manpage for that command does have the following note:

WARNING — This program can confuse your I2C bus, cause data loss and worse!

That’s pretty much what Rick said. It appears to use combinations of quick write and receive byte commands based on known device addressed, cross its fingers and hope for the best.

The same manpage also contains

This is known to corrupt the Atmel AT24RF08 EEPROM found on many IBM Thinkpad laptops.

and

This is known to lock SMBus on various write-only chips (most notably clock chips at address 0×69).

amongst the documentation of its options.

Perhaps a suitable compromise would be to issue the Service_IIC_LookupDescription call before it probes each address?

If it gets a result from the service call it knows that there’s something there and it doesn’t need to probe. If it doesn’t get a result, it can try probing, and if it finds a device it can output an “unknown device” message.

Of course this assumes that drivers will determine at startup whether their device is present (perhaps by probing, perhaps by other means) and then use that result to decide whether to respond to the service call, rather than the service call being a speculative thing.

If it doesn’t get a result, it can try probing,

Repeat previous notes regarding corrupting EEPROM and messing up write only devices.

If the user wants to write a quick program to whizz through the IIC addresses, it’s simple (four lines of BASIC) but most importantly it is on their head.

For the system to do this itself, it will need to be a lot more complicated to make judgements on what to do for each address (as certain types of devices tend to live at certain addresses), not to mention the risks that might be associated with a device in use undergoing an unexpected read operation (many devices auto increment address after a read)…
…in short, I’m saying that having the kernel probe is not a good idea. Let it ask around for information on known devices, leave it at that.

…and let me know if there’s a provisional API so I can amend my OLED driver to support it, because… ☺

At a brief look at the code…

IICService = &81100

Request is IICService with:

• R0 = n/a
• R1 = &81100 (Service#)
• R2 = 0 (Lookup Description)
• R3 = IIC device

If our device, respond with:

• R0 = n/a
• R1 = 0 (to claim)
• R2 = Pointer to null terminated string
• R3 = (doesn’t appear necessary, but no harm in preserving)

The IIC device is formatted with the device number (1-127) shifted one place to the left, so my OLED (device &3C) would be seen as device &78 (in keeping with using bit 0 for read/write).
The IIC bus number is pushed into the high byte (bits 31:24).

I have downloaded and merged in the most recent IIC sources, and am performing a full rebuild (in case the “hdr” file has side effects elsewhere). I’ll then see how it works with my OLED module, though I suspect I’ll just mask off the IIC bus information as my module talks to the default bus and consequently has no knowledge of which bus that actually is…

Yup.

That was easy.

*IICDevices
Bus Dev Description
  0 120 SD1306 OLED controller
  0 158 Unidentified IC?
  0 208 Real time clock?
  0 232 Unidentified IC?

You can get an updated version of OLED that responds to this service call from http://heyrick.co.uk/software/oled/

Could we please have sensible IIC addresses? While “120” is technically what is put on the wire (due to using bit zero to flag if it is a read or write operation), nobody refers to IIC devices that way. You’ll find plenty of examples on Google where the device is referred to in the <128 range (because, one could argue, the device actually has a seven bit address…), many of these are – it should be noted – presented in hex.

Thus, it may make more sense like this (& prefix so it is obvious it is hex):

*IICDevices
Bus Dev Description
  0 &3C SD1306 OLED controller
  0 &4F Unidentified IC?
  0 &68 Real time clock?
  0 &74 Unidentified IC?

What do you think?

BTW: &4F = CJE Temperature sensor (MCP9801), &68 = CJE RTC (DS1338), and &74 is the CJE Power controller (some sort of PIC, I’ve not yet updated CJELED to respond to this device). :-)

Does OLED 0.05 now work on the Pico build? Version 0.03 failed with SWI &400C0 not known.

SWI &400C0 not known.

Ah, yes. That.

The reason my OLED module calls Wimp_Initialise is because it outputs text and VDU sequences redirected to a sprite. Unfortunately, the Wimp notices the VDU output and opens a command window. It is possible to programmatically close the command window, but it does lead to an entire screen redraw.

So what I do is create a fake Wimp task (which, for some reason, didn’t use the X-form SWI, must fix that…), do the VDU stuff, then destroy the Wimp task. Horrible, but it’s not my fault the Wimp is too stupid to know stuff redirected to sprite doesn’t concern it (it just hooks itself into WrchV), and that there’s no command to tell it to ignore what’s about to be output. :-/

I have put together a version that does not do such things if Wimp doesn’t exist. Can you please try it on Pico and tell me if it works? http://heyrick.ddns.net/files/oled_0-06.zip If it does work, I can put it on the main site.

Tried it on Pico on the model 3 and I still get SWI &400C0 not known when I *RMLoad OLED.

Works fine on a 26 October 2016 low vector ROM on the model 3 (issues press space or click mouse to continue).

(issues press space or click mouse to continue)

Crap. Sounds like I’ve got my conditionals back to front.

Note to self: no hacking when tired (dumbass!)

Sounds like I’ve got my conditionals back to front.

Yup. That was it. A MOVVC and a MOVVS. Hard to get wrong. Only I did. <sigh>

Okay, here’s a new version that has that fixed. Note, it’s a replacement, so it has the same version number.

http://heyrick.ddns.net/files/oled_0-06.zip

Hard to get wrong

Getting things wrong is easy.

Okay, here’s a new version that has that fixed.

I have tested OLED 0.06 (08-Feb-2017) running a Pico build on the CM3 and on a model A+/Witty Pi 2 sandwich. So long as I delete the three lines in the ‘OLED_Test’ programme that call the Wimp, it runs OK now. *RMLoad OLED causes the cursor to home to the top left then produce the ‘>’ prompt. Now I must test the GPIO module.