Development Tools

cancel
Showing results for 
Search instead for 
Did you mean: 

Development Tools

7,851 Views
Dietrich
Contributor I
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

Labels (1)
0 Kudos
5 Replies

348 Views
Dietrich
Contributor I
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 19, 2005, 10:28 AM
Post #11 of 21 (139 views)
Copy Shortcut
 Re: [ColdFire] interrupt latency [In reply to]  Can't Post 
--------------------------------------------------------------------------------
 
Hi Chris,
I'm also using a 5213. It's a bit different from most other ColdFires. I guess you know most of these details, but I thought I'd outline some of the peculiarities for others on the list:
The MCF5213 has no cache, no SDRAM controller and no external bus. It has 32 kByte of SRAM and 256 kByte Flash on-board, that's it as far as memory goes. The Flash memory has 2-cycle access, but its real-world performance is improved by interleaving and speculative reads.
The management of interrupt sources is also a bit unusual. Most interrupt sources can be assigned any interrupt level (0 - 7) and priority (0-7). The interrupt level is the primary division, the interrupt priority determines priority within a level.
Edge port interrupts (i.e. digital input interrupts) are different. There are 7 of those, and they all have fixed levels and priorities. Edge port 1 has level 1, edge port 2 level 2, and so on. The priority is fixed at midpoint, so theoretically you could have another interrupt source with higher priority than edge port 7, if you program it with level 7 and a priority higher than 3.
Please confirm that you are using edge port 7 and that no other interrupt source is using level 7 with a priority higher than 3.
Regarding atomic operations that could delay the interrupt handling, DIVS.L, DIVU.L, REMS.L and REMU.L instructions use 38 cycles, if the source operand is in memory rather than a register (35 cycles register-to-register). Do you have any DIV or REM operations anywhere in your code?
Generally speaking, it's easier for people to assist if you provide as much detail as possible about your target environment, such as whether any OS is being used (VERY significant for this kind of problem!).
Regards,
Harald Hallen
*********** REPLY SEPARATOR ***********
On 2005-12-17 at 15:49 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
>
>

--------------------------------------------------------------------
Dec 19, 2005, 5:35 PM
Post #12 of 21 (138 views)
Copy Shortcut
 Re: [ColdFire] interrupt latency [In reply to]  Can't Post 
--------------------------------------------------------------------------------
 
Hi Everyone:
Thanks for all the responses and suggestions.
I will summarize some measurements. I find them quite interesting and
cannot explain them either.
I have things running fast enough to do what I need to do, however I just
cannot stop exploring this
ISR business until I understand it completely. I do not know what is wrong
with me :smileywink:
- As mentioned, 5213 coldfire. memory (flash/RAM) is all internal.
Currently all codes is
actually running out of RAM.
- using external edge port interrupt 7. when the ISR is called the 5213
core does adjust the
SR so that no lower priority interrupts can be called. There are no other
level 7 interrupt
sources being used.
- the ISR toggles a hardware bit asap. There are 10 cycles of instructions
before the bit
should change
- home brew OS, easy to shut off.
- no div or rem instructions being used. brutal timing on those opcodes
- cycle time is approx 14ns. (1/73.728MHz)
- all timing measurements done on a scope, so there is some error to them.
- all scope timings below are given in cycles

RESULTS:
1. With nothing running (ie main code is bra.s to itself) The hardware line
goes low and it takes
50 or 52 cycles for the test port to toggle. It ALWAYS takes one of these
two times.
So given ISR overhead it seems to take 40 cycles to jump to start of ISR.
Frankly i think this
is quite brutally long, what is the core doing during this time. But it
seems to be predictable
time so fine.
The 2 different times, seperated by 2 cycles is plausable. the bra.s takes
2 cycles, so the ISR
could be called right away or at most delayed by 2 cycles.
2. Add a nop to the main loop:
loop:
nop
bra.s loop
Interestingly this adds another discrete time that the ISR runs: The test
port now gets toggled
either 48 or 50 or 52 cycles after the event. The nop is 3 cycles. I cant
explain this yet.
3. Add a movem.l to the mix:
loop:
movem.l d1-d7/a0-a6,(a7);
bra.s loop
The movem.l should take 15 cycles (14 registers+1).
The ISR bit now toggles anytime in range from 48 to 76 cycles; although
quantized in 2 cycle units.
This is a range of 28 cycles. Doesn't make sense.
The 5213 ref manual is rather poor. Is a processor cycle really 2 / fsys?
I am not sure divinding
all the cycles counts by 2 helps, although it might for 2 and 3.
The more I try to figure this out the more confused I get. blah.
Chris
 

