Teensy 4.0 vs PORTENTA H7

skpang

Well-known member
Arduino has just announced the PORTENTA H7

https://store.arduino.cc/portenta-h7

Not quite a fair comparison to the Teensy 4.0 but it has some pretty impressive features.

Interesting it has two 80 pin high density connectors so extra IO pins are accessible.

Expensive at €89.90
 
That board is 2 microcontrollers on one board plus full networking capabilities.
I that 90 Euro price comes as no surprise.
And it has USB-C...

Basically, it is 2 Teensys in a single package, but 4x the price.
I am surprised the clock speed is set to 480 MHz. Maybe it can be overclocked like a Teensy?
Teensys are more breadboard friendly than this thing. Teensys don't need another $50 in shields to get the necessary functionality.
Seems like a more niche board than a Teensy
 
That board is 2 microcontrollers on one board plus full networking capabilities.
I that 90 Euro price comes as no surprise.
And it has USB-C...

Basically, it is 2 Teensys in a single package, but 4x the price.
I am surprised the clock speed is set to 480 MHz. Maybe it can be overclocked like a Teensy?
Teensys are more breadboard friendly than this thing. Teensys don't need another $50 in shields to get the necessary functionality.
Seems like a more niche board than a Teensy
Sure at that price, it is a niche board.

Technically it is not 2 separate micro-controller chips put together on a PCB, but it is a single chip with 2 different cores (M7 and M4).

Note, the 1170 NXP board that Paul has talked about for a long term Teensy similarly two cores inside (M7 and M4), but is made by NXP instead of STM:

At present the Portenta board has wifi and bluetooth, and the NXP board does not. However, since NXP just bought a chip maker that makes wifi/bluetooth boards, I suspect future IMX boards may also include wifi/bluetooth.

The Portenta board a 32-bit ARM board and I think the NXP 1170 is also. I'm wondering when the 64-bit ARM boards will percolate down to the embedded space. Raspberry PI 4 has moved to 64-bit boards.

The main pinouts look to be breadboard friendly. They are 14 pins to a side (i.e. similar to the Teensy 3.2/4.0), but it looks like it might be 0.8" wide instead of 0.7". The boards do have USB C and lipo charging built-in. Arduino has several other boards that seem to use that 2x14 setup. Note, the board is a little longer than 1.4" and it has things on the space where there are no pins (USB + lipo on one end, radio on the other?).

I can't see the bottom side clearly in the photos, but those two 80 pin connectors look like you would need to surface mount solder to attach to them.
 
Last edited:
Raspberry Pi 3 was also a 64 bit CPU, like raspberry pi 4. Raspbian OS is still 32 bit, I think.

Thanks. I haven't been keeping track of the Pi world. I gave up at the Pi-2/Zero stage. For me, it was the PI cameras were so poor, that I could only use them outdoors in daylight. I also was frustrated at the lack of abstraction in the video world (my project was to do a steampunk camera inside of a Polaroid 95A body).
 
Dario & Massimo told me about this board at Maker Faire last year, using the new 480 MHz STM32 chip. I've kept quiet about it, kinda wondering when it would appear. They said it would not be cheap, but I had no idea they'd retail it at $100. I'm a little skeptical they'll end up selling many at that sort of retail price.

They also said at the time they were going to support MicroPython, but not Adafruit's CircuitPython. I see MicroPython is mentioned on the page. Been looking forward to seeing where this goes and to (maybe) follow their lead on Python. Or maybe go with Adafruit's stuff?

Looks like they've put some pretty amazing hardware capabilities on the board, like displayport video over USB-C, a SDRAM chip, ethernet PHY, and a high performance murata connected by SDIO & serial for wireless. (fwiw, NXP recommended that part when I asked them what was recommended for wireless with IMXRT - and it's quite expensive, which went against the keep-it-to-$20 goal of Teensy 4.0)

As with any board, how useful it will be really depends on how much work they put into the software side. I'm *really* curious to see what they do for the core library and various Arduino libs. Maybe they'll fork STM32's core? Or maybe they'll build on top of mbed & cmsis? Seems unlikely they'll hand-craft the software from scratch, but who knows?
 
