dspic info ??? anywhere ???

[2dye4]

I want to learn to code my own DSP structures into the DSpic processor series. But many companies including MicroChip themselves want to sell you 'software' to create the code. This i do not want nor do i need if i could only get some details on the DSP core. I am hoping to find a shortcut to reading all the data sheets and app notes that cover this chip. Mainly just a assembly listing of a FIR filter would be a good start.
Does anybody know of a source of info on coding that is not trying to sell a 'aid' or 'crutch' depending how you view these things??

Thanks

 

[Noway2]

DSP can be divided into two disciplines: mathematics and implementation. The two are intertwined in that if you don't have a solid handle on the mathematics, you won't be able to effectively implement even the simplest of FIR filters.

An absolutely solid, excellent text for a beginner in DSP is the book by Richard Lyons, Understanding Digital Signal Processing. I would (and many others have) HIGHLY recommend this book. It will help you both in understanding the DSP math, but in a way that you will start to "intuit" it and if you have some basic programming skill will be able to start coding some basic algorithms.

As far as assembly listing, most of the vendor's websites should have some sample, example libraries you can download and work from. I know that TI does and I imagine that Microchip does also. If you want to code down at the assembly level, this will be a good place to start, as would the assembly language instruction reference. Each processor is going to have a unique set of opcodes and address modes geared towards DSP function. You will need to learn those.

Lastly, from personal experience, I recommend that you develop you basic (dsPIC) algorithm. Code it in C, C++, an excel sheet, or any other "high level" system or language that will let you verify that the algorithm works. Then, take it step, by step, reducing the language level, testing as you go. It is entirely possible that things are working perfectly and you get garbage results. Unfortunately, there are a also a ridiculous number of ways in which you can screw something up, and you get the same exact results. Proceeding this way will help prevent that.

 

[MacGyverS2000]

Googling "Microchip FIR filter" comes up with plenty of hits for code...

Dan - Owner

http://www.Hi-TecDesigns.com

 

[2dye4]

Mac

I searched "Microchip FIR filter" and went through the first two pages of results and nothing gave coding examples of DSP implemented on the DSpic.

Also spent another hour looking under "DSpic FIR filter" with not useful results.

It seems most people want to use Microchips libraries.

 

[Noway2]

You didn't search in the right place. Try this, It is from the application notes section, not from a keyword search:

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en012035

It has both IIR and FIR filter examples, as well as an xls sheet that shows the co-efficient generation.

 

[MacGyverS2000]

