<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 20.09.2017, at 14:01, Drasko DRASKOVIC <<a href="mailto:drasko.draskovic@gmail.com" class="">drasko.draskovic@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Wed, Sep 20, 2017 at 1:20 PM, Peer Stritzinger <<a href="mailto:peer@stritzinger.com" class="">peer@stritzinger.com</a>> wrote:<br class=""><blockquote type="cite" class="">Hi Drasko,<br class=""><br class=""><blockquote type="cite" class="">On 20.09.2017, at 11:36, Drasko DRASKOVIC <<a href="mailto:drasko.draskovic@gmail.com" class="">drasko.draskovic@gmail.com</a>> wrote:<br class=""><br class="">On Wed, Sep 20, 2017 at 11:12 AM, Adam Lindberg <<a href="mailto:hello@alind.io" class="">hello@alind.io</a>> wrote:<br class=""><blockquote type="cite" class="">Hi Richard and Lloyd,<br class=""><br class="">We target smaller embedded systems that could benefit from Erlang, whereas on a Raspberry Pi (even zero) or Beagleboard you can easily run Linux and Erlang on top. The goal is to be able to work as much as possible with hardware in Erlang. We combine Wi-Fi with support more standard connectors, such as ports for PMODs, I²C, 1-Wire an so on. Our 300 Mhz CPU uses much less energy and the board is aimed at being an evaluation board for (then cheaper) embedded systems.<br class=""></blockquote><br class="">Booting system from SD Card will not make it in production. I think<br class="">you'll need bigger non-volatile storage on the board.<br class=""></blockquote><br class="">We have a board with the same software stack in production for a industrial customer for about 5 year.<br class=""><br class="">This board has soldered on NAND flash, but that means you need a Flash filesystem.<br class=""><br class="">We use yaffs2 but this is GPL2 dual license and we are paying for being free from GPL in our product.<br class="">SD Card is good in production for certain use cases but for some one wants NAND flash on board.<br class=""><br class="">This is a eval and maker board to build prototypes and have fun with. And yes it can be used in production for certain use cases.<br class=""><br class="">In most production cases I would build a specialized board which have all the sensors on board and not use PMODs for them<br class="">and also boot from local NAND flash.<br class=""><br class="">GRiSP-base is meant as a starting point for that. And to get started a SD-card is *very* useful<br class=""></blockquote><br class="">Prototype - yes, SD card is useful. Production - no, SD cards break<br class="">often. They are not ment to keep your system files and that you boot<br class="">your system from them. They are secondary storage. RPi is totally<br class="">useless in production because of this. There are industrial SD cards,<br class="">but they are very expensive and do not justify not having flash<br class="">soldered on the board.<br class=""></div></div></blockquote><div><br class=""></div>I disagree, having built many products. For small batch size industrial SD cards</div><div>can be better than soldered on flash. If you don want to GPL your embedded application</div><div>you have to pay about 5k € for licensing yaffs2 … for that I can buy quite a bit of</div><div>expensive SD-cards.</div><div><br class=""></div><div>And rPI is useless for production anyway because they have quality issues and frequent new versions. </div><div>Which is not a problem since it was meant only for teaching.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">And why RTEMS when there is now Zephyr and RIOT with all necessary IoT<br class="">libs - like MQTT and CoAP?<br class=""></blockquote><br class="">The question could be stated the other way round too.<br class=""><br class="">RTEMS is around since the 1980ties and very robust.<br class=""><br class="">Its very usably in industrial and automotive and of course also for IoT (whatever that may be) also its Space rated and used on a lot of space probes of NASA and ESA.<br class=""><br class="">One other thing that makes it useful to us: it has solid SMP support and embedded systems are having more cores more and more.<br class=""><br class="">And allowing access to SMP is kind of useful for Erlang. Not available in GRiSP base since we have a single core but we are using this as<br class="">platform on smaller systems than GRiSP base and larger ones. What you see on <a href="http://www.grisp.org" class="">www.grisp.org</a> is just what we put out so everyone can get started quickly and have as much fun as we have :-)<br class=""><br class="">But there are hundreds of embedded OS with all kinds of properties, you could pick many for porting Erlang to.<br class=""><br class="">The main goal is that the embedded OS we use as basis steps aside and Erlang looks like the OS.<br class=""></blockquote><br class="">I understand this, but this is exactly why these modern RTOSes are<br class="">made for: <a href="https://www.zephyrproject.org/" class="">https://www.zephyrproject.org/</a> and <a href="https://riot-os.org/" class="">https://riot-os.org/</a>.<br class="">These are big modern projects that try to solve various problems<br class="">existing with old RTOSes, especially on communication and networking<br class="">side.<br class=""></div></div></blockquote><div><br class=""></div><div>Well RTEMS in the version we use has a recent SMP capable FreeBSD network stack.</div><div><br class=""></div><div>We like old and seasoned better for embedded than new and big projects which pop up and disappear quickly.</div><div><br class=""></div><div>Thats what we like about Erlang too.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">IoT communication protocols are not fun to port:<br class=""><a href="https://lists.rtems.org/pipermail/devel/2017-March/017240.html" class="">https://lists.rtems.org/pipermail/devel/2017-March/017240.html</a><br class=""></div></div></blockquote><div><br class=""></div>Well who wants the protocol in C when we have Erlang??</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Sticking with weird licensing: <a href="https://www.rtems.org/license" class="">https://www.rtems.org/license</a> instead<br class="">with industry-adopted Apache-2.0 is also an error IMHO.<br class=""></div></div></blockquote><div><br class=""></div><div>Well whats your problem with that license? It is an approved license for many large companies</div><div>who are our customers. And not long ago Erlang had a non mainstream license too. </div><div><br class=""></div><div>But thanks for telling us we are doing it wrong for years ;-)</div><div><br class=""></div><div>Have a nice day,</div><div>-- Peer </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Best regards,<br class="">Drasko<br class=""></div></div></blockquote></div><br class=""></body></html>