PaulStoffregen said:
They also said at the time they were going to support MicroPython, but not Adafruit's CircuitPython. I see MicroPython is mentioned on the page. Been looking forward to seeing where this goes and to (maybe) follow their lead on Python. Or maybe go with Adafruit's stuff?
Interesting thing is that they already have a port of micropython for Teensy 3.x series: https://github.com/micropython/micropython/wiki/Board-Teensy-3.1-3.5-3.6. Haven't tried it.

As for the Teensy 4: https://forum.micropython.org/viewtopic.php?t=6783 and this: https://github.com/RockySong/micropython-rocky. RockySong is from NXP and ported it to the 1050 and 1060. So if anyone is interested :)
 
This PH7 is a very intriguing board. Has GPU acceleration and computer vision abilities - very relevant for the AI revolution underway! Also really like the two 80-pin high density connectors and I2C connector complementing the 1mm GPIO headers. All in a teensy-like form factor. No more arduino format. Can PJRC top this board someday? The PH7's $99 price tag will be an impediment, that's for sure. For that price, I'll stick with the Jetson Nano (4-core ARM + 128-core GPU). Currently driving a Nano with a Teensy 3.6 to do objection detection.
 
I'd say, although I've used the 3.6 to output VGA, for things like video or object detection via camera or other applications in this range, a system running a OS like Linux is better. Normally you can use already existing libraries for everything you need. It's all there - and if you connect a big screen there is no reason to use a small board which is, compared to the raspi
dead slow.

For other things, it is more useful, and having BT and Wifi on board is nice. On the other hand, you can add this using a ESP for a few $ to every micro.

Pretty amazing is the pin- count on the HD connectors.
 
Can PJRC top this board someday?

That really depends on how you compare. PJRC definitely will not make a $99 board. So you should not expect to see any Teensy loaded with as many chips as this Portenta H7, especially the SDRAM and Murata Wifi. I'm also pretty skeptical about those 2 high density connectors, but will be watching closely how people use them to influence decisions about future Teensy boards.

In terms of raw performance, an 1170-based Teensy (M7 at 1 GHz and M4 at 400 MHz) ought to be about double Portenta's speed (M7 at 480 MHz and M4 at 240 MHz). NXP's 1170 doesn't exist yet, but we can generally expect it'll arrive near the end of this year. Presumably more STM32 chips will arrive over time.

Then again, if you only care about raw speed, how does a 600 MHz M7 without companion M4 compare to a 480 MHz M7 plus 240 MHz M4? I don't believe there as any single simple answer...

Of course these STM32 and IMXRT chips are not the end of Moore's Law on microcontrollers. We're just now seeing the beginning of chips at 40nm and soon 28nm. ARM has already announced Helium using architecture version 8 and vector processing optimized for machine learning and DSP, and competitive pressure from RISC-V is likely accelerate the traditionally slow pace of improvement on chips aimed below phones & PCs.

The reality of all this advanced hardware is a strong dependency on software support. Many people will just compare hardware specs or coremark scores and ignore the quality of driver support. But drivers & libraries matter quite a lot. I believe everyone who uses this forum regularly has seen the huge changes in USB speed since the early days of Teensy 4's beta to where we're at now with 1.49-beta4. Even at 12 Mbit, software matters greatly. If you run the lines/sec benchmark on various boards, you'll see huge differences. Even Teensy 2.0 competes with some of the non-Teensy 32 bit boards that have not well optimized code.

These new chips are bringing so much complex hardware that will need a tremendous amount of work on the software side. When you see a company like Seeed Studios make a board, you can be pretty sure the software support will be only whatever the semiconductor vendor or some 3rd party like Zerynth provides. Arduino has the potential to really craft some amazing software support. But it could also turn out like Arduino Due. At this early stage, I don't think anyone can predict where it will end up.
 
Dario & Massimo told me about this board at Maker Faire last year, using the new 480 MHz STM32 chip. I've kept quiet about it, kinda wondering when it would appear. They said it would not be cheap, but I had no idea they'd retail it at $100. I'm a little skeptical they'll end up selling many at that sort of retail price.

