Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30835
| 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 14:08 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <sl4i03$784$1@dont-email.me> (permalink) |
| References | <skvcnd$5dv$1@dont-email.me> <sl3d4h$17d3$1@gioia.aioe.org> <sl3f65$jdl$1@dont-email.me> <sl4dm3$5ut$1@dont-email.me> <sl4fk0$2si$1@dont-email.me> |
On 10/24/2021 1:27 PM, 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. Yes, I pointed that out earlier, to him. Why worry about what the compiler *might* do if you haven't sorted out what you really WANT to do? >> So, *he* may gain some advantage from disabling interrupts to >> ensure the character he is about to retrieve is n ot overwritten >> by an incoming character, placed at that location (cuz he lets >> his FIFO wrap indiscriminately). >> >> And, if the offsets ever got larger (wider) -- or became actual >> pointers -- then the possibility of PART of a value being updated >> on either "side" of an ISR is also possible. >> >> And, there's nothing to say the OP has disclosed EVERYTHING >> that might be happening in his ISR (maintaining handshaking signals, >> flow control, etc.) which could compound the references >> (e.g., if you need to know that you have space for N characters >> remaining so you can signal the remote device to stop sending, >> then you're doing "pointer/offset arithmetic" and *acting* on the >> result) > > 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. >>> 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. The problem is that it never was an assembly language -- even though it was treated as such "in days gone by" (because the compiler's were just "language translators" and didn't add any OTHER value to the "programming process"). It's only recently that compilers have become "independent agents", of a sort... adding their own "spin" on the developer's code. And, with more capable hardware (multiple cores/threads) being "dirt cheap", it's a lot easier for a developer to find himself in a situation that was previously pie-in-the-sky. >> After all, a programming language -- ANY programming language -- is just >> a vehicle for conveying our desires to the machine in a semi-unambiguous >> manner. I'd much rather *SAY*, "What are the roots of ax^2 + bx + c?" >> than have to implement an algorithmic solution, worry about cancellation, >> required precision, etc. (and, in some languages, you can do just that!) > > Indeed you don't want to write how the equation is solved every time. > This is why you can call it once you have it available. This is language > independent. For a simple quadratic, you can explore the coefficients to determine which algorithm is best suited to giving you *accurate* results. What if I present *any* expression? Can you have your solution available to handle any case? Did you even bother to develop such a solution if you were only encountering quadratics? > Then solving expressions etc. is well within 1% of the effort in > programming if the task at hand is going to take > 2 weeks; after that > the programmer's time is wasted on wrestling the language like > demonstrated by this thread. Sadly almost everybody has accepted > C as a standard - which makes it a very popular poor language. It makes it *popular* but concluding that it is "poor" is an overreach. There are (and have been) many "safer" languages. Many that are more descriptive (for certain classes of problem). But, C has survived to handle all-of-the-above... perhaps in a suboptimal way but at least a manner that can get to the desired solution. Look at how few applications SNOBOL handles. Write an OS in COBOL? Ada? A tool is only effective if it solves real problems. Under real cost and time constraints. There are lots of externalities that come into play in that analysis. 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. (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). > 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?
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