Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #30848

Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on

From Don Y <blockedofcourse@foo.invalid>
Newsgroups comp.arch.embedded
Subject Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on
Date 2021-10-25 02:35 -0700
Organization A noiseless patient Spider
Message-ID <sl5tot$dig$1@dont-email.me> (permalink)
References (3 earlier) <sl4dm3$5ut$1@dont-email.me> <sl4fk0$2si$1@dont-email.me> <itn713FpntqU1@mid.individual.net> <sl5pqv$gu1$1@dont-email.me> <itnabsFqas4U1@mid.individual.net>

Show all headers | View raw


On 10/25/2021 2:06 AM, Niklas Holsti wrote:
> On 2021-10-25 11:28, Don Y wrote:
>> On 10/25/2021 1:09 AM, Niklas Holsti wrote:
>>> On 2021-10-24 23:27, Dimiter_Popoff wrote:
>>>> On 10/24/2021 22:54, Don Y wrote:
>>>>> On 10/24/2021 4:14 AM, Dimiter_Popoff wrote:
>>>>>>> Disable interrupts while accessing the fifo. you really have to.
>>>>>>> alternatively you'll often get away not using a fifo at all,
>>>>>>> unless you're blocking for a long while in some part of the code.
>>>>>>
>>>>>> Why would you do that. The fifo write pointer is only modified by
>>>>>> the interrupt handler, the read pointer is only modified by the
>>>>>> interrupted code. Has been done so for times immemorial.
>>>>>
>>>>> The OPs code doesn't differentiate between FIFO full and empty.
>>>>
>>>> So he should fix that first, there is no sane reason why not.
>>>> Few things are simpler to do than that.
>>>
>>>
>>>     [snip]
>>>
>>>
>>>> Whatever handshakes he makes there is no problem knowing whether
>>>> the fifo is full - just check if the position the write pointer
>>>> will have after putting the next byte matches the read pointer
>>>> at the moment.  Like I said before, few things are simpler than
>>>> that, can't imagine someone working as a programmer being
>>>> stuck at *that*.
>>>
>>> That simple check would require keeping a maximum of only N-1 entries in the 
>>> N-position FIFO buffer, and the OP explicitly said they did not want to 
>>> allocate an unused place in the buffer (which I think is unreasonable of the 
>>> OP, but that is only IMO).
>>>
>>> The simple explanation for the N-1 limit is that the difference between two 
>>> wrap-around pointers into an N-place buffer has at most N different values, 
>>> while there are N+1 possible filling states of the buffer, from empty (zero 
>>> items) to full (N items).
>>
>> But, again, that just deals with the "full check".  The easiest way to do
>> this is just to check ".in" *after* advancement and inhibit the store if
>> it coincides with the ".out" value.
>>
>> Checking for a "high water mark" to enable flow control requires more
>> computation (albeit simple) as you have to accommodate the delays in
>> that notification reaching the remote sender (lest he continue
>> sending and overrun your buffer).
>>
>> And, later noting when you've consumed enough of the FIFO's contents
>> to reach a "low water mark" and reenable the remote's transmissions.
>>
>> [And, if you ever have to deal with more "established" protocols
>> that require the sequencing of specific control signals DURING
>> a transfer, the ISR quickly becomes very complex!]
> 
> Of course. Perhaps you (Don) did not see that I was agreeing with your position 
> and objecting to the "it is very simple" stance of Dimiter (considering the 
> OP's expressed constraints).

Yes, but I was afraid the emphasis would shift away from the "more involved"
case (by trivializing the "full" case).

> Personally I would use critical sections to avoid relying on delicate reasoning 
> about interleaved executions. And to allow for easy future complexification of 
> the concurrent activities. The overhead of interrupt disabling and enabling is 
> seldom significant when that can be done directly without kernel calls.

We (developers, in general) tend to forget how often we cobble
together solutions from past implementations.  And, as those past
implementations tend to be lax when it comes to enumerating the
assumptions under which they were created, we end up propagating
a bunch of dubious qualifiers that ultimately affect the code's
performance and "correctness".

Someone (including ourselves) trying to pilfer code from THIS
project might incorrectly expect the ISR to protect against buffer
wrap.  Or, implement flow control.  Or, be designed for a higher
data rate than it actually sees (saw!) -- will the buffer size -- and
task() timing -- be adequate to handle burst transmissions at 115Kbaud?
If not, where is the upper bound?  What if the CPU clock is changed?
Or, the processor load?  ...

"Steal" several bits of code -- possibly from different projects -- and
you've got an assortment of such hidden assumptions, all willing to eat
your lunch!   While you remain convinced that none of those things
can happen!

My first UART driver had to manage about a dozen control signals as
the standard had a different intent and interpretation in the mid 70's,
early 80's (anyone remember TWX?  TELEX?  DB25s?).  Porting it forward
ended up with a bunch of "issues" that no longer applied.  (e.g.,
RTS/CTS weren't originally used as flow control/handshaking signals as
they are commonly used, now).  *Assuming* a letter revision of the standard
was benign wrt the timing of signal transitions was folly.

You only see these things when you lay out all of your assumptions
in the codebase.  And, hope the next guy actually READS what you took
the time to WRITE!

[When I wrote my 9 track tape driver, I had ~200 lines of commentary
just explaining the role of the interface wrt the formatter, transports,
etc.  E.g., when you can read reverse, seek forward, rewind, etc.
with multiple transports hung off that same interface.  Otherwise,
an observant developer would falsely conclude that the driver was
riddled with bugs -- as it *facilitated* a multiplicity of
concurrent operations]

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-23 00:07 +0200
  Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Clifford Heath <no.spam@please.net> - 2021-10-23 13:40 +1100
  Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-22 22:09 -0700
    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-23 22:12 +0200
      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-23 15:59 -0700
  Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-23 18:09 +0200
    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-23 22:49 +0200
      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-24 13:02 +0200
        Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-24 17:39 +0200
          Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-24 18:37 +0200
    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-25 20:15 +0200
      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-25 20:54 +0200
      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Richard Damon <Richard@Damon-Family.org> - 2021-10-25 20:31 -0400
  Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Johann Klammer <klammerj@NOSPAM.a1.net> - 2021-10-24 12:39 +0200
    Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-24 14:14 +0300
      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-24 12:54 -0700
        Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-24 23:27 +0300
          Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-24 14:08 -0700
            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 00:50 +0300
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-24 15:47 -0700
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 02:32 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-24 18:34 -0700
            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-25 09:41 +0200
            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 10:56 +0300
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 01:19 -0700
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 11:52 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 02:50 -0700
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-25 13:49 +0200
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 15:16 +0300
          Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 11:09 +0300
            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 01:28 -0700
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 12:06 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 02:35 -0700
            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 16:04 +0300
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 18:34 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 10:43 -0700
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 20:53 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 11:02 -0700
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-25 19:52 +0200
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 11:10 -0700
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 21:33 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 22:09 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-10-25 22:53 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-25 23:02 +0300
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-26 00:05 +0200
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on pozz <pozzugno@gmail.com> - 2021-10-25 23:46 +0200
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-25 20:58 +0200
            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Clifford Heath <no.spam@please.net> - 2021-10-26 08:43 +1100
        Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on antispam@math.uni.wroc.pl - 2021-10-25 21:32 +0000
          Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-25 15:24 -0700
            Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on antispam@math.uni.wroc.pl - 2021-10-27 00:20 +0000
              Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-26 17:52 -0700
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on antispam@math.uni.wroc.pl - 2021-10-27 05:22 +0000
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-29 15:36 -0700
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on antispam@math.uni.wroc.pl - 2021-10-31 22:54 +0000
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-10-31 20:37 -0700
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on antispam@math.uni.wroc.pl - 2021-11-11 04:34 +0000
                Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on Don Y <blockedofcourse@foo.invalid> - 2021-11-19 16:21 -0700
      Re: How to write a simple driver in bare metal systems: volatile, memory barrier, critical sections and so on David Brown <david.brown@hesbynett.no> - 2021-10-25 08:57 +0200

csiph-web