Teensy 4.0 challenges - I am not asking you to do this work about o_c HOT 8 OPEN

Hi, Paul here... the guy behind Teensy.

Reaching out to ask if there is interest in making a new version of Ornament and Crime using Teensy 4.1. Since it has 2 SPI ports easily accessible, this could solve the problem of sharing SPI between the DAC and display. Of course it would mean a new PCB layout and firmware work. I can try to assist... But I'm not a musician or synth expert, so I really can't do everything.

I can help with places where Teensy 4 core library might need improvement. I can also help with issues like DMA details on Teensy 4.1.

While there's never any long-term guarantee about hardware supply, today the clear situation is plentiful supply of the newer Teensy 4.0 and 4.1 boards, and I'm sad to say Teensy 3.2 will soon be forever discontinued. It really breaks my heart to answer at least a couple emails every week from people wanting to build Ornament and Crime, but we don't have any Teensy 3.2 in stock. My hope is to help migrate to either Teensy 4.0 or Teensy 4.1.

New circuit board and firmware is of course more work than just putting a Teensy 4.0 into the socket meant for Teensy 3.2 and making only new firmware. But if there is interest, moving to Teensy 4.1 would allow dedicated SPI bandwidth for DAC and display, hopefully making the firmware side easier and opening up the possibility for enough bandwidth on the DAC to enable more applications.

from o_c.

...and since we're necrobumping: I did eventually push that refactoring to a suitably named public branch and (as my response #119 mentions) wrote a basic driver framework for T4.0.

from o_c.

So I don't remember the pinout specifics, but half-remember it being feasible at least.

Assuming that's the case the most 3.2-specific part is that the firmware works around (against?) the Teensy libraries to use the SPI/DMA, so that part probably needs rewriting. The DAC and screen sharing the SPI is a hard limitation and the timing fairly critical, and this also defines the timebase for the rest of the code. So the limit of 16.6-ish KHz (*) will probably remain even with more horsepower. I made a STM32F4 daughterboard that fits on the o_C but that suffered the same fate - lots of cycles + memory but no place to go. YMMV.

Other quirky parts might be the EEPROM use, and the ADC "stuff" may not map 1:1 either. IIRC the ADCs on the 4.0 are even worse than the current ones -- but I don’t really follow Teensy and don’t have one lying around (else I'd probably have ported it anyway).

So maybe the tl;dr is "you'll probably have to rewrite most of the driver bits, which may be overly tightly coupled with the rest of the code".

Also... the current ad hoc framework and apps weren’t really designed to scale, so the foundation for expansion is a bit wobbly. At least that’s my regretrospective view, and is perhaps a secondary issue (that I was working on at some point...)

(*) There’s some leeway there by bumping the SPI speed and/or transferring smaller chunks to the display, but we’re already way out of spec for the OLED controller.

from o_c.

Also... the current ad hoc framework and apps weren’t really designed to scale, so the foundation for expansion is a bit wobbly. At least that’s my regretrospective view, and is perhaps a secondary issue (that I was working on at some point...)

So on second thought, and a quick browse of what I was doing two years ago...
What I did was refactor the interface to the apps entirely so they are isolated from the actual ADC/DAC/etc. details (the way it "should be"). So porting to a different platform becomes way easier. The cost (aside from some runtime overhead) is that some corner cases of the existing apps require significant reworking to unlearn direct access, which is probably where it stalled.

Apropos -- the references app with the frequency counter may also be overly 3.2-specific.

from o_c.

Thank you so much for taking the time to discuss this in-depth! I'll definitely look at the refactor branch, if it's up on Github at the moment. As you say, the SPI issue is pretty limiting, but I'm going to give optimizing that a try.
Again, many thanks.

from o_c.

Max (mxmxmx) and I were investigating porting to Teensy 4.0 in 2019, I think - Max had a few pre-production T4.0s and I bought a few just after they were released. It turned out that there was a problem with the SPI bus, at least at that time. The SPI hardware on the T4 chip is actually slower than on the MPU used by the T3.2, and as a result the display and DAC weren't working correctly. If the display was disabled, then the code ran OK, iirc, but that's not much use. We were intending to wait for better SPI drivers for the T4, but decided it was better to work on a successor to O&C. We got as far as hardware design and proof-of-concept for that, then COVID-19 hit and the wheels fell off. We may get back to it at some stage... I think that a Teensy 4.0 port which worked as a "brain transplant" for O&C is still a worthwhile project, if the SPI bus performance issues have or can be solved. I' haven't been watching the teensy forums for the last year, so not sure what has been going on there wrt this issue. Note the SPI i=on the T4 is fine for all reasonable purposes, it's just that the O&C design pushed the SPI bus way beyond reasonable in order to get decent DAC sample rates, due to the single bus architecture of the O&C hardware design (given the the O&C firmware took that hardware design into places it was never intended to go).

from o_c.

There was also some work done for a 3.6 upgrade but I don't recall how far that got (see some discussions here).

The refactoring branch -- excitingly named wip/io -- currently lives in a private repo. It's a) in need of rebasing and b) I'm not sure what works and 3) there's still a bunch of work left to make it release-ready, sooooo... I'm not super enthusiastic about making it public. OTOH it's not exactly getting better with age 😛

Similarly to what Tim mentions I found new platforms without baggage more interesting...

from o_c.

Hey Paul,

thanks for reaching out (and for the work on Teensy)!
I was always surprised by the longevity of o_C so it's kind of surreal that there is still so much demand... sorry for dragging you into it I guess? :)

There's some ongoing work by @djphazer to port the Hemisphere app ecosystem using the code I put together for Teensy 4.0 but yes, a new board and upgrading to Teensy 4.1 would open things up and solve the underlying bottleneck (not to mention the SD card).

In general I'd be game for it but also think a lot of the "hard" work might be conceptual things like a UI and/or app concept that scales better. Over the years I've built a few "beyond o_C" prototypes -- admittedly not using anything Teensy -- but they always seem to peter out after board bring-up and writing drivers; perhaps because I don't have a good "what's it for?" answer 😛

For o_C we had the advantage of things just happening so I'm not sure that's repeatable recipe :)

from o_c.