Scripting tools under Windows

Hi guys, Like a lot of you I develop devices that need to be programmed, configured and tested in a production environment, often in conjunction with firmware test functions on the embedded device. Much of this is accomplished from Windows PCs using serial and parallel ports and usually involves running small utility programs. Naturally I want to script these procedures to require the minimum amount of human intervention, both for efficiencey and repeatability.

So what scripting tools are you guys using out there? Years ago, I used QuickBasic to quickly knock up this sort of script, usually 1/2 an hour at most, a nice set of serial and parallel port manipulation tools and easy to run little external apps (e.g. a bin2hex utility). Of course QuickBasic is not compatible with modern Microsoft OS's.

My preference is for a simple language that does not have to produce robust shrink-wrap code, isn't bloated with GUI stuff, has serial comms with control over handshake lines, can control parallel port lines, can send data to other apps and receive data from them, read and write files and interact with the user via a console, and can be batched. It should be capable of being modified by Windows programmers, embedded programmers, hardware engineers and production techs without too much of a learning curve - kind of leaves out huge APIs and frameworks.

Some of the tools used around various places I interface with include:

Python: A different language every week, can't do anything on its own but needs a bunch of libraries - and there's 32 different varieties of each. It's also a different language every fortnight.

C# / .Net: Like Python, has way to rich an API but makes the simplest things seem difficult - e.g getting unbuffered bytes from a serial port.

Labview: Really well suited to the task, but difficult for Labview newbies to get to grips with, and damned expensive.

Your ideas would be appreciated.

Cheers, alf

Reply to
Alf
Loading thread data ...

Sounds like Forth to me. Apart from being a Forth vendor, we eat our own dog food and do all this stuff easily. The commercial Forth vendors provide free evaluation systems which can do everything except make turnkey apps. There is also a range of public domain and GPL systems. Our product, VFX Forth for Windows, can be run in console mode or GUI mode and understands redirection.

Forth is not a fashionable language, but it sure works for us and many others who want to connect PCs to the real world.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
 Click to see the full signature
Reply to
Stephen Pelc

I've read a fair number of different descriptions of different languages over the years, but I've never seen anything as totally inaccurate as that!

Python adds language features over *years*, not weeks - and it does so with a very structured and safe system of deprecating old features (when absolutely necessary) and gradually introducing new ones.

The "bunch of libraries" is *included* in the Python system. When you install Python, there are a large number of library modules installed at the time. Installing new ones (such as pyserial and pyparallel, for serial and parallel port access, or pywin32 for windows api wrappers) is simple, and the libraries are automatically integrated. Additional libraries are available for a vast number of different purposes.

The only potential risk for using Python for this sort of thing is that it might be *too* powerful. But if you are needing something beyond a simple batch file, and beyond bash (and "expect") scripting, then it would definitely be my first recommendation. Python is regularly used for small scripts as well as for major applications.

tcl/tk would be another alternative to consider if you have some sort of snake allergy.

That's not scripting, that's software development, and needs serious development software and trained programmers.

First, consider plain bat files - there's a lot of automation possibilities there, for very little effort.

Next step up is bash scripting - it's a lot more powerful than bat files. Combine it with "expect" to automate command-line programs.

If that's not enough, Python is the way to go.

formatting link
formatting link

Reply to
David Brown

Perl.

But for the kind of production testing you describe, an ancient (in internet years) copy of Borland C++ Builder 5 along with the com port component from makes this kind of thing very easy. A nice set of graphing tools is included in the base BCB package for live trend plots, etc.

Hook that up with USB-enabled interfaces (with API libraries) from folks like , CAN interfaces from , and GPIB connectivity with

and you're rockin'!

I also have MS Visual Studio 2005 but use it only under duress.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Forth is actually a lot like dog food - when you first try it, it's horrible and repulsive. But if you can deal with the philosophy change and get used to it, your meals are very quick and very cheap, and can be made from a wide variety of easily obtained ingredients!

(Forth is a language I would like to be good at, but have never found the time.)

Reply to
David Brown

of script,

When you are writing non-shippable lab code, your principal constraint is ease of use. Therefore your #1 selection criteria should be "similarity to stuff you've done before".

If BASIC is your cup of tea, then perhaps you're best served by using VB, though it's not really BASIC of the kind we used to know and love. Microsoft makes a free version (Visual Studio Express) available.

I tend to write this kind of code in C and use either Linux or Cygwin depending on what the code actually needs to do. Really, the Windows API for serial ports is not unreasonably complicated.

Reply to
larwe

Turbo Power Async

formatting link
does a good job and it's free. It also supports a lot of TCP/IP stuff as well.

While you're about it, if you can stand Pascal, try Lazarus

formatting link
it's a good Delphi clone with cross- platform (Windows, Linux, WinCE) capabilities. And it's free.

For the port output, TVicPort is useful:

formatting link

Reply to
Paul Burke

