[time-nuts] precision timing pulse

jimlux jimlux at earthlink.net
Thu Nov 17 08:41:16 EST 2016

On 11/17/16 4:45 AM, Bob Camp wrote:
> Hi
>> On Nov 16, 2016, at 11:52 PM, jimlux <jimlux at earthlink.net> wrote:
>> On 11/16/16 7:17 PM, Hal Murray wrote:
>>> tvb at LeapSecond.com said:
>>>> Arduino probably uses compiled code, external libraries, and interrupts so
>>>> that also is a no-no for precise time.
>>> There are two parts to the Arduino ecosystem.  One is low cost hardware.  The
>>> other is a software package that is easy for non-wizards to use.
>>> I'd be very surprised if somebody hasn't figured out how to call subroutines
>>> coded in assembly language.
>> Lots of this around
> It’s around, but unless you *only* use assembly, there is no way to be sure of what is happening
> on a cycle by cycle basis. Once you put that restriction on things, the whole “cute IDE” part of it
> becomes more of a problem than part of the solution. Since the dividers are always in divide mode
> (there are no spare cycles) you don’t have some part of the process that does not matter ….

I think I would advocate using the hardware devices, and make the 
software part that uses the hardware "non-timing-critical".

> That is only part of the problem. The other part is working out just how the i/o pins get done.
> One thing about even the M series Arm’s … you still get the bus arbitration and cycle
> interleaving stuff. It makes them faster by a noticeable amount. The ones with bus
> cache (M4’s etc) get even more “interesting” when you try to work out exactly which cycle
> the pin toggles on.  They have to do something there (even on simple parts)  since flash runs
> at one speed, I/O at another speed, CPU at yet another clock speed, and RAM tied to either
> CPU or (yikes!!) I/O. The same Teensy board line also has < $30 boards in it with all the
> cache and bus stuff (180 MHz CPU and 26 MHz flash …).

True, but with some time with the processor manual(s), you can figure 
out which clocks are running which parts.   I will say that those little 
parts have an enormous amount of flexibility - there are clock 
generators and muxes here, there, and everywhere.  You really need to 
dig into the docs to figure out exactly how the clocks have been configured.

I suppose this sort of just shifts the time required from "write in 
assembler and count cycles" to "read the 1000 page processor manual and 
look at someone else's library code to figure out what's really going 
on", as well as a "hook it up and write some test programs"

Maybe, like everything, it's a de gustibus non disputandum situation

More information about the time-nuts mailing list