Vending Machine System Deployment with Raspberry Pi and STM32

Client: Premium fragrance vending startup

Role: Embedded systems engineering team

Duration: 12 weeks

Goal: Take a conceptual vending machine with minimal hardware and turn it into a reliable, publicly accessible commercial prototype with redundant fail-safe controls, RS232 spray integration, and payment initiation functionality.

The client had an enclosure, a RS232 enabled spray mechanism and a payment direction (Zettle/Swish), however was missing a complete embedded architecture that was cohesive.

The original proof of concept utilized loose wires connected to various components with manual triggers.

Our team provided a robust embedded system that consisted of a Raspberry Pi Compute Module 4 (CM4) plus an STM32 co-processor that provides a spraying response to trigger of <50ms, >99.8% actuation reliability over 10,000 test cycles and full manual override for safety purposes.

Instead of one microcontroller, we suggest a hybrid split architecture to address our goals:

Raspberry Pi CM4 (embedded Linux):

Handles top-level logic (i.e., facilitates payment processing, UI communication, remote monitoring, and transaction logging); and

STM32F103 co-processor:

Provides real-time control for spray timing, nozzle sequencing, button debouncing and watchdog supervision; and

RS232 isolation bridge:

Provides a galvanically isolated serial connection between the Raspberry Pi and the client-provided spray mechanism board.

This separation ensures that a UI crash or Python hang never prevents the spray from stopping or a safety shutdown. The architecture is field-proven for public-facing kiosks.

1. Integration of RS-232 Interface with Spray Control

The spray head from the supplier uses ASCII commands on RS232 (9600baud, 8N1). We could use a standard Pi UART, but we have added:

• MAX3232 level shifting to provide true RS232 levels.
• Opto-Isolator for RX and TX lines to avoid ground loops due to the 24v pump supply that powers the spray.
• Acknowledgment protocol for commands sent to spray unit. The spray unit will either respond with an OK or ERR. If the STM32 does not receive a response within 200ms then the STM32 will attempt to resend the command once before disabling the nozzle and flagging a fault to the cloud dashboard.

2. Payment Trigger Logic

The Zettle API operates via Ethernet on a Raspberry Pi. In the case of a successful payment:

