TS-4200

From embeddedTS Manuals
Revision as of 10:11, 21 February 2012 by Mark (talk | contribs) (→‎Boot Process)
TS-4200
TS-4200.jpg
Released Mar. 2011
Product Page
Documentation
Schematic
Mechanical Drawing
FTP Path
CPU Datasheet
CPU Manual
CPU Technical Reference Manual

Overview

The TS-4200 is a high performance low power 400MHz Atmel AT91SAM9G20 ARM9 with 128MB RAM.

Getting Started

A Linux PC is recommended for development. For developers who use Windows, virtualized Linux using VMWare or similar are recommended in order to make the full power of Linux available. The developer will need to be comfortable with Linux anyway in order to work with embedded Linux on the target platform. The main reasons that Linux is useful are:

  • Linux filesystems on the microSD card can be accessed on the PC.
  • More ARM cross-compilers are available.
  • If recovery is needed, a bootable medium can be written.
  • A network filesystem can be served.
  • Builds such as Linux kernel, buildroot, yocto, distro-seed will not work from WSL1/2 on a case insensitive filesystem.
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-4700 receives power through several pins on the socket connector. Refer to your baseboard documentation or schematics for locating the power in on your board.

Get a Console

Console on the TS-4200 will by default come out of the CPU UART (ttyS0). The console will use 8n1, no flow control, and a 115200 baud rate. You can also telnet to the board with the default network configuration, though this will omit the TS-BOOTROM messages which can be helpful for diagnostics.

Use a null modem cable to connect the ARM system to your workstation. If you do not have a COM port on your system (as many newer systems do not), you can find a USB serial adapter that will bring out RS232.

Console from Linux

There are many serial clients for Linux, but 3 simple ones would be picocom, screen, and minicom. These examples assume that your COM device is /dev/ttyUSB0 (common for USB adapters), but replace them with the COM device on your workstation.

Linux has a few applications capable of connecting to the board over serial. You can use any of these clients that may be installed or available in your workstation's package manager:

Picocom is a very small and simple client. 

picocom -b 115200 /dev/ttyUSB0

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

screen /dev/ttyUSB0 115200

Or a very commonly used client is minicom which is quite powerful: 

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.

Device Manager Putty Configuration

