Micropython is a lightweight implementation of Python for microcontroller which we covered first in 2013. The port is supported by various hardware platforms, and I even tested Micropython on ESP32 a little while ago, but the developer – Damien George – also launched officially supported boards starting with Pyboard in 2014 with an STM32F4 microcontroller.
At FOSDEM 2019, the upcoming Pyboard D-series (aka Pyboard D, or just PyBD) board was introduced during the Micropython presentation with a faster STM32F7 Cortex-M7 MCU, as well as built-in WiFi and Bluetooth connectivity.
Pyboard D preliminary specifications:
- MCU – STMicro STM32F7xx Arm Cortex M7 microcontroller at 216 MHz with 512KB RAM, 2MB flash
- Storage – micro SD card slot, and 2x external flash chips
- Connectivity – WiFi & Bluetooth with on-board antenna and u.FL antenna connector
- USB – 1x micro USB port for power, flash disk access, and USB to serial debugging/programming
- 2.54mm pitch through holes for 16x GPIOs
- 1.27mm pitch castellated and through holes for 32x GPIOs
- 2x 40-pin WBUS connectors for a total of 59 GPIOs
- Misc – User and reset buttons, RGB LED, clock
- Dimensions – TBD
The WBUS connectors are also new and will allow you to stack add-ons boards, for example the WBUS DIP28 or DIP68 boards exposing respectively 28 and 68 I/O pins, and which themselves can takes one or more sensor board(s) via other smaller 2x 10-pin sensor board connectors.
There’s also an eMMC WBUS board for extra storage, and I’m sure more WBUS boards may be planned. You’ll find more details on MCHobby’s blog post (in French).
There were a few samples on offer at FOSDEM 2019, but the only pricing and availability information I know of is that the board will be available in a few days or weeks.
Via Adafruit Blog
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.
12 Replies to “Pyboard D Series MicroPython Board Features STM32F7 MCU, WiFi and Bluetooth”
Probably way more expensive then an ESP32 🙂 My Wemos Lolin32 came preflashed with micropython for 4eur. But now it seems they stopped them…
If you have to ask for the price, you probably won’t like the answer.
“Modules” are everywhere nowadays. Great for hobbyists but they often disappear just as fast as they pop up. This makes them unsuitable for any serious production project.
Is the gap/hole next to the uFL connector a slot to solder a SMA connector?
I like many of this board’s features. If it is priced right ($20-30 for the board) it will do well. And no it is not going to compete with $5USD ESP32 boards but it doesn’t have to. Plenty of people will be willing to pay a premium for ease of use, good documentation and well thought out hardware dedigns. I’ll prolly buy a couple even if its a bit more expensive that $30.
For $25 you can get the pocketbeagle that can run actual python. I’m not sure I see the point of hobbling yourself with a microcontroller unless it’s much cheaper.
When I think ease of use I do not think PocketBeagle. PocketBeagle does not have ready made Python3 libraries for accessing its interfaces. Also you have to mess around with loading device tree fragments e.t.c. …Very ugly.
Python3 is not optimized for embedded system and will lag in comparison to Micropython, even with a 1GHz clock. Also Linux is not realtime and is not ideal for every type of embedded project. This is why projects like openMV use Micropython.
With your logic, I can get a RPi Zero for $11 bucks, a RPi Zero 3 for $35 and a nanoPi for $10-$45. So why even bother with micropython at all? Heck why bother with microcontrollers at all?
>PocketBeagle. PocketBeagle does not have ready made Python3 libraries for accessing its interfaces.
GPIO, ADCs etc are all available as files in sysfs.
>Python3 is not optimized for embedded system and will lag in comparison to
>Micropython, even with a 1GHz clock.
I’d like to see evidence for that. Either way if you had a performance critical area you can use tools like cython. If anything you have more choice because people have been trying to make normal python fast for a long time already.
>Also Linux is not realtime and is not ideal for every type of embedded project.
The soc on the beagle bones and pocket beagle has two fast micro controllers built in. I think there is even a C compiler for them now.
>So why even bother with micropython at all? Heck why bother with microcontrollers at all?
There are reasons to use microcontrollers. Most of them to do with cost. The cheapest complete ARM system that can run Linux in a chip is about $3-$4 as far as I know (Cortex A7 at 800MHz with 64MB built in). If you are buying hundreds of thousands of parts then one or two dollars on the BoM is hundreds of thousands of lost profit. On the other hand putting a microcontroller on WiFi is close to insanity.
– PocketBeagle is not easy to use. For starters you need to worry about loading device tree blobs to get the desired correct IO configuration. (Admittedly this has become easier to do in the last 3-4 years but is still hard for non-techies or those not familiar with Linux)
– Accessing IO through sysfs is slow as molasses in any language. Micropython on a microcontroller has properly developed C drivers wrapped in python code giving it faster access to IO resources.
– The two PRUs in the PocketBeagle SOC are NOT easy to use. They were intended to be programmed in assembly and only recently got a C compiler.
– MicroPython would very likely run faster on a 200MHz microcontroller than Python3 on a 1GHz Microprocessor, because MicroPython only implements an optimized (for microcontrollers) subset of the Python3 language and has underlying C drivers. Furthermore, the PocketBeagle SOC is fast but Linux as great as it is, eats up a lot of the available CPU cycles, slowing down the Python3 runtime significantly. And using Cython to speed up Python3 code again adds to development complexity.
-PocketBeagle requires Linux Knowledge. Not everyone is proficient with Linux.
– Micropython is ideal for hobbyists and fast protyping. No it is not ideal if you want the absolute cheapest hardware and most efficiently designed software. But I could also argue that neither is a pocketBeagle. It ultimately depends on your particular application.
My point is saying that a $20-$30 board is too expensive and will never succeed, is not necessarily true. The board is designed to fit a particular niche and it will succeed within that niche. You are right though, people will not be buying them by the truckload from AliExpress for $5 a pop. I doubt that will happen anytime soon. And that’s not necessarily a bad thing.
If you want to an ESP32 go buy one. If you want something that can be used right out of the box with little expertise, better support docs then get the new PyBoard. Purchasing one of these is also a great way to support the organization and the creator behind Micropython,
>For starters you need to worry about loading device tree blobs to
>get the desired correct IO configuration
How is that different from working out the pin mux settings on a microcontroller. The BB kernel has their pinmux helper etc.
>Micropython on a microcontroller has properly developed C drivers wrapped
>in python code giving it faster access to IO resources.
So the IIO subsystem in Linux isn’t properly developed C drivers?
>The two PRUs in the PocketBeagle SOC are NOT easy to use.
Doing stuff that requires hard realtime isn’t easy either. They are there if you need to do hard realtime stuff.
>MicroPython would very likely run faster on a 200MHz microcontroller
You’d need to prove it. Just saying it might be true doesn’t make it true.
>Python3 language and has underlying C drivers. Furthermore,
Lots of python3 is written in C. Modules that require native speed are written in C.
>the PocketBeagle SOC is fast but Linux as great as it is, eats up a lot of the available CPU cycles,
Probably not as many cycles as you think. You can run a buildroot based linux system in 8 megabytes of RAM.
>And using Cython to speed up Python3 code again adds to development complexity.
If you need speed then you take the hit of having to work out how to use cython. Cython isn’t actually too bad though and if you just want to write a python frontend to some C code you need to bolt in then you don’t even really need to understand half of what it does.
>PocketBeagle requires Linux Knowledge. Not everyone is proficient with Linux.
There’s absolutely no reason why there couldn’t be a pocketbeagle image that hides all of it.
Building something with buildroot that boots up and runs a user’s python script would be trivial.
Replicating what this board does (usb mass storage device and web server) wouldn’t be too hard either.
>My point is saying that a $20-$30 board is too expensive and will never succeed,
>is not necessarily true.
My point is that $20-$30 for a board that runs a hobbled version of python isn’t great value when you can get a board that runs proper python for the same money and isn’t trying to run a wifi stack, TLS etc in the same address space as your user applications.
There are situations where a board like this would make sense even if it’s expensive. For example in a battery operated project.
Oh and the pocketbeagle doesn’t have built-in network connectivity at all.
You can install MicroPython on Linux and do some benchmarks for us?
For true hard real-time you need to use an RTOS or RTAI + Linux, else it’s not hard real-time!!! Don’t be fooled.
Current break out boards are too big and this form factor is next evolution.
MicroPython gives people option to use Python from a micro to cloud – faster dev to market.
Just the wifi module is $8…