Commtech's Fastcom Product Support Blog

I just found a tool online that will calculate the programming data for an ICS307-02 clock generator that is used on our Async335 cards as well as the ESCC-PCI-335.

http://www.idt.com/?app=calculators&device=307_02

The input frequency is always 18.432MHz.
Desired output frequency is what you are trying to get.
Allowable Output Frequency Accuracy: Lower is better
Clock 2 output: Off
Output Driver: CMOS
Crystal Load Capacitance: 00
Allowable Duty Cycle Range: 45-55
Operating Temperature: -40 to 85 C

asyncpci335_2010_09_23.zip

I get a lot of questions about how far an RS-422 signal can go or how fast can an RS-422 signal be driven.  Unfortunately the answer is not exactly cut and dry.  This is an exerpt from the RS-422 specification (TIA/EIA-422-B).

The maximum permissible length of cable separating the generator and the load is a function of data signaling rate and is influenced by the tolerable signal distortion, the amount of longitudinally coupled noise and ground potential differences introduced between the generator and the load circuit commons as well as by cable balance.   Increasing the physical separation and the interconnecting cable length between the generator and the load interface points increases exposure to common mode noise, signal distortion, and the effects of cable imbalance.  Accordingly, users are advised to restrict cable length to a minimum, consistent with the generator-load physical separation requirements.

The curve of cable length versus data signaling rate given in figure A.1 may be used as a conservative guide. This curve is based upon empirical data using a 24 AWG, copper conductor, unshielded twisted-pair telephone cable with a shunt capacitance of 52.5 pF/meter (16 pF/foot) terminated in a 100 Ohm resistive load.  The cable length restriction shown by the curve is based upon assumed load signal quality requirements of:

a. Signal rise and fall times equal to or less than, one-half unit interval at the applicable data switching rate.

b. A maximum voltage loss between generator and load of 66%

At the higher data signaling rates (90 kbit/s to 10 Mbit/s), the sloping portion of the curve shows the cable length limitation established by the assumed signal rise and fall time requirements.  As the data signaling rate is reduced below 90 kbit/s, the cable length has been limited at 1200 meters (4000 feet) by the assumed maximum allowable 66% signal loss.

When generators are supplying symmetrical signals to clock leads, the period of the clock, rather than the unit interval of the clock waveform, shall be used to determine the maximum cable lengths (e.g., though the clock rate is twice the data rate, the same maximum cable length limits apply).

The user is cautioned that the curve given in figure A.1 does not account for cable imbalance, or common mode noise beyond the limits specified that may be introduced between the generator and the load by exceptionally long cables.

On the other hand, while signal quality degradation within the bounds of figure A.1 will ensure a zero crossing ambiguity of less than 0.5 unit interval, many applications can tolerate greater timing and amplitude distortion.  Thus, correspondingly greater cable length may be employed than those indicated.  Experience has shown that, in most practical cases, the operating distance at lower data rates signaling rates may be extended to several kilometers.

Cables having characteristics different from the twisted pair 24 AWG, 52.5 pF/meter (16 pF/foot), can also be employed within in bounds of figure A.1.  First, determine the absolute loop resistance and capacitance values of the typical 24 AWG cable provided by the cable length associated with the data signaling rate desired from figure A.1.  Then convert those values to equivalent lengths of the cable actually used.  For example, longer distances would be possible when using 19 AWG, while shorter distances would be necessary for 28 AWG.

The type and length of the cable used must be capable of maintaining the necessary signal quality needed for the particular application. Furthermore, the cable balance must be such as to maintain acceptable crosstalk levels, both generated and received.

asyncpci335_2010_02_02

To start we need to grab a few packages.

su -c 'yum groupinstall "Development Tools" ncurses-devel #'

Now make sure you are not logged in as root and run these commands to setup a directory tree to build the kernel.

cd
mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
echo '%_topdir %(echo $HOME)/rpmbuild' > .rpmmacros

Now we need to get the kernel source code to patch. To do this we use a command like this and edit it to use the specific kernel we wou like to use. You can browse here http://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/ for more options. This line might take awhile since it is downloading an ~50mb file first.

rpm -i kernel-2.6.18-8.el5.src.rpm

Next up lets unpack the source code and get it ready to go.

cd ~/rpmbuild/SPECS
rpmbuild -bp --target=`uname -m` kernel-2.6.spec

Now we configure the kernel to do everything we need.

cd ~/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.<arch>
cp /boot/config-2.6.18-8.el5 .config
make oldconfig

Edit the .config file we just copied to the current directory and modify the line CONFIG_SERIAL_8250_RUNTIME_UARTS to something higher than 4.

CONFIG_SERIAL_8250_RUNTIME_UARTS=8

Add this line as the first line in the .config file.

# i386

Now replace an existing config file with the one we just modified. Then move all of the config files over to the SOURCES directory.

