Pico vs 8bit Compiler

[commie]

Hi Folks,

Just recently, I discovered the Pi Pico.
Well, I'm well versed with 8051/AVR 8 bit support and coding and dont see an immediate need for more power and in fact, I haven't really had an experience for more processor power.However, the Pico uses two programming avenues, 1)program with c compiler or 2) Program with interpreter/microPython the Pico's can be had for £3 per pc in qty(5) and can run at 130MHz offer about 220kb ram 2Mbyte flash.

I have always thought interpreters to be inefficient though? what do you think?

[rstofer]

Inefficient depends on your frame of reference.  If MicroPython is fast enough for the application, who cares whether it is interpreted or compiled?  Java is interpreted...

I was just playing with the Pi Pico and MicroPython last week.  I'm starting to really like it.

I bought a Pico Breadboard to hold the device and provide for buttons and LEDs plus a small breadboard.

https://www.amazon.com/components-Raspberry-Board-Breadboard-Multi-Purpose/dp/B08TM2VHFF

I added some bumpers to the underside of the board:

https://www.amazon.com/Cabinet-Adhesive-Stoppers-Cushions-Cupboard/dp/B08GC8VZ3C

All in, this is a pretty nice development platform and MicroPython is also pretty slick.

There's a pretty good book for newcomers:

https://www.amazon.com/Get-Started-MicroPython-Raspberry-Pico/dp/1912047861

[commie]

Inefficient depends on your frame of reference.  If MicroPython is fast enough for the application, who cares whether it is interpreted or compiled?  Java is interpreted...

I was just playing with the Pi Pico and MicroPython last week.  I'm starting to really like it.

I bought a Pico Breadboard to hold the device and provide for buttons and LEDs plus a small breadboard.

I added some bumpers to the underside of the board:

All in, this is a pretty nice development platform and MicroPython is also pretty slick.

Agreed!, what I should have said, interpreters are slow whilst running microsoft basic running on a 1MHz R6502?

[Doctorandus_P]

I have bought a few We-Act "Black Pills" with an STM32F411 on it and soldered on a 25Q16, and while wondering what to do with it, I spend an afternoon in flashing micropython on it.

http://micropython.org/

I am still confused though what sort of advantage micropython has over C++.
Maybe it has some use on controllers such as the (also supported) ESP32 if Micropython has direct support for a HTTP server to generate some web pages on the fly and can combine that with live measurements, MQTT and other higher level protocols.

Do note though that I've been programming in (mostly) C and C++ for some 30 years and have only moderest interest in Python itself. Which means, C and C++ are my default languages and I'd have to have a good reason to do anything in Python.

But even then, I have the tendency to just skip micropython and use "normal" Python on a small single board computer such as the BBB, Cubieboard, or one of the Olimex boards that are linux-capable.

[commie]

Do note though that I've been programming in (mostly) C and C++ for some 30 years and have only moderest interest in Python itself. Which means, C and C++ are my default languages and I'd have to have a good reason to do anything in Python.

Hi,

If you can program c then all the better because you then hop from processor to processor. Obviously, if you you are smart with c then that is the better option.

[rstofer]

I am still confused though what sort of advantage micropython has over C++.

A lot of the current work in Machine Learning is being done in Python simply because the modern libraries are written for Python.  It seems to me that at some point there will be some synergy between the host CPU running Python and peripheral gadgets running MicroPython communicating over some network.

But even then, I have the tendency to just skip micropython and use "normal" Python on a small single board computer such as the BBB, Cubieboard, or one of the Olimex boards that are linux-capable.

MicroPython isn't full Python by any stretch.  But it shares some libraries and is syntactically similar and it seems to me that this will become more important in the very near future.

MicroPython supports Berkeley Sockets:

https://docs.micropython.org/en/latest/esp8266/tutorial/network_tcp.html

[Just_another_Dave]

I have bought a few We-Act "Black Pills" with an STM32F411 on it and soldered on a 25Q16, and while wondering what to do with it, I spend an afternoon in flashing micropython on it.

http://micropython.org/

I am still confused though what sort of advantage micropython has over C++.
Maybe it has some use on controllers such as the (also supported) ESP32 if Micropython has direct support for a HTTP server to generate some web pages on the fly and can combine that with live measurements, MQTT and other higher level protocols.

