How to design non blocking device drivers?

Simple solution:

Create a cache for EEPROM in RAM. So the tasks will be modifying and reading that cache (protected by semaphore, of course). This is going to be blocking but only for the short time. Once in a while the EEPROM driver flushes the dirty lines of cache into EEPROM.

Good solution:

Implement the EEPROM driver as the server and the communication to it as the incoming and outgoing transactions.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

State machine.

That would be the impossible way. You have only one EEPROM, and one EEPROM can only do one write job at a time. So task2 cannot write to the EEPROM while task1 is still doing so. That leaves three possibilities:

1) fail: refuse the write job and return an error condition 2) block: wait for the other task, write, then finish successfully 3) cache: store the write's data and report success, although it hasn't actually been written to EEPROM yet

One can also mix these, e.g. block for a while, but fail if it takes too long. But your requirement to complete writing excludes 3) and 1), and you explicitly excluded 2), which leaves you with no way to do the job.

You can also send your write requests through a queue to a task whose job it is to do the actual writing.

There are many ways of signalling the end of the writing through events or another queue.

The posting task can mark the operation as 'in wait' until it receives the notification. It can wait upon it or test it regularly. All that is well known and is called asynchronous operations.

vers in such a way

You dont do it that way, you have 1 driver that writes to the eeprom. All tasks write to the driver only it writes to the eeprom.

... which is just an implementation of case 3).

He said he wanted the data written _to the EEPROM_ without blocking. None of your proposals assures that.

The other (minor?) issue is that you cannot read from the EEPROM until the write is finished, whether it is in a state machine or queued. The only apparently viable solution is to mirror the EEPROM in RAM and have a background task that slowly updates the EEPROM. Even caching part of the EEPROM will not work because the entire EEPROM would be unavailable.

if you absolutely need the drivers to be non blocking then split the eeprom writes to byte by byte, that is write only one byte at a time. if two tasks need to write 20 and 30 bytes respectively and are initiated simultaneously, you can interleave byte writes between task A and task B. But that ofcourse would be a very inefficient way of writing to an EEPROM since you need to change the address every time (assuming it is serial EEPROM). Even if it is a parallel eeprom there will be overheads due to task switching. You can finish the job quicker if you write all data from a task in one go. Non Blocking drivers are useful where the hardware supports it such as a Hard disk drive with native command queuing(NCQ) or a bus like the PCIe where the device requires certain time to complete a read/write task and supports queuing of commands from different tasks so that the performance can be improved.

Aravind

While I agree that such a response is a reasonable caution for the solutions provided, it is a little much to take a vague user need statement that is not achievable if interpreted exactly and then reject solutions that are working toward the likely intent of the user need.

The correct response here is really to ask for further clarification on what the actual desired end state actually is and use these various solutions to discuss in which ways they address the aspects of the needs statement and in which ways they may fail short. The numbered list at the top of this message actually does a pretty good job of categorizing likely outcomes all possible solutions.

The most logical interpretation of the user need statement implies he is looking for solutions that fall into some form of category 3. While it is dangerous to assume that the most logical interpretation of a conflicting user need statement is what they really want, it is certainly not a bad starting place for discussion.

The EEPROM is, itself, blocking (you can't initiate a write while it's writing), so a driver for it is either going to reflect that, or you're going to have to mirror the EEPROM and schedule writes.

So your choice is blocking, or a fairly complex shadowing scheme.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html