Are all the timers sharing an interrupt to the processor ?

MK

michaelkellett said:

Are all the timers sharing an interrupt to the processor ?

All timers implemented on the same HET peripheral: yes. The same interrupt vector is called for each of the 8 timers. Only difference is the index that the HET sets in the register. Most Herculeses have multiple HET units, each with their own interrupt.

Side note: only the interrupt firing is deterministic. That happens in the HET. 
The interrupt handling happens in the main core, and that has to deal with queued interrupts, priorities, being interrupted by other interrupts, etc ... That is not a deterministic flow anymore.

If you want to control IO pins deterministicly, don't do it in an interrupt handler. You 'll have to do that in your little HET program. A decent part of the Hercules IO pins are HET controllable, for reading or writing, in a deterministic way. But only if you set or read their state in the HET microcode.

A few examples that others made inside HET:

• UART peripheral
• I2C slave
• blinky
• sinus, triangle, square wave generator
  
• counter
• phase detector
• (stepper) motor pulse train generator, with ramp-up and -down
  
• 3-phase generator for inverters
• rotary knob decoder
• complete production belt control with belt speed detection and feedback, motor control, programmable strategies for different scenarios.
  

An example that I made (I blew my own brain when that worked):

• a complimentary PWM signal generator with programmable deadband, frequency and duty cycle - to drive a half-bridge. (I wrote a blog for that but can't find it back :) ).

I get the feeling the RP2040 might have been just an experiment to trial tech to maybe put into a larger processor : ) Especially because it's lacking a few things that microcontrollers ordinarily have.

Great idea with the TPM, the RP2040 successor also needs such tech (or at least some form of secure storage and unique ID at a minimum for that). 

I wonder (since the RP2040 is supposed to be so small, and using a modern process), if they could figure a way to have a huge amount of them, to allow assigning what would normally be threads on a single core, to lots of them (a bit like XMOS). Or at least some other form of parallel processing would be interesting, e.g. GPU-like cores..

Ok, so the HET is a kind of low spec PRU. Motorola (when they still were Motorola)  had a fancy timer that could do that sort of thing. Like all such efforts I can think of (including Pi 2040 GPIO and PRU) it suffered from poor documentation and great difficulty of use. Is the HET well documented ?

It's a difficult thing to get right.

MK

As for me, I would love Raspberry Pi 5 to be conveniently adapted to an entry-level audiophiles' friendly fanless media center capable of serving music from high-resolution FLAC files and 4K movies from MKV files on a network drive. It should be Wi-Fi as well as Ethernet connectable, and it should be operated with a phone/tablet application through Bluetooth. Ideally, It should operate TWO video cards - one for external display (to serve movies) and one for "internal" display (to show "now playing" data).

Consequently - it should deliver at least stereophonic output audio through an appropriate DAC as well as HDMI / DP video.

I understand DAC is an extension card purchased separately, but all the other components should be on board.

Simply speaking - the target is Rasberry 5 as a full-featured fanless (noiseless) media-center suitable both for serious listening to music and for watching movies. Not necessarily listening to music should be linked to the necessity of turning on a TV set, so secondary video output for a handy "now-playing" in-build screen would be appropriate.

As for now, there is no easy good solution, or I am not aware of it.

If you already know such a project - I would love to know it too!

ziggi said:

I understand DAC is an extension card purchased separately

The DAC is on-board for current Pi versions.

Available for purchase at close to list price.

Is this high-quality DAC applicable for hi-res 24/96 FLAC processing?

I mean quality like

HiFiBerry DAC2 HD

ziggi said:

I understand DAC is an extension card purchased separately, but all the other components should be on board.

Yeah, I kinda agree there could be better audio processing with the Pi. 

I guess the USB port is simply so extensible that it's somewhat overlooked.

There've been a lot of DAC add-on boards so far. Perhaps there simply hasn't been a very popular demonstration of why it's important? Like project wise. May be an opportunity there.

vrs1717 said:

Available for purchase at close to list price

I mean, we know it's true, but did you have to call everyone out on it?