Any container image is based on a parent image as described here. You can build your own base image or use already published ones.

We really appreciate the work of company Resin.io in generating loads of Docker base images for different hardware platforms. One of their public repositories on Docker Hub named armh7f-debian is compiled for armv7hf architecture based platforms and delivers seamless compatibility with Raspberry Pi 2/3 respectively netPI.

Company Resin.io is very active in providing latest images of released versions of debian whenever they come out and all their images support cross build of ARM code on x86 machines allowing automated builds on Docker Hub. This is why we feel your are in good hands using their offerings and recommend to use the Debian:jessie image as base image for your work. Also we use it as basis for most of our example netPI Docker images provided here.

Since netPI is not offering SSH connectivity the Docker CLI cannot be used. Instead a Pi 3 have to be used for developing netPI Docker images.

This command pulls the latest Debian:jessie image onto your Pi 3:

docker pull resin/armv7hf-debian:jessie

This command starts a container from the image and jumps into a bash shell:

docker run -ti --entrypoint=/bin/bash resin/armv7hf-debian:jessie

We recognized a high demand for a 3G/4G/UMTS/LTE support of netPI using USB router sticks plugged into one of the four netPI USB ports.

As of today we can tell you that the current delivered netPI firmware 0.9.1.0 does not support the mapping of those USB devices into containers. We are working right now on a solution and we will be providing you a support for those devices in one of the coming firmware updates quite soon.

Docker automatically assigns IP adresses to all those containers started in default bridged network mode. A disadvantage is that each time netPI boots different IP addresses are assigned to these containers which makes a predicable inter-container communication impossible.
Instead is it recommended to create a local user-defined network on the system first where Docker is automatically operating a DNS service for. Then, in case a container is started, you can specify this user-defined network as network the container shall run with.
The embedded DNS server provides the discovery service for any container created with a valid name. Only then it maintains the mapping between the container name and its IP address on the network the container is connected to.
Example: Create two containers with names Container1 and Container2. For both containers specify your user-defined network to connect to. A DNS service will be provided automatically on this network. You can then address the containers over their names with a ping command for example like ping Container1 or ping Container2 instead of using their IP addresses.

A new container has been published that allows to run "CODESYS Control for Raspberry Pi" on netPI.

The container's repository and image is located here https://hub.docker.com/r/hilschernetpi/n...sys-basis/ ready for your download.

The loading time depends on several factors.

First of all it depends on your Internet connection, then of course on the size of the image. What you must know is that images on the web are packed. Once an image is loaded to netPI Docker starts unpacking it when a container is created of it. Usually the ratio is 1:3 which means an image of a size of 200 MB will be 600 MB effectively on netPI later.
Another parameter that influences the load and start time is the number of layers the image consists of. The more layers the more time is needed to unpack layer per layer.
For an image of a size of 185MB we measured a time for loading and unpacking of about 5 minutes. The start of a container afterwards is just a thing of some milliseconds in relation to how many other containers have to be started at the same time.
After using the +Add container option in netPI's Docker management UI patiently wait as long as the tiny gearwheel turns after you pressed Start container which indicates the image is loaded and about to be started. Once an image is loaded it will not be loaded again and containers of it will be started as a normal service along with all the other netPI's system services.

By default netPI system softare supports SSH/TSL secured web connections to its web GUI over a https:// access method only.

By definition a secure connection ensures reasonable protection only if a certificate identifies the server as trustworthy. Only then further ongoing transactions of the initiating browser and a server can be assumed as being protected against eavesdroppers and data theft.

For that reason a browser requests a certificate from the server (netPI) first of all for verification. This certificate contains the issuing authority verified the server's trust. A list of known authorities comes pre-installed in any browser. Once a server's certificate is returned the browser compares the certificate's authority with the known ones in the list. If it is not part the browser reports a certificate error and urges the user to confirm to continue operation since it has to assume the connection is insecure.

By default netPI contains a certificate issued by Hilscher and we are not a member of known authorities in the view of the browser. That's why a browser reports the connection as insecure and asks for user confirmation to continue. Once confirmed future connections will be established without questioning again.

Hint: The cerfiicate can be replaced by a trusted customer certificate at any time in netPI's web control panel.

netPI's RTC chip is backuped by a maintenance free supercapacitor of 0,22F capacity. It will backup the RTC for at least 7 days in case a netPI is not powered.

Avoid destruction:

There is a security mechanism in the BCM2837 CPU implemented preventing it from self destruction at high temperatures. For this a single temperature sensor in the CPU is monitoring the CPUs core temperature all the time (one sensor for all 4 cores) to be able to reduce the whole CPU's speed just in case and hence the waste heat it is producing.

How it works:

