DSP parts with free dev software/cheap dev tools?

ADSP-

KIT

Visual DSP is the Analog Devices development tool. There are three licenses available.

1. Full Version. You buy this once and then upgrades are free.
2. Test Drive, same as full license for 90 days, then stops working
3. Kit License - sames as full license for 90 days, then restricts program size to about 1/4 of the DSP memory. Does not support simulator or external ICE. Requires EZ-KIT style debugger which is available on ADI EZ-KITs and some of our dspstak 21369 boards. - Free. You can create bootable images that can be loaded on our production boards or another target.

--
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

Ah. I have two full version licenses, so no need in my case. But I'm interested in details for others, who may be curious and wish to play as a hobbyist.

Thanks, Jon

You have not mentioned the precisions or calculation rates you need, but one suggestion would be to take a std 32 bit C microcontroller, and code using that. We recently did a fixed point scaled problem, using the Zilog ZNEO. This has MUL/DIV opcodes with extended precision (32*32 -> 64, and

64/32 -> 32), and it also has a free compiler, and simulator. IIRC we did a 64 bit ratio and ten 32 bit divides/stores in appx 19us, using assembler (because what we needed was more easily done in assembler).

It has 32 bit registers, and IIRC, the C has 32 bit float type, so would be a free 'reference point' - just grab the ZDS II from Zilog's web site.

If that's not enough for your final app, another possible pathway, would be to use the Lattice Mico32 Soft CPU, with HW assist as needed.

-jg

if you are using the gyro/accelerometers I think you are using they have about 10% accuracy specs out of the box, so that is less then 4 bits of meaningful data, floating point math would be overkill, 16 bit math would even be overkill, the ARM would be overkill, you don't need a floating point DSP, use what you know, the ARM

If you're going to do that much, may I suggest that you also continuously pipe the data into a flash memory, such as an SD card, embedded in a few cubic inches of steel. (If you just cycle continuously at a few kB per minute or so, you won't run into lifetime issues.) This will give you a black box flight recorder functionality for a very small increment in price and other resources.

It may break in some accidents that the real FCC-approved version would survive, and won't be a cockpit-voice-recorder, but providing some flight data for merely most crashes would be better than no data at all.

There's a gcc toolchain (free software license, of course) for the ADSP-21xx, which was what they used to ship. There's also their more expensive toolchain that gives much better code, and may be worth it.

But at 2 kHz input rate, you hardly need a high performance DSP for your processing.

--
David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)

Mike,

By 'had" I meant that I have not had any experience with their products since 2003 (before the merger) and did not wish to speak assertively about that for which I have no current knowledge.

I presumed that, if curious, you would Google for "hew hitachi" or suchlike, where you would learn that I mis-spelled Renesas, and, demonstrating the initiative and ingenuity for which engineers are often noted, would then retry Google with 'hew renesas' to determined that HEW is now available in a time-limited version at:

www2.eu.renesas.com/products/mpumcu/tool/hew/support.html

I'd dig up pricing and availability for the chip, license and development boards for you but, if you can spell 'Arrow' or 'Avnet', their FAEs can probably save us both time.

So, now that I've had my grump for the day I can go back to being my usual sweet charming self.

Regards, Ken

You can get the Renesas HEW IDE for free bundled with a GNU toolchain from KPIT Cummins Infosystems Ltd., . You do have to register, but at least I haven't received anything except update notices from them.

Renesas' own toolchains are to the best of my knowledge not available for free.

-a

10% total inaccuracy doesn't necessarily mean 4 bits of meaningful data. It will only mean that if the sensor can't be calibrated, has wildly nonlinear output, and random response to temperature. I doubt any of those things are true.

Even if they were, floating-point could still be useful -- it accounts for roundoff error and overflow. It's not best for everything, but the choice has much more to do with the computation problem than the sensor.

--mpa

The original poster hasn't said anything, but I thought I'd jump in, because I'm interested too.

So far, everybody's posted about free / cheap compilers, demo boards, etc. The missing element is the *programmer*.

For example, I designed a small sub-US$100 board, which you can easily order now, and which makes a fairly nice DSP development kit ..

.. except for one thing: you need a US$1200 programmer to debug with it, and a license for a certain proprietary compiler to compile code for it at all. (It's not sold as a development board, so no questions please. :) ) If the programmer weren't $1200.00, it would be a much better proposition, but the development system and software are prohibitive.

I think the answer may turn out to be ARM -- not because the chip is fastest, but because the programming hardware is plentiful and cheap, and the compiler is free. It seems that DSPs are still Big Iron.

--mpa

hence my comment "out of the box"

floating point would be great for development, experimenting with various equations, but not needed in the end product

Then your comment was very silly. Surely he will calibrate the sensor, etc.

And how do you know that? Perhaps the designer himself is the best judge of that.

--mpa

ok, maybe I am silly for assuming a student looking for a free DSP toolset doesn't have access to a $100K+ temperature controlled multi axis rate/vib table

cause there is nothing a floating point processor can do that a fixed point can't.

Perhaps the designer himself is the best

yes I agree, he can use either a fixed point for floating point processor, I didn't say he had to use either, just that floating point was not needed, that he didn't need to restrict himself, it's up to him weight the various tradeoffs of each (learning a new toolset/processor vs dealing with the headaches of fixed point math)

With adsp there is a gcc port for the blackfin family see blackfin.org

There is a cheap robotics board on the way - blackfin handy board

as well as the blackfin stamp boards.

BF533 stamp is no longer made but the BF537 can be purchased from digikey.com

search for BF537 stamp at digikey - US$226

For TI if you are at a uni, you may be able to get the tools for free via the university program or buy some hardware and get the free matching tools offer (probably have to spend at least US$400 min).

Alex Gibson