Looking at IIR/FIR code for a generic PIC and transforming it slightly to work for a DSPIC should be extremely simplistic (you're not even changing vendors!)... if you cannot handle such a task, I think the project as a whole is going to too challenging. FIRs are possibly the easiest filter to implement in any architecture next to a running average.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[BobM3]

I get the feeling you're more interested in what bytes go where in the chip for your program to be able to run. And you want to do this without buying a programmer or software. Is this what you're after?

 

[2dye4]

Noway2 close but only for the pic18 series.

The DSpic is a different animal. To implement FIR filter you use the MAC instruction.

However there is MUCH more under the hood than this. It is 10X more difficult to digest than regular PIC operations. You can find the info in the DSpic Programmers reference.

http://www.google.com/url?sa=t&sour...0uXrCA&usg=AFQjCNFxFHF9x7aCakKpr_lUxE8Ol3lvqg

The coefficients for the filter and the 'generic' algorithm are not issues, simple with the right software.

http://www.gnu.org/software/octave/

Seems like there should be an assy listing out there for DSpic instructions to implement a filter.

Thanks for your efforts.

 

[MacGyverS2000]

MACs are nothing more than two operations in the same "cycle"... instead of multiply an incoming value with a coefficient in one cycle followed by adding that number to the output in the second cycle, it does it in one shot. Nothing esoteric about it, just consider it a shorthand notation for what's happening inside the filter.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[Noway2]

Out of curiosity, is there any particular reason you chose a dsPIC and are you constrained to it? I ask because the DSP portion of a PIC strikes me as a kludge where a math engine has been glued to a standard PIC core. This creates a very much non-ideal starter platform where various modes, dealing with the X and Y bus and such, are required to access it. A much better choice would be an Analog Devices processor, which has about the cleanest assembly <--> DSP interface I have seen. TI is an ok choice, but you will suffer from overload on the sheer number of instructions and addressing modes.

I am also questioning, exactly what you are trying to do or accomplish. I don't mean to offend, I am truly curious. You seem awfully focused on an assembly listing for this one platform. In your original post you said that you want to learn to code your DSP structures, which is great, but you seem to have an awfully narrow focus regarding how to go about it.

If you really want an assembly listing for this processor, another way to get at it would be to use a compiler, write your algorithm in C and see how the compiler does it.

 

[2dye4]

Noway2

I chose the pic because of cheap development tools and also for DIP packaged parts to prototype with. And yes the architecture does strike me as overly complicated.

I have no specific thing in mind yet but until one can code an efficient routine to implement basic DSP operations (mostly MAC) you haven't any tools in your box and don't really know what is possible.

I found some more info in the DSpic family reference guide. To utilize the chip you need to be able to do at least three things.

Perform the MAC operations
Shift the input data (or pointer) each evaluation
Implement the hardware do loops.

I have little money for tools ( $500.00 ) and i like inexpensive chips $(3-8) that are easy to prototype with.

It seems MCHP would like most people to just use their libraries and avoid the details. It's not my style.

 

[Noway2]

If you haven't fully committed to Mchip yet, take a look at the following:

http://www.analog.com/en/embedded-processing-dsp/adsp-21xx/218x-HARDWARE/products/product.html

There may be other (less expensive) boards,b but this one comes in at $300 from ADI direct.

Based on your goal of wanting to learn about DSP architecture, ADI would be one of your best choices as far as a language and architecture that is as close to "pure" as your going to get.

 

[MacGyverS2000]

As far as the classic big three (Motorola, Analog Devices, Texas Instruments) go, in increasing order of programming difficulty (and increasing order of power):
ADI
Moto
TI

Haven't used any of MCs DSPs, but I imagine they're significantly easier to set up external hardware-wise compared to the dedicated DSPs (DMA lines, external memory, etc.). The tools have changed significantly over the years, too. TI has significantly reduced their Code Composer tool line costs, with you being able to choose certain single families for $500 (used to be $3k regardless). I believe the visual designer tools from Moto are free. I remember even the professional tools from ADI being half-assed, but that may have changed in the 10 years since I used them.

Either way, they all have very inexpensive eval boards ($100) and a load of free tech info.

There used to exist books that taught fundamental DSP routines with a practical side (filtering, audio equalizers, etc.) and included assembly code for specific processor family (usually TI chips, though Moto and ADI could be found if you looked hard enough), but I wouldn't know how to track them down these days as bookstores now only carry "light" reading on technical subjects... anything truly technical has to be ordered. I'm sure some proper Googling will turn some up.


Dan - Owner

http://www.Hi-TecDesigns.com

 

[Noway2]

I like how you put, "in increasing order of programming difficulty" with TI being last .

I started assembly language programming as a pre-teen on a C-64, professionally worked on and developed decent sized commercial applications written in it, have worked with more than half a dozen (processor) versions of it AND ... TI's DSP assembly STILL about made me choke.

The last time I tried it, I needed to implement an optimized IIR filter function for a DF2-Transposed algorithm and used their filter library as the example. I think if I got the error message about some instruction not working with the one particular, of the 100+ addressing modes that I needed to use, one more time I was going to shoot myself to ease the pain.

 

[MacGyverS2000]

TI DSPs are extremely powerful (MIPS) due to their VLIW architecture, but to get that power out of the chip, you need a heavily foldable algorithm and the ability to fold it by hand... compiler pragmas only get you so far (despite what TI leads newbies to believe). Still, I've made those chips do things many previously thought impossible. It's a huge puzzle getting 8 instructions to operate in a single cycle and do so over multiple cycles in a tight loop... I love puzzles.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[IRstuff]

And, while they are indeed powerful, their I/O often sucks. We once purchased a quad-C67 board to run some image processing, only to find that a quad-PPC had more I/O, enough to run at twice the throughput that the QC67 could attain.

TTFN

FAQ731-376

 

[MacGyverS2000]

I assume by quad-C67 board you mean someone put four chips on a board... which means your problem should be with the board designer/manufacturer, not TI's chip. MHz for MHz, the TI chip is significantly more powerful (MIPS) than the PPC, again, due to the VLIW architecture. It sounds like your problem was a lack of proper architecture outside of the chip, and you can hardly blame that on the chip itself. If the board was designed with the problem in mind and the firmware was properly partitioned, it would be able to blow away a similarly-clocked GP processor. And comparing a 600MHz DSP to a 2.3GHz GP CPU starts to push apples to oranges comparisons, don't you think?

Dan - Owner

http://www.Hi-TecDesigns.com

 

[IRstuff]

Same designer did both boards, though...

The issue is that TI's throughput was based on large amounts of crunching on small amounts of data, ala classic DSP. However, if you're doing small amounts of crunching on large amounts of data, ala image processing, you'd see a big difference.

The QPPC board was running a 350 MHz system clock, while the QC67 was running 400?? (more than 10 yrs have past, so...)

As it turns out, the PPCs were equipped with Altivec coprocessors, so it might have been much closer fight, but we didn't get around to trying the Altivec until much later, when it turned out that we needed even more throughput.

TTFN

FAQ731-376

 

[MacGyverS2000]

With the image processing stuff (you're definitely in my field now ), cache is the word to live by. If you can get the algorithm to work with the same data stored in cache (be it L1 or L2) to completion, that's the best you can hope to accomplish... JPEG is a major example of this type of algorithm. JPEG2000/wavelets, on the other hand, throw this right out of the window... been there, done that.

Years ago I was tasked with implementing a JPEG2000 codec on a parallel processor architected for JPEG-style algorithms. Looking at the dismal pixel throughput, the client initially thought I didn't understand the architecture and therefore was not fully utilizing it. Over the course of an hour or so I explained the fundamental differences between the two algorithms, and it became clear 80% of the hardware was going unused 75% of the time simply because there was no way to use it more efficiently. The algorithm/architecture combination didn't allow for it. The DCTs of JPEG presented uniform (but not necessarily small) blocks of uniformly square data that could be operated on. JPEG2000, on the other hand, presented non-square, arbitrarily-sized chunks of data that needed to "rotated" (compared to the filters) between each processing step... most architectures just don't like to do that without a huge fight.

If your algorithm requires a high bandwidth compared to the actual processing, a GP CPU is often better suited as the peripheral space (DMA and the like) is typically set up to be more efficient at this task.

These days, the line has become so blurred between the two you (usually) have to make comparisons between two specific processors before it's valid. I do miss the days of "Need number-crunching? Slap a DSP on there!", no questions asked.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[IRstuff]

Well, that project became our poster-child for abysmal failures, but not for that specific reason.

The throughput problem was grossly overshadowed by the fact that our implementor was a chemist, turned into an algorithm guy, and really had no clue, and did care, about prior, working, designs. Not necessarily an NIH problem, but more that it's no fun to reverse engineer someone else's stuff.

TTFN

FAQ731-376