Initrd / Busybox / Fastboot

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

 >> TS-BOOTROM - built Mar  9 2011 09:59:23
 >> Copyright (c) 2011, Technologic Systems
 >> Booting from SD card...
 .
 .
 .
 Uncompressing Linux... done, booting the kernel.
 >> Booted from: SD card                 Booted in: 1.40 seconds
 >> SBC Model number: TS-4200            SBC Sub-model number: 0
 >> CPU clock rate: 396 MHz              RAM size: 128MB
 >> NAND Flash size: 256MB               NAND Flash Type: 0xdc20 (STMicro)
 >> MAC number: 00:D0:69:44:3E:9B        SBC FPGA Version: 4
 >> Temperature Sensor: 31.500 degC      MODE1 bootstrap: OFF
 >> RTC present: YES                     Date and Time: Jan  1 2001 00:01:49
 >> Base board type: TS-8200/Unknown     Base board FPGA Version: not present
 >> MODE2 bootstrap: ON                  SD card size: 1886MB
 >> Offboard SPI flash type: not present Offboard SPI flash size: not present
 >> XUARTs detected: 0                   CAN present: NO
 >> Linux kernel version: 2.6.36.2       Linux kernel date: Oct 7 2011
 >> Bootrom date: unknown                INITRD date: Oct  7 2011
 >> ts4200ctl date: Sep 27 2011          sdctl date: not present
 >> canctl date: not present             nandctl date: Sep 26 2011
 >> spiflashctl date: not present        xuartctl date: not present
 >> dioctl date: not present             spictl date: not present
 >> dmxctl date: not present             busybox date: Sep 26 2011 (v1.18.3)
 >> ts4200.subr date: Sep 29 2011        daqctl date: not present
 >> linuxrc date: Sep 27 2011            rootfs date: Oct  7 2011
 >> MBR date: Sept 20 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, 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. 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 the SD you would run this: 

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

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.

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

 BusyBox v1.18.3 (2011-09-22 17:52:49 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


Also on the initrd are the TS specific applications: nandctl and ts4200ctl. We also provide the ts4200.subr which provides the following functions: 

 eth_off()
 eth_on()
 attime()
 usb_off()
 usb_on()
 usbload()
 sdload()
 nandsave()
 sdsave()
 save()
 sd2nand()
 nand2sd()
 setdiopin()
 getdiopin()
 getadc()
 pc104on()
 pc104off()
 setupclk()
 tshelp()

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 ts4200.subr file with the usbload() function.

Boot Process

Boot Process

The TS-BOOTROM consists of two parts, the code in the FPGA which does low level initialization of the CPU and MMU. It reads the first 512 bytes of the SD card or XNAND depending on your boot jumpers or MODE pins, and jumps execution to the binary there. The code in the MBR looks at the partition table for the first partition of type 0xda, and loads this to memory 0x20008000. The second partition of type 0xda is loaded into memory at 0x21000000. This also sets up the ATAGS which are used by the kernel to identify the hardware, and so it knows where to load the initrd. After that it jumps into execution at 0x20008000 to the kernel. The kernel will recognize the ATAGS (which are in a standard location for ARM at 0x100) and it will see the initrd as /dev/ram0. If you look at the default kernel config, we define the cmdline as: "root=/dev/ram0 rw init=/linuxrc lpj=498688 console=null". This is how it gets the initrd loaded and executes the linuxrc script.

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=32k && sync && sync
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=32k && sync && sync

Initrd 

dd if=/dev/mmcblk0p3 of=/path/to/initrd bs=32k && sync && sync

Restore

Entire SD card 

dd if=/path/to/backup.dd of=/dev/mmcblk0 bs=32k && sync && sync

Kernel 

dd if=/path/to/zImage bs=32k of=/dev/mmcblk0p2 && sync && sync

Initrd 

dd if=/initrd bs=32k of=/dev/mmcblk0p3 && sync && sync

From SBC

Backup

Entire card 

dd if=/dev/mmcblk0 of=/path/to/backup.dd && sync && sync

Kernel 

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

Initrd 

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

Restore

The entire card from SBC 

dd if=/path/to/2gbsd-4200-latest.dd of=/dev/mmcblk0 && sync && sync

Kernel 

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

Initrd 

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

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 multiple 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 | bzip2 > backup.dd.bz2
# 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 

dd if=xnand-4200-latest.dd bs=131072 count=2048 of=/dev/nbd0 && sync && sync

Kernel 

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

Initrd 

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

Expected Partition Layout

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

XNAND init

When an XNAND based device is shipped, it is first initialized at the factory. This sets up the OOB for XNAND data and should only ever need to be run that one time. The command for full initialization is provided here for completeness. 

nandctl --xnandinit 0x80000

Operating System

Linux

Debian

Our boards boot a standard Debian Squeeze (EABI) distribution from the SD card which provides a large amount of software that you can install with relatively little effort. See the Debian page for more general information on installing/removing software, and further documentation.

Emdebian

We also have Emdebian Grip on the XNAND. Emdebian is binary compatible with standard Debian, however it has a much smaller base. You can read more about this project here.

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/4200/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/4200/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. 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. This will provide you with an explorer window you can drag files into.

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: 

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


Kernel Compile Guide

WARNING: BACKUP YOUR DATA FIRST

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:
ftp://ftp.embeddedarm.com/ts-socket-macrocontrollers/ts-4200-linux/cross-toolchains/arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

# Extract to current working directory:
tar xvf arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

# Download the Kernel sources
wget ftp://ftp.embeddedarm.com/ts-socket-macrocontrollers/ts-4200-linux/sources/linux-2.6.36-ts-src-latest.tar.gz

# Extract the Kernel Sources
gzip -dc linux-2.6.36-ts-src-latest.tar.gz | tar xf -

cd linux-2.6.36-release/

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 may be different for your system:
export CROSS_COMPILE=/opt/4200/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-4200 

make ts4200_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 try to build 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 < 2620416 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-4200/dist/<ts4200 kernel release number>/modules-install/. In that directory is initrd-modules/, lib/, and modules-<ts4200 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-4200. It is also possible to copy over modules-<ts4200 kernel release number>.tgz to the TS-4200 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

Userspace IRQs

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.

This example below will work with any of our TS-Socket boards running Linux. This 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;
}

