Interrogate firmware build in code

[pythoncoder]

I know this has been raised before but I don't recall reading that it's been implemented. It would be good if we could retrieve a number (becoming higher with each build) standing in for the build version. Python modules dependent on a minimum firmware build could check this and raise an exception on importation rather than have the user encounter runtime failures; code that falls running our own demo script makes us hapless coders look silly. It has happened.

I have an idea how it might be done but perhaps it 's already been implemented?

[dhylands]

os.uname has a bunch of into in it:

Code: Select all

>>> import os
>>> os.uname()
(sysname='pyboard', nodename='pyboard', release='1.4.3', version='v1.4.3-153-g32eb4b9 on 2015-06-12', machine='PYBv1.0 with STM32F405RG')

[pythoncoder]

Thanks for that. So when does release increment? On each daily build or less frequently? What's your view on the best way to achieve my end, to compare release values or to parse the version string for the date?

[blmorris]

The release number increments when the developers collectively agree (or Damien decides) that it is time to tag a new release. Sometimes this corresponds to a handful of new features / enhancements being implemented; frequently it is just that a month or so has passed and many commits have accumulated so a new release is tagged.

A new issue to discuss tagging 1.4.6 was opened yesterday: https://github.com/micropython/micropython/issues/1475

Beyond that, we can look more closely at the version string:

Code: Select all

version='v1.4.3-153-g32eb4b9

The git hash tag (hex string starting with 'g', here it is 'g32eb4b9') changes randomly with each commit, but each commit gets numbered sequentially; git commit '32eb4b9' is commit number 153 since release 1.4.3 was tagged.

[pythoncoder]

Thanks for that. Do you have a view on the merits of checking that rather than the date? The date seems the obvious way to do it and is more human readable: I can throw an exception with a message: "This driver requires firmware dated 10th June 2015 or later". But is there a valid reason for parsing the version part of the string instead? After all absolute accuracy isn't an issue here: if I specify a firmware build which is more recent than is strictly necessary the sky won't fall in

[dhylands]

I think that using the date is fine. Using the version number is slightly more precise.

If you're trying to point to prebuilt firmware (i.e. http://micropython.org/download/) then you'll probably want to use a release number or date which matches up with that page)

[pythoncoder]

My thoughts too. In case anyone is interested here is my attempt at a solution.

Code: Select all

import os
# Usage buildcheck((2015, 6, 12))
def buildcheck(tupTarget):
    fail = True
    if 'uname' in dir(os):
        datestring = os.uname()[3]
        date = datestring.split(' on')[1]
        idate = tuple([int(x) for x in date.split('-')])
        fail = idate < tupTarget
    if fail:
        raise OSError('This driver requires a firmware build dated {:4d}-{:02d}-{:02d} or later'.format(*tupTarget))

The only slight doubt in my mind is whether there are builds so old that aspects of this Python code will be unsupported.

[dhylands]

According to github, os.uname was implemented in this commit: https://github.com/micropython/micropyt ... 984215b7ff

which was dated April 21 (version 1.4.3).

You can conclude that is os.uname doesn't exist that the version is earlier than that.

If its at all possible, you should query by feature (see if the particular method you want exists) rather than query by version. Obviously, you can't always do that if the feature existed but was broken.

[pythoncoder]

you can't always do that if the feature existed but was broken.

Quite!

If its at all possible, you should query by feature

This is fine if you know precisely which feature is contentious (as in my os.uname example above). But if you've written a substantial body of code the task of figuring out which feature was the most recently implemented (and debugged) would be nontrivial and error prone. In my above example, short of testing against the oldest version of firmware available how would I check whether an ancient build would correctly run the final line with its Python3 string formatting ? One approach would be to code ultra conservatively and (in this instance) use the string modulo operator but this would lead (in general) to poor code and still wouldn't fix the problem in a proven way - the old method might still have been broken in an early release. Unlikely, I suppose, but possible.

Isn't the most practical approach to test against a given firmware build and mandate that? After all the Pyboard's firmware is easy to update and ideally we'd want users to do so regularly. Thanks to the efforts of you guys the process is painless and regressions rare.