TS-8100-4700

TS-8100-4700

Released Mar. 2011
Product Page
TS-4700 Documents
Schematic
Mechanical Drawing
FTP Path
TS-8100 Documents
Revision A Schematic
Revision B Schematic
Mechanical Drawing
FTP Path
Processor
Marvell PXA166
800MHz ARM9
CPU Series Website
PXA16X Software Guide
RAM
256MB DDR2
FPGA
Lattice LFXP2-5E or LFXP2-8E
Reprogrammable with Opencore
DIO
21
External Interfaces
PC/104 Bus
USB 2.0 1x host
1x 10/100 Ethernet
1x I2C/TWI
SPI
3x RS232
1x RS-232/Console Port
1-2x RS485 Port
1-2x CAN
Character Display
6x ADC
Internal Storage Media
1x SD
256MB XNAND
Power Requirements
5-28VDC
Operates around 2W
Operating Temperature
-20C
70C
Mechanical
114.30mm X 100.00mm
Height 19.22mm
Weight 83.10 (approx)

Overview

The TS-8100 baseboard is an upgrade path from our TS-7350/TS-7370 series providing a PC104 bus, multiple serial ports, LCD, and a DIO header.

Getting Started

A Linux PC is recommended for development, and will be assumed for this documentation. For users in Windows or OSX we recommend virtualizing a Linux PC. Most of our platforms run Debian and if there is no personal distribution preference this is what we recommend for ease of use.

• Debian.org

Virtualization

• Virtualbox (Windows or OSX hosts)
• VMware Player
• Parallels (OSX)

Suggested Linux Distributions

• Debian
• Ubuntu

It may be possible to develop using a Windows or OSX system, but this is not supported. Development will include accessing drives formatted for Linux and often Linux based tools.

TS-8100 Options and Accessories

TS-8100 Options

Item	Description
	The TS-8100 is a TS-Socket Baseboard including a PC104 bus, DIO, RS232, RS485, and an optional second ethernet.
	The optional "OP-ETH" replaces the push button and instead populates a second ethernet port. This utilizes a USB ethernet which will work with any System-on-Module.
	The optional "OP-CAN2-485" includes the optional second #CAN and RS485 transceiver.
	The option "OP-STHRU-64" includes a 64 pin PC104 connector that extends the pins so the TS-8100 does not need to be the base of the PC104 stack. This option is not required for stacking PC104 peripehral on the TS-8100 as the peripherals include a stack through connector.

The other options include:

Item	Description
	The RC-DB9 brings out the 10 pin connection to a DB9. See the RC-DB9 page for the exact pinout. The red line indicates pin 1 and should be lined up with the white dot on the board.
CB-DB9-Y	CB-DB9-Y description
	The CB-USB-AF5P connects from a standard 5 pin 0.1" pitch header to a USB A host. This can be used to expose a single USB port while keeping the rest internal to your own enclosure.
	The CB7-05 is a 5 foot null modem cable. This is commonly used to connect to your workstation.
	The KPAD is a 4x4 keypad compatible with the DIO header on the TS-81XX.
LCD-LED	LCD-LED description
PS-12VDC-REG-2P2	PS-12VDC-REG-2P2 description
PS-5VDC-REG-2P1	PS-5VDC-REG-2P1 description
TS-ENC720-7200	TS-ENC720-7200 description
	The WIFI-N-USB is an ASUS 802.11N adapter. See the WIFI-N-USB page for more details.
KPAD-LCD	KPAD-LCD description

Booting up the board

WARNING:

Be sure to take appropriate Electrostatic Discharge (ESD) precautions. Disconnect the power source before moving, cabling, or performing any set up procedures. Inappropriate handling may cause damage to the board.

The TS-8100-4700 accepts 5-28VDC input connected to the two terminal blocks.

While operating the board will typically idle at around 340mA@5V, but this can very slightly based on your application. For example, every USB device can consume up to 500mA@5V. The ethernet interface can draw around 50mA while the interface is up. Every DIO pin can source up to 12mA from the FPGA. A Sandisk SD card can draw 65mA@3.3V during a write. A typical power supply for just the TS-8100-4700 will allow around 1A, but a larger power supply may be needed depending on your peripherals.

Once you have applied power to your baseboard you should look for console output. Creating this connection is described more in the next chapter, but the first output is from the bootrom:

  >> TS-BOOTROM - built Dec 21 2011 10:05:44
  >> Copyright (c) 2011, Technologic Systems
  >> Booting from microSD card ...
  .
  .
  .

The 3 dots after indicate steps of the booting procedure. The first dot means the MBR was copied into memory and executed. The next two dots indicate that the MBR executed and the kernel and initrd were found and copied to memory.

The "Booting from XXXX...." message will indicate your boot media. On the TS-8160 this is controlled by the "SD Boot" jumper hear the ethernet connectors:

Get a Console

The TS-8100 console is an RS232 UART at 115200 baud, 8n1 (8 data bits 1 stop bit), and no flow control. On the TS-8100 you need to set the "Console Enable" jumper as pictured:

This will bring the console UART to both the DB9 Port, and the COM1 Header.

Note:

If DIO_9 is held low during boot until the red LED comes on (around 5 seconds), console will be redirected to XUART 0. On most baseboards where this is applicable, DIO_9 is an exposed button.

Console from Linux

There are many serial terminal applications for Linux, three common used applications are picocom, screen, and minicom. These examples demonstrate all three applications and assume that the serial device is "/dev/ttyUSB0" which is common for USB adapters. Be sure to replace the serial device string with that of the device on your workstation.

picocom is a very small and simple client.

sudo picocom -b 115200 /dev/ttyUSB0

screen is a terminal multiplexer which happens to have serial support.

sudo screen /dev/ttyUSB0 115200

Or a very commonly used client is minicom which is quite powerful but requires some setup:

sudo minicom -s

• Navigate to 'serial port setup'
• Type "a" and change location of serial device to "/dev/ttyUSB0" then hit "enter"
• If needed, modify the settings to match this and hit "esc" when done:

     E - Bps/Par/Bits          : 115200 8N1
     F - Hardware Flow Control : No
     G - Software Flow Control : No

• Navigate to 'Save setup as dfl', hit "enter", and then "esc"

Console from Windows

Putty is a small simple client available for download here. Open up Device Manager to determine your console port. See the putty configuration image for more details.

Initrd / Busybox

When the board first boots you should see output similar to this:

 >> TS-BOOTROM - built Aug  4 2011 12:52:20
 >> Copyright (c) 2010, Technologic Systems
 >> Booting from microSD card ...
 .
 .
 .
 >> Booted from: SD card                 Booted in: 1.78 seconds
 >> SBC Model number: TS-4700            SBC Sub-model number: 0
 >> CPU clock rate: 797MHz               RAM size: 256MB
 >> NAND Flash size: 256MB               NAND Flash Type: 0xdcec (Samsung)
 >> MAC number: 00:D0:69:44:1A:E9        SBC FPGA Version: 4
 >> CPU Temperature: 49 degC             MODE1 bootstrap: OFF
 >> RTC present: YES                     Date and Time: Nov 17 2015 00:57:09
 >> Base board type: 62 RevD             Base board FPGA Version: 0x0
 >> MODE2 bootstrap: ON                  SD card size: 7788MB
 >> XUARTs detected: 7                   CAN present: NO
 >> Linux kernel version: 2.6.29-ts4700- Linux kernel date: Aug 23 2011
 >> Bootrom date: unknown                INITRD date: Sep 1 2011
 >> ts4700ctl date: Aug 22 2011          sdctl date: not present
 >> canctl date: not present             nandctl date: Aug 24 2011
 >> spiflashctl date: not present        xuartctl date: Aug 22 2011
 >> dioctl date: Aug 5 2010              spictl date: not present
 >> dmxctl date: Jul 23 2010             busybox date: Aug 12 2011 (v1.18.3)
 >> ts4700.subr date: Aug 23 2011        daqctl date: not present
 >> linuxrc date: Aug 23 2011            rootfs date: Sep 1 2011
 >> MBR date: Aug 23 2011
 Type 'tshelp' for help
 # 

This is a busybox shell which presents you with a very minimalistic system. This filesystem is loaded into memory, so none of the changes will be saved unless you type the command

save

or mount a filesystem as read/write. This can also provide a simple mechanism for running your application in an entirely read-only environment. The linuxrc script will be the first thing executed as soon as the kernel is loaded. This sets the default IP address, loads a reloadable FPGA bitstream if one is present, starts the userspace ctl applications, and more. Read the linuxrc for more information.

While busybox itself doesn't contain much functionality, it does mount the Debian partition under /mnt/root/. It will also add common paths and load libraries from the Debian system. Many of the Debian applications will work by default. For example, if you are using the TS-4700 with a video interface (or a touchpanel like the TS-TPC-8390), you will see icewm startup. The linuxrc will determine if the baseboard is one that is recognized with video, and start X11 with icewm from Debian. This is why it has the Debian logo since it uses their theme files, but is not usable as Debian. This is also only provided as a demo of X11 and not intended to be used for development. Whether or not a Debian application will work in fastboot needs to be judged per application. If an application relies on certain paths being in certain places, or running services, you should instead boot to Debian to run them.

This shell when started on the COM port is what is blocking a Debian boot. If you close it by typing

exit

the boot process will continue. If you are connected through telnet, this will instead open up its own instance of the shell so typing

exit

will only end that session. Through any connection method you can relink the linuxrc to change it to boot by default to Debian.

The initrd has these boot scripts available:

Script	Function
linuxrc-fastboot (default)	Boots immediately to a shell in ramdisk. This will mount whichever boot medium you have selected to /mnt/root/. When you type 'exit', it will boot to that medium.
linuxrc-nandmount	Same as the linuxrc-fastboot script, but will mount and boot the debian partition from NAND.
linuxrc-sdmount	Same as the linuxrc-fastboot script, but will mount and boot the debian partition from SD.
linuxrc-sdroot	Boots immediately to the Debian stored on either SD or NAND depending on which device you have currently selected.
linuxrc-sdroot-readonly	Same as linuxrc-sdroot, except it will mount the Debian partition read only while creating a unionfs with a ramdisk. Changes will only happen in memory and not on disk.
linuxrc-usbroot	Mounts the first partition of the first detected USB mass storage device and boots there.

Note:

Keep in mind the boot medium is selected by the pinout on your baseboard, not through software.

For example, to set the linuxrc to boot immediately to Debian on SD or NAND, you would run this:

rm linuxrc; ln -s /linuxrc-sdroot /linuxrc; save

We recommend developing in Debian initially and then porting to the initrd if you prefer. While we set up the initrd so many Debian binaries will run, this is not intended for running "apt-get" and will cause unpredictable behavior.

The small default initrd is only 2Mbyte but there is space for approximately 300 Kbyte of additional user applications. The binaries on the initrd are dynamically linked against embedded Linux's "uclibc" library instead of the more common Linux C library "glibc". "uclibc" is a smaller version of the standard C library optimized for embedded systems and requires a different set of GCC compiler tools which are available here.

