Get it Here

Current feature list for version 0.7:

• Checks “In Stock” when opening a category page
• Deselects bulk packaging types like “Tape & Reel” when opening a category page
• Adds a checkbox interface to several “features” fields, enabling much faster filtering

Changes in version 0.7:

• Updated to work with the new modifications to the Digi-Key site.
• Removed sort-by-price shortcuts for now since the interface changed.

Suggestions welcome!

It is built around a STM32F107 processor with built-in 100 Mbit Ethernet MAC, paired with an inexpensive transceiver to provide an excellent Ethernet interface with predictable and minimal latency. This is in contrast to the USB-based MACs found in low-cost single-board computers. Also included is a small temperature-compensated crystal oscillator (TCXO) that keeps the internal clock ticking steadily.

Laureline is open-source hardware, provided under the Creative Commons Attribution 3.0 license. It was developed using Altium Designer but a PDF of the schematic as well as the Gerber and NC Drill outputs is provided below. The current revision number is 7.

The Laureline software is also open-source and is provided under the MIT License. Laureline includes and links against CoOS (BSD license), lwIP, (BSD license), and ChaN’s FatFs (permissively licensed). The software can be inspected, modified, compiled and uploaded to the burned-in bootloader using nothing more than the GCC ARM Embedded toolchain, standard build tools (GNU Make, etc.), and a Micro-SD card.

• Documentation
• Schematic PDF rev. 7
• GitHub – Source code and firmware downloads
• Mercurial source control repository – CAD documents

It provides a linear 3.3V power supply for the RT/RSMT board and 3.3V or 5V for the antenna, all from a 5V input (either external or from USB). Serial communications is available via either USB or RS-232 or both. If both are connected, USB takes precedence and can transmit to the RT or RSMT board, but both RS-232 and USB always receive data simultaneously from the RT or RSMT. Pulse-per-second output is provided via the RS-232’s DCD (carrier detect) line, and a 50-ohm driven 100mil header connector. An unpopulated SMA footprint with the same 50 ohm output is also provided. The 50-ohm output will drive 2.5V into a 50 ohm load, or 5V into a high-impedance load.

Buy it on Tindie

Feature list

• 5V input power via header or USB
• Onboard 3.3V linear regulator
• Solder jumper for selecting 3.3V or 5V for antenna power (default 5V)
• Serial RS232 on DE-9 female connector
• Serial USB on 5-pin Mini-B connector
• Pulse-per-second on the RS232 DCD pin (negative-going)
• Pulse-per-second on 100mil header (positive-going) and unpopulated SMA connector, drives 2.5V into a 50 ohm load or 5V into a high-impedance load
• 4-pin header with logic-level (3.3V) serial and PPS – use with Arduino, Raspberry Pi, or other microcontrollers alongside your PC
• Board has same shape and mounting holes as RT/RSMT board, and mounts directly on top
• Windows and Mac OS drivers for USB connectivity are available from FTDI . No drivers required for operation under Linux.
• Revision 4 and earlier: Windows drivers available from Microchip

Source

PPS Piggy is open-source hardware, provided under the
Creative Commons Attribution 3.0 license.
It was developed with Altium Designer but a PDF of the schematic as well as the
Gerber and NC Drill outputs is provided below. The current revision is number 5.2.

Schematic PDF (revision 5.2)
Source Bundle (revision 5.2)
Mercurial source control repository

Get it Here

Current feature list for version 0.6:

• Checks “In Stock” when opening a category page
• Deselects bulk packaging types like “Tape & Reel” when opening a category page
• Adds a checkbox interface to several “features” fields, enabling much faster filtering
• Adds shortcut links for “sort by price” to product listings

Changes in version 0.6:

• Updated to work with the new modifications to the Digi-Key site.

Suggestions welcome!

The goal will be to build a complete toolchain with working gcc, binutils,
and uClibc, sufficient to compile both OS-less microcontroller firmware and
high-level linux software.

Step 1: Setup

