Arduino Service and Endpoint

[renereimann]

We have several Arduinos that run some sensors and we need to comminicate with.
Since we do not have full SCIPY implementation this is a light weighted version of an endpoint and service.
This code is nicely running at our setup.

[wcpettus]

Should establish convention for where example Arduino sketches go. Essentially this is templating a SCPI-lite device, which isn't really a dripline/dragonfly code element.
In Phase II we stashed them in the hardware repo, which was just an ad hoc solution.

[renereimann]

We move all our arduino code and raspberryPi code here: https://github.com/project8/MainzDripline3/tree/main/MicroControllerScripts

The main purpose is to have it version controlled and backed up.
In this pull request I wanted to give it as an example and thus it may better be in the example folder

[wcpettus]

If I'm understanding this correctly, the EthernetService part of this code is essentially a stripped-back version of the standard EthernetSCPIService that allows for socket instability, and thus flushes the socket connection every time it communicates.

Some assorted thoughts this raises (which are not prerequisites for this PR, but maybe to start a discussion that might need to migrate over to an issue thread):

• What are the relative merits of persistent vs continually-reset socket connections?
  • There's a lot of variance to how devices handle ethernet connections - some are single connection, some support multiple; some break the connection if you try to manually control; this can afford some system state guarantee because you know the SC system is the only one communicating with a device?
• Is it possible to make Arduino's persistent socket compliant?
  • Years ago I played around with a few standard Arduino's, and found a significant drop rate requiring a socket refresh. It was true across all models that used WiFi, but when I used a device with built-in ethernet everything was fine (that's why the Phase II lab used a bunch of ESP32-Gateway devices by Olimex).
• Are we following best practice with our socket connections?
  • Prompted by this PR, I poked around a bit, and found some pages like this recommending the use of socket.shutdown in the workflow (https://www.pythonlore.com/closing-and-releasing-resources-with-socket-close/). Would need to read more.

[wcpettus]

Adding review to post code comments.

[wcpettus]

is it useful to include a logger.debug of the response? like:
https://github.com/driplineorg/dripline-python/blob/main/dripline/implementations/entity_endpoints.py#L50

[wcpettus]

add docstring?

[wcpettus]

given the odd form of socket_info, probably best to define the init args (I know they follow a reduced set of EthernetSCPIService, but since they are independently defined, the docs don't follow)

[renereimann]

I checked yesterday and our current implementation with the arduino breaks the connection after every command. With this the "cmd_at_reconnect" basically is prohibitive to setup the arduino with the normal SCPI Service since after the cmd_at_reconnect the connection breaks and you do not have a chance to send the actual request.
So this simplification is needed here. Alternatively we need a better way to program the arduino itself.

[renereimann]

I digged a bit deeper to figure out if we can use the standard EthernetSCPIService.

There are two classes of ethernet shields for arduinos.

1. Ethernet shields/modules that use the “W5x00” series of Ethernet controller chips (like W5100, W5200, W5500)
2. Modules that use the ENC28J60 Ethernet controller chip

The first class of controller chips can be run using the “official” Arduino library Ethernet.h while the second class of chips need different kind of library, i.e. Ethercard.h and UIPEthernet.h

The ENC28J60 works very different from the "W5x00" series where the "W5x00" series has a hardware stack for TCP.
For the ENC28J60 the stach has to be implemented in software. The Ethercard.h does not implement a TCP connection but just a connection that is ended after each response. The UIPEthernet.h implements a TCP connection but needs a huge amount of memory since the TCP stack has to be in software.

Currently we use the ENC28J60 with the EtherCard.h library which just allows for a one time connection.

With a ENC28J60 and the UIPEthernet.h we would get a TCP connection on the cost of huge memory usage. I have to check if this is possible with our Arduino nano.

Alternatively shields with a "W5x00" series chip and the Ethernet.h library would also provide a TCP connection.