Along with busybox we include some TS specific applications that provide driver functionalities or otherwise provide convenience.

• xuartctl - used to communicate with the xuarts.
  • Examples
    • xuartctl --server --port=0 --speed=115200 # 8n1 default
    • xuartctl --server --port=3 --speed=9600 --mode=9n1
  • See the xuartctl page for full documentation.
• ts4700ctl - provides control for FPGA DIO, offboard ADC support, reloading the FPGA bitstream, feeding the watchdog, toggling LEDs, and more.
  • Examples
    • ts4700ctl --redledon --greenledoff
    • ts4700ctl --getdio
    • ts4700ctl --info
    • ts4700ctl --loadfpga /ts4700_bitstream.vme.gz # this is run by default by the linuxrc startup script
  • See the output of ts4700ctl --help for full usage
• load_fpga - Allows you to reload the baseboard LFXP2 FPGA like those found on the TS-8100/TS-8900/TS-8820.
  • Example: load_fpga mybitstream.vme.gz
• nandctl - provides an NBD server that is used for accessing the XNAND.
  • This is already running by default. See the nandctl page for more details.
  • Example: nandctl -X -z 131072 --nbdserver lun0:disc,lun0:part1,lun0:part2,lun0:part3,lun0:part4
• peekpoke is an extremely useful utility that allows you to read and/or write memory in 8, 16, or 32 bit sizes.
  • Example: peekpoke 16 0x80004000 # read fpga id (0x4700)
  • Example: peekpoke 16 0x80004012 0x1800 # Enable green/red LEDs

We also provide the ts4700.subr which provides convenience functions in a shell script. These can be used from Debian by sourcing the subr file:

source /initrd/ts4700.subr
# Running /initrd/ts4700.subr will not do anything
# Once this is sourced you can run these commands in that shell 
# just like an application.  You can use these in
# your own shell scripts by sourcing this file.
tshelp

• printbin - Converts the first argument to a binary value
• usbload - Loads the USB modules required for the USB host controller. Does not load all USB modules. This does not work from Debian, but udev will autodetect the correct drivers during Debian's startup and load them automatically.
• save - Since the initrd is a ramdisk, this will allow you to commit the ramdisk to a persistent storage. The save command will detect your boot media, and write the currently booted initrd there. This does not work from Debian.
• sdsave - This will write the currently booted initrd to SD regardless of boot device. This does not work from Debian.
• nandsave - This will write the currently booted initrd to the XNAND regardless of boot device. This does not work from Debian.
• sd2nand - Copies the kernel and initrd from the SD to the XNAND. Assumes there is a valid MBR and partition on the XNAND. This does not work from Debian.
• nand2sd - Copies the kernel and initrd from the NAND to the SD card. Requires the SD card to already have the SD MBR and partition layout. This does not work from Debian.
• setdiopin - Sets the output value of a #DIO pin. The first argument is the DIO number.
• getdiopin - Gets the value of a #DIO pin. The first argument is the DIO number.
• tshelp - Shows available commands
• gettemp - Reads the LM73 temperature
• backlight_on - Enables the PWM backlight for baseboards with PWM controlled backlights like the 8390/8400/8900
• backlight_off - Disabled the backlight
• backlight_low - Sets the PWM backlight to a low value
• backlight_medium - Sets the PWM backlight to a medium value
• backlight_high - Sets the PWM backlight to the highest value
• speaker - The arguments on/off allow you to toggle a speaker on the baseboard like the 8390/8400/8900
• do_splash - Shows the splash screen and plays the startup sound

By default, linuxrc will not insert the necessary modules into the kernel to mount and use USB devices within the initrd/busybox environment if there is no USB device present upon bootup (USB support is enabled by default within the Debian environment). The quickest way to get a USB device (like a USB thumb drive) to mount in the initrd/busybox environment is to ensure that it is plugged in before the SBC is powered up. In order to get hot-swappable USB devices regardless of device presence at bootup time, you must "modprobe" the necessary modules. This has been done for you in the ts4700.subr file with the usbload() function.

The compiled instance of busybox includes several internal commands listed below:

 BusyBox v1.18.3 (2011-08-11 15:25:09 MST) multi-call binary.
 Copyright (C) 1998-2009 Erik Andersen, Rob Landley, Denys Vlasenko
 and others. Licensed under GPLv2.
 See source distribution for full notice.
 
 Usage: busybox [function] [arguments]...
    or: busybox --list[-full]
    or: function [arguments]...
 
         BusyBox is a multi-call binary that combines many common Unix
         utilities into a single executable.  Most people will create a
         link to busybox for each function they wish to use and BusyBox
         will act like whatever it was invoked as.
 
 Currently defined functions:
         [, [[, ar, ash, basename, cat, chat, chgrp, chmod, chown, chroot, chrt,
         cmp, cp, cpio, cttyhack, cut, date, dc, dd, depmod, devmem, df,
         dirname, dmesg, dnsdomainname, du, echo, egrep, env, expr, false,
         fdisk, fgrep, find, free, grep, gunzip, gzip, halt, head, hostname,
         hush, hwclock, ifconfig, insmod, ipcrm, ipcs, kill, killall, ln, login,
         ls, lsmod, lsusb, md5sum, mdev, microcom, mkdir, mkfifo, mknod,
         modinfo, modprobe, more, mount, mv, netstat, nohup, ping, pivot_root,
         poweroff, printf, ps, pwd, rdate, reboot, rm, rmdir, rmmod, route, rx,
         sed, seq, setconsole, setsid, sh, sha1sum, sha256sum, sha512sum, sleep,
         stty, sync, sysctl, tail, tar, tee, telnetd, test, tftp, time, top,
         touch, tr, true, udhcpc, umount, uname, unxz, unzip, uptime, usleep,
         uudecode, uuencode, vi, watch, wget, xargs, xz, xzcat, yes, zcat

Debian Configuration

For development, it is recommended to work directly in Debian on the SD card. Debian provides many more packages and a much more familiar environment for users already versed in Debian. Through Debian it is possible to configure the network, use the 'apt-get' suite to manage packages, and perform other configuration tasks. Out of the box the Debian distribution does not have any default username/password set. The account "root" is set up with no password configured. It is possible to log in via the serial console without a password but many services such as ssh will require a password set or will not allow root login at all. It is advised to set a root password and create a user account when the unit is first booted.

Note:

Setting up a password for root is only feasible on the uSD image.

It is also possible to cross compile applications. Using a Debian host system will allow for installing a cross compiler to build applications. The advantage of using a Debian host system comes from compiling against libraries. Debian cross platform support allows one to install the necessary development libraries on the host, building the application on the host, and simply installing the runtime libraries on the target device. The library versions will be the same and completely compatible with each other. See the respective Debian cross compiling section for more information.

Configuring the Network

From almost any Linux system you can use "ip" or the ifconfig/route commands to initially set up the network. To configure the network interface manually you can use the same set of commands in the initrd or Debian.

# Bring up the CPU network interface
ifconfig eth0 up

# Or if you're on a baseboard with a second ethernet port, you can use that as:
ifconfig eth1 up

# Set an ip address (assumes 255.255.255.0 subnet mask)
ifconfig eth0 192.168.0.50

# Set a specific subnet
ifconfig eth0 192.168.0.50 netmask 255.255.0.0

# Configure your route.  This is the server that provides your internet connection.
route add default gw 192.168.0.1

# Edit /etc/resolv.conf for your DNS server
echo "nameserver 192.168.0.1" > /etc/resolv.conf

Most commonly networks will offer DHCP which can be set up with one command:

Configure DHCP in Debian:

# To setup the default CPU ethernet port
dhclient eth0
# Or if you're on a baseboard with a second ethernet port, you can use that as:
dhclient eth1
# You can configure all ethernet ports for a dhcp response with
dhclient

Configure DHCP in the initrd:

udhcpc -i eth0
# Or if you're on a baseboard with a second ethernet port, you can use that as:
udhcpc -i eth1

To make your network settings take effect on startup in Debian, edit /etc/network/interfaces:

 # Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or 
 # /usr/share/doc/ifupdown/examples for more information.          
                                                                   
 # We always want the loopback interface.                          
 #
 auto lo
 iface lo inet loopback
 
 auto eth0
 iface eth0 inet static
   address 192.168.0.50
   netmask 255.255.255.0
   gateway 192.168.0.1                                             
 auto eth1
 iface eth1 inet dhcp

Note:

During Debian's startup it will assign the interfaces eth0 and eth1 to the detected mac addresses in /etc/udev/rules.d/70-persistent-net.rules. If the system is imaged while this file exists it will assign the new interfaces as eth1 and eth2. This file is generated automatically on startup, and should be removed before your first software image is created. The initrd network configuration does not use this file.

In this example eth0 is a static configuration and eth1 receives its configuration from the DHCP server. For more information on network configuration in Debian see their documentation here.

To make your changes permanent in the initrd you will need to edit the linuxrc script. Use the same commands you would use to manually configure it and place them over the current ifconfig calls.

Installing New Software

Debian provides the apt-get system which lets you manage pre-built applications. Before you do this you need to update Debian's list of package versions and locations. This assumes you have a valid network connection to the internet.

Note:

The NAND image is based on the emdebian project which is no longer maintained.

Debian Squeeze has been moved to archive so you will need to update /etc/apt/sources.list to contain only these two lines:

 deb http://archive.debian.org/debian squeeze main
 deb-src http://archive.debian.org/debian squeeze main

apt-get update

For example, lets say you wanted to install openjdk for Java support. You can use the apt-cache command to search the local cache of Debian's packages.

 <user>@<hostname>:~# apt-cache search openjdk                                                                                  
 icedtea-6-jre-cacao - Alternative JVM for OpenJDK, using Cacao                                                           
 icedtea6-plugin - web browser plugin based on OpenJDK and IcedTea to execute Java applets                                 
 openjdk-6-dbg - Java runtime based on OpenJDK (debugging symbols)                                                        
 openjdk-6-demo - Java runtime based on OpenJDK (demos and examples)                                                      
 openjdk-6-doc - OpenJDK Development Kit (JDK) documentation                                                              
 openjdk-6-jdk - OpenJDK Development Kit (JDK)                                                                            
 openjdk-6-jre-headless - OpenJDK Java runtime, using Hotspot Zero (headless)                                             
 openjdk-6-jre-lib - OpenJDK Java runtime (architecture independent libraries)                                            
 openjdk-6-jre-zero - Alternative JVM for OpenJDK, using Zero/Shark                                                       
 openjdk-6-jre - OpenJDK Java runtime, using Hotspot Zero                                                                 
 openjdk-6-source - OpenJDK Development Kit (JDK) source files                                                            
 openoffice.org - office productivity suite                                                                               
 freemind - Java Program for creating and viewing Mindmaps                                                                
 default-jdk-doc - Standard Java or Java compatible Development Kit (documentation)                                       
 default-jdk - Standard Java or Java compatible Development Kit                                                           
 default-jre-headless - Standard Java or Java compatible Runtime (headless)                                               
 default-jre - Standard Java or Java compatible Runtime                                                                   

In this case you will likely want openjdk-6-jre to provide a runtime environment, and possibly openjdk-6-jdk to provide a development environment. You can often find the names of packages from Debian's wiki or from just searching on google as well.

Once you have the package name you can use apt-get to install the package and any dependencies. This assumes you have a network connection to the internet.

apt-get install openjdk-6-jre
# You can also chain packages to be installed
apt-get install openjdk-6-jre nano vim mplayer

For more information on using apt-get refer to Debian's documentation here.

Setting up SSH

On our boards we include the Debian package for openssh-server, but we remove the automatically generated keys for security reasons. To regenerate these keys:

dpkg-reconfigure openssh-server

Make sure your board is configured properly on the network, and set a password for your remote user. SSH will not allow remote connections without a password or a shared key.

Note:

Setting up a password for root is only feasible on the uSD image.

passwd root

You should now be able to connect from a remote Linux or OSX system using "ssh" or from Windows using a client such as putty.

Note:

If your intended application does not have a DNS source on the target network, it can save login time to add "UseDNS no" in /etc/ssh/sshd_config.

Starting Automatically

From Debian the most straightforward way to add your application to startup is to create a startup script. This is an example simple startup script that will toggle the red led on during startup, and off during shutdown. In this case I'll name the file customstartup, but you can replace this with your application name as well.

Edit the file /etc/init.d/customstartup to contain this:

 #! /bin/sh
 # /etc/init.d/customstartup
 
 case "$1" in
   start)
     /sbin/ts4700ctl --redledon
     ## If you are launching a daemon or other long running processes
     ## this should be started with
     # nohup /usr/local/bin/yourdaemon &
     ;;
   stop)
     /sbin/ts4700ctl --redledoff
     ;;
   *)
     echo "Usage: customstartup start|stop" >&2
     exit 3
     ;;
 esac
 
 exit 0

