Project Logs

Collapse

• update 8: performance boosts

  8bit-bunny • 02/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!

  8bit-bunny • 01/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

  8bit-bunny • 05/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

  8bit-bunny • 03/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

  8bit-bunny • 03/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

  8bit-bunny • 01/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

  8bit-bunny • 11/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

  8bit-bunny • 11/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