From: R. Steve McKown Date: Wed, 15 Aug 2012 23:30:23 +0000 (-0600) Subject: Website document reorganization X-Git-Url: https://oss.titaniummirror.com/gitweb?p=oss-web.git;a=commitdiff_plain;h=785967ca4d107418807735c60fc463d729773a4d Website document reorganization * Three new categories: blog, misc, and projects * Move documents to their new proper locations * Add a blog entry about read-only root and bind mounting /var * Update copyright year in footer Blogs, being in a separate source directory structure, needs its own images/ subdir due to relative paths for images. This behavior is good, since it makes sense to separate blog images from main site images. --- diff --git a/in/aptrepo.md b/in/aptrepo.md index 9e6302d..a518168 100644 --- a/in/aptrepo.md +++ b/in/aptrepo.md @@ -2,6 +2,7 @@ title: APT Repository linktitle: aptrepo parent: Home ctime: 2009-12-10 +mtime: 2012-08-01 Repositories: [[aptrepo]]. diff --git a/in/blog.md b/in/blog.md new file mode 100644 index 0000000..762dfe4 --- /dev/null +++ b/in/blog.md @@ -0,0 +1,8 @@ +title: Blog +linktitle: blog +parent: Home +ctime: 2012-08-15 +mtime: 2000-01-01 + +This category contains various articles blogged by TMI staff. Please select +from the side menu on the left. diff --git a/in/blog/2011-07.md b/in/blog/2011-07.md new file mode 100644 index 0000000..43c02b3 --- /dev/null +++ b/in/blog/2011-07.md @@ -0,0 +1,5 @@ +title: 2011-07 blogs +linktitle: 2011-07 +parent: 2011 +ctime: 2011-07-01 +mtime: 2000-01-01 diff --git a/in/blog/2011-10.md b/in/blog/2011-10.md new file mode 100644 index 0000000..beef513 --- /dev/null +++ b/in/blog/2011-10.md @@ -0,0 +1,5 @@ +title: 2011-10 blogs +linktitle: 2011-10 +parent: 2011 +ctime: 2011-10-01 +mtime: 2000-01-01 diff --git a/in/blog/2011.md b/in/blog/2011.md new file mode 100644 index 0000000..e4b06aa --- /dev/null +++ b/in/blog/2011.md @@ -0,0 +1,5 @@ +title: 2011 blogs +linktitle: 2011 +parent: blog +ctime: 2011-01-01 +mtime: 2000-01-01 diff --git a/in/blog/2012-08.md b/in/blog/2012-08.md new file mode 100644 index 0000000..0380705 --- /dev/null +++ b/in/blog/2012-08.md @@ -0,0 +1,5 @@ +title: 2012-08 blogs +linktitle: 2012-08 +parent: 2012 +ctime: 2012-08-01 +mtime: 2000-01-01 diff --git a/in/blog/2012.md b/in/blog/2012.md new file mode 100644 index 0000000..738d6af --- /dev/null +++ b/in/blog/2012.md @@ -0,0 +1,5 @@ +title: 2012 blogs +linktitle: 2012 +parent: blog +ctime: 2012-01-01 +mtime: 2000-01-01 diff --git a/in/blog/images/wwvb-capture.png b/in/blog/images/wwvb-capture.png new file mode 100644 index 0000000..eb42bf6 Binary files /dev/null and b/in/blog/images/wwvb-capture.png differ diff --git a/in/blog/ro-root.md b/in/blog/ro-root.md new file mode 100644 index 0000000..8fb5e09 --- /dev/null +++ b/in/blog/ro-root.md @@ -0,0 +1,100 @@ +title: Read Only Root +linktitle: ro-root +parent: 2012-08 +ctime: 2012-08-02 +mtime: 2012-08-02 + +For GNU/Linux desktop installations, I prefer to have the root filesystem, which +mounts to /, be mostly read-only. This means /home (user data), /var (variable +data) and /tmp (temporary data) should be mounted elsewhere. The benefits of +this approach are several, but two in particular stand out for desktop use +cases. + + * It is much easier to do a clean install the OS. User data in /home, and + in some cases application data in /var, need not be backed up and restored + in the process. Of course recent backups should still be available. + * A root fs that is rarely written to is a good candidate for SSD (solid state + disk) storage. This allows one the performance benefit of SSD while + mitigating a critical deficiency. Current SSD technology is not nearly + as reliable as mechanical disk in read/write environments, so reducing + writes to SSD is a productive strategy. + +Placing /home on a separate partition is easy, and GNU/Linux desktop installers +have supported this for some time. And thanks to the recent introduction of +/run (see [here](http://lwn.net/Articles/436012/) to learn more), migrating +/var to a separate filesystem is now pretty easy for desktop installs. + +Of course, with multiple partitions, there is the issue of what to do if one of +them fills up. A common solution is to use LVM. Volumes are given minimal +practical sizes, and then incrementally grown as required. LVM works fine on +the desktop, but requires a bit more knowledge and effort to administer. + +[[!pquote text="A simpler solution is to use bind mounts"]] + +A simpler solution is to use bind mounts. By bind mounting /var from /home/var +and /tmp from /home/tmp, all user, variable and temporary data are on a single +partition. The root partition will be nearly static in content and size. I +currently use a 25 GB root partition on desktop installs, and that filesystem is +generally only about 25% full, even with a large number of development tools +installed. A swap partition is present of course, and the rest of the available +hard drive storage space is assigned to the home partition, which now holds the +contents of /var and /tmp. Essentially, /home, /var and /tmp share a common +large pool of storage, so there is less need for a volume manager. I am finding +this configuration to be quite optimal for developer desktops at my company. + +# Using bind mounts in a new installation + +These notes assume Xubuntu 12.04 desktop i386 installation, but a similar +process should work for other distributions and versions. + + * Boot from the xubuntu 12.04 desktop CD + * Run the installation + * Use a custom configuration when asked + * At least three partitions are required: root, swap and home + * Proceed with installation until the installer asks to reboot to continue + +Before rebooting, access a shell and type the following commands + + cd target # where the new root filesystem is currently mounted + cp -a var home/var # copy var to its new storage location + mv var var.old # can remove later + mkdir var # Need some dirs and symlinks during boot for some OSes + ln -s /run var/run + ln -s /run/lock var/lock + cp -a tmp home/tmp # copy tmp to its new storage location + mv tmp tmp.old + mkdir tmp + vi etc/fstab # add the following 2 bind mounts to end of /etc/fstab + /home/var /var bind defaults,bind,noatime,mode=0755 0 0 + /home/tmp /tmp bind defaults,bind,noatime,mode=1777 0 0 + sync + +Now allow the installer to reboot. The system should boot up using the bind +mounts for /var and /tmp, so their contents will actually be stored in the home +partition at locations /home/var and /home/tmp, respectively. Once the system +appears to be working OK, you may remove the /var.old and /tmp.old directories. + +# Upgrading to use bind mounts + +First, boot from a recovery or live CD, then run commands like the following +commands. + + mkdir /mnt + mount /dev/sda1 /mnt # replace /dev/sda1 with dev for your root + mount /dev/sda2 /mnt/home # replace /dev/sda2 with dev for your home + cd /mnt + cp -a var home/var # copy /var to its new storage location + mv var var.old # can remove later + mkdir var # Need some dirs and symlinks during boot for some OSes + ln -s /run var/run + ln -s /run/lock var/lock + cp -a tmp home/tmp # copyt /tmp to its new storage location + mv tmp tmp.old # can remove later + mkdir tmp + vi etc/fstab # add the following 2 bind mounts to end of /etc/fstab + /home/var /var bind defaults,bind,noatime,mode=0755 0 0 + /home/tmp /tmp bind defaults,bind,noatime,mode=1777 0 0 + sync + +Now remove the CD and reboot. You should be using bind mounts. Once the system +appears to be working OK, you may remove the /var.old and /tmp.old directories. diff --git a/in/blog/virtual-win7.md b/in/blog/virtual-win7.md new file mode 100644 index 0000000..77b5603 --- /dev/null +++ b/in/blog/virtual-win7.md @@ -0,0 +1,290 @@ +title: Virtual Windows 7 +linktitle: virtual-win7 +parent: 2011-07 +ctime: 2011-07-28 +mtime: 2011-07-28 + +# Introduction + +This page documents the process of converting a dual-boot Linux/Windows +installation into a Linux installation running the Windows partition under a +KVM virtual machine. This work was first performed under Ubuntu 10.10 and +11.04 versions. + +# Why virtualize Windows 7? + +During my development activities, customer needs infrequently require use of +software only available under Windows. But booting between OSes is an +incredible waste of time and drain on productivity. My work notebook, a Lenovo +X201, came pre-installed with an OEM version Windows 7 Home Premium. The +obvious solution? Virtualize Windows under Linux. + +# Microsoft licensing issues? + +[[!pquote text="The OEM Windows EULA allows for virtualization"]] + +I downloaded the EULA for Windows 7 from microsoft.com as applicable for +pre-installed OEM versions of Windows 7 Home Premium. For this OS configuration, +the license specifically allows execution of the pre-installed OEM OS when +virtualized on the same hardware. The actual text is found in Section 3.d: + +> Use with Virtualization Technologies. Instead of using the software directly +on the licensed computer, you may install and use the software within only one +virtual (or otherwise emulated) hardware system on the licensed computer. When +used in a virtualized environment, content protected by digital rights +management technology, BitLocker or any full volume disk drive encryption +technology may not be as secure as protected content not in a virtualized +environment. You should comply with all domestic and international laws that +apply to such protected content. + +# Virtualization requirements + +For Windows virtualization to be effective in my development use cases, the +following requirements and constraints must be met. Additionally, I want the +virtualization solution to support running additional virtual machines as well. + +* Run 32-bit x86 Windows 7 from 32-bit x86 Ubuntu Linux 10.10 and newer. +* Run various flavors of Linux or other Intel x86 based operating environments. +* No unnecessary dependences to software or hardware that will limit the +ability of the virtualized OS from functioning properly in the future. +* Ability to run with native disk, not disk-as-file, for improved IO +performance. +* Supports use of VT-x and VT-d, again for performance. +* Will be sufficiently performant on the target hardware when virtualized. The +X201 has an i5-M560 CPU which offers 4 cores at 2.66 GHz each, and 8 GB of RAM. +* Simple management of VMs, including configuration, start and stop. +* VMs must behave sanely in the presence of host OS power saving functionality, +like suspend. +* There is no requirement to continue to run Win7 natively. +* High end graphics are not required: no need for 3D, Aero effects, video +playback, etc. +* And finally, a reliable mechanism return to the prior physical configuration +if the VM experiment fails to work as hoped. + +# Selecting a virtualization framework + +There are a few virtualization options suitable for use on a development system, +including VMware, Xen, VirtualBox, and KVM. All can do the job, but KVM was +chosen for a variety of reasons: + +* KVM has the features needed, and is available through the standard +Ubuntu repositories. +* KVM management via libvirt is more than adequate. +* KVM can use an SDL local window for rendering the virtualized OS, for quite +good display performance. +* The enterprise features of Xen are overkill for this application. +* VMWare is not open source, so there is some concern about support for this +particular hardware in the far future (I tend to keep hardware for a very long +time). +* VirtualBox can not access USB hardware unless the purchased version is used. + +The virtual machine manager, using libvirt, is a pretty nice environment. This +management tool already supports a few different VM strategies, called +*backends*, and they are likely to improve moving forward. Therefore, gaining +knowledge about VMM, libvirt, and KVM could in the near future represent +an intellectual asset deployable against future customer needs. + +# Disk organization, pre-virtualization + +Prior to any changes, the 320 GB notebook disk drive was organized as follows: + + /dev/sda1, 1.17 GiB, Label=SYSTEM_DRV + /dev/sda2, 78.17 GiB, Label=WindowsOS_7 + /dev/sda3, 19.68 GiB, Label=Lenovo_Recovery + /dev/sda4, an extended partition container + /dev/sda5, 15.26 GiB, swap partition + /dev/sda6, 23.84 GiB, / partition + /dev/sda7, 159.96 GiB, /home partition + +* The SYSTEM_DRV apparently supports the Lenovo ThinkVantage functionality +which includes some backup and restore capability. +* The WindowsOS_7 partition is the one to virtualize, containing the licensed +OEM version of Windows 7 Home Premium that came with this notebook. +* The system boots using Grub2, which initially included an entry to boot the +Windows_7 partition. + +# The solution + +Unfortunately, the solution is not so simple as to point the VM to the /dev/sda2 +partition. First, the virtual hardware expects to see a hard drive, complete +with partition table. Second, suitable drivers for the virtual hardware must be +installed into the windows installation. I took several steps to convert +/dev/sda2 in place to look like a hard drive (kpartx, etc) but the best I could +accomplish was Windows 7 hanging during boot. Since my expertise with Windows +internals is limited, and so is the information available online, I elected to +do a clean re-install Windows from the virtual environment. + +## Create backups + +### R&R image + +Levnovo offers a recovery capability accessible by booting the Lenovo_Recovery +partition. I used this to create a recovery image for the WindowsOS_7 +partition. + +* Create a windows repair disc from the Win7 OS +* Create an R&R recovery boot disc +* Back up the current Win7 image via R&R to the Lenovo_Recovery partition. This +required removing all other prior backups because of size constaints in that +partition. +* Back up the current Win7 image to a set of DVD optical discs. It took 3: a +boot disc and two data discs. + +### Partition level backups + +Since the space was available in the Linux partition, I opted to create parition +level backups as well, which would be 'easier' to restore, at least for me. + + # Backup the first MiB of /dev/sda to capture MBR and any bootloader stuff + dd if=/dev/sda of=mbr.save bs=1M count=1 + # Use ntfsclone to make a space-efficient copy of the windows partition + ntfsclone --save-image -o - /dev/sda2 | gzip -c > sda2.img.gz + +## Prepare /dev/sda2 for virtualization + +First, /dev/sda2 must look like a DOS style disk, complete with disk level +partition information. This can be accomplished using this fdisk command: + + fdisk -c -u /dev/sda2 + +Drive fdisk to create a single windows partition spanning the entirety of the +'disk' (actually the physical partition /dev/sda2). Now /dev/sda2 will look +like a valid disk image usable by a VM to re-install Windows 7. + +## Install the virtualization tools in Linux + + sudo apt-get install virt-manager virt-viewer python-vm-builder \ + kvm-pxe ubuntu-vm-builder + +I tested the VM tools by creating an Ubuntu 11.04 install. I ran the Virtual +Machine Manager using an Ubuntu 11.04 install .iso image as its CD-ROM. The +installation was successful and the resulting virtual machine worked without +fail. + +## Re-install Windows 7 + +Next windows was re-installed. A Windows 7 Home Premium 32-bit OEM .iso was +used to do a clean install of Win7. See the virtioinstall.sh script for more +information. I used the Win7 iso, and virtual floppy and CD-ROM images from +RedHat containing signed virtio drivers for disk and network devices. The VM was +started using the virtio disk driver, booting into the Win7 iso. Then the +virtual floppy was accessed during the Win7 install process to load in the +virtio drivers so the Win7 install program could see the disc, which was of +course the disk image on the host /dev/sda partition. I formatted the 'drive' +(which is really the /dev/sda2 partition on the physical drive), then proceeded +to install Win7 onto it. The installation process, from first boot of the Win7 +iso, to first user login to Win7, took just under 45 minutes. + +At this point, the VM was stopped so its configuration could be altered it use +the virtio network driver. The VM was then restarted with the virtio iso from +RedHat connected as the virtual CD-ROM disc. Once Win7 was running, in device +manager the drivers for the broken network device were updated from the .iso to +get the network running. The virtio network interface seems very efficient. The +VM configuration was finally modified to provide for 2 CPU cores and 2 GB of +RAM. + +## Re-activate Windows 7 + +At this time, Win7 had to be re-activated. The online technique failed, so the +phone call technique was required. It was a bit painful, but the end result was +a properly activated installation. + +## Install other Windows 7 tools + +Since I installed from scratch, I had to reinstall the few tools I use under +Windows. Since these tools were few in number, this process was pretty +painless. This strategy would be much more painful if there were lots of tools +and/or custom configuration or data required to be recovered. + +## Improving diplay performance + +The default display mechanism when interacting with the Windows VM display is +VNC. This is not very performant. Since the Windows VM is only to be accessed +from the local hardware, I instead configured the VM to use SDL for rendering +the VM display in a window. Interestingly, this change also allowed sound from +the Win7 VM to propagate to the sound hardware. The SDL configuration is fast +enough to watch Netflix from the VM. + + Stop the win7 VM + Reconfigure the VM: + Remove VNC graphics entry for the VM and add the local SDL one. + Change the sound driver to ac97 + Edit /etc/libvirt/qemu.conf. Add: + user = "smckown" + group = "smckown" + sudo service libvirtd-bin restart + Restart the virtual machine + +### Why not SPICE? + +The SDL method creates a new local window that hosts the VM display. It cannot +be embedded into the virtual manager VM window. It looks like the better +solution is going to be to use the SPICE facility. Special drivers in the VM +work with special client features to implement a much improved connection. SPICE +provides better display performance than VNC, can do stereo sound, and also +provides for USB redirection. As of 7/13/12, Ubuntu 12.04 does not have the +right stuff to do spice through virt-manager. There is a PPA that will allow it. +The nice thing about SPICE is it is network-able and can be embedded. Since +network access to the VM is not necessary, the SDL window method seems optimal. + +## Anti Virus considerations + +It should be noted that the VM, as the native install before it, is running +Microsoft Security Essentials for Anti-Virus. There appears a noticeable +performance hit for using AV within the VM, in comparison to running it +natively. Unfortunately, the protection offered is probably worth the +performance penalty. + +# Conclusion + +I am quite happy with the results of this process. Win7 boots noticeably faster +from the VM than it did on native hardware. Disk CPU are perceptibly sluggish +within the VM with respect to native performance, but it is tolerable. Network +performance seems on par with native. For the tasks in which I will use +Windows, the virtual machine performance is more than adequate. + +Of course the big win is that Win7 can be running simultaneously with Ubuntu. +This solves a host of workflow problems and removes the terrible inefficiencies +caused by having to boot between the two OSes natively. For one, I was able to +continue working with apps in the host Ubuntu OS while the Win7 VM chugged away +literally for hours downloading and rebooting ad nauseum as it updated itself +with the latest Win7 SP1 and subsequent patches. + +My overall concern with this strategy is that a change in Microsoft policy could +complicate my life. Although this use of my windows license is perfectly +legitimate according to my reading of the EULA, I depend upon Windows Product +Activation to honor this legitimacy. Here is to hoping that Microsoft will take +care to ensure that their WPA policies retain convenient use of Windows for all +legitimate uses. + +--- + +# Updates + +### 2012-08-13 +After using this configuration for over a year, I have found it to be quite +reliable. The upgrade to 12.04 triggered Windows Product Activation, and +another phone call to the automated WPA phone number was required. The +activation was successful. + +--- + +# Links + +The following links, in no particular order, were invaluable in completing this project. Thanks to all those who published their prior experience for others to use! + +* +* +* +* +* +* +* +* +* +* +* +* +* +* +* diff --git a/in/blog/wwvb.md b/in/blog/wwvb.md new file mode 100644 index 0000000..c03be9f --- /dev/null +++ b/in/blog/wwvb.md @@ -0,0 +1,88 @@ +title: WWVB +linktitle: wwvb +parent: 2011-10 +ctime: 2011-10-28 +mtime: 2011-10-28 + +Repositories: SOON + +TMI uses a WWVB receiver in its RWS product. +[WWVB](http://www.nist.gov/pml/div688/grp40/wwvb.cfm) is a radio station +operated out of Ft. Collins, CO by NIST, which provides a 60Hz carrier wave on +which is encoded the current time as synchronized with a pair of on-site atomic +oscillators. The low frequency of the WWVB broadcast means it is available +through most of North America. Perhaps you have heard of *Atomic Clock* radios. +These simply incorporate a WWVB receiver which is then used to automatically +set, and periodically compensate, the radio's internal real time clock +circuitry. + +TMI's RWS (Remote Weather Station) project collects weather data completely +autonomously, time-stamping recorded data using its onboard RTC. The WWVB +broadcast is used to both initially set the RTC, and to periodically compensate +for its drift over time. + +TMI chose to incorporate the C-MAX +[CMMR-6](http://www.c-max-time.com/products/showProduct.php?id=31) WWVB receiver +into its RWS design. This simple board requires very little power, and the fact +that the WWVB receiver need only be consulted occasionally to compensate for RTC +drift means its time averaged power consumption is very low. The CMMR-6 offers +a simple output, TCO, treated as a digital signal. TCO is logic high when the +WWVB carrier is transmitting at full power, and is logic low when the WWVB +carrier is transmitting at reduced power. Each second uses a variable period in +which the carrier is at reduced power to encode one of three values: a 0 bit, a +1 bit, and a frame marker. 60 of these tri-state bits form a time frame +containing the time, to the minute, during the current frame transmission. More +about the WWVB signal format is available +[here](http://tf.nist.gov/stations/wwvbtimecode.htm). + +While the [WWVB time code format](http://tf.nist.gov/stations/wwvbtimecode.htm) +is easy to parse, this is not so true in the presense of noise. TMI has chosen +to address noise by implementing a digital 4th order Butterworth filter, using a +32Hz sample rate and a 3 Hz cutoff frequency. The filter inputs are either 0.0 +and 1.0, sampled from the CMMR-6 TCO pin, and the filter output is some fraction +inclusive of the range 0.0 through 1.0. The microprocessor code implements +hysteresis to generate a digital output, where outputs >= 0.7 are treated as +logic 1, outputs <= 0.3 are logic zero, and any value in between these +thresholds leave the logic output unchanged. This filter, implemented within +the uC, requires up to 5% of the CPU while WWVB is in operation, but does a +stellar job at cleaning up the WWVB signal. To evaluate filters and generate +their implementation logic, we used the simple and easy to use +[Fiview](http://www.uazu.net/fiview) design tool. + +Consider the following oscilliscope capture of live WWVB reception. TCO is the +output from the CMMR, and FOUT is the output from the digital filter. Note that +the filter delays the signal by approximately 200 ms. + +![Oscilloscope capture image](images/wwvb-capture.png) + +As mentioned earlier, the duration of the low period indicates the bit type. +200 ms for bit 0, 500 ms for bit 1, and 800 ms for a frame mark. As can be seen +in the TCO trace, there is a significant amount of relatively high frequency +noise interfering with the TCO signal. A discrete algorithm would likely be +unreliable in decoding TCO. However, the filtered output, FOUT, successfully +removed all the noise with minimal signal distortion. A discrete algorithm can +parse FOUT with a high degree of reliability. In this case, the trace as +decoded -- 0 0 1 0 M 0 0 1 1 -- was the correct sequence for the captured frame. + +The decode algorithm determines a bit value for the current low period duration +that is best matched by the expected durations. But the low pass filter cannot +remove all sources of error, so a frame may be received with bits in error. +Frames are validated according to the [WWVB time code +format](http://tf.nist.gov/stations/wwvbtimecode.htm), and two frames must have +matching data to consider a valid time acquisition. Of course in this sense, +matching frames do not have the exact same values, but the second frame's +contents differ from the first frame's only by the number of minutes separating +their acquisition. + +There are still a few enhancements possible in this design. First, the TCO +signal could be captured via an ADC, to bring additional information on each +bit into the filter. This, however, might require some software gain control +depending upon how good the CMMR-6 AGC circuitry is, and may not be worth the +effort. + +The second enhancement is one that will be implemented. Instead of matching two +complete frames to indicate valid aquisition, instead match complete frame +sections. Three incoming frames all with errors in different sections would +allow this latter approach to construct a known good frame, where the current +algorithm could not. In very noisy cases, this enhancement should perform +better. diff --git a/in/cp210x.md b/in/cp210x.md deleted file mode 100644 index 78034c6..0000000 --- a/in/cp210x.md +++ /dev/null @@ -1,48 +0,0 @@ -title: CP210X -linktitle: cp210x -parent: Home -ctime: 2009-12-10 - -Repositories: [cp210x](/gitweb/?p=cp210x.git;a=summary), [[aptrepo]]. - -# A USB to UART chip - -[Silicon Labs](http://www.silabs.com) sells a single-chip USB to UART bridge, -the -[cp210x](http://www.silabs.com/products/interface/usbtouart/Pages/default.aspx). -For windows platforms, Silicon Labs offers manufacturing support for setting the -various USB descriptor fields, port configurations, etc. They also offer a DLL -and example programs showing how to manipulate the GPIO pins available on the -cp2103 part. - -With support from Silicon Labs, TMI has modified their GPLv2 licensed reference -Linux driver to support all of the features their Windows DLLs and utilities -provide. This is accomplished via extended `ioctl()` calls from the kernel -cp210x driver, and various utilities and sample code. This code is invaluable -for those working on hardware designs using the cp2103. For example, TMI -enhancements to tos-bsl in [[tinyos]] allow programming of an MSP430 based -target using a USB/serial connection, by leveraging two of the four additional -GPIO pins present on the cp2103. - -TMI completed these driver changes were originally completed in late 2007, but -have been periodically updated since then to track changes to the linux kernel -source. Silicon Labs was to push these changes through to the mainline kernel, -did not do so. In mid 2010, TMI had discussions with the -linux-usb developers, and a decent number of changes need to be made before they -will include our modifications upstream. Specifically, they want to see all -ioctl calls replaced with another mechanism. Perhaps we can allocate some time to -work on these issues in the future. Meanwhile, TMI will continue to maintain -its branch of the cp210x driver. - -The `cp210x-module-dkms` package in the TMI APT -repository has been tested on (X)Ubuntu 8.04 LTS (Hardy Heron), 9.10 (Karmic -Koala), 10.04 LTS (Lucid Lynx), 10.10 (Maverick Meerkat), 11.04 (Natty Narwhal), -and 12.04 (Precise Pangolin). Because the driver uses the dkms facility, the -driver should build for both 32 and 64 bit systems. Some testing has happened -using older versions of 64-bit (X)Ubuntu, but TMI developers predominantly use -32-bit Xubuntu 12.04 at the moment (2012-07-09). - -Note: Silicon Labs has introduced new USB/Serial chips, like the cp2104. The -latest merge of the mainline cp210x driver, as present when used on 12.04 -systems, may be compatible with these newer parts. TMI has not tested for this -compatibility. diff --git a/in/firmware.md b/in/firmware.md deleted file mode 100644 index a4b9d32..0000000 --- a/in/firmware.md +++ /dev/null @@ -1,15 +0,0 @@ -title: Router Firmware -linktitle: firmware -parent: Home -ctime: 2006-02-13 - -Tarball: [gpl](http://www.titaniummirror.com/gpl). - -TMI has developed a fault tolerant internetworking platform composed of a set -of proprietary cluster, event and web management applications running atop a -GNU/Linux open source platform core. Essentially, the core represents a -customized Linux distribution geared specifically for network appliances. The -proprietary code developed by TMI does not link with any GPL components of the -core and honors the terms of the license. Some minor changes have been made -to the core components. Those changes are available -[here](http://www.titaniummirror.com/gpl). diff --git a/in/git-utils.md b/in/git-utils.md deleted file mode 100644 index a60f2cf..0000000 --- a/in/git-utils.md +++ /dev/null @@ -1,49 +0,0 @@ -title: GIT Utilities -linktitle: git-utils -parent: Home -ctime: 2009-12-10 - -Repositories: [git-utils](/gitweb/?p=git-utils.git;a=summary). - -# GIT - -Read about [GIT](http://git-scm.com) here. - -# Utilities - -TMI is starting to collect a number of small utilities for git. Each utility -has a man page describing its operation. A few notables: - -* `git-diffall`. Provides a facility for file-aware visual diff using an - external diff tool such as kdiff3, meld, or a similar tool. - -* `git-empty-branch`. Create an empty branch in a local git repository. - -* `git-local`. Store local branches in a shared git repository under a private - namespace. Upload, download, remove and list operations are provided. We - use this tool to backup up local commits not yet suitable for pushing into a - local shared branch. - -* `git-overview`. A simple script that scans a directory tree for git repos, - showing the overall state of each. - -* `git-publish-branch`. A shell version of the ruby script created by William - Morgan. See his [git utilities page](http://git-wt-commit.rubyforge.org). - We did not want to have to install ruby just for this one little utility. - -* `git-push-public`. Used by TMI to replicate changes made to open source - projects hosted on TMI private servers to the TMI public server. - -* `server-gc`. A tool to run git-gc on each bare git repository found within a - given filesystem directory tree. Newest versions of git generally make this - utility redundant. - -* `update-mirror`. Used by TMI to update a local git mirror of an upstream git - or svn repository. Derived from the clone.sh script found at - [girocco](http://repo.or.cz/w/girocco.git). - -# Installation - -These scripts are not packaged in the [[aptrepo]]. To install the utilities, -copy the scripts to `/usr/local/bin` and ensure they have execute permission. -Then copy the `*.1` files, which are the man pages, to `/usr/local/man/man1`. diff --git a/in/gitweb/githeader.md b/in/gitweb/githeader.md index 83833ae..390b92d 100644 --- a/in/gitweb/githeader.md +++ b/in/gitweb/githeader.md @@ -1,3 +1,4 @@ title: OSS Repository template: bodyheader ctime: 2009-12-17 +mtime: 2000-01-01 diff --git a/in/images/wwvb-capture.png b/in/images/wwvb-capture.png deleted file mode 100644 index eb42bf6..0000000 Binary files a/in/images/wwvb-capture.png and /dev/null differ diff --git a/in/index.md b/in/index.md index 4327f7c..79db1dd 100644 --- a/in/index.md +++ b/in/index.md @@ -1,6 +1,7 @@ title: OSS Projects linktitle: Home ctime: 2009-12-15 +mtime: 2000-01-01 # Introduction diff --git a/in/misc.md b/in/misc.md new file mode 100644 index 0000000..085c8a8 --- /dev/null +++ b/in/misc.md @@ -0,0 +1,8 @@ +title: Misc +linktitle: misc +parent: Home +ctime: 2012-08-15 +mtime: 2000-01-01 + +This category contains miscellaneous items of possible interest. Please select +from the side menu on the left. diff --git a/in/misc/firmware.md b/in/misc/firmware.md new file mode 100644 index 0000000..011fe5a --- /dev/null +++ b/in/misc/firmware.md @@ -0,0 +1,16 @@ +title: Router Firmware +linktitle: firmware +parent: misc +ctime: 2006-02-13 +mtime: 2006-02-13 + +Tarball: [gpl](http://www.titaniummirror.com/gpl). + +TMI has developed a fault tolerant internetworking platform composed of a set +of proprietary cluster, event and web management applications running atop a +GNU/Linux open source platform core. Essentially, the core represents a +customized Linux distribution geared specifically for network appliances. The +proprietary code developed by TMI does not link with any GPL components of the +core and honors the terms of the license. Some minor changes have been made +to the core components. Those changes are available +[here](http://www.titaniummirror.com/gpl). diff --git a/in/misc/msp430.md b/in/misc/msp430.md new file mode 100644 index 0000000..5340968 --- /dev/null +++ b/in/misc/msp430.md @@ -0,0 +1,26 @@ +title: MSP430 +linktitle: msp430 +parent: misc +ctime: 2008-01-03 +mtime: 2012-07-01 + +*This project is obsolete*. As of the release of Ubuntu 12.04 Precise Pangolin, +an up-to-date version of the MSP430 cross toolchain is available in the standard +repositories. For this reason, TMI is no longer maintaining its own MSP430 +toolchain, which ultimately use the same upstream source as the new standard +packages do. See the [[TMI Repository|aptrepo]] page for more information. + +As of 2012-08-15, the msp430-gdb package does not install due to a file +conflict as shown below. + + dpkg: error processing + /var/cache/apt/archives/gdb-msp430_7.2~mspgcc-7.2-20110612-1ubuntu1_i386.deb + (--unpack): + trying to overwrite '/usr/share/gdb/python/gdb/__init__.py', which is also + in package gdb 7.4-2012.04-0ubuntu2 + +Repositories: +[msp430-binutils](/gitweb/?p=msp430-binutils.git;a=summary), +[msp430-gcc](/gitweb/?p=msp430-gcc.git;a=summary), +[msp430-libc](/gitweb/?p=msp430-libc.git;a=summary), +[[aptrepo]]. diff --git a/in/misc/oss-web.md b/in/misc/oss-web.md new file mode 100644 index 0000000..6cf3a63 --- /dev/null +++ b/in/misc/oss-web.md @@ -0,0 +1,10 @@ +title: OSS Website Code +linktitle: oss-web +parent: misc +ctime: 2009-12-15 +mtime: 2009-12-15 + +Repositories: [oss-web](/gitweb/?p=oss-web.git;a=summary). + +The website you are viewing now is statically generated from the +[oss-web](/gitweb/?p=oss-web.git;a=summary). repository using [[Webber]]. diff --git a/in/misc/webber.md b/in/misc/webber.md new file mode 100644 index 0000000..d71998c --- /dev/null +++ b/in/misc/webber.md @@ -0,0 +1,13 @@ +title: Webber +linktitle: webber +parent: misc +ctime: 2009-12-15 +mtime: 2009-12-15 + +Repositories: [webber](/gitweb/?p=webber.git;a=summary). + +[Webber](http://gitorious.org/webber) is a great static website generator +written in Python by +[Holger Schurig](http://www.holgerschurig.de/projects/webber/). We maintain +a [local copy](/gitweb/?p=webber.git;a=summary) of his repository +with a few changes. This website is built using webber; see [[oss-web]]. diff --git a/in/msp430.md b/in/msp430.md deleted file mode 100644 index 451407d..0000000 --- a/in/msp430.md +++ /dev/null @@ -1,24 +0,0 @@ -title: MSP430 -linktitle: msp430 -parent: Home -ctime: 2008-01-03 - -Repositories: -[msp430-binutils](/gitweb/?p=msp430-binutils.git;a=summary), -[msp430-gcc](/gitweb/?p=msp430-gcc.git;a=summary), -[msp430-libc](/gitweb/?p=msp430-libc.git;a=summary), -[[aptrepo]]. - -TMI maintains an msp430 toolchain, including [[Ubuntu packages|aptrepo]], which -works with newer members of the msp430 family including the popular MSP430F2x1x -parts such as the MSP430F2618. This toolchain is properly patched for use in -[[TinyOS]] development. - -As of the release of Ubuntu 12.04 Precise Pangolin, an up-to-date version of the -MSP430 cross toolchain is available in the standard repositories. For this -reason, TMI is no longer maintaining its own packages, which ultimately use the -same upstream source as the new standard packages do. See the [[TMI -Repository|aptrepo]] page for more information. - -As of 2012-06-15, the msp430-gdb package does not install due to a file -conflict. This will likely be fixed soon. diff --git a/in/news.md b/in/news.md index 51b8345..93249f8 100644 --- a/in/news.md +++ b/in/news.md @@ -1,9 +1,10 @@ title: News ctime: 2009-12-16 +mtime: 2012-08-15 -### 2012-08-13 -Post [[Virtual Windows 7|virtual-win7]] article, and perform some -cleanups. +### 2012-08-15 +Reorganize the website into three categories: [[blog]], [[misc]], and +[[projects]]. --- diff --git a/in/oss-web.md b/in/oss-web.md deleted file mode 100644 index 2a4748e..0000000 --- a/in/oss-web.md +++ /dev/null @@ -1,8 +0,0 @@ -title: OSS Website Code -linktitle: oss-web -parent: Home -ctime: 2009-12-15 - -Repositories: [oss-web](/gitweb/?p=oss-web.git;a=summary). - -This website is statically generated from the repository using [[Webber]]. diff --git a/in/ovzbpc.md b/in/ovzbpc.md deleted file mode 100644 index 2519c38..0000000 --- a/in/ovzbpc.md +++ /dev/null @@ -1,32 +0,0 @@ -title: OpenVZ + BackupPC -linktitle: ovzbpc -parent: Home -ctime: 2008-06-09 - -Repositories: [ovzbpc](/gitweb/?p=ovzbpc.git;a=summary). - -# TMI backup strategy - -TMI hosts its compute resources in [OpenVZ](http://www.openvz.org) Virtual -Environments (VE) running on a cluster of Dell PE1800 servers. The contents -of each VE, as well as the servers hosting them, are backed up using -[BackupPC](http://backuppc.sourceforge.net). Periodically, a clone of the -BackupPC disk archive is made on one of a pool of external eSATA drives, which -are rotated off-site for disaster recovery. TMI has authored a few program -scripts which integrate these backup components. - -* `BackupPC_ovz` allows an OpenVZ VE to be backed up and restored via BackupPC - without special configuration of the VE, nor with BackupPC being told on - which hardware node the VE is running. See the - [README](/gitweb/?p=ovzbpc.git;a=blob;f=README;hb=HEAD) for more - information. - -* `bpcdump` and friends support cloning the BackupPC VE to a removeable eSATA - drive for disaster recovery. See [README.bpcdump](/gitweb/?p=ovzbpc.git;a=blob;f=README.bpcdump;hb=HEAD) - for more information. - -* `esata` wraps the `scsiadd` utility for properly handling eSATA drives on - Dell PE1800 and PE1900 platforms. Newer hardware and better Linux kernel - support will someday make scripts like this unnecessary. See - [README.esata](/gitweb/?p=ovzbpc.git;a=blob;f=README.esata;hb=HEAD) - for more information. diff --git a/in/projects.md b/in/projects.md new file mode 100644 index 0000000..2d5f8e1 --- /dev/null +++ b/in/projects.md @@ -0,0 +1,8 @@ +title: Projects +linktitle: projects +parent: Home +ctime: 2012-08-15 +mtime: 2000-01-01 + +TMI has posted code and info for various projects on this website. Navigate the +projects from the left pane. diff --git a/in/projects/cp210x.md b/in/projects/cp210x.md new file mode 100644 index 0000000..0f49413 --- /dev/null +++ b/in/projects/cp210x.md @@ -0,0 +1,49 @@ +title: CP210X +linktitle: cp210x +parent: projects +ctime: 2009-12-10 +mtime: 2012-07-03 + +Repositories: [cp210x](/gitweb/?p=cp210x.git;a=summary), [[aptrepo]]. + +# A USB to UART chip + +[Silicon Labs](http://www.silabs.com) sells a single-chip USB to UART bridge, +the +[cp210x](http://www.silabs.com/products/interface/usbtouart/Pages/default.aspx). +For windows platforms, Silicon Labs offers manufacturing support for setting the +various USB descriptor fields, port configurations, etc. They also offer a DLL +and example programs showing how to manipulate the GPIO pins available on the +cp2103 part. + +With support from Silicon Labs, TMI has modified their GPLv2 licensed reference +Linux driver to support all of the features their Windows DLLs and utilities +provide. This is accomplished via extended `ioctl()` calls from the kernel +cp210x driver, and various utilities and sample code. This code is invaluable +for those working on hardware designs using the cp2103. For example, TMI +enhancements to tos-bsl in [[tinyos]] allow programming of an MSP430 based +target using a USB/serial connection, by leveraging two of the four additional +GPIO pins present on the cp2103. + +TMI completed these driver changes were originally completed in late 2007, but +have been periodically updated since then to track changes to the linux kernel +source. Silicon Labs was to push these changes through to the mainline kernel, +did not do so. In mid 2010, TMI had discussions with the +linux-usb developers, and a decent number of changes need to be made before they +will include our modifications upstream. Specifically, they want to see all +ioctl calls replaced with another mechanism. Perhaps we can allocate some time to +work on these issues in the future. Meanwhile, TMI will continue to maintain +its branch of the cp210x driver. + +The `cp210x-module-dkms` package in the TMI APT +repository has been tested on (X)Ubuntu 8.04 LTS (Hardy Heron), 9.10 (Karmic +Koala), 10.04 LTS (Lucid Lynx), 10.10 (Maverick Meerkat), 11.04 (Natty Narwhal), +and 12.04 (Precise Pangolin). Because the driver uses the dkms facility, the +driver should build for both 32 and 64 bit systems. Some testing has happened +using older versions of 64-bit (X)Ubuntu, but TMI developers predominantly use +32-bit Xubuntu 12.04 at the moment (2012-07-09). + +Note: Silicon Labs has introduced new USB/Serial chips, like the cp2104. The +latest merge of the mainline cp210x driver, as present when used on 12.04 +systems, may be compatible with these newer parts. TMI has not tested for this +compatibility. diff --git a/in/projects/git-utils.md b/in/projects/git-utils.md new file mode 100644 index 0000000..3aa0a43 --- /dev/null +++ b/in/projects/git-utils.md @@ -0,0 +1,50 @@ +title: GIT Utilities +linktitle: git-utils +parent: projects +ctime: 2009-12-10 +mtime: 2012-05-16 + +Repositories: [git-utils](/gitweb/?p=git-utils.git;a=summary). + +# GIT + +Read about [GIT](http://git-scm.com) here. + +# Utilities + +TMI is starting to collect a number of small utilities for git. Each utility +has a man page describing its operation. A few notables: + +* `git-diffall`. Provides a facility for file-aware visual diff using an + external diff tool such as kdiff3, meld, or a similar tool. + +* `git-empty-branch`. Create an empty branch in a local git repository. + +* `git-local`. Store local branches in a shared git repository under a private + namespace. Upload, download, remove and list operations are provided. We + use this tool to backup up local commits not yet suitable for pushing into a + local shared branch. + +* `git-overview`. A simple script that scans a directory tree for git repos, + showing the overall state of each. + +* `git-publish-branch`. A shell version of the ruby script created by William + Morgan. See his [git utilities page](http://git-wt-commit.rubyforge.org). + We did not want to have to install ruby just for this one little utility. + +* `git-push-public`. Used by TMI to replicate changes made to open source + projects hosted on TMI private servers to the TMI public server. + +* `server-gc`. A tool to run git-gc on each bare git repository found within a + given filesystem directory tree. Newest versions of git generally make this + utility redundant. + +* `update-mirror`. Used by TMI to update a local git mirror of an upstream git + or svn repository. Derived from the clone.sh script found at + [girocco](http://repo.or.cz/w/girocco.git). + +# Installation + +These scripts are not packaged in the [[aptrepo]]. To install the utilities, +copy the scripts to `/usr/local/bin` and ensure they have execute permission. +Then copy the `*.1` files, which are the man pages, to `/usr/local/man/man1`. diff --git a/in/projects/ovzbpc.md b/in/projects/ovzbpc.md new file mode 100644 index 0000000..b6020ba --- /dev/null +++ b/in/projects/ovzbpc.md @@ -0,0 +1,33 @@ +title: OpenVZ + BackupPC +linktitle: ovzbpc +parent: projects +ctime: 2008-06-09 +mtime: 2009-12-16 + +Repositories: [ovzbpc](/gitweb/?p=ovzbpc.git;a=summary). + +# TMI backup strategy + +TMI hosts its compute resources in [OpenVZ](http://www.openvz.org) Virtual +Environments (VE) running on a cluster of Dell PE1800 servers. The contents +of each VE, as well as the servers hosting them, are backed up using +[BackupPC](http://backuppc.sourceforge.net). Periodically, a clone of the +BackupPC disk archive is made on one of a pool of external eSATA drives, which +are rotated off-site for disaster recovery. TMI has authored a few program +scripts which integrate these backup components. + +* `BackupPC_ovz` allows an OpenVZ VE to be backed up and restored via BackupPC + without special configuration of the VE, nor with BackupPC being told on + which hardware node the VE is running. See the + [README](/gitweb/?p=ovzbpc.git;a=blob;f=README;hb=HEAD) for more + information. + +* `bpcdump` and friends support cloning the BackupPC VE to a removeable eSATA + drive for disaster recovery. See [README.bpcdump](/gitweb/?p=ovzbpc.git;a=blob;f=README.bpcdump;hb=HEAD) + for more information. + +* `esata` wraps the `scsiadd` utility for properly handling eSATA drives on + Dell PE1800 and PE1900 platforms. Newer hardware and better Linux kernel + support will someday make scripts like this unnecessary. See + [README.esata](/gitweb/?p=ovzbpc.git;a=blob;f=README.esata;hb=HEAD) + for more information. diff --git a/in/projects/rgblamp.md b/in/projects/rgblamp.md new file mode 100644 index 0000000..822331d --- /dev/null +++ b/in/projects/rgblamp.md @@ -0,0 +1,21 @@ +title: RGB Lamp +linktitle: rgblamp +parent: projects +ctime: 2012-03-10 +mtime: 2012-03-10 + +The RGB Lamp was a little filler project. A 4.2W CREE RGBW LED module is driven +by a PIC16LF1933. Learn more: + +* [[Code Notes|rgb-code]] +* [[Features|rgb-features]] +* [[Mechanical|rgb-mechanical]] +* [Source Code](/gitweb/?p=rgblamp.git;a=summary) + +A future implementation might accept audio input from a stereo jack or onboard +microphone, use a DFT to examine the frequency components present in the audio +stream, represent each of several bands of frequencies with a color whose +brightness is proportional to the signal strength, then 'mix' the per-frequency +color results into an RGBW output that can drive the LED module. Because of the +higher performance needed, we will probably use a STMicro STM32 or EnergyMicro +EFM32 low power ARM Cortex-M3 processor. diff --git a/in/projects/rgblamp/code.md b/in/projects/rgblamp/code.md new file mode 100644 index 0000000..33f06f8 --- /dev/null +++ b/in/projects/rgblamp/code.md @@ -0,0 +1,30 @@ +title: RGB Lamp Code +linktitle: rgb-code +parent: rgblamp +ctime: 2012-03-10 +mtime: 2012-03-10 + +PIC code for the [[rgblamp]] is written in C and compiled using the MPLAB X +cross-platform IDE and the HI-TECH C compiler. + +The lamp code uses a simple event driven strategy. Events are generally +initiated through hardware events. Application logic is structured as a set of +tasks, each of which is executed in response to a given event. Because much of +the behavior of the lamp application is dependent upon timing, a timer +abstraction is also useful. + +So, this code uses both of these useful abstractions: tasks and timers. This +project hacks together some basic support for tasks and timers for the PIC16. +Thankfully the atypical architecture of the PIC16 is mostly abstracted by the C +compiler. And because this is such a simple project, the simplistic interrupt +handling of the PIC16 is not an issue either. And although not very flexible in +its use, driving Timer 1 via a 32 kHz crystal offers reasonable support for +auto-on from soft off. + +* [[rgb-task]] +* [[rgb-timer]] + +The project yielded some other other novel tidbits. + +* [[rgb-leds]] +* [[rgb-random]] diff --git a/in/projects/rgblamp/features.md b/in/projects/rgblamp/features.md new file mode 100644 index 0000000..76e56b7 --- /dev/null +++ b/in/projects/rgblamp/features.md @@ -0,0 +1,37 @@ +title: RGB Lamp Features +linktitle: rgb-features +parent: rgblamp +ctime: 2012-03-10 +mtime: 2012-03-10 + +# [[rgblamp]] features + +* Auto power cycling, 5 hours on, 19 hours off. +* Brightness level adjustment +* Twelve colors, which include white and a simulated candle color +* Several modes: random color change, slow color change, and fixed color +* Simulated candle flicker for all colors except for white +* Persistent state configuration + +# The power switch + +The power switch has three positions: off, on, and auto. When the switch +position changes to auto, a timer is started that turns off the lamp in five +hours, then back on again nineteen hours later. + +# The push button + +When the pushbutton is depressed briefly, then released, the lamp color mode is +changed. Modes cycle through all twelve color modes, the first of which is the +candle simulation and the last of which is white. The mode immediately +following white is the slow color change mode, which itself cycles through the +colors every sixteen minutes. The next and final mode is a rapid and random +color change mode (party mode). A mode change when in party mode returns to the +first mode. + +When the pushbutton is depressed and held, brightness varies until the +pushbutton is released. Brightness is dimmed until a minimum brightness is +reached. After a short delay at the minimum brightness, brightness is +then increased over time until a maximum brightness is reached. After a short +delay at the maximum brightness, the process repeats. Once the pushbutton is +released, the brightness setting at that point is retained persistently. diff --git a/in/projects/rgblamp/leds.md b/in/projects/rgblamp/leds.md new file mode 100644 index 0000000..4eb8535 --- /dev/null +++ b/in/projects/rgblamp/leds.md @@ -0,0 +1,59 @@ +title: RGB Lamp Led Driver +linktitle: rgb-leds +parent: rgb-code +ctime: 2012-03-10 +mtime: 2012-03-10 + +# PWM drive + +The LEDs in the module receive varying current to adjust their brightness via +the hardware PWM features of the PIC16LF1933 in conjunction with Timer 2. The +module has 4 capture/compare peripherals, which is perfect for the 4 LEDs in the +module. + +Each PWM output controls a simple current limited 2-transister drive circuit. +This circuit is superior to a simple single transistor switch, as the CE +junction of one transistor is used as a fixed voltage drop controlling current +through a resistor of known size. This is particularly nice given that +different LED modules have differnt voltage drops, and voltage drop is also a +function of current and temperature. A fixed current driver removes these +variables. + +# Mixing color and brightness + +An interesting challenge is to manipulate the output of the discrete color LEDs +both for the purpose of emitting a specific color and for controlling the +brightness. The solution is to treat the pre-computed PWM output value as a +fraction of the maximum value (255). In the same fashion, the color range and +the brightness are also treated as a fraction of their respective maximums. +Therefore, the rgb drive output is essentially the product of the color and +brightness values. Simple, and it seems to work out pretty well. + + rgb = 255 * (color/color_max * bright/bright_max) + +Of course, for this processor the preference is to do this computation in +integer math. The actual implementation looks more like this: + + color: 0..63 + bright: 0..BRIGHT_MAX + rgb = (color << 4) * bright / 4 / BRIGHT_MAX + +# LEDs + +An interesting effect was uncovered during testing. A certain delta change in +drive string of a LED at a relatively low average power level is readily +perceptible vsually, while the same delta is hard to detect at higher power +levels. Some research shows this to be a nature of the human eye -- it +perceives changes at lower intensities more readily than at higher percentages +[(1)](http://neuroelec.com/2011/04/led-brightness-to-your-eye-gamma-correction-no/). +To get a perceived linear output, the PWM value must be adjusted according to +CIE Lightness. + + L* = 116(Y/Yn)^1/3 - 16 , Y/Yn > 0.008856 + L* = 903.3(Y/Yn), Y/Yn <= 0.008856 + +Using these formulas, a look-up table can be created to provide the +compensation. It works pretty well. The rgb.c and rgb.h files in the +[repository](http://oss/gitweb?p=rgblamp.git;a=summary) implement this feature. +Note that there are two different look-up tables available, depending upon the +resolution desired. diff --git a/in/projects/rgblamp/mechanical.md b/in/projects/rgblamp/mechanical.md new file mode 100644 index 0000000..24023dd --- /dev/null +++ b/in/projects/rgblamp/mechanical.md @@ -0,0 +1,54 @@ +title: RGB Lamp Features +linktitle: rgb-mechanical +parent: rgblamp +ctime: 2012-03-10 +mtime: 2012-03-10 + +The [[rgblamp]] mechanicals are based on a little rectangular lamp purchased at +IKEA. The CREE LED module is placed on a 1/2 inch think heat sink designed for +the module, and that module is mounted inside the lamp in place of the standard +screw bulb mount. + +There are several challenges with this design. First, the LED module must not +exceed its thermal specs during operation. Second, the lamp must not expose +human eyes to the direct output of the LED module. Finally, we need to find a +way to mount both the module and the electronics. + +# Thermal issues + +The +[datasheet](http://media.digikey.com/PDF/Data%20Sheets/Wakefield%20Thermal%20PDFs/882_Series.pdf) +for the 0.5 inch thick [heat +sink](http://search.digikey.com/us/en/products/882-50AB/345-1104-ND/2640527) +specifies a 60 degree C rise in temperature when dissipating 9W with natural +convection. That is 60/9 or 6.67 C/W. Since the [CREE LED +module](http://search.digikey.com/us/en/products/MCE4CT-A2-RGBCW-STAR-IND/955-1043-ND/2357817) +will be limited to 350 mA at about 3.2 V by the control circuitry, maximum power +dissipation is 1.12 W per LED, or 4.48 W for the entire module. In ambient air, +the 0.5 inch heatsink will see a rise over ambient of about 30 degrees Celcius. +So if room temperature is 30 C (86 F), the temperature and the juntion beween +the module and the heatsink should be about 60 C. I failed to locate a maximum +junction temperature for this module, but 60 C is not too high for most other +LEDs out there. To ensure good thermal contact, the module was secured to the +heat sink with machine screws and a bit of thermal paste. + +In operation, the lamp when tested in operation suggests the heat sink is +actually performing a bit better than the data sheet numbers suggest. + +# Eye protection + +The problem with the IKEA lamp used is that it is open through the top. This is +an advantage thermally because the lamp acts like a chimney, allowing cool air +to enter through the opening in the bottom -- which was left open for +ventilation purposes -- and warmer air to rise out of the top. The downside is that a +person could easily look into the lamp from above. These high power modules can +cause retinal damage, so this is a problem. The solution was to mount a few +inches above the LED module a diffuser. The diffuesr spreads the light nicely +while also blocking direct visual exposure of the module LEDs. + +# Mechanical mounting notes + +This was a quick project, so the mechanicals are of the basic prototype variety. +The electronics are mounted on perfboard in a small project box, and a short +section of 28 AWG cat 5e cable delivers current to the LED module. A DC wall +wart is used for power, and the heat sink is mounted in the lamp with hot glue. diff --git a/in/projects/rgblamp/random.md b/in/projects/rgblamp/random.md new file mode 100644 index 0000000..65b2b93 --- /dev/null +++ b/in/projects/rgblamp/random.md @@ -0,0 +1,22 @@ +title: A Source of Randomness +linktitle: rgb-random +parent: rgb-code +ctime: 2012-03-10 +mtime: 2012-03-10 + +# Randomness + +The lamp implements a 'party' mode, which randomizes the next color and the time +for which that color will be displayed before the next color change. The code +uses an efficient parallel bit implementation of a Galois linear shift register. +However, unless a random seed value can be acquired, the sequence will be the +same each and every time. + +# Truly random + +The PIC16 has no PRNG (pseudo-random number generator). An approach to +simulating a PRNG is to use the ADC to capture from an unused pin. The +assumption is that noise present in the last least significant bit or so of the +result can be summed to generate a pseudo-random number. No testing was done to +attempt to quantify the quality of this methodology, but it certainly provides +some amount of randomness and is adequate for the simple needs of this project. diff --git a/in/projects/rgblamp/task.md b/in/projects/rgblamp/task.md new file mode 100644 index 0000000..4c29f6c --- /dev/null +++ b/in/projects/rgblamp/task.md @@ -0,0 +1,65 @@ +title: RGB Lamp Tasks +linktitle: rgb-task +parent: rgb-code +ctime: 2012-03-10 +mtime: 2012-03-10 + +# Tasks + +A task implements an application behavior in response to an event. Tasks are +executed to completion without pre-emption. Task start requests are queued if +another task is already executing. A task start request when that task is +already queued to start is effectively a null operation. However, a task start +request for a task that is not queued but currently running will queue the task +for a subsequent execution. This very simple task design is more than +sufficient for the needs of the lamp application. + +One key decision under such a task architecture is which task to run next if +multiple tasks are queued. This code selects the task with the highest priority +in such a case. Application code must be cognizant of this fact, as a +perpetually queueing high priority task will prevent execution of a queued lower +priority task. This behavior is similar to hardware interrupt dispatch in many +processor architectures, so most developers should already be familiar with its +pitfalls. + +# Task implementation + +Tasks are implemented in the task.c, task.h and task_defs.h files, +as found in the [repository](http://oss/gitweb?p=rgblamp.git;a=summary). + +Task identifiers are defind in the task_defs.h file. Each task id is an +enumeration, with the highest priority task given the value of zero, and +successively lower priority tasks having incrementally larger numbers. Since +the task queue is implemented as bits in a variable, the width of the task_id_t +structure defines the maximum number of supported tasks. + +Before using, initialize the task subsystem: + + task_init(); + +To queue a task for execution, post it. Tasks can be posted from within an ISR +or from without. A task can post itself as well. + + task_post(TASK_ID); + +Task dispatch is constructed from the task_get() function, which atomically gets +and clears the next task (bit). The user application code then constructs a +switch statement or similar structure to call a function associated with each +task id. The lamp code implements this behavior in the user_tasks() function +in main.c. Check it out in the +[repository](http://oss/gitweb?p=rgblamp.git;a=summary). A short version: + + void user_tasks(unsigned char block) + { + task_id_t tid; + + while ((tid = task_get(block)) >= 0) { + switch (tid) { + case TASK_BTN_PB: + pb_task(); + break; + ... + } + } + } + diff --git a/in/projects/rgblamp/timer.md b/in/projects/rgblamp/timer.md new file mode 100644 index 0000000..d9a2528 --- /dev/null +++ b/in/projects/rgblamp/timer.md @@ -0,0 +1,51 @@ +title: RGB Lamp Timers +linktitle: rgb-timer +parent: rgb-code +ctime: 2012-03-10 +mtime: 2012-03-10 + +# Timers + +Most microcontroller applications must respond to temporal events. The timers +subsystem allows an application to have multiple timers running concurrently, +each with a different duration before expiration. This implementation is very +simple, in that timers can be started, stoped, and polled for expiration +(fired). By integrating with tasks, a timer expiration can post an event. + +Timers are identified by a timer id. A timer started will fire at the end of +the time period specified in the timer start call. A timer may also be started +via startPeriodic(), which will fire the timer periodically according to the +timer period specified in the call. + +# Implementation + +The timer subsystem is implemented through the use of the PIC16 TMR0. It is +configured to trigger a hardware interrupt every 32.768 milliseconds. Within +each interrupt, the status of the currently active timers is updated. This is a +very simplistic approach. A better solution would be to use a timer compare +feature, which would dramatically reduce the number of ISR events and therefore +servicing overhead for the timer subsystem. + +Periodically the application can poll for timer fired by the tmr_fired() call. +A good time to do this is in the ISR, and timers that fire can post tasks. The +comments in tmr.h gives a complete example. Check the +[repository](http://oss/gitweb?p=rgblamp.git;a=summary). + +# Timer and low power modes + +Unfortunately, the PIC16 has limitations when it comes to using timers in sleep. +While it is true that Timer 1 can run when the PIC16 is in sleep using an +external 32 kHz crystal, no timer compare feature is possible in sleep. +Therefore, the only timer inerrupt that can wake the micro is the overflow. +This overflow happens every 2 seconds. In fact, the lamp code uses this +behavior to handle the long term timer events via the tmr32 module. +Specifically, this is used for the auto-off and auto-on events. + +It is possible to get different overflow periods by programmatically setting the +Timer 1 register. Since this is a 16 bit value implemented in 2 8-bit +registers, there are race conditions that challenge this use. But the ability +to support variable timer periods in sleep is possible. + +When it comes to managing temporal events and deep sleep, the MSP430, the EFM32, +and the STM32L are superior processors. + diff --git a/in/projects/tinyos.md b/in/projects/tinyos.md new file mode 100644 index 0000000..d47d43b --- /dev/null +++ b/in/projects/tinyos.md @@ -0,0 +1,59 @@ +title: TinyOS +linktitle: tinyos +parent: projects +ctime: 2009-12-07 +mtime: 2012-03-21 + +Repositories: [tinyos](/gitweb/?p=tinyos-2.x.git;a=summary), +[deputy-tinyos](/gitweb/?p=deputy-tinyos.git;a=summary), +[nesc](/gitweb/?p=nesc.git;a=summary), +[[aptrepo]]. + +# TMI TinyOS + +TMI maintains a [TinyOS](http://www.tinyos.net) branch containing certain +features not available in the official tree. We use this this code for our +internal and customer development efforts. TMI enhancements include: + +* Support for newer [[msp430]] chipsets, such as the MSP430F2618. + +* An implementation of the USCI peripheral, supporting UART, SPI and I2C + communications. Both SPI slave and master modes are supported, with the + driver knowing what to do in slave mode if the master unasserts the slave chip + select line. + +* Enhanced clock framework supporting parts with the basic_clock+ peripheral + and simplifying changing msp430 clock speeds on a per platform or per + application basis. + +* Support for a number of other chips, including the Silicon Labs + [[cp210x]] USB to UART adapters, the Texas Instruments BQ2403x Li Ion/Polymer + charge controllers, and the VTI SCP1000-D01 barometric pressure sensor. + +* A modularized tos-bsl program that simplifies adding other msp430 boards using + different mechanisms to access BSL programming features. Included is support + for boards using the cp2103 and its GPIO pins to effect BSL via USB. + +* Support for TMI reference platform design, [[tmicore]]. + +# About the TMI repository + +The TMI TinyOS repository is based upon code from the [official +repo](http://tinyos-main.googlecode.com/svn/). The TMI repository contains +various branches and tags representing current and past work. Most notably, the +tags beginning with `patchset/` are clean patches against a given official +upstream release. + +* Current patchset tag: `patchset/2.1.1-4.5` +* TMI enhancements are based upon the upstream release tag: `tinyos/2.1.1` +* The commits between the two above tags represent the series of patches in the + [latest patchset](/gitweb/?p=tinyos-2.x.git;a=shortlog;h=refs/tags/patchset/2.1.1-4.5). + +The TMI TinyOS code requires a GCC 4.4+ based [[msp430]] toolchain. + +# Using TMI TinyOS + +A complete TinyOS development environment including toolchain is available for +installation from our [[APT repository|aptrepo]]. Since we only use Ubuntu +workstations for our internal development, we cannot cost justify maintaining +packages for Windows or other Linux distributions at this time. diff --git a/in/projects/tmicore.md b/in/projects/tmicore.md new file mode 100644 index 0000000..2ff32b3 --- /dev/null +++ b/in/projects/tmicore.md @@ -0,0 +1,21 @@ +title: tmicore +parent: projects +ctime: 2009-12-02 +mtime: 2009-12-02 + +Repositories: SOON + +TMI has developed an [[msp430]] target board for low power data acquisition. +Its design is not complete yet, but it is (SOON) available under an open +source license. The design was created using [Eagle](http://www.cadsoft.de). +It provides a breakout of all uC pins, incorporates a Lithium Ion/Poly charger, +and a USB interface for communications and programming. + +The actual design files are for the tmirws board, which is a superset of the +tmicore design. One can trivially derive the tmicore design by simply cutting +the board layout at the inner rectangle. The tmirws design is the heart of an +off-grid solar powered remote weather station that reports its observations to +an internet server via the cellular network. + +TMI enhanced [[tinyos]] contains platform support for both the tmicore and +tmirws variants of this design. diff --git a/in/rgblamp.md b/in/rgblamp.md deleted file mode 100644 index 4b6ac06..0000000 --- a/in/rgblamp.md +++ /dev/null @@ -1,20 +0,0 @@ -title: RGB Lamp -linktitle: rgblamp -parent: Home -ctime: 2012-03-24 - -The RGB Lamp was a little filler project. A 4.2W CREE RGBW LED module is driven -by a PIC16LF1933. Learn more: - -* [[Code Notes|rgb-code]] -* [[Features|rgb-features]] -* [[Mechanical|rgb-mechanical]] -* [Source Code](/gitweb/?p=rgblamp.git;a=summary) - -A future implementation might accept audio input from a stereo jack or onboard -microphone, use a DFT to examine the frequency components present in the audio -stream, represent each of several bands of frequencies with a color whose -brightness is proportional to the signal strength, then 'mix' the per-frequency -color results into an RGBW output that can drive the LED module. Because of the -higher performance needed, we will probably use a STMicro STM32 or EnergyMicro -EFM32 low power ARM Cortex-M3 processor. diff --git a/in/rgblamp/code.md b/in/rgblamp/code.md deleted file mode 100644 index b6086f0..0000000 --- a/in/rgblamp/code.md +++ /dev/null @@ -1,29 +0,0 @@ -title: RGB Lamp Code -linktitle: rgb-code -parent: rgblamp -ctime: 2012-03-24 - -PIC code for the [[rgblamp]] is written in C and compiled using the MPLAB X -cross-platform IDE and the HI-TECH C compiler. - -The lamp code uses a simple event driven strategy. Events are generally -initiated through hardware events. Application logic is structured as a set of -tasks, each of which is executed in response to a given event. Because much of -the behavior of the lamp application is dependent upon timing, a timer -abstraction is also useful. - -So, this code uses both of these useful abstractions: tasks and timers. This -project hacks together some basic support for tasks and timers for the PIC16. -Thankfully the atypical architecture of the PIC16 is mostly abstracted by the C -compiler. And because this is such a simple project, the simplistic interrupt -handling of the PIC16 is not an issue either. And although not very flexible in -its use, driving Timer 1 via a 32 kHz crystal offers reasonable support for -auto-on from soft off. - -* [[rgb-task]] -* [[rgb-timer]] - -The project yielded some other other novel tidbits. - -* [[rgb-leds]] -* [[rgb-random]] diff --git a/in/rgblamp/features.md b/in/rgblamp/features.md deleted file mode 100644 index 81a9a80..0000000 --- a/in/rgblamp/features.md +++ /dev/null @@ -1,36 +0,0 @@ -title: RGB Lamp Features -linktitle: rgb-features -parent: rgblamp -ctime: 2012-03-24 - -# [[rgblamp]] features - -* Auto power cycling, 5 hours on, 19 hours off. -* Brightness level adjustment -* Twelve colors, which include white and a simulated candle color -* Several modes: random color change, slow color change, and fixed color -* Simulated candle flicker for all colors except for white -* Persistent state configuration - -# The power switch - -The power switch has three positions: off, on, and auto. When the switch -position changes to auto, a timer is started that turns off the lamp in five -hours, then back on again nineteen hours later. - -# The push button - -When the pushbutton is depressed briefly, then released, the lamp color mode is -changed. Modes cycle through all twelve color modes, the first of which is the -candle simulation and the last of which is white. The mode immediately -following white is the slow color change mode, which itself cycles through the -colors every sixteen minutes. The next and final mode is a rapid and random -color change mode (party mode). A mode change when in party mode returns to the -first mode. - -When the pushbutton is depressed and held, brightness varies until the -pushbutton is released. Brightness is dimmed until a minimum brightness is -reached. After a short delay at the minimum brightness, brightness is -then increased over time until a maximum brightness is reached. After a short -delay at the maximum brightness, the process repeats. Once the pushbutton is -released, the brightness setting at that point is retained persistently. diff --git a/in/rgblamp/leds.md b/in/rgblamp/leds.md deleted file mode 100644 index 385b4f3..0000000 --- a/in/rgblamp/leds.md +++ /dev/null @@ -1,58 +0,0 @@ -title: RGB Lamp Led Driver -linktitle: rgb-leds -parent: rgb-code -ctime: 2012-03-24 - -# PWM drive - -The LEDs in the module receive varying current to adjust their brightness via -the hardware PWM features of the PIC16LF1933 in conjunction with Timer 2. The -module has 4 capture/compare peripherals, which is perfect for the 4 LEDs in the -module. - -Each PWM output controls a simple current limited 2-transister drive circuit. -This circuit is superior to a simple single transistor switch, as the CE -junction of one transistor is used as a fixed voltage drop controlling current -through a resistor of known size. This is particularly nice given that -different LED modules have differnt voltage drops, and voltage drop is also a -function of current and temperature. A fixed current driver removes these -variables. - -# Mixing color and brightness - -An interesting challenge is to manipulate the output of the discrete color LEDs -both for the purpose of emitting a specific color and for controlling the -brightness. The solution is to treat the pre-computed PWM output value as a -fraction of the maximum value (255). In the same fashion, the color range and -the brightness are also treated as a fraction of their respective maximums. -Therefore, the rgb drive output is essentially the product of the color and -brightness values. Simple, and it seems to work out pretty well. - - rgb = 255 * (color/color_max * bright/bright_max) - -Of course, for this processor the preference is to do this computation in -integer math. The actual implementation looks more like this: - - color: 0..63 - bright: 0..BRIGHT_MAX - rgb = (color << 4) * bright / 4 / BRIGHT_MAX - -# LEDs - -An interesting effect was uncovered during testing. A certain delta change in -drive string of a LED at a relatively low average power level is readily -perceptible vsually, while the same delta is hard to detect at higher power -levels. Some research shows this to be a nature of the human eye -- it -perceives changes at lower intensities more readily than at higher percentages -[(1)](http://neuroelec.com/2011/04/led-brightness-to-your-eye-gamma-correction-no/). -To get a perceived linear output, the PWM value must be adjusted according to -CIE Lightness. - - L* = 116(Y/Yn)^1/3 - 16 , Y/Yn > 0.008856 - L* = 903.3(Y/Yn), Y/Yn <= 0.008856 - -Using these formulas, a look-up table can be created to provide the -compensation. It works pretty well. The rgb.c and rgb.h files in the -[repository](http://oss/gitweb?p=rgblamp.git;a=summary) implement this feature. -Note that there are two different look-up tables available, depending upon the -resolution desired. diff --git a/in/rgblamp/mechanical.md b/in/rgblamp/mechanical.md deleted file mode 100644 index 88653ed..0000000 --- a/in/rgblamp/mechanical.md +++ /dev/null @@ -1,53 +0,0 @@ -title: RGB Lamp Features -linktitle: rgb-mechanical -parent: rgblamp -ctime: 2012-03-24 - -The [[rgblamp]] mechanicals are based on a little rectangular lamp purchased at -IKEA. The CREE LED module is placed on a 1/2 inch think heat sink designed for -the module, and that module is mounted inside the lamp in place of the standard -screw bulb mount. - -There are several challenges with this design. First, the LED module must not -exceed its thermal specs during operation. Second, the lamp must not expose -human eyes to the direct output of the LED module. Finally, we need to find a -way to mount both the module and the electronics. - -# Thermal issues - -The -[datasheet](http://media.digikey.com/PDF/Data%20Sheets/Wakefield%20Thermal%20PDFs/882_Series.pdf) -for the 0.5 inch thick [heat -sink](http://search.digikey.com/us/en/products/882-50AB/345-1104-ND/2640527) -specifies a 60 degree C rise in temperature when dissipating 9W with natural -convection. That is 60/9 or 6.67 C/W. Since the [CREE LED -module](http://search.digikey.com/us/en/products/MCE4CT-A2-RGBCW-STAR-IND/955-1043-ND/2357817) -will be limited to 350 mA at about 3.2 V by the control circuitry, maximum power -dissipation is 1.12 W per LED, or 4.48 W for the entire module. In ambient air, -the 0.5 inch heatsink will see a rise over ambient of about 30 degrees Celcius. -So if room temperature is 30 C (86 F), the temperature and the juntion beween -the module and the heatsink should be about 60 C. I failed to locate a maximum -junction temperature for this module, but 60 C is not too high for most other -LEDs out there. To ensure good thermal contact, the module was secured to the -heat sink with machine screws and a bit of thermal paste. - -In operation, the lamp when tested in operation suggests the heat sink is -actually performing a bit better than the data sheet numbers suggest. - -# Eye protection - -The problem with the IKEA lamp used is that it is open through the top. This is -an advantage thermally because the lamp acts like a chimney, allowing cool air -to enter through the opening in the bottom -- which was left open for -ventilation purposes -- and warmer air to rise out of the top. The downside is that a -person could easily look into the lamp from above. These high power modules can -cause retinal damage, so this is a problem. The solution was to mount a few -inches above the LED module a diffuser. The diffuesr spreads the light nicely -while also blocking direct visual exposure of the module LEDs. - -# Mechanical mounting notes - -This was a quick project, so the mechanicals are of the basic prototype variety. -The electronics are mounted on perfboard in a small project box, and a short -section of 28 AWG cat 5e cable delivers current to the LED module. A DC wall -wart is used for power, and the heat sink is mounted in the lamp with hot glue. diff --git a/in/rgblamp/random.md b/in/rgblamp/random.md deleted file mode 100644 index 3a26df2..0000000 --- a/in/rgblamp/random.md +++ /dev/null @@ -1,21 +0,0 @@ -title: A Source of Randomness -linktitle: rgb-random -parent: rgb-code -ctime: 2012-03-24 - -# Randomness - -The lamp implements a 'party' mode, which randomizes the next color and the time -for which that color will be displayed before the next color change. The code -uses an efficient parallel bit implementation of a Galois linear shift register. -However, unless a random seed value can be acquired, the sequence will be the -same each and every time. - -# Truly random - -The PIC16 has no PRNG (pseudo-random number generator). An approach to -simulating a PRNG is to use the ADC to capture from an unused pin. The -assumption is that noise present in the last least significant bit or so of the -result can be summed to generate a pseudo-random number. No testing was done to -attempt to quantify the quality of this methodology, but it certainly provides -some amount of randomness and is adequate for the simple needs of this project. diff --git a/in/rgblamp/task.md b/in/rgblamp/task.md deleted file mode 100644 index 30759f2..0000000 --- a/in/rgblamp/task.md +++ /dev/null @@ -1,64 +0,0 @@ -title: RGB Lamp Tasks -linktitle: rgb-task -parent: rgb-code -ctime: 2012-03-24 - -# Tasks - -A task implements an application behavior in response to an event. Tasks are -executed to completion without pre-emption. Task start requests are queued if -another task is already executing. A task start request when that task is -already queued to start is effectively a null operation. However, a task start -request for a task that is not queued but currently running will queue the task -for a subsequent execution. This very simple task design is more than -sufficient for the needs of the lamp application. - -One key decision under such a task architecture is which task to run next if -multiple tasks are queued. This code selects the task with the highest priority -in such a case. Application code must be cognizant of this fact, as a -perpetually queueing high priority task will prevent execution of a queued lower -priority task. This behavior is similar to hardware interrupt dispatch in many -processor architectures, so most developers should already be familiar with its -pitfalls. - -# Task implementation - -Tasks are implemented in the task.c, task.h and task_defs.h files, -as found in the [repository](http://oss/gitweb?p=rgblamp.git;a=summary). - -Task identifiers are defind in the task_defs.h file. Each task id is an -enumeration, with the highest priority task given the value of zero, and -successively lower priority tasks having incrementally larger numbers. Since -the task queue is implemented as bits in a variable, the width of the task_id_t -structure defines the maximum number of supported tasks. - -Before using, initialize the task subsystem: - - task_init(); - -To queue a task for execution, post it. Tasks can be posted from within an ISR -or from without. A task can post itself as well. - - task_post(TASK_ID); - -Task dispatch is constructed from the task_get() function, which atomically gets -and clears the next task (bit). The user application code then constructs a -switch statement or similar structure to call a function associated with each -task id. The lamp code implements this behavior in the user_tasks() function -in main.c. Check it out in the -[repository](http://oss/gitweb?p=rgblamp.git;a=summary). A short version: - - void user_tasks(unsigned char block) - { - task_id_t tid; - - while ((tid = task_get(block)) >= 0) { - switch (tid) { - case TASK_BTN_PB: - pb_task(); - break; - ... - } - } - } - diff --git a/in/rgblamp/timer.md b/in/rgblamp/timer.md deleted file mode 100644 index b851a20..0000000 --- a/in/rgblamp/timer.md +++ /dev/null @@ -1,50 +0,0 @@ -title: RGB Lamp Timers -linktitle: rgb-timer -parent: rgb-code -ctime: 2012-03-24 - -# Timers - -Most microcontroller applications must respond to temporal events. The timers -subsystem allows an application to have multiple timers running concurrently, -each with a different duration before expiration. This implementation is very -simple, in that timers can be started, stoped, and polled for expiration -(fired). By integrating with tasks, a timer expiration can post an event. - -Timers are identified by a timer id. A timer started will fire at the end of -the time period specified in the timer start call. A timer may also be started -via startPeriodic(), which will fire the timer periodically according to the -timer period specified in the call. - -# Implementation - -The timer subsystem is implemented through the use of the PIC16 TMR0. It is -configured to trigger a hardware interrupt every 32.768 milliseconds. Within -each interrupt, the status of the currently active timers is updated. This is a -very simplistic approach. A better solution would be to use a timer compare -feature, which would dramatically reduce the number of ISR events and therefore -servicing overhead for the timer subsystem. - -Periodically the application can poll for timer fired by the tmr_fired() call. -A good time to do this is in the ISR, and timers that fire can post tasks. The -comments in tmr.h gives a complete example. Check the -[repository](http://oss/gitweb?p=rgblamp.git;a=summary). - -# Timer and low power modes - -Unfortunately, the PIC16 has limitations when it comes to using timers in sleep. -While it is true that Timer 1 can run when the PIC16 is in sleep using an -external 32 kHz crystal, no timer compare feature is possible in sleep. -Therefore, the only timer inerrupt that can wake the micro is the overflow. -This overflow happens every 2 seconds. In fact, the lamp code uses this -behavior to handle the long term timer events via the tmr32 module. -Specifically, this is used for the auto-off and auto-on events. - -It is possible to get different overflow periods by programmatically setting the -Timer 1 register. Since this is a 16 bit value implemented in 2 8-bit -registers, there are race conditions that challenge this use. But the ability -to support variable timer periods in sleep is possible. - -When it comes to managing temporal events and deep sleep, the MSP430, the EFM32, -and the STM32L are superior processors. - diff --git a/in/ro-root.md b/in/ro-root.md deleted file mode 100644 index 21a0a31..0000000 --- a/in/ro-root.md +++ /dev/null @@ -1,96 +0,0 @@ -title: Read Only Root -linktitle: ro-root -parent: Home -ctime: 2012-08-02 - -For GNU/Linux desktop installations, I prefer to have the root filesystem, -which mounts to /, be mostly read-only. This means that /home, /var and /tmp -need to be mounted elsewhere. The benefits of this approach are several, but -two in particular stand out for desktop use cases. - - * It is much easier to do a clean install the OS. User data in /home, and - in some cases application data in /var, need not be backed up and restored - in the process. Of course recent backups should still be available. - * A root fs that is rarely written to is a good candidate for SSD (solid state - disk) storage. This allows one the performance benefit of SSD while - mitigating a critical deficiency. Current SSD technology is not nearly - as reliable as mechanical disk in read/write environments, so reducing - writes to SSD is a productive strategy. - -Placing /home on a separate partition is easy, and GNU/Linux desktop installers -have supported this for some time. And thanks to the recent introduction of -/run (see [here](http://lwn.net/Articles/436012/) to learn more), migrating -/var to a separate filesystem is now pretty easy for desktop installs. - -Of course, with multiple partitions, there is the issue of what to do if one of -them fills up. A common solution is to use LVM. Volumes are given minimal -practical sizes, and then incrementally grown as required. LVM works fine on -the desktop, but requires a bit more knowledge and effort to administer. - -A simpler solution is to use bind mounts. By bind mounting /var from /home/var -and /tmp from /home/tmp, all user, variable and temporary data are on a single -partition. The root partition will be nearly static in content and size. I -currently use a 25 GB root partition on desktop installs, and that filesystem is -generally only about 25% full, even with a large number of development tools -installed. A swap partition is present of course, and the rest of the available -hard drive storage space is assigned to the home partition, which now holds the -contents of /var and /tmp. Essentially, /home, /var and /tmp share a common -large pool of storage, so there is less need for a volume manager. I am finding -this configuration to be quite optimal for developer desktops at my company. - -# Using bind mounts in a new installation - -These notes assume Xubuntu 12.04 desktop i386 installation, but a similar -process should work for other distributions and versions. - - * Boot from the xubuntu 12.04 desktop CD - * Run the installation - * Use a custom configuration when asked - * At least three partitions are required: root, swap and home - * Proceed with installation until the installer asks to reboot to continue - -Before rebooting, access a shell and type the following commands - - cd target # where the new root filesystem is currently mounted - cp -a var home/var # copy var to its new storage location - mv var var.old # can remove later - mkdir var # Need some dirs and symlinks during boot for some OSes - ln -s /run var/run - ln -s /run/lock var/lock - cp -a tmp home/tmp # copy tmp to its new storage location - mv tmp tmp.old - mkdir tmp - vi etc/fstab # add the following 2 bind mounts to end of /etc/fstab - /home/var /var bind defaults,bind,noatime,mode=0755 0 0 - /home/tmp /tmp bind defaults,bind,noatime,mode=1777 0 0 - sync - -Now allow the installer to reboot. The system should boot up using the bind -mounts for /var and /tmp, so their contents will actually be stored in the home -partition at locations /home/var and /home/tmp, respectively. Once the system -appears to be working OK, you may remove the /var.old and /tmp.old directories. - -# Upgrading to use bind mounts - -First, boot from a recovery or live CD, then run commands like the following -commands. - - mkdir /mnt - mount /dev/sda1 /mnt # replace /dev/sda1 with dev for your root - mount /dev/sda2 /mnt/home # replace /dev/sda2 with dev for your home - cd /mnt - cp -a var home/var # copy /var to its new storage location - mv var var.old # can remove later - mkdir var # Need some dirs and symlinks during boot for some OSes - ln -s /run var/run - ln -s /run/lock var/lock - cp -a tmp home/tmp # copyt /tmp to its new storage location - mv tmp tmp.old # can remove later - mkdir tmp - vi etc/fstab # add the following 2 bind mounts to end of /etc/fstab - /home/var /var bind defaults,bind,noatime,mode=0755 0 0 - /home/tmp /tmp bind defaults,bind,noatime,mode=1777 0 0 - sync - -Now remove the CD and reboot. You should be using bind mounts. Once the system -appears to be working OK, you may remove the /var.old and /tmp.old directories. diff --git a/in/style/default.tmpl b/in/style/default.tmpl index e7bea88..ec48ef4 100644 --- a/in/style/default.tmpl +++ b/in/style/default.tmpl @@ -99,7 +99,7 @@ oss@this.domain
<% - recently = get_recently() + recently = get_recently(max_items = 20) %> % if len(recently) > 1:

Recent Changes

@@ -133,7 +133,7 @@ ${self.contents()}

-Copyright (C) 2001-2011 Titanium Mirror, Inc. All Rights Reserved

+Copyright (C) 2001-2012 Titanium Mirror, Inc. All Rights Reserved

This page last updated ${format_date(file.mtime)}

diff --git a/in/tinyos.md b/in/tinyos.md deleted file mode 100644 index 6b9d90d..0000000 --- a/in/tinyos.md +++ /dev/null @@ -1,58 +0,0 @@ -title: TinyOS -linktitle: tinyos -parent: Home -ctime: 2009-12-07 - -Repositories: [tinyos](/gitweb/?p=tinyos-2.x.git;a=summary), -[deputy-tinyos](/gitweb/?p=deputy-tinyos.git;a=summary), -[nesc](/gitweb/?p=nesc.git;a=summary), -[[aptrepo]]. - -# TMI TinyOS - -TMI maintains a [TinyOS](http://www.tinyos.net) branch containing certain -features not available in the official tree. We use this this code for our -internal and customer development efforts. TMI enhancements include: - -* Support for newer [[msp430]] chipsets, such as the MSP430F2618. - -* An implementation of the USCI peripheral, supporting UART, SPI and I2C - communications. Both SPI slave and master modes are supported, with the - driver knowing what to do in slave mode if the master unasserts the slave chip - select line. - -* Enhanced clock framework supporting parts with the basic_clock+ peripheral - and simplifying changing msp430 clock speeds on a per platform or per - application basis. - -* Support for a number of other chips, including the Silicon Labs - [[cp210x]] USB to UART adapters, the Texas Instruments BQ2403x Li Ion/Polymer - charge controllers, and the VTI SCP1000-D01 barometric pressure sensor. - -* A modularized tos-bsl program that simplifies adding other msp430 boards using - different mechanisms to access BSL programming features. Included is support - for boards using the cp2103 and its GPIO pins to effect BSL via USB. - -* Support for TMI reference platform design, [[tmicore]]. - -# About the TMI repository - -The TMI TinyOS repository is based upon code from the [official -repo](http://tinyos-main.googlecode.com/svn/). The TMI repository contains -various branches and tags representing current and past work. Most notably, the -tags beginning with `patchset/` are clean patches against a given official -upstream release. - -* Current patchset tag: `patchset/2.1.1-4.5` -* TMI enhancements are based upon the upstream release tag: `tinyos/2.1.1` -* The commits between the two above tags represent the series of patches in the - [latest patchset](/gitweb/?p=tinyos-2.x.git;a=shortlog;h=refs/tags/patchset/2.1.1-4.5). - -The TMI TinyOS code requires a GCC 4.4+ based [[msp430]] toolchain. - -# Using TMI TinyOS - -A complete TinyOS development environment including toolchain is available for -installation from our [[APT repository|aptrepo]]. Since we only use Ubuntu -workstations for our internal development, we cannot cost justify maintaining -packages for Windows or other Linux distributions at this time. diff --git a/in/tinyospkgs.md b/in/tinyospkgs.md index 789bfef..50d45b4 100644 --- a/in/tinyospkgs.md +++ b/in/tinyospkgs.md @@ -2,6 +2,7 @@ title: TinyOS Packages linktitle: tinyospkgs parent: aptrepo ctime: 2009-12-10 +mtime: 2012-07-09 Repositories: [tinyos](/gitweb/?p=tinyos-2.x.git;a=summary), [deputy-tinyos](/gitweb/?p=deputy-tinyos.git;a=summary), diff --git a/in/tmicore.md b/in/tmicore.md deleted file mode 100644 index 91b4d0c..0000000 --- a/in/tmicore.md +++ /dev/null @@ -1,20 +0,0 @@ -title: tmicore -parent: Home -ctime: 2009-12-02 - -Repositories: SOON - -TMI has developed an [[msp430]] target board for low power data acquisition. -Its design is not complete yet, but it is (SOON) available under an open -source license. The design was created using [Eagle](http://www.cadsoft.de). -It provides a breakout of all uC pins, incorporates a Lithium Ion/Poly charger, -and a USB interface for communications and programming. - -The actual design files are for the tmirws board, which is a superset of the -tmicore design. One can trivially derive the tmicore design by simply cutting -the board layout at the inner rectangle. The tmirws design is the heart of an -off-grid solar powered remote weather station that reports its observations to -an internet server via the cellular network. - -TMI enhanced [[tinyos]] contains platform support for both the tmicore and -tmirws variants of this design. diff --git a/in/virtual-win7.md b/in/virtual-win7.md deleted file mode 100644 index 691ff95..0000000 --- a/in/virtual-win7.md +++ /dev/null @@ -1,289 +0,0 @@ -title: Virtual Windows 7 -linktitle: virtual-win7 -parent: Home -ctime: 2011-07-28 - -# Introduction - -This page documents the process of converting a dual-boot Linux/Windows -installation into a Linux installation running the Windows partition under a -KVM virtual machine. This work was first performed under Ubuntu 10.10 and -11.04 versions. - -# Why virtualize Windows 7? - -During my development activities, customer needs infrequently require use of -software only available under Windows. But booting between OSes is an -incredible waste of time and drain on productivity. My work notebook, a Lenovo -X201, came pre-installed with an OEM version Windows 7 Home Premium. The -obvious solution? Virtualize Windows under Linux. - -# Microsoft licensing issues? - -[[!pquote text="The OEM Windows EULA allows for virtualization"]] - -I downloaded the EULA for Windows 7 from microsoft.com as applicable for -pre-installed OEM versions of Windows 7 Home Premium. For this OS configuration, -the license specifically allows execution of the pre-installed OEM OS when -virtualized on the same hardware. The actual text is found in Section 3.d: - -> Use with Virtualization Technologies. Instead of using the software directly -on the licensed computer, you may install and use the software within only one -virtual (or otherwise emulated) hardware system on the licensed computer. When -used in a virtualized environment, content protected by digital rights -management technology, BitLocker or any full volume disk drive encryption -technology may not be as secure as protected content not in a virtualized -environment. You should comply with all domestic and international laws that -apply to such protected content. - -# Virtualization requirements - -For Windows virtualization to be effective in my development use cases, the -following requirements and constraints must be met. Additionally, I want the -virtualization solution to support running additional virtual machines as well. - -* Run 32-bit x86 Windows 7 from 32-bit x86 Ubuntu Linux 10.10 and newer. -* Run various flavors of Linux or other Intel x86 based operating environments. -* No unnecessary dependences to software or hardware that will limit the -ability of the virtualized OS from functioning properly in the future. -* Ability to run with native disk, not disk-as-file, for improved IO -performance. -* Supports use of VT-x and VT-d, again for performance. -* Will be sufficiently performant on the target hardware when virtualized. The -X201 has an i5-M560 CPU which offers 4 cores at 2.66 GHz each, and 8 GB of RAM. -* Simple management of VMs, including configuration, start and stop. -* VMs must behave sanely in the presence of host OS power saving functionality, -like suspend. -* There is no requirement to continue to run Win7 natively. -* High end graphics are not required: no need for 3D, Aero effects, video -playback, etc. -* And finally, a reliable mechanism return to the prior physical configuration -if the VM experiment fails to work as hoped. - -# Selecting a virtualization framework - -There are a few virtualization options suitable for use on a development system, -including VMware, Xen, VirtualBox, and KVM. All can do the job, but KVM was -chosen for a variety of reasons: - -* KVM has the features needed, and is available through the standard -Ubuntu repositories. -* KVM management via libvirt is more than adequate. -* KVM can use an SDL local window for rendering the virtualized OS, for quite -good display performance. -* The enterprise features of Xen are overkill for this application. -* VMWare is not open source, so there is some concern about support for this -particular hardware in the far future (I tend to keep hardware for a very long -time). -* VirtualBox can not access USB hardware unless the purchased version is used. - -The virtual machine manager, using libvirt, is a pretty nice environment. This -management tool already supports a few different VM strategies, called -*backends*, and they are likely to improve moving forward. Therefore, gaining -knowledge about VMM, libvirt, and KVM could in the near future represent -an intellectual asset deployable against future customer needs. - -# Disk organization, pre-virtualization - -Prior to any changes, the 320 GB notebook disk drive was organized as follows: - - /dev/sda1, 1.17 GiB, Label=SYSTEM_DRV - /dev/sda2, 78.17 GiB, Label=WindowsOS_7 - /dev/sda3, 19.68 GiB, Label=Lenovo_Recovery - /dev/sda4, an extended partition container - /dev/sda5, 15.26 GiB, swap partition - /dev/sda6, 23.84 GiB, / partition - /dev/sda7, 159.96 GiB, /home partition - -* The SYSTEM_DRV apparently supports the Lenovo ThinkVantage functionality -which includes some backup and restore capability. -* The WindowsOS_7 partition is the one to virtualize, containing the licensed -OEM version of Windows 7 Home Premium that came with this notebook. -* The system boots using Grub2, which initially included an entry to boot the -Windows_7 partition. - -# The solution - -Unfortunately, the solution is not so simple as to point the VM to the /dev/sda2 -partition. First, the virtual hardware expects to see a hard drive, complete -with partition table. Second, suitable drivers for the virtual hardware must be -installed into the windows installation. I took several steps to convert -/dev/sda2 in place to look like a hard drive (kpartx, etc) but the best I could -accomplish was Windows 7 hanging during boot. Since my expertise with Windows -internals is limited, and so is the information available online, I elected to -do a clean re-install Windows from the virtual environment. - -## Create backups - -### R&R image - -Levnovo offers a recovery capability accessible by booting the Lenovo_Recovery -partition. I used this to create a recovery image for the WindowsOS_7 -partition. - -* Create a windows repair disc from the Win7 OS -* Create an R&R recovery boot disc -* Back up the current Win7 image via R&R to the Lenovo_Recovery partition. This -required removing all other prior backups because of size constaints in that -partition. -* Back up the current Win7 image to a set of DVD optical discs. It took 3: a -boot disc and two data discs. - -### Partition level backups - -Since the space was available in the Linux partition, I opted to create parition -level backups as well, which would be 'easier' to restore, at least for me. - - # Backup the first MiB of /dev/sda to capture MBR and any bootloader stuff - dd if=/dev/sda of=mbr.save bs=1M count=1 - # Use ntfsclone to make a space-efficient copy of the windows partition - ntfsclone --save-image -o - /dev/sda2 | gzip -c > sda2.img.gz - -## Prepare /dev/sda2 for virtualization - -First, /dev/sda2 must look like a DOS style disk, complete with disk level -partition information. This can be accomplished using this fdisk command: - - fdisk -c -u /dev/sda2 - -Drive fdisk to create a single windows partition spanning the entirety of the -'disk' (actually the physical partition /dev/sda2). Now /dev/sda2 will look -like a valid disk image usable by a VM to re-install Windows 7. - -## Install the virtualization tools in Linux - - sudo apt-get install virt-manager virt-viewer python-vm-builder \ - kvm-pxe ubuntu-vm-builder - -I tested the VM tools by creating an Ubuntu 11.04 install. I ran the Virtual -Machine Manager using an Ubuntu 11.04 install .iso image as its CD-ROM. The -installation was successful and the resulting virtual machine worked without -fail. - -## Re-install Windows 7 - -Next windows was re-installed. A Windows 7 Home Premium 32-bit OEM .iso was -used to do a clean install of Win7. See the virtioinstall.sh script for more -information. I used the Win7 iso, and virtual floppy and CD-ROM images from -RedHat containing signed virtio drivers for disk and network devices. The VM was -started using the virtio disk driver, booting into the Win7 iso. Then the -virtual floppy was accessed during the Win7 install process to load in the -virtio drivers so the Win7 install program could see the disc, which was of -course the disk image on the host /dev/sda partition. I formatted the 'drive' -(which is really the /dev/sda2 partition on the physical drive), then proceeded -to install Win7 onto it. The installation process, from first boot of the Win7 -iso, to first user login to Win7, took just under 45 minutes. - -At this point, the VM was stopped so its configuration could be altered it use -the virtio network driver. The VM was then restarted with the virtio iso from -RedHat connected as the virtual CD-ROM disc. Once Win7 was running, in device -manager the drivers for the broken network device were updated from the .iso to -get the network running. The virtio network interface seems very efficient. The -VM configuration was finally modified to provide for 2 CPU cores and 2 GB of -RAM. - -## Re-activate Windows 7 - -At this time, Win7 had to be re-activated. The online technique failed, so the -phone call technique was required. It was a bit painful, but the end result was -a properly activated installation. - -## Install other Windows 7 tools - -Since I installed from scratch, I had to reinstall the few tools I use under -Windows. Since these tools were few in number, this process was pretty -painless. This strategy would be much more painful if there were lots of tools -and/or custom configuration or data required to be recovered. - -## Improving diplay performance - -The default display mechanism when interacting with the Windows VM display is -VNC. This is not very performant. Since the Windows VM is only to be accessed -from the local hardware, I instead configured the VM to use SDL for rendering -the VM display in a window. Interestingly, this change also allowed sound from -the Win7 VM to propagate to the sound hardware. The SDL configuration is fast -enough to watch Netflix from the VM. - - Stop the win7 VM - Reconfigure the VM: - Remove VNC graphics entry for the VM and add the local SDL one. - Change the sound driver to ac97 - Edit /etc/libvirt/qemu.conf. Add: - user = "smckown" - group = "smckown" - sudo service libvirtd-bin restart - Restart the virtual machine - -### Why not SPICE? - -The SDL method creates a new local window that hosts the VM display. It cannot -be embedded into the virtual manager VM window. It looks like the better -solution is going to be to use the SPICE facility. Special drivers in the VM -work with special client features to implement a much improved connection. SPICE -provides better display performance than VNC, can do stereo sound, and also -provides for USB redirection. As of 7/13/12, Ubuntu 12.04 does not have the -right stuff to do spice through virt-manager. There is a PPA that will allow it. -The nice thing about SPICE is it is network-able and can be embedded. Since -network access to the VM is not necessary, the SDL window method seems optimal. - -## Anti Virus considerations - -It should be noted that the VM, as the native install before it, is running -Microsoft Security Essentials for Anti-Virus. There appears a noticeable -performance hit for using AV within the VM, in comparison to running it -natively. Unfortunately, the protection offered is probably worth the -performance penalty. - -# Conclusion - -I am quite happy with the results of this process. Win7 boots noticeably faster -from the VM than it did on native hardware. Disk CPU are perceptibly sluggish -within the VM with respect to native performance, but it is tolerable. Network -performance seems on par with native. For the tasks in which I will use -Windows, the virtual machine performance is more than adequate. - -Of course the big win is that Win7 can be running simultaneously with Ubuntu. -This solves a host of workflow problems and removes the terrible inefficiencies -caused by having to boot between the two OSes natively. For one, I was able to -continue working with apps in the host Ubuntu OS while the Win7 VM chugged away -literally for hours downloading and rebooting ad nauseum as it updated itself -with the latest Win7 SP1 and subsequent patches. - -My overall concern with this strategy is that a change in Microsoft policy could -complicate my life. Although this use of my windows license is perfectly -legitimate according to my reading of the EULA, I depend upon Windows Product -Activation to honor this legitimacy. Here is to hoping that Microsoft will take -care to ensure that their WPA policies retain convenient use of Windows for all -legitimate uses. - ---- - -# Updates - -### 2012-08-13 -After using this configuration for over a year, I have found it to be quite -reliable. The upgrade to 12.04 triggered Windows Product Activation, and -another phone call to the automated WPA phone number was required. The -activation was successful. - ---- - -# Links - -The following links, in no particular order, were invaluable in completing this project. Thanks to all those who published their prior experience for others to use! - -* -* -* -* -* -* -* -* -* -* -* -* -* -* -* diff --git a/in/webber.md b/in/webber.md deleted file mode 100644 index 943de46..0000000 --- a/in/webber.md +++ /dev/null @@ -1,12 +0,0 @@ -title: Webber -linktitle: webber -parent: Home -ctime: 2009-12-15 - -Repositories: [webber](/gitweb/?p=webber.git;a=summary). - -[Webber](http://gitorious.org/webber) is a great static website generator -written in Python by -[Holger Schurig](http://www.holgerschurig.de/projects/webber/). We maintain -a [local copy](/gitweb/?p=webber.git;a=summary) of his repository -with a few changes. This website is built using webber; see [[oss-web]]. diff --git a/in/wwvb.md b/in/wwvb.md deleted file mode 100644 index af10e2b..0000000 --- a/in/wwvb.md +++ /dev/null @@ -1,87 +0,0 @@ -title: WWVB -linktitle: wwvb -parent: Home -ctime: 2011-10-28 - -Repositories: SOON - -TMI uses a WWVB receiver in its RWS product. -[WWVB](http://www.nist.gov/pml/div688/grp40/wwvb.cfm) is a radio station -operated out of Ft. Collins, CO by NIST, which provides a 60Hz carrier wave on -which is encoded the current time as synchronized with a pair of on-site atomic -oscillators. The low frequency of the WWVB broadcast means it is available -through most of North America. Perhaps you have heard of *Atomic Clock* radios. -These simply incorporate a WWVB receiver which is then used to automatically -set, and periodically compensate, the radio's internal real time clock -circuitry. - -TMI's RWS (Remote Weather Station) project collects weather data completely -autonomously, time-stamping recorded data using its onboard RTC. The WWVB -broadcast is used to both initially set the RTC, and to periodically compensate -for its drift over time. - -TMI chose to incorporate the C-MAX -[CMMR-6](http://www.c-max-time.com/products/showProduct.php?id=31) WWVB receiver -into its RWS design. This simple board requires very little power, and the fact -that the WWVB receiver need only be consulted occasionally to compensate for RTC -drift means its time averaged power consumption is very low. The CMMR-6 offers -a simple output, TCO, treated as a digital signal. TCO is logic high when the -WWVB carrier is transmitting at full power, and is logic low when the WWVB -carrier is transmitting at reduced power. Each second uses a variable period in -which the carrier is at reduced power to encode one of three values: a 0 bit, a -1 bit, and a frame marker. 60 of these tri-state bits form a time frame -containing the time, to the minute, during the current frame transmission. More -about the WWVB signal format is available -[here](http://tf.nist.gov/stations/wwvbtimecode.htm). - -While the [WWVB time code format](http://tf.nist.gov/stations/wwvbtimecode.htm) -is easy to parse, this is not so true in the presense of noise. TMI has chosen -to address noise by implementing a digital 4th order Butterworth filter, using a -32Hz sample rate and a 3 Hz cutoff frequency. The filter inputs are either 0.0 -and 1.0, sampled from the CMMR-6 TCO pin, and the filter output is some fraction -inclusive of the range 0.0 through 1.0. The microprocessor code implements -hysteresis to generate a digital output, where outputs >= 0.7 are treated as -logic 1, outputs <= 0.3 are logic zero, and any value in between these -thresholds leave the logic output unchanged. This filter, implemented within -the uC, requires up to 5% of the CPU while WWVB is in operation, but does a -stellar job at cleaning up the WWVB signal. To evaluate filters and generate -their implementation logic, we used the simple and easy to use -[Fiview](http://www.uazu.net/fiview) design tool. - -Consider the following oscilliscope capture of live WWVB reception. TCO is the -output from the CMMR, and FOUT is the output from the digital filter. Note that -the filter delays the signal by approximately 200 ms. - -![Oscilloscope capture image](images/wwvb-capture.png) - -As mentioned earlier, the duration of the low period indicates the bit type. -200 ms for bit 0, 500 ms for bit 1, and 800 ms for a frame mark. As can be seen -in the TCO trace, there is a significant amount of relatively high frequency -noise interfering with the TCO signal. A discrete algorithm would likely be -unreliable in decoding TCO. However, the filtered output, FOUT, successfully -removed all the noise with minimal signal distortion. A discrete algorithm can -parse FOUT with a high degree of reliability. In this case, the trace as -decoded -- 0 0 1 0 M 0 0 1 1 -- was the correct sequence for the captured frame. - -The decode algorithm determines a bit value for the current low period duration -that is best matched by the expected durations. But the low pass filter cannot -remove all sources of error, so a frame may be received with bits in error. -Frames are validated according to the [WWVB time code -format](http://tf.nist.gov/stations/wwvbtimecode.htm), and two frames must have -matching data to consider a valid time acquisition. Of course in this sense, -matching frames do not have the exact same values, but the second frame's -contents differ from the first frame's only by the number of minutes separating -their acquisition. - -There are still a few enhancements possible in this design. First, the TCO -signal could be captured via an ADC, to bring additional information on each -bit into the filter. This, however, might require some software gain control -depending upon how good the CMMR-6 AGC circuitry is, and may not be worth the -effort. - -The second enhancement is one that will be implemented. Instead of matching two -complete frames to indicate valid aquisition, instead match complete frame -sections. Three incoming frames all with errors in different sections would -allow this latter approach to construct a known good frame, where the current -algorithm could not. In very noisy cases, this enhancement should perform -better.