Note:

The $PATH variable is not set up by default in init scripts so this will either need to be done manually or the full path to your application must be included.

To make this run during startup and shutdown:

update-rc.d customstartup defaults

To manually start and stop the script:

/etc/init.d/customstartup start
/etc/init.d/customstartup stop

To make your application startup from the initrd you only need to add this from the linuxrc script. Usually the best place to add in your application is right after /mnt/root/ is mounted so the Debian libraries and applications are available.

Backup / Restore

If you are using a Windows workstation there is no support for writing directly to block devices. However, as long as one of your booting methods still can boot a kernel and the initrd you can rewrite everything by using a usb drive. This is also a good way to blast many stock boards when moving your product into production. You can find more information about this method with an example script here.

Note:

Note that the MBR installed by default on this board contains a 446 byte bootloader program that loads the initial power-on kernel and initrd from the first and second partitions. Replacing it with an MBR found on a PC would not work as a PC MBR contains an x86 code bootup program.

MicroSD Card

If backing up on a separate workstation, keep in mind windows does not have direct block device support needed to write these images. You will also need to determine the SD card device. You can usually find this in the output of 'dmesg' after inserting the SD card and you will typically see something like '/dev/sdb' as the block device and '/dev/sdb1' for the first partition. On some newer kernels you will see '/dev/mmcblk0' as the block device and '/dev/mmcblkop1' for the first partition. For these examples I will use the '/dev/mmcblk0' format.

If you are backing up directly on the board you will likely need to use some kind of offboard storage like a thumbdrive or external hard drive. Make sure you have any nbd devices unmounted before trying to restore new ones.

You can find the latest SD card image here. Make sure you decompress the image first before writing.

Note:

Not all SD cards are created equally, over time they tend to shrink in size due to automatic retiring of bad blocks. All of Technologic System's images are 10% smaller than the target disc size. We STRONGLY recommend following that same practice on any mass-replicated images.

From Workstation

---

Backup

Entire SD card

dd if=/dev/mmcblk0 of=/path/to/backup.dd bs=4M

Note:

Not all SD cards are created equally, over time they tend to shrink in size due to automatic retiring of bad blocks. All of Technologic System's images are 10% smaller than the target disc size. We STRONGLY recommend following that same practice on any mass-replicated images.

Kernel

dd if=/dev/mmcblk0p2 of=/path/to/zImage bs=4M

Initrd

dd if=/dev/mmcblk0p3 of=/path/to/initrd bs=4M

Restore

Entire SD card

dd if=/path/to/backup.dd of=/dev/mmcblk0 bs=4M

Kernel

dd if=/path/to/zImage bs=4M of=/dev/mmcblk0p2

Initrd

dd if=/initrd bs=4M of=/dev/mmcblk0p3

From SBC

---

Backup

Entire card

dd if=/dev/mmcblk0 of=/path/to/backup.dd bs=4M

Kernel

dd if=/dev/mmcblk0p2 of=/path/to/backup.dd

Initrd

dd if=/dev/mmcblk0p3 of=/path/to/backup.dd

Restore

The entire card from SBC

dd if=/path/to/2GB-mSD-4700-latest.dd of=/dev/mmcblk0 bs=4M

Kernel

dd if=/mnt/root/zImage of=/dev/mmcblk0p2

Initrd

dd if=/mnt/root/initrd of=/dev/mmcblk0p3

Expected Partition Layout

Partition	Contents
1	FAT32 (empty)
2	kernel binary (0xda)
3	initrd (0xda)
4	Debian root filesystem (EXT3)

XNAND

This needs to be done directly on the SBC. Please note that all NBD partitions from the NAND card must be dismounted before attempting to image the NAND on the SBC.

WARNING:

Since there is no locking mechanism, it is not safe to run 2 copies of nandctl on this board. Make sure you unmount your filesystems and stop running nandctl if you prefer to backup/write data with that. These examples use 'dd' which is safe to use while nandctl is running.

You can find the latest xnand image here.

Backup

Entire Image

# Compressed
dd if=/dev/nbd0 bs=131072 count=2048 | gzip > backup.dd.gz
# or uncompressed
dd if=/dev/nbd0 bs=131072 count=2048 of=backup.dd

Kernel

dd if=/dev/nbd1 bs=512 count=5119 of=/path/to/backup/zImage

Initrd

dd if=/dev/nbd2 bs=512 count=5120 of=/path/to/backup/initrd

Restore

Entire Image

# If compressed
gunzip xnand-4700-latest.dd.gz 
# or uncompressed
dd if=xnand-4700-latest.dd bs=131072 count=2048 of=/dev/nbd0

Kernel

dd of=/dev/nbd1 bs=512 count=5119 if=/path/to/backup/zImage

Initrd

dd of=/dev/nbd2 bs=512 count=5120 if=/path/to/backup/initrd

Software Development

Most of our examples are going to be in C, but Debian will include support for many more programming languages. Including (but not limited to) C++, PERL, PHP, SH, Java, BASIC, TCL, and Python. Most of the functionality from our software examples can be done from using system calls to run our userspace utilities. For higher performance, you will need to either use C/C++ or find functionally equivalent ways to perform the same actions as our examples. Our userspace applications are all designed to go through a TCP interface. By looking at the source for these applications, you can learn our protocol for communicating with the hardware interfaces in any language.

The most common method of development is directly on the SBC. Since debian has space available on the SD card, we include the build-essentials package which comes with everything you need to do C/C++ development on the board.

Editors

Vim is a very common editor to use in Linux. While it isn't the most intuitive at a first glance, you can run 'vimtutor' to get a ~30 minute instruction on how to use this editor. Once you get past the initial learning curve it can make you very productive. You can find the vim documentation here.

Emacs is another very common editor. Similar to vim, it is difficult to learn but rewarding in productivity. You can find documentation on emacs here.

Nano while not as commonly used for development is the easiest. It doesn't have as many features to assist in code development, but is much simpler to begin using right away. If you've used 'edit' on Windows/DOS, this will be very familiar. You can find nano documentation here.

Compilers

We only recommend the gnu compiler collection. There are many other commercial compilers which can also be used, but will not be supported by us. You can install gcc on most boards in Debian by simply running 'apt-get update && apt-get install build-essential'. This will include everything needed for standard development in c/c++.

You can find the gcc documentation here. You can find a simple hello world tutorial for c++ with gcc here.

Build tools

When developing your application typing out the compiler commands with all of your arguments would take forever. The most common way to handle these build systems is using a make file. This lets you define your project sources, libraries, linking, and desired targets. You can read more about makefiles here.

If you are building an application intended to be more portable than on this one system, you can also look into the automake tools which are intended to help make that easier. You can find an introduction to the autotools here.

Cmake is another alternative which generates a makefile. This is generally simpler than using automake, but is not as mature as the automake tools. You can find a tutorial here.

Debuggers

Linux has a few tools which are very helpful for debugging code. The first of which is gdb (part of the gnu compiler collection). This lets you run your code with breakpoints, get backgraces, step forward or backward, and pick apart memory while your application executes. You can find documentation on gdb here.

Strace will allow you to watch how your application interacts with the running kernel which can be useful for diagnostics. You can find the manual page here.

Ltrace will do the same thing with any generic library. You can find the manual page here.

Cross Compiling

While you can develop entirely on the board itself, if you prefer to develop from another x86 compatible Linux system we have a cross compiler available. For this board you will want to use this toolchain. To compile your application, you only need to use the version of GCC in the cross toolchain instead of the version supplied with your distribution. The resulting binary will be for ARM.

[user@localhost]$ /opt/arm-2008q3/bin/arm-none-linux-gnueabi-gcc hello.c -o hello
[user@localhost]$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped

This is one of the simplest examples. If you want to work with a project, you will typically create a makefile. You can read more about makefiles here. Another common requirement is linking to third party libraries provided by Debian on the board. There is no exact set of steps you can take for every project, but the process will be very much the same. Find the headers, and the libraries. Sometimes you have to also copy over their binaries. In this example, I will link to sqlite from Debian (which will also work in the Ubuntu image).

Install the sqlite library and header on the board:

apt-get update && apt-get install -y libsqlite3-0 libsqlite-dev

This will fetch the binaries from the internet and install them. You can list the installed files with dpkg:

dpkg -L libsqlite3-0 libsqlite3-dev

The interesting files from this output will be the .so files, and the .h files. In this case you will need to copy these files to your project directory.

I have a sample example with libsqlite3 below. This is not intended to provide any functionality, but just call functions provided by sqlite.

#include <stdio.h>
#include <stdlib.h>
#include "sqlite3.h"

int main(int argc, char **argv)
{
	sqlite3 *db;
	char *zErrMsg = 0;
	int rc;
	printf("opening test.db\n");
	rc = sqlite3_open("test.db", &db);
	if(rc){
		fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
		sqlite3_close(db);
		exit(1);
	}
	if(rc!=SQLITE_OK){
		fprintf(stderr, "SQL error: %s\n", zErrMsg);
	}
	printf("closing test.db\n");
	sqlite3_close(db);
	return 0;
}