This bootstrap will be done in a simple directory tree that keeps clean
source trees separate from build directories. This makes it trivial to nuke a
dir and start over if you make a mistake. First, you will need a top-level
directory. Mine is ~/armcross2. Then, you will need these
subdirectories:

• source – Original source trees
• build – Scratch space for builds
• sysroot – Install root for target binaries
• tools – Install prefix for build binaries

Once those are created, download and unpack your sources into the
source directory. I will be using the following, which were the latest
at the time:

• binutils 2.21.1a
• gcc 4.6.2
• linux 3.1
• uClibc 0.9.32

Next, create a script in the top directory called env.sh . This
will hold environment variables for convenience, and must be executed first
every time you open a terminal to be sure that they are set. In it, place the
following:

top=~/armcross2  # Change me
target=arm-linux-uclibceabi
arch=arm
tools=$top/tools
sysroot=$top/sysroot
export PATH=$tools/bin:/usr/bin:/bin
[ -z "$oldps1" ] && oldps1="$PS1"
PS1="(toolchain) $oldps1"

Don’t change the target unless you like pain. I could explain what it means,
but it really boils down to how different tools interpret it, and most of the
target-related problems tend to come from gcc which is no fun at all. Now load
your environment with the “.” command (that’s a single period):

.  env.sh

The PS1 line causes the terminal prompt to change so that you know
your environment is loaded. Now you’re ready to compile.

Step 2: binutils

binutils, as its name implies, is a suite of tools for manipulating and
inspecting program binaries. It includes the linker, assembler, and tools for
converting object code to various formats that one might need.

To compile and install it, execute these commands:

cd $top/build
mkdir binutils; cd binutils
../../source/binutils-*/configure \
  --target=$target \
  --prefix=$tools \
  --with-sysroot=$sysroot
make -j4
make install

Step 3: linux headers

There are two important sets of headers on a linux system, one comes from
libc and the other comes from the kernel. Neither are terribly important when
you have no operating system but gcc won’t compile without them. First comes
the kernel headers.

cd $top/build
mkdir linux; cd linux
make -C ../../source/linux-*/ O=`pwd` headers_install \
  ARCH=$arch CROSS_COMPILE=$target- \
  INSTALL_HDR_PATH=$sysroot/usr/

Step 4: gcc bootstrap

A full toolchain bootstrap requires building GCC 3 separate times. In
theory this first build is sufficient to produce microcontroller firmware,
however in my experience it is too difficult to use since it seems to not have
enough information about where headers are located.

cd $top/build
mkdir gcc-1; cd gcc-1
../../source/gcc-*/configure \
  --target=$target \
  --prefix=$tools \
  --without-headers --with-newlib --disable-shared \
  --disable-threads --disable-libssp --disable-libgomp \
  --disable-libmudflap --disable-libquadmath \
  --enable-languages=c
make -j4 all-gcc
make install-gcc

Step 5: libc headers

Next the libc headers need to be installed. This will involve first
configuring uClibc, which has a menu-driven system identical to that used by
the kernel. Use the arrow keys to navigate, enter to select, and press escape
twice to go back to the previous menu.

cd $top/build
mkdir uclibc; cd uclibc
make -C ../../source/uClibc-*/ O=`pwd` menuconfig

Now configure as follows: First, set the “Target Architecture” to arm.
Then enter the “features and options” submenu and set “Target Processor Endianness”
to “Little Endian”. Go up a level and enter the “General Library Settings”
menu, and set “Thread support” to “older (stable) version of linuxthreads”. You
don’t have to have a libc with threading support, but if it is disabled you
will need to adjust the configure options to gcc parts 2 and 3.
Finally, back out and save your configuration, then complete the installation:

make -C ../../source/uClibc-*/ O=`pwd` install_headers install_startfiles \
  DESTDIR=$sysroot CROSS=$target- \
  RUNTIME_PREFIX=/ DEVEL_PREFIX=/usr/ STRIPTOOL=true \
  KERNEL_HEADERS=$sysroot/usr/include

