This message contains an entire topic ported from the WildRice - Coldfire forum. Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions. Freescale assumes no responsibility whatsoever with respect to Posted Material. For additional information, please see the Terms of Use - Message Boards and Community Forums. Thank You and Enjoy the Forum!
Dec 14, 2005, 8:01 AM
Post #1 of 21
Re: [ColdFire] Development Tools
--------------------------------------------------------------------------------
My personal prefrence if GNU and P&E. GNU is free, and P&E is
reasonible. Tried CodeWarrior for 6 months could not get a stable
system, Two weeks with GNU and everything is ok. The USB tools from
P&E are a little more expensive but nice.
P&E works with ELF.
Tom
On Wed, 2005-12-14 at 09:59 -0500, Kevin Zhang wrote:
> Hi everybody,
>
> I am new to ColdFire, (was working on HC05/08//11/12, and a little bit 68340). Any suggestion that where I start? And what kind of compiler, debugger, BDM hardware I may afford? CodeWarrior is too expensive to me.
>
> Thank you in advance.
> Kevin--------------------------------------------------------------------
Dec 16, 2005, 6:23 AM
Post #2 of 21
Re: [ColdFire] Development Tools
--------------------------------------------------------------------------------
It was so nice that I got a lot suggestions for my question. Thank you all,
Sarah, Tom, Robert, Jay, NZG. This ColdFire mail list is helpful.
Kevin Zhang
----- Original Message -----
From: "Tom Burrell"
Sent: Wednesday, December 14, 2005 11:01 AM
Subject: Re: [ColdFire] Development Tools
> My personal prefrence if GNU and P&E. GNU is free, and P&E is
> reasonible. Tried CodeWarrior for 6 months could not get a stable
> system, Two weeks with GNU and everything is ok. The USB tools from
> P&E are a little more expensive but nice.
> P&E works with ELF.
> Tom
> On Wed, 2005-12-14 at 09:59 -0500, Kevin Zhang wrote:
>> Hi everybody,
>>
>> I am new to ColdFire, (was working on HC05/08//11/12, and a little bit
>> 68340). Any suggestion that where I start? And what kind of compiler,
>> debugger, BDM hardware I may afford? CodeWarrior is too expensive to me.
>>
>> Thank you in advance.
>> Kevin--------------------------------------------------------------------
Dec 17, 2005, 2:49 PM
Post #3 of 21
[ColdFire] interrupt latency
--------------------------------------------------------------------------------
Hi everyone,
I have been measuring the response time for an external interrupt line (7,
highest priority) going low and the actual ISR running. I am finding the
results rather confusing and inconsistent. The clock speedis 73 MHz so
cycle time is around 14ns.
I have a fetish with knowing where every single cycle is going and I am
finding this quite frusterating.
The reason I care so much is I am using a 5213 with no particularly easy way
of connecting a PCM bus to it. I have found a way to do this but it depends
quite a bit on servicing the external ISR in a consistent amount of time.
There seems to be a very large window of time that the ISR might get
executed in.
Now the movem.l instruction I think is responsible for a lot of this.
Moving 14 registers to/from the stack takes 15 cycles or 210ns. So the ISR
window is now 210ns.
Then there are other lower priority interrupts in the system. I cannot find
any info on how long it takes to vector to an ISR, but my measurements seeem
to indicate 250ns or around 18 cycles. This seems like quite a bit given
that two longs need to pushed on the stack and a jsr executed. Does anybody
know how long it really takes to jump to an ISR?
So now the ISR window is around 250ns.
Now I let a little bit more code run in the system (nothing fancy, nothign
doing much) and the ISR from being triggered takes anywhere from executing
almost right away to a whopping 600ns or 43 cycles later.
That implies to me that there is some atomic instruction somewhere that
takes 43 cycles to execute??? I have yet to find it or figure out what is
going on.
Has anybody been through this already? Or know what might be causing such a
delay in the ISR being executed? With a 14ns cycle time I personally would
kinda thing I could get the highest priority interrupt in the system to run
consistenly within a 200ns window.
Sorry for the length of this rambling email, I am just finding the execution
time of things on this coldfire rather unpredictable. Probably something to
do with the pipeline....
Thanks,
Chris
----- Original Message -----
From: "Kevin Zhang"
Sent: Friday, December 16, 2005 7:23 AM
Subject: Re: [ColdFire] Development Tools
> It was so nice that I got a lot suggestions for my question. Thank you
> all, Sarah, Tom, Robert, Jay, NZG. This ColdFire mail list is helpful.
>
> Kevin Zhang
> ----- Original Message -----
> From: "Tom Burrell"
> Sent: Wednesday, December 14, 2005 11:01 AM
> Subject: Re: [ColdFire] Development Tools
>
>
>> My personal prefrence if GNU and P&E. GNU is free, and P&E is
>> reasonible. Tried CodeWarrior for 6 months could not get a stable
>> system, Two weeks with GNU and everything is ok. The USB tools from
>> P&E are a little more expensive but nice.
>> P&E works with ELF.
>> Tom
>> On Wed, 2005-12-14 at 09:59 -0500, Kevin Zhang wrote:
>>> Hi everybody,
>>>
>>> I am new to ColdFire, (was working on HC05/08//11/12, and a little bit
>>> 68340). Any suggestion that where I start? And what kind of compiler,
>>> debugger, BDM hardware I may afford? CodeWarrior is too expensive to me.
>>>
>>> Thank you in advance.
>>> Kevin--------------------------------------------------------------------
Dec 17, 2005, 11:16 PM
Post #4 of 21
Re: [ColdFire] interrupt latency
--------------------------------------------------------------------------------
>Now the movem.l instruction I think is responsible for a lot of this.
>Moving 14 registers to/from the stack takes 15 cycles or 210ns. So the ISR
>window is now 210ns.
Why move all the registers in the ISR to the stack? If from the ISR
you call a C funciton, you only have to save d0/d1/a0/a1 since the C
function guarentees that it will save/restore teh rest of the
registers...
--
Peter Barada
--------------------------------------------------------------------
Dec 19, 2005, 6:54 AM
Post #5
Re: [ColdFire] interrupt latency
--------------------------------------------------------------------------------
I am not currently working on coldfire, but, I remember putting a noop
at the beginning of each interrupt because the coldfire guarentees to
execute the first instruction of each interrupt. Don't Know if this is
any help.
Tom
On Sat, 2005-12-17 at 15:49 -0700, Chris Becker wrote:
> Hi everyone,
>
> I have been measuring the response time for an external interrupt line (7,
> highest priority) going low and the actual ISR running. I am finding the
> results rather confusing and inconsistent. The clock speedis 73 MHz so
> cycle time is around 14ns.
>
> I have a fetish with knowing where every single cycle is going and I am
> finding this quite frusterating.
>
> The reason I care so much is I am using a 5213 with no particularly easy way
> of connecting a PCM bus to it. I have found a way to do this but it depends
> quite a bit on servicing the external ISR in a consistent amount of time.
> There seems to be a very large window of time that the ISR might get
> executed in.
>
> Now the movem.l instruction I think is responsible for a lot of this.
> Moving 14 registers to/from the stack takes 15 cycles or 210ns. So the ISR
> window is now 210ns.
>
> Then there are other lower priority interrupts in the system. I cannot find
> any info on how long it takes to vector to an ISR, but my measurements seeem
> to indicate 250ns or around 18 cycles. This seems like quite a bit given
> that two longs need to pushed on the stack and a jsr executed. Does anybody
> know how long it really takes to jump to an ISR?
>
> So now the ISR window is around 250ns.
>
> Now I let a little bit more code run in the system (nothing fancy, nothign
> doing much) and the ISR from being triggered takes anywhere from executing
> almost right away to a whopping 600ns or 43 cycles later.
>
> That implies to me that there is some atomic instruction somewhere that
> takes 43 cycles to execute??? I have yet to find it or figure out what is
> going on.
>
> Has anybody been through this already? Or know what might be causing such a
> delay in the ISR being executed? With a 14ns cycle time I personally would
> kinda thing I could get the highest priority interrupt in the system to run
> consistenly within a 200ns window.
>
> Sorry for the length of this rambling email, I am just finding the execution
> time of things on this coldfire rather unpredictable. Probably something to
> do with the pipeline....
>
> Thanks,
> Chris
>
>
> ----- Original Message -----
> From: "Kevin Zhang"
> Sent: Friday, December 16, 2005 7:23 AM
> Subject: Re: [ColdFire] Development Tools
>
>
> > It was so nice that I got a lot suggestions for my question. Thank you
> > all, Sarah, Tom, Robert, Jay, NZG. This ColdFire mail list is helpful.
> >
> > Kevin Zhang
> > ----- Original Message -----
> > From: "Tom Burrell"
> > Sent: Wednesday, December 14, 2005 11:01 AM
> > Subject: Re: [ColdFire] Development Tools
> >
> >
> >> My personal prefrence if GNU and P&E. GNU is free, and P&E is
> >> reasonible. Tried CodeWarrior for 6 months could not get a stable
> >> system, Two weeks with GNU and everything is ok. The USB tools from
> >> P&E are a little more expensive but nice.
> >> P&E works with ELF.
> >> Tom
> >> On Wed, 2005-12-14 at 09:59 -0500, Kevin Zhang wrote:
> >>> Hi everybody,
> >>>
> >>> I am new to ColdFire, (was working on HC05/08//11/12, and a little bit
> >>> 68340). Any suggestion that where I start? And what kind of compiler,
> >>> debugger, BDM hardware I may afford? CodeWarrior is too expensive to me.
> >>>
> >>> Thank you in advance.
> >>> Kevin--------------------------------------------------------------------
Dec 19, 2005, 7:16 AM
Post #6 of 21 (140 views)
Copy Shortcut
Re: [ColdFire] interrupt latency [In reply to] Can't Post
--------------------------------------------------------------------------------
Chris Becker wrote:
>
> I have been measuring the response time for an external interrupt line
> (7, highest priority) going low and the actual ISR running. I am
> finding the results rather confusing and inconsistent. The clock
> speedis 73 MHz so cycle time is around 14ns.
>
> There seems to be a very large window of time that the ISR might get
> executed in.
>
> Now the movem.l instruction I think is responsible for a lot of this.
> Moving 14 registers to/from the stack takes 15 cycles or 210ns. So the
> ISR window is now 210ns.
>
The divide instructions can take up to 35 cycles.
Dec 19, 2005, 8:38 AM
Post #7 of 21 (140 views)
Copy Shortcut
Re: [ColdFire] interrupt latency [In reply to] Can't Post
--------------------------------------------------------------------------------
Hi Chris ---
I had exactly the same issue on the 5282 and I'm afraid the short answer
is "Ya, that's about right." The modular design of the ColdFire core,
while excellent and clever and well-thought-out, means that "Hold
everything gang I've got an interrupt!" isn't quite as sudden and
immediate as we may be used to in more tightly integrated machines. In
a word, anyone can stall the pipeline, for a reason which objectively
may seem irrelevant (getting the EEPROM write clock started...? Only an
issue when waking from sleep but still, how much code does an EEPROM
write within moments of waking up?) but from the module's point of view,
is necessary in order to present the specified interface consistently.
The three things I'd try are:
- Use that first protected instruction inside the ISR to turn off other
interrupts (good ol' movec #$2700,sp) and make sure they're not getting
in the way.
- Change the state of some DIO pin as the second line in the ISR. This
external I/O instruction will itself take time, but it should indicate
if your variability is coming in the get-the-ISR-started phase, or
within the ISR itself. (I know you measured this at 18 cycles --- I got
24 on the 5282 --- but double-check if it's "18 and up".)
- Finally, and most tediously, go through each other module in the
processor to see if it might stall the pipeline for a reason you don't
care about, like cache validity operations or the like. The culprit is
likely far from the actual modules you care about within the ISR. One
way to check if this approach will bear fruit is to have a program which
does *only* this interrupt service, and does not turn on anything else,
not even external SDRAM. This is a program which will consist of
vectors.s / crt0.s and pretty much nothing else. If the variability
disappears, then your problem is Some Other Module introducing a stall
that has nothing to do with your code per se.
Hope this helps ---
--Scott
--------------------------------------------------------------------
Dec 19, 2005, 8:49 AM
Post #8 of 21 (140 views)
Copy Shortcut
Re: [ColdFire] interrupt latency [In reply to] Can't Post
--------------------------------------------------------------------------------
>- Use that first protected instruction inside the ISR to turn off other
>interrupts (good ol' movec #$2700,sp) and make sure they're not getting
>in the way.
I think you meant:
movew #0x2700,%sr
Another point to ponder is that if you have critical section code that
disables interrupts, that can be getting in the way as well.
--
Peter Barada
--------------------------------------------------------------------
Dec 19, 2005, 8:53 AM
Post #9 of 21 (140 views)
Copy Shortcut
Re: [ColdFire] interrupt latency [In reply to] Can't Post
--------------------------------------------------------------------------------
In the old 5206e 2700 caused some kind of trouble, so we used 2600.
check eratta.
Tom
On Mon, 2005-12-19 at 11:49 -0500, Peter Barada wrote:
> >- Use that first protected instruction inside the ISR to turn off other
> >interrupts (good ol' movec #$2700,sp) and make sure they're not getting
> >in the way.
>
> I think you meant:
>
> movew #0x2700,%sr
>
> Another point to ponder is that if you have critical section code that
> disables interrupts, that can be getting in the way as well.
>
--------------------------------------------------------------------
Dec 19, 2005, 9:46 AM
Post #10 of 21 (139 views)
Copy Shortcut
Re: [ColdFire] interrupt latency [In reply to] Can't Post
--------------------------------------------------------------------------------
> I think you meant:
>
> movew #0x2700,%sr
This is where that voice in my head saying "Don't drop assembly code
into the middle of a sentence, you won't get it right" is now saying
"Toldja so toldja so." Thanks for the catch, and the quick response, Peter.
--------------------------------------------------------------------
Message Edited by Dietrich on 04-01-2006 11:47 AM
Message Edited by Dietrich on 04-01-2006 11:49 AM
Message Edited by Dietrich on 04-04-2006 01:52 PM