On Thu, 4 Jun 2020 14:08:42 -0700 (PDT), jjhudak4@gmail.com wrote:>On Thursday, June 4, 2020 at 4:08:26 PM UTC-4, John Larkin wrote: >> On Thu, 4 Jun 2020 21:43:14 +0200, David Brown >> <david.brown@hesbynett.no> wrote: >> >> >On 04/06/2020 17:31, jlarkin@highlandsniptechnology.com wrote: >> >> On Thu, 4 Jun 2020 16:26:12 +0200, David Brown >> >> <david.brown@hesbynett.no> wrote: >> >> >> >>> On 04/06/2020 01:59, John Larkin wrote: >> >>>> >> >>>> My kids are pretty good with Python for test software. I ask, can you >> >>>> do a 5th order polynomial to calibrate that DAC? They say, sure. >> >>>> >> >>> >> >>> If someone asked me to make a 5th order polynomial for calibration, I'd >> >>> say "No. >> >> >> >> And I'd fire you, and we'd both be happy. >> > >> >What a telling reaction. >> > >> >Norway invariably beats the USA on all "happiness" comparisons. And the >> >two biggest differences I see between how people work in the USA and how >> >people work in Norway is that over here, if the boss tells you to do >> >something stupid, you question him or her. >> >> You didn't say you would question, you said that you'd refuse. >> >> I was kinda surprised when one of my engineers told me that a 5th >> order poly was best to calibrate a timing system. But since he was >> right, I didn't say "No" or anything obtuse like that. We can easily >> take a couple hundred data points to picosecond, sometimes >> femtosecond, accuracy. Lots of points smooths out the jitter. >> >> >> >> >> The other is that we have >> >job security - you need a very good reason, and a sensible time frame, >> >in order to fire someone. This all gives a health, cooperative and >> >supportive working relationship instead of employees who spend their >> >lives terrified of irritating their boss and ending up on the street >> >(and simultaneously losing their health care). >> >> California is an "at will" state; we can lay off or fire anyone, any >> time, for any reason or none. Similarly, they can quit any time they >> want, walk right out the door, no matter how much it might damage the >> company. >> >> That's symmetric. >> >> No boss has ever terrified me; quite the opposite. >> >> >> >> > >> >> >> >> 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. >> >>> >> >>>>> >> >>>>> Nowadays most systems/products are a combination of hardware >> >>>>> and software. Choosing the appropriate boundary between the two >> >>>>> is often critical, and distressingly few people can do it >> >>>>> effectively. >> >>>> >> >>>> It's great fun to design a product where you can do stuff analog or >> >>>> digital, in hardware or FPGA or uP code. Brainstorming with the FPGA >> >>>> and c people helps a lot. >> >>>> >> >>>> I do have a hard time pinning the c people down to times. Can you run >> >>>> that IRQ at 200 KHz for me? >> >>>> >> >>> >> >>> Sure - /if/ you've got the right hardware, and proper specifications for >> >>> the task. >> >> >> >> I knew he could run my filter/control algorithm at 200K, and in fact >> >> crank down the CPU clock to save power. But it's hard to get classic c >> >> programmers to push the realtime limits, or to even estimate runtimes. >> >> >> > >> >I don't know what the phrase "classic C programmer" might mean. >> > >> >> I wrote a couple of cross-assemblers that added instruction execution >> >> times to the listing so I could see runtimes directly. Caches and such >> >> make that less precise nowadays. >> >> >> > >> >All sorts of things make it difficult to calculate accurately the run >> >time of non-trivial code. You might be able to make some rough >> >estimates, but generally measurement is better. >> >> 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. >> >> >> >> -- >> >> John Larkin Highland Technology, Inc >> picosecond timing precision measurement >> >> jlarkin att highlandtechnology dott com >> http://www.highlandtechnology.com > >Ahhh the old bang a bit on the I/O port trick to get timing measurements in code theads...brings back memories >....then there is the write different values to a DAC trick....Or use a logic analyzer and get visual traces through executing code.� >Used it on more than one occasion to convince the SW types that 'yes, your code is not correct and my CPU board really does work'.... > I *really* like my keysight 4164.... >JI've never used a logic analyzer. I think one of my guys occasionally uses a little USB analyzer pod. He can also build a LA into an FPGA and load a trace RAM with an event. We're doing that now to look at the startup transient of a very complex digital PLL, saving a couple thousand ADC and DAC and integrator samples in a burst. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
KiCad Spice, Anyone Tried It?
Started by ●June 2, 2020
Reply by ●June 4, 20202020-06-04
Reply by ●June 4, 20202020-06-04
On Thu, 4 Jun 2020 21:51:29 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> 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. > >What are they, exactly? > >Cheers > >Phil HobbsI've been waiting, with a basically sour attitude, for someone to try to reduce PCB-level electronic design to some sort of Verilog-like, C++-like, structured, abstract, object-oriented language. I think it has been tried, to some extent. What ever happened to the NI attempt to reduce logic design to hooking up little boxes on the screen, the Labview for FPGAs thing? -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 4, 20202020-06-04
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.
Reply by ●June 5, 20202020-06-05
On 05/06/2020 00:47, pcdhobbs@gmail.com wrote:>> The official ITS thermocouple voltage-temperature equations range >> from 8th order to 14th order for various thermocouples. > > That's the sort of example DB has in mind, I think. Polynomials do > have certain limitations as fit functions, mostly having to do with > fitting functions that don't look like polynomials--things with > discontinuities or asymptotes, for instance. No matter what you do, > you can't fit 1/x or exp(-x) over any reasonably wide range with a > polynomial. > > The reason is that if you apply Taylor's theorem with remainder, the > relative error gets much worse as |x| increases. For an empirical > fit, extrapolating outside the fit region makes it worse, fast, > because the higher order terms increase without bound. > > However, for gentle nonlinearities such as ADC INL and RTDs, where > the high order terms are easily bounded and you don't extrapolate, > polynomials are terrific, as you say. > > The problem with the thermocouple fit functions are ridiculous has > nothing to do with the mathematical properties of polynomials per se. > Orthogonal polynomials are super useful for representing functions, > and in fact expanding a function in Chebyshev polynomials is > identical with the real-valued Fourier transform of the same function > evaluated on a warped X axis. > > The big problem is with the representation in terms of the basis set > {X^N}, which is badly ill-conditioned, so that as |x| becomes large, > the number of decimal places required to maintain accuracy explodes. >That is an extremely important point, and you explained it well. The polynomials given for things like thermistors and thermocouples are usually in the form "a + b.x + c.x² + d.x³ + ...", where the later terms get very small but can be very sensitive to errors. Orthogonal polynomials or other basis sets give more stable functions.> Forman Acton's classic "Numerical Methods That Work" is still an > excellent read on that stuff. It's full of lore, but as readable as a > young adult novel. > > Cheers > > Phil Hobbs > > > >
Reply by ●June 5, 20202020-06-05
On 05/06/20 02:47, Bill Sloman wrote:> Feynman was ingenious, which is to say he did unexpected things that worked.I liked his metaphor of having different tools in his toolbox, which he could whip out and use on other people's problems.> John Larkin likes to think that the unexpected aspect is crucial.Crucial? Not usually.>> I almost got to see Feynman in 1986, when he came to >> Cambridge to give a talk. But the queue was too long:( > I made it. Good talk, but not exactly life-changing.I didn't expect it would have been - he was ageing at that point. The interest would have been a pale Erdos number sort of thing
Reply by ●June 5, 20202020-06-05
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 programming
Reply by ●June 5, 20202020-06-05
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?
Reply by ●June 5, 20202020-06-05
On 04/06/20 21:08, John Larkin wrote:> On Thu, 4 Jun 2020 21:43:14 +0200, David Brown > <david.brown@hesbynett.no> wrote: >> >> All sorts of things make it difficult to calculate accurately the run >> time of non-trivial code. You might be able to make some rough >> estimates, but generally measurement is better. > > 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.I've used analogous techniques in telecoms applications running in both and out of JAIN servers and. It was great for: - astounding people at how fast/efficient my design strategy and code was compared with their previous products - demonstrating to other companies exactly where their code was faulty - thus avoiding CEOs and lawyers becoming involved :) The biggest problem was getting softies to understand why the mean value is so crude, and that a 95% value was much more useful.
Reply by ●June 5, 20202020-06-05
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. Using pins and scopes to measure software performance is a useful technique, but you do have to understand how to avoid re-ordering issues and make sure you are measuring what you /think/ you are measuring. (This applies to any kind of instrumentation, not just pin/scope measurements.) Not all programmers understand the details here, and end up with something that looks okay but does not do what they want.> > 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. >With care (especially processor affinity and interrupt control), you can get real-time tasks on an SMP Linux system running with extremely low latencies and jitter. But it is still very difficult to be /sure/ of the maximum latencies.
Reply by ●June 5, 20202020-06-05
On 2020-06-04 22:40, jlarkin@highlandsniptechnology.com wrote:> On Thu, 4 Jun 2020 21:51:29 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> 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. >> >> What are they, exactly? >> >> Cheers >> >> Phil Hobbs > > I've been waiting, with a basically sour attitude, for someone to try > to reduce PCB-level electronic design to some sort of Verilog-like, > C++-like, structured, abstract, object-oriented language. I think it > has been tried, to some extent. > > What ever happened to the NI attempt to reduce logic design to hooking > up little boxes on the screen, the Labview for FPGAs thing?The same thing that happened to their idea of using Labview for anything real outside somebody's lab. As an old pal put it, "Ah, Labview--spaghetti code that even *looks* like spaghetti." ;) 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
