Anyone using Linux?

Just curious about how much Linux is being used for embedded DSP apps.
If you're using it, what are your normal development tools?

On Tue, 14 Mar 2017 11:08:42 -0400, Eric 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?

I'm doing development for ARM Cortex chips, mostly.  Ubuntu for the OS, 
Eclipse for the IDE, gnu command-line tools for the build.  I'm currently 
using Subversion for version control, but my #1 son is trying to talk me 
into Mercurial.

The actual compiler is generally a function of the chip -- the gnu 
project doesn't directly support compilers for any DSP chips that I know 
of, so you're kind of at the mercy of the vendor for tools.  In the 
event, sometimes the only tools available run on Windows, in which case 
you need to have a dual-boot machine or you need to run Windows on a 
virtual machine.

-- 
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

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

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?

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.

-- 

Rick C

On Tuesday, March 14, 2017 at 2:00:38 PM UTC-4, gyans...@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?

Low frequency stuff like audio (e.g at 48Khz) is fine

as you move to higher frequencies the non-real time nature of Linux OS will be showing and you'll need an add-on real-time board like Arduino to handle I/O etc.

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

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

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 ?
    

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

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 tuning