Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29761 > unrolled thread
| Started by | pozz <pozzugno@gmail.com> |
|---|---|
| First post | 2020-07-08 00:38 +0200 |
| Last post | 2020-07-13 08:35 +0200 |
| Articles | 4 on this page of 64 — 18 participants |
Back to article view | Back to comp.arch.embedded
Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-08 00:38 +0200
Re: Interrupts: can be lost? Clifford Heath <no.spam@please.net> - 2020-07-08 09:11 +1000
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-08 08:13 +0200
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-08 09:13 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-07 16:14 -0700
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-08 08:16 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 06:55 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-08 09:02 +0200
Re: Interrupts: can be lost? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-07-08 11:43 +0300
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-08 12:24 +0200
Re: Interrupts: can be lost? antispam@math.uni.wroc.pl - 2020-07-09 23:24 +0000
Re: Interrupts: can be lost? Dave Nadler <drn@nadler.com> - 2020-07-09 17:13 -0700
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-10 08:09 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 23:39 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-10 08:59 +0200
Re: Interrupts: can be lost? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-07-08 14:57 +0300
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 07:01 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-08 16:07 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 07:35 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-09 14:16 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 11:04 -0700
Re: Interrupts: can be lost? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-07-09 14:32 -0400
Re: Interrupts: can be lost? Paul Rubin <no.email@nospam.invalid> - 2020-07-09 11:47 -0700
Re: Interrupts: can be lost? lasselangwadtchristensen@gmail.com - 2020-07-09 15:22 -0700
Re: Interrupts: can be lost? Dave Nadler <drn@nadler.com> - 2020-07-09 15:35 -0700
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 18:41 -0700
Re: Interrupts: can be lost? Clifford Heath <no.spam@please.net> - 2020-07-10 16:01 +1000
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 23:28 -0700
Re: Interrupts: can be lost? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-07-29 19:44 +0100
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-29 13:23 -0700
Re: Interrupts: can be lost? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-07-29 22:57 +0100
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-29 16:47 -0700
Re: Interrupts: can be lost? Clifford Heath <no.spam@please.net> - 2020-07-30 10:04 +1000
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-29 17:46 -0700
Re: Interrupts: can be lost? Clifford Heath <no.spam@please.net> - 2020-07-30 11:04 +1000
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-29 21:16 -0700
Re: Interrupts: can be lost? Clifford Heath <no.spam@please.net> - 2020-07-30 16:36 +1000
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-31 11:26 -0700
Re: Interrupts: can be lost? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-07-30 01:11 +0100
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-29 17:53 -0700
Re: Interrupts: can be lost? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-07-30 19:05 +0100
Re: Interrupts: can be lost? Dimiter_Popoff <dp@tgi-sci.com> - 2020-07-31 00:21 +0300
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-08-04 20:40 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-04 14:36 -0700
Re: Interrupts: can be lost? Richard Damon <Richard@Damon-Family.org> - 2020-08-04 22:32 -0400
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-08-05 15:26 +0200
Re: Interrupts: can be lost? upsidedown@downunder.com - 2020-07-30 08:31 +0300
Re: Interrupts: can be lost? Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-07-30 07:53 +0100
Re: Interrupts: can be lost? Richard Damon <Richard@Damon-Family.org> - 2020-07-30 08:10 -0400
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 18:40 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-10 09:09 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-10 01:41 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-10 13:47 +0200
Re: Interrupts: can be lost? Dimiter_Popoff <dp@tgi-sci.com> - 2020-07-11 13:41 +0300
Re: Interrupts: can be lost? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-07-08 17:33 +0300
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 09:31 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-09 14:30 +0200
Re: Interrupts: can be lost? Przemek Klosowski <przemek@tux.dot.org> - 2020-07-19 18:38 +0000
Re: Interrupts: can be lost? Dimiter_Popoff <dp@tgi-sci.com> - 2020-07-19 23:11 +0300
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-19 13:43 -0700
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-08 13:19 +0200
Re: Interrupts: can be lost? Richard Damon <Richard@Damon-Family.org> - 2020-07-09 08:00 -0400
Re: Interrupts: can be lost? dalai lamah <antonio12358@hotmail.com> - 2020-07-11 12:12 +0200
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-13 08:35 +0200
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2020-07-08 13:19 +0200 |
| Message-ID | <re4a4r$ith$1@dont-email.me> |
| In reply to | #29769 |
Il 08/07/2020 09:02, David Brown ha scritto: > On 08/07/2020 00:38, pozz wrote: >> https://www.safetty.net/download/pont_pttes_2001.pdf >> >> Page 13 >> Note carefully what this means! There is a common misconception among >> the developers of embedded applications that interrupt events will never >> be lost. This simply is not true. If you have multiple sources of >> interrupts that may appear at ‘random’ time intervals, interrupt >> responses can be missed: indeed, where there are several active >> interrupt sources, it is practically impossible to create code that will >> deal correctly with all possible combinations of interrupts. >> >> Those words are incredible for me. I suspect I didn't get the point of >> the author. I don't think that interrupt events on modern microntrollers >> can be lost in some circumstances. > > The book was written in 2001, using a microcontroller that, while very > popular (and still not dead), was 20 years out of date at the time. I > haven't looked at it yet, and can't judge the quality of the book. But > beware that some things in it could be limited by that microcontroller > architecture. > > However, the principle here is correct. It is part of a more general > principle that is actually quite simple: > > If you have event counters or trackers that have limited capacity, and > you do not handle the events before that capacity is exceeded, your > system will lose events (by either ignoring new ones, or ejecting old ones). However I have the suspect the author didn't refer to multiple events of the *same* source. > [...] If you have multiple sources of interrupts [...] it is > practically impossible to create code that will deal correctly > with all possible combinations of interrupts. It's yet an obscure sentence for me. A sentence that seems to be the foundation of the entire book.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-07-09 08:00 -0400 |
| Message-ID | <9FDNG.60125$1a1.25616@fx18.iad> |
| In reply to | #29761 |
On 7/7/20 6:38 PM, pozz wrote: > https://www.safetty.net/download/pont_pttes_2001.pdf > > Page 13 > Note carefully what this means! There is a common misconception among > the developers of embedded applications that interrupt events will never > be lost. This simply is not true. If you have multiple sources of > interrupts that may appear at ‘random’ time intervals, interrupt > responses can be missed: indeed, where there are several active > interrupt sources, it is practically impossible to create code that will > deal correctly with all possible combinations of interrupts. > > Those words are incredible for me. I suspect I didn't get the point of > the author. I don't think that interrupt events on modern microntrollers > can be lost in some circumstances. Yes, if you allow yourself to be given arbitrary constraints, it is possible to get a set of system requirements that you can't meet and you can know that at times you will lose interrupts. It is always possible to have too little processor for a given set of specifications. What can be done is to convert your system requirements into timing constraints on pieces of the software, and with a bit of skill and experience decide if these are likely to be achievable (and then after implementing see if you met the requirements) to be able to prove that you can meet the requirements, or not. Yes, you can 'lose' an interrupt if you don't service it in time, often the time limit being imposed by a second verison of that (or a related) interrupt occurring. It is also possible to lose interrupts by code defects that don't handle nesting of requests properly. It has been mentioned that this was referring to an 8051, an that processor is simplistic enough that it can be hard to make sure you are handling nested requests well. I think the ISR handler needs to check for this sort of case and handle it specially.
[toc] | [prev] | [next] | [standalone]
| From | dalai lamah <antonio12358@hotmail.com> |
|---|---|
| Date | 2020-07-11 12:12 +0200 |
| Message-ID | <aebz0xy5gryy$.kfehj4cltbc9$.dlg@40tude.net> |
| In reply to | #29761 |
Un bel giorno pozz digitò: > https://www.safetty.net/download/pont_pttes_2001.pdf > > Page 13 > Note carefully what this means! There is a common misconception among > the developers of embedded applications that interrupt events will never > be lost. This simply is not true. If you have multiple sources of > interrupts that may appear at ‘random’ time intervals, interrupt > responses can be missed: indeed, where there are several active > interrupt sources, it is practically impossible to create code that will > deal correctly with all possible combinations of interrupts. > > Those words are incredible for me. I suspect I didn't get the point of > the author. I don't think that interrupt events on modern microntrollers > can be lost in some circumstances. I don't know 8051, but every MCU I've ever used had interrupt flag registers. When an interrupt comes a flag is set, and then until you don't reset this flag (generally within the ISR) the subsequent interrupts on the same source are ignored. Therefore it is true that subsequent interrupts on the same source can be lost if they are too close [1]. But if the interrupts are different, this is not true. Two different interrupts events can come even at the exact same time, and both will be flagged. Of course they won't be serviced at the same time (unless you have a multicore CPU, maybe) but they will be "queued" and processed one at a time. [1] Actually I think that there are some MCUs that have a counter instead of a flag for each interrupt source, and therefore they can queue multiple interrupts of the same source before they are processed. Then each call of the ISR will decrement the counter. -- Fletto i muscoli e sono nel vuoto.
[toc] | [prev] | [next] | [standalone]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2020-07-13 08:35 +0200 |
| Message-ID | <regvan$fic$1@dont-email.me> |
| In reply to | #29833 |
Il 11/07/2020 12:12, dalai lamah ha scritto: > Un bel giorno pozz digitò: > >> https://www.safetty.net/download/pont_pttes_2001.pdf >> >> Page 13 >> Note carefully what this means! There is a common misconception among >> the developers of embedded applications that interrupt events will never >> be lost. This simply is not true. If you have multiple sources of >> interrupts that may appear at ‘random’ time intervals, interrupt >> responses can be missed: indeed, where there are several active >> interrupt sources, it is practically impossible to create code that will >> deal correctly with all possible combinations of interrupts. >> >> Those words are incredible for me. I suspect I didn't get the point of >> the author. I don't think that interrupt events on modern microntrollers >> can be lost in some circumstances. > > I don't know 8051, but every MCU I've ever used had interrupt flag > registers. When an interrupt comes a flag is set, and then until you don't > reset this flag (generally within the ISR) the subsequent interrupts on the > same source are ignored. Therefore it is true that subsequent interrupts on > the same source can be lost if they are too close [1]. > > But if the interrupts are different, this is not true. Two different > interrupts events can come even at the exact same time, and both will be > flagged. Of course they won't be serviced at the same time (unless you have > a multicore CPU, maybe) but they will be "queued" and processed one at a > time. > > [1] Actually I think that there are some MCUs that have a counter instead > of a flag for each interrupt source, and therefore they can queue multiple > interrupts of the same source before they are processed. Then each call of > the ISR will decrement the counter. This is exactly what I thought when reading that sentence in the book.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.arch.embedded
csiph-web