<snip>
Got a 3us interrupt servicing an ADC, assembler of course. Only a
40MIPs processor and the 3us has a scattering of 3.025us and 2.975us intervals as needed to maintain synchronisation to a remote transmitter with no possibility of a common clock.Works fine at Gas Mark 4, aka 180'C.
On a sunny day (Sat, 14 Jan 2023 10:50:30 -0800) it happened John Larkin snipped-for-privacy@highlandSNIPMEtechnology.com wrote in snipped-for-privacy@4ax.com:
Yea, OK, The thing about vcgencmd is that you can use it from a script or program to for example reduce priority or temporarily slow down or halt some not essential code to prevent the Pi lowering the clock on your important things, give alarms, etc etc. Change processor use too.
On a sunny day (Sat, 14 Jan 2023 10:21:59 -0800) it happened John Larkin snipped-for-privacy@highlandSNIPMEtechnology.com wrote in snipped-for-privacy@4ax.com:
That is silly
And if you are talking Linux or other multi-taskers there is a lot more involved.
I was amazed about the other thread about logic analyzers. Why did I never need one for my code / projects? All you need is a scope... especially an analog one, digital ones are liars!
If you have no clue then having a hall full of equipment does not give you one!
mm did I use a scope for any of this?
In the past coding ISRs in assembly was the way to go, but the complexity of current processors (cache, pipelining) makes it hard to beat a _good_ compiler.
The main principle still is to minimize the number of registers saved at interrupt entry (and restored at exit).On a primitive processor only the processor status word and program counter needs to be saved (and restored). Additional registers may need to be saved(restored if the ISR uses them.
If the processor has separate FP registers and/or separate FP status words, avoid using FP registers in ISRs.
Some compilers may have "interrupt" keywords or similar extensions and the compiler knows which registers need to be saved in the ISR. To help the compiler, include all functions that are called by the ISR in the same module(preferably in-lined) prior to the ISR, so that the compiler knows what needs to be saved. Do not call external library routines from ISR, since the compiler doesn't know which registers need to be saved and saves all.
The guardians of big iron won't let you poke around its internals with a scope although I do recall them having an AM radio on the console so that you could listen in on the RFI to see if it was stuck in a loop.
I prefer to use RDTSC for my Intel timings anyway.
On many of the modern CPUs there is a freerunning 64 bit counter clocked at once per cycle. Intel deprecates using it for such purposes but I have never found it a problem provided that you bracket it before and after with CPUID to force all the pipelines into an empty state.
The equivalent DWT_CYCCNT on the Arm CPUs that support it is described here:
If I'm really serious about finding out why something is unusually slow I run a dangerous system level driver that allows me full access to the model specific registers to monitor cache misses and pipeline stalls.
One of my recent test shows that in the MS SSE2 library whilst sin and cos are both properly rounded to acceptable machine precision tolerance the results from the combined sincos have worst case behaviour 4x eps.
This makes answers change when the optimisation level is increased to maximum in code which uses both sin(x) and cos(x) and mine does.
søndag den 15. januar 2023 kl. 06.10.24 UTC+1 skrev snipped-for-privacy@downunder.com:
cortex-m automatically stack the registers needed to call a regular C function and if it has an FPU it supports "lazy stacking" which means it keeps track of whether the FPU is used and only stack/un-stack them when they are used
it also knows that if another interrupt is pending at ISR exit is doesn't need to to un-stack/stack before calling the other interrupt
How many registers does it stack automatically? I knew the HLL nonsense would catch up with CPU design eventually. Good CPU design still means load/store machines, stacking *nothing* at IRQ, just saving PC and CCR to special purpose regs which can be stacked as needed by the IRQ routine, along with registers to be used in it. Memory accesses are the bottleneck, and with HLL code being bloated as it is chances are some cache will have to be flushed to make room for stacking. Some *really* well designed for control applications processors allow you to lock a part of the cache but I doubt ARM have that, they seem to have gone the way "make programming a two click job" to target a wider audience.
10 us for a 100+ MHz CPU should be doable; I don't know about ARM though, they keep on surprising me with this or that nonsense. (never used one, just by chance stumbling on that sort of thing). What you might need to consider is that on modern day CPUs you don't have the nice prioritized IRQ scheme you must be used to from the CPU32; once in an interrupt you are just masked for all interrupts, they have some priority resolver which only resolves which interrupt will come next *after* you get unmasked. Some I have used have a second, higher priority IRQ (like the 6809 FIRQ) but on the core I have used they differ from the 6809-s FIRQ in that the errata sheet says they don't work. On load/store machines latency should be less of an issue for the jitter you will get as long as you don't do division in your code to be interrupted. Make sure you look into the FPU you'd consider deep enough, none will get you your 32.32 bit accuracy. 64 bit FP numbers have a 52 or so (can't remember exactly now) mantissa, the rest goes on the exponent. I have found 32 bit FP numbers convenient to store some constants (on the core I use the load is 1 cycle, expanding automatically to 64 bit), did not find any other use for those.
Finally, to give you some numbers :). Back during the 80-s I wrote a floppy disk controller for the 765 on a 1 MHz 6809. It had about
10 us per byte IIRC; doing IRQ was out of question. But the 6809 had a "sync" opcode, if IRQs were masked it would stop and wait for an IRQ; and would just resume execution once the line was pulled. This worked for the fastest of floppies (5" HD), so perhaps you can use a 6809 :D. (I may have one or two somewhere here, 2 MHz ones at that - in DIP40....).====================================================== Dimiter Popoff, TGI
I was thinking about doing closed-loop control, switching power supplies and dummy loads and such, using one core of an RP2040 instead of an FPGA. That would be coded hard-metal, no OS or RTOS.
I guess I don't really need interrupts. I could run a single persistant loop that waits on a timer until it's time to compute again, to run at for instance 100 KHz. If execution time is reasonably constant, it could just loop as fast as it can; even simpler. I like that one.
I've never used a logic analyzer; they look hard to connect, especially into a single-chip uP. But color digital scopes rock.
My usual scope is a 500 MHz 4-channel Rigol. And an old Tek 11802 sampler for the fast stuff and TDR. I have a 40 GHz plugin.
I'll be doing single-function bare-metal control, like a power supply for example, on a dedicated CPU core. The only interrupt will be a periodic timer, or maybe an ADC that digitizes a few channels and then interrupts.
I'd like the power supply to be a mosfet half-bridge and an ADC to digitize output voltage and current, and code to close the voltage and current limit loops. I could use a uP timer to make the PWM into the half-bridge. Possibly go full-bridge and have a bipolar supply.
I'm just considering new product possibilities now; none of this may ever happen. Raspberry Pi Pico is sort of a solution looking for a problem, bottom-up design.
The RP2040 doesn't have an FPU, and its semi-hardware FP calls look too slow to run a decent control loop. The barbaric way to do this is with signed 32-bit ints where the LSB is 1 microvolt.
I wrote an RTOS for the MC6800! Longhand in Juneau Alaska! That was fairly awful. I mean the RTOS; Juneau was great. The 6800 wouldn't even push the index onto the stack.
I did some 6802 and 6803 poducts too, but skipped 6809 and went to
68K. You can still buy 68332's !!!!!!
This is a very common approach, being pioneered by Bell Labs when designing the first digital telephone switch, the 1ESS:
.
The approach endures in such things as missile autopilots, but always with some way to gracefully handle when the control code occasionally runs too long and isn't done in time for the next frame to start.
Typically, the frames are started by arrival of a clock interrupt, and there are no data interrupts.
The problem being that interrupts (including the hardware to monitor
10,000 lines) are expensive in both overhead and hardware cost, and so are not worthwhile when doing something like scanning 10,000 phone lines for new activity (like a phone having been picked up) where individual lines change only rarely.Logic analyzers are usefully for a board full of logic, but not for things like power supplies. One does need to design the board to accept the test leads. This gets interesting with GHz clocks.
Joe Gwinn
On a sunny day (Sun, 15 Jan 2023 08:00:39 -0800) it happened John Larkin snipped-for-privacy@highlandSNIPMEtechnology.com wrote in snipped-for-privacy@4ax.com:
Power supplies work great for me with a Microchip PIC 18F14K22 It has all the PWM, 2 hardware comparators, voltage reference, multi channel ADC, and is fast enough to do cycle by cycle current limiting, one of its hardware comparators is hardwired to the PMW generator and resets it in a few ns if needed.
Yes,
I started looking into building one once, but for showing the i2c bytes? The software to create i2c I use is so good and has been running for decades that it is much easier to look at the code... And the scope for the waveforms, same for the other serial protocols.
If I wanted I could buy a Rigol or Tek... Most gigle-Hertz stuff I play with is done via a RTL_SDR stick with converter for 2.4 GHz or 10 GHz (satellite).
Now I want a 1 TB (1000 GB) USB stick, found a cheap one for 75 USD online here... Tomshardware just did a test:
I was thinking of an endless loop that just runs compute bound as hard as it can. The "next frame" is the top of the loop. The control loop time base is whatever the average loop execution time is.
As you say, no interrupt overhead.
Do you know whether it is documented enough to allow you to throw away all the code that comes with it and write your own bare-metal one? At 100 kHz you'd likely need to do so.
Nothing I'd call barbaric about that, you have the 32 bits so why not use them.
My first board was a 6809 one, but I had no terminal to talk to it so in order to make one I made a clone of Motorola's D5 kit (clone meaning the debug monitor written by Herve Tireford worked on it, its source was public). Then I designed a terminal board, 6800 based, programmed it on an Exorciser clone I had access to and debugged the code with the 6800 on the board being emulated by the kit, a 40 pin dip right from the kit's CPU via a flat cable... (may be there were buffers to drive the cable, don't remember) So I am also used to push the X register via a swi call, doing tsx etc., taught us to be grateful for what 68k gave us.
Some years (10, may be some more) I tamed the mcf52211 in my working environment, still available, too. You will feel quite familiar with it, though it will probably be eol-ed soon. At 66 MHz you could do a lot, the ADC is true 12 bit, it has PWM-s (clocked at 33 MHz though, that resolution can be quite an enemy, especially at higher PWM frequencies). I have done some auxiliary HV sources with it for our netMCA, but they don't work at 100 kHz (IIRC something like 5) and the stepwise change in pulse width was still something I had to deal with. Probably not a great idea to start a new product with it though, only if you feel it will be best for you to write it in 68k assembler.
To be more specific, the frames effectively run at interrupt priority, triggered by a timer interrupt, but we also run various background tasks at user level utilizing whatever CPU is left over, if any. The sample rate is set by controller dynamics, and going faster does not help. Especially if FFTs are being performed over a moving window of samples.
Joe Gwinn
eight and usually in parallel with the fetch of the ISR address and instructions so with overhead 12 cycles from interrupt to first instruction of the ISR is executed
"good" depending of what your objective is, automatic stacking save code space and the time it takes to fetch that code
we are talking cortex-m with no real caches. The pico has a special cache to run code directly from slow external serial flash resonable speed, but you can tell the compiler to copy and keep a function in ram
not on a cortex-m. The interrupt controller has programmable priority for each interrupt. Higher priority interrupts interrupt lower priority interrupts. Another sub priority determines which interrupt to run first if two or more interrupts off the same priority is pending
That's the thing to do: run the fast control loop on one CPU in ram and let the other CPU do the slow stuff and thrash cache.
No, just one control loop runing full-blast on one of the CPUs, running in sram, and no interrupts.
I don't think a power supply needs FFTS. Maybe a little lowpass filtering, but that's just a few lines of code. Or one line.
The actual control loop might be a page of code.
Probably so. I was thinking radars and missile autopilots.
Generally, the FFTs (or anything lengthy) are not done at interrupt level. The interrupt code grabs and stores the data in ram, sets a flag to release the user level code doing the signal processing, and then exits the interrupt. Whereupon the user level code commences running the signal processing code. Otherwise, the system could not respond to important but rare interrupts.
Could be. What I've seen the power-supply folk do is to use SPICE to tweak the PS's control law, which is generally implemented in a FIR filter. IIR filters are feared because they can become unstable, especially in the somewhat wild environment of a power supply
Joe Gwinn.
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.