Waveform Mini-Language

If you asked this question in comp.compilers, the standard answer would be to use an existing scripting language and embed it in your application. TCL is one option, but there are many others.

-Rich

If you asked this question in comp.compilers, the standard answer would be to use an existing scripting language and embed it in your application. TCL is one option, but there are many others.

-Rich

You could use an off the shelf command language, but you may find that it's a lot more capable than you need to do the job and has a large memory footprint

If you have the time, it's more fun and you learn more by writing your own. You can design and build a simple table driven parser and command dispatch unit to fit in a few K of memory. Typical data flow would be:

Get and tokenise input line

Syntax check against defined command set.

Lexical analysis

Command dispatch,

A typical command language structure that i've used in the past is of the form or , which results in commands like set frequency 1000, set volts 250 etc. If you keep the command set structure consistent throughout, writing the parser becomes a fairly trivial exercise. What you get at the output is a collection of function stubs, which you write to do the actual work.

A book on compiler design would be usefull - you don't need all the hairy stuff for simple command line parser, but it would provide a good background to the various techniques used.

IMO, one of the more interesting areas of software design...

Chris

Electronic and Embedded System Design Oxford, England (44) 1865 750 681

On Apr 11, 4:31 am, Guy Macon

It depends how much work you're willing to put into it. If you hack together a quick Java GUI applet that will let people adjust parameters with sliders, checkboxes and radiobuttons, then you can get really fancy with the underlying language if you want.

This is a vexed question, btw - I work with a Rhode & Schwarz signal generator and occasionally need to enter custom waveforms into it. Entire civilizations have risen and fallen in the time required to learn how to program the damn thing.

I couldn't agree more. What I said is that the standard answer is to use a preexisting scripting language. What I do in practice is invent my own language when I need one. ;-)

I agree. But people may scold you for reinventing the wheel. Which is OK if you get to decide to reinvent the wheel.

-Rich

[...] [...]

