It is not possible to do a reliable SAS interface with Windows API

[AndyP]

Ok folks, so I have spent a couple of weeks playing around with SAS protocol and 9 bit comms whilst waiting on approval for my next project. I was convinced that it was possible to make a reasonably reliable solution using just the windows API and not having to move into Windows Kernel land, but alas I now know better.

The problem is thus. When you send a SAS command, it uses a wake up bit. This needs to be set for the first byte, and cleared for subsequent bytes.

A general poll is a singe byte to the poll address of the machine, so I set the parity bit to emulate the wake up bit, send the general poll, then clear the parity bit. However, the serial driver in Windows does not set the parity immediately (it waits for an interrupt). Because of this delay, the parity bit does not get cleared immediately, but machine then sends back its response to the general poll immediately, and it has a parity error, so I can't determine if its a chirp or a poll response.

Now this method worked fine on the IGT machine I had before, but it does not work on the WMS machine, so its definitely timing issue that is specific to individual machines.

IF you are not worried about chirps, you can get away with this by not looking for parity errors, which is fine for home use but no good for commercial use (sorry guys). Unfortunately, I need something for commercial use.

[Foster]

What chirps are you worried about and why do they occur?
If it is the link broken or host not polling fast enough chirps then do these 2 things
1 if the link is broken, the host is not going to see the chirps until the link is fixed anyways and figure out with IT and security how to prevent it.
2 if is because the host is not polling fast enough then more or faster hosts need to used.

If it keeps happening at particular property then something is not right.

[jay]

Linuix !

[AndyP]

What chirps are you worried about and why do they occur?
If it is the link broken or host not polling fast enough chirps then do these 2 things
1 if the link is broken, the host is not going to see the chirps until the link is fixed anyways and figure out with IT and security how to prevent it.
2 if is because the host is not polling fast enough then more or faster hosts need to used.

If it keeps happening at particular property then something is not right.

The point is, they can happen, and you need to deal with them. The reason why they are happening is irrelevant. Welcome to commercial programming, to make things reliable we have to deal with all circumstances. 

Linuix !

Yeah yeah... I have to do all this stuff in linux too, but how many people here use linux? 



The point of all this is that my original concept is no good. This project is pretty close to getting the clients approval, so now I have to move into commercial mode. I am still going to work on a cheap way to do this, but it means I need to move into windows kernel space. This means a dedicated device driver, which will be serial.sys, or the default windows serial driver. No USB.

[Foster]

You can use a different DLL with C++, C# and VB access by class that can handle any serial including USB

The work around for bug in the SerialPort Class in frameworks actually creates almost the same functions in SerialPort class but all calls are to the kernel.
The Code Project website has posts and articles about it.


 

[AndyP]

You can use a different DLL with C++, C# and VB access by class that can handle any serial including USB

The work around for bug in the SerialPort Class in frameworks actually creates almost the same functions in SerialPort class but all calls are to the kernel.
The Code Project website has posts and articles about it.
 

Does not matter what DLL you use, its how the standard microsoft serial driver works that is the problem. Because it queue's all operations for a hardware interrupt, its not possible to rely on it to get the timing right. What you have to do is change serial.sys so that the operation is not queued, or if it is the handling of the parity bit is done in the same operation as the write.

[AndyP]

BTW. This is what you need http://www.ncon.com/9bit.shtml

[AndyP]

That guy who owns that driver is on leave till 26th of this month, bugger. Started rolling my own driver, looks pretty easy at this stage, but I am guessing that it will get a lot harder

[AndyP]

Well I managed to get the driver working. Not bad going considering a week ago I knew nothing about windows drivers!! Its now working a treat. Driver is pretty badly hacked, but it works. DLL is working the best it has, and I would say that it is now at a commercial standard!

Now that part is done its time to fully learn the intricacies of the SAS protocol!

[AndyP]

Well I had another idea folks, but this one will still require real serial ports, and in fact would require 2. Now I came up with this idea as I was modifying the driver for our fibre optic serial port PCI card to work with sas.

with the standard 16550 UART, there is no way to tell if a byte has been transmitted, even if talking directly to the UART. The problem with this is we need to set the partiy bit, and we need to be able to tell when the first byte is sent before we turn parity off.

There is couple of ways to tell if a byte has been transmitted.

• Work out how long it takes to send out one byte. This is not possible using win API, as all serial port writes are deferred for an interrupt.
• Use a daisy chain (or loop), where all data is sent to all machines and is received back on the serial port.
• Use a second serial port to monitor what is being sent on the first serial port.

It is infact, a combination of the second and third that are used in out commercial fibre card. Each port actually uses 2 UARTS. One UART has the transmit looped back into the receive on the PCB, and the second UART is used purely to receive data. So you basically have a dedicated transmit UART, and a dedicated Receive UART. Because the fibre is daisy chained, you also receive all data back into the receive UART.

When I have finished my current SAS work, I might have a crack at doing this, and I might even do it all in c#. I need to think hard about this though, the reason I used a c++ dll initially was because a). its easier for low level message handling and b) because it abstracts away the stuff that encompasses my NDA with IGT.

[jay]

Andy,

While I understand the reliability of serial, fewer and fewer PCs have this technology available.
SO with a look to the future may I suggest a direct USB (not USB to serial) interface. There is lots of programming support for USB drivers available.
This will give you direct access to kernal interrupts.

[AndyP]

Andy,

While I understand the reliability of serial, fewer and fewer PCs have this technology available.
SO with a look to the future may I suggest a direct USB (not USB to serial) interface. There is lots of programming support for USB drivers available.
This will give you direct access to kernal interrupts.

Just more complication though. To do it direct with USB requires a roll your own solution with DSP or Micro. All possible, just not sure if I want to do it.

Serial cards (PCI, PCI-X etc) are cheaply and easily had.

[SlotSpecialist]

Hi,

I used following library:
http://www.wcscnet.com/Products/CdrvNT/CdrvNTDownloads.htm

With that I succeeded with the implementation of the SAS protocol - including the wakeup bits ;-)

[zarobhr]

Hi,

I used following library:
http://www.wcscnet.com/Products/CdrvNT/CdrvNTDownloads.htm

i tried that one and could not get it to work with my serial card. and the never responded to my support requests


With that I succeeded with the implementation of the SAS protocol - including the wakeup bits ;-)

[SlotSpecialist]

Oh really?
They had an exceptional support when I called them ...
I am sorry .

[AndyP]

Hi,

I used following library:
http://www.wcscnet.com/Products/CdrvNT/CdrvNTDownloads.htm

With that I succeeded with the implementation of the SAS protocol - including the wakeup bits ;-)

I did write a driver myself, that works ok.

The part I dont like is that you have to use timing to work out when the first byte is transmitted, because the UARTS (or at least the UARTS on my PC) dont give a reliable indication of when the data has actually been clocked out of the tx register.

I should do some more work on this actually, things are quiet at the moment.

[SlotSpecialist]

 This sounds tough...