When talking of side effects, more often than not, we are referring to the bad ones. This is especially true when they are involuntary and unexpected. But here is the story of a good one, a side effect of using Python to script a Graphical User Interface in embedded control applications!
As per my previous post, I have re-written from scratch some kind of replacement for the GOL lib (Graphical Object Library) using Python from the primitives up. The new module, baptised EZ.py, appears to run on a PIC32MX7 board (PIC32MX7-MMB from Mikroe) just as fast and fluid as the original (C) library. This is not too much of a surprise as eventually all the heavy lifting (graphical primitives) are exactly the same ones (MAL Graphics Lib) and Python is doing just what it is design to, scripting, that is chaining activities together to produce the same presentation and responses to user input.
This is all nice and dandy, but the real fun begins when you realise that the same exact code “could” ran on any PC, MAC or Linux box producing the same exact output. The distance between “could” and “will” is actually very small in this case, as all we need is suitable “replacement” for the embedded primitives (MAL) with something more standard in the python world. And by “replacement” I mean, binding, that is wrapping some code around another library, something that, I am starting to appreciate, is very easy to do in Python.
My alternative primitives of choice: pygame.
Once more the effort was extremely limited in time (and number of code lines, less than a hundred) and voila’:
These are screen captures from my Mac where a 320×240 (QVGA) size window is now used to emulate the screen of the PIC32MX7-MMB board. Since I don’t have a touch screen capable model, I used pygame primitives to replace the mouse for the touch screen input.
This is great for prototyping a user interface and debugging it. In fact it is so easy and addicting that I wonder if it does not make a tool such as GDD unnecessary or simply obsolete!?