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. -- 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 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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●March 14, 20172017-03-14
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. Steve
Reply by ●March 14, 20172017-03-14
On Tue, 14 Mar 2017 22:28:42 +0000, 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 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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●March 14, 20172017-03-14
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
Reply by ●March 14, 20172017-03-14
On Tue, 14 Mar 2017 22:42:23 +0000, 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.There are a number of chips using the ARM Cortex M0 core that are under a buck in quantity. They're definitely trying to give the 8051 and the various other 8-bitters a run for their money.> 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."No OS" works best if you can count the tasks on the fingers of one hand, and if there aren't hugely different time scales between your most and least critical task. Beyond that you should start seriously asking yourself why you aren't using one of the little RTOSs out there. And lack of team discipline can shoot you out of the water. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●March 14, 20172017-03-14
On Tue, 14 Mar 2017 13:03:17 -0700 (PDT), angrydude <simfidude@gmail.com> wrote:>On Tuesday, March 14, 2017 at 3:13:44 PM UTC-4, eric.j...@ieee.org wrote: >> On Tue, 14 Mar 2017 11:58:42 -0700 (PDT), angrydude >> <simfidude@gmail.com> wrote: >> >> >On Tuesday, March 14, 2017 at 2:30:07 PM UTC-4, eric.j...@ieee.org wrote: >> >> On Tue, 14 Mar 2017 11:00:31 -0700 (PDT), 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? >> >> >> >> It just depends on the requirements, what you're doing, and what else >> >> might be running on the same platform, but you can actually get a lot >> >> more done in real-time than I had initially expected. If you have >> >> control over the entire platform, i.e., you have control over what >> >> will or won't be running, it's not bad. As angrydude mentioned, >> >> there's going to be some limit on the ability to do I/O as well as how >> >> much CPU is reliably available. >> >> >> >> My applications are generally real-time for wireless communications, >> >> and I've done SDR (software defined radio) apps for continuous-stream >> >> signals that run fine on an RPi3 or Beaglebone or CHIP or whatever. >> >> >> >> There is a priority setting in Linux for "real-time", so if your app >> >> runs from root it can give itself that priority and keep up with >> >> things pretty well. >> >> >> >> >> >> >> >> --- >> >> This email has been checked for viruses by Avast antivirus software. >> >> https://www.avast.com/antivirus >> > >> >But you don't do raw RF signal processing on RPi - your signal is already down-converted to low freq with that RTL USB dongle >> >> One downside to those it that the anti-alias filtering is pretty >> crappy, so you really can't drop the sample rate much less than about >> 1MHz without dealing with a lot of issues. This means doing a lot of >> decimation filtering if your signal is much narrower than that. >> >> I've not had any trouble keeping up with the processing even at that >> rate, so it does open up a lot of possibilities. >> >> >That RTL-SDR thing is pretty neat and cheap btw. >> >I was recently wondering if one can easily get a full baseband signal for e.g. FM transmission out of it to do your own stereo and RDS decoding in software on e.g. RaspPi ??? Any thoughts ? >> >> Yes, you can d/l open-source software that does that. >> >> Actually, there are some test programs that come with the basic >> rtl-sdr library that do FM decoding and may even have some RDS stuff. >> Source code comes with it. >> >> For a more integrated app people use sdrsharp (aka sdr#), which has >> all of that functionality plus spectrogram, analyzer, etc. I don't >> know whether anybody runs the full sdr# on a Pi with a display or not, >> or just on PCs. >> >> >> >> --- >> This email has been checked for viruses by Avast antivirus software. >> https://www.avast.com/antivirus > >I have sdr# on laptop - runs just fine but it's huge with all features, fully integrated and I believe can only give you final decoded FM audio with low samp freq (48Khz) and RDS >Even if it runs on Pi (which I doubt) I don't want it - Si4703 will do it all (https://www.sparkfun.com/products/11083) in much smaller package >I actually want to change FM encoding/decoding standard and run it outside of official FM band (FCC is not a concern - it's very low power) >What I found out is that putting FM transmitter together (from raw parts like coils, capacitors etc) is much simpler than building a decent receiver, not to mention tuning both of them to the same frequency manually... >(BTW one can also use Pi as an FM transmitter with no extra parts other than antenna added ! isn't it cool ?! >http://www.icrobotics.co.uk/wiki/index.php/Turning_the_Raspberry_Pi_Into_an_FM_Transmitter) > >I think I'm gonna try this RTL-SDR dongle thing - it's very small and works with Pi, and Pi Zero too I hope >All I need is an upsampled (e.g. 1MHz) full baseband signal out of it I can apply my own decoding to... >and no manual tuningThey're a little wobbly in some ways, but generally decent devices. Let me know if you run into any troubles with it, I've probably been there and done that already. ;) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Reply by ●March 14, 20172017-03-14
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. ;) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Reply by ●March 14, 20172017-03-14
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. > >SteveFor "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. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Reply by ●March 14, 20172017-03-14
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!) -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