Do note though that I've been programming in (mostly) C and C++ for some 30 years and have only moderest interest in Python itself. Which means, C and C++ are my default languages and I'd have to have a good reason to do anything in Python.

But even then, I have the tendency to just skip micropython and use "normal" Python on a small single board computer such as the BBB, Cubieboard, or one of the Olimex boards that are linux-capable.

I think that one of the main advantages of micropython is allowing to add scripting capabilities to IoT devices. The main logic and signal processing routines can be programmed in C or C++ while using python to provide some flexibility by allowing to change high level logic without updating the firmware. Therefore, I see it as an alternative to forth or similar languages instead of one to C

[westfw]

the Pico uses two programming avenues, 1)program with c compiler or 2) Program with interpreter/microPython

3) Program with Arduino.  One could say that that's still C (or C++), but it's a MUCH "different experience" than using the SDK and build environment that RPi provides for the Pico.  (The RPi build environment is likely to be unfamiliar and annoying to many "embedded systems" engineers.  And RPi seems adamant about not supporting anything simpler.  Sigh.)

[rstofer]

I haven't explored the boundaries of the idea but MicroPython also supports threads.  The documentation refers the user to the CPython implementation

https://pyneng.readthedocs.io/en/latest/book/19_concurrent_connections/cpython_gil.html

Of course, with C, we can just port FreeRTOS.  It's better if a port already exists...

[hli]

I am still confused though what sort of advantage micropython has over C++.

No memory management. Which solves quote a big range of errors which can be hard to detect when using C/C++ (as I'm currently working a project involving C++ on a LPC1769 I can attest to how nerve-wrecking these can be).
Being able to script also means you can use a REPL to try your code step-by-step, and experiment with libraries, instead of a "code-compile-download-test-swear-repeat"-cycle.

[commie]

No memory management. Which solves quote a big range of errors which can be hard to detect when using C/C++ (as I'm currently working a project involving C++ on a LPC1769 I can attest to how nerve-wrecking these can be).
Being able to script also means you can use a REPL to try your code step-by-step, and experiment with libraries, instead of a "code-compile-download-test-swear-repeat"-cycle.

Yep, I know what you mean, language c is not a doddle to learn, I have tried a few times to conquer c but when I try and read some code previously written, I find I can't remember the syntax of intricate steps. So, anyway I use and find Bascom AVR to be very good as well, I treat Bascom just like a high level assembler and Bascom AVR fills all I need.

Just to note micropython delivers pre stored constants at around 17 digits of precision, also, wrote a small program, to find factorial of a number, I entered 79! and it returned about 80 digits of the factorial result.I'm impressed.

[commie]

the Pico uses two programming avenues, 1)program with c compiler or 2) Program with interpreter/microPython

3) Program with Arduino.  One could say that that's still C (or C++), but it's a MUCH "different experience" than using the SDK and build environment that RPi provides for the Pico.  (The RPi build environment is likely to be unfamiliar and annoying to many "embedded systems" engineers.  And RPi seems adamant about not supporting anything simpler.  Sigh.)

Cpython and micropython are well documented and free to use, no restrictions. I would have at a guess, python will become the de facto programming language within a few years time.It's buzzing with mathematical features.

[rstofer]

It is worth reading the Pico datasheet.  Maybe not all 649 pages of it but at least enough to get a flavor.  I hadn't done that, sadly...

https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdf

There is a bunch of C code given in the datasheet and it's pretty clean stuff.  Concise and to the point along with plenty of comments.  It is all part of the SDK but I haven't downloaded that either.  I've just been playing with MicroPython.

FIFOs between the cores is pretty cool and so are the 32 hardware spinlocks.
Never heard or them before but the Interpolator gadgets seem to be oriented at audio and array indexing.
And the uC uses the ARM standard NVIC interrupt controller...

There's a lot more to this uC than just an Arduino in a different package.

[commie]

Just want to point out that python is a program written in c, so go figure...

[brucehoult]

Yep, I know what you mean, language c is not a doddle to learn, I have tried a few times to conquer c but when I try and read some code previously written, I find I can't remember the syntax of intricate steps.