• The Pi communicates to the STM32, over I2C, with the message SPRAY_ENABLE.
• The STM32 checks that the nozzle position sensor is correct, that the fluid level is appropriate, and that the system is not in manual mode.
• If everything is safe, it communicates to the spray controller, using RS232 ACTIVATE_NOZZLE 1.
• The spray time will always be 350ms (this was adjusted based on customer's testing with fragrance density).
• The STM32 returns a confirmation of completion (done) to the Pi along with the timestamp of when it was completed with millisecond accuracy.

The Pi logs the transaction and triggers an IoT heartbeat to a simple monitoring dashboard. Swish payments use a callback listener on the Pi that validates the payment reference before issuing spray.

3. Safety & Fail-Safe Systems (Critical for Public Use)

Manual backup mode:

A physical keyswitch on the enclosure, wired directly to the STM32's non-maskable interrupt pin, cuts off the Pi's enable line and forces the spray into a safe state. A separate "spray test" button allows manual override without payment – essential for maintenance and emergency refill procedures.

Watching System:

The STM32 expects a "keep-alive" signal from the Pi over I2C every two seconds, and if the STM32 doesn't receive the "keep-alive" signal from the Pi after 5 seconds (indicating a Pi crash or hang), the STM32 will assume control has been lost, turn off all outputs, and flash a red error LED.

Over Spray Prevention:

The STM32 monitors the current of the pump using an ACS712 Hall Effect Sensor. If the current exceeds 1.2 Amps (indicating the nozzle is jammed, clogged, or out of material), the STM32 will cut off power to the pump in less than 10 milliseconds—much faster than the delay caused by the Pi.

Nozzle Position Sensor:

Before allowing the nozzle to spray, a microswitch completes the signal that the nozzle has returned to its home, preventing spraying against the closed door or while performing maintenance on the sprayer.

4. UI and User Flow Integration

The client had a touchscreen UI concept running in a browser. We provided a lightweight Flask API on the Pi with endpoints:

• /api/status – returns system health (fluid level, door closed, payment ready, last fault code).
• /api/spray/{id} – triggered after successful Zettle or Swish callback.
• /api/manual/{on/off} – enables maintenance mode with password authentication.

The UI development team consumed these REST endpoints easily. All API calls are logged locally. During peak testing, the API handled 30 requests per second without delay.

5. Device Driver Coordination and Relationship between Hardware and Software

• Simple 2-layer PCB design
• STM32F103C8T6 (16MHz Crystal)
• Dual RS232 Ports (One for the spray feature, one for future expansion (e.g. addition of a 2nd nozzle or printer)
• Pi I2C Isolator: Si8600
• Power Regulator/Stabilizing: 24V input -> 12V spray pump -> 5V Raspberry Pi -> 3.3V STM32 (all have soft-start and resettable fuses)
• LED Indicators: Green-Power, Yellow-Spray Active, Red-Fault, Blue-Manually Driven

The firmware was created in bare-metal C with STM32Cube HAL using a deterministic state machine (Idle -> Ready -> Spray -> Complete -> Recovery) without the use of any RTOS, providing <1ms from trigger to interrupt for interrupt-driven peripherals.

The Pi is using Raspberry Pi OS Lite and has a Python application serving as the service to interact with for API and Payment Handling.

10,000 actuations over 4 days with varying payloads → 2 failures (RS232 noise due to a loose ground cable – resolved by adding CRC validation on commands and locking all connectors with screws).

Power loss recovery:

With respect to loss of power testing, when power has been restored, the System returns to an idle state; the Transaction History (Transaction logging) for the Raspberry Pi is stored in SQLite with writeahead logging. After testing 50 simulated power failures, zero corruption was observed.

Watchdog trigger test:

During the watchdog trigger test, two separate events were conducted where the Raspberry Pi was put into kernel panic (through simulation).

The STM32 successfully prevented payment from being accepted 5.1 seconds after receipt of the command for the Raspberry Pi to fire a spray, and until the system was reset manually using a keyswitch, using the same method as used in other tests, both tests passed.

Environmental Suited:

At 0 degrees and 40 degrees Celsius, the zero-cable was durable for both indoor venue testing as per client requirements with communications via RS232 proved consistent; RS232 data showed variable pump current of +/- 8%, well within the designated limits for operation.

Mechanical Button Debounce Testing:

To establish an accurate test program for road use buttons, 5000 presses of the mechanical venue buttons resulted in no false triggers after implementing both 50ms hardware and 50ms software debounce.

The architecture supports:

IoT monitoring:

MQTT bridge from Pi to AWS IoT Core – tracks spray count by nozzle, fluid refill alerts, and remote disable command.

Multiple nozzles:

STM32 has 3 unused GPIOs with PWM – can drive additional RS232 or solenoid-controlled heads without redesigning the PCB.

Firmware OTA:

Pi can flash the STM32 over I2C via a custom bootloader (designed but not deployed in V2; reserved for V3).

Telemetry dashboard:

Simple Grafana instance pulling from Pi's InfluxDB for maintenance teams to see real-time health of all deployed units.

• KiCad schematic and PCB layout files, (BOM Included).
• The C source code, from the STM32 firmware, with a complete fail-safe state machine.
• Raspberry Pi OS Lite image with a python service and Flask API, watchdog script, and auto-starts on boot.
• Integration test plan and safety checklist for public roll-out purposes.
• 10-page illustrated (e.g. "Using manual backup mode" & "RS232 Troubleshooting") field maintenance manual.
• Cloud Dashboard Prototype (Optional with instructions on setting up MQTT).

This project has evolved from a loosely defined prototype to a vending machine embedded system that is now ready for deployment.

Utilising the Raspberry Pi to handle the high-level logic and the STM32 for real-time safety, the resulting platform is a strong and maintainable system that can scale to hundreds of machines.

The Client has secured locations to pilot the machines at two gyms along with one airport lounge, and V3 is currently in development for additional sensors and remote fluid monitoring.

Component	Selection	Role
Main processor	Raspberry Pi CM4	Payment API, UI, logging, IoT
Co-processor	STM32F103C8	Spray timing, watchdog, safety, sensor reading
Spray interface	RS232 with opto-isolation	Nozzle actuation & status feedback
Safety override	Keyswitch + NMI pin	Manual mode, maintenance access, emergency stop
Payment systems	Zettle callback + Swish listener	Transaction validation and trigger
Monitoring	I2C watchdog + ACS712 current sensor	Fault detection & hardware fail-safe