At core temperatures higher than 80°C the CPU "stepwise" starts lowering its standard 1.2Ghz (full speed) clock rate down to 600MHz (half speed) . At a level of 85°C and beyond the CPU stops reducing its speed and remains operating at 600Mhz (all 4 cores). Since the CPU  is only able to run at full speed or at half speed at a specifc time it uses a trick to vary the effective clock rate between the temperature range of 80°C and 85°C: a switching cycle decides on times the CPU is clocked at 1.2Ghz and on times it is clocked at 600Mhz and chopping the time periods in pieces. This mechanism works quite linear in the 5°C temperature difference range. So while at 80°C there is no switching resulting in 100% 1.2Ghz, at a level of 82.5°C it is running 50% of the time at 1.2Ghz and 50% at 600Mhz giving an effective clock rate of 900Mhz, while at 85°C and more it is 100% 600Mhz.

Standard RPI3, reduced speed at  24°C already:

A standard Raspberry Pi 3 that you run on your desk at a room temperature of 24°C (even with a passive heat sink on the CPU) reaches the core temperature of 80°C easily running a sysbench test with all 4 CPUs as described here. So imagine you would use such a RPi3 in an installation cabinet under industrial conditions where 40°C and more inside a cabinet are most common. Then an RPi3 would run just at 60% of its power.

netPI, no reduced speed till 50°C:

This is different with netPI. Of course netPI uses the same CPU, but netPI has a better cooling concept using an aluminium heat sink on top of the CPU that conducts its heat to the metallic housing. Additionally netPI consists of an 8 layer PCB while a RPi3 just has 6 and also the PCB is twice as big ensuring a better heat dissipation in general. All these countermeasures lead netPI keeping the CPU clock frequency to maximum 1.2GHz for all 4 cores up to an ambient air temperature of 50°C.

The interface between the Raspberry CPU (BCM2837) and netX (netX51 on netPI RTE 3) is a serial dual-port memory interface (SPM) provided by netX as described here. Any communication across this connection is initiated by the BCM chip while netX is always passive and just returns the data beeing requested.The clock speed of the SPI interface is configured to 25 Mhz by the driver. This limit comes from netX's SPI driven serial dual-port memory (SPM) that can be clocked just up to 33Mhz in maximum.

Basis of the SPM is a synchronous peripheral interface (SPI) bus interconnected between BCM and netX. Physically the following signals are connected to each other

BCM GPIO9 (SPI0_MISO) to netX SPM_MISO
BCM GPIO10 (SPI0_MOSI) to netX SPM_MOSI
BCM GPIO8 (SPI0_CE0_N) to netX SPM_CSN
BCM GPIO11 (SPI0_SCLK) to netX SPM_CLK
BCM GPIO24 (GPIO_GEN5) to netX SPM_DIRQ

Under Linux the SPI0 of the BCM chip is assigned to the device /dev/spidev0.0. So whenever any communication between the BCM2837 chip and netX51 is ongoing this happens through this Linux device. There can only be one source under Linux making use of this device. There is no support for multiple users.

A linux driver for the SPM is available here. Once you have installed it it provides you also a library that you can link to your GNU compiled applications. This library offers you a common API that we call "cifX API" (Communication InterFace for netX based devices) which is described here. It lets you send and receive acyclic messages to and from netX and also exchange you cyclic IO data of the current protocol that is running within netX.

Remark concerning interrupt event support:

The netX SPM interrupt signal SPM_DIRQ is physically connected to Raspberrys pin GPIO24 as stated above. Across this pin netX does indeed raise a signal whenever it has to "tell" the host processor something has changed in the SPM handshake cell and to trigger the host to read and to examine the handshake cell. By this read action the interrupt will be released automatically by netX.

Precondition in doing so is that the host driver listens to GPIO24 in interrupt driven mode. Far more important is that the GPIO24 is configured by default to "Level detect" mode instead of "Edge detect" mode in register GPHENn as described here in the BCM chip's manual in order not to miss any interrupts of the SPM in case netX raises signals on SPM_DIRQ in very quick succession.

Unfortunately the current implementation of Raspberrys GPIO driver in the Raspberrys official Linux kernel that is also basis of netPI does not support configuring a GPIO to level detection mode but to edge detection only. By this fact we couldn't get the SPM communication between BCM and netX to run in interrupt driven mode stable. So polling is the only mode to drive the SPM interface today. The issue could get solved only in changing the kernel module responsible for the GPIO interface, but there is no intention from Hilscher in changing it at the current time.

The Linux kernels of all netPI versions are upgraded with a real time extension also known as RT patch. For more details read the documentation.

You can use those RT features on netPI as well in your containerized applications. For that reason we are providing a compilation of RT tests as example under the Docker image netpi-linux-rt-patch-tests ready for your download. Try the different precompiled test applications, understand them as they are described in the documentation link above and create your own later.

We have seen that latencies smaller than 100usec can be reached easily.