On 1/17/2023 3:49, Don Y wrote:> On 1/16/2023 3:56 PM, Dimiter_Popoff wrote: >> I am not sure I get it, I have had such an interrupt controller on >> the power cores I have used (first one on the mpc8240, late 90-s). >> >> What happens to the core when the IRQ line from the interrupt >> controller is asserted? On power, this would cause the core >> to set the interrupt mask bit and go to a specific address, >> roughly speaking. Then it is up to the core to clear *its* >> mask bit in its MSR, no matter what the interrupt controller >> does. > > There is one EXTERNAL interrupt signal available. All of the > INTERNAL (SoC) interrupt sources each connect to the NVIC > directly. There are dozens of such sources. The NVIC makes it > possible (to some extent) to prioritize how "important" > (priority) each source is.It is the same with the power SoCs I use. What I wonder about is how the single IRQ line/mask bit the core has is handled. All the peripherals on the SoC go into a *peripheral*, called the IRQ priority encoder or something. And this encoder resolves priorities, supplies vectors etc. one way or the other. But it has only *one* IRQ wire to the core to signal an interrupt. Normal processors take the interrupt and enter the interrupt handling routine - selected by whatever vector - with the interrupt *masked*, otherwise the core would have no chance to clear the interrupt before being interrupted again. I see two ways out of this to allow interrupt nesting: - the IRQ input to the core is edge sensitive and either the IRQ is not maskable or the core unmasks itself as soon as it gets the interrupt; the external (to the core) priority encoder would deliver another edge only if it is of higher priority than the last one it has delivered which is not yet reset by the core. - the IRQ input is still level sensitive but the IACK signal from the core to the priority encoder makes it look edge sensitive (i.e. the priority encoder negates its IRQ to the core in response to IACK). Basically this would mimic 68k behaviour, the 68k core must be doing it in some similar sort of way itself anyway. And I suspect that *my* SoCs might do that as well... I have just never looked into it, the IRQ latency is good enough (around 1us worst case I think) as it is...
highest frequency periodic interrupt?
Started by ●January 13, 2023
Reply by ●January 17, 20232023-01-17
Reply by ●January 17, 20232023-01-17
On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:>On a sunny day (Mon, 16 Jan 2023 06:29:25 -0800) it happened John Larkin ><jlarkin@highlandSNIPMEtechnology.com> wrote in ><cenashpl5f7cdk37nq4dab7hcdlqknptqh@4ax.com>: > > >>We wrote one Linux program that just toggled a test point as fast as >>it could. That was interesting on a scope, namely the parts that >>didn't toggle. > >That way the task switch will interrupt, any multitasker does that. > >It all depends look at > 'using raspberry Pi as FM transmitter' (80 to 100 MHz or so): > https://linuxhint.com/turn-raspberry-pi-fm-transmitter/ > >That code gave me the following idea, >freq_pi: > http://panteltje.com/panteltje/newsflex/download.html#freq_pi > >and that was for a very old Pi model, >somebody then ported it to a later model, no idea how fast you can go on a Pi4. > >So, basically, you mentioned: > "will give it (Pi4) to some programmer" > >Now let me tell you this!!! > >STUDY THE HARDWARE >that Pi4 has some quite complex very powerful hardware on board. >Using that will beat any 'just code a loop in C or asm or whatever' or interrupt stuff.The Pi4 would just be the dev and debug system, so I don't care how fast it is. Its cost is a few percent of a PC-based dev platform. The products will use Pico, bare metal.>The same goes for most micros, most have extra hardware on board. >What we see now is programmers who have no clue about hardware >building libraries that are bloated and slow >that then are used by others that have even less knowledge of the hardware >AND of programming and user interfaces to make modern bloat like microsore and jmail email crap. > >So my advice to you: study the hardware of that Pi4 you bought for all those dollars. >Most of the time no need to learn ARM asm (and all its registers) just make use of the hardware there is. > >'A programmer' likely will not understand the hardware and resort to bloat where it is not needed. > >I'm always impressed by how little most realtime programmers know about, well, real time. They usually have no clue about execution times, or how to measure same. I buy them oscilloscopes. They are usually reluctant to use the CPUs hard, typically by about a factor of twenty.
Reply by ●January 17, 20232023-01-17
On 1/17/2023 7:36 AM, Dimiter_Popoff wrote:> On 1/17/2023 3:49, Don Y wrote: >> On 1/16/2023 3:56 PM, Dimiter_Popoff wrote: >>> I am not sure I get it, I have had such an interrupt controller on >>> the power cores I have used (first one on the mpc8240, late 90-s). >>> >>> What happens to the core when the IRQ line from the interrupt >>> controller is asserted? On power, this would cause the core >>> to set the interrupt mask bit and go to a specific address, >>> roughly speaking. Then it is up to the core to clear *its* >>> mask bit in its MSR, no matter what the interrupt controller >>> does. >> >> There is one EXTERNAL interrupt signal available. All of the >> INTERNAL (SoC) interrupt sources each connect to the NVIC >> directly. There are dozens of such sources. The NVIC makes it >> possible (to some extent) to prioritize how "important" >> (priority) each source is. > > It is the same with the power SoCs I use. What I wonder about is > how the single IRQ line/mask bit the core has is handled. > All the peripherals on the SoC go into a *peripheral*, called > the IRQ priority encoder or something. And this encoder resolves > priorities, supplies vectors etc. one way or the other.Yes. The NVIC has a similar role and interconnect.> But it has only *one* IRQ wire to the core to signal an interrupt. > Normal processors take the interrupt and enter the interrupt > handling routine - selected by whatever vector - with the interrupt > *masked*, otherwise the core would have no chance to clear the > interrupt before being interrupted again. > I see two ways out of this to allow interrupt nesting: > - the IRQ input to the core is edge sensitive and either the > IRQ is not maskable or the core unmasks itself as soon as it gets > the interrupt; the external (to the core) priority encoder would > deliver another edge only if it is of higher priority than the > last one it has delivered which is not yet reset by the core.The core could signal the acknowledgement of the request and the NVIC release the request -- unless another interrupt of higher priority immediately follows. The core can similarly signal the NVIC when the ISR is complete so the NVIC would know to allow LOWER priority requests through.> - the IRQ input is still level sensitive but the IACK signal from > the core to the priority encoder makes it look edge sensitive (i.e. > the priority encoder negates its IRQ to the core in response to > IACK).That's what I was suggesting, above. Remember, everything ARM is "pieced together". If this was a conventional/legacy design, the NVIC would likely be a separate chip with a bus interface to the CPU and some special signals/handshakes for the interrupt. When you think about it, there is a rather narrow bit of information that must be exchanged between the two parties. So, it's likely a good partitioning of functionality. Other processors have resorted to different contortions to give flexibility in interrupt handling *outside* the CPU. E.g., the 8085 allows the user to jam opcodes onto the bus. Typically, you would jam one of the "restart" opcodes to force a "call" to one of 8 specific addresses. But, you could jam any other opcode if you wanted to be creative. The Z80 had a "vectored" mode where you put an interrupt number on the bus and it would use this as an offset into the interrupt vector table. The 8x300 didn't even have an IRQ! You had to build a machine off-chip to jam opcodes onto the bus in place of instruction fetches! (that logic also had to capture the return address and store it EXTERNAL TO THE PROCESSOR!)> Basically this would mimic 68k behaviour, the 68k core must be > doing it in some similar sort of way itself anyway. > And I suspect that *my* SoCs might do that as well... I have just never > looked into it, the IRQ latency is good enough (around 1us worst > case I think) as it is... >
Reply by ●January 17, 20232023-01-17
On 1/17/2023 18:15, Don Y wrote:> On 1/17/2023 7:36 AM, Dimiter_Popoff wrote: >> On 1/17/2023 3:49, Don Y wrote: >>> On 1/16/2023 3:56 PM, Dimiter_Popoff wrote: >>>> I am not sure I get it, I have had such an interrupt controller on >>>> the power cores I have used (first one on the mpc8240, late 90-s). >>>> >>>> What happens to the core when the IRQ line from the interrupt >>>> controller is asserted? On power, this would cause the core >>>> to set the interrupt mask bit and go to a specific address, >>>> roughly speaking. Then it is up to the core to clear *its* >>>> mask bit in its MSR, no matter what the interrupt controller >>>> does. >>> >>> There is one EXTERNAL interrupt signal available. All of the >>> INTERNAL (SoC) interrupt sources each connect to the NVIC >>> directly. There are dozens of such sources. The NVIC makes it >>> possible (to some extent) to prioritize how "important" >>> (priority) each source is. >> >> It is the same with the power SoCs I use. What I wonder about is >> how the single IRQ line/mask bit the core has is handled. >> All the peripherals on the SoC go into a *peripheral*, called >> the IRQ priority encoder or something. And this encoder resolves >> priorities, supplies vectors etc. one way or the other. > > Yes. The NVIC has a similar role and interconnect. > >> But it has only *one* IRQ wire to the core to signal an interrupt. >> Normal processors take the interrupt and enter the interrupt >> handling routine - selected by whatever vector - with the interrupt >> *masked*, otherwise the core would have no chance to clear the >> interrupt before being interrupted again. >> I see two ways out of this to allow interrupt nesting: >> - the IRQ input to the core is edge sensitive and either the >> IRQ is not maskable or the core unmasks itself as soon as it gets >> the interrupt; the external (to the core) priority encoder would >> deliver another edge only if it is of higher priority than the >> last one it has delivered which is not yet reset by the core. > > The core could signal the acknowledgement of the request > and the NVIC release the request -- unless another interrupt > of higher priority immediately follows. > > The core can similarly signal the NVIC when the ISR is complete > so the NVIC would know to allow LOWER priority requests through.I just had a look at the interrupt controller on the older of the power cores I have used, the MPC8240. Called EPIC, for embedded programmable interrupt controller of course :-). It does all that as I assumed; however there is no IACK signal from the core back to it, the processor must access a location for that. The controller would then negate the interrupt request so the core can reenable the interrupt line by the respective bit in its state register. Like many things power this is also delegated wherever this can be done to add flexibility, basically does the same thing as the 3 bit mask on 68k (has 4 bits on that one though). Apparently I have never needed *that* kind of low latency (tens of ns) so I still live with the "prioritize your interrupts as you feel right, I'll take the next one when I am done with the current one".
Reply by ●January 17, 20232023-01-17
On a sunny day (Tue, 17 Jan 2023 07:44:44 -0800) it happened John Larkin <jlarkin@highlandSNIPMEtechnology.com> wrote in <g1gdshpc584v9eioeq4b1jo8073vo5lsbc@4ax.com>:>On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje ><pNaonStpealmtje@yahoo.com> wrote: > >>On a sunny day (Mon, 16 Jan 2023 06:29:25 -0800) it happened John Larkin >><jlarkin@highlandSNIPMEtechnology.com> wrote in >><cenashpl5f7cdk37nq4dab7hcdlqknptqh@4ax.com>: >> >> >>>We wrote one Linux program that just toggled a test point as fast as >>>it could. That was interesting on a scope, namely the parts that >>>didn't toggle. >> >>That way the task switch will interrupt, any multitasker does that. >> >>It all depends look at >> 'using raspberry Pi as FM transmitter' (80 to 100 MHz or so): >> https://linuxhint.com/turn-raspberry-pi-fm-transmitter/ >> >>That code gave me the following idea, >>freq_pi: >> http://panteltje.com/panteltje/newsflex/download.html#freq_pi >> >>and that was for a very old Pi model, >>somebody then ported it to a later model, no idea how fast you can go on a Pi4. >> >>So, basically, you mentioned: >> "will give it (Pi4) to some programmer" >> >>Now let me tell you this!!! >> >>STUDY THE HARDWARE >>that Pi4 has some quite complex very powerful hardware on board. >>Using that will beat any 'just code a loop in C or asm or whatever' or interrupt stuff. > >The Pi4 would just be the dev and debug system, so I don't care how >fast it is. Its cost is a few percent of a PC-based dev platform. The >products will use Pico, bare metal.Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry and a lot of others using the chip: https://en.wikipedia.org/wiki/RP2040. I also downloaded the datasheet, the pdf has 636 pages.. later! clock is not that fast, via PLL 125 MHz, (page 187). My 18F14K22 PICs run at 64 MHz via internal PLL My Pi4 8 GB locked up on the daily.mail.co.uk website just now. using Chromium browser... That is the first time, power sequence off / on and its running again, strange. Nothing is perfect...>I'm always impressed by how little most realtime programmers know >about, well, real time. > >They usually have no clue about execution times, or how to measure >same. I buy them oscilloscopes. They are usually reluctant to use the >CPUs hard, typically by about a factor of twenty.Maybe to do with history, when I started with logic there were no microprocessors and you had to do simple hardware design, gates, multiplexers, buffers, what not. You mentioned state machines a while back.. Insight for me was when I realized all that logic could only work because gates etc had a delay. Color TV was all nano second stuff that had to be in phase for the right color over long distances between sources (like cameras and even cameras in remote locations) and video tape recorders so all control loops to keep in ns lock. All without computers in sixties.. So nano nano has become a bit of a second nature to me. Maybe why I got pissed with gee-mail this morning 'sorry we are having a problem try again later' and then 'you have one email' but nowhere to be found... Anyways, how are things there, flooding stopped? Rain has stopped here (for now, was sunny and about to go biking when hail started and within seconds everything was covered by small white balls: http://panteltje.com/pub/sudden_hail_IXIMG_0915.JPG Looked up rain radar and concluded it was just a few clouds, the white stuff melted a few minutes later.. Bought lots of cookies and some Belgian potato chips... Now frost is predicted..... Chips and coffee with cream and chocolate and .. I am ready for it!
Reply by ●January 17, 20232023-01-17
On Tue, 17 Jan 2023 17:52:08 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:>On a sunny day (Tue, 17 Jan 2023 07:44:44 -0800) it happened John Larkin ><jlarkin@highlandSNIPMEtechnology.com> wrote in ><g1gdshpc584v9eioeq4b1jo8073vo5lsbc@4ax.com>: > >>On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje >><pNaonStpealmtje@yahoo.com> wrote: >> >>>On a sunny day (Mon, 16 Jan 2023 06:29:25 -0800) it happened John Larkin >>><jlarkin@highlandSNIPMEtechnology.com> wrote in >>><cenashpl5f7cdk37nq4dab7hcdlqknptqh@4ax.com>: >>> >>> >>>>We wrote one Linux program that just toggled a test point as fast as >>>>it could. That was interesting on a scope, namely the parts that >>>>didn't toggle. >>> >>>That way the task switch will interrupt, any multitasker does that. >>> >>>It all depends look at >>> 'using raspberry Pi as FM transmitter' (80 to 100 MHz or so): >>> https://linuxhint.com/turn-raspberry-pi-fm-transmitter/ >>> >>>That code gave me the following idea, >>>freq_pi: >>> http://panteltje.com/panteltje/newsflex/download.html#freq_pi >>> >>>and that was for a very old Pi model, >>>somebody then ported it to a later model, no idea how fast you can go on a Pi4. >>> >>>So, basically, you mentioned: >>> "will give it (Pi4) to some programmer" >>> >>>Now let me tell you this!!! >>> >>>STUDY THE HARDWARE >>>that Pi4 has some quite complex very powerful hardware on board. >>>Using that will beat any 'just code a loop in C or asm or whatever' or interrupt stuff. >> >>The Pi4 would just be the dev and debug system, so I don't care how >>fast it is. Its cost is a few percent of a PC-based dev platform. The >>products will use Pico, bare metal. > >Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry >and a lot of others using the chip: > https://en.wikipedia.org/wiki/RP2040. > >I also downloaded the datasheet, the pdf has 636 pages.. later! >clock is not that fast, via PLL 125 MHz, (page 187). >My 18F14K22 PICs run at 64 MHz via internal PLL > >My Pi4 8 GB locked up on the daily.mail.co.uk website just now. using Chromium browser... >That is the first time, power sequence off / on and its running again, strange. >Nothing is perfect... > >>I'm always impressed by how little most realtime programmers know >>about, well, real time. >> >>They usually have no clue about execution times, or how to measure >>same. I buy them oscilloscopes. They are usually reluctant to use the >>CPUs hard, typically by about a factor of twenty. > >Maybe to do with history, when I started with logic there were no microprocessors >and you had to do simple hardware design, gates, multiplexers, buffers, what not. >You mentioned state machines a while back.. > >Insight for me was when I realized all that logic could only work because gates etc had a delay.The flops in LT Spice don't make a reliable shift register unless you specifically add prop delay. Real shift registers, like a string of 8-wides, can mess up too, if the clocks aren't distributed right. A few parts are really safe, input on rising edge but output on falling edge. Sometimes I add a resistor between chips, Qout to Din, to allow for clock skew.>Color TV was all nano second stuff that had to be in phase for the right color over >long distances between sources (like cameras and even cameras in remote locations) and >video tape recorders so all control loops to keep in ns lock. >All without computers in sixties.. >So nano nano has become a bit of a second nature to me. >Maybe why I got pissed with gee-mail this morning >'sorry we are having a problem try again later' >and then 'you have one email' but nowhere to be found... > >Anyways, how are things there, flooding stopped?It's cool, sunny, and beautiful. I hope the storm season is just pausing for a while. We need more rain and snow.>Rain has stopped here (for now, was sunny and about to go biking when hail started >and within seconds everything was covered by small white balls: > http://panteltje.com/pub/sudden_hail_IXIMG_0915.JPGYikes, but doesn't look lethal.>Looked up rain radar and concluded it was just a few clouds, the white stuff melted a few minutes >later.. Bought lots of cookies and some Belgian potato chips...We may have shrimp sliders and tater tots for dinner. Or maybe the leftover dumplings. https://www.uniteddumplings.com/ The wontons in red oil are fabulous. And the string beans.>Now frost is predicted..... >Chips and coffee with cream and chocolate and .. I am ready for it! > > > > >
Reply by ●January 17, 20232023-01-17
tirsdag den 17. januar 2023 kl. 21.10.33 UTC+1 skrev John Larkin:> On Tue, 17 Jan 2023 17:52:08 GMT, Jan Panteltje > <pNaonSt...@yahoo.com> wrote: > > >On a sunny day (Tue, 17 Jan 2023 07:44:44 -0800) it happened John Larkin > ><jla...@highlandSNIPMEtechnology.com> wrote in > ><g1gdshpc584v9eioe...@4ax.com>: > > > >>On Tue, 17 Jan 2023 06:27:49 GMT, Jan Panteltje > >><pNaonSt...@yahoo.com> wrote: > >> > >>>On a sunny day (Mon, 16 Jan 2023 06:29:25 -0800) it happened John Larkin > >>><jla...@highlandSNIPMEtechnology.com> wrote in > >>><cenashpl5f7cdk37n...@4ax.com>: > >>> > >>> > >>>>We wrote one Linux program that just toggled a test point as fast as > >>>>it could. That was interesting on a scope, namely the parts that > >>>>didn't toggle. > >>> > >>>That way the task switch will interrupt, any multitasker does that. > >>> > >>>It all depends look at > >>> 'using raspberry Pi as FM transmitter' (80 to 100 MHz or so): > >>> https://linuxhint.com/turn-raspberry-pi-fm-transmitter/ > >>> > >>>That code gave me the following idea, > >>>freq_pi: > >>> http://panteltje.com/panteltje/newsflex/download.html#freq_pi > >>> > >>>and that was for a very old Pi model, > >>>somebody then ported it to a later model, no idea how fast you can go on a Pi4. > >>> > >>>So, basically, you mentioned: > >>> "will give it (Pi4) to some programmer" > >>> > >>>Now let me tell you this!!! > >>> > >>>STUDY THE HARDWARE > >>>that Pi4 has some quite complex very powerful hardware on board. > >>>Using that will beat any 'just code a loop in C or asm or whatever' or interrupt stuff. > >> > >>The Pi4 would just be the dev and debug system, so I don't care how > >>fast it is. Its cost is a few percent of a PC-based dev platform. The > >>products will use Pico, bare metal. > > > >Ok, I had a quick look at that RP2040, there seem to be 2 versions from Raspberry > >and a lot of others using the chip: > > https://en.wikipedia.org/wiki/RP2040. > > > >I also downloaded the datasheet, the pdf has 636 pages.. later! > >clock is not that fast, via PLL 125 MHz, (page 187). > >My 18F14K22 PICs run at 64 MHz via internal PLL > > > >My Pi4 8 GB locked up on the daily.mail.co.uk website just now. using Chromium browser... > >That is the first time, power sequence off / on and its running again, strange. > >Nothing is perfect... > > > >>I'm always impressed by how little most realtime programmers know > >>about, well, real time. > >> > >>They usually have no clue about execution times, or how to measure > >>same. I buy them oscilloscopes. They are usually reluctant to use the > >>CPUs hard, typically by about a factor of twenty. > > > >Maybe to do with history, when I started with logic there were no microprocessors > >and you had to do simple hardware design, gates, multiplexers, buffers, what not. > >You mentioned state machines a while back.. > > > >Insight for me was when I realized all that logic could only work because gates etc had a delay. > The flops in LT Spice don't make a reliable shift register unless you > specifically add prop delay. > > Real shift registers, like a string of 8-wides, can mess up too, if > the clocks aren't distributed right. A few parts are really safe, > input on rising edge but output on falling edge. Sometimes I add a > resistor between chips, Qout to Din, to allow for clock skew.many shift registers like 74HC595 are guaranteed zero-hold so a safe way is to first route the clock to the last in the chain and then to rest the opposite direction of the data same trick works for paralleling things, wire the two terminals in the opposite direction so the wire resistance is the same for all of them
Reply by ●January 17, 20232023-01-17
Buy Vape Cartridges Online Variegated Plants For Sale Near Me Bruce Banner #3 Strain Buy Edibles Online Buy Dank Gummies 500mg Brass Knuckles For Sale White Monstera For Sale Buy AK-47 Weed Online Buy One Up Mushroom Bar 3.5G Tales Of Arabian Nights Buy Green Crack Online Ghost Train Haze For Sale Buy Alaskan Thunder Fuck Online Buy Budheads Edibles Chewy Cubes 600 mg Buy Rhaphidophora tetrasperma Buy Acapulco Gold strain online Batman 66 Pinball For Sale Monstera Albo For Sale Florida Buy Gas Heads Edibles 600mg Buy Bhang Cartridges Online Philodendron fibraecataphyllum Buy Iron Man Pinball Online Buy Sour Diesel Online Caudex (Beaucarnea) Twilight Zone Pinball For Sale Buy Nova Vape Carts Online Maranta Lemon Lime For Sale Philodendron Caramel Marble Variegated Blueberry Strain For Sale Pinball Machine Star Wars Philodendron Florida Beauty Variegata Buy Kali Mist Online Jurassic Park Pinball Buy Chocolope Online Buy Durban Poison Online Buy Spliffin Vape Cartridges Online Buy Skywalker OG Online Buy Push Vape Cartridges Online Buy Wonders 1000mg THC Canna Lean Online Buy Grapefruit Online Friendly Farms Carts For Sale Buy Lemon Haze Strain Buy Weed Online Variegated Plant Shop Pinball Machine For Sale Near Me eBAY PinBall Machine Buy Grease Monkey Exotic Carts 710 Kingpen Catridges For Sale Buy Moonrock clear carts online Rare Variegated Plants For Sale Variegated Plants For Sale UK Variegated Plants For Sale NZ Philodendron Florida Beauty Variegated For Sale Rove Carts For Sale https://megaweedmarketltd.com/ https://qualitypinballcompany.com/ https://qualityvariegatedplants.com/ https://megaweedmarketltd.com/product/bruce_banner_strain/ https://megaweedmarketltd.com/product/dank_gummies/ https://megaweedmarketltd.com/product/brass_knuckles_for_sale/ https://qualityvariegatedplants.com/product/white-monstera-for-sale/ https://megaweedmarketltd.com/product/ak_47_strain/ https://megaweedmarketltd.com/product/one_up_bar/ https://qualitypinballcompany.com/product/tales_of_arabian_nights/ https://megaweedmarketltd.com/product/green_crack_strain/ https://megaweedmarketltd.com/product/ghost-train-haze/ https://megaweedmarketltd.com/product/buy-alaskan-thunder-fuck-online/ https://megaweedmarketltd.com/product/budheads/ https://qualityvariegatedplants.com/product/buy-rhaphidophora-tetrasperma/ https://megaweedmarketltd.com/product/buy-acapulco-gold-strain-online/ https://qualitypinballcompany.com/product/batman_66_pinball_for_sale/ https://qualityvariegatedplants.com/product/monstera-albo-for-sale-florida/ https://megaweedmarketltd.com/product/gas_heads/ https://megaweedmarketltd.com/product/buy_bhang_cartridges_online/ https://qualityvariegatedplants.com/product/philodendron-fibraecataphyllum/ https://qualitypinballcompany.com/product/buy_iron_man_pinball_online/ https://megaweedmarketltd.com/product/sour-diesel/ https://qualityvariegatedplants.com/product/caudex-beaucarnea/ https://qualitypinballcompany.com/product/twilight_zone_pinball_for_sale/ https://megaweedmarketltd.com/product/buy_nova_vape_carts_online/ https://qualityvariegatedplants.com/product/maranta-lemon-lime-for-sale/ https://qualityvariegatedplants.com/product/philodendron-caramel-marble/ https://megaweedmarketltd.com/product/blueberry_strain/ https://qualitypinballcompany.com/product/pinball_machine_star_wars/ https://qualityvariegatedplants.com/product/philodendron-florida-beauty-2/ https://megaweedmarketltd.com/product/kali-mist/ https://qualitypinballcompany.com/product/jurassic_park_pinball/ https://megaweedmarketltd.com/product/chocolope/ https://megaweedmarketltd.com/product/buy-durban-poison-online/ https://megaweedmarketltd.com/product/spliffin_cartridges/ https://megaweedmarketltd.com/product/skywalker_strain/ https://megaweedmarketltd.com/product/buy_push_vape_cartridges_online/ https://megaweedmarketltd.com/product/thc_lean/ https://megaweedmarketltd.com/product/grapefruit/ https://megaweedmarketltd.com/product/friendly_farms/ https://megaweedmarketltd.com/product/lemon_haze/ https://megaweedmarketltd.com/product/buy_grease_monkey_exotic_carts/ https://megaweedmarketltd.com/product/710_kingpen_cartridges_for_sale/ https://megaweedmarketltd.com/product/buy_moonrock_clear_carts_online/ https://qualityvariegatedplants.com/product/philodendron-florida-beauty-variegated-for-sale/ https://qualityvariegatedplants.com/product/philodendron-florida-beauty-for-sale-near-me/ https://megaweedmarketltd.com/product/rove_carts/
Reply by ●January 17, 20232023-01-17
On 1/17/2023 10:10 AM, Dimiter_Popoff wrote:>>> But it has only *one* IRQ wire to the core to signal an interrupt. >>> Normal processors take the interrupt and enter the interrupt >>> handling routine - selected by whatever vector - with the interrupt >>> *masked*, otherwise the core would have no chance to clear the >>> interrupt before being interrupted again. >>> I see two ways out of this to allow interrupt nesting: >>> - the IRQ input to the core is edge sensitive and either the >>> IRQ is not maskable or the core unmasks itself as soon as it gets >>> the interrupt; the external (to the core) priority encoder would >>> deliver another edge only if it is of higher priority than the >>> last one it has delivered which is not yet reset by the core. >> >> The core could signal the acknowledgement of the request >> and the NVIC release the request -- unless another interrupt >> of higher priority immediately follows. >> >> The core can similarly signal the NVIC when the ISR is complete >> so the NVIC would know to allow LOWER priority requests through. > > I just had a look at the interrupt controller on the older of the > power cores I have used, the MPC8240. Called EPIC, for embedded > programmable interrupt controller of course :-). > > It does all that as I assumed; however there is no IACK signal from > the core back to it, the processor must access a location for that.Or, the controller could implicitly jam a vector onto the bus, etc. It depends on what the controller can "see" about the inner workings of the core. E.g., the 8x300's approach was to let the designer watch the CPU's operation and "trick" it into "interrupting" it's execution sequence (the external logic had to capture the return address and reapply it -- no stack! -- when it saw the RET being executed)> The controller would then negate the interrupt request so the core > can reenable the interrupt line by the respective bit in its state > register. Like many things power this is also delegated wherever > this can be done to add flexibility, basically does the same thing > as the 3 bit mask on 68k (has 4 bits on that one though). > Apparently I have never needed *that* kind of low latency (tens > of ns) so I still live with the "prioritize your interrupts as you > feel right, I'll take the next one when I am done with the current one".I am really loath to rely on interrupts for much. Too often, people treat jobs as having "hard" real-time components when, in fact, they don't need to be. So, they design "more brittle" (brittler?) solutions and declare that "This MUST happen"... which, of course, gives them an excuse to not think about the consequences if it doesn't! [E.g., what happens if you miss a character in a serial stream? Do you know *where* you missed it? Do you know how *many* you missed? Will the sender be able to learn of this problem and recover? Do you impose sequence numbers on messages? etc.] [[Serial port drivers are delightful to watch people screw up. Too much "three-dimensional" thinking involved... plus a belief that "it's simple, right?"]]
Reply by ●January 18, 20232023-01-18
On a sunny day (Tue, 17 Jan 2023 12:10:21 -0800) it happened John Larkin <jlarkin@highlandSNIPMEtechnology.com> wrote in <jgvdsh5f09j13nrkh6hco5uc5st0i0bu2b@4ax.com>:>We may have shrimp sliders and tater tots for dinner. Or maybe the >leftover dumplings. > >https://www.uniteddumplings.com/Yummy , looks nice!>The wontons in red oil are fabulous. And the string beans.
