Hi Al, I asked this in the MacOS X development thread but apparently it got lost: any plans to support MacOS X in the long run? There are some of us who'd love to do their development work on that platform... -- Stephan M. Bernsee http://www.dspdimension.com
Multi-Sharc architecture
Started by ●December 8, 2004
Reply by ●December 9, 20042004-12-09
Reply by ●December 9, 20042004-12-09
"Jon Harris" <goldentully@hotmail.com> wrote in news:31rks7F3ddvkmU1@individual.net:> "Al Clark" <dsp@danvillesignal.com> wrote in message > news:Xns95B9F35504C2Baclarkdanvillesignal@66.133.130.30... >> "Jon Harris" <goldentully@hotmail.com> wrote in >> news:31pj9lF3ed0f8U1@individual.net: >> >> >> The ADSP-21367 & 21368 include an SDRAM controller. Think of the new >> parts as a hybrid between the 21161 and 21364. >> >> We have new boards coming soon (not on the roadmap or web site) that >> include an FPGA and SDRAM. > > Thanks, Al! Somehow I missed the SDRAM controller feature when I > looked at those parts. If you don't mind me asking, what is the > difference between the '67 and '68? The selection table doesn't show > any differences except for package. > > >The ADSP-21367 is primarily aimed at large OEMs who license audio algorithms (Dolby, DTS, etc) that reside in the ROM. The ADSP-21368 is a more general purpose part. It is the only one that supports multiprocessing. In also has ROM but for the rest of the world market, it won't be used. The new DSPs also have a few new peripherals: 1. Sample Rate Converters (also on the 21364, available soon) 2. S/PDIF transceiver (also on the 21364, available soon) 2. UARTs 3. Two Wire Interface (the legal way to avoid saying I2C) The big change with third generation SHARCs is the abundance and flexibilty of the peripherals. This started with the 21262. They are also 2x4 times faster than the 21161. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com
Reply by ●December 9, 20042004-12-09
Stephan M. Bernsee <spam@dspdimension.com> wrote in news:31ro4kF3diedlU1 @individual.net:> > Hi Al, > > I asked this in the MacOS X development thread but apparently it got > lost: any plans to support MacOS X in the long run? There are some of > us who'd love to do their development work on that platform...Hi Stephan, I'm not sure if I know the context of your question. Our current dspstak boards have USB driver support (via ftdichip.com) for most OS's including MAC. I don't know of any way to run the ADI tools except from Windows. BeastRider tools also support Linux. There is a 21262 version. Of course, you could buy lots of boards and develop the MAC support yourself ;-). We have ZERO experience with the MAC. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com
Reply by ●December 9, 20042004-12-09
On 2004-12-09 21:06:00 +0100, Al Clark <dsp@danvillesignal.com> said:> Hi Stephan, > > I'm not sure if I know the context of your question. > Our current dspstak boards have USB driver support (via ftdichip.com) > for most OS's including MAC. I don't know of any way to run the ADI > tools except from Windows. > > BeastRider tools also support Linux. There is a 21262 version. > > Of course, you could buy lots of boards and develop the MAC support > yourself ;-). We have ZERO experience with the MAC.Yeah sorry for being a bit unclear - the last time I developed on an EZ Kit in the 1990s there was no USB (it was all done with a "real" Wintel box via RS232 IIRC) so I realize this question is indeed a bit silly today. Running the ADI tools from inside VPC is not the problem I suppose. From what I remember, the problem was interfacing the hardware back then because emulating the low level stuff via RS232 never really worked, ie the tools didn't find the board. But that wasn't USB and not OS X then, so I guess this should no longer be an issue today. You did answer the actual question, too: if there are no MacOS X tools for the DSPs then we must use VPC and the ADI tools... worth a try at least. -- Stephan M. Bernsee http://www.dspdimension.com
Reply by ●December 9, 20042004-12-09
"Jon Harris" <goldentully@hotmail.com> wrote in message news:31pj9lF3ed0f8U1@individual.net...>> > Looks like a real screamer! Wonder what it will cost? I'm still >> > waiting for my "perfect SHARC"--link ports, multiprocessing, built-in >> > SDRAM controller, and 300-400MHz clock speed. I might be able to liveIt already exists, though they stuck the prefix "Tiger" in front of SHARC :-) 300 MHx for TS101 or 600 MHz for TS201, and you get your sdram controller, links, and multiprocessing. No sports though, and maybe that's why you don't like it? ---- Ron Huizen BittWare
Reply by ●December 9, 20042004-12-09
"Ron Huizen" <rhuizen@bittware.com> wrote in message news:10rhdp3ij2bec6d@corp.supernews.com...> > "Jon Harris" <goldentully@hotmail.com> wrote in message > news:31pj9lF3ed0f8U1@individual.net... > >> > Looks like a real screamer! Wonder what it will cost? I'm still > >> > waiting for my "perfect SHARC"--link ports, multiprocessing, built-in > >> > SDRAM controller, and 300-400MHz clock speed. I might be able to live > > It already exists, though they stuck the prefix "Tiger" in front of SHARC > :-) > 300 MHx for TS101 or 600 MHz for TS201, and you get your sdram controller, > links, and multiprocessing. No sports though, and maybe that's why you > don't like it?The problems I have with the TS parts are: 1) High price (>$150 vs <$30 for 21161) 2) The fact that I can't take advantage of the any of the cool features to do multiple lower-precision operations since I always operate on 40-bit FP data. So I pay for features I can't use. 3) It isn't targeted toward the pro audio market (where I work) so there are issues with peripherals, etc. 4) Major architectural differences from the other SHARCs which would probably require a large programming effort to convert our vast library of assembly code to the new platform. (Never really got far enough to see just how much work this would take, but it doesn't look trivial.) The newly announced TS301 looks a lot better in terms of price, but the other issues still remain AFAIK.