My impulsive response to your question would be Perl because it meets most of your requirements. Then I thought about it a little. Where I work, what's important is that works reliably, it's quick to build, and it's low maintenance. There are many high quality software systems or combinations of those systems that will meet your needs. My thoughtful response would be a series of questions to you:

What are your programming strengths? And those of your successors?

How much money do you want to spend?

What tools do you have on hand right now?

I would think the answer would be found not primarily on based on technical merit but rather based on your personal preferences, strengths, and what tools you have within easy reach. There are so many arguably good ways to go.

JJS

Reply to
John Speth

Tcl works fine.

Try comp.lang.tcl with your specific application.

You can get distributions from

formatting link
among other places.

It is open source, and you can add commands to the interpreter and make your own custom executable if you want to add in things most efficiently done in C.

--
David T. Ashley              (dta@e3ft.com)
http://www.e3ft.com          (Consulting Home Page)
 Click to see the full signature
Reply to
David T. Ashley

Yes, we need to test and program many of them.

No, we don't.

No, we don't.

One connector and One button.

Basically, we have an embedded tester/programer connected to the target's Jtag/Spi ports. With the push of a button, it boundary-scans for open and short traces. Program the device and turn on either a Red or Green Led. We don't really need to see anything else.

We can test and program them in 10 seconds.

Reply to
linnix

PowerBASIC Command Console matches your description. (Make sure that PowerBASIC Command Console is the one you look at; there is another flavor of PowerBASIC that is more suited for GUI work

-- you want PC/CC.)

Please keep in mind that only Windows 3.x, 95, 98, and Me can read and write directly to the parallel port. For 2000, 2003, and XP, unless your chosen language contains a driver (not likely) you will need a driver such as:

ParaPort:

formatting link
PortTalk:
formatting link
ParPort 2004:
formatting link
TVicPort:
formatting link
WinIO:
formatting link
ParIO:
formatting link
Also see:
formatting link

I don't know if any of the above work on Vista. If you are using Vista to interface with embedded systems in a production environment, you need a brain transplant, not a programming langueage or device driver. :)

--
Guy Macon  Guy Macon 
Guy Macon  Guy Macon 
 Click to see the full signature
Reply to
Guy Macon

Unix tools, like the gods intended... ;-> Cygwin works quite well once you've wrapped your head around its quirks.

I usually escalate from bash to sed, to awk to perl, as needed.

There's VisualBasic and, more importantly, the Windows Scripting Host, which runs scripts written in either Basis or JScript. That's pretty much the official solution if you're on MS Windows.

Reply to
Hans-Bernhard Bröker

Ruby, see

formatting link

Reply to
Clifford Heath

Whoops, I really wasn't trying to troll for Serpentophiles, sorry.

There's one I'd completely forgotten about, must look it up again, been many years since I dallied with it.

Thanks, Alf

Reply to
Alf

LOL, that's GOLD! Being one of the fortunate few who was brought up on HP calculators, I quite enjoyed a dalliance with Forth in the embedded sphere some 20 years ago. Others though to seems a little backward it.

Cheers, Alf

Reply to
Alf

Thanks, Lewin, Not much difference as far as I'm concerned, between VB and VC# (Express or otherwise). Still got to cope with that .NET framework and find your way through the gazillion functions that it offers. And its horrible serial port handling. I, too, have much of this stuff in C (my fave is still BC++ V4.51). Cheers, Alf

Reply to
Alf

You're right, John, and it's not technicl merit I was considering. Certainly Quickbasic had very little of that. It's convenience and accessiblity. My "tools" these days are quite varied from techs through embedded assember and C programmers to Windows C++ and C# software developers. I'm looking for one ring to rule them all and in the scripting darkness bind them. If it was just for me, I'd stick with the familiar, gcc, C# or even Python.

Cheers, Alf

Reply to
Alf

I wonder whether nobody mentions PowerShell, the new Microsoft tool. The price is right, free as in "free beer" (not freedom.). It took some inspiration from Python, I guess. The base idea is to work with typed objects, not strings like traditional shells. This is nice in itself.

I dumped it after it turned out that

ls > myfiles.txt

didn't work. ("we do not do file redirection yet"). Also there seems to be no notion of current directory.

I love to hear stories about how it is unusable, but then it may not.

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
 Click to see the full signature
Reply to
Albert van der Horst

Have you ever considered C/C++ interpreter Ch for scripting? It is free and runs across platform. You can find the shell scripting and C/C++ features in the following link:

formatting link
formatting link

The windows serial port I/O is well supported in the Ch.

formatting link
formatting link

of course, Ch is best suitable for embedded scripting:

formatting link
formatting link

Hope it helps.

Reply to
Peter

Have you ever considered C/C++ interpreter Ch for scripting? It is free and runs across platform. You can find the shell scripting and C/C++ features in the following link:

formatting link
formatting link

The windows serial port I/O is well supported in the Ch.

formatting link
formatting link

of course, Ch is best suitable for embedded scripting:

formatting link
formatting link

Hope it helps.

Reply to
Peter

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.