4 ms·

This is great! I haven't tried the boards (yet) but it's difficult to find good industrial ready boards out there. Combine that with the difficulty of handling

This is great! I haven't tried the boards (yet) but it's difficult to find good industrial ready boards out there. Combine that with the difficulty of handling precise & consistent timing below 1 ms in Linux then these boards are a real gem!

bloaf 8y ago
I'm mildly interested in industrial-ready boards myself, but my industrial-ready means sitting outside in a hot and high-vibration environment doing signal processing. Everything I've heard about Erlang says it would be great at the networking part, but has no- or lousy- libraries for most number crunching applications.
- elcritch 8y ago
  You can make even an RPi survive harsher conditions with proper housing. Though it’s easier to work with the RPi compute module for that. What kind of signal processing? The computational libraries are somewhat rough. Though the Elixir communities are slowly adding more libraries, like Matrex (https://github.com/versilov/matrex https://github.com/versilov/matrex). It’s surprisingly easy to write C and Rust extensions.
- e_proxus 8y ago
  You can include other C libraries (and whatever else you can manage to interface towards via Erlang's C driver interface) using NIFs (native implemented functions) and Erlang port drivers. This means it's entirely possible to use Erlang for the networking and coordination part and special code for the signal processing.
nikofeyn 8y ago
national instruments makes the SoM, single-board RIO, and myRIO products. each has an fpga that can be programmed with labview and/or xilinx tools and a cpu running real-time linux that can be programmed with labview or any other toolchain you want to install on the linux portion. comes ready to interact with hardware of course.
amelius 8y ago
How easy is it to do real-time programming in Erlang? Would it be possible to get to 10 microsecond precision, to e.g. reliably drive a stepper motor directly from code?
- jlouis 8y ago
  10us is not generally achievable. Expect the lowest granularity you can get to be in the millisecond range. Erlang provides soft real-time, and under load you might see a process come later to the scheduler. You are guaranteed that the delay is somewhat fair over all processes though. If you want harder real-time, it is usually better to have a specialized kernel handling that, locked to a CPU core, and then have the Erlang system orchestrate work as a control backplane for that kernel.
  - elcritch 8y ago
    That’s one of the exciting points of this board using a true rtos. You can write real time tasks/threads for the RTEMS system. They mention the possibility of future Erlang bindings to do it as well.
amelius 8y ago
Question about Erlang: is it possible to send large blobs of binary data (e.g. video frames) from one process to another with the guarantee that the data is not serialized and the transfer is close to instantaneous?
- viraptor 8y ago
  If your binary is over some threshold (video frames almost certainly qualify) and the processes live on the same node, then the binaries should stay on binheap / refcounted memory and not get copied.
  - amelius 8y ago
    Ok, that's good to know. How would that work for a large tree with many small nodes? Is structural sharing possible between the two processes?
    - viraptor 8y ago
      https://news.ycombinator.com/item?id=16842055 https://news.ycombinator.com/item?id=16842055
    - jlouis 8y ago
      Not a priori. In practice, I'd guess that if we destructure a typical video frame, it will have a header which is somewhat tree-like and a payload which we are not going to touch and decode. In that case, we avoid the copy for the heavy parts of the frame, i.e., the payload. A good trick is that if you have a full frame from the network, keep a pointer to the full frame. Then decode the header as needed on top. This way, since the frame is full, you are guaranteed that no copy will occur for the frame while you are processing it. Also, the redundancy of the header is likely to be small in overhead with this approach. About 10 years ago, I did some work in Erlang where I was moving around 16 kilobyte blocks of data. I managed 800mbit at that time on that generation of hardware. The hardware on the board notwithstanding, I think Erlang is much better at handling this nowadays. As for the structural shaing between nodes: it is possible but only for data which is written very rarely and read quite often. In practice, the copying overhead in typical usage scenarios tend to be much cheaper than what people fear. One reason is that after the copy, you obtain cache locality, though also potential increased cache pressure.

bloaf 8y ago

I'm mildly interested in industrial-ready boards myself, but my industrial-ready means sitting outside in a hot and high-vibration environment doing signal processing. Everything I've heard about Erlang says it would be great at the networking part, but has no- or lousy- libraries for most number crunching applications.

elcritch 8y ago
You can make even an RPi survive harsher conditions with proper housing. Though it’s easier to work with the RPi compute module for that. What kind of signal processing? The computational libraries are somewhat rough. Though the Elixir communities are slowly adding more libraries, like Matrex (https://github.com/versilov/matrex https://github.com/versilov/matrex). It’s surprisingly easy to write C and Rust extensions.
e_proxus 8y ago
You can include other C libraries (and whatever else you can manage to interface towards via Erlang's C driver interface) using NIFs (native implemented functions) and Erlang port drivers. This means it's entirely possible to use Erlang for the networking and coordination part and special code for the signal processing.

nikofeyn 8y ago

national instruments makes the SoM, single-board RIO, and myRIO products. each has an fpga that can be programmed with labview and/or xilinx tools and a cpu running real-time linux that can be programmed with labview or any other toolchain you want to install on the linux portion. comes ready to interact with hardware of course.

amelius 8y ago

How easy is it to do real-time programming in Erlang? Would it be possible to get to 10 microsecond precision, to e.g. reliably drive a stepper motor directly from code?

jlouis 8y ago
10us is not generally achievable. Expect the lowest granularity you can get to be in the millisecond range. Erlang provides soft real-time, and under load you might see a process come later to the scheduler. You are guaranteed that the delay is somewhat fair over all processes though. If you want harder real-time, it is usually better to have a specialized kernel handling that, locked to a CPU core, and then have the Erlang system orchestrate work as a control backplane for that kernel.
- elcritch 8y ago
  That’s one of the exciting points of this board using a true rtos. You can write real time tasks/threads for the RTEMS system. They mention the possibility of future Erlang bindings to do it as well.

amelius 8y ago

Question about Erlang: is it possible to send large blobs of binary data (e.g. video frames) from one process to another with the guarantee that the data is not serialized and the transfer is close to instantaneous?

viraptor 8y ago
If your binary is over some threshold (video frames almost certainly qualify) and the processes live on the same node, then the binaries should stay on binheap / refcounted memory and not get copied.
- amelius 8y ago
  Ok, that's good to know. How would that work for a large tree with many small nodes? Is structural sharing possible between the two processes?
  - viraptor 8y ago
    https://news.ycombinator.com/item?id=16842055 https://news.ycombinator.com/item?id=16842055
  - jlouis 8y ago
    Not a priori. In practice, I'd guess that if we destructure a typical video frame, it will have a header which is somewhat tree-like and a payload which we are not going to touch and decode. In that case, we avoid the copy for the heavy parts of the frame, i.e., the payload. A good trick is that if you have a full frame from the network, keep a pointer to the full frame. Then decode the header as needed on top. This way, since the frame is full, you are guaranteed that no copy will occur for the frame while you are processing it. Also, the redundancy of the header is likely to be small in overhead with this approach. About 10 years ago, I did some work in Erlang where I was moving around 16 kilobyte blocks of data. I managed 800mbit at that time on that generation of hardware. The hardware on the board notwithstanding, I think Erlang is much better at handling this nowadays. As for the structural shaing between nodes: it is possible but only for data which is written very rarely and read quite often. In practice, the copying overhead in typical usage scenarios tend to be much cheaper than what people fear. One reason is that after the copy, you obtain cache locality, though also potential increased cache pressure.