Signal generator applet

[ikarus23]

Hi. It would be cool to have simple signal generator applet. I'm not sure about DACs on the Glasgow, but even a square signal from a normal IO would be great.

I found the control-servo applet which generates a limited PWM signal. This is a great start, but it would be great to have more freedom. Some features I'm thinking about:

1. Simple square signal defined by providing a pulse with, a pause with and a pin.
2. "Replaying" a signal: same as 1. but a string of 1 and 0 can be provided with 1 being a high signal using the pulse with and a 0 being a low signal using the pause width.
3. Same as 1. or 2. but make it parallel. This would allow to specify multiple pins and to simulate a parallel bus signal.

This would also be great for some quick and rudimentary bit banging tests.

[whitequark]

My concern here is the degree of generality. Ultimately, you could consider any applet a type of "signal generator" since that's what Glasgow does. I think I can't accept such an applet upstream without a clearly defined and justified scope.

[whitequark]

Ultimately I also want it to be easy enough to add new applets that you wouldn't have to configure some monster with dozens of features to generate a signal similar to what you want; you would write a little bit of gateware that is exactly what you want.

[arnobert]

Hi. It would be cool to have simple signal generator applet. I'm not sure about DACs on the Glasgow, but even a square signal from a normal IO would be great.

I found the control-servo applet which generates a limited PWM signal. This is a great start, but it would be great to have more freedom. Some features I'm thinking about:

1. Simple square signal defined by providing a pulse with, a pause with and a pin.

2. "Replaying" a signal: same as 1. but a string of 1 and 0 can be provided with 1 being a high signal using the pulse with and a 0 being a low signal using the pause width.

3. Same as 1. or 2. but make it parallel. This would allow to specify multiple pins and to simulate a parallel bus signal.

This would also be great for some quick and rudimentary bit banging tests.

A simple sig gen is one of the basic features, I would expect. Just dial in frequency and amplitude, maybe waveform (sine, square, triangle), that's it.

[whitequark]

Glasgow can't generate sine or triangle without an external LPF.

[arnobert]

Glasgow can't generate sine or triangle without an external LPF.

Even a square gen would actually help me.

[rabagliati]

I also have an Analog Discovery 2, which I use a lot. I mostly use it as a digital signal analyser and protocol decoder, but I like the 'scope functionality, and the LCR addon is useful, though the dedicated ones are easier. I do not use the signal generator very much, but it is used for the LCR addon.

The Glasgow has more output capability, and its single channel analog input has a much more useful voltage range than the Analog discovery 2.

I think a signal generator and single channel scope are natural targets for the Glasgow - even if they are low frequency.

[whitequark]

Even a square gen would actually help me.

Something scoped to a square gen would work. How do you imagine controlling it? Do you want to change the signal parameters on the fly? Do you want cycle-accurate event scheduling or anything like that?

[whitequark]

I think a signal generator and single channel scope are natural targets for the Glasgow - even if they are low frequency.

An arbitrary waveform generator would need an analog frontend, and this is actually already covered: audio-dac plus a filter or a more complex frontend gives you that capability.

A binary pulse train generator can get fairly complex if you want multi-channel synchronization, on-the-fly updates, or things like that (you could write a PhD on this topic alone) so without a well defined scope I don't want to have one in-tree.

The analog input has something like 1 kHz of bandwidth, which is more of a "multimeter" width than a "scope" width, even for a toy scope. I don't think we currently have infrastructure to utilize even that at full capacity, and I'm not sure that infrastructure would be easy to fit into the FX2 either. Namely: I don't feel that the complexity of adding an entire extra USB interrupt endpoint just for that is justified (we're tight on space in the FX2 memory), and while you could use the FPGA to poll the internal I2C bus by going multi-master, this can potentially interfere with the overvoltage/overcurrent alert feature so I'm hesitant to rely on that either. (Overvoltage/overcurrent turns off Vio of the same port via a diode, but across ports the FX2 needs to be involved. Plus any issues with the I2C bus currently result in inscrutable behavior.)

[arnobert]

Even a square gen would actually help me.

Something scoped to a square gen would work. How do you imagine controlling it? Do you want to change the signal parameters on the fly? Do you want cycle-accurate event scheduling or anything like that?

I would try to keep it as simple as possible: Just one single channel, frequency and amplitude as parameters, without any changes during runtime, that's it.

[whitequark]

Glasgow does not have per-pin amplitude control. (You can control it indirectly via the port voltage, but our command line option system isn't really currently flexible enough to express the parameters as "frequency plus amplitude", although arguably it should be.)

Other than that sounds fine.

[arnobert]

Glasgow does not have per-pin amplitude control.

As long as there is only a single channel in use, that should be fine.

[whitequark]

As long as there is only a single channel in use, that should be fine.

A single channel per port (you can have two!). To be clear, I never wanted to imply this couldn't work electrically, this is purely a user interface limitation.