Handheld E-ink pocket PC on Arduino

Similar projects worth following
I want to create power efficent PPC with E-ink screen, GPS, GSM\GPRS and all this on Arduino. The goal is to achieve an approximate running time of 3 to 4 thousand screen refreshes and a conditionally infinite waiting time.


  • Done: Low power sleep on Teensy3.6
  • Done: Connect screen and write something on it
  • Done: Draw maps on screen
  • Working: Connect GPS with low power modes support
  • Waiting: Connect buttons shield
  • Waiting: Connect GSM with low power modes support
  • Working: Create 3d device body in OpenSCAD
  • Waiting: Order 3d body
  • Waiting: Create screen backlight
  • Waiting: Create PCB 
  • Waiting: Order PCB
  • Waiting: Assembly device
  • Waiting: Test lifetime

  • 1 × 4.3inch WaveShare EPaper screen module
  • 1 × Teensy 3.6
  • 1 × NEO-7M GPS
  • 1 × SIM800L module
  • 1 × Polulu 3.3 Step-up module

View all 9 components

  • "Wish" style API

    Sergey12/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

    Sergey12/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

    Sergey12/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

    Sergey12/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

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates