Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Universal serial connector for Beremiz proposal #1

Open
nucleron opened this issue Feb 16, 2017 · 0 comments
Open

Universal serial connector for Beremiz proposal #1

nucleron opened this issue Feb 16, 2017 · 0 comments

Comments

@nucleron
Copy link
Owner

nucleron commented Feb 16, 2017

Architecture

The connector consists of two parts:

  • A dynamic library with standartized API/ABI;
  • Beremiz connector which loads a dynamic lib and use it as a transport to PLC.

Dynamic lib

Dynamic lib gives us a serial transport with standart API/ABI. Libs internals may use sockets/pipes/files/devices/etc.
It can implement any transport that PLC vendor like, the only requirement, is standart API/ABI.
The proposed API/ABI is:

int handle_open (void ** handle, char * uri, uint32_t uri_len); //Returns zero on successfull connection creation
int handle_close (void ** handle); //Returns zero on success
int handle_read  (void ** handle, void *buf, size_t nbyte); //Returns numer of bytes red
int handle_write (void ** handle, void *buf, size_t nbyte); //Returns number of bytes written

Where:

  • handle - an opaque pointer for transport control entity.
  • uri - a pointer to sockets/pipes/files/devices/etc name.
  • uri_len - URI length (yes we will try address possible buffer overflow).
  • buf - a pointer to data buffer used for communication.
  • nbyte - a number of byte to transmit/receive.

Beremiz connector

The connector itself implements serial connection protocol, we propose LPCManager or YAPLC/IDE protocols as a base.

It also should have standart Beremiz side connector API, if someone adds data buffering to connector it would be very cool.

We propose the following URI format for connector:

UNIDBG://Path_to_dynamic_lib//Transport_uri

Where:

  • Path_to_dynamic_lib - A path to dynamic lib file (I beleive it should be relative to some base dir).
  • Transport_uri - a string that will be passed to handle_open as uri.
    So PLC vendors can implement any transport layer they like and they can use the same connector for different transports.

Issues

  • 32/64 bit: 32bit python wants 32bit dll, 64bit python wants 64bit lib at least on Windowr(R).
  • Boot protocol: different vendors use different boot protocols (e.g. we use STMicros-bootloader for program boot) and different file types to boot their PLCs, we must design some common way to handle these differences.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant