Difference between revisions of "PineTime Hardware Wishlist"

From PINE64
Jump to navigation Jump to search
(Refactor, reorganize pinetimev2 wishlist. Add piezo buzzer suggestion)
Line 4: Line 4:


* Long pressing the button should power-cycle the watch without any software being involved
* Long pressing the button should power-cycle the watch without any software being involved
* Other display tech could be explored. [//en.Wikipedia.org/wiki/Transflective_liquid-crystal_display A transflective LCD] would probably be a nice option. Or potentially OLED?
* Other display technology could be explored.
* Touchscreen should possibly have a configurable sensitivity level for both glove-wearing and droplet-resistance. Preferably it should still be a capacitive one, a resistive touchscreen would have too many trade-offs.
**[//en.Wikipedia.org/wiki/Transflective_liquid-crystal_display A transflective LCD]
* A slightly bigger 256×256 pixel graphics display size is preferable for its binary alignment, affording some low-level simplicity – it has the property that its X and Y coordinates are each addressable with a single byte, with no out-of-bounds; its total number of pixels is 65536 (another power of 2), and each pixel is addressable with exactly 2 bytes, with perfect efficiency. The [http://Pelulamu.net/ibniz IBNIZ (Ideally Bare Numeric Impression giZmo) virtual machine], designed for fun minimalist demoscene graphics, has chosen 256×256 for its virtual display, and makes use of these simplicity advantages. If PineTime also chose 256×256 then it would be a target platform for unclipped IBNIZ demoscene programmes, which would be really fun to play around with on one's wrist!
*** Increased readability in bright daylight
* A full 16-bit redraw on the display takes 120ms at the very least, which is 8Hz (although modest optimization is possible by adopting 12-bit color). A smooth scrolling/usage/animation experience would be 30Hz minimum, preferably 60. Display redraw is currently bottlenecked by the nRF52832 maximum SPI clock (8MHz).
**[//en.wikipedia.org/wiki/OLED OLED]
*** Self-emissive display (pixels emit their own light)
*** Allows for lower power usage with mostly black screens
*** Allows for low power visual notifications (imagine an always-on small red square in the corner to indicate a notification)
* Touchscreen with configurable sensitivity
** Ideal for gloved fingers and water droplet resistance
** Preferably it should remain capacitive, as a resistive touchscreen would have too many trade-offs.
* A slightly bigger 256×256 pixel display
** This resolution is preferable for its binary alignment for low-level simplicity
** It has the property that its X and Y coordinates are each addressable with a single byte, with no bounds checking
** Its total number of pixels is a power of 2 (65536), and each pixel is addressable with exactly 2 bytes.
** The [http://Pelulamu.net/ibniz IBNIZ (Ideally Bare Numeric Impression giZmo) virtual machine], designed for minimalist demoscene graphics, has chosen 256×256 for its virtual display specifically for code efficiency.
** If PineTime also chose 256×256 then it would be a target platform for unclipped IBNIZ demoscene programmes, which would be really fun to play around with on one's wrist!
* Full screen refresh is very slow
** A full 16-bit redraw on the display takes at worst 120ms, which is 8Hz
** Modest optimization is possible by adopting 12-bit color
** A smooth scrolling/usage/animation experience would be 30Hz minimum, preferably 60hz
** Display redraw is currently bottlenecked by the nRF52832 maximum SPI clock (8MHz).
** The nRF528(33/40) has one high speed SPI master which supports 32MHz, still well below the ST7789 maximum
** Parallel data transfer could be an option, but using more GPIOs (which don't look available)
* Some sort of scroll wheel would be nice for convenience.
* Some sort of scroll wheel would be nice for convenience.
* Changed GPIO assignment so more functionality is available (i.e. NFC and VSYNC)
* Changed GPIO assignment so more functionality is available (i.e. NFC and VSYNC)
* Wireless charging, or Qi Charging capability
* Wireless charging, or Qi Charging capability
* An external RTC circuit saving the current time to allow the main MCU go to deep-sleep.
* An external RTC circuit
* nRF5840 update: QSPI, CryptoCell + Secure Key Storage, has more RAM, a coprocessor and the possibility to expose USB through power pins
** Allows the main MCU go to deep-sleep while retaining time.
** Allows time retention through MCU reset.
* nRF5840 update
** 32MHz HS SPI, QuadSPI, CryptoCell + Secure Key Storage, more RAM, a coprocessor and the possibility to expose USB through power pins
* Preferably a pre-certified MCU module with a ceramic antenna
* Preferably a pre-certified MCU module with a ceramic antenna
* Version without sensors but maybe bigger battery
* Version without sensors but maybe bigger battery
* A couple of pins on the programmer connector to allow UART while developing (currently there is a TX test point on PCB). (Note: There's ARM SemiHosting, ITM and Segger RTT)
* Pins on the programmer connector to allow UART while developing (currently there is a TX test point on PCB). (Note: There's ARM SemiHosting, ITM and Segger RTT)
* Connect the pin of LCD controller that allows RD/WR from it in order to save RAM on the MCU. (The MOSI pin for the SPI is already connected to the nor flash that shares the same pins, pin number is P0.04)
* Connect SDO of ST7889 LCD controller to MCU.
** Allows MCU to execute READ commands
** Possibility of leveraging ST7889 RAM to save MCU RAM?
* LCD must be centered on case. Currently is not and watchfaces seems different when clock is put on the other wrist.
* LCD must be centered on case. Currently is not and watchfaces seems different when clock is put on the other wrist.
* A NFC antenna around the case, connected to the NFC pins.
* A NFC antenna around the case, connected to the NFC pins.
* Used sensors should be NDA-free and preferably also blob-free. For example the BMA421 accelerometer doesn't have a datasheet (it seems private to some hardware integrators): a more open one would be much easier to develop for. Special attention should be paid to advanced features, such as step counting integration or flick detection.
* Used sensors should be NDA-free and preferably also blob-free for easier development
* PineTime SoC could support USB or have a FTDI chip with the relevant pins exposed. It could allow flashing a sealed device, just like Arduinos work. * An USB-C connector instead of a magnetic one could be used.
* Possibly replace BMA421 accelerometer
* A bigger pulldown resistor for the power button, because 100k still leaks a noticeable amount of power when the button is always on.
** The BMA421 doesn't have a public datasheet
** Special attention should be paid to advanced features, such as step counting integration or flick detection.
* PineTime SoC could support USB or have a FTDI chip with the relevant pins exposed.
** It could allow flashing a sealed device, just like Arduinos work.
** The same USB-C could also be used for charging.  
* A bigger pulldown resistor for the power button
** 100k still leaks a noticeable amount of power when the button is always on.
* Ceramic Bluetooth antenna for better signal reception
* Ceramic Bluetooth antenna for better signal reception
* Ultra low quiescent current PMIC for better deep sleep. Better shipping/storage/turned off mode. Preferably also a built-in "fuel gauge" functionality for better estimation of battery capacity
* Ultra low quiescent current PMIC
* A separate RTC or built-in functionality in the main MCU to maintain time setting through MCU reset
** Better deep sleep/shipping/storage/off lifetime
* Battery charger IC with built-in "fuel gauge"
** Better estimation of battery capacity
* Small Piezo Buzzer
** Use case would be for very short beeps (think old-school casio watch) as notification.
** Of course developers can PWM other frequency to make it sing, but piezos tend to be shrill.
 


[[Category:PineTime]]
[[Category:PineTime]]

Revision as of 14:25, 3 October 2021

This page contains a list of things people wish PineTime did differently

Hardware

  • Long pressing the button should power-cycle the watch without any software being involved
  • Other display technology could be explored.
    • A transflective LCD
      • Increased readability in bright daylight
    • OLED
      • Self-emissive display (pixels emit their own light)
      • Allows for lower power usage with mostly black screens
      • Allows for low power visual notifications (imagine an always-on small red square in the corner to indicate a notification)
  • Touchscreen with configurable sensitivity
    • Ideal for gloved fingers and water droplet resistance
    • Preferably it should remain capacitive, as a resistive touchscreen would have too many trade-offs.
  • A slightly bigger 256×256 pixel display
    • This resolution is preferable for its binary alignment for low-level simplicity
    • It has the property that its X and Y coordinates are each addressable with a single byte, with no bounds checking
    • Its total number of pixels is a power of 2 (65536), and each pixel is addressable with exactly 2 bytes.
    • The IBNIZ (Ideally Bare Numeric Impression giZmo) virtual machine, designed for minimalist demoscene graphics, has chosen 256×256 for its virtual display specifically for code efficiency.
    • If PineTime also chose 256×256 then it would be a target platform for unclipped IBNIZ demoscene programmes, which would be really fun to play around with on one's wrist!
  • Full screen refresh is very slow
    • A full 16-bit redraw on the display takes at worst 120ms, which is 8Hz
    • Modest optimization is possible by adopting 12-bit color
    • A smooth scrolling/usage/animation experience would be 30Hz minimum, preferably 60hz
    • Display redraw is currently bottlenecked by the nRF52832 maximum SPI clock (8MHz).
    • The nRF528(33/40) has one high speed SPI master which supports 32MHz, still well below the ST7789 maximum
    • Parallel data transfer could be an option, but using more GPIOs (which don't look available)
  • Some sort of scroll wheel would be nice for convenience.
  • Changed GPIO assignment so more functionality is available (i.e. NFC and VSYNC)
  • Wireless charging, or Qi Charging capability
  • An external RTC circuit
    • Allows the main MCU go to deep-sleep while retaining time.
    • Allows time retention through MCU reset.
  • nRF5840 update
    • 32MHz HS SPI, QuadSPI, CryptoCell + Secure Key Storage, more RAM, a coprocessor and the possibility to expose USB through power pins
  • Preferably a pre-certified MCU module with a ceramic antenna
  • Version without sensors but maybe bigger battery
  • Pins on the programmer connector to allow UART while developing (currently there is a TX test point on PCB). (Note: There's ARM SemiHosting, ITM and Segger RTT)
  • Connect SDO of ST7889 LCD controller to MCU.
    • Allows MCU to execute READ commands
    • Possibility of leveraging ST7889 RAM to save MCU RAM?
  • LCD must be centered on case. Currently is not and watchfaces seems different when clock is put on the other wrist.
  • A NFC antenna around the case, connected to the NFC pins.
  • Used sensors should be NDA-free and preferably also blob-free for easier development
  • Possibly replace BMA421 accelerometer
    • The BMA421 doesn't have a public datasheet
    • Special attention should be paid to advanced features, such as step counting integration or flick detection.
  • PineTime SoC could support USB or have a FTDI chip with the relevant pins exposed.
    • It could allow flashing a sealed device, just like Arduinos work.
    • The same USB-C could also be used for charging.
  • A bigger pulldown resistor for the power button
    • 100k still leaks a noticeable amount of power when the button is always on.
  • Ceramic Bluetooth antenna for better signal reception
  • Ultra low quiescent current PMIC
    • Better deep sleep/shipping/storage/off lifetime
  • Battery charger IC with built-in "fuel gauge"
    • Better estimation of battery capacity
  • Small Piezo Buzzer
    • Use case would be for very short beeps (think old-school casio watch) as notification.
    • Of course developers can PWM other frequency to make it sing, but piezos tend to be shrill.