Corey-VR-01

The PCB is somewhat compatible with previous system, although a migration path exist to use the Machine Interface MCU instead (selectable via jumpers on the PCB).

Note that most legacy GPIO pins are expected to be migrated to be handled by the Machine Interface MCU, with the notable exception "Gas Sensor"

Raspberry Pi running Linux is not suitable for real-time (or near real-time) tasks. So there is a separate STM32F103CBT6 MCU to handle the inputs/outputs of the device. The MCU has 20kBytes of RAM and 128kB of Flash memory. The CM4 is connected via a serial port (UART4) and a protocol needs to be established.

None of the digital outputs are current limited, and they will most likely be destroyed if too much current is flowing. The exception is the RCMP that has a fuse that will blow, and need to be re-soldered in that case.

The following outputs are driven directly with power MOSFETs, capable of sinking 250mA and have a 1kΩ pull-up resistor to +5V. They are not driving any heavy load.

The following digital outputs are capable of driving additional loads.

The following digital inputs are MOSFET inputs, with ~1-2V threshold voltage.

Inter-Intergrate-Circuit (or I2C for short) is a well-established standard for communicating within a PCB or directly coupled (without cabling) PCBs. There are countless number of devices available on the market, and interoperability is extremely high. Physically I2C consists of Clock (SCL) and Data (SDA), both being pulled to VCC externally. Each device that are driving either of these lines are so called Open-Drain outputs, i.e. can only sink to GND. This means that it is possible to detect that multiple devices are trying to access the line at the same time, hence Multi-Master is possible, and utilized in Corey-VR-01 (more later).

Devices either have 7-bit addresses or 10-bit addresses, where the latter is not very common. Addresses are left-shifted by one, so they occupy Bit1 to Bit7 in the first byte being sent. Bit0 indicates whether a read or write operation will follow. This is a little bit unfortunate, as some vendors state the address without the left shift and some with the left shift. Most vendors includes bit-level diagram on which 1s and 0s are sent, and that is what to rely on.

The Colibri subsystem uses I2C to communicate with each of the IO Expandion slots. And to ensure that I2C address conflicts is not a problem, there is a TCA9548 I2C Multiplexer. Each IO slot has its own dedicated multiplexed I2C bus.

But then there is C_SCL0 and C_SDA0, that is the Bus0 on the TCA9548 and connects everything on the PCB itself. There are TWO masters for the TCA9548 and it is important that very strict access rules are in place. The Colibri MCU should be able to assume that it has full control of the I2C bus. For the CM4 to get access, a protocol over UART3 should exist where the CM4 tells the MCU to relinquish the control. This is important. Technically it is possible to instead put the MCU into BOOT mode, but not recommended.

The SPI bus is only accessible from the Colibri MCU as the master. Each IO Expansion slot has SPI connection and chip select for each. The PCB has a 128Mbit SPI flash memory for general-purpose use. The intention is to store code, parameters, configuration and/or collected data that are associated with the PCB (indirectly the machine) and not necessarily the CM4 (in case it needs to be changed). That could be name, id and/or location information, service data, malfunction codes and more.

The USB subsystem is fairly extensive, with 12 external USB ports plus a separate USB hub for the Colibri system with one USB going to each expansion card. Note that only the Colibri MCU can access the Colibri IO Expansion system directly. Each USB port has two LEDs, to indicate whether something is connected and whether it is "High Speed" (up to 480Mbps) or "Full Speed" (up to 12Mbps). The USB-C connector on the middle of the PCB is for loading boot image on the CM4. It can possibly be used for some service tasks, as USB OTG, but when it is connected, the CM4 is disconnected from the USB hubs on the PCB.

The PCB must have a voltage higher than 12VDC as input. The exact number various from unit to unit, but a safe value is that 15VDC is the guaranteed minimum input voltage. The maximum input voltage is a little bit more complicated. It depends on the ambient temperature, the load current on each regulator and the total load current on the whole device. Thermal analysis shows that at 60 ºC ambient temperature, the max input voltage is somewhere around 33VDC at max load current. At cooler than 30 ºC, 36VDC is the maximum voltage and doesn’t increase higher than that. 24VDC is the recommended input voltage.

Switching power supplies have the advantage that they preserve "power" as the voltage is converted up or down. So, if our 5V uses 4Amp, that is 20 Watts and that will require less than 1Amp at 24VDC input voltage. The efficiencies are depending on load current (goes up with higher load), so at maximum load current, the efficiencies in the LMR33630 that are used is ~95%, i.e. only ~5% will become heat. The PCB design is such that this heat is lead into PCB copper planes to dissipate. No forced cooling should be needed (experiments will be needed).

There are

The Carousel 2 expansion board is a second Machine Interface that can be plugged into the expansion socket on the lower half of the PCB. Functionality is identical to the Machine Interface with the following exceptions;

The Colibri system is a Bali Automation effort that was started before the creation of this PCB. It is a flexible I/O expansion system, with many I/O interfaces already available and more to come. Colibri is normally focused on LoraWAN communications and the primary MCU (MCU1) is a RAK3172 module, which in turn uses a STM32WLE5 MCU, that has the LoraWAN radio circuitry built-in. Colibri MCU2 and MCU3 are based on ESP32 MCUs and intended for ESPHome and Home Assistant users. Bali Automation will provide an additional MCU for VendingRobotics, based on STM32F103CBT6 to keep all MCUs in the system the same.

Bali Automation uses Mecrisp, a FORTH implementation for STM32 MCUs. This enables source code to be uploaded/stored on in the MCU, in each I/O module and on the carrier board’s memory. And source code can easily be uploaded via slow uplink, such as LoraWAN, or interactively via serial port.

Colibri has at the time of writing the following I/O modules available;