On Friday, June 5, 2020 at 5:08:14 PM UTC-4, 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.) > > Too much abstraction has that effect on people. Nuance creates > paralysis.I had an interesting discussion once about whether FPGAs used software, firmeware or something else. It lasted quite a while with strong opinions. It's silly to even talk about software and hardware separately. Neither is much good without the other. But then many of the points Larkin makes are silly whether or not they are accurate. -- Rick C. -+-- Get 1,000 miles of free Supercharging -+-- Tesla referral code - https://ts.la/richard11209
KiCad Spice, Anyone Tried It?
Started by ●June 2, 2020
Reply by ●June 6, 20202020-06-06
Reply by ●June 6, 20202020-06-06
On 06/06/2020 02:56, David Brown wrote:> You are just desperately trying to avoid learning something new.Well I learned some things from your posts, so thank you!
Reply by ●June 6, 20202020-06-06
On 5.6.20 23:32, Tom Gardner wrote:> 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.There are old pilots and bold pilots, but no old bold pilots. I'm old. -- -TV
Reply by ●June 6, 20202020-06-06
On 06/06/20 13:07, Tauno Voipio wrote:> On 5.6.20 23:32, Tom Gardner wrote: >> 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. > > > There are old pilots and bold pilots, but no old bold pilots. > I'm old.And I'm too old :( Here are a couple of envelope-pushing videos. The first is hooning around doing a "Thomas Crown Affair (1968)", the second using ground effect to get home in a competition. https://www.youtube.com/watch?v=cXrBDGu3UG0 https://www.youtube.com/watch?v=wZxvYMC2QvI Some droll comment on the latter, e.g. "thats not where I would have started my circuit but keep going" :)
Reply by ●June 7, 20202020-06-07
On 06/06/2020 13:26, Chris Jones wrote:> On 06/06/2020 02:56, David Brown wrote: >> You are just desperately trying to avoid learning something new. > > Well I learned some things from your posts, so thank you! >I appreciate that feedback. (I've learned a few things from other peoples' posts in this group too. Not many - the noise to signal ratio is very high here - but a few.)
Reply by ●June 7, 20202020-06-07
On 06/06/2020 01:08, Jasen Betts wrote:> 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? >Yes. It can see the definition of "big_calc", and thus knows all about it - including that it has no side-effects or observable behaviour. So it can be inlined in foo() and optimised in a variety of ways, including inter-weaving with other code in foo(). (The compiler must also generate a function "big_calc" that can be called from other units - I didn't bother pasting that into the post. I recommend playing around with these things in <https://godbolt.org> if you want to see what happens. Don't forget compiler flags like "-O2 -Wall -Wextra" to help out.)
Reply by ●June 7, 20202020-06-07
On 05/06/20 16:52, jlarkin@highlandsniptechnology.com wrote:> On Fri, 5 Jun 2020 15:30:04 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> On 05/06/20 14:43, 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. >> >> As long as they have other skills that complement yours, that sounds like an >> ideal combination. >> Jack Sprat could eat no fat. >> His wife could eat no lean. >> So together they scraped >> the platter clean. >> >> >>> One of them is playing with those raspberry pi things at home. I'm >>> going to send him an oscilloscope. >> >> It is always good to be able to help people step into >> areas where they are unsure and have things to learn. >> >> That's easy to do with kids, less so with adults that >> have appearances to defend. >> >> >>> >>>> >>>> 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. >> >> In hard realtime, you are only interested in the worst >> case; nothing else matters. >> >> That's why "measure and hope you've spotted worst case" >> is so unappealing. > > Set the scope to infinite persistance and run over a weekend. 20 > billion experiments should be enough.Not necessarily. Consider one aspect of intel chipsets, the System Management Interrupt (SMI). Those have delightful characteristics: - generated by power management hardware, so unless you include "hot and high" tests, one might not occur - higher priority than NMI - invisible to the operating system and software - can't intercept them because they don't have a vector in the CPU - when generated, the CPU goes into a special mode - can last hundreds of microseconds You can disable them, but that risks the processor burning. Did you know those existed? Does something equivalent exist in other chipsets? FFI, https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application
Reply by ●June 7, 20202020-06-07
On 05/06/20 15:15, jlarkin@highlandsniptechnology.com wrote:> On Fri, 5 Jun 2020 08:58:15 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> 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. > > Set the scope to infinite persistance, and run overnight.See my other post about intel processors' System Management Interrupt. SMIs wouldn't have been noticed in my application, but they could screw applications running nearer the metal and with tighter time constraints.
Reply by ●June 7, 20202020-06-07
On Sun, 7 Jun 2020 15:36:02 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 05/06/20 16:52, jlarkin@highlandsniptechnology.com wrote: >> On Fri, 5 Jun 2020 15:30:04 +0100, Tom Gardner >> <spamjunk@blueyonder.co.uk> wrote: >> >>> On 05/06/20 14:43, 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. >>> >>> As long as they have other skills that complement yours, that sounds like an >>> ideal combination. >>> Jack Sprat could eat no fat. >>> His wife could eat no lean. >>> So together they scraped >>> the platter clean. >>> >>> >>>> One of them is playing with those raspberry pi things at home. I'm >>>> going to send him an oscilloscope. >>> >>> It is always good to be able to help people step into >>> areas where they are unsure and have things to learn. >>> >>> That's easy to do with kids, less so with adults that >>> have appearances to defend. >>> >>> >>>> >>>>> >>>>> 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. >>> >>> In hard realtime, you are only interested in the worst >>> case; nothing else matters. >>> >>> That's why "measure and hope you've spotted worst case" >>> is so unappealing. >> >> Set the scope to infinite persistance and run over a weekend. 20 >> billion experiments should be enough. > >Not necessarily.20 billion is enough for me. Every interrupt is visible, and I can add. We avoid dynamic memory allocation and garbage collection and such as much as we can. Once I get a risk so low that it doesn't materially affect MTBF, I can ignore it. As far as we know, the Zynq/Linux things are reliable in the field. It wouldn't explode if it missed a few interrupts per week anyhow. What would you do? Analyze the source code of Linux for a decade or two? Formally prove the system to be correct? Some of our products are just the Zynq on a board with parts, some are MicroZeds, and I just got a couple of PicoZeds to play with.> >Consider one aspect of intel chipsets, the System Management >Interrupt (SMI). > >Those have delightful characteristics: >- generated by power management hardware, so unless you include > "hot and high" tests, one might not occur >- higher priority than NMI >- invisible to the operating system and software >- can't intercept them because they don't have a vector in the CPU >- when generated, the CPU goes into a special mode >- can last hundreds of microseconds > >You can disable them, but that risks the processor burning. > >Did you know those existed? >Does something equivalent exist in other chipsets? > >FFI, https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-applicationIntel for anything real? For anything reliable? You are joking, of course. One of our friends had the Liniux kernel re-written to make it more real-time. We don't need to do that, because we have the option to move time-critical stuff into the FPGA fabric. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 7, 20202020-06-07
On 07/06/20 18:31, jlarkin@highlandsniptechnology.com wrote:> One of our friends had the Liniux kernel re-written to make it more > real-time. We don't need to do that, because we have the option to > move time-critical stuff into the FPGA fabric.And that is the sensible part of your response, and one of the many reasons why people need to understand hardware and software, their tradeoffs, and where to set the boundary between them.