cp .config configs/kernel-2.6.18-i686.config
cp configs/* ~/rpmbuild/SOURCES

We need to copy our patch file into the ~/rpmbuild/SOURCES/ directory so it gets applied during the build.

cp commtech.patch ~/rpmbuild/SOURCES/commtech.patch

Change directories.
cd ~/rpmbuild/SPECS/

Open up the kernel-2.6.spec file and modify this line so it looks like this. This way we can tell the which kernel is which when we are done.
%define release 8%{?dist}.commtech

Then at line 913 add this line.
Patch40000: commtech.patch

Then at line 1985 add this line.
%patch40000 -p1

Build time. This step takes forever so I wouldn’t wait and watch. NOTE: Real early in the build process there is a problem with our patch that makes us manually specify the file that needs patched. So when it asks which file you need to say this line with your username and arch.
/home/<username>rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.<arch>/drivers/serial

rpmbuild --with baseonly -bb --target=`uname -m` kernel-2.6.spec

Finally the build is done and all you have left to do it install the
kernel and reboot. Just double click on the RPM file of your choosing
in the ~/rpmbuild/RPMS/ directory and follow the install prompt.

06/24/2009 -  LInux

• Added more patch files for kernel 2.6 compiles
• Updated the loop.c example program

12/05/2008 – Linux

• Added RTSCTS IOCTL call

asyncpci335_2009_06_24

Here is a guide for patching the Linux kernel in Fedora 8 so that the Commtech boards will be detected.

To start we need to make sure we have all the tools we need for obtaining and building the kernel.


su -c 'yum install yum-utils rpm-build m4 make gcc redhat-rpm-config rpmdevtools ncurses-devel'


Now that we have all the tools we need, we run another command that sets up some directories for usage.


rpmdev-setuptree


Now everything should be setup the way we want it. So we download the kernel source code.


yumdownloader --source kernel
su -c 'yum-builddep kernel-<version>.src.rpm'
rpm -Uvh kernel-<version>.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -bp --target=`uname -m` kernel.spec


The kernel source code we are going to use is now located in


~/rpmbuild/BUILD/kernel-<version>/


We are about ready to build, but before we do we need to put together a config file. In the configs folder is some you should probably use. Pick one and cp it to .config


cp configs/kernel-2.<version>-<arch>.config .config


Before we start to build the kernel we need to tweak the .config file so that it allows for enough UART ports. So modify .config and change the CONFIG_SERIAL_8250_RUNTIME_UARTS line to something higher like 8.


gedit .config


Then copy it over to help out the build process.


cp .config ~/rpmbuild/SOURCES/config-<arch>


Lets apply the patch then we will be ready to build.


patch -p0 < ../fastcom_async_pci_serial_patch_2.6.24.hardy


Now finally we get to actually build the kernel. It takes forever so go do something else for awhile.


cd ~/rpmbuild/SPECS/
rpmbuild --with baseonly -bb --target=`uname -m` kernel.spec


Finally the build is done and all you have left to do it install the kernel and reboot. Just double click on the RPM file of your choosing in the ~/rpmbuild/RPMS/ directory and follow the install prompt.

cp .config ~/rpmbuild/SOURCES/config-$arc

This new release just includes a couple of new kernel patch files to install in a 2.6 kernel source tree.  The two patches work for the default Ubuntu Gutsy and Hardy kernels (that would be 2.6.22 and 2.6.24 respectively).

Get the new driver package here: asyncpci335_2008_05_07

Exactly how does one apply the kernel patch for a Fastcom:FSCC, 232/4-PCI-335, 422/2-PCI-335 or 422/4-PCI into a Ubuntu Linux 7.10 (Gutsy) kernel?

Funny you should ask. The steps below are based largely on the howto on the Ubuntu help pages.

To start, you will need to install a few packages:

sudo apt-get install linux-kernel-devel fakeroot build-essential

The you need to get the kernel source. The simplest way, useful to those who want to rebuild the standard Ubuntu packages with additional patches is:

apt-get source linux-image-`uname -r` (that is a tick mark, it is the symbol on the key with the ~)
apt-get build-dep linux-image-`uname -r`

Now I want to apply my kernel patch of choice. For this example I will use the 2.6.22 kernel and associated patch.

cd linux-source-2.6.22-2.6.22
patch -p0 < fastcom_async_pci_serial_patch_2.6.22.gutsy

Now I copy my current config to the appropriate source config directory. Obviously I am using i386 and generic, you may be using something different.

cp /boot/config-2.6.22-14-generic debian/config/i386/config

You will want to change one entry in the config file before you proceed. You want to change the number of runtime UARTs to at least 8 (more if you are using multiple cards).

vi debian/config/i386/config
CONFIG_SERIAL_8250_RUNTIME_UARTS=8

Then to update the configs, run this:

sudo chmod 755 debian/scripts/misc/splitconfig.pl
sudo chmod 755 debian/scripts/misc/oldconfig
debian/scripts/misc/oldconfig ARCH (replacing ARCH with your architecture i.e. i386, etc)

Now it is time to compile! To build a specific target, use this command:

AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-FLAVOUR

Where FLAVOUR is one of the main flavours of the kernel (e.g. generic).

Relax. Have a cigar – this will take a little while.

When it finishes the newly created deb packages will be in the parent directory. To install them:

sudo dpkg -i linux-image-2.6.22-14-generic_2.6.22-14.47_i386.deb
sudo dpkg -i linux-headers-2.6.22-14-generic_2.6.22-14.47_i386.deb

Then reboot into your new kernel. That’s it.