So where are the applications to hardware? Even one detailed example would be interesting.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
All the embedded stuff I recall doing in C/C++ defines the various port registers as volatile, so the compiler can't play games like that.
How would you ever make embedded code work if the compiler could randomly optimize away or reorder port accesses? You could never even poll a hardware flag.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Any actual thermocouple pair has a well-behaved, gently nonlinear characteristic V(T1,T2) that is a good match to any well-designed polynomial, spline, or rational-function fit technique. (You can even use rational trig functions, knock yourself out.)
It really isn't rocket science to fit a smooth nonlinearity of at most a few tens of percent over a wide temperature range, to any accuracy remotely required for temperature measurements.
Of course, if you do the calibration sufficiently badly, you can make problems for yourself, but they aren't specifically mathematical problems.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
I await David Brown's expert comment, but from
"This means that within a single thread of execution, a volatile access cannot be optimized out or reordered relative to another visible side effect that is separated by a sequence point from the volatile access."
"Note that volatile variables are not suitable for communication between threads; they do not offer atomicity, synchronization, or memory ordering."
Note that last caveat, and welcome to the world of modern aggressive optimisers. I'll refrain from commenting on some compiler writer's attitudes - see recent discussions in comp.arch if you are interested in that.
Having to *fully* understand all those subtle terms is one of the reasons that being able to read assembler code remains valuable :(
20 microseconds is a long time for a cache miss on a gigahertz processor. L1 cache lines are typically 64 bytes, no?
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
The end of a statement is a sequence point.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
In general, there are other caches in various forms, and there can be many misses.
I haven't recently checked what's in A9(?) ARMs, nor how each processor can interfere with the other.
If I wanted to use a Zynq (and they look like interesting devices) for hard realtime purposes, then I'd look at putting a traditional RTOS on one processor and a linux on the other.
My impression of Whit's post was that the calibration in a real system might be for compensating for tolerances of bias resistors, parasitic effects of ESD protection devices, and other board-level effects. The calibration is likely to remain a smooth function that (unless you've really made a mess of the hardware), but it may no longer be a good fit for the polynomial picked by the thermocouple manufacturer. So fitting to a cubic spline (or other suitable function, as you mentioned) based on real-life board measurements is going to make more sense than trying to force usage of the original ITS polynomial. (If you are not basing it on measurements, it is not calibration.)
That helps, provided the code is written in a sane /simple/ way.
I'm it is possible to create cases which are problematic. I've seen some remarkably bad code in my time :(
We hope that the published coefficients are based on some actual calibration, because AFAIK there's no sufficiently accurate first-principles calculation available that applies to real devices.
Resistor errors, offset voltages, leakage, and so on are normally smallish smooth effects of the sort that cause no problems for polynomial fitting.
I claim that polynomial fits get into trouble with:
discontinuities in value or low-order derivatives;
asymptotes (a biggie);
large changes in local behaviour, e.g. localized oscillations;
crappy fitting procedures, e.g. use of noisy data;
full stop.
I'd be very interested in examples outside that range.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Me too, but DB was just blowing smoke at JL with that silly example.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
And ill-conditioned basis sets, of course, but that's not a fundamental problem with polynomials per se.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
That's the common misunderstanding.
"volatile" tells the compiler (but not the processor, write buffers, cache, memory buffers, or any other hardware) that this particular access can't be omitted or re-ordered with respect to other volatile accesses or "observable behaviour".
But it says /nothing/ about re-ordering with respect to non-observable behaviour, such as calculations.
Supposing you want to find out how much time your cpu takes for a multiply instruction. You might write code like this:
// Obviously this would match a real register address extern volatile unsigned char pin;
extern unsigned int testresult;
void testmults(void) { pin = 1;
unsigned int t = 1; for (unsigned int x = 1; x How would you ever make embedded code work if the compiler could
The compiler can't re-order the volatile parts - but it can re-order everything else. A very common misunderstanding about volatile is that people often think volatile accesses also order other code and accesses
- they do not. (C11/C++11 atomic accesses can affect the order of other memory accesses, but not the order of code and calculations.)
Agreed.
You might add over-fitting to the list, but that is a problem of misunderstanding the use of polynomials rather than the polynomial itself.
And even with good basis sets, high-order polynomials can be harder to evaluate well on limited processors than low-order splines (cubic or linear). Again, that is not a fundamental problem with polynomials, but it is a practical issue.
A single polynomial will also be difficult to fit if there is a curve which simply doesn't match well with a reasonable degree polynomial. An exponential decay will look smooth, but need a surprisingly high degree polynomial to get a good approximation. You'll also have trouble with a curve with distinct regions, which can occur as different physical effects dominate in different parts of the graph.
None of this excludes the possibility of using a single high-order polynomial. But it can make it a lot less practical in comparison to a low-order spline.
The relevant of this is if you have:
volatile int v1, v2;
then you are not guaranteed anything about the number or order of reads if you write:
x = v1 + v2 + v2 + v1;
Each of "v1" and "v2" will be read, but they can be read once or twice and in any order, since there is no sequence point between their accesses.
It is the "visible side effect" (or, the C standards term, "observable behaviour") that is key here. "volatile" accesses order with respect to observable behaviour, which includes other volatile accesses. For anything other than observable behaviour, you have no guarantees of ordering at all. Sequence points don't affect that.
No. It was a side track, admittedly, but my logic is sound and matches real-world cases. The fact that you don't understand exactly how volatile works shows exactly my point - a lot of programmers /think/ they understand volatile, but get it subtly wrong. (Perhaps when you've read my longer reply, you'll see the point - I did not give many details in my first reply to John.)
Am 04.06.20 um 22:30 schrieb David Brown:
The Beaglebone Black has an 1 GHz ARM CPU and two PRUs. These are
200 MHz riscs without cache and interrupts, just some fast ram for data and code. Each PRU has fast access to a dozen pins or so. I could place edges in C with the full resolution of 5 nsec, and also read that way.cheers, Gerhard
Not application so much as a lack of difference between hardware and software.
Harel StateCharts are a formalisation of finite state machine diagrams, which can obviously be implemented in hardware, software, or a combination of the two.
UML diagrams are so legion that it is embarassing. The "Unified" is not far off the superset of diagrams from other methodologies. The the well known ones are class hierarchy diagrams, there are also "swimlane interaction" diagrams, and some that are hierarchical structural compositions of software components - just like hierarchical schematics complete with i/o ports connected by wires.
Hatley and Pirbhai is particularly interesting. They have two parallel decomposition hierarchies: specification and implementation. Any of the subcomponents can be specified in any way convenient, e.g. FSMs.
Every element in the specification hierarchy must have one or more corresponding entities in the implementation hierarchy, and they can be hardware, software, mechanical etc.
While the specification hierarchy is almost completely executable (and there may be tools to do that), the only part that Hatley And Pirbhai automated was a database that tracked the complex mappings between the various parts of the specification and implementation hierarchy components. In aerospace trackability is rather important.
In the enterprise arena, many patterns are recognisable, some even with accurately suggestive names such as "filter", "multiplexer", "demultiplexer", "event", "asynchronous X", "synchronous X", "control bus", "message bus", "channel".
One of many starting points is
Thanks, David. I knew you would have chapter and verse(!) at your fingertips!
Such considerations lead me to believe that most programmers that think they know C, actually don't.
It also makes me believe that C has become part of the problem(s) that implementers face. I would prefer it had remained part of the solution.
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.