Re: Consultation: connecting I2C/SPI devices to network

[Florian Feldbauer via Tech-talk <tech-talk@aps.anl.gov>]

Hey Kuldeep,

I did not patch asyn but I needed to patch StreamDevice to use it with my I2C device support.
Each chip uses a different protocol for the communication, and since StreamDevice offers raw converters (%r, %R) I thought it was the easiest to just write a generic AsynPortDriver with an Octet interface and define the chip specific communication within a protocol file.

However, there was one issue:

The writeHandler of StreamDevice's AsynInterface tries to flush any buffered messages before sending by reading 256 bytes until the driver returns asynTimeout or asynError.
As soon as a valid slave address is set up in the I2C kernel module, such a read call will always succeed and thus returns asynSuccess.
This resulted in an endless loop, because StreamDevice kept reading from the I2C bus.

https://github.com/paulscherrerinstitute/StreamDevice/blob/master/src/AsynDriverInterface.cc#L612C1-L639C6

>     if (!pasynGpib)
>             {
>                 // discard any early input, but forward it to potential
>         async records
>                 // thus do not use pasynOctet->flush()
>                 // unfortunately we cannot do this with GPIB because
>         addressing a
>                 // device as talker when it has nothing to say is an
>         error.
>                 // Also timeout=0 does not help here (would need a
>         change in asynGPIB),
>                 // thus use flush() for GPIB.
>                 do {
>                     char buffer [256];
>                     size_t received = 0;
>                     int eomReason = 0;
>                     debug("AsynDriverInterface::writeHandler(%s):
>         reading old input\n",
>                         clientName());
>                     status = pasynOctet->read(pvtOctet, pasynUser,
>                         buffer, sizeof(buffer), &received,
>         &eomReason);
>                     if (status == asynError || received == 0) break;
>                     if (received)
>         debug("AsynDriverInterface::writeHandler(%s): "
>                         "flushing %" Z "u bytes: \"%s\"\n",
>                         clientName(), received, StreamBuffer(buffer,
>         received).expand()());
>                 } while (status == asynSuccess);
>             }
>             else
>             {
>                 debug("AsynDriverInterface::writeHandler(%s): flushing
>         old input\n",
>                     clientName());
>                  pasynOctet->flush(pvtOctet, pasynUser);
>             }

As you can see from this code snippet, StreamDevice behaves differently when used in conjunction with a GPIB interface.
So I simply created a corresponding type for I2C in my module and patched the above if statement in StreamDevice to be

> if (!pasynGpib && !pasynI2C)

The full patch is included in the git repo here:

https://github.com/ffeldbauer/drvAsynI2C/blob/master/streamDevice/stream_drvasyni2c_2.8.20.patch

Except for this there is some initialization for the i2c interface but that's it.
Therefore the behaviour of StreamDevice with other AsynDrivers (e.g. SerialPort/IPPort/GPIB/...) stays untouched.

We have IOCs here that use a patched version of StreamDevice with RS485/RS232 as well as I2C and it works.

Hope that answers your question,

Cheers,
Florian

On 12/17/25 05:26, Kuldeep Joshi wrote:

 Hello Florian,

I have superficially seen your code for the I2C to CA/PVA module.

I have a quick query regarding this, 

you have patched the asyn module due to some issue. Can you please elaborate on this.

If I want to use the asyn module along with Modbus, what will be the issues faced while using this patched module??

Regards,

Kuldeep Joshi

Date: Mon, 15 Dec 2025 11:30:39 +0100
From: Florian Feldbauer <florian@ep1.ruhr-uni-bochum.de>
To: tech-talk@aps.anl.gov
Subject: Re: Consultation: connecting I2C/SPI devices to network
Message-ID:
        <5c9e56c4-7698-4b56-bf12-a57fe414ee59@ep1.ruhr-uni-bochum.de" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">5c9e56c4-7698-4b56-bf12-a57fe414ee59@ep1.ruhr-uni-bochum.de>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hey Gabriel,


I typically use a Raspberry Pi to readout devices via I2C.
For this task I wrote a small i2c device support module, that uses
Stream Device + Asyn (https://urldefense.us/v3/__https://github.com/ffeldbauer/drvAsynI2C__;!!G_uCfscf7eWS!dYsKvtCymp2YJMjpT9hlV9epBG8rvC8U0HFXjj2UxUg0CSKQmX3WB7Ztk9HxUrleo9Jl6mVuLC1Yale1CcceS7vzniRnZn_gqG4$ )


It does not make the I2C communication directly accessible on network,
but it makes all the data points accessible via CA/PVA through an EPICS IOC.


If you really want to have a I2C to Ethernet bridge, I would most likely
use a RP2040 or ESP32 microcontroller and implement a simple UDP or TCP
protocol exchanging either ASCII or raw "strings" containing the data.


HTH,
Florian



On 12/15/25 10:43, Gabriel Fedel via Tech-talk wrote:
> Dear tech-talk,
>
> Any experience or suggestion of bringing hardware communicating I2C
> and/or SPI to be accessible on network?
> Maybe even some EPICS integration experience on them ?
>
> Thanks in advance

--
Ruhr-Universit?t Bochum
AG der Experimentalphysik I
Dr. Florian Feldbauer
NB 2/131 / Fach 125
Universit?tsstr. 150
D-44801 Bochum

Office: NB 2/134
Phone:  (+49)234 / 32-23563
Fax:    (+49)234 / 32-14170
https://urldefense.us/v3/__https://paluma.ruhr-uni-bochum.de__;!!G_uCfscf7eWS!dYsKvtCymp2YJMjpT9hlV9epBG8rvC8U0HFXjj2UxUg0CSKQmX3WB7Ztk9HxUrleo9Jl6mVuLC1Yale1CcceS7vzniRnpShNwVk$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.aps.anl.gov/pipermail/tech-talk/attachments/20251215/a99f6806/attachment.html>

-- 
Ruhr-Universität Bochum
AG der Experimentalphysik I
Dr. Florian Feldbauer
NB 2/131 / Fach 125
Universitätsstr. 150
D-44801 Bochum

Office: NB 2/134
Phone:  (+49)234 / 32-23563
Fax:    (+49)234 / 32-14170
https://paluma.ruhr-uni-bochum.de