This section is all about immediateC.  John Wulff is the man who created the language from the bottom up in the '80s as a reaction on the inefficient way PLCs were (and are still) handling tasks.

PLCs are simply running a series of commands to check if something has to be adadpted or not.  Even if nothing has changed, they're spending time in doing redundant, useless things.

immediateC is completely different: it replaces the PLC approach with a highly efficient processing.  It only (re)acts if something has changes.  Else, nothing is done.  This is much more efficient and this will also prevent the situation where PLCs don't have enough time to execute lots of tasks and as such can't guarantee stuff is done within the time specified.

immediateC can cope with very strict timings and as such can do a lot more tasks compared to an ordinary PC.

I've picked up immedateC in 2012 when the German magazine ELV made a project with immedateC as the core of it.  This can be seen in the ELV issues 05/2011, 06/2011 and 01/2012.  At that time, I was looking for a suitable mechanism to set up my home automation system.

Since at that time the Raspberry Pi saw the light of day I switched to that SBC to start my home automation system, based on Pi4J.  Since Pi4J had already a framework that supported the I/O expander MCP23017 (including I2C which was heavily borrowed from wiringPi, a famous library dedicated for the Raspberry Pi) I stepped into that adventure.

A few years later (must have been around 2016) my system was already partly up and running, but I wanted to do more things than were possible with Pi4J.  I then contacted John for the very first time to ask for some information.  Then I came to know his complete GitHub repository around immediateC.

However, at that time his immediateC system didn't support I2C but only SPI.  Since all my I/O expanders (and also future devices) run on I2C, this was a no-go for me.

In the meantime, Pi4J did a huge reorganisation in its Pi4J framework which made me far from happy.  They removed all beautiful drivers they had for many, many components (MCP23017 was, as already said, one of them) and also moved over to another Java version and so on.  In short, I was not pleased with the fact they dropped useful component drivers.

At the end of 2022 I was looking again to a kind of PLC control for my system but I bumped against the same wall: no I2C support.

Then I remembered John's language and I again contacted him with a very specific question: to be able to control a lot of MCP23017 devices spread over 8 different I2C busses, each bus being capable of controlling 8 MCP23017.  This would mean a whopping 64 x 16 = 1024 I/O pins that could be controlled!

To be able to have 8 extra I2C buses an extra I2C bus multiplexer PCA9548 was needed but luckily this was directly supported already by the Linux kernel at that time (I had looked for this multiplexer years before but the support for it was not yet available in Linux).  The nice thing of the Linux driver for the I2C multiplexer is that it's transparent for the user.  You select the I2C bus (normally 11 to 18) and Linux will first set the multiplexer in the right position before sending out the effective I2C command to the respective devices.

John was immedately wild about the idea and after some chat sessions between him and me on Sundays he started to work on the iCpiI2C component.  Another component next to iClive, iCserver, iCbox, iCpigpio