Micro Python development wish list

[safetyfactorman]

I hope I'm not out of line, but maybe a solution to the problems of micropython is to throw (more) hardware at it.

first, i dont know if python has a module reload, or class/type reload function, or an instance reload/memcopy, but if it did, it might allow the programmer to manage memory. the function would identify all instances and do a memory copy, and this might defragment memory. it is under programmer control, so the programmer can monitor their environment and determine when they want to do that. if memory is allocated on a block boundary unit level, it would on the face of it be really inefficient. but, if the consolidation function is efficient, then the overhead and penalty is low, because it is an assembler memory copy with variable start and fixed end.

a design idea might be to put a raid controller chip onto the board, and have multiple nonvolatile memory chips organized into raid0. This gigantic enormous nonvolatile memory pool gives the programmer a mechanism to use file i/o to manage string data, perhaps even implement a database system inside python. the raid 0 gives enormous throughput, and the file i/o functions simplify the management. so then it is simply a technique within python to utilize this feature for the specific hardware platform of micropython, and has minimal (zero) impact on the language itself. maybe a adapter board could be built with a sata controller on it, with 5 or 6 or n micro sdram chip interfaces, and then you could test throughput and efficiency that way to get a feel for how to use it to work around your problem. if you double the cost, or triple the cost of the hardware, but eliminate the problem, then you might obtain a radical solution.

[safetyfactorman]

the other idea is to have a default string size, and then defragment for all strings greater than the default size. for the strings that are < default size, fragmentation is not a problem. it then becomes a statistical problem as to what the default string size should be. default string size is under your control.

[blmorris]

I hope I'm not out of line, but maybe a solution to the problems of micropython is to throw (more) hardware at it.

I would respectfully suggest that 'solving' MicroPython's problems by throwing more hardware at it is a total non-starter. The objective isn't to provide a lean Python implementation for the equivalent of the Raspberry Pi or the Intel Edison - which is were you are competing if you start talking about doubling or tripling hardware costs. You can already run Python or any other high-level language that you want on those platforms anyway.
The objective of MicroPython is to allow programming in a very-high-level language in a place where that was never possible before - on a middle-high range single-chip micro controller. The goal has always been to keep the path clear for scaling down to smaller hardware, not up to more powerful hardware.
Not that I haven't considered upgrading the MicroPython hardware - some of the higher pin-count chips in the STM32F4 family support connecting to a high-speed USB transceiver, which would allow reading and writing to the SD card on a pyboard closer to the limits of the SD interface itself - but again, the benefit of such an enhancement has to be weighed against the hardware cost and how many people are willing to pay for it. As it is, many people seem pretty happy with the current price and size of the pyboard, but some users here have even put in some effort to run uPy on even less-expensive hardware.
-Bryan

[bmarkus]

+1

[safetyfactorman]

maxim integrated has a micro plc reference design. the micro plc architecture is discussed in one of the videos on the page.

http://www.maximintegrated.com/en/desig ... popupmodal

The arduino world is not industrial grade.

i would like to be able to use micropython to control this kind of hardware. the reason why i would like to do this is to allow the enduser to fix and maintain their own control system, and to attempt to implement KISS. I would like to add python as a computing module in addition to, or above, or in cooperation with, the existing default capabilities of the programmable controller. plcs have been designed for quite some time to allow for basic programming modules to connect directly to the backplane, and i think python, or micropython, could provide a greater set of capabilities because of its dynamic nature.

having an environment with multiple processes has benefits and costs. if the design constraint of micropython is a single console, then how it is it intended to have multiple micropython boards communicate with each other in a system?

arduino has its shields. what is the intended interface standard for micropython?

[kfricke]

dunno if this discussion gets offtopic... a wish list is still on track, but the topic also contains (current) "development". Not things MicroPython could possibly soon also be used for.

if the design constraint of micropython is a single console,

Where is this defined?

then how it is it intended to have multiple micropython boards communicate with each other in a system?

There are lots of embedded communication protocols to choose from (I²C, TWI, UART, and even TCP/IP stacks).

arduino has its shields. what is the intended interface standard for micropython?

Please study this project (search for skin in that picture)and the store (check for skins there too) page before asking such questions in this thread!

[blmorris]

maxim integrated has a micro plc reference design. the micro plc architecture is discussed in one of the videos on the page.
http://www.maximintegrated.com/en/desig ... popupmodal
The arduino world is not industrial grade.
i would like to be able to use micropython to control this kind of hardware.

I think that I see what you are asking. Maxim is pushing their Micro PLC platform (which, as far as I can tell is a specification for industrial control cards with a specified form-factor and interface to plug into a back plane which allows an industrial control system to be built in a modular way.) Several of the interface and control cards are published as reference designs, and they are encouraging people to design more. The key part of the platform is that the cards are built with all of the protection and galvanic isolation circuitry that you want in an industrial control environment.
At least one of the reference design cards (that I saw, the four channel analog input card) uses an STM32F415 chip as its controller. From that simple fact, I can say that you could port MicroPython to run on this card - though it would be up to you to then program it to do what it is supposed to do in a Micro PLC environment. Maybe that is useful, but I couldn't really say without digging in deeper. At the very least, it should be possible.
Alternately, if you wanted you could design industrial-hardened control boards to run MicroPython - MicroPython provides hooks to use most of the peripherals on the STM32F4 series micro controllers, and would welcome code to support the rest. You basically have full access to the micro controller hardware to make it do what you want, including being the brains of an industrial control board.
And with that I may have driven the discussion completely off-topic. Sorry...
-Bryan

[safetyfactorman]

Bryan,

thank you for your response. what you described is very much in the direction that i would be interested. the maxim integrated reference plc design backplane communication could be CAN, or some other standards based communication protocol that is already implemented, or could be easily implemented in python.

So the next step that i am going to take is to initiate communication with maxim integrated to see where they stand on interest in assisting with a micropython implementation.

Mark

[pythoncoder]

Can I suggest a few minor enhancements to the support for inline assembler? Primarily I'd like to see SDIV and UDIV instructions implemented. But it would also be handy to have CLZ (count leading zeros) and RBIT (reverse bits) as these are tedious to do in code.

One application for assembler is for DSP style processing of real time data. For example I have implemented a function for performing FIR filtering which runs as a timer callback filtering data from an ADC. It computes a 41 tap result in 15us, and I have tested it at sample rates of over 10Ksps.

Some potential DSP fuctions do use division and others could benefit from the bit twiddling opcodes.

[pythoncoder]

A further suggestion. Someone (Damien, I think) pointed out that it's possible to write a function in assembler and use it as an interrupt callback. While this is great, there seems to be no way for the code to communicate with the Python environment. This limits the scope of a potentially significant use of the inline assembler. A way to access global or class variables would be immensely useful.

If you define the function as a class method, you get what I believe is a pointer to the class as its first argument, but I've not found a way to use this to access class variables.