The first boards in this series will combine an ST microcontroller with a wireless coprocessor module, and have the following features:
Main microcontroller: STM32F7xx in UFBGA 176+25 package (with future support for STM32H7xx)
WiFi b/g/n and Bluetooth 4.1 processor: Cypress CYW4343 (was Broadcom BCM4343)
For ease of use: micro USB, micro SD card, 3x LEDs, reset and user buttons, 16-pin DIP headers
For embedding: 2x 40-pin bus headers
Features up to 59 GPIO, with ADC, DAC, UART, I2C, SPI, CAN, I2S, dual USB, SDMMC, ETH RMII, DCMI and hardware JPEG codec (depending on model)
Dual SPI flash for file storage and code execution (QSPI XIP)
Measurements in mm
- PYBD_F767_top.jpg (54.01 KiB) Viewed 1729 times
Where those pictures are coming from ?
Look at newsletter 1.
Damien is just tooling up for production now so the board isn’t available yet.
I posted it as I though people might find it interesting. It is very impressive for performance/features and size. The down side is I would image it wouldn’t be cheap to produce such a board.
Looking at the board I think he is hoping to be able to service the needs of in industrial small but high perforce embedded projects. If you read newsletter 3 he has been working with a space company called SPACEBEL as they want to use MicroPython in their space craft as MP is an interpreted language where code can be written and executed live.
Just have not taken the “next step” to learn the language. I must have been a baby when I studied Fortran at the University as part of my EE training. I had already had 3 years of exposure to Cobol and Fortran “set me free.” UNIX System V and C came a few years later during employment. Later, C++, VB, VBA, and numerous “Enterprise” languages (CA’s Visual Objects, Borland C++ Enterprise, JAVA.) Somewhere, I even took a swim in Forth… I think while working on an S100 Cromemco box at the U.
But lots of folks simply love Python. Maybe it has to do with the cute snake logo (’tis would make one hell of a tatoo,) but I guess one of these days (soon ?) I am going to have to take a rainy weekend and play.
Pro/Con of this article seems not-too-biased: https://www.slant.co/versus/110/127/~python_vs_c
Ray
In fact Micro-Python is just a program written in C that works as an abstraction layer
[flyboy74 – Thu Aug 02, 2018 9:32 pm] –
This board of course doesn’t have to be programmed in Micro-Python it can be programmed in Ardunio/C/C++In fact Micro-Python is just a program written in C that works as an abstraction layer
I would not call micropython an abstraction layer … like a wrapper to expose an API. It is a mostly a C++ program that is an interpreter that offers an object-oriented language.
But, I must look over the code base before I get too far as to the architecture.
Ray
abstraction-layer/wrapper/interpreter is splitting hairs 
it is another layer that further removes you from machine instructions to a higher level more human like syntax.
David R. Tribble explains it this way:
The next version of the C standard was ratified by ISO in 1999. Officially know as ISO/IEC 9899-1999, Programming Languages – C, it is referred to in this document as “C99”.
The C++ programming language was based on the C programming language as it existed shortly after the ANSI C standardization effort had begun. Around 1995 an ISO committee was formed to standardize C++, and the new standard was ratified in 1998, which is officially known as ISO/IEC 14882-1998, Programming Languages – C++. It is referred to in this document as “C++98” or simply as “C++”.
Though the two languages share a common heritage, and though the designers involved in the standardization processes for each language tried to keep them as compatible as possible, some incompatibilities unavoidably arose. Once the programmer is aware of these potential problem spots, they are easy, for the most part, to avoid when writing C code.
abstraction-layer/wrapper/interpreter is splitting hairs
Maybe, but I think that because Python (and micropython) both have a REPL (think “shell”) that abstraction-layer or wrapper is not an appropriate description of the micropython software product; although the software guts could be described in such terms.
I do not think the above “hairs” really matters… what matters is that MicroPython seems to be a well conceived Python implementation with extensive compatibility to the mother language. As I stated earlier, I am not a Python programmer, but the MicroPython implementation appears to be worthy of a rainy weekend play.
Ray
[mrburnette – Thu Aug 02, 2018 2:27 pm] –
Micropython.Just have not taken the “next step” to learn the language. I must have been a baby when I studied Fortran at the University as part of my EE training. I had already had 3 years of exposure to Cobol and Fortran “set me free.” UNIX System V and C came a few years later during employment. Later, C++, VB, VBA, and numerous “Enterprise” languages (CA’s Visual Objects, Borland C++ Enterprise, JAVA.) Somewhere, I even took a swim in Forth… I think while working on an S100 Cromemco box at the U.
But lots of folks simply love Python. Maybe it has to do with the cute snake logo (’tis would make one hell of a tatoo,) but I guess one of these days (soon ?) I am going to have to take a rainy weekend and play.
Pro/Con of this article seems not-too-biased: https://www.slant.co/versus/110/127/~python_vs_c
Ray
@ray
to an extent the language i’d use would depend on its support in an IDE and eclipse with CDT works really well with c++ and java
as a result i stick with that. in the same way i’ve not explored python in any depth other than messing with some scripts which are often part of some apps
i’ve been trying to find a way to debug on python, and accordingly it is there
https://docs.python.org/2/library/pdb.html
but i’ve not tried that as well
and on micropython, i think it is an attempt to put some ‘high level’ language on a mcu, so that things are ‘simplier’. it is a noble aim nevertheless but that it won’t fit on bp / mm
oh but forth do fit. Jean-Claude Wippler – Jeelabs, is one of them who have explored that frontier
https://jeelabs.org/article/1608d/
I like to think of Forth as 4th … as in my 4th choice of languages.
Ray
Python for me is a BASIC-like language with added OO features. It is well known for its slowliness and huge waste of resources. OTOH, it has a large code base. But I am repelled by its tab-sensitive formatting that reminds me of good ol’ Fortran 
I stick to C/C++ for embedded development to get the most juice from the smallest possible devices, so having these high-level languages ported to “small” MCU is just good to attract persons familiar with the language on computers, but are a total waste of resources, especially RAM, which is scarce and the first limit you wil bump into.
Of course, there are some exceptions to this rule: Forth, which can produce some extremely efficient code, but that you will be unable to decipher just’3 months after you wrote it 
And eLua, for which the interpreter is contained in a single extra-pure C source file. It has been discussed to by JeeLabs:
https://jeelabs.org/book/1548d/
The disadvantages are well quoted here : Resource hungry and slow. This of course means it doesn’t suit slow processors or low RAM but certainly something like a ESP32 with psRAM has dual core 240Mhz with over 4mb flash and over 4mb RAM has no trouble running MP code faster than C code on a much slower more traditional MCU processor.
The advantages is it is much faster to develop and debug code as you don’t have compile each time and code is more portable between platform e.g STM32 to ESP32. Another huge advantage of python is the human readability of the code as it syntax as quoted is more like basic but way more featured. Python code is also much more compact needing less lines of code so this both makes development faster but also easier to read the code.
The making blocks by indent did screw with my head when I first started with python but now that I am used to it I like it as my code is always very well set out making it again more human readable.
This a fallacy you shouldn’t fall into. Dumb code metrics have always been dumb, code readability is about how easily humans can read, now how many “things” a computer counts. Yes, Python is much more readable than say C++, but it’s not because of line count.
[MoDu – Thu Sep 13, 2018 9:43 am] –
Python code is also much more compact needing less lines of code so this both makes development faster but also easier to read the code.This a fallacy you shouldn’t fall into. Dumb code metrics have always been dumb, code readability is about how easily humans can read, now how many “things” a computer counts. Yes, Python is much more readable than say C++, but it’s not because of line count.
I personally find the less lines makes it easier for me to read because much of the code fits on the screen of the computer without scrolling. I find being able to see so much all at once of what the program is doing makes it much easier to follow. This becomes amplified with the removing of { and } for blocks and also beciase python syntax is so human readable I don’t tend to use commits much where as C I have much more commits.
Exactly. If you want more lines on screen, use a smaller font.
