TS-7350

From embeddedTS Manuals
Revision as of 23:22, 9 April 2012 by Mark (talk | contribs)
TS-7350
TS-7350.jpg
Product Page
Documentation
Schematic
Mechanical Drawing
FTP Path
Cirrus Logic EP9302
CPU User Guide
Specifications
Weight 90g (approx)
Operating Temperature
Cold -40C
Hot 70C
Hot 85C (166 MHz)

Overview

The TS-7350 is a compact full-featured Single Board Computer (SBC) based upon the Cirrus EP9302 200MHz ARM9 CPU, which provides a standard set of on-board peripherals. It features a programmable FPGA which is connected to a dedicated framebuffer and provides additional on-board peripherals.

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-7350 receives 5V-28V through the two power poles, or 5V through the PC104 bus.

Note: Pay attention to the polarity of the power connector as printed on the board.

Get a Console

Connect the TS-9445 to the 24 pin header facing outwards and use the 10 pin header (labeled "Console"). You can also telnet to the board with the default network configuration, though this will omit the TS-BOOTROM messages which are extremely useful for debugging.

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

When the board first boots you will see this shell: 

 >> TS-BOOTROM - built Jan  7 2009
 >> Copyright (c) 2008-2009, Technologic Systems
 >> Booting from SD card...
 .
 .
 .
 / #

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

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. 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 script to always boot into 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-fastgui This is used by the TS-7390/TS-7395 which starts X11
linuxrc-mtdroot This mounts the onboard flash (not present on the TS-7350)
linuxrc-sdroot Boots immediately to the Debian stored on SD.
linuxrc-nfsroot This script needs to be modified before use, but shows an example of how to use NFS as your debian filesystem.

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

