Hello,

I have been developing a C language software for software oscilloscope which is part of a control software. From timing point of view the software consists of two execution loops. 

The first execution loop (let´s say "fast loop"- FL) is interrupt service routine (ISR) for the "end of A/D conversion" interrupt. This ISR is invoked with 100 us period and is responsible for recording samples of given physical quantities into associated circular buffers which creat core of the oscilloscope. It is also responsible for pushing samples into another circular buffers for FIR filter calculations. 

The second execution loop (let´s say "slow loop" - SL) is a FreeRTOS task which is executed after 8 executions of FL. This loop is responsible for dividing the oscilloscope circular buffers into the "pre-trigger" and "post-trigger" parts based on commands comming from software running on the PC, storing the osciloscope records into the external flash memory and FIR filters  calculations based on values in the associated circular buffers.

I have been thinking about robust solution for exchanging data between the FL and SL and vice versa. I need to ensure:

a) as soon as the SL starts calculation of the FIR filters these calculations has to be done with 8 values gathered in the last 8 executions of the FL i.e. it has to be ensured that despite the FL is still running and periodically interrupting execution of the SL and has new samples the SL still uses the same "snapshot" of the 8 samples (which was valid at the beginnig of SL execution) for whole SL execution time.

b) as soon as the SL decides to change the division between "pre-trigger" and "post-trigger" (based on command comming from the PC) by changing position of a "stop" the "stop" position is allowed to change at the beginning of next FL execution.

Can anybody give me an advice how to solve that? Thanks in advance for any suggestions.

#FIR

a) Double buffer.

b) I think it would be more robust for the SL to handle the pre-trigger vs. post-trigger storage difference, and for the FL to just move samples to buffers. For that matter, seems like a DMA peripheral could do most of what the FL is doing, if I understand you correctly. 

Regards,

Tim

Hi Tim

{laughing} your solution is much more simple and straight forward than mine (skyscraper version). DMA is always a good choice because of minimal processor load.

greets,

Ro

{update, June 13.2020}: I have the (strange) feeling that we are re-inventing the wheel; minutes ago, I saw a video controling an Oscilloscope by an arduino DUE and there is also some software-under-the-hood shown. 

As I experienced already the re-enventing-the-wheel effect, it is still possible to find a new wheel, but don't expect it to be really better, more advantageous, etc. - and there are  DSP-Libs  around with everything that you dont' know that you don't know (ref.: Poem of Donald Rumsfeld, State secretary of defence, "The unknonwn") which are so incredibly optimised, I would not think that there is much increase possible. 

So it appears to me that for  licence reasons  there is done something from the scratch. But in reverse, did you come up already with the idea to make a research including patents (patent recherche). it could save valuable time and money, despite of the professionals around which give you the best support even theoretically possible. There are other aspects but I won't do a lecture here with patent-coupled-development.

Thirty years from now I had the same opinion as all engineers have and have it still, but in the mean time I learned that  eighty percent of the world's knowledge  are found in patents (and most engineers are impressed when proving the above-said effect), including program code, with good resolution as towards recherchability, as the IP-Classification is a fine grid, and recherche tools of today, driving Big Data approach, do find you the tip of a needle in the arena in Billions of protections rights. 

Hi Steven02,

you solution is nice, so what about to set up a accompanying pointer (index co-surfer riding on the index's back), which shifts resp. travels forward or backwards relative to a (variable) reference point, eg. where FL points to at the figure in your post above.

As to the fast and slow Loops, I am not so shure I this concept is optimal. I used a construction with doal ported memory (tripple-ported is possible as well, you also could set up a matrix structure engine), so there are two indpendent(ly controllable) processes like in a store shelf, having an input side and an output side. 

At the input side, the writing loop (called Hubschrauber or helicopter loop) always fills the buffer memory locations (the shelf) with sampled values from the D/A (using two shelfs would also be suitable for complex values, qadrature values etc.), and has a refresh cyle (this is simmilar or identical to you anular or circle buffer, you can use several buffers by the way in a "stacked" fashion, and do weird signal manipulation, so eg. filtering). 

At the output side, the data is taken out from buffer memory by sampling or strobing the buffer - not necessaring by applying monotonically arising adresses (like a "ramp signal" as to the linear increase of adresses from Mem_Min to Mem_Max), but also with an other kind of read-out shape of waveform or read-out frequency even with accounting for phase (in a two shelf system, you could set up a phase correspondence). 

You can also convert sampling rates if you change the input refresh cycle fill-in rate (speed) compared to the output sampling take-out cycle rate, and you can imagine a shuttle dial to lower or faster the speed, and there again comes aforesaid accompanying pointer which lets you move relativ in view of the reference pointer doing the readout. 

To make things finally really crazy, you could even exchange input with output and use the whole system structure for outputing signals as a generator. Note that it is even possible to use an D/A coverter as a A/D-Converter (which was done in former times, using an AMD6022 12 Bit converter)

I presume that you intent any windowing, averaging or moving average filtering, so this should be possible on this theoretic approach.

greets,

Ro

I definitely agree with Tim.

You definitely want to handle FL with DMA, that way you will free up the processor from all that overhead. With DMA, it would be just sitting there until it gathers the 8 data points you need (sort of).

Here, the ADC result goes directly into your buffer via DMA and then you configure your DMA to let you know it is done after it has transferred 8 data points. That way, instead of having an interrupt and ISR execution every 100us, you will have only one interrupt every 800us informing you that you have your 8 samples ready. Then SL can take them and it will have 800 uninterrupted micro seconds to process them until the next batch is ready.

If you use double buffering, then SL can have 1.6ms to do it's job.

It looks that you are doing acquisition in fast mode circular buffer and FIR filter in slow mode and the time base is fixed. (I assume 100 uSec acquisition forming the ISR & core and 800 u sec in RTOS).

I feel that you can synchronously operate both in ISR, like one set of circular buffer at 100 u sec and next set of filtered buffer occurring at every 8 samples (with 8 times samples in buffer).

You need to switch to FIR, in ISR itself, so you have to plan in such a way that FIR is executed within the ISR timing at 8th sample.

This will make your software more robust and you can handle the variation of time base

(like 100 u sec - 80 u sec, 50 u sec ...).

When you hit a limit of time you can switch off FIR filter and do raw display without the filter.

This will make your software robust and independent of RTOS task switching and entering into deadlock etc..

you can use the RTOS functionality to switch the settings of time base or voltage levels which are not time critical and even if there is a deadlock in RTOS the basic ISR base display will continue.

BV Ramesh.

Steven-

Answers from Tim and BV Ramesh are on the right track. Additionally you want to abstract timing between acquisition and display/processing. Whatever does the acquisition could be many things -- PCIe card with DSP cores and A/D, SDR radio board (e.g. USRP), USB audio with ALSA drivers, similar thing with your FreeRTOS, etc.

The concept of a digital oscope is a "snapshot in time" -- clearly there is no possible way for your high level operations to keep up with acquisition rates. Implied within this is that each snapshot needs a trigger criteria -- amplitude, +/- slope, pulse width, etc, and nested combinations thereof. Architecturally, this implies an intermediate software function that creates the snapshot:  figuring out which acquisition buffer is available (i.e. not one currently being filled), applying trigger criteria, and making available a snapshot buffer.

Preferably, from a software architecture perspective, the snapshot function is distinct and separated from both acquisition and high level. If that's not possible in your setup, and you have precise control over A/D and you handle each sample (sounds like you might since you mention ISR and "recording samples"), then you can combine the acquisition and snapshot functions. In this way the ISR:

1) Double buffers (2 circular buffers)

2) Applies triggering criteria to determine the start of each buffer, discarding samples until the criteria is satisifed

3) Holds off between buffers if for any reason creating the snapshot has taken too long and is not done yet

This is basically what we did many years ago with Hypersignal software, which supported a digital oscope function for a wide variety of DSP/acquisition hardware. The ISR was basic C/asm code running on the DSP, the holdoff flag was writable by x86 high level software (display + processing), and readable by the ISR. We came up with this because there was a wide variety in timing on both sides -- some of the DSP boards were slow, some were fast; some of the high level functions needed substantial processing time, such as transfer function measurement between channels, filtering, etc.  We could not afford to muck with the code each time there was a new board or Intel came out with a faster CPU, so we were forced to think about timing abstraction.

-Jeff

Hello Jeff,

