Many users of the FSCC experience the situation where either one of the example programs and utilities returns with an error “Device or Resource busy.”
The likely cause (if we are talking about an FSCC card specifically) is that you performed an operation on the transmitter or receiver and there is not a valid transmit or receive clock present. One example of an instance in which this can happen is if you configure the card to operate in a mode with an external receive clock (i.e. clock mode 1) and there is not a valid clock present on the RxClkIn pins and then you try to issue a command to the receiver (i.e. a HUNT or RESET command).
Basically what happens is that the command is sent to the card and it never completes. This can be verified by reading the status of the command executing bit. If it is a 1, then there is a command waiting to be executed (when a clock shows up). This can be remedied by momentarily switching to a mode that uses internal clocking (i.e. 7). It can be prevented by never issuing a receive command if there is a chance that you don’t have a receive clock.
NOTE: all of the above can also pertain to the transmitter as well, if you issue a transmit command and you don’t have a transmit clock, the same situation will occur.
October 17th, 2008 in
FSCC,
Linux |
2 Comments
While LabView/LabWindows are not fully supported environments at this time, circumstances have led us to run the evaluation package of LabWnidows/CVI and the results of that eval follow.
While none of what follows includes any of the “nifty” features of LabWindows, it does demonstrate that it is possible to touch/use our hardware in that environment. Perhaps not in the manner that LabWindows users are accustomed, but not having much familiarity with that environment my main goal was to determine if it was possible to use our products “at all”.
The following method should work with any of our products as long as the base underlying system is Windows (and not one of the real-time variants of LabWindows). It is quite possible and straightforward to use any of our example code directly in CVI, all that is necessary is to add a ‘#include “windows.h”‘ to the top of the C file that contains the Win32API function calls. Since most of the driver interface to our cards relies on the basic Win32 Functions:
CreateFile()
DeviceIoControl()
ReadFile()
WriteFile()
CloseHandle()
Using these functions in LabWIndows/CVI is fairly straightforward.
If for whatever reason it is not possible to include the windows header file, (or include the windows dll’s that back those functions) in your project. You can use the fscctoolbox dll to interface to the driver without using the win32 functions directly. They are of course used by the toolbox dll, but using the toolbox you can just include the toolbox and not have to include all of the windows functionality that is exported by windows.h.
To do this you simply add the fscctoolbox.lib to your project, and then call the functions in the toolbox to open/configure/read/write to the card.
September 25th, 2008 in
FSCC |
No Comments
This is a pretty unexciting update. This just contains a couple of code updates to fix a couple of errors and warnings when building the Linux module in newer 2.6 kernels.
esccp335_2008_09_25
Several people have been asking this question lately, so I decided it probably needed a blog post.
First of all, we all need to know that 9-bit operation is only possible when operating in Async mode (e.g. you are using the onboard UARTs).
There are basically two modes of operation of 9-bit mode on the FSCC. The first is the traditional 9-bit mode that is something this:
From the article titled Use the PC’s UART with 9-bit Protocols found here
A typical system for distributed monitoring and/or control consists of a multidrop network—a PC acts as the host and communicates with 8-bit microcontrollers acting as slaves (see the figure). Usually, the physical layer of such a network is based on the RS-485 standard, while the logical layer is a commercial or user-defined protocol. In either case there’s an address byte within the transmitted frame that identifies the target slave device.
With early-generation microcontrollers, all slaves had to search for this address byte within the frame to determine whether the frame was addressed to them. This meant that every slave in the network had to be interrupted by every byte being transmitted, wasting the slaves’ precious CPU processing time.
Later microcontrollers, like Motorola’s 68HC05C8 or Intel’s 8051, implemented their serial port with a special mode for multiprocessor communications. In this mode, 9 bits are received. The 9th bit goes to a special register. The serial port can be configured to activate the serial-port interrupt, depending on the state (i.e., a logical one) of the 9th bit.
When the master wants to transmit a block of data to one of several slaves, it first sends out an address byte that identifies the target slave. An address byte has its 9th bit set, while a data byte has it cleared. Because of this bit state, the address byte will interrupt all slaves. Each one examines the received byte and see if it’s being addressed.
The addressed slave will activate the serial port interrupt (ignoring the 9th bit state of successive bytes) to receive the data following the address byte. The non-addressed slaves will continue with their program, ignoring the incoming data bytes until a new address byte interrupts them, minimizing wasted CPU processing time.
Turning the transmitter into the Master as described above can be accomplished by simply checking the box in the FastcomSerialSettings tab of the Async port’s property page that says “9-bit mode.” The driver and hardware will automatically append the ninth address bit to the first byte of the outgoing data block.
To receive the 9th bit is a little different. You need to check both the “9-bit mode” and “9-bit receive” boxes and you will then receive 2 bytes of data for every received character. You will get The 9th bit as the first byte of your received data and the second byte will be your actual data byte. If the first byte is an 0×00, then the 9th bit was not set and if the first byte is an 0×01, then the 9th bit was set.
******************************
The second mode of 9-bit operation on the FSCC is what can best be described as arbitrary 9-bit data. Where you can simply use your code to send 9-bit data that does not have to be the first byte of a block of data.
To have arbitrary 9 bit data flow through the port you need to check all three 9 bit checkboxes (9-bit transmit, 9-bit receive, and 9-bit mode). Once you do that the ReadFile and WriteFile functions will expect to have even numbers of bytes requested for send/receive (you will receive 2 bytes for every 9bit character received, and it will take two bytes to transmit one 9 bit character). In both directions the first byte is the 9th bit (either a 0×00 or an 0×01), and the second byte is the rest of the 9 bit character (bits 0-7).
So for example, to send three bytes 0×055,0×155,0×055 (three 9 bit characters the first and third with the 9th bit clear, the second with the 9th bit set) you would construct a character array that is :
data[0] = 0×00;
data[1] = 0×55;
data[2] = 0×01;
data[3] = 0×55;
data[4] = 0×00;
data[5] = 0×55;
and send it as:
WriteFile(hPort,&data[0],6,&bytesout,NULL);
The receive direction is the same way, if you transmit the above and loop it back it will be received as:
t = ReadFile(hPort,rxbuf,6,&temp,NULL);
and the rxbuf array will contain:
rxbuf[0] = 0×00;
rxbuf[1] = 0×55;
rxbuf[2] = 0×01;
rxbuf[3] = 0×55;
rxbuf[4] = 0×00;
rxbuf[5] = 0×55;
You always want to have the nNumberOfBytesToRead value of readfile be an even number as you will always receive 2 bytes for each character that is received off of the line. In the same way you will always want to
make nNumberOfBytesToWrite of WriteFile be an even number as it takes 2 bytes for each character that is transmitted.
Piece of cake, right?
August 19th, 2008 in
FSCC |
No Comments
Many users of the FSCC experience the situation where either one of the example programs and utilities returns with an error 0×57 or their own program returns with an error 0×57.
In a Windows environment, the error code 0×57 is an ERROR_INVALID_PARAMETER which translates to “The parameter is incorrect. “ In this case, this wonderfully informative message means that something about a DeviceIoControl that has gone wrong.
On the FSCC there are basically two things that could cause this error message to occur:
- First (and easiest to fix) it could simply mean that you have performed the DeviceIoControl wrong; i.e. it expected a DWORD variable and you passed it an int.
- The second possibility (if we are talking about an FSCC card specifically) is that you performed an operation on the transmitter or receiver and there is not a valid transmit or receive clock present. One example of an instance in which this can happen is if you configure the card to operate in a mode with an external receive clock (i.e. clock mode 1) and there is not a valid clock present on the RxClkIn pins and then you try to issue a command to the receiver (i.e. a HUNT or RESET command). Basically what happens is that the command is sent to the card and it never completes. This can be verified by reading the status of the command executing bit. If it is a 1, then there is a command waiting to be executed (when a clock shows up). This can be remedied by momentarily switching to a mode that uses internal clocking (i.e. 7). It can be prevented by never issuing a receive command if there is a chance that you don’t have a receive clock.
NOTE: all of the above can also pertain to the transmitter as well, if you issue a transmit command and you don’t have a transmit clock, the same situation will occur.
Also NOTE that this same problem can crop up in a Linux environment, but the problem will be reported as a “device busy” error.
Matt Schulte
July 30th, 2008 in
FSCC |
No Comments
Another mass update blog post, though not so many this time:
- 6/13/2008 - Windows
Added support for external trigger and extended trigger modes of the SuperFSCC-104-ET (Firmware rev 04.0A)
Add FSCCToolbox DLL example code
- 6/9/2008 - Windows
Added 9bit receive mode, returns 2 bytes for each received character (all 9 bits)
- 5/30/2008 - Linux
Added monolithic external transmit example.
- 5/20/2008 - Windows/linux
Fixing transmit queuing code. The fix has been fixed…Differences in the DMA vs IRQ driven sections of the code required different handling. Fixing one broke the other. This update should make both types operate properly.
- 5/19/2008 - Linux
Fixing tx queuing (again)
Adding in external transmit example
fscc_2008_06_13
This update is a reorganization of interrupt handling for the AMCC to in the Windows driver to make interrupt latchup less likely. If you are not experiencing problems, you probably won’t notice much of a difference. However, this update does make the driver more robust for everyone.
esccp_2008_06_13
This new software release contains an updated Linux driver. This update fixes a number of build warnings that cropped up in later 2.6 kernel versions. Hopefully it will compile cleanly for a while.
escc_2008_06_13
An interesting application has crossed my desk, and it is worthy of an entry.
The problem was that it was desired to have an ASYNC port send out data using the transmit by timer mode of the Fcore.
Unfortunately the Fcore and the ASYNC section are not really connected. The ASYNC section is currently a physical UART (OX16C950) and as such has no method by which we can implement a transmit by timer function in hardware. (It is still possible to configure the sync port to generate timer interrupts and transmit out the COMx port when they happen, but doing so will not give timing down to (microseconds). )
The solution to this problem was to create code that will convert the binary data to be transmitted into ASYNC formatted data. Then pump this binary stream out of the SYNC port using the transmit by timer function (with the port configured as transparent (raw bits)). Using this method it is possible to transmit ASYNC formatted data at a given rate with very low jitter.
It is a requirement that you select Transparent mode operation, and MSB first data transmission. The rest of the FSCC port settings are user definable. Note that this is only a solution to transmit ASYNC data, it is not easily receivable in this manner.
As an example if you have the settings file ‘timedasyncset’ defined as:
fifot = 0×08001000
cmdr = 0×08020000
ccr0 = 0×0250001e
ccr1 = 0×04006008
ccr2 = 0×00000000
bgr = 0×0000009f
ssr = 0×0000007e
smr = 0×00000000
tsr = 0×0000007e
tmr = 0×00000000
rar = 0×00000000
ramr = 0×00000000
ppr = 0×00000000
tcr = 0×0028b0a3
imr = 0×0f000101
n_rbufs = 0xa
n_rfsize_max = 0×1000
n_tbufs = 0×64
n_tfsize_max = 0×1000
you can then configure the port and transmit a file out the port in 5 character blocks at a rate of 100 blocks a second by importing the above settings file into the control panel applet, selecting the CMDR register setting and clicking the “TXT -Transmit by timer” checkbox so that it is checked. click OK. Make sure that the clock setting is 18432000 (18.432MHz). This will set the bitrate at 115200 (as per the settings above). Click OK to enforce the settings. After the settings are set, go back into the port settings, and click the CMDR dialog. Cilck the button that is “TIMR -Start timer”. then cancel the CMDR dialog, and cancel the settings. (this starts up the timer, but after the port is configured).
Then convert your data from (binary/ascii) to the async formatted data as:
convert2async datafilein N81 datafileout.bin
and send the data out the port as:
sendfile 0 5 datafileout.bin
The data should then go out the port in 5 character blocks at a rate of 1 every 10mS.
Note that the rate is controlled by the timer setting TCR. In the above example the timer was set to periodic mode using the PCI clock as the source, with a 10mS timeout (333333/33333333) (which assumes a 33MHz PCI clock). You can set different frame rates by modifying the timer value and/or source.
convert2async
May 30th, 2008 in
FSCC |
No Comments
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
This software update includes:
Windows:
Updates to merge code changes to fix various Serocco issues,
Added wait for CEC after flush to prevent data loss on a write immediatly following a flushtx
Download the new software package here: gscc_2008_05_07.zip
This new software release includes these new features:
- 01/07/2008 - Linux
-updated with mods for 10 board install on centos
-update pty to allow flush on devnode (without exiting)
- modify driver to handle xdu as flush, update so 2.4 threading operates
- 05/07/2008 - Linux:
-Fixed up various PCI nasties to make the driver compile in kernels at around 2.6.24
This new driver can be found here: superfastcom_2008_05_07.zip
Ok, so I admit to not having posted to the blog for a FSCC releases. I’m sorry, but here is what has happened up to today’s release:
- 10/25/2007 - Windows
Fixes fix from 10/18…It seems the fix for 2000 broke xp.
Added 1x bitclock output on DTR feature (async).
- 12/6/2007 - Windows
Update for FSCC-232 so clock setting will work correctly
- 1/18/2008 - Linux
Update to allow poll/select to work with DMA, and status.
Warning removal against 2.6 builds.
Fixed readreg example for x64 builds.
- 1/18/2008 - Windows
Update to fix time/performance of writes with very large #buffers defined
- 2/8/2008 - Windows
Fixed BSOD on multiple iterations of dma/irq mode switch.
Fixed interrupt driven issue with write framesize >4k (>n_tfsize_max setting)
Attempt at fixing random/sporadic BSOD on configuration
- 2/13/2008 - Linux/Windows
The fix for large numbers of small frames broke transmit queuing. Transmit queue works as expected now.
- 2/13/2008 - Windows
Added/changed CMDR dialog in the settings/control pannel app to toggle driver ioctls instead of touching bits in CMDR that shouldn’t be touched via settings.
Updated settings/control panel app to correctly handle hitting return after modifying a value (in most dialogs). Previously the edit would be lost, now the edit is taken as complete.
Enforce clipping of clock frequency to 50MHz for ASYNC driver. (when using the property page)
Added ioctls to return driver state of (transmit by timer, transmit by external, transmit repeat)
- 3/5/2008 - Windows
Fixing interport SMP timing issues in async driver.
Manifstation as “port cannot open”, or system event “hardware failure” on serial port, or port will not transmit, followd by either of the others. Version 1.0.0.71 should take care of these issues.
- 3/10/2008 - Linux
Cleaning up the PPP example programs
- 3/24/2008 - Windows
Feature control register multi-port synchronization issue resolved.
- 4/28/2008 - Windows
Fixing transmit queuing code. Has been broken since the 1/18 update, and only allowed for the use of the hardware FIFO. Now it uses both the hardware FIFO and the defined n_tbufs buffers for frame buffering as intended.
- 5/07/2008 - Linux
Added a new patch for the Async kernel driver that works against the default Ubuntu Hardy Heron kernel source package (2.6.24.something)
There, that wasn’t so bad, was it?
The new software can be found here: fscc_2008_05_07.zip
This driver features a fixup for contention between setup ioctl and dpc threads that has the potential to cause BSOD’s.
Download here
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 makedumpfile
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 < fastcom_async_pci_serial_patch_2.6.22.gutsy
patch -p0
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.
December 20th, 2007 in
Async-335,
FSCC,
Linux |
3 Comments
The Fastcom:FSCC dpll has a few quirks. Revisions of the firmware prior to rev 4 operate in such a way that it requires
edges in the data all the time. Particularly including when the initialization (RRES) command is issued. If there are not edges when this command is executed, then when the first edge comes in, the RRES command will execute as a result of it, and that byte will be lost, (usually resulting in a lost frame). After this reset the first edge will phase align the internal receive clock correctly to the data. Unfortunately if the edges are not present (say in between frames, or on a RS-485 link) subsequent frames will phase align in an adjustment manner instead of aligning to the first edge and adjusting for subsequent edges. (ie the DPLL has no concept of “frames” and does not know when one ends and another begins).
The end result of all this is that data is sporadically received correctly, or dropped, depending on the relative phase drift between the transmitter and receive clock.
Revision 4 of the FCORE firmware attempts to correct these issues. The requirement for edges during initialization is removed, as an internal clock will supply edges in the absence of edges in the receive data stream. Also the dpll is forced into a seek mode (snap to first edge) if more than 32 receive clocks elapse without an edge in the data. Practically this will allow for proper operation and lock on to gapped frames with no edges between them. And currently the only downside is that you cannot send more than 4 bytes of 0×00’s in a row (assuming NRZ encoding, and no one insertion). If you do you will likely get an extra bit clocked in as the DPLL resets at the end of the zero sequence (ie at the next edge). The current implementation will insert an extra bit at the beginning of any given frame sequence (either an extra zero or one depending on the relative phase of the free running internal receive clock and the first edge in the data) This should not present any problems for HDLC modes, or any mode that uses a synchronization sequence (Xsync, or FSR gated receive) and will only cause difficulty in Transparent mode when no beginning sync is used. It is not recommended to use this combination. (continuous receive in transparent mode with the DPLL, with long sequences of 1’s or 0’s with NRZ line encoding).
The number of clock edges before the DPLL is considered out of sync is now configurable in a register (0×58) the DPLL RESET register. It may have a value from 1 to 511 and is the number of clocks without an edge that the DPLL will consider OK, more clocks than this and it will snap to the next edge (with the possibility of the extra bit being clocked in as described above). The number set is in 8 clock increments, so a value of 1 is 8 clocks, 2 16 clocks, etc. The default value is 4, which yields 32 clocks as described above.
Note that it is currently possible for the DPLLA bit/status to not be telling the whole truth. With all revisions of firmware the DPLLA status is only updated when an edge occurs and the clock phase is out of the window (as described in the manual). As a result, a long sequence of no edges will not give a DPLLA indication until the next edge occurs. This behavior will likely be updated in a future firmware release, as currently the information that it provides is not very useful.
December 20th, 2007 in
FSCC |
No Comments
Actually, the problem once found has little to do with the CRC specifically. However the manifestation of the problem is when the very last sequence of transmitted data is 5 ones (which should cause a 0 insertion) that particular zero insertion does not occur. The ending sync sequence or flag will be transmitted immediately after the 5 ones, and as such will be received incorrectly by a non FSCC serial controller. The fact that the FSCC will receive its own frames correctly indicates that the receiver probably needs adjusting as well (not done at this point). The purpose of this post is to make notification that when sending any frame (HDLC or X-SYNC) that ends in a five 1’s pattern, the resultant frame on the line will be incorrect. The receiving station will likely receive all of the data for the frame correctly, but indicate that it has a bad CRC, or perhaps end the frame as an aborted frame. This behavior is corrected on FCORE revision 6.3 for the FSCC, and revision 4 for the SuperFSCC.
As a result of tracking this down, it has come to our attention that HDLC mode forces a number of parameters that are inconvenient. Specifically, the CRC method and reset level settings. In revisions prior to those mentioned above, when HDLC mode is selected the CRC-CCITT polynomial and a reset level of all 1’s (0xffff) is forced. The latest firmware releases these to be what the user selects in the CCRx registers. To maintain identical behavior you must ensure that you set the CRC type and reset level bits in the configuration registers to be CRC-CCITT and reset as all 1’s!
Also the zero/one insertion is known to not operate at all in transparent mode, or when transmitting preambles/postambles, flags, or sync sequences. The zero/one insertion should operate in all modes as of the firmware revision listed above. Preambles/postambles/flags/ and sync sequences are still excluded from insertion.
It is known that when using X-SYNC to simulate HDLC mode, the one thing that cannot be accomplished is the abort sequence. (the 7 1’s on the line causing a frame abort) does not happen in X-SYNC mode.
December 20th, 2007 in
FSCC |
No Comments
Note: This is written in respect to Windows and the Windows driver. If you are using Linux, as an abstract the flow is pretty much the same.
Technically there are two buffers involved in transmitting data with an FSCC, software and hardware.
The hardware buffer can have a maximum of 256 frames queued up in its TxFIFO. The TxFIFO is 4096 bytes deep, so you can have 1 single 4096 byte frame in the TxFIFO or you could have 256 1-byte frames in the TxFIFO. Both of these would make the driver consider the TxFIFO to be full.
The software buffer is the number of buffers that you have defined, which we can say is limited only by the amount of memory you want to allocate to it. So let’s say that you want to allocate a second’s worth of software buffers for 16 byte writes @ 400Hz requires 400 buffers (assuming 1 data frame per buffer). First we would want to make the size of a single transmit buffer (n_tfsize_max) = 16 bytes (allocate on dword boundaries and consider 16 bytes to be your minimum). Then we would allocate the number of transmit buffers (n_tbufs) = 400. This will give you 6.4k of memory as your buffers. The actual amount of memory used will be greater because each buffer requires some overhead. Call it 6 DWORDs per buffer of overhead. In this example, that gives you 9.6k of overhead for a grand total of around 16k of allocated memory.
When you issue a WriteFile command, the data (frame) goes into a software transmit buffer. When the driver sees that there is data, it takes the data out of the buffer and pushes it into the TxFIFO where it is immediately ready to be transmitted on the next clock.
If we take a worst case scenario where there is no clock, you will be able to issue 256 16-byte WriteFiles before the TxFIFO becomes full. When the TxFIFO becomes full, the driver will stop pulling data out of the software transmit buffers. The rest of your WriteFiles will begin to queue up in the software buffer. When you have issued 400 more WriteFiles, your software transmit buffer will become full and the next WriteFile will block with an ERROR_IO_PENDING. As soon as a clock is applied, data will begin to flow.
There are a couple of things to note:
This is a simplified description of what is going on. Actually there will be a sort of give and take while your app tries to keep the software buffer full and the driver tries to keep the software buffer empty. If you can keep up and make sure that the buffer, and as a result TxFIFO, never go empty you will not have any gaps in your data.
Also, you will make much greater use of your resources if can send larger chunks of data at a time. A 16 byte frame is very small and if you are able to go larger, you should do so.
Clear as mud?
November 29th, 2007 in
FSCC |
No Comments
Fixing the fix.
The fix for the W2K BSOD’s happening due to the clock setting function being called at a raised IRQL (well, not passive at any rate) was to just not set the clock if irql!=passive. It seems that (somewhat randomly) the opening of the com port will go through the create routine at APC_LEVEL…so fixing the fix. Second whack at it. The clock will be set now, it gets done by a worker thread at passive IRQL spawned at create/open time. If the work queue item cannot be created the open will fail. This will at least make the clock be what it is supposed to be, or let you know if it couldn’t do it. (I noticed the problem while debugging the new bitclock output on DTR function) and it would manifest by sometimes the clock would set, sometimes not. The port would open fine, but the data rate output was just not right sometimes.
1x (bitclock) output on DTR function added. IOCTL_SERIALP_SET_CLK1XDTR was added to the serial driver. When called passing a 1 (see fsccset1xdtr.c) will configure the 16C950 to output the bitclock on the DTR signal. This feature is incompatible with the isosync setting. And calling the isosync set DeviceIoControl (either directly, or using the control panel settings applet) will revert the setting. If you configure the registry entry to enable the 1xclock output on dtr it will override the isosync setting (either on or off). But the last called ioctl function (either set isosync, or set 1xdtr) will determine the current function.
fsccset1xdtr
October 25th, 2007 in
FSCC |
No Comments
This new release doesn’t have any changes to the driver or software for the ESCC-PCMCIA. This new release only contains the 02Mod.zip file that is a custom driver for card with the -02 modification. If you don’t have the -02 modification, you don’t need this new release.
Download it here: esccpcmcia_2007_10_19.zip