Thanks Paul for keeping this confidential. i'm going to answer a few of the topics, invading your space a bit, just for the sake of answering the many questions being asked. It took a while but we finally made it. the one message we probably are not (yet) communicating correctly is that the $100 price tag is for the full featured version. we are actually going to provide other selectively depopulated versions which, for single units will go down as low to half price. the real deal with this product is that, being part of our new pro strategy, we are offering the possibility for volume customers to selectively depopulate the board and have it assembled with the exact BOM they need, of course with volume pricing discounts.
if you take into account the BOM you can easily see that $100 is quite a good price for what you get and if you don't need this much you can pick the lower specced version.

They also said at the time they were going to support MicroPython, but not Adafruit's CircuitPython. I see MicroPython is mentioned on the page. Been looking forward to seeing where this goes and to (maybe) follow their lead on Python. Or maybe go with Adafruit's stuff?

Our decision to stick with Micropython is to credit the huge work the MicroPython team has done putting it together and help them grow their project contributing to it. we strongly believe in open source and love when our users contribute to our code so it's natural decision to use the mainline code and contribute to it.

Looks like they've put some pretty amazing hardware capabilities on the board, like displayport video over USB-C, a SDRAM chip, ethernet PHY, and a high performance murata connected by SDIO & serial for wireless. (fwiw, NXP recommended that part when I asked them what was recommended for wireless with IMXRT - and it's quite expensive, which went against the keep-it-to-$20 goal of Teensy 4.0)

Arduino is always trying to being complex technology to the masses and this is really what we've done on this product, selecting the best technology available, in industrial temperature range, to provide a no compromise platform that can be scalable and that is easy to use. Displayport for one is really a differentiator but as you mentioned the wireless module is really a different class... it supports BT 5.0 and over 70 mbps on wifi...
what's most important is that the high density connectors pinout is designed for scalability for even bigger processors so we're paving the way for a platform that will enable users to pick the exact blend of hardware they need for any given applcation.

As with any board, how useful it will be really depends on how much work they put into the software side. I'm *really* curious to see what they do for the core library and various Arduino libs. Maybe they'll fork STM32's core? Or maybe they'll build on top of mbed & cmsis? Seems unlikely they'll hand-craft the software from scratch, but who knows?

moving on with what we did for Nano 33 BLE Sense we are building on top of mbed, so basically we've just pushing support for our board in mbed mainline kernel. this means that you can compile the same arduino code on both the M7 and the M4 using mbed either just as an abstraction layer or as a full RTOS, enabling multitaksing in addition to multiprocessing. software support however doesn't stop with mbed/arduino: you can run the micropython/jerryscript interpreters (they're living in the same binary and you can switch interpreter via REPL) and tensorflow on each core. we also developed a RPC mechanism that allows you to call functions from a processor to the other in a very seamless way and this of course is usable in every one of the supported environments so you can call a tensorflow classifier running on the M7 from an arduino code running on the M4 or call an arduino function running on M4 from a python script running on the M7...
 
Then again, if you only care about raw speed, how does a 600 MHz M7 without companion M4 compare to a 480 MHz M7 plus 240 MHz M4? I don't believe there as any single simple answer...
Very true.
If you take the ease of using way more MHz for the NXP into account, without need to have the advanced skills to use two processors, the answer is a bit simpler.
Edit: There are many users who just copy code from there to there without understanding hwo it works. With two processors, they will be completely lost.

More problematic is, that it is not possible to use all the exisiting features of the 1062, because of the low pin-count of the T4. I know there are plans to ease this situation, and I very much welcome them.
It's not the low pin-count per-se - nobody really need that much pins - it's the imposibility to make use of more of the existing features.
To replace the T3.2 (by price) by the T4.0 was great. I'm really very impressed.
 
we are offering the possibility for volume customers to selectively depopulate the board and have it assembled with the exact BOM they need, of course with volume pricing discounts.
we strongly believe in open source
So your strategy involves to support more industrial use by using free open source expert(s) knowlage for free?
(and keep the prices high for single-board customers, and so the experts whose knowlage you want to use for free).
 
Last edited:
My take is the dual core chips will be harder for the average Arduino programmer to grok, simply because up until now, they probably don't use threads or similar mechanisms already. I'm not saying they can't learn, but it will be outside of their comfort zone. Professional embedded programmers that use RTOSes already will probably be more able comfortable with it.

In the Arduino space, I suspect it most likely will be relegated to libraries that provides a high level of abrabstraction and then does all of the nasty bits in the background. For example having the libraries for writing displays, WS2812B (neopixels), playing songs, or running servos may be a useful place to use the M4 processor. Though there, I could imagine wanting to have something that does lots of WS2812B leds, plays music, and runs servos all at the same time (i.e. having a M4 slave processor is great if you have only one thing that needs offloading, but if you multiple things, each of which wants to own the M4, you have problems).

And speaking as a compiler guy, if the two cores share the same address space, it is going to be real fun if the M4 processor calls something with M7 only instructions in it.
 
it is going to be real fun if the M4 processor calls something with M7 only instructions in it.

The integer instructions are suppose to be the same on M4 and M7. But the FPU is where things might be interesting.

Eventually we're all going to have to figure out how to make this work, since 1170 will have M7+M4 and that seems to be a likely trend for future chips.
 
I am not interested in starting discussions with biased arguments so won't comment on Frank's statements to avoid polluting this great forum.

Regarding multiprocessing and multitasking we are investing quite a bit in trying to make it as easy as possible preventing the most common pitfalls. For one these architectures support mpu and that, in conjunction with secure execution, would prevent a core to step into the other.
As I mentioned our solution is to run different applications on each processor, say a real time control loop in m4 and a high level main loop in the M7 and allow one to virtually call, via RPC, other's functions.
I don't think we solved every problem with this and it's true that there are many pitfalls but multicore can greatly benefit a large number of applications and we're trying to make it more accessible than it is today.
 
I just ran across the Portenta H7 today. I think what jumped out at me the most is the 64 MB of SDRAM, and 128 MB of NAND Flash, in addition to an SD card reader via expansion. Is that much RAM essentially to run a WRT type OS? I don't know how much RAM is needed to run the not so "micro" version of Python, but I have to think that 64 MB is approaching that point.

As for dual cores, the ESP32 seemed to show the real value in dedicating a core to WIFI/IO to free the other core to run the logic. Keeping it simple with dedicated tasks to the cores would be my first inclination. I'll leave squeezing every drop of performance out of the package to others while i amaze myself at making lights blink on or off.
 
Eventually we're all going to have to figure out how to make this work, since 1170 will have M7+M4 and that seems to be a likely trend for future chips.

Maybe we should dedicate the 2nd (M4) core for audio/video/communication and make it accessible for libraries only. Using both cores is'nt beginner friendly anymore, and since Arduino is made for beginners I would not make the 2nd core visible for them.
A dedicated audio/video/comms (but not GPIO) core would give them the best of both worlds.
I'd just call it "Communication core" :)
 
Honestly, it seems like any Cortex M7 core is going to be more than enough CPU for almost anything that someone would want to do on a micro controller. A dedicated audio/video/comms M4 core that can free the M7 up to do the primary tasks sure seems like a reasonable approach. Might be different if it were true dual M7 cores with cache coherency, even if one was running at a slower speed.
 
Yes, fun times ahead. Even if we put it in a library, we are going to have to write the library. So while ordinary Arduino users might not start doing stuff with it now, we will need some way to access it to make the library.

And as I said earlier, logically you might have several libraries that want to offload stuff to the M4, and you have the usual "who's on first issue" if more than one library wants to use it.
 
Honestly, it seems like any Cortex M7 core is going to be more than enough CPU for almost anything that someone would want to do on a micro controller.
Oh, somehow that reminds me of

Thomas Watson said:
I think there is a world market for maybe five computers

Bill Gates said:
640K of memory should be enough for everyone
:rolleyes: :rolleyes:
 
Yes, fun times ahead. Even if we put it in a library, we are going to have to write the library. So while ordinary Arduino users might not start doing stuff with it now, we will need some way to access it to make the library.

And as I said earlier, logically you might have several libraries that want to offload stuff to the M4, and you have the usual "who's on first issue" if more than one library wants to use it.

It would allow us to run a RTOS on the 2nd core ;) So, additional code would be an additional task ...
 
Luni, did you ever read the german forum mikrocontroller.net?
Basically the hardcore users there say, you can do everything with 8bit controller, and all you can do with fast ARM-cores is faster blinking with Arduino-Sketches... ;) (I don't want to mention the lousy conversational tone there.)

I went away there long years ago.
 
Back
Top