Widgets

Just posted a couple of little designs: a switching power supply and a wideband preamp. Blank pcb's are available from Oshpark www.oshpark.com/profiles/sensicomm , and my documentation is at http://mhz100q.sourceforge.net/widgetries.shtml . Mostly for my own tests and experimentation, but others might find them useful.

STM32 on Linux, again.

Starting another project using the STM32 micro, so time to update and reinstall the toolchain. This is an update to my previous post on the topic at http://blog.sensicomm.com/2012/01/stm32-stm32f4discovery-arm-eval-board.html

Compiler

Previously I used the summon-arm gersion of GCC http://summon-arm-toolchain.org/
but the git repo says it's "not under active development" any more. They recommend https://launchpad.net/gcc-arm-embedded , which seems to be an offically ARM-supported
version.

It looks like Debian has packaged the launchpad version into the "unstable" branch: http://packages.debian.org/sid/gcc-arm-none-eabi but I'm running "stable" so I got it directly from launchpad instead. Install was simple:

• Download  gcc-arm-none-eabi-4_8-2013q4-20131204-linux.tar.bz2
• unpack in /opt,
• add to PATH
• Create symlink:  cd /opt && ln -s gcc-arm-none-eabi-4_8-2013q4 gcc-arm-none-eabi

That's my setup, the chosen directory is just a matter of personal preference.

Programming tools:

I'm using the STM32F4DISCOVERY board for development, so there are two ways to get code
into the chip:

1. Use the st-link USB input to the built-in programming hardware.
2. Connect directly to the USB port of the STM32F4 chip and use dfu-util.

I used dfu-util before. That's now in Debian, and should still work but I haven't retested it.



Code for the st-link interface is available and built with no problem:

• git clone git://github.com/texane/stlink.git stlink
• cd stlink && ./autogen.sh && ./configure && make && make install

Programs are installed in /usr/local/bin: st-flash st-info st-term st-util

An example was successfully placed in flash using:
st-flash write *.bin 0x8000000

Libraries:

The open source libraries and examples at http://libopencm3.org/wiki/Downloads built without problem using the launchpad compiler. My build command was:
PATH=/usr/bin:/bin:/opt/gcc-arm-none-eabi/bin DESTDIR=/opt/libopencm3 make install

ST has standard peripheral library source code on their website, but it doesn't come with Makefiles. A USB serial example at http://vedder.se/2012/07/usb-serial-on-stm32f4/ includes some (all?) of the ST libraries and compiles fine with the launchpad compiler. I downloaded and unpacked STM32F4_USB_CDC.zip and "make" ran without problems. I only had to change the top-level Makefile so that BINPATH points to the directory that arm-none-eabi-gcc is in
(BINPATH=/opt/gcc-arm-none-eabi/bin for my install).

HDMI Breakout Part 2

 I see the PCB in my Nov 6, 2013 post is getting some interest, so here's more info about it. The image to the left is a Kicad screenshot. The breakout connector (P1, CONN_5X2) is at the top, and pin 1 is the top right pad. Odd-numbered pins on top, and even-numbered on the bottom.
Top connections are:
1 Ground
3 HOTP-J
5 DCC_D-J1
7 DCC_C-J1
9 CEC-J1
and the bottom connections are:
2 +5V (J1 and J2 both)
4 HOTP-J2
6 DCC_D-J2
8 DCC_C-J2
10 CEC-J2

So to use the board as a passthrough connection, add jumpers connecting 3-4, 5-6, 7-8, and 9-10. Obviously, it's NOT a good idea to have a jumper connecting 1 and 2 (ground and +5V).

Here's the schematic. Pin 20 is the metal shell of the connector, not a real pin.

HDMI breakout PCB

This is probably only useful to a small handful of people, but if you're and engineer developing HDMI products that might include you.
For some work developing HDMI-compatible FPGA code, I needed to observe the control signals with a scope. So I built up this little breakout PCB. The high-speed video TMDS signals are routed directly through from one connector to the other. I tried to keep them equal length and as short as possible. Don't have any way to verify impedance and reflections, but it works ok on one TV with short HDMI cables.
The low speed (CEC, SCL, etc) signals are brought out to the header in the back in the photo. Jumpers allow the signals to pass through, or they can be disconnected to test and modify them.
The PCB is shared on OshPark. See http://oshpark.com/profiles/sensicomm  if you want to use this design. It uses standard HDMI female connectors, available from DigiKey and many other vendors. Soldering the fine-pitch surface mount pins on the connectors is a bit of a challenge. I tried soldering individual pins, but ended up using the flood it with solder and mop up the excess with solder-wick method.

Linux system clock and hardware clock accuracy?

This is a followup to the "my Debian Tweaks" post on on Jan 21. Briefly, my PC tends to spend a lot of time disconnected from the Internet, and the default clock management as implemented in /etc/init.d/hwclock.sh doesn't work very well in that case.

Debian timekeeping background

Linux on Intel-based PC's has two timekeepers, often referred to as the system clock and the hardware clock. The system clock is based on a high frequency crystal oscillator and is mainly intended for timing and scheduling programs and such. It doesn't run when the system is turned off, so it needs to be initialized with the current time when the PC is powered on. The hardware clock is a battery-backed circuit that keeps time even when the PC is off; it provides a value to initialize the system clock at power up and is rarely used for anything else. Debian systems assume the system clock is more accurate than the hardware clock, and they update the hardware clock every time the system is powered down (see /etc/init.d/hwclock.sh).

So how accurate are the crystal oscillators for system and hardware clocks?