To build this with the external libraries I have the makefile below. This will have to be adjusted for your toolchain path. In this example I placed the headers in external/include and the library in external/lib.

CC=/opt/arm-2008q3/bin/arm-none-linux-gnueabi-gcc
CFLAGS=-c -Wall

all: sqlitetest

sqlitetest: sqlitetest.o
        $(CC) sqlitetest.o external/lib/libsqlite3.so.0 -o sqlitetest
sqlitetest.o: sqlitetest.c
        $(CC) $(CFLAGS) sqlitetest.c -Iexternal/include/

clean:  
        rm -rf *o sqlitetest.o sqlitetest

You can then copy this directly to the board and execute it. There are many ways to transfer the compiled binaries to the board. Using a network filesystem such as sshfs or NFS will be the simplest to use if you are frequently updating data, but will require more setup. See your linux distribution's manual for more details. The simplest network method is using ssh/sftp. You can use winscp if from windows, or scp from linux. Make sure you set a password from debian for root or set up a shared key. Otherwise the ssh server will deny connections. From winscp, enter the ip address of the SBC, the root username, and the password you have set or the use of a shared key. This will provide you with an explorer window you can drag files into.

Note:

Setting up a password for root is only feasible on the uSD image.

For scp in linux, run:

#replace with your app name and your SBC IP address
scp sqlitetest root@192.168.0.50:/root/

After transferring the file to the board, execute it:

ts:~# ./sqlitetest 
opening test.db
closing test.db

Compile the Kernel

WARNING:

Backup any important data on the board before continuing.

For adding new support to the kernel, or recompiling with more specific options you will need to have an X86 compatible linux host available that can handle the cross compiling. Compiling the kernel on the board is not supported or recommended. Before building the kernel you will need to install a few support libraries on your workstation:

Prerequisites

RHEL/Fedora/CentOS:

yum install ncurses-devel ncurses
yum groupinstall "Development Tools" "Development Libraries"

Ubuntu/Debian:

apt-get install build-essential libncurses5-dev libncursesw5-dev

For other distributions, please refer to their documentation to find equivalent tools.

Set up the Sources and Toolchain

# Download the cross compile toolchain (EABI)from Technologic Systems:
wget ftp://ftp.embeddedTS.com/ts-socket-macrocontrollers/ts-4700-linux/cross-toolchains/arm-2008q3.tar.gz

# Extract to current working directory:
tar xvf arm-2008q3.tar.gz

# Download the Kernel sources
wget ftp://ftp.embeddedTS.com/ts-socket-macrocontrollers/ts-4700-linux/sources/linux-2.6.29-4700_latest.tar.bz2

# Extract the Kernel Sources
tar xvf linux-2.6.29-4700_latest.tar.bz2

cd linux-2.6.29-4700_latest/

Configure the Sources

The kernel sources need a few variables to be exported.

# Set the CROSS_COMPILE variable to the absolute path to the toolchain.  This will be different for your system:
export CROSS_COMPILE=/opt/arm-2008q3/bin/arm-none-linux-gnueabi-

# Normally, ARCH will be set based on your build hosts architecture.
export ARCH=arm

This sets up the default configuration that we ship with for the TS-4700

make ts4700_defconfig

This will bring up a graphical menu where you can edit the configuration to include support for new devices. For Example, to include support for a Prolific USB to serial adapter you would go to 'Device Drivers -> USB Support-> USB Serial Support' and then select 'USB Prolific 2303 Single Port Serial Driver'. Since the kernel only has a limited space, build drivers as modules whenever possible.

make menuconfig

Build the kernel Once you have it configured, start building. This usually takes a few minutes.

make && make modules

The new kernel will be at "arch/arm/boot" in a compressed format called zImage. The uncompressed version is simply called Image. With the default partitioning scheme it is REQUIRED that the kernel be < 2096640 bytes in size. If you need to shorten the size, try including your changes to the kernel as modules instead. Otherwise you will need to resize the kernel partition to account for the size difference.

Install the kernel Now that you have a kernel you can install it as you would our stock. See the #Backup / Restore section for examples on writing this to disk.

Install Modules Script to make directory and install modules

./build-module-bundles.sh

The build-module-bundles.sh script is meant to be run as a user (not root) and will create directories and install modules to them. The directory structure is created at /home/`whoami`/src/ts-4700/dist/<ts4700 kernel release number>/modules-install/. In that directory is initrd-modules/, lib/, and modules-<ts4700 kernel release number>.tgz.

initrd-modules/modules.tar.gz is a tarball that contains a minimal number of modules. This tarball needs to be copied to the initrd partition of the boot media. The boot process of the board will automatically un'tar this and insert any necessary modules.

