Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30837
| 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-24 15:47 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <sl4nqi$a2s$1@dont-email.me> (permalink) |
| References | (2 earlier) <sl3f65$jdl$1@dont-email.me> <sl4dm3$5ut$1@dont-email.me> <sl4fk0$2si$1@dont-email.me> <sl4i03$784$1@dont-email.me> <sl4kf7$e4r$1@dont-email.me> |
On 10/24/2021 2:50 PM, Dimiter_Popoff wrote:
> On 10/25/2021 0:08, Don Y wrote:
>> On 10/24/2021 1:27 PM, Dimiter_Popoff wrote:
>> ....
>>>
>>> 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*.
>>
>> Yes, but if you want to implement flow control, you have to tell the
>> other end of the line BEFORE you've filled your buffer. There may be
>> a character being deserialized AS you are retrieving the "last"
>> character, another one (or more) preloaded into the transmitter on
>> the far device, etc. And, it will take some time for your
>> notification to reach the far end and be recognized as a desire
>> to suspend transmission. etc.
>>
>> If you wait until you have no more space available, you are almost
>> certain to lose characters.
>
> Well of course so, we have all done that sort of thing since the 80-s,
> other people have done it before I suppose. Implementing fifo thresholds
> is not (and has never been) rocket science.
> The point is there is no point in throwing huge efforts at a
> self-inflicted problem instead of just doing it the easy way which
> is well, common knowledge.
*My* point (to the OP) was that you need to understand what you
will be doing before you can understand the "opportunities"
the compiler will have to catch you off guard.
>>>>> Although this thread is on how to wrestle a poor
>>>>> language to do what you want, sort of how to use a hammer on a screw
>>>>> instead of taking the screwdriver, there would be no need to
>>>>> mask interrupts with C either.
>>>>
>>>> The "problem" with the language is that it gives the compiler the freedom
>>>> to make EQUIVALENT changes to your code that you might not have foreseen
>>>> or that might not have been consistent with your "style" -- yet do not
>>>> alter the results.
>>>
>>> Don, let us not go into this. Just looking at the thread is enough to
>>> see it is about wrestling the language so it can be made some use of.
>>
>> The language isn't the problem. Witness the *millions* (?) of programs
>> written in it, over the past 5 decades.
>
> This does not prove much, it has been the only language allowing
> "everybody" to do what they did.
ASM has always been available. Folks just found it too inefficient
to solve "big" problems, in reasonable effort.
> I am not denying this is the best
> language currently available to almost everybody. I just happened to
> have been daring enough to explore my own way/language and have seen
> how much is there to be gained if not having to wrestle a language
> which is just a more complete phrase book than the rest of the
> phrase books (aka high level languages).
But you only have yourself as a client. Most of us have to write code
(or modify already written code) that others will see/maintain. It
does no good to have a "great tool" if no one else uses it!
I use (scant!) ASM, a modified ("proprietary") C dialect, SQL and a scripting
language in my current design. (not counting the tools that generate my
documentation).
This is a LOT to expect a developer to have a firm grasp of. But, inventing
a new language that will address all of these needs would be even moreso!
At least one can find books/documentation describing each of these individual
languages *and* likely find folks with proficiency in each of them. So, I
can spend my efforts describing "how things work" instead of the details
of how to TELL them to work.
>> I've made some syntactic changes to my code that make it much easier
>> to read -- yet mean that I have to EXPLAIN how they work and why they
>> are present as any other developer would frown on encountering them.
>
> Oh I am well aware of the value of standardization and popularity,
> these are the strongest points of C.
>
>> (But, it's my opinion that, once explained, that developer will see them
>> as an efficient addition to the language in line with other *existing*
>> mechanisms that are already present, there).
>
> Of course, but you have to have them on board first...
Yes. They have to have incentive to want to use the codebase.
They'd not be keen on making any special effort to learn how
to modify a "program" that picks resistor values to form
voltage dividers.
And, even "well motivated", what you are asking them to
embrace has to be acceptable to their sense of reason.
E.g., expecting folks to adopt postfix notation just
because you chose to use it is probably a nonstarter
(i.e., "show me some OTHER reason that justifies its use!").
Or, the wonky operator set that APL uses...
>>> Similar to say Chinese, very popular, spoken by billions, yet
>>> where are its literary masterpieces. Being hieroglyph based there
>>> are none; you will have to look at alphabet based languages to
>>> find some.
>>
>> One can say the same thing about Unangax̂ -- spoken by ~100!
>> Popularity and literary masterpieces are completely different
>> axis.
>>
>> Hear much latin or ancient greek spoken, recently?
>
> The Latin alphabet looks pretty popular nowadays :-). Everything
> evolves, including languages. And there are dead ends within them
> which just die out - e.g. roman numbers. Can't see much future in
> any hieroglyph based language though, inventing a symbol for each
> word has been demonstrated to be a bad idea by history.
Witness the rise of arabic numerals and their efficacy towards
advancing mathematics.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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