Reorganizing this blog.

I decided it's time to reorganize the domain name setup for this blog. Previously, it was accessible via two web addresses:

• blog.sensicomm.com 
• sensicomm.blogspot.com 

 One side effect of this setup is that the blog's cookies are set up under my sensicomm.com domain. I decided that I don't like the idea of scripts that I didn't write and don't control running under  the identity of a domain that I do control.

So in the new setup this blog is still accessible and will appear unchanged using the blogspot address. The sensicomm address contains static copies of all previous postings, but not any comments made on those postings.

If you have a web site containing a like to an old blog post, you might want to update the link. For example,

1. http://blog.sensicomm.com/2015/09/pebble-watch-programming.html
2. http://sensicomm.blogspot.com/2015/09/pebble-watch-programming.html

The old address of this post[1] now points to the static copy of that post, while the new address[2] contains both the post and any comments.

Lattic iCEcube2 on Debian

I recently started looking at Lattice chips for a project that needs a fairly small FPGA. They have small devices that are significantly lower in cost than the larger Xilinx Spartan chips I've used in the past. To explore further, I ordered the ICE40HX1K eval board ($22) and downloaded the free iCEcube2 IDE for my Debian stable(Jessie) 64-bit PC.
The first try at installing the IDE hit issues:
 error while loading shared libraries: libXext.so.6: cannot open shared object file: No such file or directory
The library is installed, so obviously the IDE wants the 32-bit version. I haven't tried to work with 32-bit stuff since Debian went to the multiarch approach, so that led to a new learning experience. Previously one would install ia32 versions of the needed libraries. After a bit of googling, I found that the current approach is (as root, or using sudo):
dpkg --add-architecture i386 # Include 32-bit stuff
apt-get update  # Add in the lists of 32-bit packages.
apt-file search libXext.so.6 # Find out what package I need - libxext6 in this case.
apt-get install libxext6:i386 # Add the 32-bit version of thepackage.
Now, the install fails because it's missing libpng12.so.0, so repeat the apt-file search and apt-get install steps for that. In Total I ended up installing  libpng12-0:i386, libsm6:i386, libxi6:i386, libxrender1:i386, libxrandr2:i386, libxfixes3:i386, libxcursor1:i386, libxinerama1:i386, libfreetype6:i386, libfontconfig1:i386, libglib2.0-0:i386.
With that, iCEcube2 installs and runs.

Now I can start playing with the eval board when it shows up.

Notes:

hackaday.io/project/6592-dipsy/log/24272-installing-icecube-2-on-ubuntu-14042-lts  Pointed me in the right direction to complete the install. Their Dipsy project uses the Lattice chip, and looks interesting.

Pebble watch programming to extend battery life.

These are my observations to date on battery life with the Pebble classic watch. I figure the data will be of interest to other watch face developers.

For my own Pebble watchface I wanted:

• Simple digital display with seconds counter.
• Show current date.
• Large characters to be readable in poor light conditions.

Once it was running, I wanted to measure and optimize battery life. The watch reports battery state in 10% increments, so I track the level changes as a function of time.
Pebble has some hints online at developer.getpebble.com/guides/best-practices/battery-perform-guide/ . Basically, they say to do as little as possible when servicing the timer ticks, and minimize the portion of the screen that's updated.
The plot here was obtained with the watchface shown in my previous post: blog.sensicomm.com/2015/09/pebble-watch-programming.html . The green lines are the first version: I call the routines to update everything on the screen every second. For the blue line, I update the seconds display every second, but the rest of the display only updates every minute. For the red line, I update the seconds every second (obviously), the hour and minute update when the minute changes, and the day updates every hour. The short magenta line is like red, except I turn the backlight off (instead of auto) and turn the watch off at night. Bluetooth was off in all cases.
Observations:

• The time from end-of-charging to 90% battery level varies widely, from a few minutes to many hours. My guess is that the battery keeps trickle charging even after the display shows charge is complete: the shortest times to 90% were when I took the watch off charge immediately, and the longest were when it was connected for an hour or so after the indicated completion of charge.

• That said, minimizing unnecessary screen updates appears to make a significant difference in power use: an additional day or so before the battery drops to 40% remaining power.

• I probably won't bother keeping the backlight off or turning the watch off at night: the savings don't seem that great and the inconvenience is significant.

• The screen backlight was in auto mode: it comes on for a few seconds when the watch shakes. It did occasionally come on during all tests (except magenta). No sure how much difference it made.

Again, this is for the Pebble Classic; no idea how it works on other Pebbles.

Pebble watch programming.

Time for a new watch. I chose the Pebble classic because I like the idea of a daylight-readable (e-paper) display and multi-day battery life between charges. The fact that several were available on ebay at good prices didn't hurt either.
Yes, I do love the display. It's a crisp and clear monochrome, easily readable in sunlight. In the photo, you may notice a bit of "rainbow" effect to the left of the time and date. That seems to be a polarization effect: it's noticeable when wearing polarized sunglasses or with indirect illumination from a clear sky. In direct sunlight or artificial light the rainbows go away.

Programming

The watch has an ARM chip in it, so of course I have to develop my own watch face. Pebble has an online development platform, but I decided to install the SDK on my Debian PC. I got the SDK from developer.getpebble.com/sdk/ and installed it per the instructions, which includes installing several libraries and python packages. A couple of notes:

