On Tue, 14 Mar 2017 22:55:01 +0000, eric.jacobsen wrote:> On Tue, 14 Mar 2017 15:59:20 -0500, Tim Wescott > <seemywebsite@myfooter.really> wrote: > >>On Tue, 14 Mar 2017 17:33:29 +0000, eric.jacobsen wrote: >> >>> On Tue, 14 Mar 2017 11:08:42 -0400, Eric <Eric@spamspamorspam.com> >>> wrote: >>> >>>>Just curious about how much Linux is being used for embedded DSP apps. >>>>If you're using it, what are your normal development tools? >>> >>> Lately I've done a number of projects similar to what Tim described, >>> using ARM Cortex cores running some flavor of Linux or other. >>> Generally they're good enough that an executable ports easily across >>> the different common flavors of Linux, so it doesn't matter too much >>> which one you're developing under. >>> >>> Unlike what Tim described, though, I do the development on Windows, >>> using Eclipse for the IDE and cross-compiling. Eclipse has some very >>> good remote-development tools, so doing the development and compiling >>> on Windows and then running the executable and debug on the ARM >>> platform is actually pretty easy. >>> >>> I had a client that also wanted the same process that was running on >>> ARM cores to also run on x86/IA32/IA64. Although it was a simple >>> port, it did make me set up a native Linux tool flow on the other >>> platforms since it isn't as easy to cross-compile from Windows onto >>> those platforms with the libraries I was using. >>> >>> And, yes, the apps I'm talking about are DSP apps, they're just >>> running on ARM cores or whatever. These days a lot of processors are >>> good enough that they're fine for the task. >> >>I'm developing on Linux by preference, and the processors I'm developing >>for are deeply embedded using ARM Cortex M<whatever> cores running >>little RTOS kernels or no OS at all. It sounds like you may be >>developing for ARM Cortex A<whatever> cores that are actually >>_executing_ Linux. > > Yes, A8s or better or whatever. I think having a clock speed >1GHz > does help the situation somewhat. ;)Depending on what your requirements are. The best quote I've heard to date on real-time development is "Real Fast does not mean Real Time". -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Anyone using Linux?
Started by ●March 14, 2017
Reply by ●March 14, 20172017-03-14
Reply by ●March 14, 20172017-03-14
On Tue, 14 Mar 2017 18:08:19 -0500, Tim Wescott <seemywebsite@myfooter.really> wrote:>On Tue, 14 Mar 2017 23:01:30 +0000, eric.jacobsen wrote: > >> On Tue, 14 Mar 2017 22:42:23 +0000 (UTC), spope33@speedymail.org (Steve >> Pope) wrote: >> >>>Tim Wescott <seemywebsite@myfooter.really> wrote: >>> >>>>On Tue, 14 Mar 2017 22:28:42 +0000, Steve Pope wrote: >>> >>>>> Something about running an ARM with "no OS" is freaky. >>> >>>>The LPC811M001 from NXP has 8K of flash and 2K of RAM (and 16 pins). >>>>You could shoe-horn an RTOS in there, but it would take up significant >>>>space. >>>> >>>>Less than $0.58 each if you buy 1000 of 'em from Digikey. $1.26 in >>>>onesies. >>> >>>Thanks -- that sounds like a pretty neat product. I'll have to check >>>out the datasheet. >>> >>>I've been on two significantly sized "no OS" projects, one used an 8051 >>>and the other a 68020. One of the two had sufficient programming >>>discipline that "no OS" worked out well, but I still in retrospect >>>wished that I had written a synchronization kernel. It was mostly the >>>interplay between timer interrupts and other types of interrupts that >>>led to trickiness. >>> >>>Steve >> >> For "embedded"-ish stuff, up until a few years ago the vast majority of >> my experience was on "bare metal" (I.e., no OS) projects. I've always >> found them much simpler, but for cases where they made sense, i.e., the >> processor really only did one thing, and had to do it fast. Even larger >> projects where we had to populate a micro or two for Monitor and Control >> purposes, they were always bare metal (no OS). That's not difficult with >> smaller processors, and it makes many aspects of debug easier. >> >> So I always resisted working with an embedded or real-time OS because >> they always seemed to just be in the way. The extreme other end of >> that is working on a platform with a full OS (Linux) with networking >> support, etc., which makes connecting for development and debug easy and >> opens up a whole crazy world of additional support. >> >> I think anything in between is a little sketchy, but the amount of CPU >> and OS power on the cheapie platforms does make them attractive for >> cases where they're enough oomph to do a job. > >I find that when you have things on a processor that are working at >vastly different time scales -- e.g., a human interface that needs to >respond within 50ms, and a control loop that needs to respond in 100us -- >then an RTOS is a huge help. > >They're also good when you have more than one person touching the >software, because you can let the lower-ranked software engineers loose >on the less time-critical parts of the code base with a lower likelihood >that they'll do something that'll prevent the fast stuff from doing its >job on time. > >(Lower, but not zero -- if they can turn off interrupts, they can screw >things up royally, and I've seen it done and the results blamed on me!)Yup, I don't disagree with any of that. I think maybe I've been fortunate to have nearly always been on competent teams where you didn't have to worry too much about somebody screwing something up enough to affect performance. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Reply by ●March 14, 20172017-03-14
Tim Wescott wrote:> On Tue, 14 Mar 2017 14:11:01 -0400, rickman wrote: > >> On 3/14/2017 2:00 PM, gyansorova@gmail.com wrote: >>> On Wednesday, March 15, 2017 at 6:33:30 AM UTC+13, eric.j...@ieee.org >>> wrote: >>>> On Tue, 14 Mar 2017 11:08:42 -0400, Eric <Eric@spamspamorspam.com> >>>> wrote: >>>> >>>>> Just curious about how much Linux is being used for embedded DSP >>>>> apps. >>>>> If you're using it, what are your normal development tools? >>>> >>>> Lately I've done a number of projects similar to what Tim described, >>>> using ARM Cortex cores running some flavor of Linux or other. >>>> Generally they're good enough that an executable ports easily across >>>> the different common flavors of Linux, so it doesn't matter too much >>>> which one you're developing under. >>>> >>>> Unlike what Tim described, though, I do the development on Windows, >>>> using Eclipse for the IDE and cross-compiling. Eclipse has some very >>>> good remote-development tools, so doing the development and compiling >>>> on Windows and then running the executable and debug on the ARM >>>> platform is actually pretty easy. >>>> >>>> I had a client that also wanted the same process that was running on >>>> ARM cores to also run on x86/IA32/IA64. Although it was a simple >>>> port, it did make me set up a native Linux tool flow on the other >>>> platforms since it isn't as easy to cross-compile from Windows onto >>>> those platforms with the libraries I was using. >>>> >>>> And, yes, the apps I'm talking about are DSP apps, they're just >>>> running on ARM cores or whatever. These days a lot of processors are >>>> good enough that they're fine for the task. >>>> >>>> >>>> >>>> --- >>>> This email has been checked for viruses by Avast antivirus software. >>>> https://www.avast.com/antivirus >>> >>> I take it that Raspberry Pies and the like have ordinary Linux OSs so >>> are not suitable for DSP style work. Correct? >> >> I think you are confusing "DSP" work for real time work. Not all DSP is >> hard real time. >> >> You can run any OS on the Raspsberry Pi that you wish. > > And, the most recent information I've seen is that mainstream Linux is > good enough for some realtime applications, thanks to the work of various > real-time Linux projects being folded back into mainstream Linux. > > For really super-prompt realtime work one still needs a dedicated > processor, but I couldn't tell you what the dividing line is. >I've gotten a bog-standard Windows machine down to 1-2 msec at whatever jitter that worked out to. That's with no custom hardware. My basic guess is that if you spend to time to remove packages from a RasPi, it'll do a pretty good 1 msec as well. By "1 msec" I don't mean full response time - but capturing events such that 1 msec means very low likelihoods of aliasing. It's also quite easy to put an Arduino at the other end of a FTDI serial port ( a USB fake serial port ) and let it do all the hard real time - if it'll fit. Arduinos do SPI as well. -- Les Cargill
Reply by ●March 15, 20172017-03-15
On Tue, 14 Mar 2017 23:56:21 +0000, eric.jacobsen wrote:> On Tue, 14 Mar 2017 18:08:19 -0500, Tim Wescott > <seemywebsite@myfooter.really> wrote: > >>On Tue, 14 Mar 2017 23:01:30 +0000, eric.jacobsen wrote: >> >>> On Tue, 14 Mar 2017 22:42:23 +0000 (UTC), spope33@speedymail.org >>> (Steve Pope) wrote: >>> >>>>Tim Wescott <seemywebsite@myfooter.really> wrote: >>>> >>>>>On Tue, 14 Mar 2017 22:28:42 +0000, Steve Pope wrote: >>>> >>>>>> Something about running an ARM with "no OS" is freaky. >>>> >>>>>The LPC811M001 from NXP has 8K of flash and 2K of RAM (and 16 pins). >>>>>You could shoe-horn an RTOS in there, but it would take up >>>>>significant space. >>>>> >>>>>Less than $0.58 each if you buy 1000 of 'em from Digikey. $1.26 in >>>>>onesies. >>>> >>>>Thanks -- that sounds like a pretty neat product. I'll have to check >>>>out the datasheet. >>>> >>>>I've been on two significantly sized "no OS" projects, one used an >>>>8051 and the other a 68020. One of the two had sufficient programming >>>>discipline that "no OS" worked out well, but I still in retrospect >>>>wished that I had written a synchronization kernel. It was mostly the >>>>interplay between timer interrupts and other types of interrupts that >>>>led to trickiness. >>>> >>>>Steve >>> >>> For "embedded"-ish stuff, up until a few years ago the vast majority >>> of my experience was on "bare metal" (I.e., no OS) projects. I've >>> always found them much simpler, but for cases where they made sense, >>> i.e., the processor really only did one thing, and had to do it fast. >>> Even larger projects where we had to populate a micro or two for >>> Monitor and Control purposes, they were always bare metal (no OS). >>> That's not difficult with smaller processors, and it makes many >>> aspects of debug easier. >>> >>> So I always resisted working with an embedded or real-time OS because >>> they always seemed to just be in the way. The extreme other end of >>> that is working on a platform with a full OS (Linux) with networking >>> support, etc., which makes connecting for development and debug easy >>> and opens up a whole crazy world of additional support. >>> >>> I think anything in between is a little sketchy, but the amount of CPU >>> and OS power on the cheapie platforms does make them attractive for >>> cases where they're enough oomph to do a job. >> >>I find that when you have things on a processor that are working at >>vastly different time scales -- e.g., a human interface that needs to >>respond within 50ms, and a control loop that needs to respond in 100us >>-- >>then an RTOS is a huge help. >> >>They're also good when you have more than one person touching the >>software, because you can let the lower-ranked software engineers loose >>on the less time-critical parts of the code base with a lower likelihood >>that they'll do something that'll prevent the fast stuff from doing its >>job on time. >> >>(Lower, but not zero -- if they can turn off interrupts, they can screw >>things up royally, and I've seen it done and the results blamed on me!) > > Yup, I don't disagree with any of that. > > I think maybe I've been fortunate to have nearly always been on > competent teams where you didn't have to worry too much about somebody > screwing something up enough to affect performance.Nearly always for me, too -- but boy, the exceptions sure command my attention! -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by ●March 15, 20172017-03-15
On 3/14/2017 7:09 PM, Tim Wescott wrote:> On Tue, 14 Mar 2017 22:55:01 +0000, eric.jacobsen wrote: > >> On Tue, 14 Mar 2017 15:59:20 -0500, Tim Wescott >> <seemywebsite@myfooter.really> wrote: >> >>> On Tue, 14 Mar 2017 17:33:29 +0000, eric.jacobsen wrote: >>> >>>> On Tue, 14 Mar 2017 11:08:42 -0400, Eric <Eric@spamspamorspam.com> >>>> wrote: >>>> >>>>> Just curious about how much Linux is being used for embedded DSP apps. >>>>> If you're using it, what are your normal development tools? >>>> >>>> Lately I've done a number of projects similar to what Tim described, >>>> using ARM Cortex cores running some flavor of Linux or other. >>>> Generally they're good enough that an executable ports easily across >>>> the different common flavors of Linux, so it doesn't matter too much >>>> which one you're developing under. >>>> >>>> Unlike what Tim described, though, I do the development on Windows, >>>> using Eclipse for the IDE and cross-compiling. Eclipse has some very >>>> good remote-development tools, so doing the development and compiling >>>> on Windows and then running the executable and debug on the ARM >>>> platform is actually pretty easy. >>>> >>>> I had a client that also wanted the same process that was running on >>>> ARM cores to also run on x86/IA32/IA64. Although it was a simple >>>> port, it did make me set up a native Linux tool flow on the other >>>> platforms since it isn't as easy to cross-compile from Windows onto >>>> those platforms with the libraries I was using. >>>> >>>> And, yes, the apps I'm talking about are DSP apps, they're just >>>> running on ARM cores or whatever. These days a lot of processors are >>>> good enough that they're fine for the task. >>> >>> I'm developing on Linux by preference, and the processors I'm developing >>> for are deeply embedded using ARM Cortex M<whatever> cores running >>> little RTOS kernels or no OS at all. It sounds like you may be >>> developing for ARM Cortex A<whatever> cores that are actually >>> _executing_ Linux. >> >> Yes, A8s or better or whatever. I think having a clock speed >1GHz >> does help the situation somewhat. ;) > > Depending on what your requirements are. The best quote I've heard to > date on real-time development is "Real Fast does not mean Real Time".If you want real time, ditch the OS. Or better yet, ditch the CPU. Real men use FPGAs. -- Rick C
Reply by ●March 15, 20172017-03-15
On Wed, 15 Mar 2017 12:51:24 -0400, rickman wrote:> On 3/14/2017 7:09 PM, Tim Wescott wrote: >> On Tue, 14 Mar 2017 22:55:01 +0000, eric.jacobsen wrote: >> >>> On Tue, 14 Mar 2017 15:59:20 -0500, Tim Wescott >>> <seemywebsite@myfooter.really> wrote: >>> >>>> On Tue, 14 Mar 2017 17:33:29 +0000, eric.jacobsen wrote: >>>> >>>>> On Tue, 14 Mar 2017 11:08:42 -0400, Eric <Eric@spamspamorspam.com> >>>>> wrote: >>>>> >>>>>> Just curious about how much Linux is being used for embedded DSP >>>>>> apps. >>>>>> If you're using it, what are your normal development tools? >>>>> >>>>> Lately I've done a number of projects similar to what Tim described, >>>>> using ARM Cortex cores running some flavor of Linux or other. >>>>> Generally they're good enough that an executable ports easily across >>>>> the different common flavors of Linux, so it doesn't matter too much >>>>> which one you're developing under. >>>>> >>>>> Unlike what Tim described, though, I do the development on Windows, >>>>> using Eclipse for the IDE and cross-compiling. Eclipse has some >>>>> very good remote-development tools, so doing the development and >>>>> compiling on Windows and then running the executable and debug on >>>>> the ARM platform is actually pretty easy. >>>>> >>>>> I had a client that also wanted the same process that was running on >>>>> ARM cores to also run on x86/IA32/IA64. Although it was a simple >>>>> port, it did make me set up a native Linux tool flow on the other >>>>> platforms since it isn't as easy to cross-compile from Windows onto >>>>> those platforms with the libraries I was using. >>>>> >>>>> And, yes, the apps I'm talking about are DSP apps, they're just >>>>> running on ARM cores or whatever. These days a lot of processors >>>>> are good enough that they're fine for the task. >>>> >>>> I'm developing on Linux by preference, and the processors I'm >>>> developing for are deeply embedded using ARM Cortex M<whatever> cores >>>> running little RTOS kernels or no OS at all. It sounds like you may >>>> be developing for ARM Cortex A<whatever> cores that are actually >>>> _executing_ Linux. >>> >>> Yes, A8s or better or whatever. I think having a clock speed >1GHz >>> does help the situation somewhat. ;) >> >> Depending on what your requirements are. The best quote I've heard to >> date on real-time development is "Real Fast does not mean Real Time". > > If you want real time, ditch the OS. Or better yet, ditch the CPU. > Real men use FPGAs.Real time can mean "update every Sunday before midnight, on data taken at 00:00 on the previous Monday". Unless the computational load is incredibly high, you probably don't need an FPGA for such a task. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●March 15, 20172017-03-15
On 3/15/2017 1:34 PM, Tim Wescott wrote:> On Wed, 15 Mar 2017 12:51:24 -0400, rickman wrote: > >> On 3/14/2017 7:09 PM, Tim Wescott wrote: >>> On Tue, 14 Mar 2017 22:55:01 +0000, eric.jacobsen wrote: >>> >>>> On Tue, 14 Mar 2017 15:59:20 -0500, Tim Wescott >>>> <seemywebsite@myfooter.really> wrote: >>>> >>>>> On Tue, 14 Mar 2017 17:33:29 +0000, eric.jacobsen wrote: >>>>> >>>>>> On Tue, 14 Mar 2017 11:08:42 -0400, Eric <Eric@spamspamorspam.com> >>>>>> wrote: >>>>>> >>>>>>> Just curious about how much Linux is being used for embedded DSP >>>>>>> apps. >>>>>>> If you're using it, what are your normal development tools? >>>>>> >>>>>> Lately I've done a number of projects similar to what Tim described, >>>>>> using ARM Cortex cores running some flavor of Linux or other. >>>>>> Generally they're good enough that an executable ports easily across >>>>>> the different common flavors of Linux, so it doesn't matter too much >>>>>> which one you're developing under. >>>>>> >>>>>> Unlike what Tim described, though, I do the development on Windows, >>>>>> using Eclipse for the IDE and cross-compiling. Eclipse has some >>>>>> very good remote-development tools, so doing the development and >>>>>> compiling on Windows and then running the executable and debug on >>>>>> the ARM platform is actually pretty easy. >>>>>> >>>>>> I had a client that also wanted the same process that was running on >>>>>> ARM cores to also run on x86/IA32/IA64. Although it was a simple >>>>>> port, it did make me set up a native Linux tool flow on the other >>>>>> platforms since it isn't as easy to cross-compile from Windows onto >>>>>> those platforms with the libraries I was using. >>>>>> >>>>>> And, yes, the apps I'm talking about are DSP apps, they're just >>>>>> running on ARM cores or whatever. These days a lot of processors >>>>>> are good enough that they're fine for the task. >>>>> >>>>> I'm developing on Linux by preference, and the processors I'm >>>>> developing for are deeply embedded using ARM Cortex M<whatever> cores >>>>> running little RTOS kernels or no OS at all. It sounds like you may >>>>> be developing for ARM Cortex A<whatever> cores that are actually >>>>> _executing_ Linux. >>>> >>>> Yes, A8s or better or whatever. I think having a clock speed >1GHz >>>> does help the situation somewhat. ;) >>> >>> Depending on what your requirements are. The best quote I've heard to >>> date on real-time development is "Real Fast does not mean Real Time". >> >> If you want real time, ditch the OS. Or better yet, ditch the CPU. >> Real men use FPGAs. > > Real time can mean "update every Sunday before midnight, on data taken at > 00:00 on the previous Monday". Unless the computational load is > incredibly high, you probably don't need an FPGA for such a task.And yet it will do the job every bit as well as any CPU. We only use CPUs because when hardware was very expensive it was only practical if we time multiplexed logic between different operations. We then spent the next 40+ years optimizing this. The last 20 years as the cost of a transistor dropped below microcents we have been throwing more and more hardware at increasing CPU speeds with less and less benefit. We have reached the point where hardware costs are insignificant in most applications. The advantages of multiplexing the hardware is ending. FPGAs are much more useful now than they have ever been. -- Rick C
Reply by ●March 15, 20172017-03-15
On 3/14/2017 6:28 PM, Steve Pope wrote:> Tim Wescott <seemywebsite@myfooter.really> wrote: > >> I'm developing on Linux by preference, and the processors I'm developing >> for are deeply embedded using ARM Cortex M<whatever> cores running little >> RTOS kernels or no OS at all. It sounds like you may be developing for >> ARM Cortex A<whatever> cores that are actually _executing_ Linux. > > Something about running an ARM with "no OS" is freaky.The vast majorities of ARMs run with no OS. -- Rick C
Reply by ●March 15, 20172017-03-15
On Wed, 15 Mar 2017 14:00:47 -0400, rickman <gnuarm@gmail.com> wrote:>On 3/15/2017 1:34 PM, Tim Wescott wrote: >> On Wed, 15 Mar 2017 12:51:24 -0400, rickman wrote: >> >>> On 3/14/2017 7:09 PM, Tim Wescott wrote: >>>> On Tue, 14 Mar 2017 22:55:01 +0000, eric.jacobsen wrote: >>>> >>>>> On Tue, 14 Mar 2017 15:59:20 -0500, Tim Wescott >>>>> <seemywebsite@myfooter.really> wrote: >>>>> >>>>>> On Tue, 14 Mar 2017 17:33:29 +0000, eric.jacobsen wrote: >>>>>> >>>>>>> On Tue, 14 Mar 2017 11:08:42 -0400, Eric <Eric@spamspamorspam.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Just curious about how much Linux is being used for embedded DSP >>>>>>>> apps. >>>>>>>> If you're using it, what are your normal development tools? >>>>>>> >>>>>>> Lately I've done a number of projects similar to what Tim described, >>>>>>> using ARM Cortex cores running some flavor of Linux or other. >>>>>>> Generally they're good enough that an executable ports easily across >>>>>>> the different common flavors of Linux, so it doesn't matter too much >>>>>>> which one you're developing under. >>>>>>> >>>>>>> Unlike what Tim described, though, I do the development on Windows, >>>>>>> using Eclipse for the IDE and cross-compiling. Eclipse has some >>>>>>> very good remote-development tools, so doing the development and >>>>>>> compiling on Windows and then running the executable and debug on >>>>>>> the ARM platform is actually pretty easy. >>>>>>> >>>>>>> I had a client that also wanted the same process that was running on >>>>>>> ARM cores to also run on x86/IA32/IA64. Although it was a simple >>>>>>> port, it did make me set up a native Linux tool flow on the other >>>>>>> platforms since it isn't as easy to cross-compile from Windows onto >>>>>>> those platforms with the libraries I was using. >>>>>>> >>>>>>> And, yes, the apps I'm talking about are DSP apps, they're just >>>>>>> running on ARM cores or whatever. These days a lot of processors >>>>>>> are good enough that they're fine for the task. >>>>>> >>>>>> I'm developing on Linux by preference, and the processors I'm >>>>>> developing for are deeply embedded using ARM Cortex M<whatever> cores >>>>>> running little RTOS kernels or no OS at all. It sounds like you may >>>>>> be developing for ARM Cortex A<whatever> cores that are actually >>>>>> _executing_ Linux. >>>>> >>>>> Yes, A8s or better or whatever. I think having a clock speed >1GHz >>>>> does help the situation somewhat. ;) >>>> >>>> Depending on what your requirements are. The best quote I've heard to >>>> date on real-time development is "Real Fast does not mean Real Time". >>> >>> If you want real time, ditch the OS. Or better yet, ditch the CPU. >>> Real men use FPGAs. >> >> Real time can mean "update every Sunday before midnight, on data taken at >> 00:00 on the previous Monday". Unless the computational load is >> incredibly high, you probably don't need an FPGA for such a task. > >And yet it will do the job every bit as well as any CPU. We only use >CPUs because when hardware was very expensive it was only practical if >we time multiplexed logic between different operations. We then spent >the next 40+ years optimizing this. The last 20 years as the cost of a >transistor dropped below microcents we have been throwing more and more >hardware at increasing CPU speeds with less and less benefit. > >We have reached the point where hardware costs are insignificant in most >applications. The advantages of multiplexing the hardware is ending. >FPGAs are much more useful now than they have ever been.Not really. FPGAs make sense if the application isn't too cost-sensitive on hardware or, historically, the application is power-sensitive. It used to be in many cases that populating enough processor to do a particular job consumed more power than a well-sized FPGA. The CPU was often way cheaper, though, both in unit and support cost and developlment cost. The tradeoffs still exist. It doesn't make any sense to populate a $50 FPGA when a $3 processor will do the job with similar power consumption. I've done a LOT of FPGA work over the years where it made sense to do so, and also silicon when it made sense, and processors when it makes sense. FPGAs make sense in many cases, but definitely not in others. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Reply by ●March 15, 20172017-03-15
On 3/15/2017 2:10 PM, eric.jacobsen@ieee.org wrote:> On Wed, 15 Mar 2017 14:00:47 -0400, rickman <gnuarm@gmail.com> wrote: > >> On 3/15/2017 1:34 PM, Tim Wescott wrote: >>> On Wed, 15 Mar 2017 12:51:24 -0400, rickman wrote: >>> >>>> On 3/14/2017 7:09 PM, Tim Wescott wrote: >>>>> On Tue, 14 Mar 2017 22:55:01 +0000, eric.jacobsen wrote: >>>>> >>>>>> On Tue, 14 Mar 2017 15:59:20 -0500, Tim Wescott >>>>>> <seemywebsite@myfooter.really> wrote: >>>>>> >>>>>>> On Tue, 14 Mar 2017 17:33:29 +0000, eric.jacobsen wrote: >>>>>>> >>>>>>>> On Tue, 14 Mar 2017 11:08:42 -0400, Eric <Eric@spamspamorspam.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Just curious about how much Linux is being used for embedded DSP >>>>>>>>> apps. >>>>>>>>> If you're using it, what are your normal development tools? >>>>>>>> >>>>>>>> Lately I've done a number of projects similar to what Tim described, >>>>>>>> using ARM Cortex cores running some flavor of Linux or other. >>>>>>>> Generally they're good enough that an executable ports easily across >>>>>>>> the different common flavors of Linux, so it doesn't matter too much >>>>>>>> which one you're developing under. >>>>>>>> >>>>>>>> Unlike what Tim described, though, I do the development on Windows, >>>>>>>> using Eclipse for the IDE and cross-compiling. Eclipse has some >>>>>>>> very good remote-development tools, so doing the development and >>>>>>>> compiling on Windows and then running the executable and debug on >>>>>>>> the ARM platform is actually pretty easy. >>>>>>>> >>>>>>>> I had a client that also wanted the same process that was running on >>>>>>>> ARM cores to also run on x86/IA32/IA64. Although it was a simple >>>>>>>> port, it did make me set up a native Linux tool flow on the other >>>>>>>> platforms since it isn't as easy to cross-compile from Windows onto >>>>>>>> those platforms with the libraries I was using. >>>>>>>> >>>>>>>> And, yes, the apps I'm talking about are DSP apps, they're just >>>>>>>> running on ARM cores or whatever. These days a lot of processors >>>>>>>> are good enough that they're fine for the task. >>>>>>> >>>>>>> I'm developing on Linux by preference, and the processors I'm >>>>>>> developing for are deeply embedded using ARM Cortex M<whatever> cores >>>>>>> running little RTOS kernels or no OS at all. It sounds like you may >>>>>>> be developing for ARM Cortex A<whatever> cores that are actually >>>>>>> _executing_ Linux. >>>>>> >>>>>> Yes, A8s or better or whatever. I think having a clock speed >1GHz >>>>>> does help the situation somewhat. ;) >>>>> >>>>> Depending on what your requirements are. The best quote I've heard to >>>>> date on real-time development is "Real Fast does not mean Real Time". >>>> >>>> If you want real time, ditch the OS. Or better yet, ditch the CPU. >>>> Real men use FPGAs. >>> >>> Real time can mean "update every Sunday before midnight, on data taken at >>> 00:00 on the previous Monday". Unless the computational load is >>> incredibly high, you probably don't need an FPGA for such a task. >> >> And yet it will do the job every bit as well as any CPU. We only use >> CPUs because when hardware was very expensive it was only practical if >> we time multiplexed logic between different operations. We then spent >> the next 40+ years optimizing this. The last 20 years as the cost of a >> transistor dropped below microcents we have been throwing more and more >> hardware at increasing CPU speeds with less and less benefit. >> >> We have reached the point where hardware costs are insignificant in most >> applications. The advantages of multiplexing the hardware is ending. >> FPGAs are much more useful now than they have ever been. > > Not really. FPGAs make sense if the application isn't too > cost-sensitive on hardware or, historically, the application is > power-sensitive.You using vague terms like "cost-sensitive". Yes, there are no $0.50 FPGAs. But for the majority of projects an FPGA can do what a processor can do at the same price. It is much more an issue of memory than cost. FPGA internal memory scales with size, so if memory is the constraint an otherwise adequate FPGA with surplus capacity won't fit the bill. Not sure what you are saying about power.> It used to be in many cases that populating enough processor to do a > particular job consumed more power than a well-sized FPGA. The CPU > was often way cheaper, though, both in unit and support cost and > developlment cost.Not at all sure what FPGAs and what processors you are referring to. The range of processors is huge and I'm sure your statement above only applies to the small subset you are used to working with.> The tradeoffs still exist. It doesn't make any sense to populate a > $50 FPGA when a $3 processor will do the job with similar power > consumption.Likewise it makes no sense to use a $50 CPU when a $3 FPGA will do the job with lower power consumption. What's your point?> I've done a LOT of FPGA work over the years where it made sense to do > so, and also silicon when it made sense, and processors when it makes > sense. FPGAs make sense in many cases, but definitely not in others.Sometimes you feel like a nut... I can't argue with that! -- Rick C
