Return of "Multiple interrupt SPI + hardware serials crash"

Created Thu, 15 Jan 2015 08:02:56 +0000 by rasmadrak

rasmadrak

Thu, 15 Jan 2015 08:02:56 +0000

Hi there!

It's been a while since my last post but my pinball machine is still under construction. I've connected my DMD display to DPSI1 and SD-card reader to DSPI0. They work great when doing regular SPI but is quite inefficient since most of the time the main loop is just waiting (I get 50+ fps, but still). I've been wrestling with squeezing out performance out of the MAX32 card only to find that I'm stuck at the point where I left the subject two years ago.

That is - How can I use interrupt driven SPI-transfers on DSPI0 and DSPI1 while still using hardware serial ports Serial1, Serial2 and Serial3?

The last thing I heard about this, and still today, is that ISR vectors where being used conflictingly between SPI/UART and could somehow be rearranged. The other thing was requiring a total rewrite of the MPIDE/ChipKit core. I'm not requiring a lot of speed for the serial ports, so I might get away with using software serial ports instead, but I'm wondering if there's a fix for this yet?

Hailing Majenko and Gene Apperson...? :)

P.s For those interested, my building blog is available at: [url]http://poormanspinball.blogspot.com[/url]

majenko

Thu, 15 Jan 2015 10:41:07 +0000

Yeah, the whole shared vector thing is a right royal pain in the sphincter when you're working in MV mode.

What is needed is a way to install multiple interrupt handlers into the same vector, but distinguish them by IRQ. Something like an expansion of setIntVector(vec, func) as setIntVector(vec, irq, func) which then installs a stub function that checks the IRQ and calls a different registered function for each one.

A different method might be to switch to SV mode instead and just register the functions against the IRQ instead of the vector. Then the one ISR function in the core looks up the callback in a simple array of IRQs and calls that function. That method might be cleaner to implement than trying to work with bending MV mode and still accounting for the MZ that has no vector sharing.

However, that would be a complete re-write of the whole interrupt system, and would break untold libraries that work with interrupts. It might also reduce the responsiveness of interrupts as the lookup takes more cycles.

majenko

Thu, 15 Jan 2015 11:06:04 +0000

BY the way, I have just kicked off a discussion on the steerage group about the benefits / drawbacks of switching the core to SV mode. We'll see what comes of it.