> steve wrote:
>
> > Data wrote:
> > > On Dec 20, 9:15 pm, "steve" <bungalow_st...@yahoo.com> wrote:
> > >
> > > > 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
> > >
> > > 10% total inaccuracy doesn't necessarily mean 4 bits of meaningful
> > > data. It will only mean that if the sensor can't be calibrated,
> >
> > hence my comment "out of the box"
>
> Then your comment was very silly. Surely he will calibrate the sensor,
> etc.
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
>
> > > 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.
> >
> > floating point would be great for development, experimenting with
> > various equations, but not needed in the end product
>
> And how do you know that?
cause there is nothing a floating point processor can do that a fixed
point can't.
Perhaps the designer himself is the best
> judge of that.
>
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)
Reply by Data●December 22, 20062006-12-22
steve wrote:
> Data wrote:
> > On Dec 20, 9:15 pm, "steve" <bungalow_st...@yahoo.com> wrote:
> >
> > > 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
> >
> > 10% total inaccuracy doesn't necessarily mean 4 bits of meaningful
> > data. It will only mean that if the sensor can't be calibrated,
>
> hence my comment "out of the box"
Then your comment was very silly. Surely he will calibrate the sensor,
etc.
> > 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.
>
> floating point would be great for development, experimenting with
> various equations, but not needed in the end product
And how do you know that? Perhaps the designer himself is the best
judge of that.
--mpa
Reply by steve●December 22, 20062006-12-22
Data wrote:
> On Dec 20, 9:15 pm, "steve" <bungalow_st...@yahoo.com> wrote:
>
> > 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
>
> 10% total inaccuracy doesn't necessarily mean 4 bits of meaningful
> data. It will only mean that if the sensor can't be calibrated,
hence my comment "out of the box"
> 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.
floating point would be great for development, experimenting with
various equations, but not needed in the end product
>
> --mpa
Reply by Data●December 22, 20062006-12-22
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
Reply by Data●December 22, 20062006-12-22
On Dec 20, 9:15 pm, "steve" <bungalow_st...@yahoo.com> wrote:
> 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
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
Reply by ●December 21, 20062006-12-21
Mike Noone <nleahcim@gmail.com> wrote:
> Ken Asbury wrote:
>> The Hitachi (now Renasis) SH-3 had what I consider to be a pretty
>> decent free development environment called HEW which covered
>> their entire SH and H8 line. The programming interfaces for both
>> were well documented. I used it in a Windows environment but I
>> understand that it also operated in the Linux environment.
> "had"? So do you mean they no longer have free dev software for their
> parts?
You can get the Renesas HEW IDE for free bundled with a GNU toolchain
from KPIT Cummins Infosystems Ltd., <http://www.kpitgnutools.com/>. 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
Reply by Ken Asbury●December 21, 20062006-12-21
Mike Noone wrote:
> Ken Asbury wrote:
> > The Hitachi (now Renasis) SH-3 had what I consider to be a pretty
> > decent free development environment called HEW which covered
> > their entire SH and H8 line. The programming interfaces for both
> > were well documented. I used it in a Windows environment but I
> > understand that it also operated in the Linux environment.
>
> "had"? So do you mean they no longer have free dev software for their
> parts?
>
> > As an alternative, if you have Microsoft's Visual Studio environment,
> > the Intel 80X86 MMX instruction set makes and excellent DSP
> > learning tool free on your PC.
>
> I'm not looking for a learning tool though. I would need actual
> hardware for this stuff to run on.
>
> -Mike
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
Reply by David M. Palmer●December 21, 20062006-12-21
In article <1166634518.825042.94640@48g2000cwx.googlegroups.com>, Mike
Noone <nleahcim@gmail.com> wrote:
> Jonathan Kirwan wrote:
> > On 19 Dec 2006 21:53:45 -0800, "Mike Noone" <nleahcim@gmail.com>
> > wrote:
> >
> > >Hi - I'm looking at doing some DSP work (specifically, I'm working on
> > >an AHARS system).
> >
> > Airborne Heading-Attitude Reference System?
> >
>
> Exactly. My plan is to have 3 axes of magnetometer, 3 axes of gyro, 3
> axes of accelerometer, and a gps. The gyro and accelerometer will be
> sampled at probably 2KHz. GPS will be coming in at 4Hz, not sure about
> magnetometer (haven't chosen what kind to use just yet). I'll be mixing
> the gyro and accelerometer data with a kalman filter. GPS and
> magnetometer will be used to further fix the gyro and accelerometer
> data.
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.
>
> > I've been using the ADSP-21xx series DSP processors for 15 years and
> > more. There was an older assembler, linker and so on that you may be
> > able to get for free from Analog Devices support folks.
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)
Reply by steve●December 21, 20062006-12-21
Mike Noone wrote:
> Jonathan Kirwan wrote:
> > On 19 Dec 2006 21:53:45 -0800, "Mike Noone" <nleahcim@gmail.com>
> > wrote:
> >
> > >Hi - I'm looking at doing some DSP work (specifically, I'm working on
> > >an AHARS system).
> >
> > Airborne Heading-Attitude Reference System?
> >
>
> Exactly. My plan is to have 3 axes of magnetometer, 3 axes of gyro, 3
> axes of accelerometer, and a gps. The gyro and accelerometer will be
> sampled at probably 2KHz. GPS will be coming in at 4Hz, not sure about
> magnetometer (haven't chosen what kind to use just yet). I'll be mixing
> the gyro and accelerometer data with a kalman filter. GPS and
> magnetometer will be used to further fix the gyro and accelerometer
> data.
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