close-circle
Close
0%
0%

Pix-Watch - stm32l4 based smartwatch

A smartwatch with an cortex m4f at heart. using awesome components and imagination to bring it to life.

Similar projects worth following
close
The Pix-Watch is an stm32l4 based smartwatch, it features a 1.44" tft touch screen, 32bit STM32 ARM processor, extra QSPI flash and accelerometer, all in a neat case.
The idea is based upon the Retrowatch and Piwatch.
it has a 230mAh lipo battery.

The Pix-Watch started off as a follow-up of the zerowatch from the Pix-Project.

The Pix-Watch uses an ST microcontroller, uses the Arduino IDE and has custom software written for it.

it's hardware specs are:
- up to 80mhz Cortex M4F MCU
- 128 kilobytes RAM
- 512 kilobytes system FLASH, hosting the firmware
- 1.44 inch high color tft screen (ili9163, 128*128px) with capacitive touch input
- extra flash (4mbyte)
- 3 axis accelerometer
- vibrating motor

some of the featureset:
- framebuffered
- fast drawing
- easy to extend api
- alpha blending
- open source software and hardware


currently the work that is done:
- set up a development platform


work that is in progress:
- inline app framework
- case design
- write initial test code


currently the work that is to be done:
- pcb design
- better graphical command set
- usage of the onboard RTC for the time
- external flash image/app loading support
- creating a SDK
- application eeprom storage (storing variables in the eeprom emulation)
- application syncing and flashing using USB

  • 1 × pix-watch core board mainboard
  • 1 × 230mah lipo 30x20x5mm
  • 1 × casing 3D printed
  • 1 × Ili9361c with capacitive touch AliExpress: kingtech has those

  • update 8: performance boosts

    Ramon Schepers02/27/2017 at 18:10 0 comments

    ramon here with a small update again

    just wanting to state the performance increase per watt in floating point math (for alpha blending/antialias) between the original design (teensy 3.2) and the new design (stm32l4)

    first i'd like to point that the stm32l4 is at least 3x as power efficient as the teensy 3.2 spec wise

    in reality more like 4x as the teensy 3.2 requires a seperate bootloader ic which used power too.

    then the floating point math.... the teensy 3.2 doesn't have a fpu at all, so calculations are slow for sure, on the stm32l4 however, the speed is over 7x compared to the teensy, as the stm has a fpu.

    compared to power effifiency, this is about a factor 28 or so (fpu math / watt)

    also, might change from the stm32l476 to the stm32l496 with 320k of sram in the future, for bigger apps, and it's more power efficient too. (91micro amps / mhz versus 100 micro amps / mhz)

  • Update 7: changing plans!

    Ramon Schepers01/07/2017 at 00:03 0 comments

    Ramon here

    As some might have noticed I'm not satisfied with the teensy as MCU and am going to switch to a stm32l4 MCU, I already have the display working, and am going to ditch Bluetooth, because I want to keep it minimalistic.

    The tact buttons will be replaced by a capacitive touchscreen, and will behave similar to how Android wear does things (basic gesture control yay!)

    Another design change is the whole PCB , I'm aiming for a 34*15mm 4 layer one.

    I'm going to try my best to get it somewhat waterproof (pogo pins for charging/programming it using a dock and no buttons should allow me to achieve this.

    Also, the teensy 3.2 has no fpu, so alpha blending was veeery slow, this is solved by switching the MCU, giving a boost of 7x at the same MCU clock =)

    Anyhow, this is the update for now.

  • update 6: lack of motivation and delays

    Ramon Schepers05/26/2016 at 11:04 0 comments

    Ramon here

    as you guys might've noticed this project isn't updated that much lately, it's because i can't really find the motivation to continue right now. (don't worry, the project will be finished!)

    Atomsoft (who would do the pcb design) hasn't let me know anything about the current state of the design sadly. (it's been over 2 weeks now)

    anyhow, in some positiveness:

    i got some time to redo a small part of the code, and am planning to redo the inline app API once i get my motivation back.

    for now, have a video demonstrating some of the graphical commands, including antialias circles.


  • update 5: notes and graphics

    Ramon Schepers03/25/2016 at 22:36 0 comments

    Ramon here,

    since the ble113 was going to be a pain to get right (Atomsoft said so) (it needed a extra swd on the pcb to program), we ditched it and switched to a BC118 module, which works over uart as well, and uses only 9uA in sleep mode

    both modules are about the same price ($11 at digikey) so that won't be an issue.

    i have also started on cleaning the code and spread it over multiple libraries, otherwise we'd have one library of 1500+ lines of code.

    code will be up soon hopefully.

    update 31march:

    i also have created some one graphics command, namely: a circular loading bar (demo vid on end of log), and have put as much graphic commands in the RAM because it simple speeds things up.

    i also tried overclocking the teensy, and it runs stable up to 144mhz, any higher will cause the system to fail (under voltage on the mcu i think).

    note that this is 200% of the recommended mcu clockspeed, so i don't recommend going over 96mhz (which is already a overclock on the teensy).

    video for the circular loading bar drawing is here:


  • update 4: switching bluetooth module

    Ramon Schepers03/13/2016 at 02:47 0 comments

    ramon here,

    first of all, i wanted to say i'm sorry for not updating this project that often.

    right now i came across a new bluetooth module, namely a ble113 module, which is bluetooth low energy, and has very low power modes (to a few hundred nA).

    compared to a hc06 it is about 1/2 the size, and consumes way less power.

    this also results in a smaller pcb size (in theory).

    i haven't gone further with coding as of now. but i will resume coding soon (hopefully within a week)

    yes, this project is far from dead!

    offtopic: i just looked at the time here, 3:45AM, i should go to bed now. :P

    that's it for this update.

  • update 3: framebuffer is getting real, loooong battery life

    Ramon Schepers01/19/2016 at 06:00 6 comments

    Ramon here,

    i have been working again on the watch a few days ago till now, with 2 main things in mind: framebuffer and extending the battery life

    i succeeded in both, mainly in battery life: 370 hour standby (17 hour runtime @ 24mhz) time (no accelerometer yet) (total powerdraw: 1.35mA)

    which is like 15 days of standby on a 500mAh lipo!

    right now i am working on porting all graphic commands to use the framebuffer.

    only downside of the framebuffer is: it consumes half of the teensy 3.2's RAM.

    but thanks to rossum's microtouch framework we can still have 9kilobytes of RAM for apps, which is 1/8th more than an Arduino mega!

    also, cool thing of the framebuffer is: alpha blending is possible, and some people might have seen a video of me demonstrating it. but for those who didn't, here's the video:

  • update 2: pcb getting smaller

    Ramon Schepers11/26/2015 at 14:23 0 comments

    Ramon here,

    i got the pcb length from about 50mm to 43,5mm while still having the same features (moving traces and components)

    meaning it is only 3,5mm longer than my zerowatch project (which has a length of 40mm)

    still wondering for a framebuffer.

    that's it for now.

  • update 1: tft speed measurements

    Ramon Schepers11/16/2015 at 23:45 0 comments

    Ramon here.

    i just wanted to share my benchmarks of the breadboarded system.

    a full screen refresh (fillScreen command): 15ms (aka 66fps)

    a fullscreen (128*128) bitmap loaded from microsd using the sdfat lib: a bit lesds than 125ms (aka 8fps)

    you might wonder why the bitmap loading is so inefficient?

    well, because we read a horizontal line of pixel data from the microsd in a buffer, draw that to the screen and repeat the process for each vertical line (128x total)

    this really wants me to go for a framebuffer, loading the whole bitmap into it, then adjust pixels where needed, and then push it like the fillScreen command.

    this should speed things up drastically.

    however, it has it's downside too: a single framebuffer consumes 50% of the RAM we have.

    note: we can't read from the screen, as there's no MISO line on the screen, otherwise we could have used that as a framebuffer, saving us 32kb of ram at the costs of 30-40ms (guessed) drawing speed for a framebuffer (if we do i in internal RAM it would take like 20-25ms (guessed))

    tell us what you think is the best, go without or with framebuffer?

View all 8 project logs

Enjoy this project?

Share

Discussions

ctjet wrote 03/30/2016 at 20:28 point

This looks really cool, do you have any idea of what the final cost will be?

  Are you sure? yes | no

Ramon Schepers wrote 03/31/2016 at 10:22 point

i expect the price for a single watch (excluding casing and battery) to be about 55 USD, where the costs is as follow:
$20 teensy parts
$12 bluetooth
$5 screen
$3 pcb
$15 other components

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

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