Prev: LPc2478 external Sdram initialization Help Needed
Next: speed of writing file is fixed when changing the CLK of SD/MMC
From: Vladimir Vassilevsky on 5 Feb 2010 16:31


Jon Kirwan wrote:


> For example, Analog Devices printed an excellent book
> on the general topic regarding their ADSP-21xx processors.

> "DIGITAL SIGNAL PROCESSING
> APPLICATIONS: Using the ADSP-2100 Family." The latter one,
> for example, covers a host of fixed point and floating point
> arithmetic operations, function approximations, and so on. In
> enough detail to implement on other processor families. I've
> ported the ideas from time to time, so I know this is quite
> true.

Good book as far as the basic concepts explanation, but terrible as far
as the number of bugs and misprints. You have to verify every formula or
code snippet from there.

> Another excellent reference of another nature is to have is
> one of the incarnations of "Numerical Recipes." If you don't
> have it get that, too.

The code from NR works fine, until you look under the hood: disgustfull
and ignorant style of programming:

#define SWAP(x,y) temp=x; x=y; y=temp

So on...


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
From: Jon Kirwan on 5 Feb 2010 17:02
On Fri, 05 Feb 2010 15:31:17 -0600, Vladimir Vassilevsky
<nospam(a)nowhere.com> wrote:

>Jon Kirwan wrote:
>
>> For example, Analog Devices printed an excellent book
>> on the general topic regarding their ADSP-21xx processors.
>
>> "DIGITAL SIGNAL PROCESSING
>> APPLICATIONS: Using the ADSP-2100 Family." The latter one,
>> for example, covers a host of fixed point and floating point
>> arithmetic operations, function approximations, and so on. In
>> enough detail to implement on other processor families. I've
>> ported the ideas from time to time, so I know this is quite
>> true.
>
>Good book as far as the basic concepts explanation, but terrible as far
>as the number of bugs and misprints. You have to verify every formula or
>code snippet from there.

Well, there is always that. ;) I admit to having used it,
sparingly. In those cases where I have, it has been
accurate.

>> Another excellent reference of another nature is to have is
>> one of the incarnations of "Numerical Recipes." If you don't
>> have it get that, too.
>
>The code from NR works fine, until you look under the hood: disgustfull
>and ignorant style of programming:
>
>#define SWAP(x,y) temp=x; x=y; y=temp
>
>So on...

Yeah. I do NOT use their code. I use it for gaining a
survey on a topic it covers, not for its source code.

Jon
From: Hans-Bernhard Bröker on 5 Feb 2010 17:26
Jon Kirwan wrote:
> On Fri, 05 Feb 2010 15:31:17 -0600, Vladimir Vassilevsky
> <nospam(a)nowhere.com> wrote:

>> The code from NR works fine, until you look under the hood: disgustfull
>> and ignorant style of programming:
>>
>> #define SWAP(x,y) temp=x; x=y; y=temp

>> So on...
>
> Yeah. I do NOT use their code. I use it for gaining a
> survey on a topic it covers, not for its source code.

Yep. The "NR in C" code _must_ be the daftest collection of C code
anyone ever dared to put in print, with the possible exception of H.
Schildt's oeuvre.

Maybe the only responsible way of recommending the NR books is to tell
people to get an edition of it for a programming language they're _not_
going to be using --- and this being c.a.embedded, FORTRAN should fit
that bill nicely ;-)

That way they won't feel tempted to actually use the code, and just
apply the knowledge instead.
From: Jon Kirwan on 5 Feb 2010 17:38
On Fri, 05 Feb 2010 23:26:04 +0100, Hans-Bernhard Br�ker
<HBBroeker(a)t-online.de> wrote:

>Jon Kirwan wrote:
>> On Fri, 05 Feb 2010 15:31:17 -0600, Vladimir Vassilevsky
>> <nospam(a)nowhere.com> wrote:
>
>>> The code from NR works fine, until you look under the hood: disgustfull
>>> and ignorant style of programming:
>>>
>>> #define SWAP(x,y) temp=x; x=y; y=temp
>
>>> So on...
>>
>> Yeah. I do NOT use their code. I use it for gaining a
>> survey on a topic it covers, not for its source code.
>
>Yep. The "NR in C" code _must_ be the daftest collection of C code
>anyone ever dared to put in print, with the possible exception of H.
>Schildt's oeuvre.
>
>Maybe the only responsible way of recommending the NR books is to tell
>people to get an edition of it for a programming language they're _not_
>going to be using --- and this being c.a.embedded, FORTRAN should fit
>that bill nicely ;-)
>
>That way they won't feel tempted to actually use the code, and just
>apply the knowledge instead.

Hehe. Well, the very first edition _was_ in FORTRAN. So I
never did have the problem of deciding whether or not to copy
out the code into a c compiler's input! I did buy the c
version later, so I have two editions on the shelf. One with
a yellow dust jacket and the other with a red dust jacket.
But I don't use them for their source code. :)

Jon
From: Ian Bell on 5 Feb 2010 18:28
Tim Wescott wrote:
> On Fri, 05 Feb 2010 13:31:30 +0000, Tim Watts wrote:
>
>> Hi,
>>
>> I can hack my way around AVRs OK - but I realise my limitations... I
>> normally program in perl on larger computers, so wasting cycles has
>> never been something I've worried about(!). Nor do I normally do timing
>> sensitive stuff where timing < 0.1s
>>
>> Can anyone recommend a good book that would cover things like:
>>
>> 1) Compare-nybble (ie is there a more clever more efficient way than
>> AND- mask and compare-word?)
>>
>> 2) Bitstream input techniques - eg efficient sampling of either a self
>> clocking serial stream or a timing critical one (eg 1-wire) where the
>> timings are so small (10's of uS) that one cannot really afford to waste
>> instructions on a 20MIPS device. Use of interrupts and timers...
>>
>> 3) Cool ways to semi-virtualise a timer - eg ideally you'd like 10
>> hardware timers but you have 2.
>>
>> 4) Bomb proof "boot sector" and live firmware (flash) update tricks.
>>
>> 5) Efficient algorithms for certain maths operations, eg integer square
>> root (as has been mentioned recently, if not here, on a USENET group I'm
>> subscribed to).
>>
>> 6) Keypad debounce.
>>
>> 7) Serial comms (SPI, I2C, 1-wire, RS485, roll-yer-own-with-a-GPIO-pin)
>>
>> 8) Working with an OS, eg FreeRTOS.
>>
>> And lots more in the same vein...
>>
>> Although I'm most likely to use AVRs or maybe PIC24s, the book doesn't
>> have to be that specific - just "how to hack around in 8 bits". Pretty
>> much a "Knuth for uControllers".
>>
>> Many thanks in advance :)
>>
>> Cheers
>>
>> Tim
>
> http://www.ganssle.com/book.htm
>
> I think you want the one on the bottom first.
>
> Then go buy mine, even if you don't need it :-).
>

That's definitely a good one but The Firmware Handbook further up might
be just as relevant.

Cheers

ian
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: LPc2478 external Sdram initialization Help Needed
Next: speed of writing file is fixed when changing the CLK of SD/MMC