Re: How to design non blocking device drivers?
- From: Rocky <RobertGush@xxxxxxxxx>
- Date: Thu, 18 Sep 2008 21:57:31 -0700 (PDT)
On Sep 19, 12:11 am, Hans-Bernhard Bröker <HBBroe...@xxxxxxxxxxx>
wrote:
Lanarcam wrote:
Hans-Bernhard Bröker wrote:
1) fail: refuse the write job and return an error conditionYou can also send your write requests through a queue
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
to a task whose job it is to do the actual writing.
... which is just an implementation of case 3).
There are many ways of signalling the end of the writing
through events or another queue.
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.
.
- References:
- How to design non blocking device drivers?
- From: ssubbarayan
- Re: How to design non blocking device drivers?
- From: Hans-Bernhard Bröker
- Re: How to design non blocking device drivers?
- From: Lanarcam
- Re: How to design non blocking device drivers?
- From: Hans-Bernhard Bröker
- How to design non blocking device drivers?
- Prev by Date: Re: Code security on modern 32bit embedded processors
- Next by Date: Cypress EZ-USB FX2 firmware downloading
- Previous by thread: Re: How to design non blocking device drivers?
- Next by thread: Re: How to design non blocking device drivers?
- Index(es):
Relevant Pages
|