0
\$\begingroup\$

I have been writing a control software for field oriented control of three phase induction motor. As far as the platform I have been using the FreeRTOS real time operating system. My plan is to calculate the whole torque control loop in the interrupt service routine associated with end of the A/D conversion interrupt which will be invoked regularly with 100 us period. Besides the torque control loop the associated isr will be also responsible for implementation of software oscilloscope. Operation of the software oscilloscope will be configurable in such a manner that it will be possible to set how many samples are reserved for the pre-trigger, to set the trigger variable and trigger condition (given variable greater than or less than the specified value).

My question is how to pass the oscilloscope configuration into the interrupt service routine (more precisely into the oscilloscope module which is invoked from the isr) in such a manner that it is ensured that in all cases the oscilloscope works with consistent configuration i.e. always new pre-trigger setting, new trigger variable and new trigger condition are used together (it is not allowed to use let´s say new pre-trigger setting, new trigger variable with old trigger condition).

My idea was to exploit disabling of the interrupts in case configuration of the oscilloscope will being changed. But I have doubts regarding the negative impact on the torque control loop execution. Does anybody have better idea how to resolve that? Thanks in advance for any ideas.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ You shouldn't be doing that in an ISR especially not if you have an RTOS, the whole point of an RTOS is running tasks at consistent times. Leave the new settings and pick them up next time around, look at the offered thread communication mechanisms. \$\endgroup\$
    – Chris Stratton
    Commented Jun 18, 2020 at 12:50
  • \$\begingroup\$ @ChrisStratton thank you for your reaction. Do you have any particular solution in your mind? What will be the difference from the perspective of my problem when the ISR will be replaced by some task? \$\endgroup\$
    – Steve
    Commented Jun 18, 2020 at 13:06
  • \$\begingroup\$ The point is that you are not really using the RTOS if you do it your way. If you want to use a tool you have to take time to understand how solutions are supposed to be structured around it. Schedule this task periodically and use one of the thread communication mechanisms to give it the new settings. \$\endgroup\$
    – Chris Stratton
    Commented Jun 18, 2020 at 13:10
  • \$\begingroup\$ Is it possible to achieve task execution period equal 100 us? Maybe I have something missed but I don´t think so. In my opinion from the perspective of my problem it is irrelevent whether the ISR or task is used. In both cases I have another execution thread into which I need to pass data in consistent manner. \$\endgroup\$
    – Steve
    Commented Jun 18, 2020 at 13:19
  • \$\begingroup\$ If you don't want to use the RTOS you could consider doing everything in a loop, polling the inputs which could develop into new requests at the end. You can probably just have a settings struct and a staging copy and flags that mean dump state and copy in the new values the next time through. But if you're not going to use the RTOS you should strip it out entirely. \$\endgroup\$
    – Chris Stratton
    Commented Jun 18, 2020 at 13:25

1 Answer 1

Reset to default
0
\$\begingroup\$

Most benchtop oscilloscopes enter one setting at a time. This way during the configuration the oscilloscope will display garbage because it is using partly old and partly new settings. Then when the configuration is complete it will display the desired waveform.

Oscilloscopes have a concept known as arming the trigger. This is very clear in Single shot mode. Arming the trigger gets a single acquisition. In Auto and Normal modes, this is still the case but the Oscilloscope automatically arms the trigger internally. The catch 22 is that the trigger is not armed immediately after the completion of the previous acquired waveform. There is a delay for processing the data.

What you can do is use the same behavior. Have the ISR check if the trigger is armed. If it is armed then read in the configuration. Set the routine such that the very first thing it does is disarm the trigger. Then change the configuration. Then rearm the trigger as the routine exits.

While the trigger is disarmed just don't do anything in the ISR.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.