Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
peerst
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
1.
▲
by
peerst
1y ago
The development was funded by a research project where the coordinator was a manufacturer of thermal energy harvesting devices. That's why we focussed on power most. That requires certain choices for CPU, RAM. We also have a lot of en
2.
▲
by
peerst
1y ago
It's an evaluation board for a technology stack. That's its "use". We wanted to explore the design space towards smaller/low power/cheaper and find out where we can still squeeze a fully functional Erlang VM.
3.
▲
by
peerst
1y ago
It's all relative. Hard Realtime vs Soft Realtime is not clearly delineated. Because on anything real world there is always a probability distribution for every deadline. Our observation is that Erlang's "soft-realtime"
4.
▲
by
peerst
1y ago
Addendum: we have Buildroot and Yocto based platforms too. Not clear on the website right now but we have three platforms actually: * GRiSP Metal - aka just GRiSP (Erlang/Elxiir + RTEMS) * GRiSP Alloy - Buildroot Linux based, starts t
5.
▲
by
peerst
1y ago
With Linux we can only run on larger embedded CPUs that support virtual memory well enough. With RTEMS we can go towards much smaller platforms.
6.
▲
by
peerst
8y ago
Its not really „on RTEMS“, its more side by side. RTEMS is not a layer between the BEAM and te hardware its just helping by providing threads, TCP stack and file access. From a Erlang NIF or port driver (thats what we use to access the ou
7.
▲
by
peerst
8y ago
Yes we boot the BEAM on the hardware.
8.
▲
by
peerst
8y ago
RTEMS supports all 32bit hardware architectures. We also run it on a PowerPC controler for a customer project, but it also runs on Sparc, Mips all Arm and many other architectures. We don’t use the MMU so we don’t need it, some embedded ch
9.
▲
by
peerst
10y ago
Back then it was only running on customer specific hardware and was entangled with application code. Building this special hardware for it we can offer better user experience than with just a code release. Once we ship the board all of the
10.
▲
by
peerst
10y ago
As does using C for more complex applications ;-)
11.
▲
by
peerst
10y ago
This is a eval board, which is optimized for developer time. In practice low power and performance are interchangeable (you try to race as fast as you can to the next point where you sleep as deep as you can). The CPU has decent sleep mode
12.
▲
by
peerst
10y ago
Of course it can. It runs everything that runs on BEAM, Elixir, LFE, erlua and Erlang
13.
▲
by
peerst
10y ago
Firmware update in the field is important but only a small aspect of a embedded system (one that really needs to work). But Erlang already offers a lot around releases out of the box and in our case The VM + the whole "OS" is just
14.
▲
by
peerst
10y ago
Yes that also means the latency is not very long since in normal Erlang processes the process heap is also quite small so it doesn't take long to collect. Even without our planned extensions to the Erlang VM its astonishing well behav
15.
▲
by
peerst
10y ago
If you ignore the external memory the SAMV71 on the Grisp-Base has 384k on chip memory ... We plan to use this for the inner loop of the Erlang VM since its much faster than external memory. But thats a optimization for later after we can
16.
▲
by
peerst
10y ago
Well with RAM and flash you can either fit everything in on chip memory or you need external memory. Once you have external memory 64MB is the smallest that you can get and be confident that you can obtain it for the next years. Its also
17.
▲
by
peerst
10y ago
Actually we have Erlang on RTEMS in production since Erlang R16B03 on a MPC8309 embedded cpu (200MHz) this is running a controler for industrial manufacturing transport system with attached RFID antennas and a distributed PLC language that
18.
▲
by
peerst
12y ago
"require guarantees that erlang can't give" ... at the moment, working on it. In the meantime note that the percentage of stuff that really needs hard realtime in many systems is quite low. What I do at the moment is run Erl
19.
▲
by
peerst
12y ago
Soft is the new hard ;-) If you reason about hard realtime you pretty soon end up with the question: how high can the probability be that it misses a deadline. If you run on modern embedded CPU's with pipelines and caches its often a
20.
▲
by
peerst
12y ago
Well Erlang is running on RTEMS in production in industrial control systems http://www.grisp.org Hard realtime processes to come
21.
▲
by
peerst
12y ago
I have a project planned which when funded will give us hard realtime guarantees for certain Erlang processes. This can only work of course if the underlying OS is also hard realtime capable. I have ported Erlang to the open source RTEMS
22.
▲
by
peerst
13y ago
Well JS is keeping you thinking in pretty ancient ways. The "ideas" in JS are so old that you need quotes around the word. This sounds like from a Blub programmer. I'd better add a reference because Blub programers don'
23.
▲
by
peerst
13y ago
Well Erlang does have binaries for quite a while and many use them as high performance strings. So you can also use lists for strings, but why do you if you don't like the characteristics of lists?
24.
▲
by
peerst
13y ago
If I run a Erlang server and am no professional Erlang developer after 2 years what does that say about me?
25.
▲
by
peerst
13y ago
"modern parallel computing" ... well not everything that can run parallel on multi core CPU's can run very well on a GPU. I'm using Erlang and GPU programming each for its area of expertise. FWIW I even use both together via https://githu
26.
▲
by
peerst
13y ago
No it hasn't :-) Just to stay on your level of detail
27.
▲
by
peerst
14y ago
Same here, since Pinboard is protocol compatible to Del.icio.us its well integrated almost everywhere (also an option in lots of mobile apps). Everywhere else I use just the great boomarklet. Especially great is their page archiving ... go
28.
▲
by
peerst
14y ago
Can't wait to get my preordered print copy: "Learn You Some Erlang" rocks!
29.
▲
by
peerst
14y ago
I agree, besides ruby based syntax (which I don't consider a plus over Erlangs) you get pseudo mutable variables (they are not really but mimic them with a invisible sequence of Erlang like variables). The style that needs this ended up ha
30.
▲
by
peerst
14y ago
Thats what not many realize, that iolists with binaries need never be pasted together. They are basically passed to the kernel with a writev
More ›