Arm development systems

binaries)

You may want to look into rate monotonic schedulers.

?-)

What would that do for me? AFAICT all that does is schedule shorter tasks sooner. It doesn't give me deterministic timing, unless I'm missing something.

Cheers

Phil Hobbs

timing-sensitive

That

very

That (deterministic timing) is exactly what it is supposed to do. Of course there are limits in what the mechanism can do.

Cheers

?-)

You obviously don't do any data acq. Once processor cycle is too much jitter for many, many things.

Cheers

Phil Hobbs

timing-sensitive

That

timing.

very

Well not for a long time (back when the CA3308 was new). If jitter is that sensitive you need to move some of that into an FPGA.

At what CPU frequency? 4 MHz? 200 MHz? Beyond 200 MHz processor speed gets too decoupled from the bus transactions to exhibit anything like CPU clock correspondence.

?-)

No, you just need to use interrupts and count cycles. In the timer ISR, you look at the timer count and jump over the right number of NOPs to align the timing before triggering the ADC. On a modern processor it's never more than one or two of them, unless you have something nasty like a zillion-cycle hardware divide.

Cheers

Phil Hobbs

Modern high-speed processors decouple the CPU from the peripherals with a bus which has its own clock timing and latencies.

Best regards, Spehro Pefhany

The Cortex M3 seems to be much nicer for irqs than the older ARMs - even though the latter have the separate FIQ for fast response,

Also I gather the M0 is designed to be more "deterministic" with respect to instruction execution times.

The M0 core is more of an 8051 replacement, no? So us (we?) old farts that are used to deterministic behavior..

Is there something equivalent to the Mplab "stopwatch" function in an ARM IDE? It would be nice to get a rough idea of how long, say, a multi-channel floating point Chebychev polynomial calculation takes to run (in a simulation environment, it's easy enough to do if you have hardware sitting on the desk).

Best regards, Spehro Pefhany

That

very

Okay, so you're more modern than I am. Be that way. ;) In any case, you don't need an FPGA to get coherent timing.

Cheers

Phil Hobbs

Rowley's CrossWorks does include an "ARM Simulator" as a target (i.e., one loads and runs the simulator in the same way one would load/run through a J-Link JTAG).

From the user manual: "The ARM Simulator target interface provides access to CrossStudio's ARM instruction set simulator (ISS). The ISS simulates the ARM V4T, ARM V5TE, ARM V6-M and ARM V7-M instruction sets as defined in appropriate ARM Architecure Reference Manuals. The ARM architecture, core type and memory endian to be simulated are specified by the project's code generation properties.

The ISS supports MCR and MRC access to the 16 primary registers of the System Control coprocessor (CP15) as defined in the ARM Architecture Reference Manual. The MMU is simulated but the cache isn't. The ISS supports MCR and MRC access to the Debug Communication Channel (CP14) as defined in the ARM7TDMI Technical Reference Manual. The ISS supports a limited subset of VFP instructions (CP10 and CP11) that enable C programs that use the VFP to execute.

The ISS implements a 3 word instruction pre-fetch buffer."

I'd imagine that some of the other large vendors provide a similar functionality but I don't have any direct experience with them.

Dunno (but looks like Rich does downthread).

I use a development board, a pio pin and a scope. Or if I am feeling sophisticated I may use an internal timer!

I was impressed by the software floating point on gcc / cortex M3, I posted the results here or on CAE recently. Can't find it now but my simple benchmark gave:

Float operation benchmarks

Double Precision: 0.415us / 49.852 cycles /multiply 0.378us / 45.403 cycles /add 2.414us / 289.702 cycles /divide Single Precision: 0.194us / 23.350 cycles /multiply 0.250us / 30.052 cycles /add 0.610us / 73.202 cycles / divide

Hmm, that sounds cumbersome. I use a synchronous bus or continously running SPI for that sort of things. Let the hardware do the timing.

timing-sensitive

That

very

How do you get coherent timing when the CPU itself is indeterminate?

That

very

It isn't. Timer interrupts get serviced with a jitter equal to the difference between the lengths of the longest and shortest instructions. All you need to do is to iron that out.

Cheers

Phil Hobbs

Yeah, that's pretty much what I've used. If the timer is simulated that should work okay, but it's not as convenient as the 'stopwatch'.

That's not bad. Once again, the importance of avoiding unnecessary divides is indicated.

timing-sensitive

That

very

...which can be pretty large in itself. You were talking about using NOP (loops) before.

timing-sensitive

That

timing.

isn't very

CPU

If you don't have (or don't use) a slow hardware divide, it's usually between one and three instruction cycles--not a big issue in most cases. Probably a worst-case delay of six or seven cycles, which is very cheap in the circumstances.

Cheers

Phil Hobbs

If you just want to do continuous data acq, that works fine. I'm usually interleaving it with control stuff, though. And once you have the six lines of ASM, it works forever.

Cheers

Phil Hobbs