On Fri, 5 Jun 2020 04:25:36 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>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." ;)Now that's a keeper. -- 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 5, 20202020-06-05
Reply by ●June 5, 20202020-06-05
On Friday, June 5, 2020 at 10:20:35 AM UTC-4, Tom Gardner wrote:> On 05/06/20 14:50, jlarkin@highlandsniptechnology.com wrote: > > On Fri, 5 Jun 2020 10:39:00 +0100, Tom Gardner > > <spamjunk@blueyonder.co.uk> wrote: > > > >> On 05/06/20 10:24, Phil Hobbs wrote: > >>> On 2020-06-05 03:49, Tom Gardner wrote: > >>>> On 05/06/20 03:24, jlarkin@highlandsniptechnology.com wrote: > >>>>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown > >>>>> <david.brown@hesbynett.no> wrote: > >>>>> > >>>>> > >>>>>>> > >>>>>>> That's what I have to do, use an oscilloscope to show programmers what > >>>>>>> their code does. You can often relate the pulse widths to paths > >>>>>>> through the code. > >>>>>>> > >>>>>> > >>>>>> A scope can be a fine tool for measuring code performance. I like to > >>>>>> make sure there are a few test pins on our boards that can be connected > >>>>>> to an oscilloscope precisely for measuring critical code. Not all > >>>>>> programmers understand how to instrument code for such measurements, > >>>>>> unfortunately. > >>>>> > >>>>> Raise a port pin at the start of the routine, and drop it at the end. > >>>>> Maybe invert it a couple of times, at interesting points. > >>>> > >>>> Yes, it isn't rocket science. > >>>> > >>>> If the test point reflects the "idle" time, you can even > >>>> put a voltmeter (preferable moving coil!) on it to visualise > >>>> the processor utilisation. Dirty, but quick. > >>>> > >>>> > >>>>> We did one test on a Zynq, dual 600 MHz ARMs running the usual Linux. > >>>>> One program just toggled a pin as hard as it could, and we looked at > >>>>> that on a scope to see how much other things suspended the loop. We'd > >>>>> see occasional long highs or lows, "long" being numbers like 20 us. I > >>>>> was impressed. The linux periodic interrupt only took a few > >>>>> microseconds. > >>>> > >>>> Did you form an opinion as to what caused the pauses? > >>>> > >>>> Did the "other stuff" manage/avoid interfering with > >>>> the caches? > >>> > >>> 20 microseconds is a long time for a cache miss on a gigahertz processor. L1 > >>> cache lines are typically 64 bytes, no? > >> > >> In general, there are other caches in various forms, > >> and there can be many misses. > >> > >> I haven't recently checked what's in A9(?) ARMs, nor > >> how each processor can interfere with the other. > >> > >> If I wanted to use a Zynq (and they look like interesting > >> devices) for hard realtime purposes, then I'd look at > >> putting a traditional RTOS on one processor and a linux > >> on the other. > > > > There is a Xilinx appnote for implementing linux on one ARM core, and > > running bare-metal on the other. That's what we'd do if we had to. If > > we had more than one fast thing to run, we'd do a simple state > > machine. Even an RTOS has overhead. > > > > One could toss a bunch of soft-core processors in the FPGA too, which > > certain parties are eager to do. > > OK for some limited things, but an ARM+i/o+FPGA is an > more general and more appealing concept to me. > > > > Some day we'll just run every process on its own CPU and avoid all > > that context switching nonsense. > > Some day? *I do /precisely/ that right now*. > > It is *precisely* the concept behind and implementation > of the XMOS xCORE processors, programmed in xC (think > Occam or CSP, or some of the CSP concepts appearing in > Rust and golang), within a standard IDE. > > It works, is easy and *fun*. A *much* lower learning > curve than Vivado. > > To kick the tyres of the concepts I had > - one core counting the transitions on an input serial stream, > - another doing the same on a different stream, > - one core for the front panel, > - several cores communicating over USB with a PC (could have > been ethernet) > - one core for a supervisory FSM coordinating all the above > > Hard realtime *guarantees* not to miss any transitions, > nor comms, etc. The IDE inspects the optimised binary > to calculate precise timing. None of this "measure and hope" > crap :) > > IDE is free, buy the processors and dev boards at DigiKey.Yes, on the XMOS you run every process in its own processor until you run out of processors... then you are back to sharing like everyone else does. -- Rick C. --++ Get 1,000 miles of free Supercharging --++ Tesla referral code - https://ts.la/richard11209
Reply by ●June 5, 20202020-06-05
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.> 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.Sounds sane. Processors intimately coupled with FPGA are /one/ good starting point for many interesting things. I haven't investigated real time linux on the grounds that it feels as if the proponents only have hammers in their toolkit.>> Did the "other stuff" manage/avoid interfering with >> the caches? > > Don't know. We just scoped the gross timeouts.Fine if the processors are grossly underused.
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 08:38:33 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 05/06/20 02:51, Phil Hobbs wrote: >> On 2020-06-04 12:42, Tom Gardner wrote: >>> On 04/06/20 17:22, jlarkin@highlandsniptechnology.com wrote: >>>> On Thu, 4 Jun 2020 16:10:06 +0100, Tom Gardner >>>> <spamjunk@blueyonder.co.uk> wrote: >>>> >>>>> On 04/06/20 00:59, John Larkin wrote: >>>>>> On Thu, 4 Jun 2020 00:25:35 +0100, Tom Gardner >>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>> >>>>>>> On 03/06/20 21:21, John Larkin wrote: >>>>>>>> On Wed, 3 Jun 2020 17:33:30 +0100, Tom Gardner >>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>>> >>>>>>>>> The similarities outweigh the differences. >>>>>>>> >>>>>>>> The similarities of that statement, six times, are tedious. >>>>>>> >>>>>>> Your misapprehensions on this topic are legion >>>>>>> and repetitive. >>>>>>> >>>>>>> >>>>>>>> Do you design electronics? >>>>>>> >>>>>>> I did, for decades. >>>>>>> >>>>>>> I also designed and implemented server-side software >>>>>>> for decades. >>>>>>> >>>>>>> Do you implement such software? >>>>>>> >>>>>>> (I believe you have said you leave that to others.) >>>>>> >>>>>> I wrote two compilers and three pre-emptive RTOSs and maybe a hundred >>>>>> embedded programs, >>>>> It is worth pointing out that all of those examples are >>>>> (almost certainly) very different to general purpose software >>>>> and, especially, to application servers and the applications >>>>> that run within them. >>>> >>>> What's not general about an RTOS? Thousands of units were sold. >>> >>> It is a single specialised program than can be used in >>> different end equipment. >>> >>> There's far more to software and software development >>> than that. >>> >>> >>> >>>>> Ditto your organisation and the organisations that write/maintain >>>>> such codebases. >>>>> >>>>> Thus it is unsurprising that you do not understand modern >>>>> medium/large scale software and software practices. Especially >>>>> the congruences with medium/large scale hardware. >>>> >>>> This is an electronic design group. I deal with the software that >>>> makes electronic instruments work. My relationship to servers is that >>>> I have to talk to them, feed them javascript and UDP packets and such. >>> >>> No doubt. >>> >>> But it confirms that you have no experience of creating >>> large-scale software systems using modern techniques. >>> >>> It is therefore unsurprising that you haven't understood >>> the congruences with hardware. >> >> Congruences between large scale software "using modern techniques" and hardware? >> Interesting!� Since you're obviously expert in both, I'd like to learn more. > >More of a jack of all trades and master of none, by choice. >That has advantages and disadvantages. > > >> What are they, exactly? > >That would take a /long/ time to discuss, especially if >half the concepts are unfamiliar to the audience. >To take /one/ example > - how application server frameworks are designed > and implemented > - design patterns in the applications' components > and the way they are composed to form an application, > - design patterns used to communicate with the outside > world, > - antipatterns found in politics, development and design > >It is a good topic for a conversation in pubs. > >I normally start it by provocatively asking someone to >distinguish between hardware and software.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. 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 programmingAll artificial, arbitrary, trendy constructs. None of them will drive a fuel injector. Real men design hardware. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 12:00:51 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 05/06/20 09:28, Phil Hobbs wrote: >> On 2020-06-05 03:38, Tom Gardner wrote: >>> On 05/06/20 02:51, Phil Hobbs wrote: >>>> On 2020-06-04 12:42, Tom Gardner wrote: >>>>> On 04/06/20 17:22, jlarkin@highlandsniptechnology.com wrote: >>>>>> On Thu, 4 Jun 2020 16:10:06 +0100, Tom Gardner >>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>> >>>>>>> On 04/06/20 00:59, John Larkin wrote: >>>>>>>> On Thu, 4 Jun 2020 00:25:35 +0100, Tom Gardner >>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>> >>>>>>>>> On 03/06/20 21:21, John Larkin wrote: >>>>>>>>>> On Wed, 3 Jun 2020 17:33:30 +0100, Tom Gardner >>>>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>>>>> >>>>>>>>>>> The similarities outweigh the differences. >>>>>>>>>> >>>>>>>>>> The similarities of that statement, six times, are tedious. >>>>>>>>> >>>>>>>>> Your misapprehensions on this topic are legion >>>>>>>>> and repetitive. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Do you design electronics? >>>>>>>>> >>>>>>>>> I did, for decades. >>>>>>>>> >>>>>>>>> I also designed and implemented server-side software >>>>>>>>> for decades. >>>>>>>>> >>>>>>>>> Do you implement such software? >>>>>>>>> >>>>>>>>> (I believe you have said you leave that to others.) >>>>>>>> >>>>>>>> I wrote two compilers and three pre-emptive RTOSs and maybe a hundred >>>>>>>> embedded programs, >>>>>>> It is worth pointing out that all of those examples are >>>>>>> (almost certainly) very different to general purpose software >>>>>>> and, especially, to application servers and the applications >>>>>>> that run within them. >>>>>> >>>>>> What's not general about an RTOS? Thousands of units were sold. >>>>> >>>>> It is a single specialised program than can be used in >>>>> different end equipment. >>>>> >>>>> There's far more to software and software development >>>>> than that. >>>>> >>>>> >>>>> >>>>>>> Ditto your organisation and the organisations that write/maintain >>>>>>> such codebases. >>>>>>> >>>>>>> Thus it is unsurprising that you do not understand modern >>>>>>> medium/large scale software and software practices. Especially >>>>>>> the congruences with medium/large scale hardware. >>>>>> >>>>>> This is an electronic design group. I deal with the software that >>>>>> makes electronic instruments work. My relationship to servers is that >>>>>> I have to talk to them, feed them javascript and UDP packets and such. >>>>> >>>>> No doubt. >>>>> >>>>> But it confirms that you have no experience of creating >>>>> large-scale software systems using modern techniques. >>>>> >>>>> It is therefore unsurprising that you haven't understood >>>>> the congruences with hardware. >>>> >>>> Congruences between large scale software "using modern techniques" and >>>> hardware? Interesting!� Since you're obviously expert in both, I'd like to >>>> learn more. >>> >>> More of a jack of all trades and master of none, by choice. >>> That has advantages and disadvantages. >>> >>> >>>> What are they, exactly? >>> >>> That would take a /long/ time to discuss, especially if >>> half the concepts are unfamiliar to the audience. >>> To take /one/ example >>> ��- how application server frameworks are designed >>> ��� and implemented >>> ��- design patterns in the applications' components >>> ��� and the way they are composed to form an application, >>> ��- design patterns used to communicate with the outside >>> ��� world, >>> ��- antipatterns found in politics, development and design >>> >>> It is a good topic for a conversation in pubs. >>> >>> I normally start it by provocatively asking someone to >>> distinguish between hardware and software. They normally >>> claim it is obvious and come up with a definition. Then >>> I introduce them to examples that don't fit their definition. >>> Rinse and repeat. > >>> Sometimes it can take a long time to realise what the >>> proponents of a particular technique are doing, because >>> they use unfamiliar terms to describe things that are >>> standard in other fields. >>> >>> Some examples: >>> ��- Jackson's Structured Programming >>> ��- Harel StateCharts >>> ��- many of the more esoteric UML diagrams >>> ��- Hatley and Pirbhai's Strategies for Realtime Systems >>> ��� Specification, as successfully used for the Boeing 777 >>> ��- and, obviously, object oriented programming >> >> So where are the applications to hardware?�� Even one detailed example would be >> interesting. > >Not application so much as a lack of difference between >hardware and software.Design an electronic circuit. Post it. That would be fun to see. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 5, 20202020-06-05
On 05/06/20 15:24, Ricketty C wrote:> On Friday, June 5, 2020 at 10:20:35 AM UTC-4, Tom Gardner wrote: >> On 05/06/20 14:50, jlarkin@highlandsniptechnology.com wrote: >>> On Fri, 5 Jun 2020 10:39:00 +0100, Tom Gardner >>> <spamjunk@blueyonder.co.uk> wrote: >>> >>>> On 05/06/20 10:24, Phil Hobbs wrote: >>>>> On 2020-06-05 03:49, Tom Gardner wrote: >>>>>> On 05/06/20 03:24, jlarkin@highlandsniptechnology.com wrote: >>>>>>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >>>>>>> <david.brown@hesbynett.no> wrote: >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> That's what I have to do, use an oscilloscope to show programmers what >>>>>>>>> their code does. You can often relate the pulse widths to paths >>>>>>>>> through the code. >>>>>>>>> >>>>>>>> >>>>>>>> A scope can be a fine tool for measuring code performance. I like to >>>>>>>> make sure there are a few test pins on our boards that can be connected >>>>>>>> to an oscilloscope precisely for measuring critical code. Not all >>>>>>>> programmers understand how to instrument code for such measurements, >>>>>>>> unfortunately. >>>>>>> >>>>>>> Raise a port pin at the start of the routine, and drop it at the end. >>>>>>> Maybe invert it a couple of times, at interesting points. >>>>>> >>>>>> Yes, it isn't rocket science. >>>>>> >>>>>> If the test point reflects the "idle" time, you can even >>>>>> put a voltmeter (preferable moving coil!) on it to visualise >>>>>> the processor utilisation. Dirty, but quick. >>>>>> >>>>>> >>>>>>> We did one test on a Zynq, dual 600 MHz ARMs running the usual Linux. >>>>>>> One program just toggled a pin as hard as it could, and we looked at >>>>>>> that on a scope to see how much other things suspended the loop. We'd >>>>>>> see occasional long highs or lows, "long" being numbers like 20 us. I >>>>>>> was impressed. The linux periodic interrupt only took a few >>>>>>> microseconds. >>>>>> >>>>>> Did you form an opinion as to what caused the pauses? >>>>>> >>>>>> Did the "other stuff" manage/avoid interfering with >>>>>> the caches? >>>>> >>>>> 20 microseconds is a long time for a cache miss on a gigahertz processor. L1 >>>>> cache lines are typically 64 bytes, no? >>>> >>>> In general, there are other caches in various forms, >>>> and there can be many misses. >>>> >>>> I haven't recently checked what's in A9(?) ARMs, nor >>>> how each processor can interfere with the other. >>>> >>>> If I wanted to use a Zynq (and they look like interesting >>>> devices) for hard realtime purposes, then I'd look at >>>> putting a traditional RTOS on one processor and a linux >>>> on the other. >>> >>> There is a Xilinx appnote for implementing linux on one ARM core, and >>> running bare-metal on the other. That's what we'd do if we had to. If >>> we had more than one fast thing to run, we'd do a simple state >>> machine. Even an RTOS has overhead. >>> >>> One could toss a bunch of soft-core processors in the FPGA too, which >>> certain parties are eager to do. >> >> OK for some limited things, but an ARM+i/o+FPGA is an >> more general and more appealing concept to me. >> >> >>> Some day we'll just run every process on its own CPU and avoid all >>> that context switching nonsense. >> >> Some day? *I do /precisely/ that right now*. >> >> It is *precisely* the concept behind and implementation >> of the XMOS xCORE processors, programmed in xC (think >> Occam or CSP, or some of the CSP concepts appearing in >> Rust and golang), within a standard IDE. >> >> It works, is easy and *fun*. A *much* lower learning >> curve than Vivado. >> >> To kick the tyres of the concepts I had >> - one core counting the transitions on an input serial stream, >> - another doing the same on a different stream, >> - one core for the front panel, >> - several cores communicating over USB with a PC (could have >> been ethernet) >> - one core for a supervisory FSM coordinating all the above >> >> Hard realtime *guarantees* not to miss any transitions, >> nor comms, etc. The IDE inspects the optimised binary >> to calculate precise timing. None of this "measure and hope" >> crap :) >> >> IDE is free, buy the processors and dev boards at DigiKey. > > Yes, on the XMOS you run every process in its own processor until you run out of processors... then you are back to sharing like everyone else does.All technologies have their limits. The question is whether you can do useful work within the limits. That also applies to the GA144. I know which technology is widely used and which company continues to get new investment.
Reply by ●June 5, 20202020-06-05
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.But the worst case only occurs when Jupiter is aligned with Mars. Or during acceptance tests on a customer's site.
Reply by ●June 5, 20202020-06-05
On 05/06/20 13:04, Phil Hobbs wrote:> On 2020-06-05 07:00, Tom Gardner wrote: >> On 05/06/20 09:28, Phil Hobbs wrote: >>> On 2020-06-05 03:38, Tom Gardner wrote: >>>> On 05/06/20 02:51, Phil Hobbs wrote: >>>>> On 2020-06-04 12:42, Tom Gardner wrote: >>>>>> On 04/06/20 17:22, jlarkin@highlandsniptechnology.com wrote: >>>>>>> On Thu, 4 Jun 2020 16:10:06 +0100, Tom Gardner >>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>> >>>>>>>> On 04/06/20 00:59, John Larkin wrote: >>>>>>>>> On Thu, 4 Jun 2020 00:25:35 +0100, Tom Gardner >>>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>>> >>>>>>>>>> On 03/06/20 21:21, John Larkin wrote: >>>>>>>>>>> On Wed, 3 Jun 2020 17:33:30 +0100, Tom Gardner >>>>>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>>>>>> >>>>>>>>>>>> The similarities outweigh the differences. >>>>>>>>>>> >>>>>>>>>>> The similarities of that statement, six times, are tedious. >>>>>>>>>> >>>>>>>>>> Your misapprehensions on this topic are legion >>>>>>>>>> and repetitive. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Do you design electronics? >>>>>>>>>> >>>>>>>>>> I did, for decades. >>>>>>>>>> >>>>>>>>>> I also designed and implemented server-side software >>>>>>>>>> for decades. >>>>>>>>>> >>>>>>>>>> Do you implement such software? >>>>>>>>>> >>>>>>>>>> (I believe you have said you leave that to others.) >>>>>>>>> >>>>>>>>> I wrote two compilers and three pre-emptive RTOSs and maybe a hundred >>>>>>>>> embedded programs, >>>>>>>> It is worth pointing out that all of those examples are >>>>>>>> (almost certainly) very different to general purpose software >>>>>>>> and, especially, to application servers and the applications >>>>>>>> that run within them. >>>>>>> >>>>>>> What's not general about an RTOS? Thousands of units were sold. >>>>>> >>>>>> It is a single specialised program than can be used in >>>>>> different end equipment. >>>>>> >>>>>> There's far more to software and software development >>>>>> than that. >>>>>> >>>>>> >>>>>> >>>>>>>> Ditto your organisation and the organisations that write/maintain >>>>>>>> such codebases. >>>>>>>> >>>>>>>> Thus it is unsurprising that you do not understand modern >>>>>>>> medium/large scale software and software practices. Especially >>>>>>>> the congruences with medium/large scale hardware. >>>>>>> >>>>>>> This is an electronic design group. I deal with the software that >>>>>>> makes electronic instruments work. My relationship to servers is that >>>>>>> I have to talk to them, feed them javascript and UDP packets and such. >>>>>> >>>>>> No doubt. >>>>>> >>>>>> But it confirms that you have no experience of creating >>>>>> large-scale software systems using modern techniques. >>>>>> >>>>>> It is therefore unsurprising that you haven't understood >>>>>> the congruences with hardware. >>>>> >>>>> Congruences between large scale software "using modern techniques" and >>>>> hardware? Interesting! Since you're obviously expert in both, I'd like to >>>>> learn more. >>>> >>>> More of a jack of all trades and master of none, by choice. >>>> That has advantages and disadvantages. >>>> >>>> >>>>> What are they, exactly? >>>> >>>> That would take a /long/ time to discuss, especially if >>>> half the concepts are unfamiliar to the audience. >>>> To take /one/ example >>>> - how application server frameworks are designed >>>> and implemented >>>> - design patterns in the applications' components >>>> and the way they are composed to form an application, >>>> - design patterns used to communicate with the outside >>>> world, >>>> - antipatterns found in politics, development and design >>>> >>>> It is a good topic for a conversation in pubs. >>>> >>>> I normally start it by provocatively asking someone to >>>> distinguish between hardware and software. They normally >>>> claim it is obvious and come up with a definition. Then >>>> I introduce them to examples that don't fit their definition. >>>> Rinse and repeat. > >>>> Sometimes it can take a long time to realise what the >>>> proponents of a particular technique are doing, because >>>> they use unfamiliar terms to describe things that are >>>> standard in other fields. >>>> >>>> Some examples: >>>> - Jackson's Structured Programming >>>> - Harel StateCharts >>>> - many of the more esoteric UML diagrams >>>> - Hatley and Pirbhai's Strategies for Realtime Systems >>>> Specification, as successfully used for the Boeing 777 >>>> - and, obviously, object oriented programming >>> >>> So where are the applications to hardware? Even one detailed example would >>> be interesting. >> >> Not application so much as a lack of difference between >> hardware and software. >> >> Harel StateCharts are a formalisation of finite state >> machine diagrams, which can obviously be implemented >> in hardware, software, or a combination of the two. >> >> UML diagrams are so legion that it is embarassing. >> The "Unified" is not far off the superset of diagrams >> from other methodologies. The the well known ones are >> class hierarchy diagrams, there are also "swimlane >> interaction" diagrams, and some that are hierarchical >> structural compositions of software components - just >> like hierarchical schematics complete with i/o ports >> connected by wires. >> >> Hatley and Pirbhai is particularly interesting. >> They have two parallel decomposition hierarchies: >> specification and implementation. Any of the >> subcomponents can be specified in any way convenient, >> e.g. FSMs. >> >> Every element in the specification hierarchy must >> have one or more corresponding entities in the >> implementation hierarchy, and they can be hardware, >> software, mechanical etc. >> >> While the specification hierarchy is almost completely >> executable (and there may be tools to do that), the >> only part that Hatley And Pirbhai automated was a >> database that tracked the complex mappings between >> the various parts of the specification and >> implementation hierarchy components. In aerospace >> trackability is rather important. >> >> In the enterprise arena, many patterns are recognisable, >> some even with accurately suggestive names such as >> "filter", "multiplexer", "demultiplexer", "event", >> "asynchronous X", "synchronous X", "control bus", >> "message bus", "channel". >> >> One of many starting points is >> https://www.enterpriseintegrationpatterns.com/patterns/messaging/index.html > > Okay, so you don't actually have any hardware examples. A pity.True, I don't have a Boeing 777.
Reply by ●June 5, 20202020-06-05
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. 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. 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. 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 https://hobbs-eo.com
Reply by ●June 5, 20202020-06-05
On 6/5/20 10:15 AM, 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. > > >Newer scopes have colour histogramming to show rare events as being rare, which is nice for that sort of thing. If I ever buy a bnew fancy scope, that and the number of traces per second will be why. Cheers Phil "boat anchors rule" 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 https://hobbs-eo.com
