Hi Dan,
I had in mind something along the lines of a monostable. The extra $1 on
the BOM is perhaps worthwhile vs spontaneous combustion.
Cheers,
Frog
_____
From: A... [mailto:A...] On Behalf Of
Dan Lyke
Sent: Friday, 5 June 2009 10:41 a.m.
To: A...
Subject: Re: [AT91SAM] Super accurate short delays, SAM9XE and GCC?
On Thu, 4 Jun 2009 09:56:33 +1200
"Frog Twissell, Blue Sky Solutions"
ns.co.nz> wrote:
> Surely if the pulse timing is that critical you
should use dedicated
> hardware?
That's what the 9XE is for: handling all the timing critical bits.
It'd
be nice to have an ASIC to do all this stuff, but that's not in the
cards. Could probably have spec'd out an FPGA, but there's enough
general purpose compute and memory shuffling that needs to happen in
this subsystem that just throwing a processor at it seemed like the
right (ie: fastest and least expensive with quantity flexibility) thing
to do.
So Paul suggests that I need to learn a few things about alignment, and
probably delve into my linker files a bit to make sure that functions
are landing where I intend them to. And keep shuffling those no-ops
around and learn a little bit more about ARM assembly language. Sigh,
more bedtime reading...
Dan
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.52/2153 - Release Date: 06/04/09
17:55:00
Super accurate short delays, SAM9XE and GCC?
Started by ●June 3, 2009
Reply by ●June 4, 20092009-06-04
Reply by ●June 5, 20092009-06-05
Hi Dan,
My guess is that the way the literal (7) is yielded changes at ASM level.
"Close-to-a-power-of-2" permutations are easily yielded, whereas some might
require a bit of twiddling around
with multiple instructions. Weirder literals will come from a pool, which
changes instruction further, but I don't think that's the case here.
I don't think GCC would unroll the loop when Opts are off .. ?
Can't you say "fook it", and have a bunch of NOPs inline which you then
jump into at some point, depending on the delay ?
Just throwing some thoughts around...
Best regards,
Kris
On Wed, 3 Jun 2009 14:38:29 -0700, Dan Lyke wrote:
> On Wed, 3 Jun 2009 16:44:23 -0400
> Eric Haver wrote:
>> Hi Dan, First thought is that you have to turn off any interrupts,
>> secondly, set the Assembler to save it's output and look at the
>> assembly code.
>
> Yeah, interrupts are definitely off. No room for them in the hard real
> time stuff, and I spent half an hour this morning cleaning off my desk,
> mouse and half of my keyboard with denatured alcohol because of the kind
> of thing that happens if I go too long on that pulse, definitely not a
> customer experience we can allow...
>
> And I haven't dug into the assembly yet because its a single function
> that hasn't changed, and yet the timing changes, which makes me think
> there's something about alignment and linking that anyone who's worked
> with the ARM before probably knows immediately, but that I don't.
>
> Dan
>
My guess is that the way the literal (7) is yielded changes at ASM level.
"Close-to-a-power-of-2" permutations are easily yielded, whereas some might
require a bit of twiddling around
with multiple instructions. Weirder literals will come from a pool, which
changes instruction further, but I don't think that's the case here.
I don't think GCC would unroll the loop when Opts are off .. ?
Can't you say "fook it", and have a bunch of NOPs inline which you then
jump into at some point, depending on the delay ?
Just throwing some thoughts around...
Best regards,
Kris
On Wed, 3 Jun 2009 14:38:29 -0700, Dan Lyke wrote:
> On Wed, 3 Jun 2009 16:44:23 -0400
> Eric Haver wrote:
>> Hi Dan, First thought is that you have to turn off any interrupts,
>> secondly, set the Assembler to save it's output and look at the
>> assembly code.
>
> Yeah, interrupts are definitely off. No room for them in the hard real
> time stuff, and I spent half an hour this morning cleaning off my desk,
> mouse and half of my keyboard with denatured alcohol because of the kind
> of thing that happens if I go too long on that pulse, definitely not a
> customer experience we can allow...
>
> And I haven't dug into the assembly yet because its a single function
> that hasn't changed, and yet the timing changes, which makes me think
> there's something about alignment and linking that anyone who's worked
> with the ARM before probably knows immediately, but that I don't.
>
> Dan
>
Reply by ●June 8, 20092009-06-08
Just a follow-up, the official suggestion for deterministic timing was
to run the critical code in SRAM. Using the stock linker files that
come with the Softpack examples, that's:
__attribute__ ((section (".ramfunc)))
void MyFunctionThatAlwaysNeedsConsistentTiming()
{
}
to run the critical code in SRAM. Using the stock linker files that
come with the Softpack examples, that's:
__attribute__ ((section (".ramfunc)))
void MyFunctionThatAlwaysNeedsConsistentTiming()
{
}
Reply by ●June 16, 20092009-06-16
--- In A..., Dan Lyke wrote:
>
> Just a follow-up, the official suggestion for deterministic timing was
> to run the critical code in SRAM.
That was the unofficial suggestion in this thread as well if read it correctly. ;-)
Sorry to just walk in like this ...
Just another suggestion: It should be possible to program the Timer Counter for single pulse generation (I have never tried it, but seems possible from the datasheet). But this will require your output to be a TIOx pin.
Regards,
Stef
>
> Just a follow-up, the official suggestion for deterministic timing was
> to run the critical code in SRAM.
That was the unofficial suggestion in this thread as well if read it correctly. ;-)
Sorry to just walk in like this ...
Just another suggestion: It should be possible to program the Timer Counter for single pulse generation (I have never tried it, but seems possible from the datasheet). But this will require your output to be a TIOx pin.
Regards,
Stef
Reply by ●June 16, 20092009-06-16
On Tue, 16 Jun 2009 10:49:37 -0000
"stef33d" wrote:
> --- In A..., Dan Lyke wrote:
> >
> > Just a follow-up, the official suggestion for deterministic timing
> > was to run the critical code in SRAM.
>
> That was the unofficial suggestion in this thread as well if read it
> correctly. ;-)
Yeah, Michael ("nutleycottage") suggested that I "Place the function in
non-cacheable memory.".
> Just another suggestion: It should be possible to program the Timer
> Counter for single pulse generation (I have never tried it, but seems
> possible from the datasheet). But this will require your output to be
> a TIOx pin.
When I'm not bound by various NDAs I'll write a tell-all, but I'm
pretty sure it's nothing that more experienced embedded developers
haven't heard before.
Anyway, yeah, I (one of the software guys) was supposed to have a single
signal pin to trigger the gate for a bit mess of state signals: Set up
all the state bits, toggle that signal pin with the precise timing.
However, it turns out that by the time all the cable length and
capacitance issues fall out that the state signals have much squarer
waves at the end device than the gating signal.
Wonderful theories smashed hard by the realities of hardware design
spread across several continents and languages.
Dan
"stef33d" wrote:
> --- In A..., Dan Lyke wrote:
> >
> > Just a follow-up, the official suggestion for deterministic timing
> > was to run the critical code in SRAM.
>
> That was the unofficial suggestion in this thread as well if read it
> correctly. ;-)
Yeah, Michael ("nutleycottage") suggested that I "Place the function in
non-cacheable memory.".
> Just another suggestion: It should be possible to program the Timer
> Counter for single pulse generation (I have never tried it, but seems
> possible from the datasheet). But this will require your output to be
> a TIOx pin.
When I'm not bound by various NDAs I'll write a tell-all, but I'm
pretty sure it's nothing that more experienced embedded developers
haven't heard before.
Anyway, yeah, I (one of the software guys) was supposed to have a single
signal pin to trigger the gate for a bit mess of state signals: Set up
all the state bits, toggle that signal pin with the precise timing.
However, it turns out that by the time all the cable length and
capacitance issues fall out that the state signals have much squarer
waves at the end device than the gating signal.
Wonderful theories smashed hard by the realities of hardware design
spread across several continents and languages.
Dan