Step 6: gcc, Part 2

First, a dirty trick. In order to compile all the components of gcc, a libc
is required. But libc hasn’t been built yet, and can’t be until gcc #2 is done.
What to do? Fake it. A libc.so with no contents will be created first,
which will placate the linker well enough to get gcc built, and then the real
libc will be built in the next step.

$target-gcc -nostdlib -nostartfiles -shared -x c /dev/null -o $sysroot/usr/lib/libc.so
cd $top/build
mkdir gcc-2; cd gcc-2
../../source/gcc-*/configure \
  --target=$target \
  --prefix=$tools \
  --with-sysroot=$sysroot \
  --disable-libssp --disable-libgomp --disable-libmudflap \
  --disable-libquadmath --enable-languages=c
make -j4
make install

Step 7: libc

Next, the final libc will be built.

cd $top/build/uclibc
make -C ../../source/uClibc-*/ O=`pwd` all install -j4 \
  DESTDIR=$sysroot CROSS=$target- \
  RUNTIME_PREFIX=/ DEVEL_PREFIX=/usr/ STRIPTOOL=true \
  KERNEL_HEADERS=$sysroot/usr/include

Step 8: gcc, Part 3

Now the third and final gcc will be built against the new libc and with all
features enabled. One more hack is required; as documented here and here a configure
script must be modified to not run a test it is unable to execute.

cd $top/build
mkdir gcc-3; cd gcc-3
../../source/gcc-*/configure \
  --target=$target \
  --prefix=$tools \
  --with-sysroot=$sysroot \
  --enable-__cxa_atexit \
  --disable-libssp --disable-libgomp --disable-libmudflap \
  --enable-languages=c,c++
make -j4
make install

Step 9: Profit!!

If you made it this far, you have gcc compiled and installed into your tools
directory. Congratulations! All you have to do to use it, is add your
tools/bin directory to PATH and prefix toolchain commands with your
target setting (in this case, arm-linux-uclibceabi-). You can check
out a makefile I used for a Cortex-M3 device
here

What I hacked on today is a way to configure gPXE to fetch all of the
pxelinux confguration over HTTP rather than the traditional TFTP, thus
creating the possibility of bootstrapping an installer over the internet.
To make this more useful in practice, instead of creating a PXE image which
would require a functioning DHCP server to launch I created a disk image that can be loaded onto a USB key or virtual flash device such as those found on DRAC or iLO management cards. This means I can now remotely flash gpxelinux onto a server and network boot into an install of Fedora or Scientific Linux, for example.

To get started, first set up a typical pxelinux environment and make it
reachable via HTTP. Then build a gPXE image with a URL to that environment
hardcoded in it using these steps:

git clone git://git.kernel.org/pub/scm/boot/syslinux/syslinux.git
make
cd gpxe/src

cat >netinst.gpxe <<EOD
#!gpxe
dhcp net0
set 209:string pxelinux.cfg/default
set 210:string http://my.http.server/pxeroot/
imgload pxelinux.0
boot pxelinux.0
EOD

make bin/gpxe.sdsk EMBEDDED_IMAGE=netinst.gpxe,../../core/pxelinux.0 NO_WERROR=1

You can then upload gpxe.sdsk to a DRAC Virtual Flash. Alternately, replace
“gpxe.sdsk” with “gpxe.dsk” for a hard drive image or “gpxe.usb” for a USB-key
friendly output. I found the sdsk (floppy image) format to work best with the
DRAC’s Virtual Flash device.

Some tips:

• Many Dell servers ship with Broadcom NICs which require firmware to
  function correctly. I could not reliably pull down files using gPXE with
  one of these NICs. The gPXE project is purportedly working on improving this
  as a Google Summer of Code project. You will need to change ‘net0’ to
  e.g. ‘net2’ if you have additional non-Broadcom NICs that you wish to boot
  from.
• You can change the ‘dhcp’ line in the gPXE script to configure a static IP
  instead, see the gPXE wiki page on scripting for examples.