-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Examples -> Memory Errors #5
Comments
BTW, this was with Mu set to minify. |
Was the jsfiddle minifier used to compress the cyber:bot library? Im not having the same experience yet... |
@AndyLindsay tried the jsfiddle with me in a Hangout today. I think the micro:bit complained about a missing function. Maybe we could try this with you to see what we're doing differently? |
Okay - I've been really picking at this memory thing tonight, and I'm starting to see a pattern, and hopefully from there some clues on how to both optimize it and write programs. It appears that there is both a total character count restriction AND a restriction on variables (and definitions?) in memory - and the second one is actually the culprit in this case. I'm going to optimize the .min file by hand for now - and it doesn't appear that we need to be compressing the examples themselves. What DOES make a difference is adding variables where they aren't essential. For example:
versus:
|
@AndyLindsay, I have the example working with an improved version of the newest library. Give it a try again. Use the .min version in this repo, that should work well now. |
No out-of-memory errors are apparent in current examples. They are all pretty concise. An IR Multi Bot example would be another better test. Navigation courses and dance routines also tend to be longer. |
This apparent limitation is very disturbing particularly because of what it may mean for users of our library... for example, are we taking away their ability to create another variable simply because we chose to use one more? |
From Carlos @ micro:bit - The user Python code itself is stored in flash together with the MicroPython runtime, the text is UTF-8encoded and written to a known location with a small header. If you are using the online editor there is a current limitation of 8KBs, but in the future we want to move towards using the MicroPython filesystem instead. This method can use for code all the flash space not claimed by the MicroPython runtime (which is about 20KBs at the moment). For RAM there is 10KBs of heap available for the user Python code. Because the Python code is interpreted and executed by the run time, any allocations are stored in memory and later freed by the garbage collector when possible. I recommend this article from the upstream MicroPython docs, as it contains quite a few useful tips about memory: http://docs.micropython.org/en/v1.9.2/pyboard/reference/constrained.html The micro:bit port of MicroPython includes the “gc” and “micropython” modules with useful functions to analyse the memory on run time, so I would recommend having a look at those as well, as it can help to give you a better sense of how memory is being used. An example running from the REPL:
|
Examples that worked as-is with the 10/25 library get a memory error when updating to the 11/1 library. A temporary solution is to trim methods from the library that the example does not use.
The text was updated successfully, but these errors were encountered: