
Tiny DSP Based Erlang / Linux Boards - dr_linux
https://lumenosys.com
======
thenewwazoo
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.

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

~~~
thenewwazoo
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
Blackfin DSPs? Heh, I'm good thanks.

~~~
coderjames
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
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
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
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.