That weird. I find basic C absolutely trivial. It maps so easily to assembly language. Scheme is really great too.

But the languages which are supposedly used by beginners (or at least inexpert) such as Python, JavaScript, or AppleScript I find absolutely incomprehensible.

[hli]

But the languages which are supposedly used by beginners (or at least inexpert) such as Python, JavaScript, or AppleScript I find absolutely incomprehensible.

Its because they introduce and use concepts which are not known in C (or Assembler). Learning a different syntax for the same concepts is usually easy, but learning new concepts is hard.
Python is not too complicated in that regard, it mostly removes the 'easy to get wrong' things that other languages have and replaces them by something simpler and less error-prone. Yes, if you are used to going to the bare metal this makes things more complicated, but OTOH the more high-level parts (e.g. algorithms and actual function logic) are getting easier.
Javascript, with its 'everything is either an object of a function, and we derive anything else from there' is a different matter. Its probably easier when you have not seen other languages before because this remove conceptual ballast which gets in the way. (Displaimer: I'm currently learning JS for earnest. Discovering how you do a module system when you only have functions and objects was kinda enlightening for me).

[SiliconWizard]

The C language is one of the "simplest" languages out there. Purely in terms of *language*, Python or Javascript are much more complex.

But that's not the main issue for beginners IMO, at least the way they are usually taught programming these days, and for the fact they often want to quickly achieve non-trivial things.

C is simple, but needs significant boilerplate code for even simple stuff. Say you want to handle dynamic lists of objects; it's very easy in Python, while in C, you need to master a number of concepts.

Another factor is the languages you mention are dynamically typed. Although this can introduce a range of new problems of their own, it's still much easier to handle for beginners.

[commie]

Hi folks,

My pi pico (pack of 10) arrived today, struggled at first but I came across this utube channel:
                           
                                 

This video is quite good, but there are others...

[commie]

The C language is one of the "simplest" languages out there. Purely in terms of *language*, Python or Javascript are much more complex.

Then you say,

C is simple, but needs significant boilerplate code for even simple stuff. Say you want to handle dynamic lists of objects; it's very easy in Python, while in C, you need to master a number of concepts.

This appears as a contradiction, on the one hand, c is simple then on the other, you say... 'its very easy in python, whilst c you need extended knowledge and much more code overhead.

[NorthGuy]

C is simple, but needs significant boilerplate code for even simple stuff. Say you want to handle dynamic lists of objects; it's very easy in Python, while in C, you need to master a number of concepts.

This appears as a contradiction, on the one hand, c is simple then on the other, you say... 'its very easy in python, whilst c you need extended knowledge and much more code overhead.

It is not very difficult to organize lists of objects in C and you can create lists in many ways as you see fit.

Python is an interpreter, which is already a huge overhead which you do not see.

[SiliconWizard]

The C language is one of the "simplest" languages out there. Purely in terms of *language*, Python or Javascript are much more complex.

Then you say,

C is simple, but needs significant boilerplate code for even simple stuff. Say you want to handle dynamic lists of objects; it's very easy in Python, while in C, you need to master a number of concepts.

This appears as a contradiction, on the one hand, c is simple then on the other, you say... 'its very easy in python, whilst c you need extended knowledge and much more code overhead.

It is absolutely not, and your reaction actually shows the crux of the matter! C is a simple language, and as such, doesn't have many built-in features, which often makes it hard for beginners.
Python has a lot more features built in the language, which objectively makes it a more complex language.

A simple language doesn't imply it is simple to use. And, we would also need to define what "simple to use" exactly means. If easy means, as is often the case for a beginner, that you can quickly achieve a given result with the language without having to spend months learning it, then surely Python and the like are simple to use. Now if it means, very readable and easy to maintain, that's yet another matter.

If you want to understand what "simple" means for a programming language, I suggest reading Niklaus Wirth (which, incidentally, has had ideas of even simpler languages than C.)
To better understand the point, knowing all of C is absolutely possible once you have properly learned it, and the knowledge will linger on - that explains brucehoult's comment. I dare you to know all of Python, even after years of use. Even a seasoned Python programmer will probably have to open a book, search Google or spend time on Stackoverflow (or the like) on a regular basis. Probably the younger generation finds this appropriate and "easy", but that's only from a restricted point of view. That makes you dependent, whereas with simpler languages, in the sense I explained, you can be fully autonomous.

Many beginners these days don't care about becoming autonomous, or learning things that they'll still remember in decades, they just want to achieve things.

[commie]

Python is an interpreter, which is already a huge overhead which you do not see.

Correct, if you reread my first post, I did say python was an interpreter which are woefully inefficient. I have also said previously that python uses 64bit floats 16/7 digits of precision, I have today found out micropython(a reduced subset of python) only kicks out 7 digits of precision which is the same as my AVR 8 bit compiler, so much for a 133MHz 32 bit pi pico rp2040.

[rstofer]

Interpreted languages may not be as fast as compiled languages but they still have a place.  I don't write much production code.  Mostly, I write a program to get an answer to something, run it a couple of times and it's scrap.  I may spend hours writing and debugging the code and, here, Python might be a little faster than compiling C++ for every iteration.  In any event, repetitive execution is more dependent on my thinking and typing speed than on the language.

If there were consensus on the Internet, it would be that Python is on the order of 30 times slower than C++.  In many cases, this simply doesn't matter because it doesn't account for the edit->compile->execute->loop.  Edit consumes the vast majority of the time.

[rstofer]

Python is an interpreter, which is already a huge overhead which you do not see.

Correct, if you reread my first post, I did say python was an interpreter which are woefully inefficient. I have also said previously that python uses 64bit floats 16/7 digits of precision, I have today found out micropython(a reduced subset of python) only kicks out 7 digits of precision which is the same as my AVR 8 bit compiler, so much for a 133MHz 32 bit pi pico rp2040.

There is a trend in the AI world to move back to 16 bit floating point.  It's faster and has sufficient precision for the application.  For the most part, values used in neural networks are constrained to be between -1 and +1.  If they aren't, they're forced into compliance with a squashing function.

Why have many bits of precision to a value you can't control +- 10%?

Here's a research paper on alternative forms of representation.  Even 8 bit floating point is being considered/used...

https://research.fb.com/wp-content/uploads/2018/12/Rethinking-floating-point-for-deep-learning.pdf

Floating point on the Pi Pico is an interesting subject.  Highly optimized floating point functions are included on the bootrom.  Start here:

2.8.2.2. Fast Floating Point Library
The Bootrom contains an optimized single-precision floating point implementation. Additionally V2 onwards also
contain an optimized double-precision float point implementation. The function pointers for each precision are kept in a
table structure found via the rom_data_lookup table (see Section 2.8.2.3).

There are functions for both single and double precision floating point.  No, the Pico doesn't have a FPU but it makes a notable attempt.  And, for machine control (robotics), floating point may not be all that important.

https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdf

The Pico is a very interesting device.  It might be worth the time to actually read through the datasheet.  Or at least skim the Table of Contents. Not many low end uCs (like the ATmega328) have an MPU much less hardware support for an RTOS in the form of hardware spin locks.  The fact that it is a dual ARM core brings quite a bit of capability.

This chip is NOT just another Arduino!

[SiliconWizard]

Interpreted languages may not be as fast as compiled languages but they still have a place.  I don't write much production code.  Mostly, I write a program to get an answer to something, run it a couple of times and it's scrap.  I may spend hours writing and debugging the code and, here, Python might be a little faster than compiling C++ for every iteration.  In any event, repetitive execution is more dependent on my thinking and typing speed than on the language.

Yep. Well, one benefit of an interpreted language is not just with compile times, it's also with the fact you can execute pieces of code on the command prompt directly and get an 'immediate' result. This gets you some interactivity that you just can't get with a compiled language unless you implement that yourself in said language. Or unless you use a debugger, but a debugger is typically a much clunkier way of testing things interactively.

If there were consensus on the Internet, it would be that Python is on the order of 30 times slower than C++.

Well yeah, although it's very hard to get a figure for this because it's heavily dependent on the kind of code.
But while it's slower in general, it's not just that: it's pretty hard to use it for anything with real-time requirements, notably because AFAIK, it heavily uses dynamic allocation and with garbage collection, on top of that. Now I don't know Micropython, so I don't know whether some things have been optimized for embedded work or not. People knowing more about it can chime in.