3 ms·

Tiny DSP Based Erlang / Linux Boards

64 points by dr_linux 11y ago

vvanders 11y ago
$99, not bad. I wonder if they're using nerves to build the linux image or if they're running a full distro? http://nerves-project.org/ http://nerves-project.org/
- Sanddancer 11y ago
  ucLinux -- https://lumenosys.com/store/index.php?route=product/product&product_id=52 https://lumenosys.com/store/index.php?route=product/product&... . So probably something close to the reference build Analog makes.
- thenewwazoo 11y ago
  Looks like they're running a fork of ADI's Linux distro for Blackfin[0], along with a BEAM port for mmu-less hardware[1] [0] https://github.com/lumenosys/lumenosys-adi-linux https://github.com/lumenosys/lumenosys-adi-linux [1] https://github.com/lumenosys/erlang-nommu https://github.com/lumenosys/erlang-nommu
themanfrommars 11y ago
Blackfin DSPs? Heh, I'm good thanks.
- coderjames 11y ago
  That was my reaction, too :-). My day job for 4 years was writing a software-defined radio for aviation on a Blackfin-based system. Intel and ADI made some really unfortunate design choices with that architecture that ADI seems surprisingly unwilling to correct.
  - diydsp 11y ago
    Any details you can share? I mostly don't use ADI due to closed compilers, but I had many fond experiences with 21xx and made one epic project with an early Blackfin.
    - coderjames 11y ago
      My single biggest pain point was the single-buffered UARTs in the 53X series. On the BF-538 that we were using, there are three of them and we needed them all. Since each one can only buffer a single incoming or outgoing byte at a time, there's a lot of interrupt-handling overhead with all of the RISC-style registers that need to be saved on each incoming byte. We were already using two of the SPORTs and both DMA engines for hard real-time transmit and receive signal processing with microsecond-scale deadlines, so they weren't available to offload the UARTs. But since the UARTs have such tiny hardware buffers, their interrupts have to be very high priority in order to avoid dropping characters. On a different project we were trying to build a very-low-power system around one of their new (at the time) BF52X parts, which had new low-power states for extended sleep. Except in the 0.0 version of the chips, those low-power states simply didn't work. An updated errata sheet was published a week or two later documenting that the processor couldn't be woken up once put to sleep.
      - diydsp 11y ago
        Ugh! Single buffered UARTS are catastrophic and outdated. sorry you had to go through that. ADI is more about raw processing power in base station apps; they don't seem to be interested in embedded, sigh. Thank you for getting back to me.
  - themanfrommars 11y ago
    Yup, those errata lists....
thenewwazoo 11y ago
Taking a quick glance over their repos, this looks like a pretty good approach for medium-latency applications. I'm reluctant to stack BEAM atop Linux in an embedded application, though, as I found Linux to add too much jitter and latency. Specifically, I was doing some testing with the AM3359's eCAP module in Erlang, and took a few approaches: - writing a NIF that consumed kernel interrupts directly, and sent messages - writing kernel module to expose the eCAP in sysfs and a NIF that select(1)ed the file, and sent messages - using Erlang to poll the sysfs eCAP fd None of them worked very well, unfortunately. I gave up when I couldn't get my kernel module working with a version that was supported by Xenomai or RTLinux, and moved onto Cloudozer's bare-metal Erlang VM implementation (which also eventually fizzled). I like Lumenosys' approach of using libiio and ioctls for this application. I was worried they were going to rely on Linux for the IO (i.e. sysfs) like Nerves does. I also very much appreciate that their work could be reasonably easily adopted on different platforms.

64 points by dr_linux 11y ago

$99, not bad. I wonder if they're using nerves to build the linux image or if they're running a full distro? http://nerves-project.org/ http://nerves-project.org/

Sanddancer 11y ago
ucLinux -- https://lumenosys.com/store/index.php?route=product/product&product_id=52 https://lumenosys.com/store/index.php?route=product/product&... . So probably something close to the reference build Analog makes.
thenewwazoo 11y ago
Looks like they're running a fork of ADI's Linux distro for Blackfin[0], along with a BEAM port for mmu-less hardware[1] [0] https://github.com/lumenosys/lumenosys-adi-linux https://github.com/lumenosys/lumenosys-adi-linux [1] https://github.com/lumenosys/erlang-nommu https://github.com/lumenosys/erlang-nommu

themanfrommars 11y ago

Blackfin DSPs? Heh, I'm good thanks.

coderjames 11y ago
That was my reaction, too :-). My day job for 4 years was writing a software-defined radio for aviation on a Blackfin-based system. Intel and ADI made some really unfortunate design choices with that architecture that ADI seems surprisingly unwilling to correct.
- diydsp 11y ago
  Any details you can share? I mostly don't use ADI due to closed compilers, but I had many fond experiences with 21xx and made one epic project with an early Blackfin.
  - coderjames 11y ago
    My single biggest pain point was the single-buffered UARTs in the 53X series. On the BF-538 that we were using, there are three of them and we needed them all. Since each one can only buffer a single incoming or outgoing byte at a time, there's a lot of interrupt-handling overhead with all of the RISC-style registers that need to be saved on each incoming byte. We were already using two of the SPORTs and both DMA engines for hard real-time transmit and receive signal processing with microsecond-scale deadlines, so they weren't available to offload the UARTs. But since the UARTs have such tiny hardware buffers, their interrupts have to be very high priority in order to avoid dropping characters. On a different project we were trying to build a very-low-power system around one of their new (at the time) BF52X parts, which had new low-power states for extended sleep. Except in the 0.0 version of the chips, those low-power states simply didn't work. An updated errata sheet was published a week or two later documenting that the processor couldn't be woken up once put to sleep.
    - diydsp 11y ago
      Ugh! Single buffered UARTS are catastrophic and outdated. sorry you had to go through that. ADI is more about raw processing power in base station apps; they don't seem to be interested in embedded, sigh. Thank you for getting back to me.
- themanfrommars 11y ago
  Yup, those errata lists....

thenewwazoo 11y ago

Taking a quick glance over their repos, this looks like a pretty good approach for medium-latency applications. I'm reluctant to stack BEAM atop Linux in an embedded application, though, as I found Linux to add too much jitter and latency. Specifically, I was doing some testing with the AM3359's eCAP module in Erlang, and took a few approaches: - writing a NIF that consumed kernel interrupts directly, and sent messages - writing kernel module to expose the eCAP in sysfs and a NIF that select(1)ed the file, and sent messages - using Erlang to poll the sysfs eCAP fd None of them worked very well, unfortunately. I gave up when I couldn't get my kernel module working with a version that was supported by Xenomai or RTLinux, and moved onto Cloudozer's bare-metal Erlang VM implementation (which also eventually fizzled). I like Lumenosys' approach of using libiio and ioctls for this application. I was worried they were going to rely on Linux for the IO (i.e. sysfs) like Nerves does. I also very much appreciate that their work could be reasonably easily adopted on different platforms.