NEWBIE: Extending Python with C

[engsol at teleport.com]

On 10 Nov 2002 06:17:44 GMT, bokr at oz.net (Bengt Richter) wrote:

>On Sat, 09 Nov 2002 20:15:31 GMT, engsol at teleport.com wrote:
>
>>On 9 Nov 2002 09:54:01 GMT, bokr at oz.net (Bengt Richter) wrote:
>>
>>>On Sat, 09 Nov 2002 03:48:35 GMT, engsol at teleport.com wrote:
>>>

>>One example of the legacy requirement is: we have a custom plug-in card which needs to be
>PCI? All done via IO ports or has DMA? Uses interrupts? Time-critical parts?
>
>>loaded with data, then triggered to output the data stream to the system under test. The
>>driver for the card works well, and it'd be nice to not have to rewrite it. The source can
>How do you use "the driver" now? Are you saying "driver" just in the loose sense of any software
>that lets you use some hardware in some way? Or do you really mean "driver" as in developed using
>DDK or equivalent and put in C:\WINNT\system32\drivers\whizzomatcard.sys? Or a privileged app?
>
>>be recompiled as a DLL(?)  module...I think.  Or at the least as a library header
>Why do you think you want to do that? (I'm not suggesting it's a bad idea, I'm just wondering
>what leads you to think you may need to do that). How do you currently operate, and how do
>you hope to operate, at the user interface level?
>
>>file..again..I think.
>>
>It's still hard (for me anyway) to tell what your situation.
>
>Regards,
>Bengt Richter


LOL...this is a bit embarrassing....but here's more detail. Please keep the groans to a
minimum...:)

The test application is written in C. It's a DOS 6.22 application, compiled using Borland
3.0. We've tried newer versions, but they won't compile our source as is. The source is
3/4 million lines, including comments, blank lines, dead code, etc.,and the executable is
about 1 meg. It uses COM1, COM2 and COM3 to "talk" to the test fixture, plus it talks to a
couple of in-house designed and built ISA cards refered to above. One card's output is a
pair of BNC coax connectors which in turn are connected to the test fixture. The other
custom ISA card is attached to the test fixture using a 37 conductor ribbon cable.

The application provides a console-like user interface, command line style. The app has
the facility to run 'scripts', loosely based on a C-like syntax, which is how we write our
test scenarios to automate product software testing. The app also has "drivers" to run the
cards, IO ports, user interface, etc.

As background, the app began 10-12 years ago as a simple thing, then as time went on,
became larger and larger as more capabilty was added. Concurrantly, the products under
test became faster, more complicated, etc. We're now to the point that maintenance is
almost a full time job, we're out of memory (lots of page swapping/overlays), speed is an
issue (we really need an RTOS....events of interest are sub-millisecond now), background
sequencers are at their limits (threads would be nice), on and on. Plus it locks up a lot
these days, which is not good when trying to run a two day test suite over the weekend.

Soooo what is the new tool to look like? Which platform/OS is the "right" one? Which
script language would provide the testers with what they need? Having to compile scripts,
if it were C or C++, doesn't seem like a good idea, and not very newbie friendly. Perl,
while powerful,is a bit obtuse. TCL is a bit limited, although named pipes are handy.
Plus, "bread-boarding" quickie tests from the command line would be awkward at best. How
best to implement a user GUI, and still maintain a command line interface?  We're in the
exploration mode, as it were, to answer some of these questions.

After a lot of reading and web searching, we discovered Python. I'd done some tcl/tk, and
while it was fun, didn't seem to be a suitable script language for inexperienced test
people. But Python does. I've been writing routines in Python, just to get a feel for the
difficulty in implementing some "bread and butter" functions. Guess what...I was amazed at
how easy it was to perform rather complicated encoding schemes in Python...1-2 pages of
code... as compared to doing it in C, which takes 3-6 pages of code. As another "test", I
also wrote a Python routine to parse test log files (big, and lots of them, scattered in
different directories...thanks, glob), and make a formatted CSV file. Then hand it off to
Access for report generation. Piece of cake...gotta love them REs...:) That's why I'm a
convert. Then I wondered about IO port access....not much mention of that in the Python
docs...sockets, yes....direct control of the UARTs, no. But thanks to Mark Hammond and
Andy Robinson's book re Win32 API...that looks do-able with no particular tricks.

Then the thought occurs....will we be forced to write some things in C/C++? ISRs? RTOS
interface? Driving the custom cards? Timers? I don't know, but it's possible there will be
some tasks which will benefit from extending Python. If so, what's involved? How do you do
that...exactly? This is why I posted the request for help/info to this great newsgroup. I
need to figure out the process of extending Python...if it's needed.

To end my rambling...the answer to the driver question above has answered itself, I think.
Why would I want to port a 16-bit DOS module to NT/2K/Linux, as is? Thanks to the
discussion on this helpful newsgroup..I don't think I do. But I still need to understand
the process of adding Python modules, when to use DLLs if it makes sense, how to expose
them to Python, how to use them, etc. I need the "process"...I can figure out the code, I
hope...:)

(Now, if I can just find a good COM book per Alex's suggestions.....)

Regards,
Norm