Well, so much for micropython

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I watched the first half of a webinar on micropython on Monday. I bailed when I found that it required a 165K "kernel" installed in the target and 16K of SRAM.  micropython.org indicates on its home page that a minimum of 256K of flash and 16K of ram is needed.

 

The presenter also indicated that micropython programs are run-time interpreted.

 

Does not sound like the developers have much interest in 8/16 bit world.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does not sound like the developers have much interest in 8/16 bit world.

That's true.   Cortex M0 or better, usually.

(Also, it reminds me of of the various "Java for Embedded" efforts, which have similar footprints.)

 

Python is getting to be my go-to choice for desktop programming, though.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The advantage of C/C++ for 8-bit is that the language

is compiled directly to machine code so all of the "smarts"

are in the compiler.  Python is interpreted so the compiler/

interpreter needs to be in the chip itself, not an external

program like avr-gcc is.

 

--Mike

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

I watched the first half of a webinar on micropython on Monday. I bailed when I found that it required a 165K "kernel" installed in the target and 16K of SRAM.  micropython.org indicates on its home page that a minimum of 256K of flash and 16K of ram is needed.

The presenter also indicated that micropython programs are run-time interpreted.

Does not sound like the developers have much interest in 8/16 bit world.

 

Yes, a good example of software expanding faster than hardware can support the load ;)

 

Well almost, in this case, hardware may be catching up, as the micropython is fairly stable in size, but the choice of MCUs available with > 256k Code is growing, and their price reduces.

Another irony is that many of the uses micropython is put to, would be fine with any clean language that can run on a 8-bit MCU, but the C juggernaut has smothered many alternatives. 

- so programmers wanting to avoid C, have little choice but to jump up to the 32b MCUs that can host micropython.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The advantage of C/C++ for 8-bit is that the language

is compiled directly to machine code so all of the "smarts"

are in the compiler. 

 

 

 

Last Edited: Wed. Jun 12, 2019 - 08:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

https://github.com/micropython/micropython/tree/master/ports/pic16bit had recent updates for dsPIC33FJ256GP506A - 16-Bit - Microcontrollers and Digital Signal Controllers

 

32b MCU for Zerynth, half the footprint, low price

Zerynth Supported Devices

https://www.zerynth.com/get-started/#what-is-zerynth

...

Just 60k-80k of flash, 3-5k RAM. 

...

https://www.mouser.com/new/zerynth/

 

edit :

SAMC21 added to Zerynth Supported Devices though have to go through DesignSpark.

ATSAMC21E18A - 32-bit Microcontrollers

5-Volt 32-Bit ARM Cortex M0+ MCU with CAN-FD

...

Our Software - DesignSpark

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Jul 5, 2019 - 07:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ch is a C/C++ interpreter though with an order of magnitude greater footprint.

Raspberry Pi Zero might be a fit for Ch; otherwise, arm Cortex-A5.

Embedded and embedding Ch - System Requirements

Buy a Raspberry Pi Zero – Raspberry Pi

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where the likes of micropython, espruino and lua come into their own is when you need to something more than a simple user interface and maybe some control logic. An example is ‘iot’ where you might send/receive a json formatted packet over mobile to a server. Doing a lot of string operations in C is labourious. For the above scripting languages it is a doddle. For a state machine taking a few inputs and outputting a few bits, the effort is near identical Vs C. Also note these scripting languages are not fast - there’s a lot of overhead so any real heavy work is done by C functions and the scripting level code is just ‘pulling the levers’. If you want interpreters for the AVR, look at tiny basic and uLisp. Getting your mind around Lisp should fire up a few neurons!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about FORTH?  We used it for some graphics programming, many eons ago...compiled to very small code.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I mentioned Lisp - wasn't that bad enough? No you put the evil of Forth upon us!!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I mentioned Lisp - wasn't that bad enough? No you put the evil of Forth upon us!!!

Some of our programmers seemed very adept & efficient with forth & the product was trouble free; they seemed to really get on well with forth.   I vaguely remember they were even doing embedded mutitasking with it.

Maybe if forth was more popular it would become popular surprise

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FORTH has some attractive advantages.  It encourages producing

lots of very short functions. Branching (if-else) is complicated so

you try to avoid it, which makes for better code.  If you mess up

the stack, everything goes to ---- so many bugs are corrected quickly.

The core language is very small so you are almost creating your

own custom language for each project.  The big downside is the

difficulty in reading the code, especially after time away from it.

I hope to investigate it more someday when time allows....

 

--Mike

 

EDIT: corrected corrected

 

Last Edited: Thu. Jun 13, 2019 - 04:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

There seems to be a degree of fervour with Forth advocates and this seems to have migrated to Rust.

I was amiss at not mentioning it - considering I had been playing with mecrisp forth recently. It must've popped off my memory stack! Should've done a DUP.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Does not sound like the developers have much interest in 8/16 bit world.
Well just playing devils advocate but even in AVR8 you get 256K and 384K devices so I would have thought the 165K would easily fit. While RPi shows that Python can be used for "real time control" the fact is that's not really why you'd choose it. It's more of a systems level language and is possibly the cream of the crop in that arena.

 

These days when I just want to "throw something together" more often than not I choose Python over C/C++ as it's just so quick, easy and productive to get things done quick. I also usually stick to the supplied TK/Tcl (Tkinter) for the UI as I know every Python installation will have it (which kind of makes me wonder if the 165K of "Micropython" does have room for that?)

 

EDIT: answering my own question. Looks like the "graphics support" ends at a basic FB support:  http://docs.micropython.org/en/latest/library/framebuf.html (I guess that's OK, in my day job I work on software with elaborate UI even though there's little more than graphics primitives to call on).

Last Edited: Thu. Jun 13, 2019 - 08:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

d

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Mon. Jun 24, 2019 - 08:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Paulvdh wrote:

Ah, yes, you can use it as a timer to switch a relay twice a day.

Err no, that's not what I meant - for Rpi it exposes interfaces to all the hardware:

 

https://radiostud.io/raspberrypi-hardware-interface-programming-python/

 

Also things like:

 

Paulvdh wrote:
and the total dependence of whitespace for indentation is about the worst.

I guess that one is a question of personal preference. For me a language where indentation is mandated to show program structure rather than the kind of:

int main(void) {
if (PINB & (1 << 3)) {
if (digitalRead(3) == 17) {
PORTC = 0x55;
}
   }
   }

nonsense we see all the time here at Freaks from misused C is an absolute Godsend!

 

I'm guessing you haven't actually written much Python if you can't see the merit in this?

Paulvdh wrote:
(promises that support will finally stop in 2020)
Exactly. 3.6+ takes over completely on 1/1/20. V2 is just "legacy". In the last 3..4 years I don't think I've bothered writing anything with V2 compatibility any more - sure if you have some ancient old Python thing you want to maintain you might still be tied to V2. It's a bit like C or C++. Surely these days people are writing C at least at C99 standard and C++ at least a C++11 standard ?

Last Edited: Thu. Jun 13, 2019 - 04:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Surely these days people are writing C at least at C99 standard and C++ at least a C++11 standard ?
No for at least a few reasons :

  • customer doesn't want to re-qualify a toolchain
  • old CPU, old C
  • PIC recently made C99 via MPLAB XC8 v2; most PIC code will likely stay MPLAB XC8 v1.

 

OpusFAQ - XiphWiki | On what platforms does Opus run?

http://ww1.microchip.com/downloads/en/DeviceDoc/xc8-2.05-full-install-release-notes-PIC.pdf

MPLAB® XC8 C Compiler Version 2.05 Release Notes for PIC® MCU

...

 

3. What's New

...

3.2. Version 2.00

...

[page 14]

C99 support

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

'Tis my understanding that a lot of Linux's use Python 2 for installation and other admin stuff.

At one time, before Python 3, I think Windows used Python.  Not sure.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:

I think Windows used Python.

 

Only if it was Python#.NET

 

--Mike

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems like for AVR targets the problem is to come up with a virtual machine (VM) design that has tiny footprint and requires little RAM.    The host side could allow user to work any language that is able to compile down to the tiny VM.

 

On the target-based interpreter side, VxWorks has  a nice C-expression interpreter that allows one to peek/poke variables and call hosted C functions.  Something like that might prove useful on AVR targets.  It might require a table of C function signatures and addresses to be burned into ROM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW wrote:
Seems like for AVR targets the problem is to come up with a virtual machine (VM) design that has tiny footprint and requires little RAM.
GitHub - dwhall/p14p: (INACTIVE) Python-on-a-Chip (p14p) : a tiny Python 2.6 vm (PyMite) for 8-bit and larger microcontrollers

due to PyMite - Python Wiki

though there is hope : Python for the 8bit AVR mocrocontroller · Issue #3699 · micropython/micropython · GitHub

Opinion : start with the current dsPIC MicroPython port; consider porting that to the new dsPIC33C.

MattRW wrote:
On the target-based interpreter side, VxWorks has  a nice C-expression interpreter that allows one to peek/poke variables and call hosted C functions.
... that made the news.

If one can't afford VxWorks' sizing and accounts payable then there's Ch with your preferred RTOS or event framework.

MattRW wrote:
Something like that might prove useful on AVR targets.
A near plethora of computer languages on AVR so that may have already been implemented.

 


Build Larger, More Robust Applications with Microchip’s Expanded Dual- and Single-core dsPIC Digital Signal Controller (DSC) Family | Microchip Technology

What really happened on Mars? (VxWorks)

https://www.avrfreaks.net/forum/production-quality-avr-basic-interpreter#comment-2548386 (Ch)

 

"Dare to be naïve." - Buckminster Fuller