On 01/09/20 19:11, Ricketty C wrote:> On Tuesday, September 1, 2020 at 1:03:55 PM UTC-4, Chris wrote: >> On 09/01/20 17:49, piglet wrote: >>> On 01/09/2020 16:11, jlarkin@highlandsniptechnology.com wrote: >>>> >>>> >>>> https://www.electronicdesign.com/technologies/test-measurement/whitepaper/21140081/warning-your-dmm-is-discharging-your-battery-cell?utm_source=EG+ED+Today&utm_medium=email&utm_campaign=CPS200828010&o_eid=7322A4702401H9R&rdx.ident%5Bpull%5D=omeda%7C7322A4702401H9R&oly_enc_id=7322A4702401H9R >>>> >>>> >>>> It's sad how bad the electronics press has become. >>>> >>>> >>>> >>> >>> Ten gigaohms!? I want one that goes to eleven. >>> >>> piglet >>> >> >> Rofl, such contempt :-). Last time I checked, a lot of >> Keysight test gear was running Windoze under the hood, >> not even embedded Linux, or a real time os like VxWorks. > > "Real time"??? I used it on a project with an embedded small form factor PC. There was an OS call to do something simple that didn't return for over 400 uS! We contacted support about this long time and the response, once we got one, was that function has been in use for years and it has no bugs! > > Don't even call VxWorks "real time"!Hint: time is measured in seconds, not Siemens. A 400us (not uS) call does not imply anything about realtime behaviour. A 400us (not uS) call might imply something about performance, depending on what the function did.
typically stupid ED article
Started by ●September 1, 2020
Reply by ●September 1, 20202020-09-01
Reply by ●September 1, 20202020-09-01
On 09/02/20 00:11, Ricketty C wrote:> On Tuesday, September 1, 2020 at 5:20:39 PM UTC-4, Chris wrote: >> On 09/01/20 19:11, Ricketty C wrote: >>> On Tuesday, September 1, 2020 at 1:03:55 PM UTC-4, Chris wrote: >>>> On 09/01/20 17:49, piglet wrote: >>>>> On 01/09/2020 16:11, jlarkin@highlandsniptechnology.com wrote: >>>>>> >>>>>> >>>>>> https://www.electronicdesign.com/technologies/test-measurement/whitepaper/21140081/warning-your-dmm-is-discharging-your-battery-cell?utm_source=EG+ED+Today&utm_medium=email&utm_campaign=CPS200828010&o_eid=7322A4702401H9R&rdx.ident%5Bpull%5D=omeda%7C7322A4702401H9R&oly_enc_id=7322A4702401H9R >>>>>> >>>>>> >>>>>> It's sad how bad the electronics press has become. >>>>>> >>>>>> >>>>>> >>>>> >>>>> Ten gigaohms!? I want one that goes to eleven. >>>>> >>>>> piglet >>>>> >>>> >>>> Rofl, such contempt :-). Last time I checked, a lot of >>>> Keysight test gear was running Windoze under the hood, >>>> not even embedded Linux, or a real time os like VxWorks. >>> >>> "Real time"??? I used it on a project with an embedded small form factor PC. There was an OS call to do something simple that didn't return for over 400 uS! We contacted support about this long time and the response, once we got one, was that function has been in use for years and it has no bugs! >>> >>> Don't even call VxWorks "real time"! >>> >> >> That suggests poor system design, but it depends on what the function >> was doing and host of other variables. Having worked on several rtos >> and vxworks projects in the past, it qualifies for the name real time, >> but good system design is essential to get the best from any sharp >> tool. Anyway this was a critical thread about Keysight and the >> comments look pretty accurate to me... > > I don't recall the exact function, but it was something to do with scheduling or checking a semaphore. I just remember that we used a logic analyzer to measure the timing and was very surprised that support wouldn't even discuss what was going on. The person on the phone was just a person capable of answering the phone. We got our response and could now shove off! > > Even if the response time of the software was adequate, the response time of the company was not. > >Vxworks is basically a scheduler and set of libraries and it's up to the project designer which tasks are needed, designed and implemented. Plenty of scope for common os errors that many engineers would not be aware of, coming from a hardware and not comp sci background. Many engineers, me included, bought books and taught themselves. Even NASA had priority inversion problems in one of their projects, so yes, real time os programming has a minefield of traps to fall into for the unwary. Ten or twenty of us were sent on an in house VxWorks course from Wind River for one project. Didn't learn much new about os theory, but quite a bit about capabilities, which were quite impressive in 1995. Even included a full tcp/ip stack, quite rare for an rtos at the time... Chris ting back then. on one p roject, must have cost to o
Reply by ●September 1, 20202020-09-01
On Wed, 02 Sep 2020 01:23:55 +0100, Chris <xxx.syseng.yyy@gfsys.co.uk> wrote:>On 09/02/20 00:11, Ricketty C wrote: >> On Tuesday, September 1, 2020 at 5:20:39 PM UTC-4, Chris wrote: >>> On 09/01/20 19:11, Ricketty C wrote: >>>> On Tuesday, September 1, 2020 at 1:03:55 PM UTC-4, Chris wrote: >>>>> On 09/01/20 17:49, piglet wrote: >>>>>> On 01/09/2020 16:11, jlarkin@highlandsniptechnology.com wrote: >>>>>>> >>>>>>> >>>>>>> https://www.electronicdesign.com/technologies/test-measurement/whitepaper/21140081/warning-your-dmm-is-discharging-your-battery-cell?utm_source=EG+ED+Today&utm_medium=email&utm_campaign=CPS200828010&o_eid=7322A4702401H9R&rdx.ident%5Bpull%5D=omeda%7C7322A4702401H9R&oly_enc_id=7322A4702401H9R >>>>>>> >>>>>>> >>>>>>> It's sad how bad the electronics press has become. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Ten gigaohms!? I want one that goes to eleven. >>>>>> >>>>>> piglet >>>>>> >>>>> >>>>> Rofl, such contempt :-). Last time I checked, a lot of >>>>> Keysight test gear was running Windoze under the hood, >>>>> not even embedded Linux, or a real time os like VxWorks. >>>> >>>> "Real time"??? I used it on a project with an embedded small form factor PC. There was an OS call to do something simple that didn't return for over 400 uS! We contacted support about this long time and the response, once we got one, was that function has been in use for years and it has no bugs! >>>> >>>> Don't even call VxWorks "real time"! >>>> >>> >>> That suggests poor system design, but it depends on what the function >>> was doing and host of other variables. Having worked on several rtos >>> and vxworks projects in the past, it qualifies for the name real time, >>> but good system design is essential to get the best from any sharp >>> tool. Anyway this was a critical thread about Keysight and the >>> comments look pretty accurate to me... >> >> I don't recall the exact function, but it was something to do with scheduling or checking a semaphore. I just remember that we used a logic analyzer to measure the timing and was very surprised that support wouldn't even discuss what was going on. The person on the phone was just a person capable of answering the phone. We got our response and could now shove off! >> >> Even if the response time of the software was adequate, the response time of the company was not. >> >> > >Vxworks is basically a scheduler and set of libraries and it's >up to the project designer which tasks are needed, designed and >implemented. Plenty of scope for common os errors that many >engineers would not be aware of, coming from a hardware and not >comp sci background. Many engineers, me included, bought books and >taught themselves. Even NASA had priority inversion problems >in one of their projects, so yes, real time os programming has a >minefield of traps to fall into for the unwary. > >Ten or twenty of us were sent on an in house VxWorks course from >Wind River for one project. Didn't learn much new about os theory, >but quite a bit about capabilities, which were quite impressive >in 1995. Even included a full tcp/ip stack, quite rare for an >rtos at the time... > >Chris > >ting back then. > >on one p >roject, must have cost to oWe did a few products using a Zynq, with dual-core 600 MHz ARM CPUs, running the Linux that comes with the Xilinx tools. Just a little futzing with priorities got a critical task to run with worst-case timeouts in the ballpark of 20 us. "Any OS is an RTOS if it's fast enough."
Reply by ●September 1, 20202020-09-01
On 9/1/2020 11:49 AM, piglet wrote:> On 01/09/2020 16:11, jlarkin@highlandsniptechnology.com wrote: >> >> >> https://www.electronicdesign.com/technologies/test-measurement/whitepaper/21140081/warning-your-dmm-is-discharging-your-battery-cell?utm_source=EG+ED+Today&utm_medium=email&utm_campaign=CPS200828010&o_eid=7322A4702401H9R&rdx.ident%5Bpull%5D=omeda%7C7322A4702401H9R&oly_enc_id=7322A4702401H9R >> >> >> It's sad how bad the electronics press has become. >> >> >> > > Ten gigaohms!? I want one that goes to eleven. > > pigletOkay. My old HP3456A says input impedance is >10g ohm for ranges <= 10V. It probably exceeds that even today.
Reply by ●September 1, 20202020-09-01
On Tuesday, September 1, 2020 at 5:38:58 PM UTC-7, John Larkin wrote:> "Any OS is an RTOS if it's fast enough."Not true. Our-of-order execution and uncontrolled interrupts are tools of Finagle and his gremlins.
Reply by ●September 1, 20202020-09-01
jla...@highlandsniptechnology.com wrote: =========================================> https://www.electronicdesign.com/technologies/test-measurement/whitepaper/21140081/warning-your-dmm-is-discharging-your-battery-cell?utm_source=EG+ED+Today&utm_medium=email&utm_campaign=CPS200828010&o_eid=7322A4702401H9R&rdx.ident%5Bpull%5D=omeda%7C7322A4702401H9R&oly_enc_id=7322A4702401H9R > > It's sad how bad the electronics press has become. >** Leaving a DMM connected to a small cell for months or years implies it is being computer monitored and sampled 24/7. Surely once a day is enough for that purpose ? .... Phil
Reply by ●September 2, 20202020-09-02
On Tuesday, September 1, 2020 at 11:48:15 AM UTC-4, Phil Hobbs wrote:> On 2020-09-01 11:11, jlarkin@highlandsniptechnology.com wrote: > > > > > > https://www.electronicdesign.com/technologies/test-measurement/whitepaper/21140081/warning-your-dmm-is-discharging-your-battery-cell?utm_source=EG+ED+Today&utm_medium=email&utm_campaign=CPS200828010&o_eid=7322A4702401H9R&rdx.ident%5Bpull%5D=omeda%7C7322A4702401H9R&oly_enc_id=7322A4702401H9R > > > > It's sad how bad the electronics press has become. > > > > > > > > Good golly, Miss Molly, I'm sure glad he put in that table. Ohm's law > makes my head hurt. > > The guy works at _Keysight_. "How are the mighty fallen." Or maybe > it's their customers.I didn't read the article, but I liked keysight's latest low-end 'scope offering. 'nice triggering' :^) George H.> > 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 ●September 2, 20202020-09-02
On 02/09/20 02:12, whit3rd wrote:> On Tuesday, September 1, 2020 at 5:38:58 PM UTC-7, John Larkin wrote: > >> "Any OS is an RTOS if it's fast enough." > > Not true. Our-of-order execution and uncontrolled interrupts are > tools of Finagle and his gremlins.Don't forget the effect of caches, which improve the /average/ execution time. Strictly speaking, John's statement is correct. But the problem is /proving/ it is "fast enough".
Reply by ●September 2, 20202020-09-02
On 02/09/20 01:23, Chris wrote:> Even NASA had priority inversion problems > in one of their projects,That "project" happened to be trundling around Mars at the time. On principle the JPL engineers kept the debugging functions enabled, so they were able to capture the trace/log. Once they found the problem, they uploaded a C(!) program which was interpreted(!) by VxWorks, and which flipped a global flag that enabled priority inheritance in the select() calls. http://www.cse.chalmers.se/~risat/Report_MarsPathFinder.pdf
Reply by ●September 2, 20202020-09-02
On 2020-09-01 12:49, piglet wrote:> On 01/09/2020 16:11, jlarkin@highlandsniptechnology.com wrote: >> >> >> https://www.electronicdesign.com/technologies/test-measurement/whitepaper/21140081/warning-your-dmm-is-discharging-your-battery-cell?utm_source=EG+ED+Today&utm_medium=email&utm_campaign=CPS200828010&o_eid=7322A4702401H9R&rdx.ident%5Bpull%5D=omeda%7C7322A4702401H9R&oly_enc_id=7322A4702401H9R >> >> >> It's sad how bad the electronics press has become. >> >> >> > > Ten gigaohms!? I want one that goes to eleven. > > piglet >Another Tap on the voltage divider. 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
