Meditech: Networking architecture

[...]

These considerations were accomplished with a clear schematic image reported below

My point of view

The intuitive reason - and probably my decent knowledge on how the networks works - that the adoption of the SPI protocol is not the correct solution has been influenced by several aspects.

• Just because SPI is under software control while the LAN after the setting is managed by the system it is not a disadvantage but it seems a good way to develop the software in a more clean and linear way. When the Pi devices are correctly set, they can communicate following the established rules, with some dynamic variable elements then this a problem that can be forget. If something is not as expected the LAN settings can be modified until the system interconnects exactly as needed.
• As I have already worked with SPI almost intensively developing on-board components, I have privileged this kind of bus and always like those chips that can be controlled by the SPI bus. But nothing more, this is the case of different machines that should dialogate.
• To adopt the SPI bus - always remaining in a context of intuitive vision - seems to me like forcing the devices to do a taks with the wrong tool. As a matter of fact, this is a Serial Protocol Interface, probably slower and less performing in a context of multi-machine connection: this is just the role of the network. It seemed like a sort of step-back in technology.
• Then I have considered that if SPI is so reliable and works so well between microcontrollers and chips managing bounch of data between computers, with a 10/100 Ethernet unused it sounds really bad.

After the discussion mentioned above I have checked to see if these concepts was confirmed by more reliable documentation then my personal view.

The Serial Peripheral Interface or SPI-bus is a simple 4-wire serial communications interface used by many microprocessor/microcontroller peripheral chips that enables the controllers and peripheral devices to communicate each other. Even though it is developed primarily for the communication between host processor and peripherals, a connection of two processors via SPI is just as well possible.

[...]

The SPI Bus is usually used only on the PCB. There are many facts, which prevent us from using it outside the PCB area. The SPI Bus was designed to transfer data between various IC chips, at very high speeds. Due to this high-speed aspect, the bus lines cannot be too long, because their reactance increases too much, and the Bus becomes unusable. However, its possible to use the SPI Bus outside the PCB at low speeds, but this is not quite practical.

This is what I have found on almost all sites with tutorials explaining how the SPI protocol works and how it should be adopted. The text above is from this tutorial that I attach in pdf to this post for your convenience.

The most important reason to adopt the Ethernet connection

The most important reason that I have finally decided to adopt the Ethernet connection for the internal data flow is because as I mention i the previous posts Meditech is not a fixed system: it is conceived to work with a minimal set of probes organised in a multi-board Pi processors that must be able to accept other specific probes without nothing to be changed. The better solution I see for this kind of cases is that every unit when present share the same networked architecture.

Bridged networking

Then the network architecutre has been defined as follows:

• RPI Master hosts the bridge-util Linux utilities with the internal network assessed on the IP set 192.168.5.0/255 (the use of the 192.168.5 class is because it is a private network that it is very difficult that is managed by commercial routers)
• RPI Master include a DHCP server available for extra devices connected to Meditech in future, for any reason. These can be connected to the pre-existing architecture without changing nothing.
• RPI Master access to the Internet via the Wi-Pi and act as the master router of the Meditech internal wired Ethernet.
• RPI is also the LAN gateway.
• All the internal RPI have a static IP of the same 192.168.5.x class pointing to the RPI Master as their gateway
• All the Meditech RPI has the SSH enabled.

To make the architecture able to connect only with the desired access point the AP connection information are defined statically in the network configuration files. This can be parametrised if a different WiFi AP connection approach is needed.

If you are interested, take a look to the next chronological post where it is explained the command set used to enable the router-bridge on the RPI Master.