Features

CPU Functionality

SPI

The SPI controller is provided by the Atmel CPU.

USB Host

The Atmel CPU contains 2 USB Host ports.

WIFI-N-USB

See the WIFI-N-USB page for information on using the WIFI-N-USB module.

WIFI-G-USB-2

Note: The WIFI-G-USB-2 USB adapter went end of life in June 2011. This has been replaced with the WIFI-N-USB

The WIFI-G-USB-2 kernel module is included in the Debian modules.

WIFI-G-USB

Note: The WIFI-G-USB USB adapter is EOL. This has been replaced with the WIFI-N-USB

The WIFI-G-USB kernel module is included in the Debian modules.

USB Device

This section will discuss the configuration and use of the Linux USB device gadgets (http://www.linux-usb.org/).

The USB Mass Storage Device Linux USB gadget will allow you to use your board as a storage device, like a USB thumb drive, when connected to a host PC. Subsequently, the CPU can access the saved data through the storage element named usb_storage_file.

The IP over USB (A.K.A. USB Ethernet) Linux USB gadget will allow you to connect to your board with a USB cable from a PC like you would with a CAT5 Ethernet cable. You will have access to the board via the TCP/IP connection allowing you to use any networking utility (e.g. ping, ssh, ftp, http, etc).

For Windows, a driver interface configuration file (linux.inf) will need to be downloaded and installed on the host PC. This procedure is described in detail below. The linux.inf file can be downloaded here.

USB Device as Mass Storage

The USB Gadget file storage device will allow you to allow access to a block device (file or otherwise) over USB. To use this functionality, you must first have a block device to give to the driver. In this example I will use a 100MB file on the Debian filesystem. 

dd if=/dev/zero of=/root/usbstorage.img bs=1MB count=100

Load the driver with the file as an argument 

modprobe g_file_storage file=/root/usbstorage.img

If you now, or are have already connected the USB device cable to a host pc, you should now see the USB device. Like inserting any other usb drive you should now have a new device on your system. From a linux host pc: 

[690892.624575] sd 23:0:0:0: Attached scsi generic sg3 type 0
[690892.626160] sd 23:0:0:0: [sdd] 195312 512-byte logical blocks: (99.9 MB/95.3 MiB)
[690892.628419] sd 23:0:0:0: [sdd] Write Protect is off
[690892.628424] sd 23:0:0:0: [sdd] Mode Sense: 0f 00 00 00
[690892.628911] sd 23:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[690892.644202]  sdd: unknown partition table
[690892.647287] sd 23:0:0:0: [sdd] Attached SCSI disk

Now on your workstation you can use this device as any other usb storage. As this file contains all zeros, you will need to format it and create a partition/filesystem to be able to store data on it. See the documentation for your workstation for more details. Keep in mind you cannot mount the same block device or file twice so this will not allow you to share your live filesystem over USB.

USB Device as USB Ethernet

In order to use USB Device as USB Ethernet you will first need a new kernel compiled from source. The instructions to compile the kernel can be found here.

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 media.

Once you have added the newly compiled kernel to your image you will now have Ethernet Gadgets driver built in which will allow you to use USB Device as USB Ethernet. The board must be setup prior to connection to a host PC.

Now assign an IP address to the new usb0 interface 

ifconfig usb0 192.168.42.20

The IP address in the above example may be any valid IP address, but should typically not be on the same subnet as the Ethernet network on the the board (if connected), or the host computer to which the SBC will be connected.

Connecting Linux Host to the board via IP over USB

Most modern Linux distributions already have all of the required modules (such as usbnet.ko) and utilities installed, so the setup steps are minimal. Simply plug in the board after it has been prepared for IP over USB (see above) and observe that a new interface has been added named usb0 or similar (use dmesg | tail to verify). You can now assign an IP address to that interface with ifconfig (e.g. ifconfig usb0 192.168.42.21) and begin using the TCP/IP connection. To test your connection, use ping 192.168.42.20. You should also be able to login to the SBC using ssh ie. ssh root@192.168.42.40.

Connecting Windows XP Host to the board via IP over USB

An additional driver interface configuration file called linux.inf is required for IP over USB connection to a Windows host. First, download this file onto the Windows PC and remember where you placed it. The linux.inf file can be downloaded here. Next, connect the board and Windows PC with the A to B USB cable (ISB Cable). You should see the "Found New Hardware Wizard". Answer the prompts as follows:

  • Select Include this location in the search and choose the location of the driver you downloaded. Finish running the wizard.
  • Go to the Control Panel and open "Network Connections". Right-click the new connection (labeled "Linux USB Ethernet/RNDIS Gadget") and click "Rename". Rename it to something useful such as "USB Network".
  • Right-click on the newly labeled icon, and select properties.
  • Under the properties General tab, select the item labeled Internet Protocol (TCP/IP)
  • Select Use the following IP Address, and enter 192.168.42.21.
  • Click OK; Click OK
  • You may now access the board via the TCP/IP connection. Use ping in the Command Prompt window to verify connectivity (e.g. ping 192.168.42.20).
Note: The IP address above may be any valid IP address, but must be in the same subnet as the IP address assigned to the board IP over USB connection above. The subnet used should also be different from any other interfaces on the SBC or PC, otherwise strange results may occur.

FPGA Functionality

The TS-4200 features a Low power Actel FPGA clocked by the CPU only when needed. This FPGA is not end user programmable, but you can use the MUXBUS to allow communication to an offboard FPGA. The TS-4200 provides access to the FPGA in an 8 bit region and a 16 bit region. The 8 bit base address is 0x10000000. The 16 bit base address is 0x30000000. All registers inside the TS-4200 FPGA are 16 bit registers and should be accessed via the 16 bit space. The 8 bit space is only needed for off-board 8 bit devices on the MUXBUS. To access hardware cores in the FPGA, add the offset in the table below to the base address.

This table shows our top level decode for the FPGA. Use the 16 or 8 bit address with these offsets to talk to our various FPGA cores.

Offset Usage
0x0 Syscon registers
0x080 ADC registers (for off-board ADC)
0x100 NAND flash registers
0x200 NVRAM control registers
0x400 1KB MUXBUS space
0x800 2KB Direct blockram access (For NVRAM transfers)

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 0x30000000.

Offset Bits Usage
0x0 15:0 Model ID: Reads 0x4200
0x2 15 Green LED (1 = on)
14 Red LED (1 = on)
13:8 Reserved
7:4 Board Sub-model: reads 0x0 on standard unit
3:0 FPGA revision
0x4 15:0 DIO direction for DIO 15(MSB)-0(LSB)
0x6 15:0 DIO output data for DIO 15(MSB)-0(LSB)
0x8 15:0 DIO input data for DIO 15(MSB)-0(LSB)
0xa 15:12 Reserved
11 UART0 9 bit mode (so that TX_EN works correctly)
10 1 = use DIO12 for uart0 TX_EN instead of DIO
9 1 = use 512Hz for WDT instead of 200Hz
8 1 = auto reboot when DIO 9 is driven low (enable reset button)
7:6 Scratch Register (used by bootrom)
5:4 Mode strapping inputs Mode2 and Mode1
3 Reserved
2 1 = Enable power to Ethernet PHY
1 1 = Enable power to SD card
0 Offboard reset signal (1 = reset)
0xc 15:0 32-bit 1MHz free running counter (16 LSBs)
0xe 15:0 32-bit 1MHz free running counter (16 MSBs)
0x10 15:0 Watchdog feed register
0x12 15:0 DIO direction for DIO 31(MSB) - 16(LSB)
0x14 15:0 DIO output data for DIO 31(MSB) - 16(LSB)
0x16 15:0 DIO input data for DIO 31(MSB) - 16(LSB)
0x18 15:0 Hardware RNG (16 LSB)
0x1a 15:0 Hardware RNG (16 MSB)
0x1c 15 Embedded FlashROM CLK
14:8 Embedded FlashROM Address
7:0 Embedded FlashROM Data Byte
0x1e 15:0 UART0 baud rate divisor (for UART0 TX_EN)
0x20 15:0 MUXBUS configuration register
0x22 15:0 IRQ register
0x24 15:0 IRQ mask register

The born-on date of the unit and the MAC address can be read by from the FPGA FlashROM. See ts4200ctl source code for sample usage.

Watchdog

The Watchdog feed register is write-only. Valid write values are:

Write Value Effect
0 Feed watchdog for the next 0.5 sec
1 Feed watchdog for the next 2 sec
2 Feed watchdog for the next 16 sec
3 Disable watchdog

These watchdog timeout times assume that the 512Hz clock is being used as a watchdog clock. At power-up, the 200Hz clock is used, which means that the timeout times would actually be roughly 150% longer. The 512Hz clock signal is not turned on until a time is written to the RTC. The default linuxrc writes the RTC, which enables the 512Hz signal, and then switches the watchdog to the 512Hz signal. 

#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,
                      0x30000000);
 
        for(;;) {
                // This feeds the watchdog for 10s.
                syscon[0x10/2] = 2;
                sleep(8);
        }
 
        return 0;
}

