Commtech's Fastcom Product Support Blog

04/27/2012 – LabVIEW

• Commtech is pleased to announce the initial release of our FSCC Family instrument driver for National Instrument’s LabVIEW.

I may have missed posting a few software updates here and there, so here is a bit of a rollup:

09/21/2011 – Lnux_v1

• Add fc-async module to the async code and removed the bits about patching  the kernel for 2.6 and up.

09/15/2011 – Linux_v2

• Fix build errors caused by new kernel requirements. init_MUTEX(x) removed in 2.6.37

09/14/2011 – Linux_v1

• Fix build warnings and errors caused by new kernel requirements.  This   has been tested to build up to kernel 3.0

07/11/2011 – Windows

• Modify behavior of Isosync mode to prevent system hang when large number of   interrupts occur on a modem control line.  Please enable Isosync mode as boot  default, then reboot before connecting external clock signal.

05/19/2011 – Windows

• Driver version 1.0.0.94 – basically just a recompile to fix some previous build errors  Including update fscc_basic_settings with tooltips and new boards recognized  Signing all drivers

03/14/2011 – Windows

• Had to update the fscc.cat file to allow installation in win7-64

fscc_2011_09_21

Version 2.1.2 (09/14/2011)

• Fix build error with kernels 2.6.37 and up
• Fix problem with SuperFSCC/4-LVDS installation
• See changesets for full list of changes

http://hg.commtech-fastcom.com/fscc-linux/downloads

Version 2.1.0 (05/02/2011)

• Fix comments in code
• Add make help target
• Migrate from google code to bitbucket
• Added code and examples for various transmit modes
• Fixed dma insmod parameter
• Add SuperFSCC-LVDS and SuperFSCC/104 to the driver
• See changesets for full list of changes

http://hg.commtech-fastcom.com/fscc-linux/downloads

01/05/2011

• Update writereg example program.  It was incorrectly checking the return variable of deviceIoControl() for information.  This will resolve any issues that you may see with IOCTL_FSCCDRV_WRITE_REGISTER saying that it failed when it really passed.
• Fix line endings on Visual Studio project files and .txt files on the CD

12/29/2010

• New linux code that will fix build errors on newer kernels.

fscc_2011_01_06

asyncpci335_2010_09_23.zip

esccp335_2010_09_23.zip

08/19/2010 – Windows

• Add installer to the Windows 7 32-bit driver.
• Added in the Windows 7 (64 bit) driver with installer.
• Added SET_PROGBITS and GET_PROGBITS and associated example programs
• Modified Sync driver to remove an errant DbgPrint that was causing some BSOD on some customers’ systems.

- Linux

• Add most recent driver that includes the bridged PCIe boards

fscc_2010_09_23.zip

Download here: fscc_2010_04_02

fscc_2010_03_12

fscc_2010_02_02.zip

asyncpci_2010_02_02.zip

asyncpci335_2010_02_02

fscc_2009_12_23

This is the second recent firmware update to the FCore.

• FSCC Family = FCore version 9.09
• SuperFSCC Family = FCore version 4.11

This fixes another small bug in XSync mode.  If you turned on zero or one insertion in XSync mode, it was not only doing the insertion to the data or payload (intended) but it was also bit insertion the opening and closing flags (bug).  This prevented (for example) correctly being able to receive and transmit HDLC frames while in XSync mode as it would bit-stuff the opening HDLC flag.  In this example the HDLC flag 0x7E (0111 1110) would end up getting bit stuffed and would end up like this:  0111 1101 0.

This bug would have affected anyone who had a sync or term character that had 5 or more contiguous one bits (like: 0xFF or 0x3E).

Note: as of the date of this post, this is considered the current, shipping firmware unless otherwise noted.

There have been a couple of firmware updated since I last posted.  Here the first one.

• FSCC family = FCore version 9.08
• SuperFSCC family = FCore version 4.10

This is a fix to a bug discovered by our good friend Al.  Thanks Al.

The problem is with XSync mode when you have what I’m calling a “double” termination character.  That is any termination character that is a double byte (i.e. 0xAA, 0×22, 0xFF, etc).  If the last byte of your data’s upper nibble matches the byte of your “double” termination character, then you will lose it.

Example:

Data = 0×12345678

Termination = 0×77

The data is put on the line LSB first and so the 7 in the last byte of data will be accidentally taken to be the first byte of the termination character.

It is still possible to induce this problem if you try to enable zero/one insertion while you are using a double termination byte.  We would have to redesign major portions of the receive state machine to make it work with zero/one insertion as well.

We have only had one person report this problem, so chances are that most of you aren’t affected by this bug, but we fixed it anyway.

09/23/2009 – Linux

• Fix request_irq() to stop using deprecated SA_INTERRUPT and SA_SHIRQ flags.
• I can also confirm that this driver installs and runs in OpenSuse 11.0.

esccpcmcia_2009_09_23

07/20/2009 - Windows

• Added IOCTL call to Async module to allow reading of auto hardware RTS & CTS flow control
• Making settings tab able to read the hardware flow control
• Created example application to show how to use the set/get hardware flow control

fscc_2009_07_20.zip

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

06/24/2009 - Windows

• Added updated firmware for FSCC/232
• Modified basic_settings GUI so that the CRC is changable in HDLC mode

06/24/2009 - Linux

• Added new device IDs
• Bug fixes for new kernel revs
• New patch files for async mode

05/06/2009 - Windows

• Added IOCTL call to Async module to allow setting of auto hardware RTS & CTS flow control

03/16/2009 - Windows

• Modified installation files to recognize new SuperFSCC/4 firmware revision 14.0D

fscc_2009_06_24