Project Logs

Collapse

• "Wish" style API

  Sergey • 12/30/2017 at 13:04 • 0 comments

  Due to "Low power" project priority, I start to change all code of subsystems to "Wish" style. This style need me to write application in certain style. 

  Any API request can be executed momentarily, delayed or even never. So any application must check all and work in "state" patterns style.

  Let's see in example on VectorMaps application. 

  1.We look have we fresh coords or not. For me, I decide that coords with 2-3 min - still pretty fresh and we dont need to power on GPS for getting more actual coords. And if its not so fresh - we call "updateCoords" fucntion and set wish to work again for "task switcher" for 20 secs. Then we return execution from application to "task switcher".

  2. After 20 secs (or more if we sleep due to low voltage) application start again check for fresh coords. This cycle can repeat forever until application got fresh coords or we can add return to main menu after 2-3 tries for battery save. 

  This "wish" style api help to create a very similar to "tickless" work mode for Mayak. When we wait for GPS coords - MCU sleep, when we updated it, GPS sleep :).

• Project report 22\12\17

  Sergey • 12/22/2017 at 12:46 • 0 comments

  • Disable GPS reports when no sat's fix with u-blox software
  • Add connection between INT on Teensy and PPS pin on GPS ( it will wakeup MCU from deepsleep on fix)
  • Start to rewrite loop cycle code from RTC wakeup to Low Power Timer wakeup
  • Write GPS code subsystem for manage GPS power including GPS fix failure after 60 sec.
  • Add getting fresh GPS coords on refresh screen in VectorMap Application

• Planning apps

  Sergey • 12/17/2017 at 17:35 • 0 comments

  • Maps
    • Vector maps 
    • Raster maps
    • Route and waypoints
    • Compass
    • Some statistics
  • News && Article reader
  • Bookreader
    
    • txt format
    • bookmarks
  • Food ration planner
    • Provides recipes based on input data
  • Reminder
    • What to do
    • What to buy

  • Logger (background app)
    • Voltage on two points 
    • Screen refreshes counter
    • GPS coords
    • Screenshoots (optional)
  • Weather
    • Provide prediction based on updated data
    • Provide prediction based on collected data
  • Mesh network
    • Update maps over network
    • Update reminders

• About multitasking\multithreading

  Sergey • 12/17/2017 at 14:40 • 0 comments

  In portable devices projects, it is very important to think about the correct architecture of the program code.

  This project implies the execution of both a "main application task" - maps, a book reader, a weather screen, and "background tasks" - updating the weather forecast, swapping maps, etc. Usuall solution for this - is to use multi-threaded programming.
  I like multithreaded programming, but in this case I think it is redundant and somewhat wasteful in terms of energy - because we have constant flow context switching (which is a relatively cheap operation? but in the context of time it has the property of accumulating).

  An alternative to multithreaded programming in the context of multitasking is the cooperative multitask approach, where each task keeps the thread of execution exactly as long as it needs it.

  Obvious advantages:

  - It's easy to realize "idle" sleep state.

  - We do not need to sync threads. 

  - We do not spend time on switching thread context ( of course we spend some ticks on magic with pointers)

  - Execution of the program flow becomes linear and easier to debug

  Reasoning in this way, I chose cooperative multitasking for this project.

View all 4 project logs