Installing CCS Tools on PC

We use Custom Computer Services (CCS) software development tools to compile and build embedded programs that control the custom printed circuit boards in the lab. The PIC and SX microcontrollers are the main programmable units used to drive the circuit boards. The necessary CCS development tools can be found in DRBIO's ftp site under the directory called CCS_Compilers

Here's the installation guide for the CCS programs.

Lumencor RS232 Control

     The past few days, I’ve been working with Paul to write a C++ program to communication with the Aura Lumencor Light Engine via the computer’s RS-232 port. Warren provided a COMMDRV library (http://www.wcscnet.com/), which includes functions for RS-232 communication. The most critical functions for the project were ‘PutByte’ (which allows for the transfer of a single character), ‘OpenComPort’, ‘SetPortCharacteristics’ (to set baud rate, parity, stop bits and communication protocol) and ‘CloseComPort’. Since the Lumencor specification (http://www.lumencor.com/downloads/Aura%20TTL%20IF%20Doc.pdf) expresses byte sequences in hexadecimal, we used ‘PutByte’ to pass unsigned char’s represented as hex (e.g. unsigned char byte1 = 0xff). One issue that we ran into was that the program processed all the bytes and terminated much more quickly than the serial port could pass the data to the Light Engine. This led to the truncation of many of the commands. In order to correct for this, we added ‘Sleep’ commands so that the program would wait long enough to allow data transfer.

     A few notes on the COMMDRV library. In order to use the library functions, the cdrvhf32.lib and cdrvxf32.lib files must be included in the program. In addition, <comm.h> must be included and ‘MSWIN’, ‘MSWIN32’ and ‘MSWINDLL’ must be defined. The omission or incorrect placement of these declarations may lead to link errors; try to include them as early as possible in the program.

     One very useful tool for debugging RS-232 communication is a terminal emulator such as Hyperterminal or Realterm; I preferred the layout of the latter. By connecting two COM ports (whether on different computers or on the same computer) via a NULL MODEM cable, you can pass bytes and check to see how they are received on the other end; the NULL MODEM cable serves to cross the transmit and receive pins of the two RS-232 cables (so that receive(COM1) à transmit(COM2) and transmit(COM1)àreceive(COM2)). Note: NULL MODEM cables have the same pin structure as RS-232 cables and can come in various male / female configurations. Be sure to look for the NULL MODEM label!

     In order to create short hex files containing Lumencor commands, I used the HxD hex editor. The hex files could be dumped to the COM port using RealTerm.

PCI-1755 DAQ Tip

This PCI-based card manufactured by Advantech is the high speed 32-channel digital I/O device used for the multiphoton image acquisition system. It has an extra general-purpose 8-ch DI/O feature that comes in handy. However, make sure to flip the on-board 8-pin switches in order to designate individual pins DI or DO. This is something that is easily overlooked and caused confusion for me.

Project Build error in Visual Studio 2005

I came across the error "SignTool Error:ISignedCode::Sign returned error: 0x80880253 The signer's certificate is not valid for signing." when trying to build/publish my VB code in Visual Studio 2005. I know a few people in the lab also use VS2005, so I'm posting how to get around this error in case you come across the same thing.

The first time you publish your solution, VS creates a certificate that expires in one year. If you try to update your solution or re-publish over a year later, you will probably get the error mentioned above. Microsoft explains this problem and gives a fix for it here... http://support.microsoft.com/kb/925521

I did not get the Microsoft fix to work for me, but I was able to work around it as follows.
Go to Project -> Properties -> Signing Tab.
Click "Create Test Certificate"
Enter a password
Click "OK"

This doesn't exactly fix the problem, but it extends your certificate for another year so that you can publish your project.

FCS Bin Size - Board #1 (Revised)

The FCS counter board #1 (used by Phill Jones) has been re-flashed with updated firmware to allow one- or two-channel data acquisition mode.

The bin sizes for one-channel mode are 0.479 μs, 0.998 μs, 1.995 μs and 4.989 μs. For two-channel mode it's 0.818 μs, 0.998 μs, 1.995 μs and 4.989 μs.

FCS Bin Size - Board #2

New FCS hardware and firmware now provide the FCS application-level software the option of choosing one or two data channels. Lisa measured and verified the actual time bin sizes generated from the new board.

The bin sizes for one-channel mode are 0.4801 μs, 1.0002 μs, 2.0003 μs and 5.0007 μs. For two-channel mode, the values are 0.8201 μs, 1.0002 μs, 2.0003 μs and 5.0007 μs.

FCS Bin Size - Board #1

The FCS software provides four different user-selectable bin sizes. Nominally, the available bin sizes are 0.8 μs, 1 μs, 2 μs, and 5 μs. The actual bin sizes will be slightly different because of how they are calculated in the firmware. (I will go into more detail on this below.) In reality, the bin sizes used by the software are 0.818 μs, 0.998 μs, 1.995 μs, and 5.009 μs.

The FCS hardware is controlled with an SX48 microprocessor, and the different bin sizes are generated by adding or removing instruction cycles to the SX code. The SX uses a 50MHz crystal, so each instruction cycle is 20 ns. These actual bin sizes are the closest we could get to the ideal values given the 20 ns resolution. The code for the 0.818 μs bin size has no delay cycles added, so this is the smallest possible bin size.