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?

▲

alnwlsn 13 hours ago | parent | next [-]

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.

▲

Xenograph 10 hours ago | parent | next [-]

> 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?

▲

alnwlsn 9 hours ago | parent [-]

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.

	▲	isopede 2 hours ago \| parent [-]
		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?

▲

throwaway81523 6 hours ago | parent | prev [-]

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

▲

Brian_K_White 6 hours ago | parent | prev | next [-]

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.

▲

vablings 13 hours ago | parent | prev | next [-]

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

▲

inferiorhuman 14 hours ago | parent | prev [-]

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.

▲

alibarber 13 hours ago | parent | next [-]

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.

▲

ahepp 11 hours ago | parent [-]

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?

▲

alibarber 11 hours ago | parent [-]

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.

	▲	ahepp 10 hours ago \| parent [-]
		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.

▲

ptorrone 13 hours ago | parent | prev | next [-]

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?

▲

jacquesm 13 hours ago | parent | next [-]

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.

▲

ptorrone 13 hours ago | parent [-]

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

▲

jacquesm 11 hours ago | parent | next [-]

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

▲

15155 13 hours ago | parent | prev [-]

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.

▲

djmips 6 hours ago | parent [-]

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.

	▲	15155 2 hours ago \| parent [-]
		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.

▲

inferiorhuman 13 hours ago | parent | prev [-]

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.

▲

jacquesm 11 hours ago | parent [-]

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.

▲

inferiorhuman 5 hours ago | parent [-]

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.

▲

jacquesm 3 hours ago | parent [-]

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.

	▲	inferiorhuman 2 hours ago \| parent [-]
		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.

▲

cjbgkagh 13 hours ago | parent | prev [-]

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.