From: Dave C. <gu...@mo...> - 2007-04-25 18:46:23
|
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 |
From: Ryan R. <rjr...@uc...> - 2007-04-25 23:44:11
|
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 |
From: Dave C. <gu...@mo...> - 2007-04-26 15:07:48
|
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 |
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 |
From: Craig H. <cr...@gu...> - 2007-05-01 00:59:34
|
Rather than a DSP, you might consider looking at an FPGA; integrating an FPGA to the gumstix should be pretty easy, and if you pick the right family of FPGAs, I think you can even get free development tools for them from the manufacturers. C On Apr 30, 2007, at 10:51 AM, Ryan Rapetti wrote: > 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 > > > ---------------------------------------------------------------------- > --- > 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 |
From: MadAlexGumstix <Gum...@ma...> - 2007-05-01 01:39:07
|
I second the motion on FPGAs as an ideal addition to the gumstix for hi- performance processing and I/O, especially for something like frame-rate video processing. For really-high-performance DSP, there are a number of folks out there who are now employing high-end FPGAs with built-in, dedicated DSP sections for image- processing solutions: <http://www.altera.com/products/devices/cyclone3/overview/architecture/cy3-architecture.html> <http://www.xilinx.com/products/silicon_solutions/fpgas/spartan_series/spartan3adsp_fpgas/index.htm> Of particular interest for gumstix-based applications are FPGAs that use anti-fuse or built-in flash technology for configuration memory, allowing dramatically lower-power solutions, in extremely small packages (but with lower performance than the devices above): <http://www.actel.com/> Igloo (Flash) and Axcelerator (Anti-Fuse) <http://www.quicklogic.com/> PolarPro and Eclipse II (Anti-Fuse) If you want to start with a FPGA-on-a-DIP solution, see somebody like <http://www.hydraxc.com/>. FYI, FPGA intellectual property (IP) is available from the FPGA OEMs (often free for eval or for simple functions), 3rd-party IP vendors, and from open-source sites like OpenCores <http://www.OpenCores.org/>. I will say, however (no direspect to the gumstix), that if you need a solution with general-purpose processing, flexible I/O, power efficiency, DSP, and Linux support, the Analog Devices Blackfin family is pretty nice as an alternative to a PXA-based processor: <http://www.analog.com/blackfin> <http://blackfin.uclinux.org/> <http://blackfin.uclinux.org/gf/project/stamp> -- Alex On Mon, 30 Apr 2007 17:59:28 -0700, "Craig Hughes" <cr...@gu...> said: > Rather than a DSP, you might consider looking at an FPGA; integrating > an FPGA to the gumstix should be pretty easy, and if you pick the > right family of FPGAs, I think you can even get free development tools > for them from the manufacturers. > > On Apr 30, 2007, at 10:51 AM, Ryan Rapetti wrote: > > > 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... |
From: Ryan R. <rjr...@uc...> - 2007-05-01 17:12:27
|
FPGAs are definitely cool. I have a friend at Lockheed who is working with them for high speed automatic control. I just don't know a whole lot about using them, whereas I know a fair bit about DSPs. The Blackfin is a great platform, and gcc will compile code for it, though how optimized it is I don't know. I haven't investigated the I/O as much as I have the TigerSHARC, but I imagine it's similar and a shared memory interface is workable. Like I said before, do some benchmarks before you invest thousands in hardware and software. Ryan On Mon, 2007-04-30 at 21:38 -0400, MadAlexGumstix wrote: > I second the motion on FPGAs as an ideal addition to the gumstix for hi- > performance processing and I/O, especially for something like frame-rate > video processing. For really-high-performance DSP, there are a number of > folks out there who are now employing high-end FPGAs with built-in, > dedicated DSP sections for image- processing solutions: > > <http://www.altera.com/products/devices/cyclone3/overview/architecture/cy3-architecture.html> > > <http://www.xilinx.com/products/silicon_solutions/fpgas/spartan_series/spartan3adsp_fpgas/index.htm> > > Of particular interest for gumstix-based applications are FPGAs that use > anti-fuse or built-in flash technology for configuration memory, > allowing dramatically lower-power solutions, in extremely small packages > (but with lower performance than the devices above): > > <http://www.actel.com/> Igloo (Flash) and Axcelerator (Anti-Fuse) > > <http://www.quicklogic.com/> PolarPro and Eclipse II (Anti-Fuse) > > If you want to start with a FPGA-on-a-DIP solution, see somebody like > <http://www.hydraxc.com/>. > > FYI, FPGA intellectual property (IP) is available from the FPGA OEMs > (often free for eval or for simple functions), 3rd-party IP vendors, and > from open-source sites like OpenCores <http://www.OpenCores.org/>. > > > I will say, however (no direspect to the gumstix), that if you need a > solution with general-purpose processing, flexible I/O, power > efficiency, DSP, and Linux support, the Analog Devices Blackfin family > is pretty nice as an alternative to a PXA-based processor: > > <http://www.analog.com/blackfin> > > <http://blackfin.uclinux.org/> > > <http://blackfin.uclinux.org/gf/project/stamp> > > -- > Alex > > On Mon, 30 Apr 2007 17:59:28 -0700, "Craig Hughes" > <cr...@gu...> said: > > Rather than a DSP, you might consider looking at an FPGA; integrating > > an FPGA to the gumstix should be pretty easy, and if you pick the > > right family of FPGAs, I think you can even get free development tools > > for them from the manufacturers. > > > > On Apr 30, 2007, at 10:51 AM, Ryan Rapetti wrote: > > > > > 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... > > ------------------------------------------------------------------------- > 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 |