Hi,
we've prooved (unfortunately we didn't see the spra925 Appendix
before) that the emif of a 5501 device will make an async read acess to the emif
only 1 per 18 cpu cycles. So a really fast read from the async interface is not
possible. tI told us, the 5503/07/09 is much faster in this matter. Can someone
approve this? How fast can you achieve with that devices?
Thanks in advance & Greetings
Michael
EMIF performance
Started by ●November 18, 2005
Reply by ●November 18, 20052005-11-18
Michael-
> > Did TI mention 5502? What about with cache enabled -- still that slow?
> > Can you tell me which TI person you were talking to?
> well cache enabling does not help. We have to read data from a AD-Converter,
> and store it back to a sdram, so a cache won't help (?).
SDRAM or SRAM? Your comment referred to "async EMIF" -- that's not an SDRAM.
> No, the 5502 was not recommend to us by TI Epic Center (I don't want to
> publish a name on this here).
That's fine, but in that case can you ask them if it's Ok? Or ask them to send
e-mail to me so I can continue the dialog? There is confusion here that I want to
resolve. Thanks.
-Jeff
> > Did TI mention 5502? What about with cache enabled -- still that slow?
> > Can you tell me which TI person you were talking to?
> well cache enabling does not help. We have to read data from a AD-Converter,
> and store it back to a sdram, so a cache won't help (?).
SDRAM or SRAM? Your comment referred to "async EMIF" -- that's not an SDRAM.
> No, the 5502 was not recommend to us by TI Epic Center (I don't want to
> publish a name on this here).
That's fine, but in that case can you ask them if it's Ok? Or ask them to send
e-mail to me so I can continue the dialog? There is confusion here that I want to
resolve. Thanks.
-Jeff
Reply by ●November 18, 20052005-11-18
Hi,
> Did TI mention 5502? What about with cache enabled -- still that slow?
> Can you tell me which TI person you were talking to?
well cache enabling does not help. We have to read data from a AD-Converter,
and store it back to a sdram, so a cache won't help (?).
No, the 5502 was not recommend to us by TI Epic Center (I don't want to
publish a name on this here). What I can say they really tried to help us,
but no chance. Anyway, do you have any measurements there? I hope the 5503
can read so fast we need (no cache enabled )
Michael
--
____________________________________________________
Dr.-Ing. Michael Schuster
Geschtsfrer
Enertex Bayern GmbH
Innovative Systemlungen der Energie- und Elektrotechnik
www.enertex.de
Erlachstra 13 91301 Forchheim
Tel: ++49-9191-974 637 Fax: ++49-9191-974 687 Mob:0175 5151913
> Did TI mention 5502? What about with cache enabled -- still that slow?
> Can you tell me which TI person you were talking to?
well cache enabling does not help. We have to read data from a AD-Converter,
and store it back to a sdram, so a cache won't help (?).
No, the 5502 was not recommend to us by TI Epic Center (I don't want to
publish a name on this here). What I can say they really tried to help us,
but no chance. Anyway, do you have any measurements there? I hope the 5503
can read so fast we need (no cache enabled )
Michael
--
____________________________________________________
Dr.-Ing. Michael Schuster
Geschtsfrer
Enertex Bayern GmbH
Innovative Systemlungen der Energie- und Elektrotechnik
www.enertex.de
Erlachstra 13 91301 Forchheim
Tel: ++49-9191-974 637 Fax: ++49-9191-974 687 Mob:0175 5151913
Reply by ●November 19, 20052005-11-19
Jeff
to be clear:
I want to read from serveral AD Converter 16 bit via async read done by the
emif. I do some calculations with the data and then write it to an external
sdram (also on the emif).
The async read of the data has to be fast (e.g. 12 times in 600 ns). A read
during conversion is not possible, so really only 600ns for at least 12
acesses. The problem is the latancy between two async read acess, which is
-as told- 18 cpu clocks! DMA is slightly better, but not really significant.
The spreadsheet was spr924a.pdf, appendix D Table D-1.
TI made a sheet and some measurements. Those tests were peformed on the C5509A
EVM plus from spectrum digital. This EVM is use to emulate the C5503 as the
C5509A is a true superset. The told the 5503/09/07 can read much faster, but
still they couldnot answer all Qs to the latency, especially why a latency is
not proper documented (if you look at timings in the main pdf you won't find
declarations to latency. Look at Figure 5-8. Asynchronous Memory Read
Timings, of the 5501 timing. Do you think, that someone could gueess a read
after read takes 18 more cpu cycles?). We now made a board with the 5503 and
it will come in two weeks from production. We hope we can be at least 1 read
all 4 cpu clocks which would be 200/4 MHz + asyn Timing ~ 50 MHz +async
timing read acesses on the async ad converters' interfaces.
Well,it is Service Request # 1-197223501, if this helps you.
I will ask them Monday if I can give it to you personally!
Thanks
Michael
--
____________________________________________________
Dr.-Ing. Michael Schuster
Geschtsfrer
Enertex Bayern GmbH
Innovative Systemlungen der Energie- und Elektrotechnik
www.enertex.de
Erlachstra 13 91301 Forchheim
Tel: ++49-9191-974 637 Fax: ++49-9191-974 687 Mob:0175 5151913
to be clear:
I want to read from serveral AD Converter 16 bit via async read done by the
emif. I do some calculations with the data and then write it to an external
sdram (also on the emif).
The async read of the data has to be fast (e.g. 12 times in 600 ns). A read
during conversion is not possible, so really only 600ns for at least 12
acesses. The problem is the latancy between two async read acess, which is
-as told- 18 cpu clocks! DMA is slightly better, but not really significant.
The spreadsheet was spr924a.pdf, appendix D Table D-1.
TI made a sheet and some measurements. Those tests were peformed on the C5509A
EVM plus from spectrum digital. This EVM is use to emulate the C5503 as the
C5509A is a true superset. The told the 5503/09/07 can read much faster, but
still they couldnot answer all Qs to the latency, especially why a latency is
not proper documented (if you look at timings in the main pdf you won't find
declarations to latency. Look at Figure 5-8. Asynchronous Memory Read
Timings, of the 5501 timing. Do you think, that someone could gueess a read
after read takes 18 more cpu cycles?). We now made a board with the 5503 and
it will come in two weeks from production. We hope we can be at least 1 read
all 4 cpu clocks which would be 200/4 MHz + asyn Timing ~ 50 MHz +async
timing read acesses on the async ad converters' interfaces.
Well,it is Service Request # 1-197223501, if this helps you.
I will ask them Monday if I can give it to you personally!
Thanks
Michael
--
____________________________________________________
Dr.-Ing. Michael Schuster
Geschtsfrer
Enertex Bayern GmbH
Innovative Systemlungen der Energie- und Elektrotechnik
www.enertex.de
Erlachstra 13 91301 Forchheim
Tel: ++49-9191-974 637 Fax: ++49-9191-974 687 Mob:0175 5151913
Reply by ●November 22, 20052005-11-22
hi,
It is true that 5501 data sheet does not mention about
this extra cycles in the async read memory. But i see
something like that in figure 2-3 of the document
spru621f, which is the 5501/02 emif document.It says
that there is a CE read hold period of 11 cycles which
is not programmable.
As you pointed out, this looks like a documentation
mistake from TI side on 5501 data sheet. Fortunately,
figure 2-3 of the document spru670a, the 5503 emif doc
does not say anything about such extended cycles.
regards,
Dileepan.
--- Michael Schuster <schuster@schu...> wrote:
> Jeff
> to be clear:
>
> I want to read from serveral AD Converter 16 bit via
> async read done by the
> emif. I do some calculations with the data and then
> write it to an external
> sdram (also on the emif).
>
> The async read of the data has to be fast (e.g. 12
> times in 600 ns). A read
> during conversion is not possible, so really only
> 600ns for at least 12
> acesses. The problem is the latancy between two
> async read acess, which is
> -as told- 18 cpu clocks! DMA is slightly better, but
> not really significant.
> The spreadsheet was spr924a.pdf, appendix D Table
> D-1.
>
> TI made a sheet and some measurements. Those tests
> were peformed on the C5509A
> EVM plus from spectrum digital. This EVM is use to
> emulate the C5503 as the
> C5509A is a true superset. The told the 5503/09/07
> can read much faster, but
> still they couldnot answer all Qs to the latency,
> especially why a latency is
> not proper documented (if you look at timings in the
> main pdf you won't find
> declarations to latency. Look at Figure 5-8.
> Asynchronous Memory Read
> Timings, of the 5501 timing. Do you think, that
> someone could gueess a read
> after read takes 18 more cpu cycles?). We now made a
> board with the 5503 and
> it will come in two weeks from production. We hope
> we can be at least 1 read
> all 4 cpu clocks which would be 200/4 MHz + asyn
> Timing ~ 50 MHz +async
> timing read acesses on the async ad converters'
> interfaces.
>
> Well,it is Service Request # 1-197223501, if this
> helps you.
> I will ask them Monday if I can give it to you
> personally!
> Thanks
>
> Michael
> --
> ____________________________________________________
> Dr.-Ing. Michael Schuster
> Geschtsfrer
>
> Enertex Bayern GmbH
> Innovative Systemlungen der Energie- und
> Elektrotechnik
> www.enertex.de
>
> Erlachstra 13 91301 Forchheim
> Tel: ++49-9191-974 637 Fax: ++49-9191-974 687
> Mob:0175 5151913 >
__________________________________
It is true that 5501 data sheet does not mention about
this extra cycles in the async read memory. But i see
something like that in figure 2-3 of the document
spru621f, which is the 5501/02 emif document.It says
that there is a CE read hold period of 11 cycles which
is not programmable.
As you pointed out, this looks like a documentation
mistake from TI side on 5501 data sheet. Fortunately,
figure 2-3 of the document spru670a, the 5503 emif doc
does not say anything about such extended cycles.
regards,
Dileepan.
--- Michael Schuster <schuster@schu...> wrote:
> Jeff
> to be clear:
>
> I want to read from serveral AD Converter 16 bit via
> async read done by the
> emif. I do some calculations with the data and then
> write it to an external
> sdram (also on the emif).
>
> The async read of the data has to be fast (e.g. 12
> times in 600 ns). A read
> during conversion is not possible, so really only
> 600ns for at least 12
> acesses. The problem is the latancy between two
> async read acess, which is
> -as told- 18 cpu clocks! DMA is slightly better, but
> not really significant.
> The spreadsheet was spr924a.pdf, appendix D Table
> D-1.
>
> TI made a sheet and some measurements. Those tests
> were peformed on the C5509A
> EVM plus from spectrum digital. This EVM is use to
> emulate the C5503 as the
> C5509A is a true superset. The told the 5503/09/07
> can read much faster, but
> still they couldnot answer all Qs to the latency,
> especially why a latency is
> not proper documented (if you look at timings in the
> main pdf you won't find
> declarations to latency. Look at Figure 5-8.
> Asynchronous Memory Read
> Timings, of the 5501 timing. Do you think, that
> someone could gueess a read
> after read takes 18 more cpu cycles?). We now made a
> board with the 5503 and
> it will come in two weeks from production. We hope
> we can be at least 1 read
> all 4 cpu clocks which would be 200/4 MHz + asyn
> Timing ~ 50 MHz +async
> timing read acesses on the async ad converters'
> interfaces.
>
> Well,it is Service Request # 1-197223501, if this
> helps you.
> I will ask them Monday if I can give it to you
> personally!
> Thanks
>
> Michael
> --
> ____________________________________________________
> Dr.-Ing. Michael Schuster
> Geschtsfrer
>
> Enertex Bayern GmbH
> Innovative Systemlungen der Energie- und
> Elektrotechnik
> www.enertex.de
>
> Erlachstra 13 91301 Forchheim
> Tel: ++49-9191-974 637 Fax: ++49-9191-974 687
> Mob:0175 5151913 >
__________________________________
Reply by ●November 22, 20052005-11-22
Hi,
> It is true that 5501 data sheet does not mention about
> this extra cycles in the async read memory. But i see
> something like that in figure 2-3 of the document
> spru621f, which is the 5501/02 emif document.It says
> that there is a CE read hold period of 11 cycles which
> is not programmable.
using a 32 bit read you will have 18 cycles latency. If you use the cpu, the
cpu will need 18 cycles (so it can do anything else).
> As you pointed out, this looks like a documentation
> mistake from TI side on 5501 data sheet. Fortunately,
> figure 2-3 of the document spru670a, the 5503 emif doc
> does not say anything about such extended cycles.
it is our hope, that "not say" means those cylces don't exist...
BTW: Why is the SDC3 register of c5503 not supported by the csl lib, which
means you can't config the c5503 to run 200 MHz with a 100 MHz emif, at least
if you want use the csl standard procedere (and not programm registers
directly)? Michael
--
____________________________________________________
Dr.-Ing. Michael Schuster
Geschtsfrer
Enertex Bayern GmbH
Innovative Systemlungen der Energie- und Elektrotechnik
www.enertex.de
Erlachstra 13 91301 Forchheim
Tel: ++49-9191-974 637 Fax: ++49-9191-974 687 Mob:0175 5151913
> It is true that 5501 data sheet does not mention about
> this extra cycles in the async read memory. But i see
> something like that in figure 2-3 of the document
> spru621f, which is the 5501/02 emif document.It says
> that there is a CE read hold period of 11 cycles which
> is not programmable.
using a 32 bit read you will have 18 cycles latency. If you use the cpu, the
cpu will need 18 cycles (so it can do anything else).
> As you pointed out, this looks like a documentation
> mistake from TI side on 5501 data sheet. Fortunately,
> figure 2-3 of the document spru670a, the 5503 emif doc
> does not say anything about such extended cycles.
it is our hope, that "not say" means those cylces don't exist...
BTW: Why is the SDC3 register of c5503 not supported by the csl lib, which
means you can't config the c5503 to run 200 MHz with a 100 MHz emif, at least
if you want use the csl standard procedere (and not programm registers
directly)? Michael
--
____________________________________________________
Dr.-Ing. Michael Schuster
Geschtsfrer
Enertex Bayern GmbH
Innovative Systemlungen der Energie- und Elektrotechnik
www.enertex.de
Erlachstra 13 91301 Forchheim
Tel: ++49-9191-974 637 Fax: ++49-9191-974 687 Mob:0175 5151913
Reply by ●November 22, 20052005-11-22
Am Dienstag, 22. November 2005 15:04 schrieben Sie:
> hi,
>
> i dont think the existing csl has 5503 support.
> Neither the release notes nor the website mentions
> about 5503/07.
I don't know exactly, but does the 5509a have also the sdc3 register? Is this
csl-supported?
Ok, direct programming of the register is not too difficult.
regards
Michael
> hi,
>
> i dont think the existing csl has 5503 support.
> Neither the release notes nor the website mentions
> about 5503/07.
I don't know exactly, but does the 5509a have also the sdc3 register? Is this
csl-supported?
Ok, direct programming of the register is not too difficult.
regards
Michael
Reply by ●January 19, 20062006-01-19
Michael-
Has TI said anything to you about whether you could use a faster external clock, for
example 50 MHz and internal PLL multiplier of 4, and get better EMIF performance?
What is your ext clock / PLL multiplier, vs. the settings used on the EVM C5509A
board?
Are you still operating with 18 cpu cycle between async accesses, or found a way to
improve that?
-Jeff
Michael Schuster wrote:
>
> Jeff
> to be clear:
>
> I want to read from serveral AD Converter 16 bit via async read done by the
> emif. I do some calculations with the data and then write it to an external
> sdram (also on the emif).
>
> The async read of the data has to be fast (e.g. 12 times in 600 ns). A read
> during conversion is not possible, so really only 600ns for at least 12
> acesses. The problem is the latancy between two async read acess, which is
> -as told- 18 cpu clocks! DMA is slightly better, but not really significant.
> The spreadsheet was spr924a.pdf, appendix D Table D-1.
>
> TI made a sheet and some measurements. Those tests were peformed on the C5509A
> EVM plus from spectrum digital. This EVM is use to emulate the C5503 as the
> C5509A is a true superset. The told the 5503/09/07 can read much faster, but
> still they couldnot answer all Qs to the latency, especially why a latency is
> not proper documented (if you look at timings in the main pdf you won't find
> declarations to latency. Look at Figure 5-8. Asynchronous Memory Read
> Timings, of the 5501 timing. Do you think, that someone could gueess a read
> after read takes 18 more cpu cycles?). We now made a board with the 5503 and
> it will come in two weeks from production. We hope we can be at least 1 read
> all 4 cpu clocks which would be 200/4 MHz + asyn Timing ~ 50 MHz +async
> timing read acesses on the async ad converters' interfaces.
>
> Well,it is Service Request # 1-197223501, if this helps you.
> I will ask them Monday if I can give it to you personally!
> Thanks
>
> Michael
> --
> ____________________________________________________
> Dr.-Ing. Michael Schuster
> Geschtsfrer
>
> Enertex Bayern GmbH
> Innovative Systemlungen der Energie- und Elektrotechnik
> www.enertex.de
>
> Erlachstra 13 91301 Forchheim
> Tel: ++49-9191-974 637 Fax: ++49-9191-974 687 Mob:0175 5151913
Has TI said anything to you about whether you could use a faster external clock, for
example 50 MHz and internal PLL multiplier of 4, and get better EMIF performance?
What is your ext clock / PLL multiplier, vs. the settings used on the EVM C5509A
board?
Are you still operating with 18 cpu cycle between async accesses, or found a way to
improve that?
-Jeff
Michael Schuster wrote:
>
> Jeff
> to be clear:
>
> I want to read from serveral AD Converter 16 bit via async read done by the
> emif. I do some calculations with the data and then write it to an external
> sdram (also on the emif).
>
> The async read of the data has to be fast (e.g. 12 times in 600 ns). A read
> during conversion is not possible, so really only 600ns for at least 12
> acesses. The problem is the latancy between two async read acess, which is
> -as told- 18 cpu clocks! DMA is slightly better, but not really significant.
> The spreadsheet was spr924a.pdf, appendix D Table D-1.
>
> TI made a sheet and some measurements. Those tests were peformed on the C5509A
> EVM plus from spectrum digital. This EVM is use to emulate the C5503 as the
> C5509A is a true superset. The told the 5503/09/07 can read much faster, but
> still they couldnot answer all Qs to the latency, especially why a latency is
> not proper documented (if you look at timings in the main pdf you won't find
> declarations to latency. Look at Figure 5-8. Asynchronous Memory Read
> Timings, of the 5501 timing. Do you think, that someone could gueess a read
> after read takes 18 more cpu cycles?). We now made a board with the 5503 and
> it will come in two weeks from production. We hope we can be at least 1 read
> all 4 cpu clocks which would be 200/4 MHz + asyn Timing ~ 50 MHz +async
> timing read acesses on the async ad converters' interfaces.
>
> Well,it is Service Request # 1-197223501, if this helps you.
> I will ask them Monday if I can give it to you personally!
> Thanks
>
> Michael
> --
> ____________________________________________________
> Dr.-Ing. Michael Schuster
> Geschtsfrer
>
> Enertex Bayern GmbH
> Innovative Systemlungen der Energie- und Elektrotechnik
> www.enertex.de
>
> Erlachstra 13 91301 Forchheim
> Tel: ++49-9191-974 637 Fax: ++49-9191-974 687 Mob:0175 5151913
Reply by ●January 19, 20062006-01-19
Jeff,
> Has TI said anything to you about whether you could use a faster external
> clock, for example 50 MHz and internal PLL multiplier of 4, and get better
> EMIF performance?
no, didnot mentioned anthing about that. We generally use 20 MHz outside and a
PLL so we can reach 200 with c5503 or 300 MHz with the c5501 "inside". We
configure emif-SDRAM to run on 100 MHz.
> What is your ext clock / PLL multiplier, vs. the settings used on the EVM
> C5509A board?
We don't have c5509 EVM boards, but custom design boards. Our first try was
with the c5501 - the results I reported here. Now we made a redesign with a
c5503 (recommended by TI). As Ti told us, this was the only way to get rid of
the problems. We now can subsequently read from the async EMIF with 50 MHz.
(If faster, the emif somehow is disturbed, adds extra cycles and needs
effectively more time). So we can do 20ns reads or writes. DMA runs also
perfectly - as long as we don't use const src adressing mode and an even word
adress (see other thread here).
> a way to improve that?
The only way was another dsp, did cost some EURO here (sigh),
Michael
>
> -Jeff
>
> Michael Schuster wrote:
> > Jeff
> > to be clear:
> >
> > I want to read from serveral AD Converter 16 bit via async read done by
> > the emif. I do some calculations with the data and then write it to an
> > external sdram (also on the emif).
> >
> > The async read of the data has to be fast (e.g. 12 times in 600 ns). A
> > read during conversion is not possible, so really only 600ns for at least
> > 12 acesses. The problem is the latancy between two async read acess,
> > which is -as told- 18 cpu clocks! DMA is slightly better, but not really
> > significant. The spreadsheet was spr924a.pdf, appendix D Table D-1.
> >
> > TI made a sheet and some measurements. Those tests were peformed on the
> > C5509A EVM plus from spectrum digital. This EVM is use to emulate the
> > C5503 as the C5509A is a true superset. The told the 5503/09/07 can read
> > much faster, but still they couldnot answer all Qs to the latency,
> > especially why a latency is not proper documented (if you look at timings
> > in the main pdf you won't find declarations to latency. Look at Figure
> > 5-8. Asynchronous Memory Read Timings, of the 5501 timing. Do you think,
> > that someone could gueess a read after read takes 18 more cpu cycles?).
> > We now made a board with the 5503 and it will come in two weeks from
> > production. We hope we can be at least 1 read all 4 cpu clocks which
> > would be 200/4 MHz + asyn Timing ~ 50 MHz +async timing read acesses on
> > the async ad converters' interfaces.
> >
> > Well,it is Service Request # 1-197223501, if this helps you.
> > I will ask them Monday if I can give it to you personally!
> Has TI said anything to you about whether you could use a faster external
> clock, for example 50 MHz and internal PLL multiplier of 4, and get better
> EMIF performance?
no, didnot mentioned anthing about that. We generally use 20 MHz outside and a
PLL so we can reach 200 with c5503 or 300 MHz with the c5501 "inside". We
configure emif-SDRAM to run on 100 MHz.
> What is your ext clock / PLL multiplier, vs. the settings used on the EVM
> C5509A board?
We don't have c5509 EVM boards, but custom design boards. Our first try was
with the c5501 - the results I reported here. Now we made a redesign with a
c5503 (recommended by TI). As Ti told us, this was the only way to get rid of
the problems. We now can subsequently read from the async EMIF with 50 MHz.
(If faster, the emif somehow is disturbed, adds extra cycles and needs
effectively more time). So we can do 20ns reads or writes. DMA runs also
perfectly - as long as we don't use const src adressing mode and an even word
adress (see other thread here).
> a way to improve that?
The only way was another dsp, did cost some EURO here (sigh),
Michael
>
> -Jeff
>
> Michael Schuster wrote:
> > Jeff
> > to be clear:
> >
> > I want to read from serveral AD Converter 16 bit via async read done by
> > the emif. I do some calculations with the data and then write it to an
> > external sdram (also on the emif).
> >
> > The async read of the data has to be fast (e.g. 12 times in 600 ns). A
> > read during conversion is not possible, so really only 600ns for at least
> > 12 acesses. The problem is the latancy between two async read acess,
> > which is -as told- 18 cpu clocks! DMA is slightly better, but not really
> > significant. The spreadsheet was spr924a.pdf, appendix D Table D-1.
> >
> > TI made a sheet and some measurements. Those tests were peformed on the
> > C5509A EVM plus from spectrum digital. This EVM is use to emulate the
> > C5503 as the C5509A is a true superset. The told the 5503/09/07 can read
> > much faster, but still they couldnot answer all Qs to the latency,
> > especially why a latency is not proper documented (if you look at timings
> > in the main pdf you won't find declarations to latency. Look at Figure
> > 5-8. Asynchronous Memory Read Timings, of the 5501 timing. Do you think,
> > that someone could gueess a read after read takes 18 more cpu cycles?).
> > We now made a board with the 5503 and it will come in two weeks from
> > production. We hope we can be at least 1 read all 4 cpu clocks which
> > would be 200/4 MHz + asyn Timing ~ 50 MHz +async timing read acesses on
> > the async ad converters' interfaces.
> >
> > Well,it is Service Request # 1-197223501, if this helps you.
> > I will ask them Monday if I can give it to you personally!
Reply by ●January 31, 20062006-01-31
Jeff,
best to switch to the c5509 /07/03 dsp. These work as expected, I can tell ...
I was told the purpose of the c5501/02 was to work for mobile communcation ,
so the data extern will be transfered to intern memory, where these devices
run really with 300 MHz.
BTW: Using code composer - if you have a hardware at your dsp - doesnot make
sense (to express it reputably). Not even the CSL lib is realy cool. Only
thing, which makes things easier, is the Makro - support of the CSL. We had a
latency for an external interrupt, using code composer (c5503, 200 MHz)
+ dsp-bios 1.6s
+ standard CSL disppatcher 600 ns
+ register programming 60 ns Michael
--
____________________________________________________
Dr.-Ing. Michael Schuster
Geschtsfrer
Enertex Bayern GmbH
Innovative Systemlungen der Energie- und Elektrotechnik
www.enertex.de
Erlachstra 13 91301 Forchheim
Tel: ++49-9191-974 637 Fax: ++49-9191-974 687 Mob:0175 5151913
best to switch to the c5509 /07/03 dsp. These work as expected, I can tell ...
I was told the purpose of the c5501/02 was to work for mobile communcation ,
so the data extern will be transfered to intern memory, where these devices
run really with 300 MHz.
BTW: Using code composer - if you have a hardware at your dsp - doesnot make
sense (to express it reputably). Not even the CSL lib is realy cool. Only
thing, which makes things easier, is the Makro - support of the CSL. We had a
latency for an external interrupt, using code composer (c5503, 200 MHz)
+ dsp-bios 1.6s
+ standard CSL disppatcher 600 ns
+ register programming 60 ns Michael
--
____________________________________________________
Dr.-Ing. Michael Schuster
Geschtsfrer
Enertex Bayern GmbH
Innovative Systemlungen der Energie- und Elektrotechnik
www.enertex.de
Erlachstra 13 91301 Forchheim
Tel: ++49-9191-974 637 Fax: ++49-9191-974 687 Mob:0175 5151913
