From: Ryan R. <rjr...@uc...> - 2007-04-30 17:51:08
|
I think the DSP idea may be your best bet. I don't know enough about the software architecture to give a whole lot of direction here, but it should be possible to abstract out all the heavy duty computation to the DSP and go from there. The major downside of DSP is the development cost. The devel environments are very complex and hence expensive. GCC won't do the job, so you'll have to get Analog's software. The upside is that this setup works very, very, well. Analog has a text that they put out on fundamentals of DSP and signal/image processing in general that I found very helpful. Personally, I wouldn't count out the gumstix as a processing tool. It may work ok. You can write up the code and have gcc compile it for x86 without floating point and then dig up an old 600MHz linux box, boot it to console and do some benchmarks. It won't be perfect but it should ballpark things. I'd get a better idea of the actual processing needs before I invested in a bunch of TigerSHARCs and 5 or 10K in software. Good luck- Ryan On Thu, 2007-04-26 at 11:07 -0400, Dave Cubanski wrote: > Ryan-- > > Thanks for the overview and background info... > > As for the application - it is an image processing application. I'm > going to be identifying and measuring a large number of features in > video imagery at 20-30 frames per second, and I'd much prefer to have > hardware floating point support for the (very complicated) underlying > mathematics. My gut feeling (though incompletely informed) is that > software emulated floating point in this case is going to be much too > slow. I could switch everything to integer math, I suppose, but at > this point I really don't want to do the work of analyzing all of the > scaling of values to prevent overflows or imprecisions, etc. I've > read (via this mailing list) that the PXA270 has some support for > 64-bit integer operations; this might be a useful alternative, but at > this point I don't know what support there might be for that in gcc/g++. > > My thinking at this point is that a DSP chip like a SHARC is probably > the best choice here; in the end I'm probably going to need to build a > 120-pin expansion card for the Verdex, that has a DSP chip on it to > crunch the signal processing math. I kind of need to have the Verdex > / Linux as part of the system to have prebuilt access to networking, > storage, communications, etc; I had hoped to avoid the software > complexity of two separate processors; it would have been nice if the > Verdex could somehow do everything. I've seen reference to an arm-gcc > -nofpu option, which somehow gave me hope that there might be an easy > way to add a memory-mapped FPU; maybe not with PXA270, though... > > Thanks-- > > --Dave > > At 07:44 PM 4/25/2007, you wrote: > >There are a couple of issues here. The big one is how the FPU attaches > >to the PXA. Some older Motorola (and Intel x86) have a dedicated FPU > >interface, so you just get an extra set of registers or instructions > >that will do floating point. So all you do is tell the compiler to use > >FP instructions and away you go. I don't know of a switch like this for > >the ARM, so I'm not optimistic about this type of interface. The verdex > >does have a shared memory interface, so if you bought some type of FPU > >you could wire to that interface and then you'd have a bunch of memory > >locations that would do FP math for you, but it would not be transparent > >in your code unless you rewrote the SoftFloat libs. Timing would also be > >an issue since the Verdex might well be able to check the output > >registers before the math was done. You'd have to write FPMult(), etc > >funcs that did all the memory shuffling and had a delay loop to make > >sure the math is done before returning a value. Overall a highly complex > >operation. Out of curiosity, what is your application? You may want to > >look at more sophisticated systems if you need more power. > > > >Ryan > > > >On Wed, 2007-04-25 at 14:46 -0400, Dave Cubanski wrote: > >> Does anybody know what it would take to connect some type of hardware > >> floating point coprocessor to the PXA270 in a Verdex, via the 120 pin > >> connector? I'm prototyping an application that ultimately I'm going > >> to want to port to a Verdex, and in the end I'm going to want to be > >> doing a lot of very fast floating point math, and so I'm wondering at > >> this point if some type of accelerated hardware FPU is going to be a > >> reasonable option in the future. > >> > >> I can easily fab an expansion board to interface an FPU if necessary. > >> My questions are more along the lines of: > >> > >> 1) Is there a series of FPU chips commonly used for this purpose > >> within the PXA family? I've tried looking through the available > >> PXA270 literature posted via the Gumstix support wiki, but so far I > >> haven't turned up any references to FPUs. > >> > >> 2) I assume such a chip would possibly need some type of driver to > >> configure it, and for sure a compiler capable of knowing how to > >> generate object code to make efficient use of it. I know very little > >> about the nuts and bolts of how something like this is supposed to > >> work in practice, however, so if somebody could point me to the right > >> sources for this kind of overview information, I'd appreciate that a > >> lot. > >> > >> Thanks-- > >> > >> --Dave > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |