I only discovered uPython a couple of weeks ago and want to congratulate the development team for an excellent contribution to the embedded software industry.
I have limited embedded software experience but am enjoying learning from other folks code examples and am about ready tointo my first aplication with a PyBoard and possibly an ESP8266 NodeMCU board.
When not playing with uPython, I'm building an IOT business monitoring water pumps for inefficiency operation and I reckon the PyBoard will be an excellent platform for developing this type of application, particularly when I advance to the LoPy (LoRa enabled) board. I'm interested in understanding how to develop and assess the quality of code. Can anybody recommend a book or online resource which will help me understand how to develop code which is reliable, modular and easy to maintain and debug as a library of applications etc?
I'm also interested in hearing from anyone interested in earning a bit of extra cash by working with me helping me accelerate my uPython development skills and capacity, not sure about the protocol of using this site to recruit developers but hope it's OK. I look forward to sharing more of my experience with the forum in future months.
Developing maintainable uPython code.
Re: Developing maintainable uPython code.
What you are asking for here is literally a career goal of all professional (and many hobbyist) programmers. We spend decades learning, practicing, working on small and large projects, reading books, online articles and scientific publications, experimenting, analyzing existing code, etc. just to get a little bit closer to the ideal. It's as if you entered an art gallery and asked for some quick tips about becoming a famous artist.
It doesn't help that the experience is often pretty domain-specific and only applies within a certain context. For instance, when I first saw some of the fragments of MicroPython's code, I felt almost physical pain, and my skin began to crawl -- this was against everything that I've learned in my career. I'm still not comfortable with some of this, but I'm being told that it's necessary due to the limited resources with which MicroPython has to run, and I believe it. It still shows how specific this kind of knowledge is.
It doesn't help that the experience is often pretty domain-specific and only applies within a certain context. For instance, when I first saw some of the fragments of MicroPython's code, I felt almost physical pain, and my skin began to crawl -- this was against everything that I've learned in my career. I'm still not comfortable with some of this, but I'm being told that it's necessary due to the limited resources with which MicroPython has to run, and I believe it. It still shows how specific this kind of knowledge is.
Re: Developing maintainable uPython code.
@deshipu, encouraging to know that I'm not alone in trying to adjust my thinking to a new paradigm, and figure out how best to apply this great creation to maximum effect. I'm sure that this innovation will be regarded as a step-change in embedded systems design a few years from now. Its refreshing to work with a technology which is elegantly simple and intuitive, but at the same time can achieve a great deal of functional benefit with limited resources.
I'm coming to realise that part of my confusion in the past with software dev has been the many layers of 'OSs', tools and 'frameworks' which usually sit between the developer and the 'bare metal' (a new term which i love). The tools may provide a familiar environment for traditional sw engineers, but at the cost of additional obscurity and often massive complexity and compatibility problems. The fact that in uPython I can import just the services which i need for my application and directly manipulate the limited resources with a few simple commands is a revelation but obvious when you understand. I guess my hesitation derived from the question "Can it really be this simple?" - I'm gradually building confidence to conclude that it seems it is.
You used two very important words in your reply, 'domain' and 'context', very hard to understand how important context is when you are deep in the middle of a swamp, and unless you've spent a lot of time swimming in swamps, its difficult to spot the alligators! The most satisfying experiences over the past 5 years of my IOT journey have been when a small team of folks with open minds and complimentary domain begin to understand and experience how important context is to understanding a multi-disciplinary problem, and can reach a consensus which is much greater than the sum of the parts.
Nevertheless as with any powerful tool there are good ways and not so good ways of using it, I'd like to see a section of the forum pulling together best practice and good design. Bad design is useful to examine too because we can learn faster through our and others mistakes.
I've not spent long enough with uPython yet to know where to start, but just having this dialogue has helped me think about these questions with renewed confidence.
I'm coming to realise that part of my confusion in the past with software dev has been the many layers of 'OSs', tools and 'frameworks' which usually sit between the developer and the 'bare metal' (a new term which i love). The tools may provide a familiar environment for traditional sw engineers, but at the cost of additional obscurity and often massive complexity and compatibility problems. The fact that in uPython I can import just the services which i need for my application and directly manipulate the limited resources with a few simple commands is a revelation but obvious when you understand. I guess my hesitation derived from the question "Can it really be this simple?" - I'm gradually building confidence to conclude that it seems it is.
You used two very important words in your reply, 'domain' and 'context', very hard to understand how important context is when you are deep in the middle of a swamp, and unless you've spent a lot of time swimming in swamps, its difficult to spot the alligators! The most satisfying experiences over the past 5 years of my IOT journey have been when a small team of folks with open minds and complimentary domain begin to understand and experience how important context is to understanding a multi-disciplinary problem, and can reach a consensus which is much greater than the sum of the parts.
Nevertheless as with any powerful tool there are good ways and not so good ways of using it, I'd like to see a section of the forum pulling together best practice and good design. Bad design is useful to examine too because we can learn faster through our and others mistakes.
I've not spent long enough with uPython yet to know where to start, but just having this dialogue has helped me think about these questions with renewed confidence.
-
pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Developing maintainable uPython code.
@Aquax While MicroPython is a great tool for accessing hardware, there are a number of factors to consider when using it on bare metal. There is a set of tutorials in the official docs http://docs.micropython.org/en/latest/p ... index.html. Alas the menu structure makes these a little hard to find; apologies if you've already read these.
If you're new to the Python language you might want to look at http://legacy.python.org/dev/peps/pep-0008/ - this offers a set of coding style guidelines. Adhering to these makes code easier for others to read and maintain.
There has been considerable discussion here and on GitHub on standards for writing device drivers. As far as I know these ideas haven't been condensed into an official document but reading around will give you some pointers if you plan to do this.
If you're new to the Python language you might want to look at http://legacy.python.org/dev/peps/pep-0008/ - this offers a set of coding style guidelines. Adhering to these makes code easier for others to read and maintain.
There has been considerable discussion here and on GitHub on standards for writing device drivers. As far as I know these ideas haven't been condensed into an official document but reading around will give you some pointers if you plan to do this.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.