What would you look forward to being on the Raspberry Pi 5 ?

• Subsystem that supports deterministic timing (like RP2040 Pio or BB Pru)
• Less power, less heat
• Support for external antennas for the wireless functions
• TPM 2 hardware module and drivers for it in the software releases

You just beat me to it, a PRU !!

(and decent high speed drivers to support it !).

The RP2040 state machine GPIO is a possibility but a PRU would be better.

MK

Pi 5 with integrated RP2040?

Not what I would really like, the RP2040 will become a restirction.

The 2040 GPIO system tightly coupled to the Pi5 cores would be much better.

A clone of the TI PRU would be much better still, but the RPi people are much more likely to be able to do the 2040 IO system.

Another reasonable thing would be any kind of really fast bi-directional pipe that could link to an FPGA.

My problem with the Pi, and pretty much every single board Linux or Windows capable computer is that while you have a really fast processor (or 4 of them) there is no way simple to get data in and out at high speed.

So while the Pi could easily crunch the data from a 100MHz ADC there isn't a simple way to get it into the processor.

MK

For instance. 

In my wildest dreams, the Raspberry org would license the PIO ip to the processor manufacturer. They would then put it on silicon. With DMA and interrupt support please .

That would do !

MK

Please, not the cheesy interprets as in the Arduino. LOL . To work properly interrupts must return something, not a freakn side-effect.

Perhaps it's time for me to go home for tea, but I seem to be missing something.

How does an interrupt return anything ?

The processor is trundling along, doing stuff and then something happens and it gets interrupted. The main task wasn't expecting it so to who/what could the interrupt return something.

MK

Perhaps it's time for me to go home for tea, but I seem to be missing something.

How does an interrupt return anything ?

The processor is trundling along, doing stuff and then something happens and it gets interrupted. The main task wasn't expecting it so to who/what could the interrupt return something.

MK

michaelkellett said:

The processor is trundling along, doing stuff and then something happens and it gets interrupted. The main task wasn't expecting it so to who/what could the interrupt return something.

Yes. With the TI high-end timer, you get the program counter of the little HET unit's machine code as only indication. Here's a blog where I explained it. 

This is a program where one HET unit can support 8 independent timers, each with an interrupt when the time expires.

; this program only generates interrupts. No pin required
DUMMY_PIN .equ 0

; interrupt and count attributes are set on the host program
L00 CNT { next=L01,reg=A,comp=EQ,irq=OFF,control=ON,max=0};
L01 CNT { next=L02,reg=A,comp=EQ,irq=OFF,control=ON,max=0};
L02 CNT { next=L03,reg=A,comp=EQ,irq=OFF,control=ON,max=0};
L03 CNT { next=L04,reg=A,comp=EQ,irq=OFF,control=ON,max=0};
L04 CNT { next=L05,reg=A,comp=EQ,irq=OFF,control=ON,max=0};
L05 CNT { next=L06,reg=A,comp=EQ,irq=OFF,control=ON,max=0};
L06 CNT { next=L07,reg=A,comp=EQ,irq=OFF,control=ON,max=0};
L07 CNT { next=L00,reg=A,comp=EQ,irq=OFF,control=ON,max=0};

Each line of code represents an isolated timer. Note that when this microcode gets loaded, the IRQs are OFF. When I want to use one of the timers, I set its count, and enable its interrupt, from the main core's C program. 

In the C event handler, I know which of the timers executed, because the program counter is available (the HAL gets it out of the registers and presents it as a parameter)

void hetNotification(hetBASE_t *het, uint32 offset)
{
  uint32_t index = offset - 1;
  if (index >= HUI_NUM_COUNTERS) {  // invalid offset trap, expecting to be not higher than number of available virtual counters
    while(1);
  }

  // ...

}

The interrupt code runs on the main core, not on the timer unit. That one (as michaelkellett calls it) trundles along.

Here's the procedure to enable one of the timers:

void huiSetTimeout(uint32_t index, uint32_t us) {
  if (index >= HUI_NUM_COUNTERS) {
    while(1); // invalid index trap, should be lower as the number of available virtual counters
  }

  // interrupt off
  hetRAM1->Instruction[index].Program &= 0xFFFE;

  if (us > 0x1FFFFFE) {
    while(1); // invalid count trap, value has to fit in a 25 bit field
  }

  // reset active count
  hetRAM1->Instruction[index].Data = 0;

  // set us
  hetRAM1->Instruction[index].Control = us;

  // enable interrupt if timeout > 0
  if (us) {
    hetRAM1->Instruction[index].Program |= 0x0001;
  }
}

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 :) ).

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