I’ll try to explain what I have so far and what I think is flawed about it.
I have multiple devices connected to an I2C bus which I will be reading and writing to using a G30 and NETMF 4.3.
I have at this point elected to give control of the I2C bus to one thread.
A thread responsible for controlling an I2C device can create an I2CNode which includes all of the information necessary to make the transaction as well as handle for a callback function. It will then place this Node into a Queue.
When the I2C Thread runs it grabs a Node from the queue, makes the transaction happen, Executes the Callback to deliver whether the transaction was successful or not and any byte array that needs to be returned from the transaction.
My problem with this is that I believe this means that the I2C thread will actually be responsible for running the code contained within the callbacks. This becomes a throughput issue as the Callbacks become lengthy.
I do like the idea of the I2C Thread makes sure that the byte arrays returned get a valid reference that the other thread can hold on to. I like this because I don’t have to worry about the data being lost when I Dequeue the Node after the transaction. But I want the I2C Thread to end its responsibility there and get back to the queue for the next transaction.
Should I have another thread to handle lengthy logic that currently resides in these callbacks?
How would I then get the signal that this thread is finished?
Or is there a nice clean way that the thread which is handling the device can know that the data is ready and can safely access data returned by the I2C Thread?