If it has to be small (you didn't specify), you could do much worse than Forth. Parsing is trivial, and the virtual machine extremely simple. The syntax might seem strange at first, but it's amazing how powerful it really is.

Regards,

-=Dave

The key to this will be to make it graphical, so they can SEE what will happen. A really polished design would be 'live', and allow them to drag/ insert the disturbances, and probably also accept PWL captures of real spikes....

So, it's sounding more like a spice problem, than a language one ?

Have a trawl thru the various Spice offerings, and see if you can create all you need from wrappers on one of those ?

-jg

(Replies to multiple posts combined)

--------------------------------------------------------------

Richard Penn>

Existing languages have many features that I don't need. This application doesn't process text, doesn't do simple math, etc. It's only purpose is to define three AC waveform outputs and perhaps to respond to a contact closure or an overcurrent/overheat condition -- and I am considering not having iny input at all to make the I/O into just O and thus to simplify the language.

--------------------------------------------------------------

larwe wrote:

This is an embedded system with no human-readable I/O such as a screen or a keyboard. I need to be able to feed it a text file through GPIB, serial or USB and have it respond by outputting the appropriate AC waveforms at the amplifier outputs. I would like that mini-language to be as human-friendly as possible.

I may, however, create a PC app that works as you describe and which creates programs written in the mini-language.

That's exactly what I wish to avoid.

--------------------------------------------------------------

Dave Hansen wrote:

I have been a FORTH advocate for many years (I was responsible for Mattel starting to program toys in FORTH instead of always doing it in Assembly Language) and may very well do the underlying code in FORTH, but I am not inclined to ask a bunch of electricians to leann FORTH suyntax. A limited subset of BASIC would seem a better choice for the mini-language.

It doesn't have to be small. I can afford any processor and memory I wish, and would be happy to spend many cycles/bytes in order to make it easier for an electricion or test engineer to program.

--------------------------------------------------------------

-jg wrote:

Those are really good ideas for a PC app that creates programs in the mini-language, but the input to the generator must be a mini-language contained in a plain ASCII text file, and the only output from the generator will be waveforms.

--------------------------------------------------------------

ChrisQuayle wrote:

I am purposely deferring the implementation details for now so as to avoid creating something that is easy to code at the expense of being hard to use.

That's a syntax well worth considering. Easy to iunderstand for the human. Got any ideas for how to make a "go" command so that the frequency and voltage change at the same instant? FM? AM? PWM? Slewing phase/voltage/frequency? Iterating?

--------------------------------------------------------------

Guy Macon

That's actually what I meant... sorry :)

I don't get what the hard part is. You need an application specific language and Forth is pretty much perfect for that. Forth does not impose a syntax on it. I have seen many examples of alternate syntax to the standard RPN of Forth.

But you still want the scripting language to be english like so that the users can see what the commands are?

How about "Frequency 500 Hz Voltage 20 Volts Set"? The word Frequency would be executed and read the number following, leaving the value of

500 on the stack along with a token indicating it to be a Frequency and increment a variable indicating the number of parameters. The word Hz would modify the value of 500 to whatever works as the internal value. The word Voltage will do likewise, but increment the value of the parameter variable. The word Volts modifies the value

1. The word Set then executes the items on the stack simultaneously leaving the parameter variable as 0. You could simplfy this a bit by omitting the words Frequency and Voltage and letting Hz and Volts do all the work. "500 Hz 20 Volts Set"

Is it that hard to figure out how to do the same with FM, PWM, slewing, looping, etc?

"Slew-Frequency 100 Hz 500 Hz 10 Hz/Sec" would execute the word Slew- Frequency which would invoke the Forth "execute" on the remainder of the command line. Once the stack contained the parameters, Slew- Frequency would error check and execute it.

"Repeat Slew-Frequency 100 Hz 500 Hz 10 Hz/Sec NextStep Slew-Frequency 500 Hz 100 Hz 10 Hz/Sec NextStep Loop 10"

Here "NextStep" provides an exit from parsing the Slew-Frequency command as well as separating the steps that are repeated by the "Repeat" and "Loop" commands.

Is this close to what you are thinking?

I have done similar things when I was reading text files and parsing object descriptions for PCB footprints. I don't recall the details, but I let the description be a language which was executed using Forth and it built up an output file that the PCB program understood.

To figure out how to implement it I think you just need to define a language you want to use. Then you can use Forth to implement it fairly easily.

On Apr 12, 8:16 am, Guy Macon wrote: [...]

If you have a little more space, you might want to look at Lua

Simple procedureal syntax, and it's designed to be embedded within other applications.

It's been a while since I've looked at it, but it seemed pretty nice about 5 years ago.

Regards,

-=Dave

"-jg" skrev i meddelandet news: snipped-for-privacy@n76g2000hsh.googlegroups.com...

Ah, you want to reinvent National Instruments LabView? Did not use it, but I am sure it will do what you want.

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

Very expensive, complex and needs a windows machine to run, yes ?.

By the time you get fluent in Labview, you could have written a command line parser several times over...

Chris

--

----------------------
Greenfield Designs Ltd
Electronic and Embedded System Design
Oxford, England
(44) 1865 750 681

A far better choice of viewer would be gtkwave - smaller, faster, and easier than LabView since all it really does is show waveforms, and it's open source and cross-platform.

As for the language, I'd use python if it can run on a PC, or lua if it is to be embedded. Both will be bigger than a roll-your-own dedicated language, but much easier to implement and you get a lot of extra for free.

mvh.,

David

I have used LabView many times, and have not found it to be a pure-ASCII-based human-readable mini language capable of programming an embedded waveform generator that has no keyboard, mouse, or display. It really likes to have a PC to run on...

My question is *NOT* "what existing software or language can be kludged into kinda sorta controlling a waveform generator?"

My question *IS* "How do I write a human-readable text file that describes most or all of the commonly asked for waveforms that a high-end uC and three good DACs can generate?"

"rickman" understands what I am trying to do. He suggested commands such as:

Frequency 500 Hz Voltage 20 Volts Set

500 Hz 20 Volts Set

Slew-Frequency 100 Hz 500 Hz 10 Hz/Sec

Repeat Slew-Frequency 100 Hz 500 Hz 10 Hz/Sec NextStep Slew-Frequency 500 Hz 100 Hz 10 Hz/Sec NextStep Loop 10

...which is what I am looking for -- a Waveform Mini-Language.

Thus the subject line of this thread.

Rickman's idea is sound. A computer can parse it with ease and a non-programmer can understand it and create new programs.

Right now I am trying to work out how to use his scheme to tell the waveform generator to do the following:

OUTPUT A: 10VRMS 1/F Noise, bandwith limited to the frequency response defined in the CIAJ CES-Q001 "specification and rules concerning telephone voice communications quality" specification.

OUTPUT B: Sine output, 100 second duration, log sweep of frequency from 10 Hz to 1KHz, antilog sweep of AM modulation from 10% to 90%, linear sweep of crossover distortion from

5% THD+N to 25% THD+N, 1% pink noise added.

OUTPUT C: What a 10Hz 10VRMS sine wave would liok like after going through an 8-bit ADC --> DAC conversion with several non- monotonic codes.

..and other things like the above.

I can, of course, keep adding commands to handle these and any other cases I might think of, but I keep thinking that there must be some simple scheme that will allow me to define the above waveforms and many without adding hundreds of special cases.

Guy Macon

I am not sure what you are asking for at this point. I thought you wanted to "control" a waveform generator. Some of your examples go far beyond "controlling" a generator and are more a waveform description language. I don't know for sure, but I expect the waveform generator does not know what "CIAJ CES-Q001" is and has no way to set it up directly for that. Instead you have to translate that into bandwidth and other specs that the generator understands. If you want the language to "understand" what that spec is and how to setup the generator for it, then you are asking for a *much* more difficult thing.

Example B: I am not sure I understand it myself and it is supposed to be in English! How would the generator or the language understand?

Example C: is clear, but this is the sort of thing that is way beyond a language per-se... unless that is truely your intent which will be a

*much* more complicated thing.

I did not think much about the generator you are controlling. Is this an arbitrary waveform generator? Just how much control do you have over the output? If the control is complex, the language will be complex. I assume that the front panel can be used to program the device. I would make my language mimic the front panel controls in extent, perhaps with more clarity, and then use the PC based tool to generate the complex commands from your examples.

Or do you really want the language to understand "CIAJ CES-Q001" or the generation of a DAC output?

Sorry for being unclear. I am *DESIGNING* the waveform generator. And a waveform description language is exactly what I am devising..

That was my point. I don't want to pre-program in hundreds of special cases, only to have to add more every time a user calls with an application I hadn't thought of. I want to devise a waveform description language that is powerful and flexible enough so that the answer is almost always "yes, it can be programmed to do that as well."

If the waveform description language can describe any waveform, it can describe the waveform in example C. And indeed, I can devise such a language if I abandon the requirement that it be easy for a human to write programs in the language; just specify the time and amplitude of each individual sample.

As I wrote in the post that started this thread:

"I am doing some preliminary design work on a AC waveform generator. The primary use will be generating signals that, when amplified, will generate three-phase AC power with various line disturbances dropouts, spikes, etc.). This will all be done with DACs.

and

"I am pondering making a mini-language to make it easier for the users (who range from EEs to electricians) to program waveforms ... how simple can I make such a mini- language whole minimizing the odds of someone ending up not being able to create the waveform they want?"

100%. I control the entire hardware and software design.

I disagree. I have seen many examples of simple languages being used to do complex things. FORTH is a good example; the same basic concepts that were designed to control the movement of a telescope have proved to be flexible and powerful enough to do many complex things without having to add extra features to FORTH to accommodate each new application.

Nope. I may put in a simple panel that displays voltages, turns the unit off, etc. or I may make it 100% headless.

I have no intention of trying to make a panel with a bunch of buttons be able to program in any waveform. Others have tried that and have ended up with systems that are very limited and hard to use. That's why I am going with a mini- language paradigm.

I don't know why I am having so much trouble making it clear that I am asking about a mini-language-based design and not about a GUI-based or front-panel-based design. Is my writing unclear, or is this a case of the readers assuming that there are only one or two possible ways to tell an embedded system what waveform to generate?

Guy Macon

Ok, I missed that.

Unfortunately, no matter if the generator knows what "CIAJ CES-Q001" or the language knows it, if you want the user to be able to specify "CIAJ CES-Q001", then that has to be built in. However, I have no idea what it is.

If you want to be able to describe an arbitrary waveform, then you need to consider the various ways you might be able to describe it to a human (such as myself) who knows what waveforms are but does not know the details of any of your requirements. For example, if you told me you wanted a sine wave of a given amplitude, frequency and phase, I could understand that. So it seems logical to include that in your language. Likewise square, triangle, ramp and other waveforms would be primitives. There should be a way to sum any combination of these waveforms including a sum of sums. You might want to be able to multiply waveforms. Likewise there should be certain basic transforms on these primitive waveforms such as frequency and amplitude ramping.

The description "CIAJ CES-Q001" means nothing to me and I expect it will mean nothing to a language unless you really need for it to know that. What goes into making a signal like this?

In essence, it sounds like what you need is a text description of a signal processing workstation.

I don't agree. Forth is not really all that simple for a problem like this. In fact you specifically eliminated it because the syntax is to complicated for non-Forth programmers. I don't know that a telescope is a complicated thing to control in terms of the user interface. It likely does three things... Goto a point in the sky, Track a point to coorect for the movement of the earth and Track an object that is also in motion relative to the cosmos. So the interface is likely simple. But none of this is relevant.

Are you saying that you are willing to consider a (non-RPN) language as complex as Forth for this application?

I completely missed the point that you were designing the system, or maybe I just forgot after the first few messages. Now that I am over that hump, I see that you are trying to design a general purpose waveform description language.

I don't see this as a simple exercise as there are so many different types of waveforms. I think the first step in designing the language would be to figure out what waveforms you need to describe. Think of it as a form of compression. You can't compress *every* waveform possible. You can only compress a subset into something smaller than the listing of all the points. Of course you also need to allow a listing of all the points in the waveform so that the user *can* describe any waveform.

One last thought, consider postscript. It can be used to draw

*anything* that can be printed on a page. It uses commands for drawing all sorts of shapes or text and by using it as a language it can describe many types of pages. But there are times when that is not enough and PS allows bitmaps to be provided which are mapped to the output device. Even then the user may need to know things about the output device... I have seem some pretty weird stuff come out of a PS printer when an image was not handled correctly for that particular device. Have you considered perhaps a subset of PS? Require everything to be on a single (or triple) line. That would certainly be simple enough to image!

Hmmm... that actually sounds like it has potential. If you can define a waveform as a function (even an arbitray one), then PS should be able to image it and your waveform generator should be able to generate it! But then it is RPN like Forth... Is RPN really so hard for a user to learn? I have always thought that was the easy part of Forth.

I think that's clear - I realised that was what you were trying to do, but I see the problem as less the languae itself, and more how the heck does the user know they have it right/wrong ?

- so I believe you need some visualise method on the creation end - it can work from a simple text file, of course.

Rick's idea of Postscript is good, as that DOES give immediate visual verify, and another variant on that theme is SVG - there are editors and viewers for SVG, and it is always a text language - I think you can also document well with SVG, as a single web page can import/display multiple SVG files, which can be your templates.

You then create a 'smart editor', that keeps the SVG in the subset your embedded side can understand.

-jg