• The "pip install -r requirements.txt" command takes a long time to run -- several minutes.
• I did not install the Pebble-supplied ARM compiler: it requires a later version of glibc than I have installed. I already had a compiler installed (blog.sensicomm.com/2014/02/stm32-on-linux-again.html), and it seems to work fine.
• To tell the SDK where the existing compiler is:
• cd $HOME/pebble-dev/PebbleSDK-3.3/
• ln -s  /opt/gcc-arm-none-eabi arm-cs-tools

And it works. I was able to compile a sample program using the "pebble build" command and install it using Bluetooth and an Android phone.

HDMI-VGA adapter for Raspberry Pi

This year Santa left an HDMI to VGA adapter under the christmas tree. I have an old LCD monitor with only a VGA input while the Raspberry Pi and Beagleboard/Beaglebone boards only have HDMI outputs.
The specific adapter is under $10 from seeedstudio.com, although I see a bunch of others on ebay and other sites that look similar.
Setup on the Raspberry Pi was pretty easy - only one Google search. Had to edit the /boot/config.txt file to force the Pi to use the HDMI output and to set the screen resolution (both VGA and HDMI can report screen resolution back to the host, but it doesn't seem to happen with this setup).
Configuration info was found at www.raspberrypi.org/forums/viewtopic.php?p=269212.
Internally the adapter is just a Chrontel CH7101A chip to do the HDMI-VGA conversion, and an Everest Semiconductor ES7144LV audio output chip. My unit pulls about 180 milliAmps from the +5 volt output of the HDMI connector. That's way more than the 50 mA maximum (according to Wikipedia), but the Pi is driving it without any problems. I haven't tried the adapter with Beagles yet, but research so far indicates that they require an externally powered adapter because they can't supply enough current via HDMI.
Caution: poking around inside will most likely void the warranty and might smoke the adapter and/or the Beagleboard. You're on your own if you try something like this:
Interestingly, there's space on the lower right corner of the PCB for a USB connector as an alternate +5 input. I took out the zero-ohm resistor (R1, just to the left of the USB connector footprint), and brought out 3 wires: Ground, HDMI +5 out, and +5 power in. Now I can just connect the +5's together for the Pi and should be able to use external power for the Beagles.

Debian on BeagleBoard classic.

I have one of the original beagleboards with the omap3 processor, which is ARM+DSP coprocessor. Originally it used the Angstrom Linux distribution, which uses bitbake to build the kernel and all related software tools. I saw recently that Debian is now supported on this device; I like to run Debian on everything including my PC's, BeagleBone Black, and Raspberry Pi (raspbian - almost Debian), so why not on the beagleboard as well?
My hardware setup is a USB-serial adapter from a Linux (Debian, of course) host to the serial port of the Beagleboard. I also have a Sabrent USB-Ethernet adapter on the Beagleboard.
The "official" instructions seem to be at elinux.org/BeagleBoardDebian, which I found from beagleboard.org/project/debian. Per those instructions, I downloaded the netinstall package from github.com/RobertCNelson/netinstall (using git of course), and put it on a 16GB SD card using the command:

sudo ./mk_mmc.sh --mmc $SDCARD --dtb omap3-beagle --distro wheezy-armhf --firmware --serial-mode

On my PC I have SDCARD=/dev/sdb, because that's where the memory card shows up when it's plugged in. MAKE SURE you get this right, because you could wipe out a disk on the PC if you get it wrong. I decided to uses the --serial-mode option to work from the serial port and avoid any HDMI display issues.
Moved the SD card from the PC to Beagleboard, powered up, and got a typical Debian install menu on the serial port! I used

minicom -D /dev/usb/prolific2303 -b 115200 -o

to connect to the USB-serial port. The Beagleboard serial port does not use the modem control lines, so had to turn off the "Hardware Flow Control" and "Modem has DCD" options in minicom.
The netinstall process was just like installing Debian on a PC: select some options and wait for it to download a bunch of packages. It found the Sabrent ethernet and used it with no problem; device usb0 shows up as a network device as well, so it should be possible to install by using a USB connection to the PC host, but I didn't try that.
Finished the install, rebooted the Beagleboard, aaaannnd - nothing happened!!! Load process just stopped in uboot. After a few hours of screaming, hair-pulling, and spelunking in uboot macros, I found the problem:
I had set up /boot as a separate partition.
The uboot macros look for  /boot/uEnv.txt on each partition and then boot Linux using that partition as the root partition. Made /boot a normal directory instead of a mount point, patched up /etc/fstab, and uboot brought up Debian with no problem.
Did my usual Debian tweaks (sensicomm.blogspot.com/2013/01/my-debian-tweaks.html) and everything seems to be working as expected.

Goats and Coffee

OK, this post is way off normal topics. Last month my wife and I were part of a team that visited a non-government organization working on economic development in Guatemala. The project related to raising goats and fighting the coffee rust fungus that's been causing so many problems in Central America.
I put together a writeup that gives more background on the problem and how it's being approached: www.rothweiler.us/guatemala-2014 .
It's outside my area of expertise, but looks like an interesting approach that makes good use of local resources. Comments (positive or negative) from folks with more experience are welcome.