typically stupid ED article

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

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

Not true. Our-of-order execution and uncontrolled interrupts are tools of Finagle and his gremlins.

========================= ================

01H9R ** Leaving a DMM connected to a small cell for months or years implies it i s being computer monitored and sampled 24/7.

Surely once a day is enough for that purpose ?

.... Phil

2401H9R

I didn't read the article, but I liked keysight's latest low-end 'scope offering. 'nice triggering' :^) George H.

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

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.

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

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

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

--

John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 

  Claude Bernard

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.

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

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

:-) 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.

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

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

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

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

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

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.

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

Galvos were slow and not very sensitive. A decent DVM will leak picoamps on a low voltage range, and not take 30 minutes of your time to make a measurement.

I charged a 2.2u film cap to 5 volts and plugged that into my Fluke. I'll watch that for a while.

There are cheap opamps with fA input currents.