Relative accuracies of these clocks depend on the specific PC. The only spec I found in a quick search is 500 parts per million (PPM) in the Intel HPET timer spec software-developers-hpet-spec-1-0a.pdf. The system clock may or may not be related to the HPET timer. Timing crystals are usually spec'ed at 100 PPM or better even for cheap crystals, so 500PPM sounds like a really loose spec.
The PC hardware clock typically uses a 32.768 kHz watch crystal and a battery-backed timing circuit (you can see the coin cell battery in the photos in my Dec 24 2012 posting). Watch crystals are readily available with 20 PPM accuracy specs, and the frequency is generally stable with time and temperature. For example, the CFS206 available from Digikey and other distributors is 20PPM accuracy, 3PPM per year max drift and .034 PPM per degree C temperature sensitivity. So timekeeping accuracies of a few PPM should be feasible with some calibration.
The US National Institute of Standards and Technology did an interesting study of wristwatches, tf.nist.gov/general/pdf/2276.pdf, and found that even a cheap[2] ($30) modern watch can achieve better than 1 PPM timekeeping accuracy. Older quartz watches were orders of magnitude worse, which implies that manufacturers have started calibrating the crystals in the last few years. So a PC's hardware clock should be capable of similar performance.

How good are the clocks in my PC?

Here's a quickie experiment with my main PC, an Acer Aspire 5253 notebook  with hardware clock updating disabled in hwclock.sh.  I set the hardware clock on Feb 13, 2013, and it hasn't been touched since. The hardware clock lost 6.227 seconds in 4609045 seconds (about 53 days), which is an average frequency offset of 1.35 parts per million (PPM).[1] In contrast the Linux system clock lost 0.44 seconds in 9103 seconds (about 2.5 hours), which is 48 PPM.
I checked a couple of older systems and their hardware clocks are in the 6 to 10 PPM range. So newer PC's are probably being calibrated like newer watches are. I suspect that the hardware clock is still more accurate than the system clock on the older PC's, but the difference should be less pronounced.

My Setup

The hardware clock in the Acer Aspire is more accurate than the system clock by a factor of 35, so that's why I don't let hwclock.sh update the hardware clock on shutdown; instead I manually set the time using ntpdate-debian every month or so, and manually update the hardware clock at that time. That keeps me within 3 seconds or so of true time, which is more than adequate for my purposes.
There are routines (adjtimex and such) that attempt to improve the calibration of the hardware clock and/or the system clock. They generally assume the oscillators are off by a fixed percentage from the true rate and that frequency changes due to temperature and drift are insignificant. In the 1 PPM range I doubt that that's true, so I don't bother with adjtimex and friends.

Side Notes

[1] I checked my Timex DataLink USB watch at the same time, and it lost about 2 seconds over the same interval. So it's averaging around 0.5 PPM.
[2] And if you want to spend a few thousand dollars, you can get a Grand Seiko SBGX059 which is spec'ed at less than 10 seconds per year, or about 0.3 PPM. Nice, but I think I'll stick with my sub-$100 Timex.

ARM presentation at Consultants Network of NH

On February 6 I made a presentation to the IEEE Consultants Network of New Hampshire (www.consultantsnh.org) entitled "Beagles and Berries: the World of Low-Cost ARM Computing," about the history of the ARM architecture and describing and demonstrating the Texas Instruments Beagleboard (www.beagleboard.org) and the Raspberry PI (www.raspberrypi.org).
My slides are available for download at https://sites.google.com/site/sensicommllc/Home .

My Debian tweaks

When doing a new Debian Linux installation, there are a set of basic configuration changes that I nearly always make. While the issues do not apply to everyone, I think they are common enough that many others may find them useful. As always, your mileage may vary, use at your own risk, etc.
My system is Debian Testing installed on a laptop that is typically shut down at night and that often runs disconnected from the Internet. So here are the problems I often see and my solutions:

1. PC locked by fsck. The fsck partition check program typically runs every 30 reboots or so on EXT2/EXT3 filesystems (and maybe others). This automatically happens during the boot process and, per Murphy's law, it usually happens while setting up a critical demo or presentation. The problem is that it can't be interrupted, so the group gets to spend several minutes watching the progress bar slowly move. The fix is to add the lines:
   [options]
   allow_cancellation = true
   to the file /etc/e2fsck.conf. One site that discusses this fix and potential issues is wiki.archlinux.org/index.php/Fsck
2. Boot pauses due to exim. When booting while not connected to the Internet, the exim mail handling program may hang for 60 seconds. I found that adding
   MAIN_HARDCODE_PRIMARY_HOSTNAME = mypc.example.com
   to /etc/exim4/exim4.conf.localmacros gets rid of the hang, where mypc.example.com should be changed to whatever is appropriate for that PC. Depending on other configuration options, this line might belong somewhere in  /etc/exim4/conf.d instead.
3. Annoying computer beep.For some reason, many programs seem to think a loud "beep" on errors is a helpful feature. I'm one of the legions that disagree, so I disable the pcspkr device by adding
blacklist pcspkr
blacklist snd_pcsp
to a file in the /etc/modprobe.d/blacklist directory. See www.thinkwiki.org/wiki/How_to_disable_the_pc_speaker_%28beep!%29 for example.
4. Hardware Clock. Normal PC's have a hardware clock that keeps track of the date and time of day even when the PC is powered off, and Linux also has a system clock that keeps time when running. This system clock is initialized from the hardware clock while booting. In normal Debian setups the /etc/init.d/hwclock.sh script also copies the system clock back to the hardware clock during system shutdown. That's a problem in my system because it's using the less accurate clock to reset the more accurate clock. One fix is to install the ntpdate package; then the system time gets set whenever an Internet connection comes up. Another option I use sometimes is to edit hwclock.sh to disable the hardware clock update, and just set it manually. I'm planning a more detailed post on this issue.