typically stupid ED article...

[Tom Gardner]

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.

 

[Chris]

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

 

[John Larkin]

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 o

We 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.\"

 

[John S]

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.

piglet

Okay. My old HP3456A says input impedance is >10g ohm for ranges <= 10V.

It probably exceeds that even today.

 

[whit3rd]

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.

 

[Phil Allison]

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

 

[George Herold]

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

 

[Tom Gardner]

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\".

 

[Tom Gardner]

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

 

[Phil Hobbs]

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

 

[server]

On Wed, 2 Sep 2020 07:42:42 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

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\".

I measured the Linux performance with an oscilloscope. My programmer
couldn\'t estimate timing within a factor of 20 or so. I have to push
him to do terrifying stuff like interrupting at 4 KHz. I did useful 20
KHz interrupts on a 68332, roughly one cent of the power in the Zynq.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[server]

On Wed, 2 Sep 2020 07:36:28 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

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

Even a 10M input, $20 DVM is a decent picoammeter.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[Tom Gardner]

On 02/09/20 15:33, jlarkin@highlandsniptechnology.com wrote:

On Wed, 2 Sep 2020 07:42:42 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

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\".

I measured the Linux performance with an oscilloscope. My programmer
couldn\'t estimate timing within a factor of 20 or so. I have to push
him to do terrifying stuff like interrupting at 4 KHz. I did useful 20
KHz interrupts on a 68332, roughly one cent of the power in the Zynq.

With anything that isn\'t bare silicon I\'d be reluctant to
give /hard/ realtime guarantees - even with measurement.

The problem is twofold: there\'s a awful/aweful lot of
/stuff/ in a modern \"desktop\" OS, and very few people
understand all of the stuff stuffed in there. Plus who
knows what is going to kick off infrequently and even
less frequently at the most inconvenient time.

But then I like bare silicon coding.