To use any of the other boot scripts, you can simply replace 'linuxrc-sdroot' with the script name mentioned above.

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

 BusyBox v1.7.1 (2008-08-01 11:47:44 MST) multi-call binary
 Copyright (C) 1998-2006  Erik Andersen, Rob Landley, and others.
 Licensed under GPLv2.  See source distribution for full notice.
 
 Usage: busybox [function] [arguments]...
    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:
 	[, [[, ash, basename, cal, cat, catv, chgrp, chmod, chown,
 	chroot, cksum, clear, comm, cp, cttyhack, cut, date, dd,
 	df, dirname, dmesg, du, echo, egrep, env, eptime, expr,
 	false, fdisk, fgrep, find, free, ftpget, ftpput, getopt,
 	getty, grep, gunzip, halt, head, hexdump, hostname, ifconfig,
 	insmod, kill, killall, ln, ls, lsmod, md5sum, mdev, mkdir,
 	mkfifo, mknod, modprobe, more, mount, mtdcp, mv, mvtime,
 	netstat, nice, nohup, nslookup, peekpoke, ping, ping6,
 	pivot_root, playsound, poweroff, printenv, printf, ps,
 	pscan, pwd, reboot, rm, rmdir, rmmod, route, rx, sed,
 	setconsole, setlogcons, sh, sha1sum, sleep, split, stat,
 	stty, sum, sync, tail, tar, tee, telnetd, test, tftp,
 	time, top, tr, traceroute, true, tty, udhcpc, umount,
 	uname, unzip, uptime, usleep, uudecode, uuencode, vi,
 	wget, which, xargs, zcat


We also provide the ts7000.subr which provides the following functions: 

 bit_set
 bit_clr
 bit_get
 dio_dir_get
 dio_dir_set
 dio_data_get
 dio_data_set
 usb_init
 usb_off
 usb_numports
 usb_port_devexists
 eth_off
 eth_on
 led0
 led1
 cpu_speed_max
 cpu_speed_166
 cpu_speed_42
 cpu_speed_min
 pc104on
 pc104off
 nand_on
 nand_off
 lcd_on
 lcd_off
 speaker_on
 speaker_off
 wdt_on_338ms
 wdt_on_2706ms
 wdt_on_10824ms
 wdt_on
 wdt_off
 is_ts7390 
 tshelp
 sdmount
 mtdmount
 help

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, 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 0x8000. The second partition of type 0xda is loaded into memory at 0x1000000. 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 0x8000 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 so that it executes the 'linuxrc' script as soon as it mounts the initrd.

The debian filesystem is bootstrapped at the end of our own init process from the initrd: 

cd /mnt/root
pivot_root . ./initrd
./bin/mount -n --move ./initrd/sys ./sys
./bin/mount -n --move ./initrd/proc ./proc
exec ./usr/sbin/chroot . ./sbin/init < .$CONSOLE > .$CONSOLE 2>&1

Backup / Restore

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

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


From Workstation

Backup

Entire SD card 

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

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=/path/to/initrd bs=32k of=/dev/mmcblk0p3 && sync && sync

From TS-7800

Backup

Entire card 

dd if=/dev/tssdcarda of=/path/to/backup.dd bs=512 && sync && sync

Kernel 

dd if=/dev/tssdcarda2 of=/path/to/zImage bs=512 && sync && sync

Initrd 

dd if=/dev/tssdcarda3 of=/path/to/initrd bs=512 && sync && sync

Restore

The entire card from SBC 

dd if=/path/to/sdimage.dd of=/dev/tssdcarda conv=sync bs=512 && sync && sync

Kernel 

dd if=/path/to/zImage of=/dev/tssdcarda2 conv=sync bs=512 && sync && sync

Initrd 

dd if=/path/to/zImage of=/dev/tssdcarda3 conv=sync bs=512 && sync && sync

Operating System

Our supported OS is Debian 4.0 (Etch). While the CPU will support OABI and EABI distributions, the kernel is limited to 2.6.21. This will run Debian's EABI Lenny, but is not recommended for more new distributions.

You can find our provided distributions here.

Linux

Kernel Compile Guide

WARNING: BACKUP YOUR DATA FIRST

Prerequisites

This guide is intended to run on an x86 compatible Linux workstation. While you may be able to compile the kernel on the board, we do not recommend it. A typical workstation compile will take several minutes. The same compile on the board will take several hours.

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. Next you need to set up the cross compiler and sources: 

# Download the cross compile toolchain (OABI)from Technologic Systems:
wget ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7350-linux/cross-toolchains/crosstool-linux-gnueabi-2005q3-2.tar.gz

#Extract to current working directory:
tar xvf  crosstool-linux-gnueabi-2005q3-2.tar.gz

#Download the kernel sources
wget ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7350-linux/sources/linux-2.6.21-ts-src-latest.tar.gz
tar xvf linux-2.6.21-ts-src-latest.tar.gz
cd linux-2.6.21-ts

Export the CROSS_COMPILE variable with a path that points to the appropriate cross-compiler. If you followed the steps above exactly, the toolchain is extracted into the same directory as the kernel. 

export CROSS_COMPILE=../arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-
export ARCH=arm

Now you will want to configure your settings. You can start with our default config by running: 

make ts7350_defconfig

At this point you can configure any additional options with: 

make menuconfig

For example, to include CIFS support use the arrow and Enter keys to navigate to Filesystems -> Network File Systems -> CIFS Support. Press "y" to include CIFS support into the kernel (alternatively, you could modularize the feature with "m" so you can enable or disable the module on demand which will also enable you to simply copy/paste the cifs.ko into the correct path in the kernel instead of copying the entire kernel (outlined below in appendix)). Keep hitting "exit" until you're prompted to save changes, choose "yes".

After you have made your selection, you can build your kernel and modules with: 

make && make modules
Note: If you receive an error about PATH_MAX not being defined, you will need to edit scripts/mod/sumversion.c and add "#define PATH_MAX 1024".

The new kernel will be at "arch/arm/boot" in a compressed format called zImage (the uncompressed version is simply called Image, but it is REQUIRED that it fit in the kernel partition. If it does not fit, you can go back in and change any changed options from included (*) to modules (m).

Once you have a zImage that fits, you can copy this to the SD card by following the "Restore Kernel" steps in the #Backup / Restore section.

You will need to install several of these modules to the initrd (third partition) of the SD card. Mount the third partition of the SD card and copy these files: 

# Create a directory to mount this device
mkdir -p /mnt/sd/

# Note, your device may be something different.  Check 'dmesg' to get the correct name.  On my system, this is /dev/sdg.
# If you receive an error here, try restoring to the stock image first.  You may also need 
# to load kernel modules for filesystem support.

mount /dev/sdg3 /mnt/sd

# This assumes you are still in the root of the kernel sources
cp ./drivers/mtd/nand/ts7800.ko /mnt/sd/
cp ./drivers/mmc/tssdcard.ko /mnt/sd
cp ./drivers/serial/tsuart1.ko /mnt/sd/
cp ./drivers/serial/tsuart7800.ko /mnt/sd/
cp ./drivers/usb/core/usbcore.ko /mnt/sd/
cp ./drivers/usb/host/ehci-hcd.ko /mnt/sd/

umount /mnt/sd && sync && sync

To install the modules in the Debian partition: 

mkdir newmodules
INSTALL_MOD_PATH=newmodules make modules_install

# Again, your device may be something different.  Check 'dmesg' to get the correct name.  On my system, this is /dev/sdg.
mount /dev/sdg4 /mnt/sd

# Remove the old modules
rm -rf /mnt/sd/lib/modules/2.6.21-ts/

# Install the new modules
cp -r newmodules/lib/ /mnt/sd/

umount /mnt/sd && sync && sync

Once you boot up to the board to Debian, you need to run 'depmod' once to calculate module dependencies. This will not work from the fastboot as it cannot write to this directory. After this is run, you can 'modprobe <module>' for your specific device support.


Features

CPU Features

DIO

Pins named "DIO" in the function column are connected directly to EP9302 GPIO pins. To use these pins, you must first set the data direction registers, and then read or write values from the data registers. When accessing these registers, it is important to do a read-modify-write, as other bits may be used internally. Pins named "BGPIO" are accessed through port B. The port B data direction register is located at address 0x80840014 and the port B data register is at 0x80840004. Pins named "HGPIO" are accessed through port H. The port H data direction register is located at address 0x80840044 and the port H data register is at 0x80840040. These pins are rated at 0v-3.3v and can safely source 4mA or sink 8mA.

LEDs

There are three LEDs on the TS-7350: one red, one green, and one yellow. The green LED comes on at power-up and stays on by default (boards born before 9/12/2009 all LEDs flash on and then stay off by default). The green and red LEDs are controlled through the CPU GPIO port E. They can be controlled using bits 0 (GRN) and 1 (RED) of the port E register at address 0x8084_0020. The yellow LED is controlled by bit 6 of the register at 0x600ff084. For example, using "bit_set 32 0x80840020 0" will turn on the green LED, whereas bit_clr 32 0x80840020 0 will turn it off and using "bit_set 32 0x80840020 1" will turn on the red LED, whereas bit_clr 32 0x80840020 1 will turn it off.

SPI Bus

The SPI_CLK, SPI_MOSI, SPI_MISO, and SPI_FRAME pins bring out the SPI bus from the EP9302 CPU. Please refer to the EP9302 user's guide for more information.

I2C Bus

The I2C_SCL and I2C_SDA pins bring out the I2C bus from the EP9302 CPU. Please refer to the EP9302 user's guide for more information.

FPGA Features

The 5,000 LUT Lattice FPGA is an integral part of the TS-7350 design. When the TS-7350 is powered on, the FPGA comes on first and it then boots the CPU, using boot code from the SD card. After an operating system has booted, the FPGA provides the CPU access to the SD cards, and the PC/104 connector. The default FPGA load allows these pins to be used either as a standard PC/104 bus or for GPIO. Due to the flexibility of FPGAs, many other functionalities are possible such as quadrature encoders, PWM outputs, extra serial ports, or other unique communications protocols. Please contact Technologic Systems if you require custom FPGA logic.

Random Number Generator

The TS-7350 has two built-in true random number generators (RNG). The numbers are generated from internal random entropy. The 16-bit value at address 0x600f_f0d0 and 0x600f_f0d2 contains the most recent random value generated. Only thirty-two bits of true random data are created every second, so if these registers are read more quickly the values read are not guaranteed to be random: in fact, you will either read the same value as previously or else a pseudo-random intermediate value from the last value generated.

Watchdog

The TS-7350 incorporates a Watchdog Timer (WDT) unit. The WDT can be used to prevent a system "hanging" due to a software failure. The WDT causes a full system reset when the WDT times out, allowing a guaranteed recovery time from a software error. To prevent a WDT timeout, the application must periodically "feed" the WDT by writing a specific value to a specific memory location. The watchdog functionality was implemented in the TS-7350 on 9/12/2009. To find out if your TS-7350 has the watchdog implemented, use "peekpoke 16 0x600FF080". There will be four hex digits total. The first three (0x6C8) identify the system as a TS-7350, the last identifies the revision number for the FPGA programming. A value of 0x8 or above indicates that the watchdog has been implemented in your FPGA version.

The WDT register (memory location 0x600ff0d6) must be re-initialized within the timeout period desired. This may be as short as 338 mS or may be as long as 10.824 seconds. After the WDT has been enabled, the WDT counter begins. The application software can reset this counter at any time by "feeding" the WDT. If the WDT counter reaches the timeout period, then a full system reset occurs.

Watchdog Timeout Register
Value Timeout
0x00 338ms
0x01 2706ms
0x02 10824ms
0x03 Disable Watchdog

You can use the following code as an example of controlling the watchdog from your own program. This also shows a simple example of manipulating the #Syscon registers. 

#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,
                      0x600FF000);
 
        for(;;) {
                // This feeds the watchdog for 10s.
                // The syscon starts at 0x80, and the WTD is at 0x56 in the syscon
                syscon[(0x80 + 0x56)/2] = 0x2;
                sleep(5);
        }

        return 0;
}

Buffered Inputs

There are a total of 10 buffered digital input lines. Pins IN_0 through IN_6 are dedicated digital inputs, while pins IN_9 through IN_11 are in parallel with analog inputs and thus can only be used for digital input if analog inputs are not needed. Pins IN_0 through IN_3 have resistor pull-ups. The others will return random data if not driven high or low.

The 32 bit register at address 0x600f_f084 provides access to digital inputs. Pins IN_0 through IN_6 are accessed by bits 7 through 13. Pin IN_9 is accessed by bit 15. Pins IN_10 and IN_11 are accessed by bits 11 and 12 of the register at address 0x600f_f086.

Latched Outputs

Pins OUT_0 through OUT_5 are digital output lines. The 32 bit register at address 0x600f_f084 provides access to digital outputs through bits 0 through 5. These pins are rated at 0v-3.3v and can safely source or sink 50mA.

Temperature Sensor

The TS-7350 has an optional on-board temperature sensor (part #:OP-TMPSENSE). The temperature sensor used is a TMP124; a copy of the datasheet can be found here, and sample code can be found here.

The temperature sensor is accessed via SPI pins on the DIO header documented in the previous section. The DATA pin on the TMP124 is connected to the SPI_MISO# signal, while the CLK pin is connected to the SPI_CLK pin. In addition there is a chip select signal which must be asserted in order to use the temperature sensor chip. This signal is accessed through bit 2 of the register at address 0x80840030. (CPU GPIO port F) Note that the polarity of this signal is active high (set this bit to select the temp sensor).

Real Time Clock

The TS-7350 optionally supports a Non-volatile Battery-backed real-time clock (RTC) which is soldered onto the board. This option uses an ST Micro M48T86PC1 module for the real-time clock function. This module contains the lithium battery, 32.768 kHz crystal, and a RTC chip with 114 bytes of battery-backed CMOS RAM. It will maintain clock operation for a minimum of 10 years in the absence of power.

The 114 bytes of non-volatile RAM, physically located in the RTC chip, are available to the user. Contact Technologic Systems for driver support.

The RTC can be accessed and setup through the hwclock command: 

  / # hwclock --help
  hwclock - query and set the hardware clock (RTC)
 
  Usage: hwclock [function] [options...]
 
  Functions:
    --help        show this help
    --show        read hardware clock and print result
    --set         set the rtc to the time given with --date
    --hctosys     set the system time from the hardware clock
    --systohc     set the hardware clock to the current system time
    --adjust      adjust the rtc to account for systematic drift since 
                  the clock was last set or adjusted
    --getepoch    print out the kernel's hardware clock epoch value
    --setepoch    set the kernel's hardware clock epoch value to the 
                  value given with --epoch
    --version     print out the version of hwclock to stdout
 
  Options: 
    --utc         the hardware clock is kept in coordinated universal time
    --localtime   the hardware clock is kept in local time
    --directisa   access the ISA bus directly instead of /dev/rtc
    --badyear     ignore rtc's year because the bios is broken
    --date        specifies the time to which to set the hardware clock
    --epoch=year  specifies the year which is the beginning of the 
                  hardware clock's epoch value
    --noadjfile   do not access /etc/adjtime. Requires the use of
                  either --utc or --localtime

Connectors

40 pin header

The general header is a 40 pin (2x7, 0.1" spacing) header providing I2C, SPI, GPIO, latched outputs, buffered inputs, A/D inputs, an external reset line, and a console UART.

The general header is made up of two adjacent headers, labeled JTAG and DIO:

2 4 6 8 10 12 14 16 2 4 6 8 10 12 14 16 18 20 22 24
1 3 5 7 9 11 13 15 1 3 5 7 9 11 13 15 17 19 21 23
JTAG DIO
Pin Name Function
JTAG 1 JTAG_DOUT Reserved
JTAG 2 JTAG_TMS Reserved
JTAG 3 GND Ground
JTAG 4 JTAG_DIN Reserved
JTAG 5 JTAG_CLK Reserved
JTAG 6 JTAG_CLK Reserved
JTAG 7 UART0_TXD UART0
JTAG 8 UART0_RXD UART0
JTAG 9 SPI_MISO SPI bus
JTAG 10 3.3V 3.3V
JTAG 11 HGPIO_5 DIO
JTAG 12 SPI_MOSI SPI bus
JTAG 13 FLASH_CS# Reserved
JTAG 14 SPI_CLK SPI bus
JTAG 15 5V 5V
JTAG 16 EXT_RESET# External Reset
DIO 1 SPI_FRAME SPI bus
DIO 2 GND Ground
DIO 3 RSVD Reserved
DIO 4 OUT_5 Latched output
DIO 5 IN_00 Buffered input
DIO 6 OUT_4 Latched output
DIO 7 IN_01 Buffered input
DIO 8 OUT_3 Latched output
DIO 9 IN_02 Buffered input
DIO 10 OUT_2 Latched output
DIO 11 IN_03 Buffered input
DIO 12 OUT_1 Latched output
DIO 13 IN_04 Buffered input
DIO 14 OUT_0 Latched output
DIO 15 IN_05 Buffered input
DIO 16 ADC4/BGPIO_7 ADC/DIO
DIO 17 IN_06 Buffered input
DIO 18 BGPIO_6 DIO
DIO 19 BGPIO_5 DIO
DIO 20 ADC2 ADC/Buffered input
DIO 21 I2C_SDA I2C
DIO 22 ADC1 ADC/Buffered input
DIO 23 I2C_SCL I2C
DIO 24 ADC0 ADC/Buffered input
Note: Pins labeled "Reserved" are used at the factory for production purposes and should not be used for development or applications.

TS-7350 Errata

TS-7350 PC/104 XUART pins unusable as GPIO

Synopsis PC/104 XUART pins cannot be used as GPIO
Severity Minor
Class FPGA bug
Affected TS-7350/70 All FPGA Revs
Status No workarounds available

Description:

The two XUARTs on PC/104 pins A12, A15, A18, and A19 are unavailable as GPIO pins and are always XUART pins if the PC/104 bus is in GPIO mode, `pc104off`. If the PC/104 bus is in PC/104 mode, `pc104on`, then these pins will be used in their PC/104 modes and not available as XUART. This is not considered a bug at this point in time.

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-7350&oldid=1749"