Am 05.06.20 um 19:27 schrieb Tom Gardner:> On 05/06/20 17:56, David Brown wrote: >> You are just desperately trying to avoid learning something new. I >> don't get that - it really is hard to comprehend. Perhaps you feel >> you've invested too much in calling my posts BS, and that admitting >> you were wrong about this would be a blow to your ego. > > There seems to be a general principle that: > - if you are a respected expert in field X > - you have some knowledge and experience in field Y > - you think you are expert in field Y > > In gliding circles that is known as the "doctor syndrome"... > > In middle age a successful doctor takes up gliding, > becomes solo, becomes a cross country flyer. Then > because they have the money and there's nothing > stopping them, they buy themselves the biggest > baddest glider. > > Sooner or later, and despite warnings, they end up > dead - because their arrogance couldn't let them > admit to themselves that other people knew more.AFAIR the current world champion is a former dentist. Gerhard
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 Fri, 5 Jun 2020 01:29:25 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> 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.Tough cookies, buttercup. I design electronics that works and sells, and you don't. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 11:11:13 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>On 6/5/20 9:43 AM, jlarkin@highlandsniptechnology.com wrote: >> On Fri, 5 Jun 2020 08:49:38 +0100, Tom Gardner >> <spamjunk@blueyonder.co.uk> 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. >> >> I know Fellows of big aerospace companies, software guys, who aren't >> sure which end of an oscilloscope goes up. They can't estimate >> runtines within 10:1, so they grossly overkill on compute power. >> >> One of them is playing with those raspberry pi things at home. I'm >> going to send him an oscilloscope. >> >>> >>> 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? >> >> There was an obvious linux timer IRQ, always there, at 1 KHz as I >> recall. Things like ethernet activity added less regular timeouts from >> the hard loop. But the worst stackup that we saw was under 40 us, and >> rare. >> >> Linux, I understand, allows weak suggestion of what to run on which >> CPU, which we did, and that seemed to help. We didn't research or >> document this extensively, because it became obvious that we could run >> our state loops and such plenty often enough, and that we should do >> some of our math (like summing the means and squares of ADC samples, >> for RMS) in the FPGA. >> >>> >>> Did the "other stuff" manage/avoid interfering with >>> the caches? >> >> Don't know. We just scoped the gross timeouts. > >I haven't done performance-critical code on Linux for a few years, but >last time I checked, the thread scheduler was a mess. > >In Windows and the late lamented OS/2, a given process can have user >threads, real-time threads, and can set any priority it likes. Since >I haven't done performance-critical code on Linux for a few years, so >there's some possibility that it's improved, but as it was obviously a >design choice I sort of doubt it. (Broken As Designed.) > >In Windows and the late lamented OS/2, a given process can have user >threads and real-time threads, and can set any priority it likes. Since >those are basically single-user OSes, if you want to hog all the CPU >cycles, knock yourself out. That's super useful in situations such as >distributed simulations, where you can make the communications threads >high priority so that one node doesn't wind up waiting while its >neighbour sucks its thumb even after the data are ready to send. I have >a comms library that I've used for yonks, which encapsulates a >high-priority thread blocking until data are available, then waking up, >sending/receiving, and then blocking again. Works great. > >In Linux, this is not doable in a single process. Despite what the >pthreads docs say, a user process cannot change the priority of any >thread--you can't even _decrease_ it--and all threads of a realtime >process are higher priority than any user thread. Thus if you try doing >a compute-bound thing in a realtime process, you immediately bring the >UI to its knees.This does not sound correct. What problem are you trying to solve? If I recall, one could choose threads to have local (to the process) scheduling scope, or global scheduling scope (at the level of processes, in effect. I'm pretty sure that POSIX provides that, and Linux and Posix largely overlap in such things.>Whenever I bring this up, fanbois immediately jump on me for trying to >hog the machine, as if running my own code on my own box and wanting it >to do as it's damn well told qualifies me for a Scarlet Letter.Absolutely. It's an embedded computer, not a general-purpose computer.>In fact, most of the time I'd be perfectly happy to have my compute >threads running at niceness +20 and the communications threads at +19, >but nooooo. To do it, I'd probably have to use all sorts of fuggly >nonportable shared memory things between a user process doing the work >and a realtime process just doing the comms. Stooopid.The way I've seen this done in big radars is by use of Linux/Posix realtime scheduling policies: .<https://man7.org/linux/man-pages/man7/sched.7.html> And yes, shared memory windows are widely used. Joe Gwinn
Reply by ●June 5, 20202020-06-05
On Friday, June 5, 2020 at 6:50:47 AM UTC-7, jla...@highlandsniptechnology.com wrote:> Some day we'll just run every process on its own CPU and avoid all > that context switching nonsense.If an operational amplifier is the processing unit, this is already the case for a large category of applications.
Reply by ●June 5, 20202020-06-05
On Friday, June 5, 2020 at 7:30:47 AM UTC-7, jla...@highlandsniptechnology.com wrote:> On Fri, 5 Jun 2020 08:38:33 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote:> >It is a good topic for a conversation in pubs. > > > >I normally start it by provocatively asking someone to > >distinguish between hardware and software. > > Hardware is physical stuff that you buy or make, and pay for per unit. > Motors, transformers, PC boards, opamps. Things that have mass. > > Software is stuff that people type and that temporarily changes the > states of some storage elements. It is massless.So, a firmware EPROM (that has to be yanked and physically replaced in order to change the firmware) is... hardware? And a bug in the firmware is a hardware bug if 't s EPROM, but a software bug if it's a flash ROM?
Reply by ●June 5, 20202020-06-05
On 05/06/20 18:33, Gerhard Hoffmann wrote:> Am 05.06.20 um 19:27 schrieb Tom Gardner: >> On 05/06/20 17:56, David Brown wrote: >>> You are just desperately trying to avoid learning something new. I don't get >>> that - it really is hard to comprehend. Perhaps you feel you've invested too >>> much in calling my posts BS, and that admitting you were wrong about this >>> would be a blow to your ego. >> >> There seems to be a general principle that: >> - if you are a respected expert in field X >> - you have some knowledge and experience in field Y >> - you think you are expert in field Y >> >> In gliding circles that is known as the "doctor syndrome"... >> >> In middle age a successful doctor takes up gliding, >> becomes solo, becomes a cross country flyer. Then >> because they have the money and there's nothing >> stopping them, they buy themselves the biggest >> baddest glider. >> >> Sooner or later, and despite warnings, they end up >> dead - because their arrogance couldn't let them >> admit to themselves that other people knew more. > > AFAIR the current world champion is a former dentist.:) And somebody once calculated that about 10% of the top glider pilots had died, far more than the general glider pilot population. That's unsurprising when you realise they choose to fly close to the edge of the envelope.
Reply by ●June 5, 20202020-06-05
On 05/06/20 21:27, whit3rd wrote:> On Friday, June 5, 2020 at 7:30:47 AM UTC-7, jla...@highlandsniptechnology.com wrote: >> On Fri, 5 Jun 2020 08:38:33 +0100, Tom Gardner >> <spamjunk@blueyonder.co.uk> wrote: > >>> It is a good topic for a conversation in pubs. >>> >>> I normally start it by provocatively asking someone to >>> distinguish between hardware and software. >> >> Hardware is physical stuff that you buy or make, and pay for per unit. >> Motors, transformers, PC boards, opamps. Things that have mass. >> >> Software is stuff that people type and that temporarily changes the >> states of some storage elements. It is massless. > > So, a firmware EPROM (that has to be yanked and physically > replaced in order to change the firmware) is... hardware? > > And a bug in the firmware is a hardware bug if 't s EPROM, > but a software bug if it's a flash ROM?Or fuse programmable logic, or programmed/unprogrammed FPGAs, or the one time programmable MCUs costing $0.03 each, or a microcoded processor, or...
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 21:40:03 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 05/06/20 21:27, whit3rd wrote: >> On Friday, June 5, 2020 at 7:30:47 AM UTC-7, jla...@highlandsniptechnology.com wrote: >>> On Fri, 5 Jun 2020 08:38:33 +0100, Tom Gardner >>> <spamjunk@blueyonder.co.uk> wrote: >> >>>> It is a good topic for a conversation in pubs. >>>> >>>> I normally start it by provocatively asking someone to >>>> distinguish between hardware and software. >>> >>> Hardware is physical stuff that you buy or make, and pay for per unit. >>> Motors, transformers, PC boards, opamps. Things that have mass. >>> >>> Software is stuff that people type and that temporarily changes the >>> states of some storage elements. It is massless. >> >> So, a firmware EPROM (that has to be yanked and physically >> replaced in order to change the firmware) is... hardware? >> >> And a bug in the firmware is a hardware bug if 't s EPROM, >> but a software bug if it's a flash ROM? > >Or fuse programmable logic, or programmed/unprogrammed >FPGAs, or the one time programmable MCUs costing $0.03 >each, or a microcoded processor, or...Clearly neither of you guys can tell the difference between a computer (which can break your toe if you drop it) and the programs that it runs (which can't.) Too much abstraction has that effect on people. Nuance creates paralysis. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●June 5, 20202020-06-05
On 05/06/20 22:08, John Larkin wrote:> On Fri, 5 Jun 2020 21:40:03 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> On 05/06/20 21:27, whit3rd wrote: >>> On Friday, June 5, 2020 at 7:30:47 AM UTC-7, jla...@highlandsniptechnology.com wrote: >>>> On Fri, 5 Jun 2020 08:38:33 +0100, Tom Gardner >>>> <spamjunk@blueyonder.co.uk> wrote: >>> >>>>> It is a good topic for a conversation in pubs. >>>>> >>>>> I normally start it by provocatively asking someone to >>>>> distinguish between hardware and software. >>>> >>>> Hardware is physical stuff that you buy or make, and pay for per unit. >>>> Motors, transformers, PC boards, opamps. Things that have mass. >>>> >>>> Software is stuff that people type and that temporarily changes the >>>> states of some storage elements. It is massless. >>> >>> So, a firmware EPROM (that has to be yanked and physically >>> replaced in order to change the firmware) is... hardware? >>> >>> And a bug in the firmware is a hardware bug if 't s EPROM, >>> but a software bug if it's a flash ROM? >> >> Or fuse programmable logic, or programmed/unprogrammed >> FPGAs, or the one time programmable MCUs costing $0.03 >> each, or a microcoded processor, or... > > > Clearly neither of you guys can tell the difference between a computer > (which can break your toe if you drop it) and the programs that it > runs (which can't.)Correct :)> Too much abstraction has that effect on people. Nuance creates > paralysis.False.
Reply by ●June 5, 20202020-06-05
On 2020-06-05, David Brown <david.brown@hesbynett.no> wrote:> > Perhaps you think that using a function call matters: > > extern volatile unsigned char pin; > > unsigned int t = 1; > > unsigned int big_calc(unsigned int x) { > unsigned int y = x * x; > unsigned int z = x * y; > return y * y + 2 * z + 3 * y + 4; > } > > void foo(void) { > pin = 1; > > t = big_calc(t); > > pin = 0; > } > > foo: > mov eax, DWORD PTR t[rip] > mov BYTE PTR pin[rip], 1 > mov BYTE PTR pin[rip], 0 > mov edx, eax > imul edx, eax > lea eax, [rdx+3+rax*2] > imul eax, edx > add eax, 4 > mov DWORD PTR t[rip], eax > ret > > No loops are removed, and "big_calc" is written as a function call, with > an externally visible definition including several statements, > semicolons, and local variables. You can see the "pin = 1; pin = 0;" > assembly within the generated assembly.Wait what! The compiler determined that big calc had no side-effects somehow? -- Jasen.