Unfortunately, even with bare silicon coding, caches & OoO
can be a problem. They are designed to improve performance
/on average/, but with /hard/ realtime code nobody in their
right mind cares about average. (Soft realtime is fine, and
I\'ve successfully used applications with GC in that mode.)

So, what\'s the effect of caches on peak/mean performance?
I haven\'t got any info for a modern processor, but even on
the intel 486 with its tiny caches and non-Out-of-Order
execution, there could be a 5:1 ratio. God only knows
what it is now.

So IMNSHO, linux + Out of Order + caches is not suitable
for interesting *hard* realtime performance.

 

[Steve Wilson]

jlarkin@highlandsniptechnology.com wrote:

On Wed, 2 Sep 2020 07:36:28 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:
Another Tap on the voltage divider.

Cheers

Phil Hobbs

Even a 10M input, $20 DVM is a decent picoammeter.

Assuming 200 mV on the lowest scale, I get 20 nanoamperes full scale.

 

[Chris]

On 09/02/20 15:57, Tom Gardner wrote:

On 02/09/20 15:33, jlarkin@highlandsniptechnology.com wrote:
On Wed, 2 Sep 2020 07:42:42 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

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\".

I measured the Linux performance with an oscilloscope. My programmer
couldn\'t estimate timing within a factor of 20 or so. I have to push
him to do terrifying stuff like interrupting at 4 KHz. I did useful 20
KHz interrupts on a 68332, roughly one cent of the power in the Zynq.

With anything that isn\'t bare silicon I\'d be reluctant to
give /hard/ realtime guarantees - even with measurement.

The problem is twofold: there\'s a awful/aweful lot of
/stuff/ in a modern \"desktop\" OS, and very few people
understand all of the stuff stuffed in there. Plus who
knows what is going to kick off infrequently and even
less frequently at the most inconvenient time.

But then I like bare silicon coding.

Unfortunately, even with bare silicon coding, caches & OoO
can be a problem. They are designed to improve performance
/on average/, but with /hard/ realtime code nobody in their
right mind cares about average. (Soft realtime is fine, and
I\'ve successfully used applications with GC in that mode.)

So, what\'s the effect of caches on peak/mean performance?
I haven\'t got any info for a modern processor, but even on
the intel 486 with its tiny caches and non-Out-of-Order
execution, there could be a 5:1 ratio. God only knows
what it is now.

So IMNSHO, linux + Out of Order + caches is not suitable
for interesting *hard* realtime performance.

In practice, you don\'t rely software timing for hard real
time work. Long gone are the days where I would count cycles
in interrupt handlers to ensure timer accuracy, but modern cpus
are so fast compared to older 68xxxx and 8 bit processors that
outright performance is rarely an issue. It it is, the system
design is wrong, or you just put a cpu with more welly. It\'s
easier and less hassle to disable the cpu cache and use just
one core as well.

The last project I worked on had 11 sources of interrupt and
the hard real time requirements meant that a fair bit of processor
time was done in interrupt context. Usually considered dodgy
practice, but the system architecture and processor had already
been chosen and just had to make it work with what was there.
No real time os either, just a state driven loop. Rtos\'s may be
fashionable, but it\'s gross overkill for many projects, though
it can force good partitioning and better analysis of the
various subsystems...

Chris

 

[Martin Brown]

On 01/09/2020 16:48, 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.

Helps to use up more real estate in the article.

We should go back to old school potentiometer measurements of voltage -
then no current flows at all when you have balanced the bridge.

I am a bit surprised they use a 10M shunt though. Reliable precision
100M and 1G resistors are relatively common and have been for ages.

The guy works at _Keysight_.  \"How are the mighty fallen.\"  Or maybe
it\'s their customers.

Formerly Agilent, formerly HP - do they change company name each time
there is a body to be buried?

If he was complaining about the load that a Model 7 Avo puts on the
battery under test which ISTR was 500R/volt then he might have a point.
They were virtually indestructible though. I still have a mostly working
one. The ohm\'s range is shot but current and voltage are fine.

--
Regards,
Martin Brown

 

[Tom Gardner]

On 02/09/20 16:45, Chris wrote:

On 09/02/20 15:57, Tom Gardner wrote:
On 02/09/20 15:33, jlarkin@highlandsniptechnology.com wrote:
On Wed, 2 Sep 2020 07:42:42 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

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\".

I measured the Linux performance with an oscilloscope. My programmer
couldn\'t estimate timing within a factor of 20 or so. I have to push
him to do terrifying stuff like interrupting at 4 KHz. I did useful 20
KHz interrupts on a 68332, roughly one cent of the power in the Zynq.

With anything that isn\'t bare silicon I\'d be reluctant to
give /hard/ realtime guarantees - even with measurement.

The problem is twofold: there\'s a awful/aweful lot of
/stuff/ in a modern \"desktop\" OS, and very few people
understand all of the stuff stuffed in there. Plus who
knows what is going to kick off infrequently and even
less frequently at the most inconvenient time.

But then I like bare silicon coding.

Unfortunately, even with bare silicon coding, caches & OoO
can be a problem. They are designed to improve performance
/on average/, but with /hard/ realtime code nobody in their
right mind cares about average. (Soft realtime is fine, and
I\'ve successfully used applications with GC in that mode.)

So, what\'s the effect of caches on peak/mean performance?
I haven\'t got any info for a modern processor, but even on
the intel 486 with its tiny caches and non-Out-of-Order
execution, there could be a 5:1 ratio. God only knows
what it is now.

So IMNSHO, linux + Out of Order + caches is not suitable
for interesting *hard* realtime performance.

In practice, you don\'t rely software timing for hard real
time work. Long gone are the days where I would count cycles
in interrupt handlers to ensure timer accuracy, but modern cpus
are so fast compared to older 68xxxx and 8 bit processors that
outright performance is rarely an issue. It it is, the system
design is wrong, or you just put a cpu with more welly. It\'s
easier and less hassle to disable the cpu cache and use just
one core as well.

Disabling the cache and \"surplus\" cores is a sensible workaround,
but feels so inelegant and wasteful

As for \"plenty of performance for anybody\", that feels like
\"640k is plenty of RAM for anybody\".

The last project I worked on had 11 sources of interrupt and
the hard real time requirements meant that a fair bit of processor
time was done in interrupt context. Usually considered dodgy
practice, but the system architecture and processor had already
been chosen and just had to make it work with what was there.
No real time os either, just a state driven loop. Rtos\'s may be
fashionable, but it\'s gross overkill for many projects, though
it can force good partitioning and better analysis of the
various subsystems...

\"RTOS\" is a very variable feast.

There are very lean and simple RTOSs; some are so lean they
are a pain to use.,

Others were once lean and simple RTOSs but have expanded
over the decades to be \"fully featured\" behemoths.

I must admit to liking event-driven loops for hard realtime
systems, but you still have to know the maximum time it
could take to process an event.

One advantage of RTOSs is drivers for the things I\'d rather
not have to bother with, e.g. ethernet or USB comms with a
host PC. But that\'s not a killer advantage.

 

[Tabby]

On Wednesday, 2 September 2020 17:11:40 UTC+1, Martin Brown wrote:

If he was complaining about the load that a Model 7 Avo puts on the
battery under test which ISTR was 500R/volt then he might have a point.
They were virtually indestructible though. I still have a mostly working
one. The ohm\'s range is shot but current and voltage are fine.

I thought the Avo 7 managed 20k/volt, but it\'s been a mercifully long time since I last used one.
My deity, the first version was 60 ohms per volt!
Model 8 MkII was 20kpv.


NT

 

[Tom Gardner]

On 02/09/20 17:11, Martin Brown wrote:

On 01/09/2020 16:48, 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.

Helps to use up more real estate in the article.

We should go back to old school potentiometer measurements of voltage - then no
current flows at all when you have balanced the bridge.

Literally, in my case. NiFe + Weston cell + metre rule + resistance wire.
Ah, them\'s were the days.

If he was complaining about the load that a Model 7 Avo puts on the battery
under test which ISTR was 500R/volt then he might have a point. They were
virtually indestructible though. I still have a mostly working one. The ohm\'s
range is shot but current and voltage are fine.

I remember a story told at GPO/BT Martlesham Labs.

They had an Avo salesman and a (newfangled) DMM salesman demonstrate
the virtues of their equipment. It was neck-and-neck at the end of
the formal evaluation.

Then the DMM salesman threw the DMM across the room, walked over and
picked it up, and made another measurement.

I don\'t know whether or not he was grinning.

 

[server]

On Wed, 02 Sep 2020 16:45:21 +0100, Chris <xxx.syseng.yyy@gfsys.co.uk>
wrote:

On 09/02/20 15:57, Tom Gardner wrote:
On 02/09/20 15:33, jlarkin@highlandsniptechnology.com wrote:
On Wed, 2 Sep 2020 07:42:42 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

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\".

I measured the Linux performance with an oscilloscope. My programmer
couldn\'t estimate timing within a factor of 20 or so. I have to push
him to do terrifying stuff like interrupting at 4 KHz. I did useful 20
KHz interrupts on a 68332, roughly one cent of the power in the Zynq.

With anything that isn\'t bare silicon I\'d be reluctant to
give /hard/ realtime guarantees - even with measurement.

The problem is twofold: there\'s a awful/aweful lot of
/stuff/ in a modern \"desktop\" OS, and very few people
understand all of the stuff stuffed in there. Plus who
knows what is going to kick off infrequently and even
less frequently at the most inconvenient time.

But then I like bare silicon coding.

Unfortunately, even with bare silicon coding, caches & OoO
can be a problem. They are designed to improve performance
/on average/, but with /hard/ realtime code nobody in their
right mind cares about average. (Soft realtime is fine, and
I\'ve successfully used applications with GC in that mode.)

So, what\'s the effect of caches on peak/mean performance?
I haven\'t got any info for a modern processor, but even on
the intel 486 with its tiny caches and non-Out-of-Order
execution, there could be a 5:1 ratio. God only knows
what it is now.

So IMNSHO, linux + Out of Order + caches is not suitable
for interesting *hard* realtime performance.

In practice, you don\'t rely software timing for hard real
time work. Long gone are the days where I would count cycles
in interrupt handlers to ensure timer accuracy, but modern cpus
are so fast compared to older 68xxxx and 8 bit processors that
outright performance is rarely an issue. It it is, the system
design is wrong, or you just put a cpu with more welly. It\'s
easier and less hassle to disable the cpu cache and use just
one core as well.

The last project I worked on had 11 sources of interrupt and
the hard real time requirements meant that a fair bit of processor
time was done in interrupt context. Usually considered dodgy
practice, but the system architecture and processor had already
been chosen and just had to make it work with what was there.
No real time os either, just a state driven loop. Rtos\'s may be
fashionable, but it\'s gross overkill for many projects, though
it can force good partitioning and better analysis of the
various subsystems...

Chris

I\'ve written three RTOSs and don\'t see any reason to use one these
days. Just do the \"realtime\" stuff in a periodic state machine in a
high-priority task. Overkill on CPU power until you feel comfortable.

Do the really fast processing in the FPGA fabric. For example, let the
FPGA filter a delta-sigma ADC stream, square and filter again. Let the
uP pick that up and finish the RMS calculation whenever it wants to.

Similarly, the fast parts of PID control can be delegated to hardware.






--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard