On 2020-06-05 03:38, Tom Gardner wrote:> On 05/06/20 02:51, Phil Hobbs wrote: >> On 2020-06-04 12:42, Tom Gardner wrote: >>> On 04/06/20 17:22, jlarkin@highlandsniptechnology.com wrote: >>>> On Thu, 4 Jun 2020 16:10:06 +0100, Tom Gardner >>>> <spamjunk@blueyonder.co.uk> wrote: >>>> >>>>> On 04/06/20 00:59, John Larkin wrote: >>>>>> On Thu, 4 Jun 2020 00:25:35 +0100, Tom Gardner >>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>> >>>>>>> On 03/06/20 21:21, John Larkin wrote: >>>>>>>> On Wed, 3 Jun 2020 17:33:30 +0100, Tom Gardner >>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>>> >>>>>>>>> The similarities outweigh the differences. >>>>>>>> >>>>>>>> The similarities of that statement, six times, are tedious. >>>>>>> >>>>>>> Your misapprehensions on this topic are legion >>>>>>> and repetitive. >>>>>>> >>>>>>> >>>>>>>> Do you design electronics? >>>>>>> >>>>>>> I did, for decades. >>>>>>> >>>>>>> I also designed and implemented server-side software >>>>>>> for decades. >>>>>>> >>>>>>> Do you implement such software? >>>>>>> >>>>>>> (I believe you have said you leave that to others.) >>>>>> >>>>>> I wrote two compilers and three pre-emptive RTOSs and maybe a hundred >>>>>> embedded programs, >>>>> It is worth pointing out that all of those examples are >>>>> (almost certainly) very different to general purpose software >>>>> and, especially, to application servers and the applications >>>>> that run within them. >>>> >>>> What's not general about an RTOS? Thousands of units were sold. >>> >>> It is a single specialised program than can be used in >>> different end equipment. >>> >>> There's far more to software and software development >>> than that. >>> >>> >>> >>>>> Ditto your organisation and the organisations that write/maintain >>>>> such codebases. >>>>> >>>>> Thus it is unsurprising that you do not understand modern >>>>> medium/large scale software and software practices. Especially >>>>> the congruences with medium/large scale hardware. >>>> >>>> This is an electronic design group. I deal with the software that >>>> makes electronic instruments work. My relationship to servers is that >>>> I have to talk to them, feed them javascript and UDP packets and such. >>> >>> No doubt. >>> >>> But it confirms that you have no experience of creating >>> large-scale software systems using modern techniques. >>> >>> It is therefore unsurprising that you haven't understood >>> the congruences with hardware. >> >> Congruences between large scale software "using modern techniques" and >> hardware? Interesting! Since you're obviously expert in both, I'd >> like to learn more. > > More of a jack of all trades and master of none, by choice. > That has advantages and disadvantages. > > >> What are they, exactly? > > That would take a /long/ time to discuss, especially if > half the concepts are unfamiliar to the audience. > To take /one/ example > - how application server frameworks are designed > and implemented > - design patterns in the applications' components > and the way they are composed to form an application, > - design patterns used to communicate with the outside > world, > - antipatterns found in politics, development and design > > It is a good topic for a conversation in pubs. > > I normally start it by provocatively asking someone to > distinguish between hardware and software. They normally > claim it is obvious and come up with a definition. Then > I introduce them to examples that don't fit their definition. > Rinse and repeat. > > Sometimes it can take a long time to realise what the > proponents of a particular technique are doing, because > they use unfamiliar terms to describe things that are > standard in other fields. > > Some examples: > - Jackson's Structured Programming > - Harel StateCharts > - many of the more esoteric UML diagrams > - Hatley and Pirbhai's Strategies for Realtime Systems > Specification, as successfully used for the Boeing 777 > - and, obviously, object oriented programmingSo 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
KiCad Spice, Anyone Tried It?
Started by ●June 2, 2020
Reply by ●June 5, 20202020-06-05
Reply by ●June 5, 20202020-06-05
On 2020-06-05 04:05, David Brown wrote:> On 05/06/2020 04:24, jlarkin@highlandsniptechnology.com wrote: >> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >> <david.brown@hesbynett.no> wrote: >> >> >>>> >>>> That's what I have to do, use an oscilloscope to show programmers what >>>> their code does. You can often relate the pulse widths to paths >>>> through the code. >>>> >>> >>> A scope can be a fine tool for measuring code performance. I like to >>> make sure there are a few test pins on our boards that can be connected >>> to an oscilloscope precisely for measuring critical code. Not all >>> programmers understand how to instrument code for such measurements, >>> unfortunately. >> >> Raise a port pin at the start of the routine, and drop it at the end. >> Maybe invert it a couple of times, at interesting points. > > And how do you know that you are raising it at the /real/ start of the > routine, and dropping it at the /real/ end of the routine? I've seen > people write code like : > > ... > set_pin_hi_macro(); > x = big_calculation(); > set_pin_lo_macro(); > ... > > without realising that the compiler (and processor, for more advanced > cpus) can re-order a lot of that and make the timing seriously unrealistic.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
Reply by ●June 5, 20202020-06-05
On 2020-06-04 22:58, whit3rd wrote:> On Thursday, June 4, 2020 at 9:14:43 AM UTC-7, jla...@highlandsniptechnology.com wrote: >> On Thu, 4 Jun 2020 16:10:35 +0100, Tom Gardner >> <spamjunk@blueyonder.co.uk> wrote: >> >>> On 04/06/20 15:26, David Brown wrote: > >>>> If someone asked me to make a 5th order polynomial for calibration, I'd say >>>> "No. Let's look at the system and see how to handle it /properly/". Any >>>> polynomial above 3rd order is likely (not guaranteed, but likely) to be wrong - >>>> over-fitted, unstable, or both. > >> The official ITS thermocouple voltage-temperature equations range from >> 8th order to 14th order for various thermocouples. We make both >> thermocouple acquisition and simulation products. If anyone refused to >> implement the ITS equations, of course I'd fire them, for stupidity if >> nothing else. > > But the ITS equations are a temperature scale, that apply to all thermocouples > of a type. Calibration includes instrument peculiarities that aren't known > except after construction of the whole instrument. Not > all calibrations have continuous, well-behaved functional nature, > but all polynomials do. > > The general class of calibrations isn't automatically fit to a polynomial. >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
Reply by ●June 5, 20202020-06-05
On 05/06/20 09:45, Phil Hobbs wrote:> On 2020-06-05 04:05, David Brown wrote: >> On 05/06/2020 04:24, jlarkin@highlandsniptechnology.com wrote: >>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >>> <david.brown@hesbynett.no> wrote: >>> >>> >>>>> >>>>> That's what I have to do, use an oscilloscope to show programmers what >>>>> their code does. You can often relate the pulse widths to paths >>>>> through the code. >>>>> >>>> >>>> A scope can be a fine tool for measuring code performance. I like to >>>> make sure there are a few test pins on our boards that can be connected >>>> to an oscilloscope precisely for measuring critical code. Not all >>>> programmers understand how to instrument code for such measurements, >>>> unfortunately. >>> >>> Raise a port pin at the start of the routine, and drop it at the end. >>> Maybe invert it a couple of times, at interesting points. >> >> And how do you know that you are raising it at the /real/ start of the >> routine, and dropping it at the /real/ end of the routine? I've seen people >> write code like : >> >> ... >> set_pin_hi_macro(); >> x = big_calculation(); >> set_pin_lo_macro(); >> ... >> >> without realising that the compiler (and processor, for more advanced cpus) >> can re-order a lot of that and make the timing seriously unrealistic. > > 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.I await David Brown's expert comment, but from https://en.cppreference.com/w/c/language/volatile "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 :(
Reply by ●June 5, 20202020-06-05
On 2020-06-05 03:49, Tom Gardner wrote:> On 05/06/20 03:24, jlarkin@highlandsniptechnology.com wrote: >> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >> <david.brown@hesbynett.no> wrote: >> >> >>>> >>>> That's what I have to do, use an oscilloscope to show programmers what >>>> their code does. You can often relate the pulse widths to paths >>>> through the code. >>>> >>> >>> A scope can be a fine tool for measuring code performance. I like to >>> make sure there are a few test pins on our boards that can be connected >>> to an oscilloscope precisely for measuring critical code. Not all >>> programmers understand how to instrument code for such measurements, >>> unfortunately. >> >> Raise a port pin at the start of the routine, and drop it at the end. >> Maybe invert it a couple of times, at interesting points. > > Yes, it isn't rocket science. > > If the test point reflects the "idle" time, you can even > put a voltmeter (preferable moving coil!) on it to visualise > the processor utilisation. Dirty, but quick. > > >> We did one test on a Zynq, dual 600 MHz ARMs running the usual Linux. >> One program just toggled a pin as hard as it could, and we looked at >> that on a scope to see how much other things suspended the loop. We'd >> see occasional long highs or lows, "long" being numbers like 20 us. I >> was impressed. The linux periodic interrupt only took a few >> microseconds. > > Did you form an opinion as to what caused the pauses? > > Did the "other stuff" manage/avoid interfering with > the caches?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
Reply by ●June 5, 20202020-06-05
On 2020-06-05 05:07, Tom Gardner wrote:> On 05/06/20 09:45, Phil Hobbs wrote: >> On 2020-06-05 04:05, David Brown wrote: >>> On 05/06/2020 04:24, jlarkin@highlandsniptechnology.com wrote: >>>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >>>> <david.brown@hesbynett.no> wrote: >>>> >>>> >>>>>> >>>>>> That's what I have to do, use an oscilloscope to show programmers >>>>>> what >>>>>> their code does. You can often relate the pulse widths to paths >>>>>> through the code. >>>>>> >>>>> >>>>> A scope can be a fine tool for measuring code performance. I like to >>>>> make sure there are a few test pins on our boards that can be >>>>> connected >>>>> to an oscilloscope precisely for measuring critical code. Not all >>>>> programmers understand how to instrument code for such measurements, >>>>> unfortunately. >>>> >>>> Raise a port pin at the start of the routine, and drop it at the end. >>>> Maybe invert it a couple of times, at interesting points. >>> >>> And how do you know that you are raising it at the /real/ start of >>> the routine, and dropping it at the /real/ end of the routine? I've >>> seen people write code like : >>> >>> ... >>> set_pin_hi_macro(); >>> x = big_calculation(); >>> set_pin_lo_macro(); >>> ... >>> >>> without realising that the compiler (and processor, for more advanced >>> cpus) can re-order a lot of that and make the timing seriously >>> unrealistic. >> >> 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. > > I await David Brown's expert comment, but from > https://en.cppreference.com/w/c/language/volatile > > "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."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
Reply by ●June 5, 20202020-06-05
On 05/06/20 10:24, Phil Hobbs wrote:> On 2020-06-05 03:49, Tom Gardner wrote: >> On 05/06/20 03:24, jlarkin@highlandsniptechnology.com wrote: >>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >>> <david.brown@hesbynett.no> wrote: >>> >>> >>>>> >>>>> That's what I have to do, use an oscilloscope to show programmers what >>>>> their code does. You can often relate the pulse widths to paths >>>>> through the code. >>>>> >>>> >>>> A scope can be a fine tool for measuring code performance. I like to >>>> make sure there are a few test pins on our boards that can be connected >>>> to an oscilloscope precisely for measuring critical code. Not all >>>> programmers understand how to instrument code for such measurements, >>>> unfortunately. >>> >>> Raise a port pin at the start of the routine, and drop it at the end. >>> Maybe invert it a couple of times, at interesting points. >> >> Yes, it isn't rocket science. >> >> If the test point reflects the "idle" time, you can even >> put a voltmeter (preferable moving coil!) on it to visualise >> the processor utilisation. Dirty, but quick. >> >> >>> We did one test on a Zynq, dual 600 MHz ARMs running the usual Linux. >>> One program just toggled a pin as hard as it could, and we looked at >>> that on a scope to see how much other things suspended the loop. We'd >>> see occasional long highs or lows, "long" being numbers like 20 us. I >>> was impressed. The linux periodic interrupt only took a few >>> microseconds. >> >> Did you form an opinion as to what caused the pauses? >> >> Did the "other stuff" manage/avoid interfering with >> the caches? > > 20 microseconds is a long time for a cache miss on a gigahertz processor. L1 > cache lines are typically 64 bytes, no?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.
Reply by ●June 5, 20202020-06-05
On 05/06/2020 10:54, Phil Hobbs wrote:> On 2020-06-04 22:58, whit3rd wrote: >> On Thursday, June 4, 2020 at 9:14:43 AM UTC-7, >> jla...@highlandsniptechnology.com wrote: >>> On Thu, 4 Jun 2020 16:10:35 +0100, Tom Gardner >>> <spamjunk@blueyonder.co.uk> wrote: >>> >>>> On 04/06/20 15:26, David Brown wrote: >> >>>>> If someone asked me to make a 5th order polynomial for calibration, >>>>> I'd say >>>>> "No. Let's look at the system and see how to handle it >>>>> /properly/". Any >>>>> polynomial above 3rd order is likely (not guaranteed, but likely) >>>>> to be wrong - >>>>> over-fitted, unstable, or both. >> >>> The official ITS thermocouple voltage-temperature equations range from >>> 8th order to 14th order for various thermocouples. We make both >>> thermocouple acquisition and simulation products. If anyone refused to >>> implement the ITS equations, of course I'd fire them, for stupidity if >>> nothing else. >> >> But the ITS equations are a temperature scale, that apply to all >> thermocouples >> of a type. Calibration includes instrument peculiarities that aren't >> known >> except after construction of the whole instrument. Not >> all calibrations have continuous, well-behaved functional nature, >> but all polynomials do. >> >> The general class of calibrations isn't automatically fit to a >> polynomial. >> > > 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. >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.)
Reply by ●June 5, 20202020-06-05
On 05/06/20 10:25, Phil Hobbs wrote:> On 2020-06-05 05:07, Tom Gardner wrote: >> On 05/06/20 09:45, Phil Hobbs wrote: >>> On 2020-06-05 04:05, David Brown wrote: >>>> On 05/06/2020 04:24, jlarkin@highlandsniptechnology.com wrote: >>>>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >>>>> <david.brown@hesbynett.no> wrote: >>>>> >>>>> >>>>>>> >>>>>>> That's what I have to do, use an oscilloscope to show programmers what >>>>>>> their code does. You can often relate the pulse widths to paths >>>>>>> through the code. >>>>>>> >>>>>> >>>>>> A scope can be a fine tool for measuring code performance. I like to >>>>>> make sure there are a few test pins on our boards that can be connected >>>>>> to an oscilloscope precisely for measuring critical code. Not all >>>>>> programmers understand how to instrument code for such measurements, >>>>>> unfortunately. >>>>> >>>>> Raise a port pin at the start of the routine, and drop it at the end. >>>>> Maybe invert it a couple of times, at interesting points. >>>> >>>> And how do you know that you are raising it at the /real/ start of the >>>> routine, and dropping it at the /real/ end of the routine? I've seen people >>>> write code like : >>>> >>>> ... >>>> set_pin_hi_macro(); >>>> x = big_calculation(); >>>> set_pin_lo_macro(); >>>> ... >>>> >>>> without realising that the compiler (and processor, for more advanced cpus) >>>> can re-order a lot of that and make the timing seriously unrealistic. >>> >>> 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. >> >> I await David Brown's expert comment, but from >> https://en.cppreference.com/w/c/language/volatile >> >> "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." > > The end of a statement is a sequence point.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 :(
Reply by ●June 5, 20202020-06-05
On 2020-06-05 05:40, David Brown wrote:> On 05/06/2020 10:54, Phil Hobbs wrote: >> On 2020-06-04 22:58, whit3rd wrote: >>> On Thursday, June 4, 2020 at 9:14:43 AM UTC-7, >>> jla...@highlandsniptechnology.com wrote: >>>> On Thu, 4 Jun 2020 16:10:35 +0100, Tom Gardner >>>> <spamjunk@blueyonder.co.uk> wrote: >>>> >>>>> On 04/06/20 15:26, David Brown wrote: >>> >>>>>> If someone asked me to make a 5th order polynomial for >>>>>> calibration, I'd say >>>>>> "No. Let's look at the system and see how to handle it >>>>>> /properly/". Any >>>>>> polynomial above 3rd order is likely (not guaranteed, but likely) >>>>>> to be wrong - >>>>>> over-fitted, unstable, or both. >>> >>>> The official ITS thermocouple voltage-temperature equations range from >>>> 8th order to 14th order for various thermocouples. We make both >>>> thermocouple acquisition and simulation products. If anyone refused to >>>> implement the ITS equations, of course I'd fire them, for stupidity if >>>> nothing else. >>> >>> But the ITS equations are a temperature scale, that apply to all >>> thermocouples >>> of a type. Calibration includes instrument peculiarities that >>> aren't known >>> except after construction of the whole instrument. Not >>> all calibrations have continuous, well-behaved functional nature, >>> but all polynomials do. >>> >>> The general class of calibrations isn't automatically fit to a >>> polynomial. >>> >> >> 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. >> > > 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.) >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
