- #Utime micropython full#
- #Utime micropython software#
- #Utime micropython code#
- #Utime micropython Pc#
- #Utime micropython series#
But, the desire for a compact log format was raised above as a possible requirement to save storage or transmission, which may be a constraint on the logging module.
#Utime micropython software#
In general, I prefer the logging module to be as simple as possible (KISS), so that it is as reliable as possible (my main use case has been logging errors/warnings/information is software systems). But does anyone/anything know when that has happened? And when an anomalous value is recorded, is that a genuine event, a measurement fault, or an artefact caused by post-measurement problems? If the logger or data is corrupted, all bets are off, and the data logged is unreliable anyway.
#Utime micropython full#
The logging module could detect if the sample interval has drifted and put in a full timestamp, and should put a full timestamp periodically anyway. What if your data becomes corrupted, or your logger loses correct time? It is better to always have a timestamp per recordĪgreed that independent lines of log are more robust, but it depends on your usage and requirements (as nearly always in software design).
#Utime micropython series#
But if logging at fixed intervals, only an opening time is required, followed by a series of comma-separated values. Having said that, I can think of circumstances where the deltas (particularly fixed deltas) could be useful. It can be essential when the timestamp is in a message rather than a log. Sorting is not usually required in single logfiles, but can be useful when combining events from different sources.
I stick to self-contained readable timestamps, in a sortable format. It all depends how far one is prepared to go, how small versus readable one wants the file to be, how much processing when read can be tolerated. Using "+20," saves almost 20% for the above example. "+n," can be used to set a specified increment and just the "+" can be used subsequently. Using hexadecimal, base 32 or 64 can reduce things further, as can using '*n' to repeat digits "29*3" -> "29999". Raw case time.strftime('%A, %1d%n %B') 'Sunday, 10th October' Timezone time.strftime('%Z %z') 'LOCAL +0000' Week of Year (Mon) time.strftime('%W') '99' Week of Year (Sun) time.strftime('%U') '88' Thanks a million for helping this (nearly old) chapĬode: Select all No format time.strftime() ' 19:07:39' I just wish I had your level of knowledge folks. Only simple stuff, but given I am 58, and only seriously started learning last year I am happy with that.
#Utime micropython code#
I've dabbled for many years, but only really started to learn code during the lockdown last year, and I now have three commercial apps for sale. As I have been hacking the time module it might get pushed up the To Do list.įair play, you guys damn well amaze me with your coding expertise. It's something I have long been intending to implement for the Pico which has plenty of space for adding extra functionality but haven't got round to it. I am guessing it's not included by default because it's a bit of an overhead for the kind of constrained systems MicroPython was intended for.
#Utime micropython Pc#
Not having 'time.strftime()' in MicroPython has often frustrated me, in having to figure out what I need to use, having to rewrite Python code before that can be used, and having to include both versions so it runs on my Pi, PC and Pico. It's taking the "array subscripts start at zero" orthodoxy way too far Formatting the date took me a little while too, as Python's array slicing and joining syntax was written by a maniac.
0 kommentar(er)
