Difference between revisions of "PineTime Hardware Wishlist"
Jump to navigation
Jump to search
Line 7: | Line 7: | ||
* 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 tech could be explored. [//en.Wikipedia.org/wiki/Transflective_liquid-crystal_display A transflective LCD] would probably be a nice option. Or potentially OLED? | ||
* 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. | * 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. | ||
* 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 | * 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! | ||
* A full redraw on the display takes 120ms at the very least, which is 8Hz. A smooth scrolling/usage/animation experience would be 30Hz minimum, preferably 60. I heard a rumor that the SPI connection to the display is a bottleneck. Can this be fixed? | * A full redraw on the display takes 120ms at the very least, which is 8Hz. A smooth scrolling/usage/animation experience would be 30Hz minimum, preferably 60. I heard a rumor that the SPI connection to the display is a bottleneck. Can this be fixed? | ||
* Some sort of scroll wheel would be nice for convenience. | * Some sort of scroll wheel would be nice for convenience. |
Revision as of 21:22, 24 February 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
- Used sensors should be NDA-free and preferably also blob-free
- Other display tech could be explored. A transflective LCD would probably be a nice option. Or potentially OLED?
- 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.
- 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 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!
- A full redraw on the display takes 120ms at the very least, which is 8Hz. A smooth scrolling/usage/animation experience would be 30Hz minimum, preferably 60. I heard a rumor that the SPI connection to the display is a bottleneck. Can this be fixed?
- 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 saving the current time to allow the main MCU go to deep-sleep.
- nRF5340 update: QSPI, CryptoCell + Secure Key Storage, has more RAM, a coprocessor and the possibility to expose USB through power pins
- 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 and Segger RTT)
- Connect the pin of LCD controller that allows RD/WR from it in order to save RAM on the MCU.
- 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.
- BMA421 accelerometer doesn't have a datasheet (it seems private to some hardware integrators): take it off and put alternative with open documentation.