Will upload proper pictures later…

Received the PCB’s for the Lab PSU yesterday and soldered up the boards. The Regulator works fine – I was only able to test it with 5A at which point I burned the transistors due to overheating. That was with 30V in and 6V out so we dissipate ca 24*5 = 120W – or 60W on each TIP3055. Without heat-sink that was just to much, so I need to mount heat-sinks and fan’s before I continue + it’s a bit on the extreme to test test this design with 24V drop over the TIP’s.

I am not sure about the current limiter on this – I could not see it having much effect, but I was not able to test properly either. The principle is simple – you apply voltage measured over shunts to pin 2&3 and LM723 should limit VOut.

I initially also burned the wires in, but replaced them with thicker wires and things work fine. The PCB lanes seems to be fine, but I won’t know for sure before I am able to run 10A for longer periods.

A classic PLC design tend to use what we call “Remote IO”. We basically have a top-side control system that read some input and control some output through a “long wire”. The PLC itself contains little or no intelligence. This design have a legacy from days where CPU power was a limitation, but it is still very popular because it is simple and in many cases sufficient.

The drawing above illustrate Remote IO using a light switch PLC style. As we change the switch the signal will be sent all the way to top-side where logic decide that we need to set the light on/off and the signal is sent all the way back down.

This drawing illustrate a modern approach with distributed processing as implemented in Plain. In this case we only use top-side to control the behaviour of logic executing on the device.

Distributed processing is little supported in PLC languages, so this have more or less been the domain of advanced systems written in languages where we write logic per device. In this case we would need complementing software on 4 devices (top-side, 2 x Hub’s and the device). Plain simplify this to a single small application where the user easily can decide wherever processing should happen top-side or distributed.

Just an update on the backbone board. I have decided to use a “All-In-One” central for home automation, but I still want to make a minimized PLC alike system. This backbone is very small – only 50mm width and 65mm height. The connectors are basically so tight with only ca 6.3mm apart that we are not likely to use every slot. I considered making it larger, but decided against it because the primary target here is mobile robotics. The connectors give me the option to use 1, 2, 3, 4 or even more slot width on a single card + I can add backbone board by having a board to board cable.

The main difference is that I ditched the A and B PSU signals and use a wider, combined lane to increase available ampere. I also add drill holes for each board. I am still a bit undecided about how I connect this to the PSU etc. I will be back on that.

This last picture illustrate the new power lanes. Wide tracks on both sides to support higher currents. The weak point is however how to connect this to a PSU. At present I would use a 40 pin connector and 4 cables per voltage – I need to think about that. One option is to add screw connectors etc. I will not order this board before I have a PSU design + some add-on boards, so we can let the ideas mature a bit.

Finally got the PCB’s for the Universal Motor Controller, so we will have some fun the next days. Sadly I also instantly realise a few mistakes. The holes in the adapter board is to small for the capacitors I bought, but I can manage by using a small drill to widen some holes. Comparing the actual board with the 3D model is always a surprise. This board is smaller and tighter than I expected, so I am sure we will need to do some mechanical adjustments – but, well that’s part of the game.

I have written a lot about the intentions with easyIPC so it’s time we dig into the details of the protocol. easyIPC will follow the OSI model on a pragmatic level as illustrated below.

Smart SPI, RS-X and CAN-X are layer 2 links. Their only responsibility is to transport generic data between two nodes and maintain that link.

Stream routing is a small layer that will look-up DID & SID, replace them and forward messages either to a different Link or to an application.

Managing Entity is a database maintaining status over the tree of devices and it’s resources. This is the more complex part where we provide plug & play, dynamic resource allocation, redundancy and all the complex features in easyIPC.

The API is a thin layer interfacing easyIPC into various applications and programming languages. On Linux this will be running as a daemon (Service on Windows) with applications connecting as they start/stop. On an embedded device we use a tighter technique written in C/C++.

Watch out for updates on the doc pages.

Smart SPI is a Layer 1 – 2 protocol using SPI to establish a direct communication link between Raspberry PI and Hat’s. SPI itself is a bit oriented full duplex protocol where the master control the speed by ticking a CLK signal. For every cycle on the clock we transfer a bit on both MOSI and MISO. Using SPI in 1:1 we only need GND, MOSI, MISO and CLK, but a CS (Chip Select) is needed for communication with several devices.

In a classic SPI design we would set a Chip Select pin and communicate with that device, select the next and communicate with that in a sequence.

All easyIPC aware Raspberry PI Hat’s use a technique called “Smart SPI” that implement several tricks to optimize SPI usage.

• The stream on MOSI include target address allowing 8 Hat’s to read the message and filter out the messages they want to see. This allows Linux to send continuous on SPI without doing a bit-bang on CS pins that would slow down sending.
• The message stream also include a Chip Select Message in software. As this is read by all Hat’s only the Hat selected will activate MISO. This allows the RPI driver to select MISO independent from MOSI stream.
• MISO Send algorithm will enable Hat’s in sequence and automatically switch to the next after 1ms or as soon as the Hat report 0 messages. Bit padding is supported on both MOSI and MISO to complete a message.

Start-Up Procedure

The Start-Up procedure consist of a sequence of operations that must be executed as the system is powering on. The Hat’s will at this time not know their own Hat-number and as such not be able to communicate using Smart SPI.

1. We Set Chip Select to 1 and send Device Identification Request with number “1”. The Hat that see it’s CS enabled will consume this message and set it’s id to 1. All others will ignore the message.
2. The Hat will respond with a short Device ID Response. This is a short message to tell the master that the device is active. Master will on a slower scheme attempt to send Device Identification request to device numbers that are not active to enable Hat’s at a later point. Device ID Response tell the Master that the device is active and ready to communicate using Smart SPI.

Normal operation

1. Once a full iteration through all 8 Hat’s are completed we start using Smart SPI. The Master will on regular intervals continue to send Device ID Request to Hat’s that’s not active. If a Hat fail to answer normal messaging it will be moved to Non-Active list until Master can perform a successfully ID request.

Note that the full start-up procedure for easyIPC consist of other sequences, but Smart SPI is a layer 2 link only responsible for sending/receiving between Raspberry PI and the Hat’s. See easyIPC for the higher level start-up procedure.

Smart SPI Message format

Length is a 8 bit unsigned integer that indicate the total length of the message in bytes. Minimum length value is 6 bytes since minimum payload is 1 byte. Payload length = Length-5.

DID (Device ID) is a physical address needed by layer 2 for message transfer. This is always the device ID. MOSI will contain the destination ID, MISO will contain the Source ID.

DID=0 is used for broadcast. Device 1-31 is a physical Device #.

SID (Stream ID) is the ID of a point to point stream. Stream 0 is always the device and layer 2 link. Stream is used for internal addressing on a node.

SEQ (Sequence Number) is a 1 byte number that start on 1 and wrap at 255. The value 0 is used for none-sequence. Each side in a Smart SPI need to remember the last messages sent and be able to repeat them on request. The receiver will verify that the SEQ increment with one, and if not issue a MessageMessage Repeat Request. MISO Switch Request also contain the last message received in case the last message was cut short. Sequence is unique per device and only intended to guarantee that all messages are transferred.

MID (Message ID) is actually the first byte in the payload. The meaning of the payload needs only be known by the stream end-points.

Payload is the actual message parameters/data.

CRC is a 2 byte CRC to ensure message integrity.

Device ID Request

Device ID Request is sent to a device that also will be selected by a Chip Select pin. Any device receiving this with CS set to 1 will accept this as it’s ID and respond with Device ID Response. The device will accept the address in the DID field as it’s address

The device ID procedure will send a Device ID Request on MOSI and then start padding with zero’s for a selected response time of x ms. The device needs to respond within this time or it will be marked as inactive and not included in the active iteration.