----- Original Message -----
From: "Chris Becker"
Sent: Saturday, December 17, 2005 3:49 PM
Subject: [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--------------------------------------------------------------------


 
 

Message Edited by Dietrich on 03-31-2006 05:00 PM

Message Edited by Dietrich on 04-01-2006 11:46 AM

Message Edited by Dietrich on 04-04-2006 01:51 PM

0 Kudos

348 Views
Dietrich
Contributor I
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 19, 2005, 6:27 PM
Post #13 of 21 (137 views)
Copy Shortcut
 Re: [ColdFire] interrupt latency [In reply to]  Can't Post 
--------------------------------------------------------------------------------
 
The NOP Is not a NOP you use it to sync the core, no doubt the
reason for the 3 cycles.
It would be interesting to know how long it takes to sync the core. It's
definitely longer than 3 cycles for the 5474.
The interrupt will clear out all the prefeteched and decoded instructions
pipelines. When you think about it 40 cycles to load it all up and getting it
running again isn't too bad.
I't would be really interesting to know if you replaced the movem with 14
moves with auto increments how it comes out time wise relative to the movem.
There is no doubt it won't effect the responce time as badly as each
instruction could be interrupted.
It sounds as if the chip your using has a tiny cache. That being the case
wouldn't most of the movem time be in the time it takes to write to ram?
On Tuesday 20 December 2005 12:35, Chris Becker wrote:
> Hi Everyone:
>
> Thanks for all the responses and suggestions.
>
> I will summarize some measurements. I find them quite interesting and
> cannot explain them either.
> I have things running fast enough to do what I need to do, however I just
> cannot stop exploring this
> ISR business until I understand it completely. I do not know what is wrong
> with me :smileywink:
>
> - As mentioned, 5213 coldfire. memory (flash/RAM) is all internal.
> Currently all codes is
> actually running out of RAM.
>
> - using external edge port interrupt 7. when the ISR is called the 5213
> core does adjust the
> SR so that no lower priority interrupts can be called. There are no other
> level 7 interrupt
> sources being used.
>
> - the ISR toggles a hardware bit asap. There are 10 cycles of instructions
> before the bit
> should change
>
> - home brew OS, easy to shut off.
>
> - no div or rem instructions being used. brutal timing on those opcodes
>
> - cycle time is approx 14ns. (1/73.728MHz)
>
> - all timing measurements done on a scope, so there is some error to them.
>
> - all scope timings below are given in cycles
>
>
> RESULTS:
> 1. With nothing running (ie main code is bra.s to itself) The hardware
> line goes low and it takes
> 50 or 52 cycles for the test port to toggle. It ALWAYS takes one of these
> two times.
> So given ISR overhead it seems to take 40 cycles to jump to start of ISR.
> Frankly i think this
> is quite brutally long, what is the core doing during this time. But it
> seems to be predictable
> time so fine.
> The 2 different times, seperated by 2 cycles is plausable. the bra.s takes
> 2 cycles, so the ISR
> could be called right away or at most delayed by 2 cycles.
>
> 2. Add a nop to the main loop:
> loop:
> nop
> bra.s loop
>
> Interestingly this adds another discrete time that the ISR runs: The test
> port now gets toggled
> either 48 or 50 or 52 cycles after the event. The nop is 3 cycles. I cant
> explain this yet.
>
> 3. Add a movem.l to the mix:
> loop:
> movem.l d1-d7/a0-a6,(a7);
> bra.s loop
>
> The movem.l should take 15 cycles (14 registers+1).
> The ISR bit now toggles anytime in range from 48 to 76 cycles; although
> quantized in 2 cycle units.
> This is a range of 28 cycles. Doesn't make sense.
>
> The 5213 ref manual is rather poor. Is a processor cycle really 2 / fsys?
> I am not sure divinding
> all the cycles counts by 2 helps, although it might for 2 and 3.
> The more I try to figure this out the more confused I get. blah.
>
> Chris
>
>
>
>
> ----- Original Message -----
> From: "Chris Becker"
> Sent: Saturday, December 17, 2005 3:49 PM
> Subject: [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-----------------------------------------------------------------

 

Message Edited by Dietrich on 04-01-2006 11:45 AM

Message Edited by Dietrich on 04-04-2006 01:50 PM

0 Kudos

346 Views
Dietrich
Contributor I
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 20, 2005, 6:47 AM
Post #14 of 21 (134 views)
Copy Shortcut
 Re: [ColdFire] interrupt latency [In reply to]  Can't Post 
--------------------------------------------------------------------------------
 
The NOOP should be the first instruction in interrupt routines. this is
because the coldfire guarentees i instruction will be executed after an
interrupt, and you want that to be a short one.
Tom
On Tue, 2005-12-20 at 13:27 +1100, wrote:
> The NOP Is not a NOP you use it to sync the core, no doubt the
> reason for the 3 cycles.
>
> It would be interesting to know how long it takes to sync the core. It's
> definitely longer than 3 cycles for the 5474.
>
> The interrupt will clear out all the prefeteched and decoded instructions
> pipelines. When you think about it 40 cycles to load it all up and getting it
> running again isn't too bad.
>
> I't would be really interesting to know if you replaced the movem with 14
> moves with auto increments how it comes out time wise relative to the movem.
> There is no doubt it won't effect the responce time as badly as each
> instruction could be interrupted.
>
> It sounds as if the chip your using has a tiny cache. That being the case
> wouldn't most of the movem time be in the time it takes to write to ram?
>
> On Tuesday 20 December 2005 12:35, Chris Becker wrote:
> > Hi Everyone:
> >
> > Thanks for all the responses and suggestions.
> >
> > I will summarize some measurements. I find them quite interesting and
> > cannot explain them either.
> > I have things running fast enough to do what I need to do, however I just
> > cannot stop exploring this
> > ISR business until I understand it completely. I do not know what is wrong
> > with me :smileywink:
> >
> > - As mentioned, 5213 coldfire. memory (flash/RAM) is all internal.
> > Currently all codes is
> > actually running out of RAM.
> >
> > - using external edge port interrupt 7. when the ISR is called the 5213
> > core does adjust the
> > SR so that no lower priority interrupts can be called. There are no other
> > level 7 interrupt
> > sources being used.
> >
> > - the ISR toggles a hardware bit asap. There are 10 cycles of instructions
> > before the bit
> > should change
> >
> > - home brew OS, easy to shut off.
> >
> > - no div or rem instructions being used. brutal timing on those opcodes
> >
> > - cycle time is approx 14ns. (1/73.728MHz)
> >
> > - all timing measurements done on a scope, so there is some error to them.
> >
> > - all scope timings below are given in cycles
> >
> >
> > RESULTS:
> > 1. With nothing running (ie main code is bra.s to itself) The hardware
> > line goes low and it takes
> > 50 or 52 cycles for the test port to toggle. It ALWAYS takes one of these
> > two times.
> > So given ISR overhead it seems to take 40 cycles to jump to start of ISR.
> > Frankly i think this
> > is quite brutally long, what is the core doing during this time. But it
> > seems to be predictable
> > time so fine.
> > The 2 different times, seperated by 2 cycles is plausable. the bra.s takes
> > 2 cycles, so the ISR
> > could be called right away or at most delayed by 2 cycles.
> >
> > 2. Add a nop to the main loop:
> > loop:
> > nop
> > bra.s loop
> >
> > Interestingly this adds another discrete time that the ISR runs: The test
> > port now gets toggled
> > either 48 or 50 or 52 cycles after the event. The nop is 3 cycles. I cant
> > explain this yet.
> >
> > 3. Add a movem.l to the mix:
> > loop:
> > movem.l d1-d7/a0-a6,(a7);
> > bra.s loop
> >
> > The movem.l should take 15 cycles (14 registers+1).
> > The ISR bit now toggles anytime in range from 48 to 76 cycles; although
> > quantized in 2 cycle units.
> > This is a range of 28 cycles. Doesn't make sense.
> >
> > The 5213 ref manual is rather poor. Is a processor cycle really 2 / fsys?
> > I am not sure divinding
> > all the cycles counts by 2 helps, although it might for 2 and 3.
> > The more I try to figure this out the more confused I get. blah.
> >
> > Chris
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Chris Becker" 
> > Sent: Saturday, December 17, 2005 3:49 PM
> > Subject: [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-----------------------------------------------------------------
 
 

Message Edited by Dietrich on 04-01-2006 11:45 AM

Message Edited by Dietrich on 04-04-2006 01:49 PM

0 Kudos

346 Views
Dietrich
Contributor I
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 20, 2005, 6:30 PM
Post #15 of 21 (133 views)
Copy Shortcut
 Re: [ColdFire] interrupt latency [In reply to]  Can't Post 
--------------------------------------------------------------------------------
 
Who told you that?
The sort version
The first instruction is guaranteed execution so you can write to the staus
registers and be sure it is done. The coldfire does not alter the interrupt
priority as the 68k did, your code has to look after it.
The long version.
When you are in an interrupt routine you don't want to be interrupted by a
interrupt with a lower priority. That is when your in a level 3 routine you
really aren't interested in level 2 routines.
The 68k took care of this automatically, the coldfire does not, however the
coldfire garentees the first instruction in an interrupt reoutine is
executed. You take advantage of this and solve the problem by putting an
instruction that writes to the status register that either raises the level
or locks out interrupts bepending on how you feel it should be done.
Regards
 

On Wednesday 21 December 2005 01:47, Tom Burrell wrote:
> The NOOP should be the first instruction in interrupt routines. this is
> because the coldfire guarentees i instruction will be executed after an
> interrupt, and you want that to be a short one.
> Tom
>
> On Tue, 2005-12-20 at 13:27 +1100,  wrote:
> > The NOP Is not a NOP you use it to sync the core, no doubt the
> > reason for the 3 cycles.
> >
> > It would be interesting to know how long it takes to sync the core. It's
> > definitely longer than 3 cycles for the 5474.
> >
> > The interrupt will clear out all the prefeteched and decoded instructions
> > pipelines. When you think about it 40 cycles to load it all up and
> > getting it running again isn't too bad.
> >
> > I't would be really interesting to know if you replaced the movem with 14
> > moves with auto increments how it comes out time wise relative to the
> > movem. There is no doubt it won't effect the responce time as badly as
> > each instruction could be interrupted.
> >
> > It sounds as if the chip your using has a tiny cache. That being the case
> > wouldn't most of the movem time be in the time it takes to write to ram?
> >
> > On Tuesday 20 December 2005 12:35, Chris Becker wrote:
> > > Hi Everyone:
> > >
> > > Thanks for all the responses and suggestions.
> > >
> > > I will summarize some measurements. I find them quite interesting and
> > > cannot explain them either.
> > > I have things running fast enough to do what I need to do, however I
> > > just cannot stop exploring this
> > > ISR business until I understand it completely. I do not know what is
> > > wrong with me :smileywink:
> > >
> > > - As mentioned, 5213 coldfire. memory (flash/RAM) is all internal.
> > > Currently all codes is
> > > actually running out of RAM.
> > >
> > > - using external edge port interrupt 7. when the ISR is called the
> > > 5213 core does adjust the
> > > SR so that no lower priority interrupts can be called. There are no
> > > other level 7 interrupt
> > > sources being used.
> > >
> > > - the ISR toggles a hardware bit asap. There are 10 cycles of
> > > instructions before the bit
> > > should change
> > >
> > > - home brew OS, easy to shut off.
> > >
> > > - no div or rem instructions being used. brutal timing on those
> > > opcodes
> > >
> > > - cycle time is approx 14ns. (1/73.728MHz)
> > >
> > > - all timing measurements done on a scope, so there is some error to
> > > them.
> > >
> > > - all scope timings below are given in cycles
> > >
> > >
> > > RESULTS:
> > > 1. With nothing running (ie main code is bra.s to itself) The hardware
> > > line goes low and it takes
> > > 50 or 52 cycles for the test port to toggle. It ALWAYS takes one of
> > > these two times.
> > > So given ISR overhead it seems to take 40 cycles to jump to start of
> > > ISR. Frankly i think this
> > > is quite brutally long, what is the core doing during this time. But
> > > it seems to be predictable
> > > time so fine.
> > > The 2 different times, seperated by 2 cycles is plausable. the bra.s
> > > takes 2 cycles, so the ISR
> > > could be called right away or at most delayed by 2 cycles.
> > >
> > > 2. Add a nop to the main loop:
> > > loop:
> > > nop
> > > bra.s loop
> > >
> > > Interestingly this adds another discrete time that the ISR runs: The
> > > test port now gets toggled
> > > either 48 or 50 or 52 cycles after the event. The nop is 3 cycles. I
> > > cant explain this yet.
> > >
> > > 3. Add a movem.l to the mix:
> > > loop:
> > > movem.l d1-d7/a0-a6,(a7);
> > > bra.s loop
> > >
> > > The movem.l should take 15 cycles (14 registers+1).
> > > The ISR bit now toggles anytime in range from 48 to 76 cycles; although
> > > quantized in 2 cycle units.
> > > This is a range of 28 cycles. Doesn't make sense.
> > >
> > > The 5213 ref manual is rather poor. Is a processor cycle really 2 /
> > > fsys? I am not sure divinding
> > > all the cycles counts by 2 helps, although it might for 2 and 3.
> > > The more I try to figure this out the more confused I get. blah.
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Chris Becker"
> > > Sent: Saturday, December 17, 2005 3:49 PM
> > > Subject: [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-------------------------------------------------------------

 

Message Edited by Dietrich on 04-01-2006 11:44 AM

Message Edited by Dietrich on 04-04-2006 01:48 PM

0 Kudos

346 Views
Dietrich
Contributor I
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 20, 2005, 7:16 PM
Post #16 of 21 (133 views)
Copy Shortcut
 RE: [ColdFire] interrupt latency [In reply to]  Can't Post 
--------------------------------------------------------------------------------
 
> The 68k took care of this automatically, the coldfire does not,
Hmmm. I am not quite sure this is correct. On page 11-1 of the Coldfire Programmer's Reference Manual, revision 2 it states:
1. The processor makes an internal copy of the status register (SR) and then enters supervisor mode by setting SR[S] and disabling trace mode by clearing SR[T]. The occurrence of an interrupt exception also clears SR[M] and sets the interrupt priority mask, SR[I] to the level of the current interrupt request.
Also, on the same page it discusses the differences between Cold fire and 68000. There is no mention of a fundamental change to interrupt processing and not setting the interrupt priority, as you suggested in your last email.
Bill

> -----Original Message-----
> Sent: Tuesday, December 20, 2005 9:31 PM
> Subject: Re: [ColdFire] interrupt latency
>
>
> Who told you that?
>
> The sort version
> The first instruction is guaranteed execution so you can write to
> the staus
> registers and be sure it is done. The coldfire does not alter the
> interrupt
> priority as the 68k did, your code has to look after it.
>
> The long version.
>
> When you are in an interrupt routine you don't want to be
> interrupted by a
> interrupt with a lower priority. That is when your in a level 3
> routine you
> really aren't interested in level 2 routines.
>
> The 68k took care of this automatically, the coldfire does not,
> however the
> coldfire garentees the first instruction in an interrupt reoutine is
> executed. You take advantage of this and solve the problem by putting an
> instruction that writes to the status register that either raises
> the level
> or locks out interrupts bepending on how you feel it should be done.
>
> Regards
>
>
>
>
> On Wednesday 21 December 2005 01:47, Tom Burrell wrote:
> > The NOOP should be the first instruction in interrupt routines. this is
> > because the coldfire guarentees i instruction will be executed after an
> > interrupt, and you want that to be a short one.
> > Tom
> >
> > On Tue, 2005-12-20 at 13:27 +1100, wrote:
> > > The NOP Is not a NOP you use it to sync the core, no doubt the
> > > reason for the 3 cycles.
> > >
> > > It would be interesting to know how long it takes to sync the
> core. It's
> > > definitely longer than 3 cycles for the 5474.
> > >
> > > The interrupt will clear out all the prefeteched and decoded
> instructions
> > > pipelines. When you think about it 40 cycles to load it all up and
> > > getting it running again isn't too bad.
> > >
> > > I't would be really interesting to know if you replaced the
> movem with 14
> > > moves with auto increments how it comes out time wise relative to the
> > > movem. There is no doubt it won't effect the responce time as badly as
> > > each instruction could be interrupted.
> > >
> > > It sounds as if the chip your using has a tiny cache. That
> being the case
> > > wouldn't most of the movem time be in the time it takes to
> write to ram?
> > >
> > > On Tuesday 20 December 2005 12:35, Chris Becker wrote:
> > > > Hi Everyone:
> > > >
> > > > Thanks for all the responses and suggestions.
> > > >
> > > > I will summarize some measurements. I find them quite
> interesting and
> > > > cannot explain them either.
> > > > I have things running fast enough to do what I need to do, however I
> > > > just cannot stop exploring this
> > > > ISR business until I understand it completely. I do not
> know what is
> > > > wrong with me :smileywink:
> > > >
> > > > - As mentioned, 5213 coldfire. memory (flash/RAM) is all internal.
> > > > Currently all codes is
> > > > actually running out of RAM.
> > > >
> > > > - using external edge port interrupt 7. when the ISR is called the
> > > > 5213 core does adjust the
> > > > SR so that no lower priority interrupts can be called. There are no
> > > > other level 7 interrupt
> > > > sources being used.
> > > >
> > > > - the ISR toggles a hardware bit asap. There are 10 cycles of
> > > > instructions before the bit
> > > > should change
> > > >
> > > > - home brew OS, easy to shut off.
> > > >
> > > > - no div or rem instructions being used. brutal timing on those
> > > > opcodes
> > > >
> > > > - cycle time is approx 14ns. (1/73.728MHz)
> > > >
> > > > - all timing measurements done on a scope, so there is some error to
> > > > them.
> > > >
> > > > - all scope timings below are given in cycles
> > > >
> > > >
> > > > RESULTS:
> > > > 1. With nothing running (ie main code is bra.s to itself)
> The hardware
> > > > line goes low and it takes
> > > > 50 or 52 cycles for the test port to toggle. It ALWAYS takes one of
> > > > these two times.
> > > > So given ISR overhead it seems to take 40 cycles to jump to start of
> > > > ISR. Frankly i think this
> > > > is quite brutally long, what is the core doing during this
> time. But
> > > > it seems to be predictable
> > > > time so fine.
> > > > The 2 different times, seperated by 2 cycles is plausable.
> the bra.s
> > > > takes 2 cycles, so the ISR
> > > > could be called right away or at most delayed by 2 cycles.
> > > >
> > > > 2. Add a nop to the main loop:
> > > > loop:
> > > > nop
> > > > bra.s loop
> > > >
> > > > Interestingly this adds another discrete time that the ISR
> runs: The
> > > > test port now gets toggled
> > > > either 48 or 50 or 52 cycles after the event. The nop is 3
> cycles. I
> > > > cant explain this yet.
> > > >
> > > > 3. Add a movem.l to the mix:
> > > > loop:
> > > > movem.l d1-d7/a0-a6,(a7);
> > > > bra.s loop
> > > >
> > > > The movem.l should take 15 cycles (14 registers+1).
> > > > The ISR bit now toggles anytime in range from 48 to 76
> cycles; although
> > > > quantized in 2 cycle units.
> > > > This is a range of 28 cycles. Doesn't make sense.
> > > >
> > > > The 5213 ref manual is rather poor. Is a processor cycle really 2 /
> > > > fsys? I am not sure divinding
> > > > all the cycles counts by 2 helps, although it might for 2 and 3.
> > > > The more I try to figure this out the more confused I get. blah.
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Chris Becker"
> > > > Sent: Saturday, December 17, 2005 3:49 PM
> > > > Subject: [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-------------------------------------------------------------

 

Message Edited by Dietrich on 04-01-2006 11:43 AM

Message Edited by Dietrich on 04-04-2006 01:47 PM

0 Kudos