thank you for your reaction. I would like to refine my intention. I am going to implement software oscilloscope which is used for monitoring control software execution in real time. Its purpose is to monitor variables of the control software for induction motor drive. I need to monitor mainly stator currents, three phase voltage source inverter dc bus voltage and mechanical speed of the motor. This osciloscope has to also support recording of the above mentioned variables before and after some by user specified events. The timing of the control software is based on A/D converter sampling period. I would say that the "end of conversion" ISR (FL) is the smallest time step which the software works with. It is the reason why I am going to implement the oscilloscope in the FL. The SL has to compute the FIR filter algorithm for control purposses.

I have been thinking about the solution and it seems to me that as far as the a) problem I could use simple circular buffers (8 buffers in maximum) consisting of 8 elements and set the execution period of the SL to be eight times the execution period of the FL. The FL will insert samples into the circular buffers and SL will take the samples out. The SL will have 100 us for taking out one sample from all circular buffers. It is more than enough time. 

As far as the b) problem. I am not hundred percent sure whether it is problem at all. Because the division of the circular buffers between the "pre-trigger" and "post-trigger" part is done in the SL. The new position of the "stop" is determined in case the FL is not being executed (ISR - FL- has higher priority than a SL task). It means that the new "stop" position can be used only at the beginning of FL execution inherently.

Do you thing that the solution I have suggested could work?

Hello Steven02,

the application you intent do develop is very interesting. 

As an alternative to

"monitor mainly stator currents, three phase voltage source inverter dc bus voltage and mechanical speed of the motor." and to "recording of the a[f]o[r]e mentioned variables before and after some by user specified events.", whereas "[t]he timing of the control software is based on A/D converter sampling period.?",

myself remembers, at first, 

- a DSP application note of Motorola 96K to control, respectively to control the generation of a three (or n) phase motor drive signals; and complementarily thereto, myself, at second, had to deal with 

- a patent application of NEC  which bases motor control on measuring resp. correspondent to the motor response, i.e. the signals which the motor adds during operation (harmonics, changes in signal shape, phase shifts, including phase shifts in harmonics, spectral energy density distribution) on the driving lines - using the lines bidirectionally (this can be regarded as an pulse radar application, and crazily enough, using a motor as a camera to resolve geometries would thus be even possible) of the inverter (in fact it is a power D/A Converter, eg. in Class D mode, ie. PWM, which is very powerful using the windowing, sampling - without an A(D convert (the signal is the A/D-Converter ... ),  resp. using discretisation effect of the synthesized PWM pulses or an IGBT Bridge) - in that DSP-control of the motor allows for the behavior of the motor accompanied by a simulation how the motor should react (with a neural network or artificial intelligence) - making kind of an intelligent motor (motor is sensor, actor and part of the control). I believe that this goes into the direction of "total control" or even "natural control" of a motor (- is the motor still "Hardware", is force "hardware" or is it "software" ? -) in that using the back-communication of the motor on the causal side, instead of sampling signals on the effect's side. I admit, this approach is not too easy to understand, and I won't bet that I can explain it so that instantly everybody says "wow", however it is tremendous. In case of interest as to the application note or the patent I would find that out.

Your solution sounds promising and very simple, reliable, (but needs not to be state of the art, in the direction of an intelligent motor) and I strongly expect that it works, but there exists possibly another solution with even less effort, a quasi-analog approach using the Power of PWM, and than you can use 74HC*.* Counters, PLLC and/or a software approach, using the physical model of old standard logic in the frame of object programming, so doing low lewel bit manipulation on high level software.

So is it possible to integrate what you want to motor in the control of the supply signals at an earlier stage so as to save the A/D Converter ?

You fairly would believe that it works. Namely, it is the signal that does the A/D conversion and the motor is used as reconstruction low pass.

regards,

+Roger.

Steve-

You won't need 8 buffers, that's for sure. My suggestion is to first modify your ISR to implement basic triggering, for example a simple amplitude threshold, and make sure you can obtain "clean display" of snapshots of your A/D data. By clean I mean a stable waveform display, no glitches, no buffer boundary problems. Until you get that far then worries about "execution time ratio", filtering, etc are pointless. You could then modify the triggering to be more advanced, for example if your input is a sine wave and your background code updates the amplitude threshold then you should see the sine wave shift left or right.

That's a step-by-step design and engineering approach, tried and true. I think once you get that far, you will find that some of the things you think you need you don't, and some things you didn't think of you do.

-Jeff