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.comAhhh 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.... J
KiCad Spice, Anyone Tried It?
Started by ●June 2, 2020
Reply by ●June 4, 20202020-06-04
Reply by ●June 4, 20202020-06-04
>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. 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 4, 20202020-06-04
On 04/06/20 20:51, John Larkin wrote:> On Thu, 4 Jun 2020 20:09:03 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> On 04/06/20 18:14, John Larkin wrote: >>> On Thu, 4 Jun 2020 17:42:22 +0100, Tom Gardner >>> <spamjunk@blueyonder.co.uk> 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. >>> >>> Good grief, this is an electronic design forum. I'm an electrical >>> engineer. >> >> Software and electronic have been completely entwined for >> almost half a century. >> >> As a competent electronic engineer you are unwise to make >> strong statements in spheres where you have limited experience. > > Unwise? Because I don't meet your expectations? Because I use ITC > thermocouple equations?Unwise because it makes you look ignorant and/or foolish and/or arrogant. "Better to keep your mouth closed and be thought a fool than to open it and demonstrate you are a fool".> We get purchase orders for electronics things, from people that you > have heard of, and they are happy with what we make for them. > > Given that, or being some google coder droid, I like the hardware. > > Post some electronics now and then and we'll discuss it.What's the relevance of that to the subject being discussed, viz modern large software systems? Basically it is mere flack: true but irrelevant and designed to deflect attention. Sorry, it has the opposite effect.
Reply by ●June 4, 20202020-06-04
On Thu, 4 Jun 2020 15:47:59 -0700 (PDT), 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.Some of the thermocouple tables have two regions, with different coefficients. That's impressive, since thermocouple voltages change softly with temperature.> >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.Nobody here wants to argue with the ITS equations. We either code them full-tilt, or sometimes use them to build lookup tables that we can interpolate into.> >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.No comment.> >Cheers > >Phil Hobbs > > >-- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●June 4, 20202020-06-04
On Fri, 5 Jun 2020 00:34:56 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 04/06/20 20:51, John Larkin wrote: >> On Thu, 4 Jun 2020 20:09:03 +0100, Tom Gardner >> <spamjunk@blueyonder.co.uk> wrote: >> >>> On 04/06/20 18:14, John Larkin wrote: >>>> On Thu, 4 Jun 2020 17:42:22 +0100, Tom Gardner >>>> <spamjunk@blueyonder.co.uk> 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. >>>> >>>> Good grief, this is an electronic design forum. I'm an electrical >>>> engineer. >>> >>> Software and electronic have been completely entwined for >>> almost half a century. >>> >>> As a competent electronic engineer you are unwise to make >>> strong statements in spheres where you have limited experience. >> >> Unwise? Because I don't meet your expectations? Because I use ITC >> thermocouple equations? > >Unwise because it makes you look ignorant and/or foolish >and/or arrogant. > >"Better to keep your mouth closed and be thought a fool >than to open it and demonstrate you are a fool". > > > >> We get purchase orders for electronics things, from people that you >> have heard of, and they are happy with what we make for them. >> >> Given that, or being some google coder droid, I like the hardware. >> >> Post some electronics now and then and we'll discuss it. > >What's the relevance of that to the subject being discussed, >viz modern large software systems?Why would you discuss that in an electronic design forum? Take that somewhere else.> >Basically it is mere flack: true but irrelevant and designed to >deflect attention. > >Sorry, it has the opposite effect.Good book: https://www.amazon.com/What-Care-Other-People-Think/dp/0393355640/ref=sr_1_1?crid=1N094TUR21JN8&dchild=1&keywords=feynman+what+do+you+care+what+other+people+think&qid=1591315148&sprefix=feinman+what+do+you+care%2Caps%2C215&sr=8-1 Pretty smart guy. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●June 4, 20202020-06-04
On 05/06/20 01:01, John Larkin wrote:> On Fri, 5 Jun 2020 00:34:56 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> On 04/06/20 20:51, John Larkin wrote: >>> On Thu, 4 Jun 2020 20:09:03 +0100, Tom Gardner >>> <spamjunk@blueyonder.co.uk> wrote: >>> >>>> On 04/06/20 18:14, John Larkin wrote: >>>>> On Thu, 4 Jun 2020 17:42:22 +0100, Tom Gardner >>>>> <spamjunk@blueyonder.co.uk> 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. >>>>> >>>>> Good grief, this is an electronic design forum. I'm an electrical >>>>> engineer. >>>> >>>> Software and electronic have been completely entwined for >>>> almost half a century. >>>> >>>> As a competent electronic engineer you are unwise to make >>>> strong statements in spheres where you have limited experience. >>> >>> Unwise? Because I don't meet your expectations? Because I use ITC >>> thermocouple equations? >> >> Unwise because it makes you look ignorant and/or foolish >> and/or arrogant. >> >> "Better to keep your mouth closed and be thought a fool >> than to open it and demonstrate you are a fool". >> >> >> >>> We get purchase orders for electronics things, from people that you >>> have heard of, and they are happy with what we make for them. >>> >>> Given that, or being some google coder droid, I like the hardware. >>> >>> Post some electronics now and then and we'll discuss it. >> >> What's the relevance of that to the subject being discussed, >> viz modern large software systems? > > Why would you discuss that in an electronic design forum? Take that > somewhere else.Software and electronic have been completely entwined for almost half a century. You made globally applicable statements based on your understanding of a small part of the software ecosphere that existed decades ago. Technology has moved on since then. Hence it is unsurprising that your statements were, um, inadequate.>> Basically it is mere flack: true but irrelevant and designed to >> deflect attention. >> >> Sorry, it has the opposite effect. > > Good book: > > https://www.amazon.com/What-Care-Other-People-Think/dp/0393355640/ref=sr_1_1?crid=1N094TUR21JN8&dchild=1&keywords=feynman+what+do+you+care+what+other+people+think&qid=1591315148&sprefix=feinman+what+do+you+care%2Caps%2C215&sr=8-1 > > Pretty smart guy.I'm not sure what relevance that has to the similar characteristics of software and electronics. I almost got to see Feynman in 1986, when he came to Cambridge to give a talk. But the queue was too long :(
Reply by ●June 4, 20202020-06-04
On 2020-06-04 19:57, John Larkin wrote:> On Thu, 4 Jun 2020 15:47:59 -0700 (PDT), 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. > > Some of the thermocouple tables have two regions, with different > coefficients. That's impressive, since thermocouple voltages change > softly with temperature.You're quite right, and it's a pointer to the real cause: the badness of {X**N} as a basis set. If you take a long Taylor series around T=0K and do the math to centre it at T = 300K, you wind up with a lot of high-order terms of the form T**N x 300K**(M-N), some with very large coefficients. Even after collecting terms, that'll make the coefficients of powers of T move around quite a bit just due to roundoff. Powers of T really aren't the right basis set except in intervals that include absolute zero. Shifted Chebyshev polynomials are the bomb for that, especially with the Clenshaw-Curtis recursion that makes their evaluation very nearly efficient as the usual Horner rule for the powers-of-X basis, and of course dramatically better conditioned in general.>> 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. > > Nobody here wants to argue with the ITS equations. We either code > them full-tilt, or sometimes use them to build lookup tables that we > can interpolate into.I haven't tried it myself, so I'll happily defer to your experience within the temperature range you care about. IIRC there was a discussion here some months ago about the badness of high-order expansions in powers of X**N, at least in situations where the contributions of high order terms weren't provably small. As a physicist, I've had orthogonal polynomials up the wazoo, so the badness of the basis set {X**N} is really ingrained. I haven't needed to do a really high accuracy functional approximation in some years, but when I do, my go-to technique is to use ratios of Chebyshev polynomials computed via FFTs of function sampled on Chebyshev abscissae. It's really pretty--I learned it from the first edition of Numerical Recipes over 30 years ago when I was young and keen. I coded it up and still have it. You sample the function at the appropriate Chebyshev abscissae, FFT to get the Nth order Chebyshev expansion (where N >> the number of orders you need), then construct rational functions of the form sum(i=0 to N) A_i T_i(x) f_N,M(x) = -------------------------- 1 + sum (j=1 to M) A_j T_j(x) By equating this to the computed FFT expansion, multiplying through by the denominator, and applying the Chebyshev orthogonality rules up to order J+M, you come up with a unique, generally well-conditioned expression for the numerator and denominator of the rational function. You can trade off N vs M to get the best accuracy, but in general functions with asymptotes fit best when M > N. For functions I've used it on, this simple direct method gets within a decibel or so of the best minimax rational function approximations.>> 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. > > No comment.It's really a great read, despite being 50 or so years old, which is antediluvian for most computing books. I hope you like it. 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 4, 20202020-06-04
On Friday, June 5, 2020 at 10:29:30 AM UTC+10, Tom Gardner wrote:> On 05/06/20 01:01, John Larkin wrote: > > On Fri, 5 Jun 2020 00:34:56 +0100, Tom Gardner > > <spamjunk@blueyonder.co.uk> wrote: > > > >> On 04/06/20 20:51, John Larkin wrote: > >>> On Thu, 4 Jun 2020 20:09:03 +0100, Tom Gardner > >>> <spamjunk@blueyonder.co.uk> wrote: > >>> > >>>> On 04/06/20 18:14, John Larkin wrote: > >>>>> On Thu, 4 Jun 2020 17:42:22 +0100, Tom Gardner > >>>>> <spamjunk@blueyonder.co.uk> 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. > >>>>> > >>>>> Good grief, this is an electronic design forum. I'm an electrical > >>>>> engineer. > >>>> > >>>> Software and electronic have been completely entwined for > >>>> almost half a century. > >>>> > >>>> As a competent electronic engineer you are unwise to make > >>>> strong statements in spheres where you have limited experience. > >>> > >>> Unwise? Because I don't meet your expectations? Because I use ITC > >>> thermocouple equations? > >> > >> Unwise because it makes you look ignorant and/or foolish > >> and/or arrogant. > >> > >> "Better to keep your mouth closed and be thought a fool > >> than to open it and demonstrate you are a fool". > >> > >> > >> > >>> We get purchase orders for electronics things, from people that you > >>> have heard of, and they are happy with what we make for them. > >>> > >>> Given that, or being some google coder droid, I like the hardware. > >>> > >>> Post some electronics now and then and we'll discuss it. > >> > >> What's the relevance of that to the subject being discussed, > >> viz modern large software systems? > > > > Why would you discuss that in an electronic design forum? Take that > > somewhere else. > > Software and electronic have been completely entwined for > almost half a century. > > You made globally applicable statements based on your > understanding of a small part of the software ecosphere > that existed decades ago. Technology has moved on since > then. > > Hence it is unsurprising that your statements were, > um, inadequate. > > > >> Basically it is mere flack: true but irrelevant and designed to > >> deflect attention. > >> > >> Sorry, it has the opposite effect. > > > > Good book: > > > > https://www.amazon.com/What-Care-Other-People-Think/dp/0393355640/ref=sr_1_1?crid=1N094TUR21JN8&dchild=1&keywords=feynman+what+do+you+care+what+other+people+think&qid=1591315148&sprefix=feinman+what+do+you+care%2Caps%2C215&sr=8-1 > > > > Pretty smart guy. > > I'm not sure what relevance that has to the similar > characteristics of software and electronics.Feynman was ingenious, which is to say he did unexpected things that worked. John Larkin likes to think that the unexpected aspect is crucial.> 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. -- Bill Sloman, Sydney
Reply by ●June 4, 20202020-06-04
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 -- 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 4, 20202020-06-04
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. 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. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