Master will attempt to re-connect to inactive devices ca once per sec.

Device ID Response

Device IS response is send by a device that receive Device ID request while chip select is active. This indicate that the device have received it’s address and established a link capable of communicating on Smart SPI.

Devices that fail to respond before Chip Select goes 0 (Zero) will be listed as inactive. SPI will always have a number of fixed slots that in theory is max 31, but the current limitation on Hat’s are 8.

Inactive Devices are listed separately and Master will use Idle time to attempt to re-connect to devices. See Device ID Request.

MISO Switch Request

MISO Switch Request is used to switch MISO Sender. All devices will set MISO to 3-state and stop communicating. The device currently sending will finish it’s current message and stop.

The Switch procedure contain a programmatic delay intended for the sending device to detect and abort it’s sending. Once that times out the new device will assume the MISO is available and start sending.

MISO Switch Response

MISO Switch Response is sent after a delay needed to secure that the sending device stops. This is sent from the new device and indicate the current queue length. The next message is the first message in the queue.

Message Repeat Request

A repeat request is issued to repeat 1-2 missing messages. The response will either be messages repeated or a Message Repeat Reject if the sender is unable to repeat the messages.

Message Repeat Reject

Sent in response to a Message Repeat Request if one side is unable to repeat the messages. Can happen if the gap in sequence is to large.

Link Reset

Issued by both sides to reset sequence numbering. Used as a response to errors.

See documentation page for an updated Version of this post…

I initally hoped to test rev 1.0 of this Controller back in february, but as often happens with hobby plans – they get delayed because of real life. I am still waiting for the PCB’s on 1.0, but I am already starting the planning for rev 1.1.

• Testing the design on 11.1V battery.
• Testing power and heat under full load.
• Testing spike tolerance.
• I am not fully happy with connectors, their size and location. Need to evaluate if we can improve this.
• SWD needs to be moved/turned a little.
• RS485 should be upgraded to galvanic isolated version. This is a challenge as I need physical space.
• I am considering tilting the MCU 45 degrees left because a lot of PCB lanes would then be Shorter. It could save some Space.

I was considering 48V and more current, but the truth is that we then start moving towards specialized needs that is better handed as such due to the effects involved.

CAN or Ethernet is still an option. Despite having advocated CAN and written CAN stacks in the past – I am not a fan of CAN. RSX is better for many reasons. I would love Ethernet, but the truth is Ethernet wiring and need for switches is a drawback in robotics. I will consider an add-on option for communications, but I am actually happy with RSX because it is robust, flexible and easy. For now I assume I have to wait 1-2 weeks 🙁

Final 3D model with TVS diodes added. This is not the most Advanced Hat, but it enables me to use a Raspberry PI With long wiring and motors in the network without too much worries.

I used a little trick on the 3-port Galvanic RSX as I connect to ground through the ground layer on layer 0. If you look at the area marked in green this is part of the ground, but the EDA don’t warn me that this is an iceland isolated from actual ground. I added a connection (in yellow circle) to fix the issue.

Just a reminder that an EDA is only a tool. It might contain snags so it’s up to yourself to actually check what it is doing.

I made a 5 port (3 port RS485 and 2 port CAN) earlier that is great, but I want a version that is galvanic isolated for solutions that require wiring around a house or more hash environments. ADM2582E is a “All-In-One” package for this, so using 3 of these I get a 3-port RS485 will full isolation. This will cost ca 15.- USD more than the plain one due to the more expensive isolation chips, but those bucks are worth it.

The 3D model above is a bit premature, but it gives you an idea of how the Hat will look like. I have also included a snip of the PCB to illustrate the galvanic isolation.

I have not connected the 3 ports to the MCU yet as I basically wanted to see if I could achieve 3 ports with proper spacing. I am actually quite happy with the result. The 4 red areas are ground. As we have isolation it means that each port have it’s own isolated ground completely separate.