Is anybody familiar with the micropython project? It is another kickstarter success, and it’s target platform is almost identical to the spark.
https://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers
The two projects have very similar goals (making microcontroller programing easy and fun). I personally much prefer programming in python when possible, so this intrigues me.
Micropython on a photon wireless stack? Yes please!
Love the idea. But it would require some serious commitment from the spark team and community. Certainly the python aspect would open the core to a much wider audience…
Just getting it on the phton probably wouldn’t be THAT hard as they use an ARM chip from the same family. Pretty much you would just have to interface the C wifi drivers with python and you would be good to go. (you can do this through the micropython C API, which is very similar to the standard C API)
Being able to re-program the board over the air on the other hand might be more challenging – but I don’t think it would be all that difficult. Really you just need to send text files and where they should be located!
I’m sure there are a bunch of things that would be difficult, but those two aspects are doable.
All hypothetical here… But why over the air? Local reprogramming over USB would be acceptable right? i.e. It’s the way I program mine today. It’s also one of the benefits of micro python i.e. It’s interactive nature. I can spin up the local micro python interpreter and just turn pins on and off and test code out. Debugging is simpler and it’s easier to be creative.
What I would love is all that PLUS the spark cloud. Now that would be a winner.
Oh ya, I would absolutely want both. In my opinion OTA is overated for development – but for implementation and updating code on devices in the field it is invaluable.
What I’d love to see is micropython running as a task inside our system firmware so that it’s simple to build bindings from python to Spark.connect(), Spark.function() et. al. (Presently, I believe the python interpreter completely replaces the Particle firmware.)
This would also mean we can take advantage of the split system/user firmware and have the micropython interpreter stored and running entirely as part of system code. The user firmware wouldn’t be compiled C++ but a set of python modules (either as text or compiled) that have been cooked into a firmware image.
@mdma is correct, pull request mentioned allows MicroPython to be compiled against STM32 F2 family and replaces whole Particle firmware. This was a first proof of concept to see if F2 can even handle micropython. Well it does, so the next step would be to run micropython on top of our stack, as a “user firmware”, so you could just flash it instead of Blink
Hi Guys,
I can confirm that we are going to release VIPER ready for the Particle Core on June 24th.
We will develop the porting for the Photon as soon as we will receive it from Particle, we hope to be ready for it in one month.
VIPER installation on the Core and Photon replace the official firmware installing on them the VIPER Virtual Machine and a dedicated RTOS.
However, going back to the original Particle firmware is always possible doing a factory reset.
We are very happy to collaborate with the Particle Team and Community and we would be very glad to develop with your support and contribution a VIPER module for the Particle Cloud.
Visit www.viperize.it for updates on our releases.
I can confirm that this is working as advertised. Python on the Core! What a relief.
I actually like their IDE better than the Particle IDE. Local compilation and uploading is much easier than the cloud stuff. Viper also has useful libraries for stuff like multitasking, sensor reading etc.
Note that Viper is in beta so be prepared for rough edges. Some functionality is not there yet: wifi, OTA upgrades, specific sensors, Viper iOS app.
The Viper guys are very responsive. Some bugs reported were fixed within hours.
Any chance of a walkthrough / video about how all this works specifically on the Photon ? I’m having trouble imagining what this is like in practice. If I viperize my Photon will I lose the ability to use all of the hard work by the community like the libraries and such. Will I lose features like Spark functions and variables ?
I would love to use Python instead of C but it wouldnt be worth it if I lose the features and libraries I depend on.
Hi @Rockvole
There is a detailed step by step guide on how to viperize a photon or a core on the Viper documentation
If you viperize your photon the Particle firmware on it will be replaced by the Viper Virtual Machine. You can always revert to the Particle firmware by using the Viper IDE dedicated button.
Viper and Particle are two different operating systems for embedded boards, they have different libraries and examples. However, we would like to work with the Particle Team and community for adding to viper the support for the Particle cloud.
Ok, thanks for the information.
Will there be Python versions of the sensor libraries available ?
That would be ideal since it would be easier to understand for many people than ‘C’
But I guess that these types of low-level libraries have specific
timings so would be different for every Viperized device - unless
there is some kind of hardware device driver ?
Hi @Rockvole
Please use the Viper forum for questions and doubts related to the Viper Suite. We don’t want to abuse of the Particle friends hospitality
However, Viper includes various sensors libraries and many other will come. The Viper VM take care of differences between hardware platforms allowing developers to write multi-board compatible code