Re: Re: Re: Using (stripped down ei.h) with generic TCP instead of ports

Ok I see. I was under the impression that you were using some kind of
RT Linux kernel. Unfortunately I'm not familiar with TwinCAT. I'm very
familiar with hard real time systems though. I normally approach these
things in same way as you. I write optimized code for DSP and then
Erlang for logic and supervision. I have written some Linux device
drivers but no windows drivers. To me the idea of using TCP/IP for
communication between kernel space and user space seems really
strange, but maybe that's the way they do it. The binary encoding of
Erlang terms is not very complicated, I think there's some
documentation and even some thirds party libraries floating around.
Good luck with your project.

--Albin

On Sun, Sep 20, 2020 at 6:34 PM Brett Hemes <[email protected]> wrote:
>
> For this particular effort, I am using Beckhoff’s TwinCAT 3 framework for PC-based industrial control.  In addition to the normal industrial programming standards, they provide a C/C++ implementation that provides *hard* real-time capability through a modified subset of the standard libraries implemented in the kernel mode of the underlying (Windows 10 in this case) OS.  Within this environment I am constrained by the APIs offered to communicate with the outside world / programs in user mode.  I have to use proprietary libraries to get socket functionality etc. and thus I can not use the erl_interface without modification (and the port driver and NIF approaches are not applicable in this scenario).
>
>
>
> I have been learning about Erlang and am very intrigued by the language.  I would like to try out some ideas implemented in Erlang but some of the code will have hard real-time constraints as well as other industrial communication protocol requirements.  Thus, I will have to split the code across the BEAM and the TwinCAT3 environments.  Since I am at the beginning, I have the luxury of defining the architecture/interfaces and I thought passing Erlang (binary) terms between the two environments would be a nice approach to allow somewhat native communication between hard real-time C/C++ processes while also avoiding writing an arbitrary serialized protocol from scratch….   Perhaps I am being naïve.  Also, after digging some more, I have discovered that a lot of the functions in ei/erl_interface that I was excited about have been deprecated in OTP 22 and are scheduled for (have been already?) removal.
>
>
>
> Thanks for your help and patience,
>
> Brett
>
>
>
>
>
> From: Albin Stigö <[email protected]>
> Sent: Sunday, September 20, 2020 10:58 AM
> To: Brett Hemes <[email protected]>
> Cc: Max Lapshin <[email protected]>; Erlang Questions <[email protected]>
> Subject: [EXTERNAL] Re: Re: Using (stripped down ei.h) with generic TCP instead of ports
>
>
>
> Which kernel are you using?
>
>
>
> --Albin
>
>
>
> On Sat, Sep 19, 2020, 21:29 Brett Hemes <[email protected]> wrote:
>
> Could you perhaps elaborate on your reply a bit?  The RT development environment (running in kernel mode) offers only a memory mapped interface besides the aforementioned UDP/TCP option for communication between the RT modules and user mode applications.  I believe “exposing the interface” would require me to both make an interface from scratch and then wrap it as a port driver or NIF to get it into the BEAM.  Aside from some arbitrary handshaking interface via registers I could imagine passing strings via fixed length character buffers but I will still need some form of encoding/decoding… which is how I ended up looking at the ei library.
>
>
>
> Also, most of what I have read regarding Erlang seems to favor ports over drivers and NIFs as they better align with the Erlang philosophy but I am too new to all this to really know when each is preferred.
>
>
>
> Thanks much,
>
> Brett
>
>
>
> From: Albin Stigö <[email protected]>
> Sent: Thursday, September 17, 2020 9:32 AM
> To: Max Lapshin <[email protected]>
> Cc: Brett Hemes <[email protected]>; Erlang Questions <[email protected]>
> Subject: [EXTERNAL] Re: Using (stripped down ei.h) with generic TCP instead of ports
>
>
>
> I would expose the kernel code through a char or block device driver. There are already many facilities in most kernels for effective communication with userpace. a
>
> After all, that's the whole point of a kernel...
>
>
>
> --Albin
>
> On Thu, Sep 17, 2020, 16:00 Max Lapshin <[email protected]> wrote:
>
> Your idea is ok.  Just strip everything you don't need from ei and it will work for you.
>
>
>
> As for me, I like enif api more, but Sverker has pointed that I'm misuing it inside drivers and it may break once =)
>
>
>
>