Open askvictor opened 8 years ago
This issue truly baffles me. PlatformIO compiles code, uploads it, runs it, and provides a serial connection or test runner. Doing this for MicroPython requires adding a platformio.ini
file to that project and working out the details (a complex task, which MPy currently does in its own way just fine, without having to depend on PIO).
Once that is done, and MPy is running on the µC, it's an app like any other. Things like rshell
help using MPy from a host. If using rshell
is the issue, then a new custom target can be created for PIO, which streamlines that scenario.
Most of the comments above (and I admit to only skimming some of them) seem to be about using MPy (and developing with it, since it is a build & dev system itself). But what does this have to do with PIO, which is aimed at C/C++ code?
Is this issue not simply due to conflating two different development roles, perhaps because they both use Python?
@jcw Yeah...I think that we all seem to misunderstand each others situations in some way. I know that at least I am totally confused. This might not only apply to this though. :-)
My scenario, or at least goal scenario, is that:
I develop library and framework-y things in C, for optimization and maximum compatibility.
I write the application code in Micro- or Circuit Python, because to my experience, Python is just a way better language for business logic. It is like clarity- and specificity wonderland compared to C.
In a technical sense, these two things could be done separately. But in practice, and to be productive and uninterrupted, I want to do both these things in the same environment, and in many cases, the same project.
If this is already possible and there is an example for that that I can try and I just haven't got it, great, but if it isn't, it would be awesome if PlatformIO in some way could support it, at least in some way.
I would agree mostly with @jcw, there are two aspects of this and people that might be less familiar with Python and Micropython might be trying to make it act too much like C. This is common when transitioning to Micropython.
The one use-case which is more advanced is in the production environment it is nice to freeze your code within Micropython firmware.
A good way to think of this is Micropython is the bare metal OS, and that is your firmware. Then there is your application layer, which for development usually lives in the mounted flash storage. This does not require any compiling, just syncing to your device. You should avoid unnecessary rights (flash wears) and definitely not put GIT on it, it is just for code, configs, and sometimes image assets.
You develop locally, sync files, run, test, write, sync, run, test.
One of the benefits that C does not have is the interactive REPL that python provides. It makes manual testing of modules a breeze.
You can use tools in windows and linux to a binary sync (rsync in linux and mac) which is great for syncing specific files for development. I use a script for this and a config file to say which files are synced. If you want to go one set further you could pre-compile files but that is overkill for most people.
What I was hoping for awhile that PIO would initially make a nice config and syncing scheme that would be easy to use, eventually it could get into a good custom build system to integrate custom boards and freezing firmware, but this is advanced.
Any update on this?
Bump for attention.
Add support for Micropython for compatible boards (e.g. esp8266 family)