In my quest for the holy grail of code to run on the 216 MHz Arm7, what kind of feedback does your IDE offer to examine program and data space consumption each time the code is compiled? By code I mean python, but since its bytecode will have to run either out of flash or ram, I see it as the same question irrespective of programming language.

If the Arm7 is a harvard-based architecture, which has separate memory-addressable maps for program and data spaces, does your IDE provide a burn rate of each section (please the see the screenshot of Atmel's IDE for an example) so I can tell if I may be cutting it close when allocating variables in Python?

Also, are there any utilities in your IDE for estimating available clock cycles and/or CPU load? I understand that MicroPython supports multithreaded, so how will a developer be able to tell if he/she is overtaxing the horsepower of the Arm7 CPU that is available for running the Python scripts? I can imagine the Arm7 will hold up fine at 25 or 30 FPS with very lean Python code, but if I want to perform operations on the video data that are processor-intensive then how would I go about estimating how many clock cycles are available in order to strike a balance of processing vs frame rate? I am assuming it is possible to roll back the frame rate in order to free up clock cycles for other tasks, is that a correct assumption?

Thank you for answering this painfully detailed email. If you get back to me within the week I'll order you your favorite meal on GrubHub.

Um, so, from the IDE I can see how large the script is. That said, the script gets turned into byte code on the MP board. So, the size of the script and the actual CPU space required to run it is different.

Anyway, MicroPython basically turns any script it parses into a byte blob that is stored on your heap. That said, the code is quite efficient. Running out of heap space will be really hard unless you have like a 10K line program.

Just check the value before something and then check it after doing a thing... and take the difference. This tells you how long it took.

... note that snapshot() waits for the next image in a stream of frames. The STM32F7 processor can actually generally run at a higher FPS than what you get... but, due to an algorithm taking slightly longer to process a frame than when the next frame comes in you drop frames. That said, you're always working on the latest data so this is okay. On the Pi... it will buffer frames for good video purposes... however, this also means you're not looking at the latest data.