Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^3: i2c bus contention

by GrandFather (Sage)
on Mar 30, 2020 at 06:24 UTC ( #11114791=note: print w/replies, xml ) Need Help??


in reply to Re^2: i2c bus contention
in thread i2c bus contention

In principle yes. In practice it ain't quite as simple as you suggest. The complication isn't the function prototype (or even the implementation) anyway, but even there your suggested API is a little simplistic for practical use. The devil is in the error handling. Not only may either the write or the read fail, but either may partially succeed. So, sticking with pseudo-C/C++ where Buffer is a suitable C++ class equivalent to a Perl string, the function prototype changes a little to:

Status TransactI2C(uint8_t address, Buffer wData, uint8_t &written, Bu +ffer &rBuffer, uint8_t expected);

and the calling code needs to be able to handle statuses like: I2C busy, Write failed, Partial Write, Read Failed, Partial Read, Complete OK.

But the real issue is exactly what the OP is struggling with: simultaneous access. And that isn't solved by just defining a nice API. That has to be solved using some common "process" that serialises access to the I2C port as provided by the OS. That can be non-trivial indeed depending on what the system provides and what your actual use case is. As it happens I've been working to solve exactly those sorts of problems with an embedded system that uses 6 I2C buses, a couple of SPI buses and the odd ADC, USB controller and Ethernet controller thrown in. With all of that stuff running interrupt driven and half of it driving DMA things get pretty interesting!

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Replies are listed 'Best First'.
Re^4: i2c bus contention
by jcb (Vicar) on Mar 31, 2020 at 04:03 UTC

    That API is for submitting a transaction to a shared daemon that will queue the transaction and process it later, so the "I2C busy" status cannot occur. You are probably correct about the possibilities of partial success, but the application I previously worked with did not handle that and did not have problems from lacking that handling. It also drove only very simple peripherals.

    Defining a nice API is the first step towards solving simultaneous access. The API must be an interface to an implementation that can queue and serialize transactions from multiple clients. What I suggested is similar to the I2C module I once wrote for an embedded application that handled some I/O in interrupt handlers or with DMA but did nearly all processing in a cooperative multitasking loop. The "I2C daemon" was another function called as part of that loop and an interrupt handler for advancing an "in-progress" transaction.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11114791]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2020-09-27 17:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    If at first I donít succeed, I Ö










    Results (142 votes). Check out past polls.

    Notices?