search

bsiever / microbit-pxt-timeanddate

Software Based Real Time Clock (Time & Date) for the Micro:Bit
https://bsiever.github.io/microbit-pxt-timeanddate/
MIT License
4 stars 1 forks source link

Open questions #9

Closed bsiever closed 3 years ago

bsiever commented 4 years ago

Docs / Examples at: https://bsiever.github.io/microbit-pxt-softclock/

General features

  1. What other time/date formats should be included?
    1. Current ones may be common uses for U.S. notation, but what about international?
  2. Currently I'm ignoring the special cases for leap years at centuries, although including them is just another couple of mods and and AND statement. (Code is there/correct, just commented out). It seems like the major use-cases are "calendar from 0" and "calendar from now". Should I bother with the special cases for leap years? Eh...Decided it wasn't significant.
  3. Should I include anything that translates to weekday abbreviations or names ("Mon", "Tues", etc.) and month abbreviations/names? Or is that an exercise for the user? (Decided on "exercise for the user")
  4. The "stopwatch" behavior could be handy. Should I update the package to highlight this a bit more? Added completed example.
  5. I could expose access to milli-seconds, but I didn't think it'd be useful generally. Any thoughts? Decided accuracy undermined utility.
  6. How's the Palette color? I just used a default from the playground and am open to suggestions. Calling it done.
  7. Anything else? :)

Package Prep

  1. I should probably add a comment that indicates this assumes the micro:bit sleeps "regularly". (Time won't be kept if a background task can't run at least every 512s or so. The "minute changed" update requires updates at least once a minute)
  2. Action call backs: Is there a better approach than storing them like this?
    1. What about re-entrant? If there's a "on next minute" that includes a 2 minute sleep, will multiple calls be queued?
  3. How can I improve documentation? See: https://bsiever.github.io/microbit-pxt-softclock/ (Probably, but calling it good here for now)~~
    1. The block and in-line block environments aren't working, but blocks does. Just the attempts to show reporter blocks in isolation are failing.
    2. Should I use a docs directory?
    3. Blocks don't always seem to render correctly. Suggestions?
  4. Add tutorial?
  5. Is there a better way to do string formatting (padding with zeros) than the current approach, which calls leftZeroPadTo() in main.ts.
  6. Python support check? (looks ok so far)?
  7. Any guidance on test.ts for this? Or examples of effective tests are included in comparable types of extensions?
  8. Is there anything I can do to improve internationalization efforts?

Typescript vs. C++ & Performance Questions

  1. How does C++ performance/memory compare to TS. Should I move all the code to C++ with shims for all exported blocks?
    1. If I go to all C++, I've got blocks (shims) that call helper methods. Do I need to mark the helper methods as shims in my typescript to avoid compiling them? Or are unused typescript functions omitted from the executable?
  2. In typescript I'm using constants like 60*60 (for seconds in hour). I commonly do this in C++ for readability and know that the compiler will simplify. Will typescript or should I just use the final value?
  3. In typescript I'm using a const cdoy: uint16[] = [ ... ]. Will this consume ram or go to code space? (I'd want code space)
AirplanegoBrr commented 3 years ago

Any plans for MicroPython support?

bsiever commented 3 years ago

Hi @AirplanegoBrr --- I wasn't planning too, but I'll try to look into it.

My original code was prototyped in Python (https://github.com/bsiever/software-based-RTC-algorithm). I think it would be pretty easy to update it a bit to work with Micro:Python's utime. The big unknown is accuracy: I had to do some really low-level tricks to get the MakeCode version to be accurate.

bsiever commented 3 years ago

@AirplanegoBrr : A quick update. I did make a Python version using utime and tested it. (Test version here: https://github.com/bsiever/micropython-timeanddate). It lost about 4 minutes of time in about 12 hours, so it's not very accurate. I suspect this is because of the way MicroPython configures the micro:bit. I hope to look into this in a week or two, but I think accuracy will require a more complex solution than just use of Python code.