On Thu, 18 Sep 2008 06:54:59 -0700, ssubbarayan wrote:
> Hi all,
> I would like to understand how to design drivers in such a way
> that its non blocking?
>
> To be more specific,If suppose I have an EEPROM device and two tasks are
> trying to write some data to the EEPROM device,generally what happens
> is,we will have a semaphore inside driver so that till one task
> completes using the device,the other task will be pending to complete
> the writing.What would be the way to design the driver in such a way
> that the second task mentioned above does not go into blocking,but still
> completes writing to the EEPROM.
>
> Sorry if this query looks naive,I am trying to think on alternatives for
> one our product.Application is a thirdparty application which needs this
> requirement.
>
> Looking farward for your thoughts and advanced thanks for the same,
>
> Regards,
> s.subbarayan
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
Reply by Jeffrey Creem●September 20, 20082008-09-20
Hans-Bernhard Br�ker wrote:
> Lanarcam wrote:
>> Hans-Bernhard Br�ker wrote:
>
>>> 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
>
>> You can also send your write requests through a queue
>> 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.
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.
Reply by aravind●September 19, 20082008-09-19
On Sep 18, 6:54=A0pm, ssubbarayan <ssu...@gmail.com> wrote:
> Hi all,
> =A0 =A0 =A0I would like to understand how to design drivers in such a way
> that its non blocking?
>
> To be more specific,If suppose I have an EEPROM device and two tasks
> are trying to write some data to the EEPROM device,generally what
> happens is,we will have a semaphore inside driver so that till one
> task completes using the device,the other task will be pending to
> complete the writing.What would be the way to design the driver in
> such a way that the second task mentioned above does not go into
> blocking,but still completes writing to the EEPROM.
>
> Sorry if this query looks naive,I am trying to think on alternatives
> for one our product.Application is a thirdparty application which
> needs this requirement.
>
> Looking farward for your thoughts and advanced thanks for the same,
>
> Regards,
> s.subbarayan
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
Reply by Rocky●September 19, 20082008-09-19
On Sep 19, 12:11=A0am, Hans-Bernhard Br=F6ker <HBBroe...@t-online.de>
wrote:
> Lanarcam wrote:
> > Hans-Bernhard Br=F6ker wrote:
> >> 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
> > You can also send your write requests through a queue
> > 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.
Reply by ●September 18, 20082008-09-18
Lanarcam wrote:
> Hans-Bernhard Br�ker wrote:
>> 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
> You can also send your write requests through a queue
> 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.
Reply by ●September 18, 20082008-09-18
On Sep 18, 2:54=EF=BF=BDpm, ssubbarayan <ssu...@gmail.com> wrote:
> Hi all,
> =EF=BF=BD =EF=BF=BD =EF=BF=BDI would like to understand how to design dri=
vers in such a way
> that its non blocking?
>
> To be more specific,If suppose I have an EEPROM device and two tasks
> are trying to write some data to the EEPROM device,generally what
> happens is,we will have a semaphore inside driver so that till one
> task completes using the device,the other task will be pending to
> complete the writing.What would be the way to design the driver in
> such a way that the second task mentioned above does not go into
> blocking,but still completes writing to the EEPROM.
>
> Sorry if this query looks naive,I am trying to think on alternatives
> for one our product.Application is a thirdparty application which
> needs this requirement.
>
> Looking farward for your thoughts and advanced thanks for the same,
>
> Regards,
> s.subbarayan
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.
Reply by Lanarcam●September 18, 20082008-09-18
Hans-Bernhard Br�ker wrote:
> ssubbarayan wrote:
>> complete the writing.What would be the way to design the driver in
>> such a way that the second task mentioned above does not go into
>> blocking,but still completes writing to the EEPROM.
>
> 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.
Reply by ●September 18, 20082008-09-18
ssubbarayan wrote:
> complete the writing.What would be the way to design the driver in
> such a way that the second task mentioned above does not go into
> blocking,but still completes writing to the EEPROM.
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.
Reply by Jim Stewart●September 18, 20082008-09-18
ssubbarayan wrote:
> Hi all,
> I would like to understand how to design drivers in such a way
> that its non blocking?
>
> To be more specific,If suppose I have an EEPROM device and two tasks
> are trying to write some data to the EEPROM device,generally what
> happens is,we will have a semaphore inside driver so that till one
> task completes using the device,the other task will be pending to
> complete the writing.What would be the way to design the driver in
> such a way that the second task mentioned above does not go into
> blocking,but still completes writing to the EEPROM.
>
> Sorry if this query looks naive,I am trying to think on alternatives
> for one our product.Application is a thirdparty application which
> needs this requirement.
>
> Looking farward for your thoughts and advanced thanks for the same,
State machine.
Reply by Vladimir Vassilevsky●September 18, 20082008-09-18
ssubbarayan wrote:
> Hi all,
> I would like to understand how to design drivers in such a way
> that its non blocking?
>
> To be more specific,If suppose I have an EEPROM device and two tasks
> are trying to write some data to the EEPROM device,generally what
> happens is,we will have a semaphore inside driver so that till one
> task completes using the device,the other task will be pending to
> complete the writing.What would be the way to design the driver in
> such a way that the second task mentioned above does not go into
> blocking,but still completes writing to the EEPROM.
>
> Sorry if this query looks naive,I am trying to think on alternatives
> for one our product.Application is a thirdparty application which
> needs this requirement.
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
http://www.abvolt.com