hi, great question. we have to start with something and while the RP2350 is not going to beat a 600mhz m7 it is much less expensive, fast to get, has lots of nifty support libraries available, and will definitely do better than the teensy 3.2 which many folks loved so much (and was discontinued during the chip shortage). this is also a great time to add things that we always wanted in the teensy: SWD debug, built in 8 MB storage, lipoly battery charging, open source bootloader, open hardware design. stuff like CAN is supported via PIO (https://github.com/KevinOConnor/can2040), as is USB host on any two adjacent pins. M33 has FPU, and the dormant/RTC mode for the RP2350 is 10uA (see https://www.tomshardware.com/raspberry-pi/raspberry-pi-pico/...). other 'teensiriffic' things like NeoPixel DMA support is well supported by PIO on the RP2350. as well as I2S audio.

as for the bootloader chip: we don't want to trade one closed-single-source component for another. if we're going to make something it should be fully open source as much as we can!

finally, for teensyduino libraries that you love: there's no reason they cant be ported (we did an audio port for the samd51) - which specific library are you referring to?

Thanks for the answer. I know many are scared off by the closed bootloader of the teensy (though I feel it's a fair thing to do). The lack of on-chip debugging is another shortcoming the Teensys have.

I've been working on an audio project recently, and the the ease of use and feature set that TeensyAudio has is incredible.

Teensy 4 does currently fill a pretty unique niche in terms of processing power though. There isn't much like it outside of professional eval boards.

> I know many are scared off by the closed bootloader of the teensy (though I feel it's a fair thing to do).

Why is it a fair thing to do?

It supports the developer by preventing blatant ripoffs of the Teensy.

Paul is one guy, and has put in a ton of effort writing high quality libraries for it. Most or all of them are open source. The main MCU is a commodity item. Only the bootloader chip is closed source.

If you want to rip off the Teensy, you can use the same MCU but you'll need to come up with your own bootloading process (Adafruit could do this if they wanted to). It wouldn't be that difficult but is enough of a barrier to stop casual cloning. Seeing as how Amazon and Aliexpress are filled with cheap Arduino clones but not Teensys, it seems to have gone well so far. Nobody wants to be undercut so easily by someone who has no intention of contributing back.

What's so special about the Teensy bootloader? If it's the only closed source component, why not just replace the bootloader with an open source one?

Supporting free and open source technology means supporting whoever can get it in as many hands as possible as cheaply as possible while paying your employees fairly. Adafruit gets this.

Making anything proprietary at this point for use in DIY software or hardware projects just makes me roll my eyes and hold my money for the day the open clones come. I have been saddened by dead open hardware projects because old versions of Teensy they were built around are no longer produced.

I will never buy a Teensy, but I look forward to buying the Freensy.

Sparkfun blew it by making the Teensy partially closed and so Teensy will be irrelevant. LibreOffice, OpenTofu, MariaDB etc. The most open solution always wins in the end. It is why I buy Prusa over Bambu, and why I pick Adafruit over Sparkfun.

My own companies likewise freely OSI license everything we do to the public no matter what the profit minded folks in our universe have to say. I -love- when people compete with us using our own work. If you can make a budget version of what we invent for people that cannot afford a bit extra to support us, wonderful. That is success for us as a creators that want to maximize impact.

If you cannot afford our prices, by all means buy from a competitor and contribute to the ecosystem that our customers benefit from anyway. That is why we will never spend a second of our engineering time creating or promoting proprietary technology because all the skills we have are because others shared their work with us.

I honestly take a lot of inspiration from companies like Adafruit as a leader of my own orgs.

> Teensy 4 does currently fill a pretty unique niche in terms of processing power though. There isn't much like it outside of professional eval boards.

If I want that much performance, maybe I should think about a Pocketbeagle 2. And almost every embedded MCU these days is sprouting an on-chip "AI" extension ;).

I think this is a bit tone-deaf the reason why the teensy is so desirable is because of its raw power in such a neat package. The RP2350 is great but if I wanted that I would just purchase it rather than the Freensy

Right, but you're not really competing on processor speed. You're competing on maturity of peripherals where the RP doesn't really match up PIO or not.

Edit: I see you're comparing it to the 3.2 but I suspect most folks are going to be comparing your offering to the 4.x.

Yeah - I don't really consider this comparable for my uses which rely heavily on the DSP and processing power of the Teensy itself either.

Drama and whatnot aside I'm not really sure why anyone would buy the (considerably more expensive) Teensy over something RP based if RP was suitable for their needs already.

Interestingly despite being a Teensy fan I have found myself reaching more towards the RP when I can because I can't stand the Arduino API and much prefer the RP SDK. I do use Teensy without Teensyduino (Makefile based) and also a bit of the CMSIS-DSP stuff directly - but it's kinda clunky IMO.

I've been interested to hear more about use cases for these "hybrid" MCUs, can you share a bit about why you chose that over something like a Cortex-A running linux, or an SoC with -A and -M cores?

It's a good question - unfortunately I don't really have a good answer...

Almost all of my embedded activities are for a my own hobby purposes, and I just like the ability to go 'as low as I can' with projects on MCUs. It's nice to be able to use the device's peripherals as much as possible (hardware DSP etc) and I'm not confident in how I'd do that on a Linux based system. I'm in to building my own ham radio Software Defined receivers and it's nice to keep it completely real time.

If I were to be doing this stuff professionally (and I am very close to people who do at work) then yeah I'd probably be using Zephyr or something.

Ah interesting! I work on (very expensive) SDRs and we make pretty heavy use of Xilinx Zynq Ultrascale SoCs. They combine Cortex-A, Cortex-R, and FPGA fabric all in one package, with some fancy interconnects. So you can handle the hard realtime stuff on an RTOS or in the FPGA, then send the data over to the application processor with a hard float ALU to crunch some numbers (or build some kind of dsp IP into the FPGA, idk much about that side of it).

I've also seen some cool stuff with the BeagleBone products, which have a few TI custom architecture DSPs and "realtime units" which you can communicate with via Linux.

But yeah, I can certainly see how just doing it all on a super fast MCU could be easier and cheaper without the backing of commercial enterprises.

I've always thought it would be cool to design a "poor man's zynq" hat for a SBC. Stick a RP3050 and a Lattice FPGA on there and set up some SPI / UART connections.

it will have benefits over the 4.x - we can always spin up a version with the iMX chipset (we have a metro board with the little sister chip, iMX RT1011 already in stock) - tbh if we did something with the iMX RT106x we'd probably start with a Metro (Arduino-shield compatible) or Feather board since that's a super-popular pinout.

either way, more hardware is better and we don't want to just give people the same-old-same-old... as we mentioned there's lots of things that we can add to make the board useful to people: SWD, USB C, Lipoly batt, onboard storage, neopixel LED, etc). what peripheral/library are you specifically concerned about?

If you replace the Teensy 4.x it would have to be something very close to the same pinout, foot print, cost and features otherwise it would just be a new product. Ideally you would find a way to source the Teensy directly bypassing Sparkfun.

sparkfun is the single source supplier (and now maker of the product).

Spinning an IMXRT1062/IMXRT1064 design sans the terrible Teensy bootloader should take a day or two at most.

These chips have perfectly-fine ROM USB bootloaders and SWD, don't ruin them by adding extra garbage.

The layout of the Teensy 4.x was challenging as I recall with the speeds involved. But maybe you are a demigod of compact high clock designs.

Nothing on that board is remotely high speed or challenging.

USB HS on a board that small is a non issue: it's one measly differential pair with easy impedance requirements.

Go ahead and make one then, we'll be thankful.

Yes, obviously, but they don't make the chips, so can't you just source the exact same chip, make thing pin compatible and call it a day? Then you'd have a drop in replacement, any changes you make will cause disruption for people downstream.

https://www.nxp.com/part/MIMXRT1062DVL6A

Mostly I'm just leery of software defined peripherals being at the mercy of whatever community springs up around them, nothing specific. In terms of a Metro then yeah, something to slot in where the Due was absolutely with high speed USB, 10/100 ethernet, CAN FD, and all that jazz that wouldn't work on a $10 board. A SAMV70 successor to the Due?

NXP just seems antithetical to an open platform. Then again Arduino went with Renesas, and they're… not great.

Otherwise it's the openness that would pique my interest. SWD headers, yes 100%. But also the documentation. No half-assed SVDs, buggy closed source flash algorithms (Microchip), wholly undocumented peripherals (looking at you Renesas), stuff like that.

All chip manufacturers are alike in this respect, unfortunately. That whole industry believes that they thrive on secrecy and that simply properly speccing their hardware would already be a massive competitive risk.

Nah, it's a spectrum. Companies like NXP and Infineon are at one end. NXP wants a ton of personal information to access even the most basic docs on some of its chips, sometimes even an NDA. Infineon won't even acknowledge you for the most part.

Companies like STM, RP, and TI are at the other end. STM got super popular because they're cheap and the documentation is incredibly easy to get at. I think RP is following suit.

Renesas puts out some documentation, but it's really rough. Anything that has even a whiff of crypto is completely undocumented. They're also squatting on a few Rust crates where Espressif actually hired a Rust developer to work on their Rust HAL. The most comical thing is that while they version their reference manual they don't seem to update it and instead issue a ton of broad errata that apply to multiple manuals.

Before the acquisition Atmel's documentation was well written and organized.

That's fair. Even so, the majority of the companies whose chips I would consider for specialized electronics seem to be so far down on the paranoid spectrum that it hinders their business.

Sure, some do, but some are coming around and some were never there. Which is why it's important for a company like Adafruit to pick a manufacturer that is towards the open end of the spectrum. Unfortunately NXP isn't that manufacturer even if their silicon is more powerful.

Agreed. I will say that Renesas does have one thing going for them, being Japanese it has the lowest supply chain/geopolitical risk right now of anybody other than TI. And the Microchip/Atmel low end stuff is so overpriced/outdated, that you're be better off stockpiling reels of the 8 cent Puya chips or going with the the TI MSPM0.

There is a place for a cheaper 5v tolerant microcontroller, but that’s more of a commodity space and probably not worth competing in for most.

I have projects that can equally use either a Teensy or a few different Feather boards, and frankly the Feather boards are always the prefferred option beacause:

* assymetrical footprint - the assymmetrical dip footprint means the board has polarity protection. I have hat/receiver boards with zig-zag stagger dip rows that work as free componentless sockets to receive a feather board with pins soldered. The Feather versions are far more convenient and safe since they can't be plugged in any way but the correct way.

* The Feather standard being a standard - ecosystem of compatible boards with compatible footprint & pinout at least for main functions.

* lipo charging circuit and jst plug, the automatic ups functionality, usb charging, removable/replaceable via standard plug

* off-board power on/off - I very much make use of the trick Feather has where a hat can turn the mcu board on/off without being the source of power to the mcu board.

* Perhaps a small detail but Feathers with sd card slots have the card sense pin wired up to a gpio pin while the teensy's do not. On Feather I can have a hardware interrupt fire when a card is inserted or ejected, and I can't do that on Teensy.

* keeping all parts on the top surface - there are other mcu dev boards with some similar functions but they are less convenient to use as a module in a project since they may have buttons, jst plug, sd card slot, or other stuff on both sides of the board, which makes them inaccessible when mounted onto some other pcb.

Teensy has a few points in their favor too but I really value these facets of most Feather boards.

That’s all well and good but it simply doesn’t make it an open source teensy.

I for one abandoned the Teensy for all projects once I realized it was closed as I have no interest in promoting or teaching closed hardware and software in my personal DIY time.

I will gladly be a customer of your open hardware replacements.

It looks like it's just a set of bullet points on a forum thread, not anything like a final design, so go post that comment there.

> hardware support, like 600Mhz clock, CAN, FPU, RTC, other hardware peripherals which the RP2350 lacks

FWIW, those are all NXP-provided features on the chip, not something Sparkfun has any particular connection with. There are other iMX devices on the market, just not in this form factor. And there are other vendors with SoCs offering similar performance.

Really one of the biggest problems in this market is that everyone is putting the abstractions in the wrong place. We've all collectively decided that this stuff is scary and we need comforting IDEs and hardware uniformity to deal with it.

But... portable software and frameworks are hardly new ideas. Come over to Zephyr and see all the stuff you can run on boards from basically everyone, including NXP.

There's a lot more great hardware for your project than just Teensy, so stop locking yourself in.