tvb@LeapSecond.com said:

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.  If so, you can use their hardware and their
software environment and write your code like it was running on a bare
machine as long as you add a wrapper to call it from their environment and
start your code with a disable interrupts.

--
These are my opinions.  I hate spam.

On 11/16/16 7:17 PM, Hal Murray wrote:

Lots of this around

If so, you can use their hardware and their

ANd many "supported by Arduino environment" hardware platforms have
hardware that can do the timing.. the teensy alluded to before has
hardware timers that are trivially accessible from the Arduino dev
environment, because Paul at PJRC (or other folks, too) has built
APIs/libraries to get access to the capabilities of the chip.

So you can use the "timer0" library, which is software on a vanilla
Arduino, and hardware on the Freescale processor used on the teensy.

Hi

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

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

Bob

On 11/17/16 4:45 AM, Bob Camp wrote:

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

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

For counting and timing the ARM has hardware counbter/timmer that is made
with logic gates so you don't need software or to disable interrupts.
Most modern uP has loads and loads of peripheral hardware built-in.  With
the ARM there is a lot more of these peripheral devices than there are pins
on the chip so the hard part is learning how to configure the chip (each is
different)

So rather then doing like the PicDiv does, counting cycles in software you
would load up a bunch of config registers to set up a hardware divide by N
counter.

The little AVR chip on the Arduino also has built-in counter but that ARV
chip is pretty low-end so the counter has not the best specs and there are
not so many independent counters

With these counters we could build a scintillation counter that is as good
as you can build using logic gates and not have to resort to assembly
language.  We can program counters to do things like latch their contents
so that if the interrupt handler takes some time to read a value it is OK
because we have a hardware latch.

It takes time to learn to use this, but there are library functions to call
that provide a standard API across several different processors.

using a modern uP is debugging.  Many times we can step through code, line
by line as it executes inside the chip.  Unfortunately the Arduino
environment does not take advantage of this but most professional level
IDEs do.  If time is money source level debugging in C is worth a mint.

Again, you really can get accurate counting, that function in moved to
specialized hardware now that is built into the uP chip.

On Wed, Nov 16, 2016 at 7:17 PM, Hal Murray hmurray@megapathdsl.net wrote:

--

Chris Albertson
Redondo Beach, California

On Wed, Nov 16, 2016 at 8:52 PM, jimlux jimlux@earthlink.net wrote:

It is using the same gcc compiler as "everyone" uses including gcc on PC
hardware.  There is no special trick.  gcc always accepts inline assembly.
just do this  asm (your asm code here);  You can Google "gcc inline
assembly" and find tutorials and examples

But WHY?  Critical timing should likely go on a hardware counter/timer And
I doubt except for tiny examples most developers could write better code
than a modern optimizing compiler

If you are looking for the most bang per buck for Arduino compatible
hardware go to eBay and search for "minimum arm" and you get a bout 1,000
items like this one
http://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-System...
http://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduino-/311156408508

Then using Google you find there exists an Arduino boot loader you can
install.  If you don't like Arduino then rather then a boot loader load
any binary file you like

What's nice about these boards is they really ARE minimal.  The chip's
leads are just run out to 0.1 headers and other connectors and passives.
You can assign most functions to most pins and the CPU is roughly an order
of magnitude better then Arduino  With Arduino it is easy to run out of
(say) analog inputs or especially external interrupts but with this ARM you
don't run out of anything until basically you run of of pins.  There ARE
better boards but not for under $3.

Chris Albertson
Redondo Beach, California

Hi

If you head of into ARM land (or even FPGA’s) there is a bit of a gotcha. If you
want to run a 10 MHz input and a PPS output, you need a counter with at least
24 bits. The peripherals on ARM chips are all over the place. Some have very
fancy timers, but only go to 16 bits. Some have 32 bit timers that aren’t very fancy.
Some timers will clock at the input clock frequency. Others have weird pre-scale
rules on them. Since the pre-scaler is a “can’t get at it” device in terms of restarting,
it puts some limits on what you can do.  With FPGA’s it’s rare to get a 1 pps divider
and all of the other stuff you want to do in less than about 64 flip flops. That’s not
a crazy thing on modern parts. It can be an issue on older parts.

Bob

Am 18.11.2016 um 02:18 schrieb Bob Camp:

The Xilinx XC2064 with 64 FlipFlops is 30 years old or so, RIP!
I don't think that you get FPGAs with less than 10000 flip flops nowadays.

(copy/paste:)

Design Name        ocxo_carrier
Fitting Status          Successful
Software Version  P.20131013
Device Used          XC2C64A-5-VQ44
Date                      10-30-2016, 12:51PM

RESOURCES SUMMARY
Macrocells        Used Pterms        Used Registers      Used
Pins        Used Function Block Inputs
50/64  (79%)    157/224  (71%)    50/64  (79%)          7/33 (22%)
87/160  (55%)

That is about the smallest thing made by Xilinx that you can buy.
It's a CPLD, not even a FPGA.  It runs at 100 MHz, with some care at 200
MHz,
and provides the 1pps on my crystal oven carrier board. It also has the
phase detector to lock the oscillator to an incoming 1pps when locking to
a 5/10 MHz reference frequency  or running free  is not wanted.

Source code is about one page all in all.

<
https://www.flickr.com/photos/137684711@N07/30952263115/in/album-72157662535945536/

and the picture to the right.

In the top left corner of the board is some space for an alternate PICDIV.

(For 200 MHz the CPLD needs a beautiful clock signal.)

I have made a design with 2 of these (or one 2C128) that produces one
fixed 1pps
from a 200 MHz clock and another 1pps that can be shifted over > 1
second in 5 ns steps,
with an interface to a BeagleBoneBlack to receive control  and enough
outputs to
steer some switchable ECL delay lines for 5 ps fine steps.

A 2C64 is $1.50 or so.

regards, Gerhard