Arduino Portenta H7 Lite is a cost-down version of Portenta H7 STM32H7 that shaves off a little over $30 of the Arduino Pro board by doing without a wireless module nor USB-C video output and opting for a lower cost Microchip ATECC608 secure element.
Arduino says the new board provides a cost-optimized solution for companies developing high-end industrial machinery, laboratory equipment, computer vision, PLCs, robotics controllers, and mission-critical devices.
Arduino Portenta H7 Lite specifications (with differences in bold or strikethrough):
- Microcontroller – STMicro STM32H747XI Cortex-M7 @ 480 MHz + M4 @ 200 MHz MCU with 2MB dual-bank Flash memory, 1 MB RAM, Chrom-ART graphical hardware accelerator
- System Memory – 2MB SDRAM (upgradeable up to 64MB)
- Storage – 16MB QSPI NOR Flash (Upgradeable up to 128MB)
- Connectivity
2.4GHz WiFi 802.11b/g/n up to 65 Mbps and Bluetooth 5.1 BR/EDR/LE via Murata 1DX module- On-board 10/100M PHY
- Video I/F – MIPI DSI & 8-bit camera interfaces via 80-pin expansion connector,
DisplayPort over USB-C port - USB – 1x USB 2.0 Type-C port for power (PD) and programming
, and DisplayPort output - I/Os
- Arduino MKR headers with UART1, 6x Analog input pins, GPIO, PWM, SPI, I2C, Reset, 5V, 3.3V, and GND
- 2x 80 pin high-density connectors
- Storage – SD card signals
- Connectivity – 10/100M Ethernet
- Display – 2-lane MIPI DSI
- Camera – 8-pin camera Interface up to 80 MHz
- Audio – I2S, DMIC, SAI
- USB – 2x USB 2.0 interfaces
- Serial – 4x UART ports (2 with flow control), CAN bus (Tx/Rx)
- 2x I2C, SPI
- 8× ADC pins with 16-bit max. resolution
- 2× 12-bit DAC (@ 1 MHz)
- 6x GPIO and 10x PWM
- Debug – SWD interface
- 5-pin I2C ESLOV connector with 1.0mm pitch
- 3.3V operating voltage
- Security – Microchip ATECC608 (instead of NXP SE0502)
- Misc – 22x timers and watchdogs
- Power Supply
- 5V via USB-C port or VIN pin
- Support for 3.7V/700mAH minimum LiPo single-cell battery; integrated charger
- Consumption – 2.95 μA in Standby mode (Backup SRAM OFF, RTC/LSE ON)
- Temperature Range – -40 °C to +85 °C
Portenta H7 Lite has the same board layout as its older brother, and the main differences are the removal of several chips and modules including Murata 1DX module and antenna, the MIPI to USB-C/DisplayPort converter and corresponding level shifter, NXP Crypto chip (replaced by Microchip ATECC608 on the bottom of the board), plus some other passive components.
The Portenta H7 Lite can be programmed either with the Arduino IDE or MicroPython, with support for Arduino sketches on top of the Arm Mbed OS, Native Mbed applications, MicroPython/JavaScript via an interpreter, and TensorFlow Lite for AI applications.
The latest Arduino Pro board can either be used as a standalone embedded microcontroller board, or as the module for a larger carrier board such as the Portenta Carrier thanks to two 80-pin board-to-board connectors.
You can purchase Portenta H7 Lite now for $72 or 60 Euros on the Arduino store, which compares to $103.40 for the original Portenta H7. Additional information may be found on the product page.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
A GRBL parser running on this could be impressively efficient!
Aren’t there better ways to go about that? Are you thinking for CNC machining or 3D printing? If the latter, Klipper is a much better solution.
It’s for my laser engraver. In order to print raster images at high speed (3000+ mm/mn) it requires a fast CPU. I slightly overclocked the arduino nano on the board (24 MHz vs 16 initially) that allowed me to cross a nice step, but I’m thinking about migrating to the GRBL-HAL at some point and use one of the supported boards. Better do that for real gains though. This one seems worth trying.
What s shame RPI and similar are not up to it.
I’d recommend a Teensy board instead, but that’s more of a personal preference. I’m surprised that there isn’t something like Klipper for laser engravers.
> I’d recommend a Teensy board instead, but that’s more of a personal preference.
Good point, I remember noticing its support in the past. I initially was not interested because my board uses an arduino-nano board with a pinout that almost no other board supports, so that would force me to design an adapter board that I initially wanted to avoid. But I finally came to the conclusion that I will not have any other choice anyway.
> I’m surprised that there isn’t something like Klipper for laser engravers.
I never heard about Klipper before. I’ve read the description and figured there could possibly be a good reason: “The kinematics algorithms, the G-code parsing, …are all written in Python”. With a laser engraver you have to process intense GCODE. I’ve tried quite a number of UIs for the GCODE upload. *all* of those written in Python couldn’t deal with raster images on a core i5 at 3 GHz, resulting in freezes or visible steps due to motors stopping while waiting for new instructions. The buffers in the MCU are quite small, so the sender must respect a low latency. At 600 pixels per second you have a 1.6ms cycle time, which includes reading the MCU’s window updates messages and immediately sending a new instruction before the previous one leaves the buffer. And it looks like these Python-based programs were not able to maintain such a latency to keep the MCU’s buffer filled :-/
Well, a few things. 🙂 I am no fan of python for the exact reasons you mention. Most python code is trash. Klipper is not. It’s written by people who actually are good at coding and it uses a lot of heavily optimized libraries for the heavy lifting.
For those unfamiliar, traditional 3D printers often use a 16MHz 8 bit AVR processor to decode the GCODE commands and translate them into precisely timed STEP and DIRECTION pulses to a set of stepper motor controllers. That’s a lot to ask of a little processor with very limited CPU and memory. Klipper flips that around. They put all of the GCODE parsing and motion control logic on a beefy PC (or at least an RPI) and relegate the AVR to just decoding very simple timing commands. It allows much more complex motion planning and more precise (and faster) stepper motor control. I don’t know the specifics as I haven’t looked at the protocol, but there’s no reason they couldn’t do a lot more buffering as they have all the ram that used to be needed for command parsing and motion planning sitting unused for a Klipper board.
So, there’s no reason a python program can’t do a good job, it’s just that most python is so horribly poorly written that they don’t. As much as I want to, I can’t blame python for that.
The reason for a high level coding language, is it is ment to make doing the job easier.
Like a UI enables people with no command coding training, the ability to use a computer.
If you find the high level non machine code language a problem, in doing the job, then ask yourself, why are you using it.
> The reason for a high level coding language, is it is ment to make doing the job easier.
When chosen by developers, yes. When chosen by companies, it’s often done on purpose because such developers can be much cheaper. It can be disguised behind “wow we are a super strong community blah blah” but the reality is that it’s a business model to build inexpensive developer teams where anyone can be easily replaced as long as stackoverflow remains accessible :-/ Developers need to be cautious not to be enclosed into such situations where they have little hope of seeing their career progress.
That’s indeed what I understood from there. They’re advertising high step rates but I’m really unsure about the really perceived benefits. I mean, to get back to my example of 600 pixels per second with a laser modulated at 12 kHz, that means a pixel only receives 20 pulses, which means a resolution of +/- 5% only. And that doesn’t even factor in the laser module’s latency. As such *for this use case*, I don’t see much that can be improved from the software side. But it probably matters more for 3D printers.