mirrors
/
micropython
mirror of https://github.com/micropython/micropython.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

More typos.

pfalcon 2014-12-11 14:48:24 -08:00
parent d2adef97e1
commit fed38576d4
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
ContributorGuidelines.md

@ -4,11 +4,11 @@ MicroPython is named "Micro" for a reason. We don't want to compete with CPython
Here are more specific examples:
1. For microcontroller case, reference MicroPython implementation runs on a pretty big MCU. But we would like to maintain portability to much smaller MCU cores. The theorhetical minimum requirements we'd like to maintain are 128K ROM/8K RAM. Note that those are "raw hardware" requirements. In real-world case, part of ROM and RAM may be used for RTOS/supervisor, and that lowers requirements to 100K/4K respectively.
1. For microcontroller case, reference MicroPython implementation runs on a pretty big MCU. But we would like to maintain portability to much smaller MCU cores. The theorhetical minimum requirements we'd like to maintain are 128K ROM/8K RAM. Note that those are "raw hardware" requirements. In real-world case, part of ROM and RAM may be used for RTOS/supervisor, and that lowers requirements to around 100K/4K respectively.
2. It may seem that "unix" port would not be affected by such stringent requirements, and yet it is, because one of the usecase is running MicroPython on truly minimal Linux systems with just 4 or even 2Mb of flash, half of which is taken by kernel, remaining half by support utilities, and only mere hundreds of Ks are available for MicroPython, user apps and data. So, every byte is still accounted for.
2. It may seem that "unix" port would not be affected by such stringent requirements, and yet it is, because one of the usecases is running MicroPython on truly minimal Linux systems with just 4 or even 2Mb of flash, half of which is taken by the kernel, remaining half by support utilities, and only mere hundreds of Ks are available for MicroPython, user apps, and data. So, every byte is still accounted for.
3. MicroPython is not the only small, embeddable language, so we need to stay competitive in this niche. Well-known small language is Lua, and we take it as an assessment baseline. It's our belief that many people use Lua due to lack of better alternative. With MicroPython, there's now good alternative. But we don't want people to reject MicroPython because it's "much bigger" than Lua. Note that it's necessarily bigger, because Python provides more standardized and well-defined functionality. But we want to stay at "somewhat bigger", and not "much bigger" mark. Actually, we want to maintain "minimal" MicroPython configuration, which achieves sizes comparable, or better, than typical non-finetuned Lua builds.
3. MicroPython is not the only small, embeddable language, so we need to stay competitive in this niche. Well-known small language is Lua, and we take it as an assessment baseline. It's our belief that many people use Lua due to lack of a better choice. With MicroPython, there's now a good alternative. But we don't want people to reject MicroPython because it's "much bigger" than Lua. Note that it's necessarily bigger, because Python provides more standardized and well-defined functionality. But we want to stay at "somewhat bigger", and not "much bigger" mark. Actually, we want to maintain "minimal" MicroPython configuration, which achieves sizes comparable, or better, than typical non-fine-tuned Lua builds.
# Where to contribute