NVRAM

The TS-4200 features an 8KB non-volatile SRAM. If a voltage is supplied on V_BAT, the TS-4200 can shut down without losing SRAM data. To communicate with the SRAM, software must read and write the FPGA blockram region, and use NVRAM control registers to initiate block transfers between the FPGA blockram and the SRAM. The NVRAM control register map is as follows:

Offset Bits Usage
0x0 15:2 Reserved
1 power fail. 1 = further transfers are not permitted.
0 busy flag. Indicates transfer is occurring.
0x2 15:3 Reserved
2:1 NVRAM bank used for copy
0 0 = copy NVRAM to blockram
0x4 15:1 Reserved
0 transfer enable register
0x6 15:0 Power fail flag can be cleared by writing 0 to this register.

Data transfers between FPGA blockram and SRAM happen in 2KB blocks. The NVRAM consists of 8KB divided into 4 banks of 2KB. The correct software algorithm for a single transfer is as follows:

  • Make sure the busy flag and power fail flag are not set
  • Program the NVRAM bank register and direction register as desired
  • Set the transfer enable flag
  • Poll the busy flag until it goes high
  • Clear the transfer enable flag

The ts4200ctl utility source code includes a function that demonstrates the above algorithm.

MUXBUS

Muxbus timing.png

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 [1]
bits 15:13 TH_DAT
  1. ↑ A TP_CS of 0x3f is not supported -- use a value from 0 to 62 (that's 0x00 to 0x3e).

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. The TS-4200 uses a 20.20 ns clock cycle.

PC104

With the baseboards that make use of the PC104 bus, you must first set up the MUXBUS timing registers. From Debian, you would run this: 

source /initrd/ts4200.subr 
pc104on

From your application you can now talk to the MUXBUS for communication to PC104. The TS-4200 with our baseboards will implement the 8 bit PC104 address space from 0x10000400 to 0x10000800. The 16 bit access is available from 0x30000400 to 0x30000800. This example uses the TS-RELAY8. 

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

// This offset is for the TS-4200 8bit SMC (FPGA)
#define BASE_ADDRESS 0x10000000

// This assumes jumper 1 is on the TS-RELAY8
#define PLD_OFFSET 0x140

unsigned short *muxbus_base;
typedef enum {
  RLYON = 0x00,
  RLYOFF = 0xFF,
  RLY1 = 1 << 0,
  RLY2 = 1 << 1,
  RLY3 = 1 << 2,
  RLY4 = 1 << 3,
  RLY5 = 1 << 4,
  RLY6 = 1 << 5,
  RLY7 = 1 << 6,
  RLY8 = 1 << 7
} RelayFlags;

static void poke8(unsigned int adr, uint8_t val) {
        muxbus_base[adr / 2] = val;
}

void set_relays(RelayFlags bits) {
    // This adds the PLD offset to talk to the TS-RELAY8
    // the 0x400 is the offset for the MUXBUS (see the FPGA Functionality section)
    // 0x2 is added for the offset of the actual relays.  See the TS-RELAY8 wiki for more details
    poke8(PLD_OFFSET + 0x400 + 0x2, bits);
    usleep(15000);
}

int main(int argc, char **argv) {
    int mem = open("/dev/mem", O_RDWR|O_SYNC);
    assert(mem != -1);
    muxbus_base = mmap(0,
         getpagesize(),
         PROT_READ|PROT_WRITE,
         MAP_SHARED,
         mem,
         BASE_ADDRESS);
    assert(muxbus_base != MAP_FAILED);

    while(1)
    {
	set_relays(RLYOFF);
        set_relays(RLY1);
        set_relays(RLY1|RLY2);
        set_relays(RLY1|RLY2|RLY3);
        set_relays(RLY1|RLY2|RLY3|RLY4);
        set_relays(RLY1|RLY2|RLY3|RLY4|RLY5);
        set_relays(RLY1|RLY2|RLY3|RLY4|RLY5|RLY6);
        set_relays(RLY1|RLY2|RLY3|RLY4|RLY5|RLY6|RLY7);
        set_relays(RLYON);
    }
    return 0;
}

COM Ports

This CPU brings out 7 UARTs all brought out as TTL. The first port is used as the debug console. See your baseboard for more details on how these UARTs are level shifted (RS232, RS485, etc). While we do not have example code for handling the UARTS, you can find documentation on working with these from The Linux Documentation Project here.

For the RS485 implementation, you must toggle a DIO in the FPGA to enable the auto tx-enable functionality. For our off the shelf baseboards, that is typically set like this. 

#Enables auto TX Enable in FPGA for ttyS1
peekpoke 16 0x3000000A 0x407

See the #Syscon for more details.

Device TX Location RX Location
/dev/ttyS0 CN2-93 CN2-95
/dev/ttyS1 CN2-78 CN2-80
/dev/ttyS2 CN2-82 CN2-84
/dev/ttyS3 CN2-86 CN2-88
/dev/ttyS4 CN2-90 CN2-92
/dev/ttyS5 CN2-94 CN2-96
/dev/ttyS6 CN2-98 CN2-100

Interrupts

The TS-4200 has 4 IRQs that can be used by external devices. See page 30 of the CPU manual for a complete listing of all of the available IRQs. See the #Userspace IRQs section for examples on how to use these IRQs.

The Linux kernel on the TS-4200 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.

IRQ # Name Socket Location
31 PC14_IRQ2 CN2-91
192 IRQ5/DIO_00 CN1-93
193 IRQ6/DIO_01 CN1-91
194 IRQ7/DIO_02 CN1-89
Note: IRQs 192-194 require 'pc104on' to be run to MUX these IRQs. See the #PC104 chapter.

Connectors

TS-Socket

The TS-SOCKET System-on-Modules (SoMs) all use two high density 100 pin connectors for power and all I/O. These follow a common pinout for various external interfaces so new modules can be dropped in to lower power consumption or use a more powerful processor. The male connector is on the baseboard, and the female connector is on the SoM. You can find the datasheet for the baseboard's male connector here. This can be ordered from the TS-Socket SoM product page as CN-TSSOCKET-M-10 for a 10 pack, or CN-TSSOCKET-M-100 for 100 pieces, or from the vendor of your choice, the part is an FCI "61083-102402LF".

TS-Socket

We have an Eaglecad library available for developing a custom baseboard here. We also provide the entire PCB design for the TS-8200 baseboard here which you can modify for your own design.

In our schematics and our table layout below, we refer to pin 1 from the male connector on the baseboard.

Example Baseboard Please refer to your baseboard wiki or schematics for more details on which of these pins go where.

CN1 CN2
Name Pin Pin Name
FPGA_JTAG_TMS 1 2 EXT_RESET#
FPGA_JTAG_TCK 3 C 4 EN_USB_5V
FPGA_JTAG_TDO 5 N 6 SDCARD_D2
FPGA_JTAG_TDI 7 1 8 SDCARD_D3
OFF_BD_RESET# 9 10 SDCARD_CMD
BOOT_OVERRIDE 11 12 SDCARD_3.3V
SPI0_CLK 13 C 14 SDCARD_CLK
POWER 15 N 16 POWER
Reserved 17 1 18 SDCARD_D0
Reserved 19 20 SDCARD_D1
Reserved 21 22 SER_FLASH_WP
Reserved 23 C 24 Reserved
Reserved 25 N 26 Reserved
Reserved 27 1 28 Reserved
POWER 29 30 Reserved
Reserved 31 32 Reserved
Reserved 33 C 34 Reserved
Reserved 35 N 36 V_BAT
Reserved 37 1 38 Reserved
Reserved 39 40 Reserved
Reserved 41 42 Reserved
Reserved 43 C 44 Reserved
Reserved 45 N 46 Reserved
POWER 47 1 48 Reserved
Reserved 49 50 Reserved
Reserved 51 52 Reserved
Reserved 53 C 54 Reserved
Reserved 55 N 56 Reserved
Reserved 57 1 58 Reserved
Reserved 59 60 Reserved
Reserved 61 62 GND
DIO_14 63 C 64 MUX_AD15
DIO_13 65 N 66 MUX_AD14
DIO_12 67 1 68 MUX_AD13
DIO_11 69 70 MUX_AD12
DIO_10 71 72 MUX_AD11
DIO_9 73 C 74 MUX_AD10
GND 75 N 76 MUX_AD09
DIO_8 77 1 78 MUX_AD08
DIO_7 79 80 MUX_AD07
DIO_6 81 82 MUX_AD06
DIO_5 83 C 84 MUX_AD05
DIO_4 85 N 86 MUX_AD04
DIO_3 87 1 88 MUX_AD03
DIO_2 89 90 MUX_AD02
DIO_1 91 92 MUX_AD01
DIO_0 93 C 94 MUX_AD00
GND 95 N 96 BUS_ALE#
BUS_WAIT# 97 1 98 BUS_DIR
BUS_BHE# 99 100 BUS_CS#
Name Pin Pin Name
ETH_RX+ 1 2 ETH_LEFT_LED
ETH_RX- 3 C 4 ETH_RIGHT_LED
ETH_CT 5 N 6 RED_LED#
ETH_TX+ 7 2 8 GREEN_LED#
ETH_TX- 9 10 SHUT_DOWN
ETH_CT 11 12 WAKE_UP
3.3V 13 C 14 PC6
GND 15 N 16 PC0
Reserved 17 2 18 PC1
Reserved 19 20 PC2
GND 21 22 PC3_SPI_CS3#
DEV_USB_M 23 C 24 AN_VREF
DEV_USB_P 25 N 26 PA22
1.0V BU 27 2 28 TW_CLK
HOST_USB_M 29 30 TW_DAT
HOST_USB_P 31 32 PA6
1.0V 33 C 34 Reserved
HOSTB_USB_M 35 N 36 PB16
HOSTB_USB_P 37 2 38 PB17
3.3V 39 40 PB18
Reserved 41 42 PB19
Reserved 43 C 44 CPU_JTAG_TMS
GND 45 N 46 CPU_JTAG_TCK
Reserved 47 2 48 CPU_JTAG_TDI
Reserved 49 50 CPU_JTAG_TDO
GND 51 52 PB28
Reserved 53 C 54 PC8
Reserved 55 N 56 DIO_16
1.8V 57 2 58 PB20
Reserved 59 60 PB21
Reserved 61 62 PB22
1.5V 63 C 64 PB25
SPI_CS0# 65 N 66 PB26
SPI_MOSI 67 2 68 PB27
SPI_MISO 69 70 PB30
SPI_CLK 71 72 PB29
GND 73 C 74 Reserved
PC4_SPI_CS2# 75 N 76 Reserved
PC4_SPI_CS1# 77 2 78 UART0_TXD(PB4)
3.3V 79 80 UART0_RXD(PB5)
PB23 81 82 UART1_TXD(PB6)
Reserved 83 C 84 UART1_RXD(PB7)
PC9 85 N 86 UART2_TXD(PB8)
PC10 87 2 88 UART2_RXD(PB9)
PC13 89 90 UART3_TXD(PB10)
PC14_IRQ2 91 92 UART3_RXD(PB11)
DEBUG_TXD 93 C 94 UART4_TXD(PA31)
DEBUG_RXD 95 N 96 UART4_RXD(PA30)
DIO_15 97 2 98 UART5_TXD(PB12)]]
PC7 99 100 UART5_RXD(PB13)

Product Notes

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.

Retrieved from "http://docs.embeddedTS.com/index.php?title=TS-4200&oldid=1422"