1. Home
  2. Embedded Programming
  3. Shared Data Problem
  4. Page 3

Shared Data Problem

You, too, have presented the unachievable spec of "not delayed," yet the sequential instruction nature of microprocessors means that there will be delays. The trick is to first understand the system's acceptable level of delay and include sufficent performance in that system's hardware design to be able to meet that system's requirements reliably, even if one must disable interrupts for a few instructions to be able to accurately perform a non-atomic read of a shared variable.

I see, too, that you have specified a "simple system," just as did Robert Scott, yet you imply multitasking and you have both specified the rather stringent requirement of no jitter/delay. You simply cannot have it both ways!

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
          mkesti@gv.net            |          - The Who, Bargain
Reply to
Michael R. Kesti
Loading thread data ...

Certainly, and this is why one must ensure that one's hardware performance holds this compromise to acceptable limits.

This may very well be the result of attempts to describe the general case rather than the capabilities of specific systems.

Here we agree, as long as one's hardware supports the ability to do so.

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
          mkesti@gv.net            |          - The Who, Bargain
Reply to
Michael R. Kesti

I like the counter solution. It means the background can detect if data is lost rather than burden the ISR with this task and increase latency to boot.

snip

Yep, it is horses for courses as usual.

Ian

--
Ian Bell
Reply to
Ian Bell

Forgive my lax description. Perhaps I should have said 'overly delayed' of 'further delayed'. My point was the accuracy of the data depends on how soon after the interrupt occurs the data is collected. I realize this will inevitably have jitter imposed by the interrupt hardware itself and any other higher priority interrupts that happen to be being service at the time. I was trying to suggest there is likely to be enough factors contributing jitter without adding another.

That was just to show that it was unnecessary to invoke great complexity for the effect to be understood, not that it was confined to simple systems as you seem to imply.

Ian

--
Ian Bell
Reply to
Ian Bell

And one software performance too.

Agreed.

Ditto.

--
Ian Bell
Reply to
Ian Bell

The example I cited is not hypothetical. It is a real design that has been produced and is providing variable duty-cycle PWM signals to solenoids in an industrial test stand. The processor is a PIC 12C671. It converts an analog voltage command to a PWM duty cycle. If I were to do a hardware-only solution, then my single PIC would become an oscillator with triangle-wave output and a comparator. It would not have any better performance, and would take up considerably more room on the circuit board.

-Robert Scott Ypsilanti, Michigan

Reply to
Robert Scott

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.