Teensy 3.1/3.2 unavailable - port to 4.0

[ChromeFoundry]

Now that everyone is price gouging the old Teensy 3.2 for over $120 USD... is there any chance of porting this code to the Teensy 4.0? Your awesome hack is the only solution I've found for filling up landfills with obsolete Cricut Minis.

[seishuku]

Funny you should open this issue... I was actually just on the PJRC site looking at a 4.0.
I needed to use my own mini and discovered that the USB port fell off the 3.2 I was using and had to do some repairs, thankfully I had a few 3.2's kicking around.

I don't think it would be too big of a job to do this, I just need a 4.0 and some time.

[ChromeFoundry]

I am more than happy to offer my assistance in porting this over to the 4.x. I haven't written code in C in a lot of years, so this would be a fun project to jump into. The Teensy platform is new territory for me as well, but I believe this is effort is very worth the time. Thanks for the work you have done on this to date...Bravo.

[seishuku]

In hindsight, I probably should have just done this whole project in the Arduino ecosystem instead of bare metal, it would have made porting easier... Oh well.
Actually, what I really should have done was look into just reprogramming the original PIC MCU, it shouldn't have been that hard to do (there are already ICP headers on the main board), but I personally don't care for PICs and don't have any tools for them.

But yeah, feel free to try porting it yourself.

If I have some free time this weekend, I'll take a look at the SDK for the 4.x's MCU and see about tossing something together that could be used for testing maybe?

[ChromeFoundry]

Do you see any reason that recompiling for Teensy LC would not work? It appears they are pin compatible with the 3.1/3.2. I have not looked closes enough at your clocking and handling of the buffers to determine if this is option for least resistance.

[seishuku]

I do drive the PID loop for the motor control at a pretty high rate, but it's possible the LC can do it... Though with the USB serial interface and everything else, I have a feeling the 8K of RAM it has will disappear fast.

It wouldn't be a simple recompile though, while all the small form Teensy share similar pinouts, the MCU hardware registers are all different... So the GPIO ports/pin would have to be remapped and the hardware PWM/timers would need to be reconfigured to match the MCU it's running on.

[ChromeFoundry]

I'm getting the impression that this is quickly getting far outside of my league of expertise. I have a Teensy 4.0 and a Teensy LC being delivered soon. I am more than happy to test any code changes you are able to support either of these devices. It looks like the LC will soon become unavailable as well, so the 4.x is probably a better target if you choose to continue supporting this effort. The more I learn about the effort you put into this, the more I am in awe of your knowledge.

[seishuku]

Yea, I was wondering that about the LC... I'm guessing it's probably the Freescale Kinetis MCUs that they used on those boards that are being discontinued, so it gets harder to find them. Plus the whole MCU price gouging in general.

I did start a new branch for the Teensy 4, got a little bit kind of stubbed in... I guess I should probably get a Teensy 4 my self, it won't be long before I'll need to test on actual hardware.

Looking at the SDK, it seems to be fairly similar to the old Kinetis K20 MCU that the Teensy 3.2 used, but the general GPIO grouping and pin mux control is a bit weird, so I'll have to figure that out.

[tgsavs69]

Hello everyone!

Are there any updates regarding porting to 4.0? I would like to revive my old Cricut Mini and it seems teensy 3.2 is nowhere to be found anymore.

I will try to use a RP2040 to replace the Teensy 3.2 Do you think there are any incompatibilities? (not enough ram/flash, etc).

Best regards

[seishuku]

I haven't had time to work on it any more than what's in the 4.0 branch, unfortunately.
RP2040 should be more than enough though, might even be nice to move the PID and motor control onto the second core and leave the main core for input processing.