the core it self only has one interrupt signal, but the NVIC takes care of all the stuff that makes it possible for higher priority interrupts to interrupt an already running interrupt
being "in" an interrupt only mask that priority and lower priorities
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.
On 68k/coldfire it is different; the core has a 3 bit interrupt mask in its status register and 7 interrupt wires. If you assert say IRQ2 the core sets its mask to 2 which masks IRQ2 and goes through the IRQ2 vector. Now if IRQ3 is asserted it will be taken the same way immediately and the mask will be set to 3; if IRQ1 comes it will have to wait until the core sets it mask bits to 0. Level 7 IRQ is unmaskable (useful only for debugging purposes, not in general code).
(Please feel free to ignore me if you don't feel like explaining all that ARM stuff now, obviously I can dig it myself if I really need it).
it is basically the same as how you describe the 68K it just isn't inside the core it is in a module that sits next to the core
all the different interrupts a connected to the NVIC and single interrupt from the NVIC to the core, all the different interrupts have a programmable priority level
when an unmasked interrupt is asserted the NVIC interrupts the core, mask same and lower priorities, "reenables" interrupts and vector to that ISR
same happens if another interrupt that isn't masked i.e. higher priority is asserted while an ISR is running
On a sunny day (Mon, 16 Jan 2023 06:29:25 -0800) it happened John Larkin snipped-for-privacy@highlandSNIPMEtechnology.com wrote in snipped-for-privacy@4ax.com:
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):
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 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.
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...
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.
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.
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".
On a sunny day (Tue, 17 Jan 2023 07:44:44 -0800) it happened John Larkin snipped-for-privacy@highlandSNIPMEtechnology.com wrote in snipped-for-privacy@4ax.com:
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:
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...
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:
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.
It's cool, sunny, and beautiful. I hope the storm season is just pausing for a while. We need more rain and snow.
Yikes, but doesn't look lethal.
We may have shrimp sliders and tater tots for dinner. Or maybe the leftover dumplings.
tirsdag den 17. januar 2023 kl. 21.10.33 UTC+1 skrev John Larkin:
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
On a sunny day (Tue, 17 Jan 2023 12:10:21 -0800) it happened John Larkin snipped-for-privacy@highlandSNIPMEtechnology.com wrote in snipped-for-privacy@4ax.com:
Yummy , looks nice!
On a sunny day (Tue, 17 Jan 2023 12:10:21 -0800) it happened John Larkin snipped-for-privacy@highlandSNIPMEtechnology.com wrote in snipped-for-privacy@4ax.com:
2 accidents happened, there was warning about it in the news. That stuff acts like ball bearings you drive - into a field like that - and steering and breaking has no effect, you will keep moving in a straight line!
OK I did read all 636 pages of the datasheet just now. What I do not like for starters is the 12 bit ADC uses the 3.3 V supply as referene it seems, see page 566 specifically.
My PIC ADC has a programmable internal reference (1, 2, or 4 times 1,24 V)
Also my PIC has 2 hardware comparators, one can reset the PMW for cycle by cycle current limit.
Am I imagining this or is this hardware bloat design by them? Not even on on-board EEPROM like my PICs have...
Its not my chip!
They are clear that one can add a bandgap to pin 35 of the Pico, or force an external reference.
2 Mbyte serial flash on the Pico. That should be plenty for a reasonable product.Digikey has 200K of the 2040 chips in stock for $1, and 19K of the Pi Pico board for $4. What's interesting is that the pricing is for any quantity. The Pi foundation probably requires that.
They are mostly back-ordered or EOL on the other ARMs that we have used, and are price gouging at that.
On a sunny day (Wed, 18 Jan 2023 08:18:21 -0800) it happened John Larkin snipped-for-privacy@highlandSNIPMEtechnology.com wrote in snipped-for-privacy@4ax.com:
Must have missed that.
The nice point of EEPROM is for example keep settings after power down, calibration of things.
18F14K22 has 16k FLASH, 256 bytes EEPROM you could store your FPGA code in the FLASH for example (dunno how many bytes you need) sleep mode 34 nA for the PIC 18LF1XK22 Hobby shop in UK has 30 in stock Aliexpres has 100 for about 200$ it says. Many analog inputs, DAC output, PWM generator, serial, but no USB But I have cheap serial to USB modules from ebay for my projects. I program the PICs is ASM, so far no problems, even controls my drone, radiation meters (PMT based too), clock, bench power supply, camera motion control, FM transmitter, fluxgate compass, thermocouple tester, step motor control, many thingAnyways, let us know how that module pans out!
gm2pic has been on 24/7 now since 2011, the OLED display did suffer burn in, replaced that by a new one,..
12 years is pretty good data retention for its FLASH.No, if I needed more computer power and/or C programming then I would get the Raspberry Pi 4 It seems halfway this year they will pop up again? By the zillions? Anyways you have one now, so have fun! Do not give it away to your 'programmer' :-)
We'd need in the 2M flash, per unit, the runtime code, the calibration table, sometimes an FPGA bit stream, and a release notes text file. Some of the runtime code, the fast ISR for one of the ARM cores, would be relocated into SRAM at powerup time. That might be another file in the flash. I've got to figure that out.
I'd just buy 10 more from Amazon and make sure that are all set up the same.
onsdag den 18. januar 2023 kl. 19.48.54 UTC+1 skrev John Larkin:
I've not tried it yet, but as far I can tell you just decorate the function with __not_in_flash_func in the code then the linker and bootloader figures it all out for you
It sounds like the Pi people have done everything right. I need a maker-space refugee kid who has time to work out the details. I just want to design circuits.
I am thinking that there are lots of cases where a dedicated 133 MHz ARM core can replace an FPGA.
Sadly., John Laarkin doesn't seem to know what designing circuits entails. Working out the details is part of the process.
An ARM core is a single-threaded processor. With an FPGA you can set up genuinely parallel processes and have them operating simultaneously, and only communicating when they need to. It's a pretty basic distinction.
If you are essentially using the FPGA to realise a standard processor (and you can program them to include an ARM core) you could replace that FPGA with the right off-the-shelf processor, but it would be a pretty bizarre design assignment that lead you to do that - you'd have to need lots of odd peripherals in a single package to make it worth doing.
On a sunny day (Thu, 19 Jan 2023 04:06:47 -0800) it happened John Larkin snipped-for-privacy@highlandSNIPMEtechnology.com wrote in snipped-for-privacy@4ax.com:
I wonder, procesor in FPGA is common, many have gone that way:
Have not tried it myself...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.