Tiny DSP Based Erlang / Linux Boards | Hacker News Reader

Tiny DSP Based Erlang / Linux Boards

lumenosys.com

64 pointsdr_linux10 comments

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.

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

ucLinux -- https://lumenosys.com/store/index.php?route=product/product&... . So probably something close to the reference build Analog makes.

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

[1] https://github.com/lumenosys/erlang-nommu

Blackfin DSPs? Heh, I'm good thanks.

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.

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.

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.

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.

Yup, those errata lists....

Reply on news.ycombinator.com