Sign in
Search AT91SAM
Subscribe to AT91SAM
Sponsor
Ads
Discussion Groups
See Also
Discussion Groups | AT91SAM ARM | Super accurate short delays, SAM9XE and GCC?
For users of the Atmel AT91SAM7 and AT91SAM9 ARM CPU chips. Atmel has taken a new direction by combining on chip flash and ram with the ARM CPU on a single die. This provides low cost devices for small systems using the ARM CPU. This group is to exchange information to help users get started and learn how to use the devices.
Super accurate short delays, SAM9XE and GCC? - Dan Lyke - Jun 3 14:45:33 2009
I'm driving some hardware with the SAM9XE that has some hard real time
limits: I need to lower some pins, wait for *two microseconds* then
raise those pins.
Any longer and I let the magic smoke out. Any shorter and the right
thing fails to happen.
I'm doing this on the AT91SAM9XE-EK with code that looks like:
void Strobe( unsigned int bits )
{
LowerPins(...); // an inline function, pin->pio->CODR = bits;
for (int i = 0; i < 7; ++i)
{
__asm__ __volatile__( "nop\n" );
}
__asm__ __volatile__( "nop\n" );
__asm__ __volatile__( "nop\n" );
__asm__ __volatile__( "nop\n" );
__asm__ __volatile__( "nop\n" );
RaisePins(...); // an inline function, pin->pio->SODR = bits;
}
This function is off in its own object module.
Changing the "7" in there is distinctly non-linear, but I have the
feeling that that's because the optimizer sometimes chooses to unroll
the loop. However, it also seems like there's some sort of difference
in how long this takes to run depending on linking: The delay seems to
change every time I compile the project.
Anyone have any idea what's going on? I'm way too acquainted with the
'scope recently.
Dan
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
limits: I need to lower some pins, wait for *two microseconds* then
raise those pins.
Any longer and I let the magic smoke out. Any shorter and the right
thing fails to happen.
I'm doing this on the AT91SAM9XE-EK with code that looks like:
void Strobe( unsigned int bits )
{
LowerPins(...); // an inline function, pin->pio->CODR = bits;
for (int i = 0; i < 7; ++i)
{
__asm__ __volatile__( "nop\n" );
}
__asm__ __volatile__( "nop\n" );
__asm__ __volatile__( "nop\n" );
__asm__ __volatile__( "nop\n" );
__asm__ __volatile__( "nop\n" );
RaisePins(...); // an inline function, pin->pio->SODR = bits;
}
This function is off in its own object module.
Changing the "7" in there is distinctly non-linear, but I have the
feeling that that's because the optimizer sometimes chooses to unroll
the loop. However, it also seems like there's some sort of difference
in how long this takes to run depending on linking: The delay seems to
change every time I compile the project.
Anyone have any idea what's going on? I'm way too acquainted with the
'scope recently.
Dan
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Super accurate short delays, SAM9XE and GCC? - Eric Haver - Jun 3 16:46:33 2009
On Wed, Jun 3, 2009 at 2:43 PM, Dan Lyke wrote:
> I'm driving some hardware with the SAM9XE that has some hard real time
> limits: I need to lower some pins, wait for *two microseconds* then
> raise those pins.
>
> Any longer and I let the magic smoke out. Any shorter and the right
> thing fails to happen.
>
> I'm doing this on the AT91SAM9XE-EK with code that looks like:
>
> void Strobe( unsigned int bits )
> {
> LowerPins(...); // an inline function, pin->pio->CODR = bits;
> for (int i = 0; i < 7; ++i)
> {
> __asm__ __volatile__( "nop\n" );
> }
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> RaisePins(...); // an inline function, pin->pio->SODR = bits;
> }
>
> This function is off in its own object module.
>
> Changing the "7" in there is distinctly non-linear, but I have the
> feeling that that's because the optimizer sometimes chooses to unroll
> the loop. However, it also seems like there's some sort of difference
> in how long this takes to run depending on linking: The delay seems to
> change every time I compile the project.
>
> Anyone have any idea what's going on? I'm way too acquainted with the
> 'scope recently.
>
> Dan
>
> 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. Good Luck.
>
>
> __.
>
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
> I'm driving some hardware with the SAM9XE that has some hard real time
> limits: I need to lower some pins, wait for *two microseconds* then
> raise those pins.
>
> Any longer and I let the magic smoke out. Any shorter and the right
> thing fails to happen.
>
> I'm doing this on the AT91SAM9XE-EK with code that looks like:
>
> void Strobe( unsigned int bits )
> {
> LowerPins(...); // an inline function, pin->pio->CODR = bits;
> for (int i = 0; i < 7; ++i)
> {
> __asm__ __volatile__( "nop\n" );
> }
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> RaisePins(...); // an inline function, pin->pio->SODR = bits;
> }
>
> This function is off in its own object module.
>
> Changing the "7" in there is distinctly non-linear, but I have the
> feeling that that's because the optimizer sometimes chooses to unroll
> the loop. However, it also seems like there's some sort of difference
> in how long this takes to run depending on linking: The delay seems to
> change every time I compile the project.
>
> Anyone have any idea what's going on? I'm way too acquainted with the
> 'scope recently.
>
> Dan
>
> 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. Good Luck.
>
>
> __.
>
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Super accurate short delays, SAM9XE and GCC? - Dan Lyke - Jun 3 17:41:29 2009
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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Eric Haver
> 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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Super accurate short delays, SAM9XE and GCC? - Paul Curtis - Jun 3 17:50:43 2009
Dan Lyke wrote:
> I'm driving some hardware with the SAM9XE that has some hard real time
> limits: I need to lower some pins, wait for *two microseconds* then
> raise those pins.
>
> Any longer and I let the magic smoke out. Any shorter and the right
> thing fails to happen.
>
> I'm doing this on the AT91SAM9XE-EK with code that looks like:
>
> void Strobe( unsigned int bits )
> {
> LowerPins(...); // an inline function, pin->pio->CODR = bits;
> for (int i = 0; i < 7; ++i)
> {
> __asm__ __volatile__( "nop\n" );
> }
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> RaisePins(...); // an inline function, pin->pio->SODR = bits;
> }
>
> This function is off in its own object module.
>
> Changing the "7" in there is distinctly non-linear, but I have the
> feeling that that's because the optimizer sometimes chooses to unroll
> the loop. However, it also seems like there's some sort of difference
> in how long this takes to run depending on linking: The delay seems to
> change every time I compile the project.
>
> Anyone have any idea what's going on? I'm way too acquainted with the
> 'scope recently.
>
I'm sure the performance will depend upon the alignment of the loop.
The STR9 suffers problems too, it had distinctly strange behaviour when
the flash controller, flash burst queue, and ARM9 core collided.
-- Paul.
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
> I'm driving some hardware with the SAM9XE that has some hard real time
> limits: I need to lower some pins, wait for *two microseconds* then
> raise those pins.
>
> Any longer and I let the magic smoke out. Any shorter and the right
> thing fails to happen.
>
> I'm doing this on the AT91SAM9XE-EK with code that looks like:
>
> void Strobe( unsigned int bits )
> {
> LowerPins(...); // an inline function, pin->pio->CODR = bits;
> for (int i = 0; i < 7; ++i)
> {
> __asm__ __volatile__( "nop\n" );
> }
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> RaisePins(...); // an inline function, pin->pio->SODR = bits;
> }
>
> This function is off in its own object module.
>
> Changing the "7" in there is distinctly non-linear, but I have the
> feeling that that's because the optimizer sometimes chooses to unroll
> the loop. However, it also seems like there's some sort of difference
> in how long this takes to run depending on linking: The delay seems to
> change every time I compile the project.
>
> Anyone have any idea what's going on? I'm way too acquainted with the
> 'scope recently.
>
I'm sure the performance will depend upon the alignment of the loop.
The STR9 suffers problems too, it had distinctly strange behaviour when
the flash controller, flash burst queue, and ARM9 core collided.
-- Paul.
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
RE: Super accurate short delays, SAM9XE and GCC? - "Frog Twissell, Blue Sky Solutions" - Jun 3 18:17:10 2009
Surely if the pulse timing is that critical you should use dedicated
hardware?
Frog
_____
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
Dan Lyke
Sent: Thursday, 4 June 2009 9:38 a.m.
To: A...@yahoogroups.com
Subject: Re: [AT91SAM] Super accurate short delays, SAM9XE and GCC?
On Wed, 3 Jun 2009 16:44:23 -0400
Eric Haver com> 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
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.37/2129 - Release Date: 06/03/09
18:00:00
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
hardware?
Frog
_____
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
Dan Lyke
Sent: Thursday, 4 June 2009 9:38 a.m.
To: A...@yahoogroups.com
Subject: Re: [AT91SAM] Super accurate short delays, SAM9XE and GCC?
On Wed, 3 Jun 2009 16:44:23 -0400
Eric Haver
> 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
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.37/2129 - Release Date: 06/03/09
18:00:00
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Super accurate short delays, SAM9XE and GCC? - 42Bastian - Jun 3 21:47:58 2009
Dan Lyke schrieb:
> I'm doing this on the AT91SAM9XE-EK with code that looks like:
>
> void Strobe( unsigned int bits )
> {
> LowerPins(...); // an inline function, pin->pio->CODR = bits;
> for (int i = 0; i < 7; ++i)
> {
> __asm__ __volatile__( "nop\n" );
> }
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> RaisePins(...); // an inline function, pin->pio->SODR = bits;
> }
>
> This function is off in its own object module.
>
> Changing the "7" in there is distinctly non-linear, but I have the
> feeling that that's because the optimizer sometimes chooses to unroll
> the loop. However, it also seems like there's some sort of difference
> in how long this takes to run depending on linking: The delay seems to
> change every time I compile the project.
a) Don't write such code in C, use assembly (even not inline assembly)
b) Does this part have I-TCM, if so, place the code in there.
Otherwise you get runtime differences due to the cache.
c) Lock interrupts.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
> I'm doing this on the AT91SAM9XE-EK with code that looks like:
>
> void Strobe( unsigned int bits )
> {
> LowerPins(...); // an inline function, pin->pio->CODR = bits;
> for (int i = 0; i < 7; ++i)
> {
> __asm__ __volatile__( "nop\n" );
> }
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> RaisePins(...); // an inline function, pin->pio->SODR = bits;
> }
>
> This function is off in its own object module.
>
> Changing the "7" in there is distinctly non-linear, but I have the
> feeling that that's because the optimizer sometimes chooses to unroll
> the loop. However, it also seems like there's some sort of difference
> in how long this takes to run depending on linking: The delay seems to
> change every time I compile the project.
a) Don't write such code in C, use assembly (even not inline assembly)
b) Does this part have I-TCM, if so, place the code in there.
Otherwise you get runtime differences due to the cache.
c) Lock interrupts.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Super accurate short delays, SAM9XE and GCC? - nutleycottage - Jun 4 9:43:39 2009
Hi Dan,
Assuming you can't poll a hardware counter perhaps you could
1) Always compile the function with -O0/Write the function in assembly code.
2) Place the function in non-cacheable memory. Alternatively you may be able to lock the function into the icache but I've never tried this.
Regards
Michael
>
> I'm driving some hardware with the SAM9XE that has some hard real time
> limits: I need to lower some pins, wait for *two microseconds* then
> raise those pins.
>
> Any longer and I let the magic smoke out. Any shorter and the right
> thing fails to happen.
>
> I'm doing this on the AT91SAM9XE-EK with code that looks like:
>
> void Strobe( unsigned int bits )
> {
> LowerPins(...); // an inline function, pin->pio->CODR = bits;
> for (int i = 0; i < 7; ++i)
> {
> __asm__ __volatile__( "nop\n" );
> }
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> RaisePins(...); // an inline function, pin->pio->SODR = bits;
> }
>
> This function is off in its own object module.
>
> Changing the "7" in there is distinctly non-linear, but I have the
> feeling that that's because the optimizer sometimes chooses to unroll
> the loop. However, it also seems like there's some sort of difference
> in how long this takes to run depending on linking: The delay seems to
> change every time I compile the project.
>
> Anyone have any idea what's going on? I'm way too acquainted with the
> 'scope recently.
>
> Dan
>
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Assuming you can't poll a hardware counter perhaps you could
1) Always compile the function with -O0/Write the function in assembly code.
2) Place the function in non-cacheable memory. Alternatively you may be able to lock the function into the icache but I've never tried this.
Regards
Michael
>
> I'm driving some hardware with the SAM9XE that has some hard real time
> limits: I need to lower some pins, wait for *two microseconds* then
> raise those pins.
>
> Any longer and I let the magic smoke out. Any shorter and the right
> thing fails to happen.
>
> I'm doing this on the AT91SAM9XE-EK with code that looks like:
>
> void Strobe( unsigned int bits )
> {
> LowerPins(...); // an inline function, pin->pio->CODR = bits;
> for (int i = 0; i < 7; ++i)
> {
> __asm__ __volatile__( "nop\n" );
> }
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> RaisePins(...); // an inline function, pin->pio->SODR = bits;
> }
>
> This function is off in its own object module.
>
> Changing the "7" in there is distinctly non-linear, but I have the
> feeling that that's because the optimizer sometimes chooses to unroll
> the loop. However, it also seems like there's some sort of difference
> in how long this takes to run depending on linking: The delay seems to
> change every time I compile the project.
>
> Anyone have any idea what's going on? I'm way too acquainted with the
> 'scope recently.
>
> Dan
>
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Re: Super accurate short delays, SAM9XE and GCC? - Eric Pasquier - Jun 4 10:54:55 2009
Hi Dan,
What about writting these lines in an assembler file linked with your project ?
Eric.
----- Original Message -----
From: nutleycottage
To: A...@yahoogroups.com
Sent: Thursday, June 04, 2009 3:42 PM
Subject: [AT91SAM] Re: Super accurate short delays, SAM9XE and GCC?
Hi Dan,
Assuming you can't poll a hardware counter perhaps you could
1) Always compile the function with -O0/Write the function in assembly code.
2) Place the function in non-cacheable memory. Alternatively you may be able to lock the function into the icache but I've never tried this.
Regards
Michael
>
> I'm driving some hardware with the SAM9XE that has some hard real time
> limits: I need to lower some pins, wait for *two microseconds* then
> raise those pins.
>
> Any longer and I let the magic smoke out. Any shorter and the right
> thing fails to happen.
>
> I'm doing this on the AT91SAM9XE-EK with code that looks like:
>
> void Strobe( unsigned int bits )
> {
> LowerPins(...); // an inline function, pin->pio->CODR = bits;
> for (int i = 0; i < 7; ++i)
> {
> __asm__ __volatile__( "nop\n" );
> }
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> RaisePins(...); // an inline function, pin->pio->SODR = bits;
> }
>
> This function is off in its own object module.
>
> Changing the "7" in there is distinctly non-linear, but I have the
> feeling that that's because the optimizer sometimes chooses to unroll
> the loop. However, it also seems like there's some sort of difference
> in how long this takes to run depending on linking: The delay seems to
> change every time I compile the project.
>
> Anyone have any idea what's going on? I'm way too acquainted with the
> 'scope recently.
>
> Dan
>
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
What about writting these lines in an assembler file linked with your project ?
Eric.
----- Original Message -----
From: nutleycottage
To: A...@yahoogroups.com
Sent: Thursday, June 04, 2009 3:42 PM
Subject: [AT91SAM] Re: Super accurate short delays, SAM9XE and GCC?
Hi Dan,
Assuming you can't poll a hardware counter perhaps you could
1) Always compile the function with -O0/Write the function in assembly code.
2) Place the function in non-cacheable memory. Alternatively you may be able to lock the function into the icache but I've never tried this.
Regards
Michael
>
> I'm driving some hardware with the SAM9XE that has some hard real time
> limits: I need to lower some pins, wait for *two microseconds* then
> raise those pins.
>
> Any longer and I let the magic smoke out. Any shorter and the right
> thing fails to happen.
>
> I'm doing this on the AT91SAM9XE-EK with code that looks like:
>
> void Strobe( unsigned int bits )
> {
> LowerPins(...); // an inline function, pin->pio->CODR = bits;
> for (int i = 0; i < 7; ++i)
> {
> __asm__ __volatile__( "nop\n" );
> }
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> __asm__ __volatile__( "nop\n" );
> RaisePins(...); // an inline function, pin->pio->SODR = bits;
> }
>
> This function is off in its own object module.
>
> Changing the "7" in there is distinctly non-linear, but I have the
> feeling that that's because the optimizer sometimes chooses to unroll
> the loop. However, it also seems like there's some sort of difference
> in how long this takes to run depending on linking: The delay seems to
> change every time I compile the project.
>
> Anyone have any idea what's going on? I'm way too acquainted with the
> 'scope recently.
>
> Dan
>
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Super accurate short delays, SAM9XE and GCC? - Dan Lyke - Jun 4 18:40:46 2009
On Thu, 4 Jun 2009 09:56:33 +1200
"Frog Twissell, Blue Sky Solutions" 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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
"Frog Twissell, Blue Sky Solutions"
> 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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Re: Super accurate short delays, SAM9XE and GCC? - Dan Lyke - Jun 4 18:41:07 2009
On Thu, 4 Jun 2009 16:53:15 +0200
"Eric Pasquier" wrote:
> What about writting these lines in an assembler file linked with your
> project ?
Now that I've got it in its own separate C file the changes on rebuild
seem to have settled down, but if it is, as several have suggested, a
linking alignment issue, then the assembler code wouldn't fix the
problem.
I've got a request for a little clarification on this in to Atmel,
hopefully I'll get all the caching and alignment issues ironed out soon.
Dan
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
"Eric Pasquier"
> What about writting these lines in an assembler file linked with your
> project ?
Now that I've got it in its own separate C file the changes on rebuild
seem to have settled down, but if it is, as several have suggested, a
linking alignment issue, then the assembler code wouldn't fix the
problem.
I've got a request for a little clarification on this in to Atmel,
hopefully I'll get all the caching and alignment issues ironed out soon.
Dan
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
RE: Super accurate short delays, SAM9XE and GCC? - "Frog Twissell, Blue Sky Solutions" - Jun 4 19:14:48 2009
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...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
Dan Lyke
Sent: Friday, 5 June 2009 10:41 a.m.
To: A...@yahoogroups.com
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
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
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...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
Dan Lyke
Sent: Friday, 5 June 2009 10:41 a.m.
To: A...@yahoogroups.com
Subject: Re: [AT91SAM] Super accurate short delays, SAM9XE and GCC?
On Thu, 4 Jun 2009 09:56:33 +1200
"Frog Twissell, Blue Sky Solutions"
> 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
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Super accurate short delays, SAM9XE and GCC? - micr...@virginbroadband.com.au - Jun 5 2:43:02 2009
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
> ------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
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
> On Wed, 3 Jun 2009 16:44:23 -0400
> Eric Haver
>> 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
> ------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Re: Super accurate short delays, SAM9XE and GCC? - Dan Lyke - Jun 8 14:15:07 2009
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()
{
}
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
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()
{
}
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Super accurate short delays, SAM9XE and GCC? - stef33d - Jun 16 6:51:21 2009
--- In A...@yahoogroups.com, 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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
>
> 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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Re: Super accurate short delays, SAM9XE and GCC? - Dan Lyke - Jun 16 10:35:31 2009
On Tue, 16 Jun 2009 10:49:37 -0000
"stef33d" wrote:
> --- In A...@yahoogroups.com, 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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
"stef33d"
> --- In A...@yahoogroups.com, Dan Lyke
> >
> > 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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )