Brightan Driver

[Brightan]

I am thinking that I am going to have a few questions during my driver development so I thought I would start a new thread and continue to add to it as I go. Some of these questions have likely been asked before but finding information is sometimes as time consuming as anything.
Anyway, I am creating the RS232 protocol itself, writing the firmware on the controller side, learning CML and writing the CQC driver, all at the same time :shock:
I thought I would start with a simple PDL driver to get my feet wet and I found the sample manifest but cannot find a pdl example. Another thread made reference to all the .pdl and .cml source files but I can't find them, what am I missing?
Steve

[robertmee]

They are just text files. You can open them with notepad or any other text editor. They are located in the CQC\CQCData\DataServer\Protocol directory and have the CQCProto extension.

[Brightan]

I found 19 .CQCProto files in the
CQC\CQC_1_6_21\Image\Protocols directory.
oh, I guess they are only on the server at the directory you mentioned, thanks

[Brightan]

Can a PDL driver support CRC16? The CRC functions I use on the micro side are table based and I don't know what the polynomial is that generated the original tables. Has anybody done this before and did you use standard CRC16 functions from the net? (there appears to be some debate over correct and incorrect examples floating out there)
Also, I'm looking at the Denon DVD-3800 file and there are many lines of mappings, like
Item="Power ON" , 0x20; // Space
but then they are never used but lines like this show up
Equals(Extract(&Reply, Card1, 1), 0x20), // Power On
I'm assuming the auther was supposed to use the text representation?

[Dean Roddey]

Those tables are used. The line you are referring to is just telling PDL what reply has just come in. The map is used for incoming/outgoing messages, to map to and from the numeric format used by the device and the text values exposed by the driver.

Have you read the driver development guide? If not, you should start there.

[Brightan]

Have you read the driver development guide? If not, you should start there.

ouch. I guess I am trying to get this done as fast as possible and am used to lower level langauges without so much abstraction. I'm not saying that is a bad thing, just a little frustrating dealing with the limitations. Maybe I also misunderstood the purpose of this forum. My apologies.

[Dean Roddey]

PDL is designed to be as simple as possible while still being able to handle a reasonable amount of scenarios. Anything beyond that you have CML available and it's not limited in those ways. So you have to figure out if the protocol is amenable to PDL or not, and sometimes they just aren't consistent or well designed enough.

This forum certainly is a place to ask questions, but the guides are the most dense source of information and you should always read them if you want to understand the nitty gritty details, which is important for something like device drivers. No one is going to replicate all that information here and most folks will assume you have read the relevant guides.

[Brightan]

I am going to post the following notes in case somebody comes after me wanting to do the same thing. At this stage I have a simple PDL driver sending two way commands that is now generating CRC's. :-D
If you are using CRC's in your PDL driver, here are a few things that you should know to speed development along
1) If you use a nice utility like this one
http://www.lammertbies.nl/comm/info/crc-calculation.html?crc=12345678&method=ascii
They talk about the two most common polynomials 0x1021 and 0x8005 and yet the handy little test utility uses the 0xA001 polynomial (they didn't mention that part! :-( )
2) When using the CRC16 command within CQC
CRC16(buffer, offset, len, poly, count)
-Len must be one less than the actual length. I noticed that the Checksum examples subtract one from their length as well but I'm not sure why that is.
The sample code in the driver guide
Card4 ByteInd(StartInd);
Card4 EndInd(StartInd + Len);
While (ByteInd <= EndInd)
would indicate that the <= should be a <
-count should be 8 (8 bits in a byte)
-the data returned by CRC16 is little endian and will have to be flipped if sending to some micros (for us Motorola guys!)
As a reference, use the following code

WriteCmd=TestCRC
Send=
0x31; 0x32; 0x33;
0x34; 0x35; 0x36;
0x37; 0x38; 0x39;
CRC16(&WriteCmd, 0, 8, 0xA001, 8);
EndSend;
EndWriteCmd;

The assumption here is that you have a basic working PDL driver with the appropriate Fields etc. This will send 9 ascii characters "123456789" and generate the CRC16 of 0xBB3D.
Also note that the web page mentioned above contains sample C code for generating a table based system for implementing on the receiving side...my next step...

[Brightan]

ok, I take back any cranky comments about limitations, I have been having all kinds of fun, both on the graphic side and the protocol side. The protocol driver harness works very well and is excellant at showing such detail as the state machine etc, well done!
One of the tools I am using is a little VB6 app that I wrote that runs on my development computer that communicates through one of the serial ports. This allows me to run the PDL harness and communicated back through a loop back cable to my test program. The harness shows incoming and outgoing packets and the test app shows the incoming and outgoing packets and can then be modified for testing. I have one version that uses a very simple 4 byte serial protocol to turn on a virtual LED and check the status of a virtual switch. Its kind of like the simulator used in the tuturial but it communcates out through a real serial port.
Anyway, I can zip up the driver, the exe and the VB6 source code if anybody wants it or it can be posted somewhere for future use.
S