|
Just for general information, I found out today that AD is no longer
offering telephone support for any of the ADSP 210XX line of DSPs.
The only way to get support is via email. You might want to
consider this when choosing a DSP for your next project. Let the buyer beware. -------------------------- Steve Holle Link Communications, Inc. 1035 Cerise Road Billings, Montana 59101-7378 406.245.5002 s...@link-comm.com -------------------------- |
|
|
ADSP 210XX
Started by ●November 20, 2003
Reply by ●November 21, 20032003-11-21
|
> Just for general information, I found out today that AD is no longer offering telephone > support for any of the ADSP 210XX line of DSPs. The only way to get support is via > email. You might want to consider this when choosing a DSP for your next project. Hmmm... What is the future of this line, particularly the 21065L? This part seems to be in a unique "nice place" in terms of value for a floating-point DSP, and we're considering it for a new design. But I certainly don't want to see an EOL notice while we bring up prototypes. |
Reply by ●November 22, 20032003-11-22
|
At 04:15 PM 11/21/2003, James Dabbs wrote: > > Just for general information, I found out today that AD is no longer >offering telephone > > support for any of the ADSP 210XX line of DSPs. The only way to get >support is via > > email. You might want to consider this when choosing a DSP for your >next project. > >Hmmm... > >What is the future of this line, particularly the 21065L? This part >seems to be in a unique "nice place" in terms of value for a >floating-point DSP, and we're considering it for a new design. But I >certainly don't want to see an EOL notice while we bring up prototypes. > I would suggest the ADSP-21262. We are using this part in many of our current projects including our dspstak 21262sx. The 21065L is not really a good choice for a new design. Al Clark Danville Signal Processing, Inc. -------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com |
|
|
Reply by ●November 22, 20032003-11-22
|
But the ADSP-21065L is $25 qty 1, and less than $10 I production quantities. The -----Original Message----- From: Al Clark [mailto:] Sent: Friday, November 21, 2003 6:19 PM To: ; Subject: RE: [adsp] ADSP 210XX At 04:15 PM 11/21/2003, James Dabbs wrote: > > Just for general information, I found out today that AD is no longer >offering telephone > > support for any of the ADSP 210XX line of DSPs. The only way to get >support is via > > email. You might want to consider this when choosing a DSP for your >next project. > >Hmmm... > >What is the future of this line, particularly the 21065L? This part >seems to be in a unique "nice place" in terms of value for a >floating-point DSP, and we're considering it for a new design. But I >certainly don't want to see an EOL notice while we bring up prototypes. > I would suggest the ADSP-21262. We are using this part in many of our current projects including our dspstak 21262sx. The 21065L is not really a good choice for a new design. Al Clark Danville Signal Processing, Inc. -------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: Send an email to To Post: Send an email to To Leave: Send an email to Archives: http://groups.yahoo.com/group/adsp Other Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ |
Reply by ●November 22, 20032003-11-22
|
> I would suggest the ADSP-21262. We are using this part > in many of our current projects including our dspstak > 21262sx. The 21065L is not really a good choice for > a new design. We really need an external memory interface. Also, this particular project won't make it into ROM volumes. Is there a 212XX part imminent with an SDRAM interface, or more generally, does ADI have a low-code floating-point part with SDRAM that *is* within their focus? Where do they point people who ask about the 21065L? |
Reply by ●November 22, 20032003-11-22
|
At 06:43 PM 11/21/2003, James Dabbs wrote: > > I would suggest the ADSP-21262. We are using this part > > in many of our current projects including our dspstak > > 21262sx. The 21065L is not really a good choice for > > a new design. > >We really need an external memory interface. Also, this particular >project won't make it into ROM volumes. Although it is possible to make an ADSP-21262 with ROM, there is no need to do so. You can use either parallel or serial flash memory. We use 2M serial flash with our boards. This keeps the boot memory small with only a few traces needed on the board. There is an external parallel port available but it does not have an SDRAM controller. This is probably the only feature that the 21262 is lacking over earlier parts like the 21065L. >Is there a 212XX part imminent with an SDRAM interface, or more >generally, does ADI have a low-code floating-point part with SDRAM that >*is* within their focus? The 21161 is a better part than the 21065L. It is about 3 times faster (100M & SIMD). We sell boards with this part also. The biggest issue most people have with the 21161 (and why the 21065L is still being used) is that it is only available in BGA. BGAs are expensive and difficult to prototype. We make our dspblok 21161sm to address this problem for small production volumes and prototyping. You probably need at least a 6 layer pc board with this part if you have external memory such as SDRAM. >Where do they point people who ask about the >21065L? They sell them 21065Ls. This is a current part. I'm suggesting that the momentum is with the later generation parts. There are plenty of reasons for needing lots of memory. Most of the time, I find it is for long delay lines. It is rarely for program space. The internal SRAM in the 21262 (2Mbits) is usually more than adequate for most applications. I would examine your requirements to make sure you really need the SDRAM. If you don't need a lot of excess memory, SRAM is also an option. Al Clark Danville Signal Processing, Inc. -------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com |
|
|
Reply by ●November 24, 20032003-11-24
At 04:19 PM 11/21/2003, Al Clark wrote:At 04:15 PM 11/21/2003, James Dabbs wrote: I this part a BGA? That's one of the reasons we went back to the 21065. We haven't had much luck placing BGA's here and many assembly houses have problem with those also. Al Clark-------------------------- Steve Holle Link Communications, Inc. 1035 Cerise Road Billings, Montana 59101-7378 406.245.5002 s...@link-comm.com -------------------------- |
Reply by ●November 24, 20032003-11-24
|
>> >>I would suggest the ADSP-21262. We are using this part in many of our >>current projects including our dspstak 21262sx. The 21065L is not really a >>good choice for a new design. > >I this part a BGA? That's one of the reasons we went back to the >21065. We haven't had much luck placing BGA's here and many assembly >houses have problem with those also. > >The ADSP-21262 is available in either 144 pin LQFP or 136 ball BGA. We >supply our dspblok 21161sm module for customers who want a 21161 solution >without the BGA issues. >>Al Clark >>Danville Signal Processing, Inc. >>-------------------------------- >>Purveyors of Fine DSP Hardware and other Cool Stuff >>Available at http://www.danvillesignal.com >> >> >>_____________________________________ >>Note: If you do a simple "reply" with your email client, only the author >>of this message will receive your answer. You need to do a "reply all" >>if you want your answer to be distributed to the entire group. >> >>_____________________________________ >>About this discussion group: >> >>To Join: Send an email to >> >>To Post: Send an email to >> >>To Leave: Send an email to >> >>Archives: http://groups.yahoo.com/group/adsp >> >>Other Groups: http://www.dsprelated.com/groups.php3 >> >> >>">http://docs.yahoo.com/info/terms/ > >-------------------------- >Steve Holle >Link Communications, Inc. >1035 Cerise Road >Billings, Montana 59101-7378 >406.245.5002 > >-------------------------- Al Clark Danville Signal Processing, Inc. -------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com |
Reply by ●December 12, 20032003-12-12
|
YEPP! We use 21065L and 21161 too and think of switching to 21262 because of the BGA issues. We use SDRAM with the 065 and SRAM with the 161 so the "no SRAM" at 262 would not harm our design. In the 065 project we use one internal bank and lot of external SRAM for code execution. Rarely used code can be redirected to be placed there. It's a kind of brain squeezer but manageable. Beside SDRAM is there any issue not to switch a new project to 21262 DSPs?? Currently run VDSP 2.0 for our 065 project and VDSP 3.0 for the 161 one. Had no luck porting the 065 project to 3.0 last time. In my early version the handling of makefiles failed. Has anyone had more luck with it? Jens Michaelsen > -----Ursprungliche Nachricht----- > Von: > > oo.com > [mailto: > oups.yahoo.com]Im Auftrag von Al Clark > Gesendet: Samstag, 22. November 2003 15:12 > An: ; > Betreff: RE: [adsp] ADSP 210XX > At 06:43 PM 11/21/2003, James Dabbs wrote: > > > I would suggest the ADSP-21262. We are using this part > > > in many of our current projects including our dspstak > > > 21262sx. The 21065L is not really a good choice for > > > a new design. > > > >We really need an external memory interface. Also, this particular > >project won't make it into ROM volumes. > > Although it is possible to make an ADSP-21262 with ROM, there is > no need to > do so. You can use either parallel or serial flash memory. We use > 2M serial > flash with our boards. This keeps the boot memory small with only a few > traces needed on the board. > > There is an external parallel port available but it does not have > an SDRAM > controller. This is probably the only feature that the 21262 is lacking > over earlier parts like the 21065L. > >Is there a 212XX part imminent with an SDRAM interface, or more > >generally, does ADI have a low-code floating-point part with SDRAM that > >*is* within their focus? > > The 21161 is a better part than the 21065L. It is about 3 times faster > (100M & SIMD). We sell boards with this part also. The biggest issue most > people have with the 21161 (and why the 21065L is still being > used) is that > it is only available in BGA. BGAs are expensive and difficult to > prototype. > We make our dspblok 21161sm to address this problem for small production > volumes and prototyping. You probably need at least a 6 layer pc > board with > this part if you have external memory such as SDRAM. |
|
|
Reply by ●December 12, 20032003-12-12
|
--On Friday, December 12, 2003 3:28 PM +0100 "jmi@ded" <> wrote: > In the 065 project we use one internal bank and > lot of external SRAM for code execution. Rarely > used code can be redirected to be placed there. > It's a kind of brain squeezer but manageable. Tip: Use the statistical profiler to see what code is used most frequently, and move that to internal memory. I use macros SLOWCODE, FASTCODE0, and FASTCODE1 (defined as section("seg_extcode"), section("seg_pmda") and section("seg_pmda1")) on individual functions to get fine placement granularity. The macros allow the code to be more easily ported to other CPU's with different placement syntax. (I also have analogous SLOWDATA and FASTDATA macros.) > Currently run VDSP 2.0 for our 065 project > and VDSP 3.0 for the 161 one. Had no luck > porting the 065 project to 3.0 last time. In my > early version the handling of makefiles failed. > Has anyone had more luck with it? Our 65L projects work fine with 3.0. We define an environment variable, ADI21K, with the value being the date of a compiler release (eg. 20031020 would be October 20, 2003). We then test this macro in our makefiles to perform any release-specific things. It can also be passed as a macro to the compiler and linker to work around release bugs and syntax changes. (It's particularly useful in LDF files, which change a lot from release to release.) The important thing is to change the macro's value whenever you upgrade the tools, so that the makefiles can make the right decisions. |
|
|