Now the contents of lib/ can be copied to the root of the TS-4700. It is also possible to copy over modules-<ts4700 kernel release number>.tgz to the TS-4700 and unpack it in the root linux directory. You may want to remove any old modules on the board in /lib/modules/* before copying them to the board to rule out any incompatibilities. Once you boot up to the board, you need to run 'depmod' once to calculate module dependencies. You can then run 'modprobe' with the device drivers you've added. For the Prolific adapter added in the example, this would be:

modprobe pl2303

tsctl

The tsctl library and network service is available to simplify communicating with many peripherals and standard TS devices such as DIO, CAN, SPI, I2C, PC104, and more. The API supports a C API, TCP binary interface, text protocol, and presents a JSON service to allow for flexible options to interface with hardware.

You can download the tsctl sources here. To build tsctl you should connect the TS-4700 to the network. Once connected, you can follow the next steps to build and install tsctl.

First you must install libreadline which is used for the tsctl shell:

apt-get update
apt-get install libreadline5-dev -y

Once the dependencies are installed you can build tsctl. You can also use these next steps to update tsctl.

wget ftp://ftp.embeddedarm.com/apps/tsctl/libtsctl-src-LATEST.tar.gz
tar -xf libtsctl-src-LATEST.tar.gz
cd libtsctl

# This next command will take approximately 2.5 minutes
make tsctl

cp noncavium/tsctl /usr/local/bin/
chmod a+x /usr/local/bin/tsctl

Once installed tsctl can be launched from the command line using "tsctl". If your application relies on the server, you can launch:

tsctl --server

This will cause tsctl to fork into the background and look for incoming tcp connections.

Features

CPU

The TS-4700 features an 800MHz Marvell PXA166 CPU. This is also known as the Armada 166, or 88AP166. The common features will be described in other sections, but for more details see the CPU user guide.

MicroSD Card Interface

The SD interface supports both MicroSD and MicroSDHC cards. There is a linux driver provided in the default TS-4700 kernel that allows you to access the SD card block device as /dev/mmcblk0, or /dev/mmcblk0p# for accessing a specific partition. By default the TS-4700 will use this layout:

Device	Contents
/dev/mmcblk0p1	Fat32 partition.
/dev/mmcblk0p2	Linux kernel.
/dev/mmcblk0p3	Initrd/Fastboot
/dev/mmcblk0p4	Debian Filesystem

The FAT32 partition isn't necessarily required, but unless Windows can recognize one of the partitions it will ask the user if they want to formt the disk. If you remove this partition you will need to modify the linuxrc scripts accordingly

XNAND

The XNAND is a custom block device abstraction which is designed to vastly increase the reliability of NAND access. This board includes a 512MB flash chip, but the XNAND algorithm will limit this to a usable 256MB from redundancy. The software layer to access the XNAND is implemented in userspace in conjunction with NBD (network block device). You may want to refer to the nandctl page which will show more advanced usage, but by default the linuxrc script will mount the sd card with the following layout:

 /dev/nbd0 - whole disk device of XNAND drive
 /dev/nbd1 - 1st partition (kernel partition)
 /dev/nbd2 - 2nd partition (EXT2 initrd)
 /dev/nbd3 - 3rd partition (~252MByte mini Debian EXT3 filesystem)
 /dev/nbd4 - 4th partition (unused)
 

Note:

NBD devices do not report size correctly. If you are formatting a partition or using dd you will need to specify the size.

Interrupts

We include a userspace IRQ patch in our kernels. This allows you to receive interrupts from your applications where you would normally have to write a kernel driver. This works by creating a file for each interrupt in '/proc/irq/<irqnum>/irq'. The new irq file allows you to block on a read on the file until an interrupt fires.

The original patch is documented here.

The Linux kernel supports up to 16 IRQs from the FPGA. When the CPU receives an IRQ from the FPGA, it uses the IRQ register in the #Syscon to find out which IRQ on the MUX is triggering. Currently only three IRQs are used. Off-board IRQs 5, 6, and 7 correspond to FPGA IRQs 0, 1, and 2, respectively. FPGA IRQs 3 to 15 are reserved for future uses. If the DIO pins are not being used as IRQs, they can be masked out by writing 0 to the corresponding bit in the IRQ mask register.

With the TS-8100 all of these pins are available on the PC104 header:

IRQ #	Name
67	IRQ5/DIO_00
68	IRQ6/DIO_01
69	IRQ7/DIO_02

This example below will work with any of our products that support userspace IRQs. It opens the IRQ number specified in the first argument, and prints when it detects an IRQ.

#include <stdio.h>
#include <fcntl.h>
#include <sys/select.h>
#include <sys/stat.h>
#include <unistd.h>

int main(int argc, char **argv)
{
	char proc_irq[32];
	int ret, irqfd = 0;
	int buf; // Holds irq junk data
	fd_set fds;

	if(argc < 2) {
		printf("Usage: %s <irq number>\n", argv[0]);
		return 1;
	}

	snprintf(proc_irq, sizeof(proc_irq), "/proc/irq/%d/irq", atoi(argv[1]));
	irqfd = open(proc_irq, O_RDONLY| O_NONBLOCK, S_IREAD);

	if(irqfd == -1) {
		printf("Could not open IRQ %s\n", argv[1]);
		return 1;
	}
	
	while(1) {
		FD_SET(irqfd, &fds); //add the fd to the set
		// See if the IRQ has any data available to read
		ret = select(irqfd + 1, &fds, NULL, NULL, NULL);
		
		if(FD_ISSET(irqfd, &fds))
		{
			FD_CLR(irqfd, &fds);  //Remove the filedes from set
			printf("IRQ detected\n");
			
			// Clear the junk data in the IRQ file
			read(irqfd, &buf, sizeof(buf));
		}
		
		//Sleep, or do any other processing here
		usleep(10000);
	}
	
	return 0;
}

LEDs

On all of our baseboards we include 2 indicator LEDs which are under software control. You can manipulate these using ts4700ctl --greenledon --redledon or ts4700ctl --greenledoff --redledoff. The LEDs have 4 behaviors from default software.

Green Behavior	Red behavior	Meaning
Solid On	Off	System is booted and running
Solid On	On for approximately 15s, then off	Once the system has booted the kernel and executed the startup script, it will check for a USB device and then determine if it is a mass storage device. This is used for updates/blasting through USB. Once it determines this is not a mass storage device the red LED will turn back off.
On for 10s, off for 100ms, and repeating	Turns on after Green turns off for 300ms, and then turns off for 10s	The watchdog is continuously resetting the board. This happens when the system cannot find a valid boot device, or the watchdog is otherwise not being fed. This is normally fed by ts4700ctl once a valid boot media has started. See the #Watchdog section for more details.
Off	Off	The FPGA is not able to start. Typically either the board is not being supplied with enough voltage, or the FPGA has been otherwise damaged. If a stable 5 V is being provided and the supply is capable of providing at least 1 A to the System-on-Module (SoM), an RMA is suggested.
Blinking about 5ms on, about 10ms off.	Blinking about 5ms on, about 10ms off.	The board is receiving too little power, or something is drawing too much current from the SoM's power rails.

Ethernet Port

The Marvell processor implements a 10/100 ethernet controller with support built into the Linux kernel. You can use standard Linux utilities such as ifconfig/ip to control this interface. See the #Configuring the Network section for more details. For the specifics of this interface see the CPU manual.

Note:

Ethernet Magnetics should be placed as close to CN2 as possible on the base board.

TS-4700 DIO

Note:

Most of the DIO brought out on the TS-8100 are accessed using the TS-8100's CPLD registers, or by accessing through #tsctl.

This board uses both CPU and a DIO controller in the FPGA. The CPU DIO typically has 1-7 functions associated with various pins (I2C, PWM, SPI, etc). See the CPU manual CPU manual for the complete listing and for information on how to control these DIO. For purposes of identity, all FPGA DIO will be labelled DIO_n (where n is the DIO pin number), and all CPU dio will be labelled MFP_n.
Bit masking: Any bits not expressly mentioned here should be masked out. Direction setting: 0 is input, 1 is output.

All FPGA DIO are controlled by three distinct register types: Direction, Input Data, and Output Data. To use any DIO pin, the direction register must be set (0 for input, 1 for output), then either the input register may be read, or the output register may be written to. These registers are described in the Syscon memory table.
For example, to write to DIO_0, bit 0 (the LSB) of 0x80004018 (The direction register for DIO_0 through DIO_14) must be set high, then the desired value (high = 1 low = 0) should be written to bit 0 of 0x80004010 (the Output Data register for DIO_0 through DIO_14). Alternatively to read the status of that pin, the Direction Register must be set low, then bit zero of 0x80004020 would reflect the status of that pin.

Full details on CPU pins can be found in the CPU manual, along with mode and mapping assignments specific to the CPU. As this comprises twelve pages of material that must be completely understood, it is best to read the CPU manual carefully before making use of these pins.
The pages of interest in the CPU manual regarding the MFP_n pins start at page A-5 and continue through page A-12 under section A.1. General information for DIO access is given here for convenience: CPU GPIO Register base: 0xD4019000 The offsets table for the CPU GPIO pins is on pages A-7 through A-9. The register description for each pin's register is located on pages A-9 through A-12.

All 60 of the DIO from the FPGA will default to the DIO mode. These pins coming from the FPGA are all 3.3V tolerant. To manipulate these DIO you can access the #Syscon. The initrd also has ts4700.subr which has functions for manipulating the DIO through shell functions:

# If you're in the initrd:
source /ts4700.subr

# If you're in Debian:
source /initrd/ts4700.subr

#Usage: setdiopin <pin> <1,0,Z> <b>
setdiopin 8 0

#Usage: getdiopin <pin>
getdiopin 9

DIO Number	Connector Location	Alternate Function
0	CN1_93	Offboard IRQ 67
1	CN1_91	Offboard IRQ 68
2	CN1_89	Offboard IRQ 69
3	CN1_87	12.5MHz clock
4	CN1_85	XUART5 CTS, edge counter 0 input
5	CN1_83	Board ID
6	CN1_81	Edge counter 1 input
7	CN1_79	XUART5 TX_EN, ADC_CLK
8	CN1_77	AN_SEL, XUART1 TX_EN
9	CN1_73	External Reset
10	CN1_71	CAN2_TXD, XUART2 TX_EN
11	CN1_69	CAN2_RXD
12	CN1_67	XUART0 TX_EN
13	CN1_65	XUART6 RXD, XUART3_TXEN
14	CN1_63	XUART4_TXEN
15	CN2_97	CAN1_TXD
16	CN2_99	CAN1_RXD
17	CN2_65	SPI_FRM
18	CN2_67	SPI_MOSI
19	CN2_69	SPI_MISO
20	CN2_71	SPI_CLK
21	N/A	N/A
22	CN1_97	BUS_WAIT#
23	CN1_99	BUS_BHE#
24	CN1_100	BUS_CS#
25	CN1_98	BUS_DIR, MODE2
26	CN1_96	BUS_ALE#
27	CN1_78	MUX_AD_08
28	CN1_76	MUX_AD_09
29	CN1_74	MUX_AD_10
30	CN1_72	MUX_AD_11
31	CN1_70	MUX_AD_12
32	CN1_68	MUX_AD_13
33	CN1_66	MUX_AD_14
34	CN1_64	MUX_AD_15
35	CN1_94	MUX_AD_00
36	CN1_92	MUX_AD_01
37	CN1_90	MUX_AD_02
38	CN1_88	MUX_AD_03
39	CN1_86	MUX_AD_04
40	CN1_84	MUX_AD_05
41	CN1_82	MUX_AD_06
42	CN1_80	MUX_AD_07
43	N/A	N/A
44	N/A	N/A
45	N/A	N/A
46	N/A	N/A
47	N/A	N/A
48	CN2_78	XUART0 TXD
49	CN2_80	XUART0 RXD
50	CN2_82	XUART1 TXD
51	CN2_84	XUART1 RXD
52	CN2_86	XUART2 TXD
53	CN2_88	XUART2 RXD
54	CN2_90	XUART3 TXD
55	CN2_92	XUART3 RXD
56	CN2_94	XUART4 TXD
57	CN2_96	XUART4 RXD
58	CN2_98	XUART5 TXD
59	CN2_100	XUART5 RXD

Baseboard ID

All of our off the shelf baseboards contain a hard wired 3-state 8-input multiplexers. This is not required to implement in custom baseboards, but it can be useful to identify the board in software. During startup of the System-on-Module, 4 DIO are used to obtain the baseboard model ID. The red LED (CN2_06) is state 0, green LED (CN2_08) is state 1, BUS_DIR (CN1_98) is state 2, and BD_ID_DATA (CN1_83) is used for data.

The first 6 lines are used as the six bits that define the baseboard. The last two lines (Y6 & Y7 in the schematic image below) define the bits to indicate the board revision.

You can find example code for accessing the baseboard ID in ts4700ctl. For example, "ts4700ctl -B" will return "baseboard_model=" with the detected baseboard.

For custom baseboards we have reserved the address 42 which will never be used by our standard products.

TS-8160 baseboard ID resulting in ID 6.

TS-Baseboard IDs

ID	Baseboard
0	TS-8200
1	Reserved, do not use
2	TS-TPC-8390
4	TS-8500
5	TS-8400
6	TS-8160
7	TS-8100
8	TS-8820-BOX
9	TS-8150
10	TS-TPC-8900
11	TS-8290
13	TS-8700
14	TS-8280
15	TS-8380
16	TS-AN20
17	TS-TPC-8920
19	TS-8550
20	TS-TPC-8950
22	TS-8551
42	Reserved for customer use, never used by us
63	TS-8200

USB

USB OTG

This board features USB OTG which allows you to use the USB port as either a host, or a device. Much of the USB OTG framework is described here. You will need to recompile your kernel to include these modules.

The OTG driver from Marvell has a caveat attached to it, whenever the OTG port is to be used as a host the following command needs to be issued after the device is plugged in:

echo 1 > /proc/driver/otg

Device mode of OTG will function without having to write to the above proc file.

Note:

When paired with the TS-8160 the OTG port is exposed as the lower USB host A port. Because of this the above command needs to be run whenever a USB device is attached to the port in order to tell the OTG driver to enter host mode and communicate with the USB device.

USB Host

The USB host port is a standard USB 2.0 at 480Mbps. The Linux kernel provides most of the USB support, and some devices may require a kernel recompile. Common devices such as keyboards, mice, wifi, and ethernet should mostly work out of the box.

The libusb project can also be used to communicate directly with USB peripherals from userspace.

TWI

These pins provide a standard two-wire interface. This bus also connects to an RTC and temperature sensor on the System-on-Module. MFP105 and MFP106 can be used as a second TWI bus directly from the CPU. For more information, see the CPU manual here.

SPI

The SPI controller is implemented in the FPGA. This core is found at 0x80004800, and should only be accessed using 16-bit reads/writes.

The table below is the register map for the SPI in the FPGA:

Offset	Access	Bit(s)	Description
0x0	Read Only	15	SPI MISO state
	Read/Write	14	SPI CLK state
	Read/Write	13:10	Speed - 0 (highest), 1 (1/2 speed), 2 (1/4 speed)...
	Read/Write	9:8	LUN (0-3 representing the 4 chip selects)
	Read/Write	7	CS (1 - CS# is asserted)
	N/A	6:1	Reserved
	Read/Write	0	Speed
0x2	Read Only	15:0	Previous SPI read data from last write
0x4	N/A	15:0	Reserved
0x6	N/A	15:0	Reserved
0x8	Read/Write	15:0	SPI read/write with CS# to stay asserted
0xa	Read Only	15:0	SPI pipelined read with CS# to stay asserted
0xc	Read/Write	15:0	SPI Read/Write with CS# to deassert post-op
0xe	N/A	15:0	Reserved

The SPI clk state register should be set when CS# is deasserted. Value 0 makes SPI rising edge (CPOL=0), 1 is falling edge (CPOL=1). This only applies to speed >= 1.

Where the base clock is 75Mhz (extended temp alters this to 50Mhz), speed settings break down as follows:

Value	Speed
0	75Mhz
1	37.5MHz
2	18.75MHz
3	12.5MHz
4	9.375MHz
5	7.5MHz
6	6.25MHz
7	5.36MHz
8	4.68MHz
9	4.17MHz
15	2.5MHz
19	1.97MHz
31	1.21MHz

The pipelined read register is for read bursts and will automatically start a subsequent SPI read upon completion of the requested SPI read. Reading from this register infers that another read will shortly follow and allows this SPI controller "a head start" on the next read for optimum read performance. This register should be accessed as long as there will be at least one more SPI read with CS# asserted to take place.

TS-4700 FPGA

All macrocontrollers feature an FPGA. Any external interfaces called for by the TS-SOCKET specification that are not provided by the CPU are implemented in the FPGA whenever possible. The FPGA is connected to the CPU by a static memory controller, and as a result the FPGA can provide registers in the CPU memory space.

While most common functionality is accessed through layers of software that are already written, some features may require talking directly to the FPGA. Access to the FPGA is done through either the 8-bit or 16-bit memory regions. Code should access 16-bit or 8-bit depending on the access designed for the specific hardware core. For example, the CAN core is 8 bit, the 8 bit MUXBUS space is 8 bit, and some 8 bit cycles are needed for the SPI core if you want to do 8 bit SPI transactions. To access hardware cores in the FPGA, add the offset in the table below to the base address.

Bit Width	Base Address
16	0x80000000
8	0x81000000

Offset	Usage	Bit Width
0x0000	16KB blockram access (for XUART buffer)	16
0x4000	Syscon registers	16
0x4400	ADC registers (for off-board ADC)	16
0x4800	SPI interface	16
0x4C00	CAN controller	8
0x4D00	2nd CAN controller	8
0x5000	Touchscreen registers	16
0x5400	XUART IO registers	16
0x8000	32KB MUXBUS space	16/8

TS-4700 FPGA Bitstreams

The FPGA has the capability to be reloaded on startup and reprogram itself with different configurations. The default bitstream is hardcoded into the FPGA, but the soft reloaded bitstreams can be placed in /ts4700_bitstream.vme.gz on the initrd root to make the board load the bitstream on startup. If we do not have a configuration you need, you can build a new bitstream, or contact us for our engineering services.

Bitstream	XUARTs	CAN	CAN2	Touchscreen	SPI
Default (5k LUT)	0-6	Off	Off	On	On
Default (8k LUT)	0-6	On	On	On	On

TS-4700 FPGA Programming

Note:

We do not provide support for the opencores under the free support, however we do offer custom FPGA programming services. If interested, please contact us.

The opencore FPGA sources are available here.

We have prepared the opencore projects which gives you the ability to reprogram the FPGA while either preserving or removing our functionality as you choose. The code sources are in verilog, and we use Lattice Diamond to generate the JEDEC file. You can download Lattice Diamond from their site. You can request a free license, and it will run in either Windows or Linux (only Redhat is supported). In the sources you can find the functionality switches in the ts4700_top.v file:

parameter xuart_opt = 1'b1;
parameter can_opt = 1'b1;
parameter can2_opt = 1'b0;
parameter touchscreen_opt = 1'b1;
parameter spi_opt = 1'b1;

You can use these switches to enable and disable functionality. We do not enable everything at the same time because of space constraints on the FPGA. So for example, lets say you wanted to change from 2 enabled XUARTs to 7 enabled XUARTS. Lattice Diamond will not place them if they are not used. In this core we automatically disable XUARTS depending on if you have CAN enabled. To change this, you would simple change the toggles:

parameter xuart_opt = 1'b1;
parameter can_opt = 1'b0;
parameter can2_opt = 1'b0;
parameter touchscreen_opt = 1'b1;
parameter spi_opt = 1'b1;

For more advanced changes you may look to opencores.org which has many examples of FPGA cores. To build the FPGA with your new changes, go to the 'Processes' tab and double-click 'JEDEC File'. This will build a jedec file in the project directory. On a linux system, either x86 compatible or ARM, we provide an application called jed2vme.

jed2vme for x86

jed2vme for ARM (oabi)

We also have the sources here.

WARNING:

Do not use the 'jed2vme' provided by Lattice. Their version writes to flash and as the opencores do not contain the bootrom this will brick your board.

jed2vme can be used like this:

jed2vme bitstream.jed | gzip > bitstream.vme.gz

To load this bitstream in your FPGA you will need to copy it to the initrd and name it '/ts4700_bitstream.vme.gz'. During the beginning of the linuxrc script it will start the reload with the command below. This must be done before the userspace ctl applications start or they may try to make use of the FPGA while it is being programmed, or the FPGA programming may just fail.

ts4700ctl --loadfpga=ts4700_bitstream.vme.gz

The FPGA contains flash memory which contains Technologic System's default FPGA SRAM load. The "ts4700ctl --loadfpga" will not overwrite the flash memory of the FPGA and will only load the SRAM contents of the FPGA, making for an unbrickable system if something should go wrong. If something does go wrong, you can restore the onboard flash via the offboard flash or microSD card.

Syscon

The registers listed below are all 16 bit registers and must be accessed with 16 bit reads and writes. This register block appears at base address 0x80004000. For example, to identify the TS-4700:

peekpoke 16 0x80004000

This will return 0x4700 to read back the model ID.

Many of the syscon options can be manipulated using ts4700ctl.

 Usage: ts4700ctl [OPTION] ...
 Technologic Systems TS-4700 FPGA manipulation.
 
 General options:
   -g, --getmac            Display ethernet MAC address
   -s, --setmac=MAC        Set ethernet MAC address
   -R, --reboot            Reboot the board
   -i, --info              Display board FPGA info
   -B, --baseboard         Display baseboard ID
   -a, --adc               Display MCP3428 ADC readings in millivolts
   -e, --greenledon        Turn green LED on
   -b, --greenledoff       Turn green LED off
   -c, --redledon          Turn red LED on
   -d, --redledoff         Turn red LED off
   -D, --setdio=LVAL       Set DIO output to LVAL
   -O, --setdiodir=LVAL    Set DIO direction to LVAL (1 - output)
   -G, --getdio            Get DIO input
   -Z, --getdioreg         Get DIO direction and output register values
   -x, --random            Get 16-bit hardware random number
   -W, --watchdog          Daemonize and set up /dev/watchdog
   -A, --autofeed=SETTING  Daemonize and auto feed watchdog
   -n, --setrng            Seed the kernel random number generator
   -X, --resetswitchon     Enable reset switch
   -Y, --resetswitchoff    Disable reset switch
   -l, --loadfpga=FILE     Load FPGA bitstream from FILE
   -k  --clocks            Display the CPU/DRAM clock speeds from FPGA tagmem
   -q  --cputemp           Display the CPU die temperature
   -h, --help              This help

Offset	Bits	Usage
0x00	15:0	Model ID: Reads 0x4700
0x02	15	Reset switch enable (Use DIO 9 input)
	14	Enable touchscreen (override DIO 30-35)
	13	Enable UART4 TXEN (override DIO 14)
	12	Enable UART0 TXEN (override DIO 12)
	11	Enable 12.5MHz base board clock (override DIO 3)
	10	Enable SPI (override DIO 17-20)
	9	Enable 2nd CAN (override DIO 10,11)
	8	Enable CAN (override DIO 15,16)
	7:6	Scratch Register
	5	Mode2
	4	Mode1
	3:0	FPGA revision
0x04	15:0	Muxbus configuration register
0x06	15:0	Watchdog feed register
0x08	15:0	Free running 1MHz counter LSB
0x0a	15:0	Free running 1MHz counter MSB
0x0c	15:0	Hardware RNG LSB
0x0e	15:0	Hardware RNG MSB
0x10	15	Reserved
	14:0	DIO 14:0 output data
0x12	15:13	Reserved
	12	Red LED (1 = on)
	11	Green LED (1 = on)
	10:6	DIO 26:22 output data
	5:0	DIO 20:15 output data
0x14	15:0	DIO 42:27 output data
0x16	15	Enable UART2 TXEN (override DIO 10)
	14	Enable UART1 TXEN (override DIO 8)
	13	Enable UART5 TXEN (override DIO 7)
	12	Enable UART3 TXEN (override DIO 13)
	11:0	DIO 59:48 output data
0x18	15	Reserved
	14:0	DIO DIO 14:0 data direction
0x1a	15:11	Reserved
	10:6	DIO DIO 26:22 data direction
	5:0	DIO DIO 20:15 data direction
0x1c	15:0	DIO DIO 42:27 data direction
0x1e	15:12	Reserved
	11:0	DIO DIO 59:48 data direction
0x20	15	Reserved
	14:0	DIO DIO 14:0 input data
0x22	15:11	Reserved
	10:6	DIO DIO 26:22 input data
	5:0	DIO DIO 20:15 input data
0x24	15:0	DIO DIO 42:27 input data
0x26	15:12	Reserved
	11:0	DIO DIO 59:48 input data
0x28	15:4	Reserved
	3:0	FPGA TAG memory access
0x2a	15:0	Custom load ID register
0x2c	15:6	Reserved
	5	Offboard IRQ 7
	4	Offboard IRQ 6
	3	Offboard IRQ 5
	2	CAN2 IRQ
	1	CAN IRQ
	0	XUART IRQ
0x2e	15:6	Reserved
	5	Offboard IRQ 7 mask (1 disabled, 0 on)
	4	Offboard IRQ 6 mask (1 disabled, 0 on)
	3	Offboard IRQ 5 mask (1 disabled, 0 on)
	2	CAN2 IRQ mask (1 disabled, 0 on)
	1	CAN IRQ mask (1 disabled, 0 on)
	0	XUART IRQ mask (1 disabled, 0 on)
0x34	0	Enable 14.3MHz baseboard clock on DIO 3
	1	USB 5V disable
	2	LCD 3.3V disable

ADC Core

The FPGA includes a core for communicating with the MCP3428 ADC controller we use on several of our baseboards. If you are using this on your own baseboard this core assumes the standard circuit which allows 2 differential channels and 4 single-ended channels. The single-ended channels are chosen using analog muxes controlled by the AN_SEL line. Since different baseboards use a different pin for AN_SEL, a register is also provided to select the correct lines. Channels 1 and 2 are differential channels with a range of -2.048V to +2.048V. Channels 3-6 are 0 to 10.24V.

This example prints out all 6 ADC readings in millivolts:

#include <stdio.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <assert.h>
#include <fcntl.h>

#define peek16(adr) PEEK16((unsigned long)&syscon[(adr)/2])
#define poke16(adr, val) POKE16((unsigned long)&syscon[(adr)/2],(val))

static volatile unsigned short *syscon;

static inline unsigned short PEEK16(unsigned long addr) {
        unsigned short ret;

        asm volatile (
                "ldrh %0, [ %1 ]\n"
                : "=r" (ret)
                : "r" (addr)
                : "memory"
        );
        return ret;
}

static inline void POKE16(unsigned long addr, unsigned short dat) {
        asm volatile (
                "strh %1, [ %0 ]\n"
                :
                : "r" (addr), "r" (dat)
                : "memory"
        );
}

int main()
{
	int x, i, devmem;

	// Map the Syscon core
	devmem = open("/dev/mem", O_RDWR|O_SYNC);
        assert(devmem != -1);
        syscon = (unsigned short *) mmap(0, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, devmem, 0x80004000);

	//// Select AN_SEL line:
	//// If you have a TS-TPC-8390 baseboard:
	poke16(0x400, 0x28);
	//// TS-8160/TS-8100
	//poke16(0x400, 0x18);
	//// if unknown baseboard, uses no an_sel
        //// but assumes ADC is there
	//poke16(0x400, 0x08);

	// enable all 6 channels
	poke16(0x402, 0x3f);
	// allow time for conversions
	usleep(500000);

	for (i = 1; i <= 6; i++) {
		x = (signed short)peek16(0x402 + 2*i);
                if (i > 2) x = (x * 1006)/200;
                x = (x * 2048)/0x8000;
                printf("adc%d=%d\n", i, x);
	}

	return 0;
}

Running this code on a TS-TPC-8390 with pin 7 of the ADC header (channel 3) connected to 3.3V returns:

 root@ts4700:~# ./adctest 
 adc1=0
 adc2=0
 adc3=3302
 adc4=0
 adc5=0
 adc6=0

ADC Core Register Map

Offset	Bits	Description
0x0	15:8	Core ID register (reads 0xad)
	7:6	Reserved
	5:4	Analog Select Pin Value Description 0 Do not use an AN+SEL 1 use CN1 pin 77 for AN_SEL (TS-8100) 2 use CN1 pin 74 for AN_SEL (TS-8390) 3 Reserved
	3:2	Speed Value Description 0 240Hz, 12 bit resolution 1 60Hz, 14 bit resolution 2 15Hz, 16 bit resolution 3 Reserved
	1:0	Programmable Gain Amplifier Value Description 0 No gain 1 2x gain 2 4x gain 3 8x gain
0x2	15:0	Channel Mask
0x4	15:0	Channel 1 most recent conversion value
0x6	15:0	Channel 2 most recent conversion value
0x8	15:0	Channel 3 most recent conversion value
0xa	15:0	Channel 4 most recent conversion value
0xc	15:0	Channel 5 most recent conversion value
0xe	15:0	Channel 6 most recent conversion value

The channel mask register controls which channels are enabled. Bits 0-5 enable channels 1-6 respectively. If a given channel is not enabled, (enable bit == 0) it will not be sampled and its conversion value register will contain an obsolete and meaningless value. The more channels that are enabled, the lower the sampling speed on each channel.

Watchdog

The watchdog is manipulated via the ts4700ctl utility by default. The linuxrc script starts an autofeed thread for the watchdog timer which daemonizes and automatically feeds the WDT in the background. By default, the autofeed thread is started with a value of 1 (timeout of ~2.7 s) and will feed the WDT around every 1 second interval. This is suitable for most applications. However, if it is desired to integrate the WDT more tightly in to an application thread, it is possible to manually feed the WDT. Note that the linuxrc script which is used must be modified to not start up the autofeed thread. Instead, it should feed the WDT timer directly or start up any other processes that will be responsible for feeding the WDT.

The WDT in the FPGA syscon can be fed by writing one of four values to the 16-bit register. The values have the following effects:

Value	Result
0	Feed watchdog for .338s
1	Feed watchdog for 2.706s
2	Feed watchdog for 10.824s
3	Disarm/disable the watchdog

Watchdog by default comes out of reset armed for .338 seconds. TS-BOOTROM firmware feeds for 10.824 and OS code has 10.824 seconds to take over.

You can feed the watchdog from your application by poking a register:

#include <stdio.h>
#include <stdint.h>
#include <fcntl.h>
#include <sys/mman.h>

int main()
{
        int mem;
        volatile uint16_t *syscon;

        mem = open("/dev/mem", O_RDWR|O_SYNC);
        syscon = mmap(0,
                      getpagesize(),
                      PROT_READ|PROT_WRITE,
                      MAP_SHARED,
                      mem,
                      0x80004000);

        for(;;) {
                // This feeds the watchdog for 10s.
                syscon[0x6/2] = 2;
                sleep(5);
        }

        return 0;
}

MUXBUS

All TS-SOCKET System-on-Modules have an external bus called the MUXBUS. The bus consists of 16 muxed address/data lines, ALE#, CS#, DIR, BHE#, and WAIT#. The MUXBUS provides a way for TS-SOCKET base board designers to include static memory devices, bridges to other industry standard buses such as PC/104, or an FPGA that implements custom features. Verilog modules ts8100.v and muxbusbridge.v are provided as examples of how to interface with the MUXBUS.

MUXBUS slaves can be 8 bit or 16 bit devices. Each SoM has an 8 bit MUXBUS address space which must be accessed with 8 bit reads and writes, and a 16 bit MUXBUS address space which must be accessed with 16 bit reads and writes. Software that works with the MUXBUS must know whether it is talking to an 8 bit or 16 bit slave device and act accordingly.

The bus cycle speed depends on the FPGA clock speed, which varies from one SoM to another. Thus, the MUXBUS behavior is specified in clock cycles. The bus cycle works as follows:

• ALE# is asserted, and the address is driven on the bus lines. This condition is held for TP_ALE + 1 clock cycles.
• ALE# is de-asserted while the address remains valid for TH_ADR + 1 clock cycles.
• Data is driven on the bus lines (for a write) or the bus lines go high-Z (for a read) for TSU_DAT + 1 clock cycles.
• CS# is asserted for TP_CS + 1 clock cycles.
• CS# is de-asserted and data remains valid for TH_DAT + 1 clock cycles.

BHE# and DIR remain valid throughout the whole bus cycle. WAIT# is an input. The external device can assert the WAIT signal during the CS# pulse to extend it. The bus can work in 8 bit or 16 bit modes. In 8 bit mode, mux lines 8-15 are not used for data and BHE# is ignored. In 16 bit mode, byte reads and writes are still supported using BHE# and A0.

Each module will have a 16 bit external bus configuration register in its #Syscon.

Bus Config Register Bits	Usage
bit 0	Bus enable (otherwise, pins are GPIO or reserved)
bits 2:1	TP_ALE
bits 4:3	TH_ADR
bits 6:5	TSU_DAT
bits 12:7	TP_CS
bits 15:13	TH_DAT

IMPLEMENTATION TIMING NOTES:

On a MUXBUS write, all timing values are controlled by the bus config register. The slave device is permitted to latch data on either the leading edge or the trailing edge of the CS# pulse, or any time in between.

One a MUXBUS read, the MUXBUS latches data on the trailing edge of the CS# pulse. The slave device should begin driving the data bus in response to CS# assertion. Users should program TP_CS so that TSU_RD is at least 10ns plus any delays between the two boards. A conservative TP_CS setting is recommended, because an extra clock cycle here will not have a significant effect on net MUXBUS bandwidth.

The slave device must stop driving the data bus in response to CS# de-assertion. TH_RD must be at most 30ns.

XUARTS

The default FPGA load comes with 7 available XUARTs. When you load CAN in the FPGA this will be reduced to 2.

The XUARTs can be managed with xuartctl. See the xuartctl page for more details.

CAN

On the TS-8100 CAN is avaialble on:

Signal	Location
CAN1_H	DB9 pin 4 and COM1 header pin 4
CAN1_L	DB9 pin 9 and COM1 header pin 9
CAN2_H	COM3 header pin 4
CAN2_L	COM3 header pin 9

See the tsctl page for documentation on communication with the CAN bus.

TS-8100 Register Map

All of these registers are intended for 16 bit access. You can find this range at 0x80008000. You must first set the MUXBUS configuration register before accessing this range. For example, to read the board ID:

peekpoke 16 0x80004004 0x181 # Set MUXBUS configuration
peekpoke 16 0x80008000 # Read Board ID register (0x0)

Offset	Bits	Access	Description
0x0	15:0	Read Only	Board ID (0x8100)
0x2	3:0	Read Only	PLD revision
	7:4	Read/Write	Value to control PWM for LCD contrast
	8	Read/Write	TS-8100 USB Reset
	9	Read/Write	Controls ISA_RESET on the PC104 bus
	10	Read/Write	Enables a 14.3MHZ clock on the PC104 bus (B30) and the PLD (default 1)
	11	Read/Write	Enables the RS232 transceiver (default 1)
	12	Read/Write	Toggles 5V to the LCD header pin 1 (LCD_5V)
	13	Read/Write	Enable CAN1 standby
	14	Read/Write	Enable CAN2 standby
	15	Read/Write	Enables the PWM output for the contrast value
0x4	7:0	Read/Write	DIO output data (header odd pins, bit 0 is pin 1)
	13:8	Read/Write	PC104 header A21:A16 output data
	15:14	Read/Write	PC104 header B12:B11 output data
0x6	7:0	Read/Write	LCD pins 14:7 output data
	8	Read/Write	LCD Header pin 6 output data
	9	Read/Write	LCD Header pin 3 output data
	10	Read/Write	LCD Header pin 5 output data
	11	Read/Write	AVR MOSI
	12	Read/Write	AVR SCLK
	13	Read/Write	AVR RESET
	14:15	N/A	Reserved
0x8	7:0	Read/Write	DIO Header odd pins 15:1 data direction
	13:8	Read/Write	PC104 A21:A16 data direction
	15:14	Read/Write	PC104 B12:B11 data direction
0xa	7:0	Read/Write	LCD pins 14:7 data direction
	8	Read/Write	LCD Header pin 6 data direction
	9	Read/Write	LCD Header pin 3 data direction
	10	Read/Write	LCD Header pin 5 data direction
	15:11	N/A	Reserved
0xc	7:0	Read Only	DIO Header dd pins 15:1 input data
	13:8	Read Only	PC104 A21:A16 input data
	15:14	Read Only	PC104 B12:B11 input data
0xe	7:0	Read Only	LCD header pins 14-7 input data
	8	Read Only	LCD Write/Read (pin 6) input data
	9	Read Only	LCD Register Select (pin 3) input data
	10	Read Only	LCD Enable (pin 5) input data
	11	Read/Write	AVR MISO
	15:12	N/A	Reserved

TS-8100 DIO

The TS-8100 has up to 21 DIO available:

Signal	Location
8100_DIO_1	DIO header pin 1
8100_DIO_3	DIO header pin 3
8100_DIO_5	DIO header pin 5
8100_DIO_7	DIO header pin 7
8100_DIO_9	DIO header pin 9
8100_DIO_11	DIO header pin 11
8100_DIO_13	DIO header pin 13
8100_DIO_15	DIO header pin 15
8100_DIO_15	DIO header pin 15
8100_DIO_A16	PC104 header pin A16
8100_DIO_A17	PC104 header pin A17
8100_DIO_A18	PC104 header pin A18
8100_DIO_A19	PC104 header pin A19
8100_DIO_A20	PC104 header pin A20
8100_DIO_A21	PC104 header pin A21
8100_DIO_B11	PC104 header pin B11
8100_DIO_B12	PC104 header pin B12
8100_LCD_3	LCD header pin 3
8100_LCD_5	LCD header pin 5
8100_LCD_6	LCD header pin 6
8100_LCD_D1	LCD header pin 7
8100_LCD_D0	LCD header pin 8
8100_LCD_D3	LCD header pin 9
8100_LCD_D2	LCD header pin 10
8100_LCD_D5	LCD header pin 11
8100_LCD_D4	LCD header pin 12
8100_LCD_D7	LCD header pin 13
8100_LCD_D6	LCD header pin 14

Connectors

USB Port

The USB is available on two ports as a USB 2.0 host.

Header PIN Name 1 USB_5V 2 USB - 3 USB + 4 GND

DIO header

The TS-8100 includes a 2x8 0.1" pitch header with 8 DIO, I2C, and SPI. Most DIO on this header are rated for 3.3V and are not tolerant of 5V IO. The only exception is SPI_MOSI which is 5V tolerant. The DIO on this baseboard can be accessed by manipulating the TS-8100 Register Map, or using tsctl.

Pinout	Header
Pin Name Notes 1 8100_DIO_1 Pulled high by R124 2 Ground 3 8100_DIO_3 Pulled high by R123 4 I2C_CLK 5 8100_DIO_5 Pulled high by R122 6 SPI_CS 7 8100_DIO_7 pulled high by R121 8 I2C_DAT 9 8100_DIO_9 Pulled high by R120 10 SPI_MISO 11 8100_DIO_11 Pulled high by R119 12 SPI_MOSI 13 8100_DIO_13 Pulled high by R118 14 SPI_CLK 15 8100_DIO_15 Pulled high by R117 16 CPU_3.3V

LCD Header

The LCD header is designed around compatibility with our low cost LCD-LED: Alphanumeric 2x24 LCD. These I/O are manipulated through tsctl, or through manipulation of the TS-81xx registers directly. Connector CN8 is a 14 pin (2x7) 0.1" spacing header.

Pinout	Header
Pin Name Notes 1 LCD_5V Provides up to 1400mA 2 Ground 3 LCD_RS 4 LCD_BIAS 5 LCD_EN 6 LCD_WR# 7 LCD_D1 8 LCD_D0 9 LCD_D3 10 LCD_D2 11 LCD_D5 12 LCD_D4 13 LCD_D7 14 LCD_D6	14 13 12 11 10 9 8 7 6 5 4 3 2 1

WARNING:

LCD_D0 thru LCD_D7 are 5V tolerant. LCD_WR#, LCD_RS, and LCD_EN are not.

Power to the LCD header can be toggled by manipulating LCD Enable in the #Register Map. The LCD_5V pin can provide up to 1400mA, but this is a shared 5V rail and will depend on your power supply and what other devices are using that rail.

ADC Header

The Analog to Digital Converter consists of a 4-channel 16 bit sigma-delta converter and two, 2-channel analog switches. These are configured to allow input and conversion on two differential channels and 4 single ended channels. The 6-channel Analog to Digital signals are contained on connector HD5 which is a 16 pin (2x8) 0.1" spacing header. The connector layout and the signals carried by each pin are defined below. The input range for the differential input channels is 0- 2 VDC, and the input range on the single-ended channel is nominally 0-10 VDC.

Pinout	Header
Pin Type Signal 1 Single ended Channel 6 2 N/A GND 3 Single ended Channel 5 4 N/A GND 5 Single ended Channel 4 6 N/A GND 7 Single ended Channel 3 8 N/A GND 9 N/A Not connected 10 N/A GND 11 Differential Channel 2- 12 Differential Channel 2+ 13 N/A GND 14 Differential Channel 1- 15 Differential Channel 1+ 16 N/A GND	16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

Sleep mode

The TS-8160 features a AVR that has the ability to cut power to the System-on-Module (SoM) for a specified amount of time. You can also use the jumper labelled 'WAKE', or the press the button on SW1 to restore power to the SoM.

The ts8160ctl is available here.

Sleeping the board is essentially a shutdown. It is recommended that you have all of your filesystems in a read only state before running this command to avoid disk corruption. This example will simply shut down the SoM for 20 seconds.

ts8160ctl --sleep 20

Power consumption during sleep mode is approximately 100uA.

Note:

Sleep times will be rounded up to the granularity of sleep, which is 8 seconds for sleeps under ~3 days and 2048 seconds for longer sleeps. Actual sleep time will be +/- 10% the requested time due to low-power oscillator variation.

COM ports

Port	Type	RX (or 485 +)	TX (or 485 -)	Notes
ttyS0	RS232	DB9 pin 2, COM1 header pin 2	DB9 pin 3, COM1 header pin 3	Only with console enable jumper on
XUART0	RS485	DB9 pin 1, COM1 header pin 1	DB9 pin 6, COM1 header pin 6
XUART1	RS232	DB9 pin 2, COM1 header pin 2	DB9 pin 3, COM1 header pin 3	Only with console enable jumper off
XUART2	RS232	DB9 pin 8, COM1 header pin 8	DB9 pin 7, COM1 header pin 7
XUART3	RS232	COM2 header pin 2	COM2 header pin 3
XUART4	RS485	COM2 header pin 1	COM2 header pin 6
XUART5	RS232	COM3 header pin 2	COM3 header pin 3	CTS available on pin 8

The COM headers follow a legacy pin configuration different from other pin header numberings. The COM headers are numbered thus:

1	6
2	7
3	8
4	9
5	10

Pin 1 corresponds to the pin next to the "dot" on the silk screen.

PC104 Header

See the #MUXBUS section for more details on working with the MUXBUS peripherals.

The PC/104 connector consists of two rows of pins labeled A and B, the numbering of of which is shown below. The signals for the PC/104 are generated by the MAX240 PLD located on the baseboard. It converts the MUXBUS signals from the dual 100-pin System-on-Module (SoM) interface bus. Pin A1 is nearest to the SoM mounting hole.

Any of the IO on this board labelled DIO_ can be controlled through tsctl as PC104_A/B<pin>, or through manipulation of the registers directly.

# Start tsctl server if it is not already running.
# This only needs to be done once
tsctl --server &

# Lookup the logical DIO mapping of the PC104 header pin A16
eval `tsctl 127.0.0.1 System MapLookup PC104_A16`
# If you run this outside of the eval it will return:
# PC104_A16=138

# Toggle the DIO high and low:
tsctl 127.0.0.1 DIO Set $PC104_A16 high
tsctl 127.0.0.1 DIO Set $PC104_A16 low

You can also drive these DIO to manually manipulate the PC/104 address to make peripherals usable that require a higher range of address than provided by the default address space of the MUXBUS.

Pin Name Pin Name A1 BUS_BHE# B1 Ground A2 AD_07 B2 ISA_RESET A3 AD_06 B3 5V A4 AD_05 B4 AD_08 A5 AD_04 B5 CPU_3.3V A6 AD_03 B6 Not connected A7 AD_02 B7 Not connected A8 AD_01 B8 Not connected A9 AD_D0 B9 VIN A10 ISA_WAIT# B10 Ground A11 Ground B11 DIO_B11 A12 Not connected B12 DIO_B12 A13 Not connected B13 ISA_LOW# A14 Not connected B14 ISA_IOR# A15 Not connected B15 Not connected A16 DIO_A16 B16 Not connected A17 DIO_A17 B17 AD_09 A18 DIO_A18 B18 AD_10 A19 DIO_A19 B19 Not connected A20 DIO_A20 B20 AD_12 A21 DIO_A21 B21 ISA_IRQ7 A22 ISA_ADD9 B22 ISA_IRQ6 A23 ISA_ADD8 B23 ISA_IRQ5 A24 ISA_ADD7 B24 Ground A25 ISA_ADD6 B25 AD_11 A26 ISA_ADD5 B26 AD_13 A27 ISA_ADD4 B27 AD_14 A28 ISA_ADD3 B28 AD_15 A29 ISA_ADD2 B29 5V A30 ISA_ADD1 B30 ISA 14.3 MHZ A31 ISA_ADD0 B31 Ground A32 Ground B32 Ground

WARNING:

Most of the pins on the PC/104 bus are only 3.3 V tolerant. Refer to the schematic for more details.

Further Resources

For further support you can go to our Developer Forums here. You can also contact us for more information.

We recommend reading our white papers if they are relevant to your project:

• Preventing Filesystem Corruption in Linux
• XNAND
• Meeting Real-Time Requirements with Technologic Systems Computers

For learning more about Debian:

• The Debian Handbook (online or book)
• Learning Debian GNU/Linux (book)
• Debian Administration (online)

For Linux programming in general:

• The Linux Documentation Project (online)
• The Linux Programming Interface (book)
• Linux System Programming (book)
• Linux in a Nutshell (book)

Product Notes

Errata

Synopsis	Boot-time information script causes watchdog reset.
Affected	TS-4700 FPGA Version 3 and older attempting to load the current bootable SD image.
Status	Workarounds available

Description:

The default SD image available on the Technologic Systems FTP site includes a boot-time information program that causes watchdog reset during query of FPGA for CAN capability status.

Workaround:

Remove the line eval `ts4700ctl --info` from the file 'linuxrc' before attempting to boot from the latest software image. The linuxrc file can be found at the root of partition 3 in the SD image.

Synopsis	Rev 2 of the AVR software does not correctly use the WAKE button/pins
Severity	Minor
Class	Software bug
Affected	TS-8160 AVR Rev 2
Status	Workarounds available, fixed in Rev 3, shipping on June 12th 2012

Description:

Revision 2 of the AVR software did not correctly enable the interrupt for the IO port that the WAKE button/pins are on. Because of this sleep could not be interrupted without cutting power to the TS-8160. The only way to fix this is by updating to Rev 3. There are two ways to do this, see below for more information.

Workaround: The TS-8160 AVR software revision can be checked with:

ts8160ctl --info

If the Revision field shows "2" then this device cannot wake up from a sleep. The fix is as follows:

1) The System-on-Module (SoM) NEEDS to be a TS-4200. Currently none of our other SoMs can reprogram the AVR. If this is the case, an RMA can be submitted and we will reflash the AVR here. Submit an RMA request here.

2) Download this tarball, unzip it in the fastboot shell on the TS-4200 while booted with the TS-8160. Follow the instructions contained in the README file. Once this is completed, reboot, and the new AVR software will be running.

Due to space limitations, it is best to download and unpack in the /tmp folder of the fastboot shell

FCC Advisory

This equipment generates, uses, and can radiate radio frequency energy and if not installed and used properly (that is, in strict accordance with the manufacturer's instructions), may cause interference to radio and television reception. It has been type tested and found to comply with the limits for a Class A digital device in accordance with the specifications in Part 15 of FCC Rules, which are designed to provide reasonable protection against such interference when operated in a commercial environment. Operation of this equipment in a residential area is likely to cause interference, in which case the owner will be required to correct the interference at his own expense.

If this equipment does cause interference, which can be determined by turning the unit on and off, the user is encouraged to try the following measures to correct the interference:

Reorient the receiving antenna. Relocate the unit with respect to the receiver. Plug the unit into a different outlet so that the unit and receiver are on different branch circuits. Ensure that mounting screws and connector attachment screws are tightly secured. Ensure that good quality, shielded, and grounded cables are used for all data communications. If necessary, the user should consult the dealer or an experienced radio/television technician for additional suggestions. The following booklets prepared by the Federal Communications Commission (FCC) may also prove helpful:

How to Identify and Resolve Radio-TV Interference Problems (Stock No. 004-000-000345-4) Interface Handbook (Stock No. 004-000-004505-7) These booklets may be purchased from the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402.

Limited Warranty

See our Terms and Conditions for more details.