The screen
Getting the e-ink working was very easy with an Arduino, but proved to be more difficult with the EFM32... there was some source code available, but it was for an older version of the display which was both quite incompatible with the newer B13 release, and also used a comical amount of RAM as relied on a framebuffer and a graphics library for rendering text.
Even though I was developing on the LG, I wanted to be able to target a regular Gecko with only 16KB of RAM and 128KB of Flash, and no USB capability... this was a much cheaper part (about half the price) which would greatly reduce the BOM. It also can only run up to 32MHz but in theory that should have been okay. Makes things trickier with the screen, though.
So what I did was take the Arduino library that worked and ported it to the EFM32... as an AVR has virtually no memory, this slashed the memory requirements down to a line buffer. The SPI was a bit fiddly but eventually got it working.
A note on the e-ink screens... these are really closer to an analogue device than any other traditional digital screen... in order to get a clear picture it is required to write first in a particular pattern to clear any ghosting from the previous image, and then depending upon temperature, draw the image a particular number of times with suitable delays.
If you just try to draw an image once, you will still be able to see what was previously written in the same space, just a bit faded (this one has been stopped mid-write for the new frame, which causes an interesting bleed effect...).
The thing is, the longer you spend updating the screen, the more power you are consuming... and there is also a balancing act between how fast you run the processor (which will affect the SPI transfer speed) and the total power consumed to update the screen. Looking at power measurements, it seemed that running the processor flat out was most efficient in terms of total power consumption for a screen update... then sending it back to sleep as soon as possible.
To get a really clear image may take 4 redraws, but a perfectly readable image is normally possible in 2, with some degradation. This is both quicker from a UI perspective and also consumes much less power, but eventually the ghosting of previous images will reduce the contract to the point when a full clear is necessary. This generally involves an inverse image of what was previously drawn, and then alterating solid black and white... the Pervasive Displays datasheet has more information.
Something that isn't covered in great detail is the endian-ness... I found it was necessary to flip about bytes but that was quite easy to do as a lookup table.
One note about the ghosting... some e-ink displays have greyscale capability... the Pervasive unit is not designed for this, but in theory you could probably get a few shades out by carefully understanding the persistence of the image and how it varies with temperature. I decided this was beyond the scope of the favours as was up against it in terms of time!
The Bluetooth
I bought another module off the shelf to help with development... first, the Adafruit nRF9001 unit...
It is clearly targeted towards the Arduino crowd as has a 3V regulator and level translation... neither is desirable in the Notey but for a prototype it is fine. The example code for the Adafruit module talks to the Bluetooth module via. ACI, which is a simple high level interface. I was able to take the essence of the Adafruit code onto the EFM32, translating on the way into straight C, and replace the ACI section with the EFM32 port.
I've had a few issues with dropped connections, but generally the nRF8001 is a plug and play solution for sending messages across BTLE, and importantly, has a free application available for both Android and Apple devices.
In terms of supporting BTLE, Apple were in early as an iPhone 4S or later is all that is required... Android is rather more fragmented.... v4.4 is required for stable support. I picked up second hand an iPhone 4S and also a Moto G for testing. Both are relatively inexpensive now, particularly, the G which had a cracked front glass, but still perfectly functional.
Software
While there were a lot of challenges ahead just to get the hardware finished, I needed to at least make a start on the software, so worked on some font rendering. It had been a while since I'd had to do any font stuff, but decided to go slightly more advanced than I had with the engagement ring and splash out with.... wait for it... proportional fonts. No, not exactly earth shattering but means the fonts wouldn't look silly. I did consider custom kerning as well but that was really a "nice to have" rather than an essential item.
A bit squashed at the first attempt, but it works...
I found a helpful .NET application which would convert TrueType fonts into bitmaps along with size and proportioning information. These were then brought into the main code as const char arrays.
I brought in three fonts... a 12pt, a 24pt, and a 32pt. In hindsight, the 24pt is too big, as it only gave an extra row of text, but it seemed like a good idea at the time!
At this point I had some basic BTLE and display test applications working, it was time to get cracking on the real hardware...
No comments:
Post a Comment