This repository contains hardware designs and software for implementing slave devices using the Maxim 1-Wire® protocol on the STM32 microcontrollers.
Hardware is licensed under the The TAPR Open Hardware License Version 1.0
Software, Firmware & Documentation is licensed under GPLv3
- Eclipse on Windows (may work on Linux, untested)
- System Workbench for STM32
- MBed
The libs directory contains source code for the OneWireSlave library.
The devices directory contains schematics, PCBs & firmware for the client devices.
A template schematic with the basics wired up.
A passive Y splitter that allows short CAT5 runs to be broken off the main bus. A typical use would be to allow a short run to be dropped down a wall to a sensor or switch panel. Optionally includes a DS18B20 for temperature sensing.
A partial implementation of the DS2408 in software, used for initial testing of the 1-Wire® protocol, but is otherwise unmaintained and unsupported.
A device that accepts 4 switches, and provides 4 solid state relays. A jumper allows the relays to operate independently, or forced to operate in on/off pairs (for roller shutter/projector screen control). Somewhat obsoleted by SoManySwitches.
A sub-16KB bootloader which allows devices that implement the Inferno Embedded commands to update firmware over the bus. The included STM32F030X8.ld linker file stores the bootloader at the start of the flash region. Firmware that is designed to be flashed with this uses a modified linker file that stores the firmware with a 16kB offset.
Inferno Embedded commands allow the device to be rebooted into the bootloader so that they can be updated. The device can also be forced to remain in bootloader mode by shorting SWDAT on the SWD header to GND with a jumper.
A device with 8 RJ45 jacks, which each permit 6 toggle or momentary switches to be connected to the 1-Wire® network. The device will be alarmed when a switch is activated, and can then be polled to identify which switch was activated.
A daughterboard for SoManySwitches, designed to be installed at the switch point. The RJ45 socket is broken out into pairs of Gnd/Switch, and pullup/pulldowns are provided to suppress spurious switch activations.
A device that controls up to 8 24VAC air conditioning dampers, following the PolyAire pinout:
| RJ45 Pin | Signal |
|---|---|
| 1 | N/C |
| 2 | Open |
| 3 | Open |
| 4 | Neutral |
| 5 | Neutral |
| 6 | Close |
| 7 | Close |
| 8 | N/C |
By setting the transition time for each damper, the controller can partially open them, allowing balancing to be achieved via software control.
A device to control up to 4 channels of common-anode RGBW LED strips, at up to 48V. Fading from the current colour to a new one is handled locally. An external relay can be driven via the Inline SSR board, allowing the LED power supply to be shut down when no strips require power.
A small board with a solid state relay installed, designed to be mounted inline in a power cord. It connects to other boards via a headphone cable.
This software has been developed and tested on the STM32F030R8 microcontroller, an ARM Cortex-M0 with 64kB of flash & 8kB of RAM. We are running it at 48MHz using the internal RC oscillator. It may be possible to reduce the clock speed, but this is untested. They can be purchased for around AUD$1 each on Aliexpress.
Prototype testing can be performed on a Nucleo-F030R8.
A single GPIO from the microcontroller is used to communicate over the 1-Wire® protocol. This is typically pin F0.
| RJ45 Pin | Signal |
|---|---|
| 1 | Gnd |
| 2 | +5V |
| 3 | Gnd |
| 4 | 1W Data |
| 5 | Gnd |
| 6 | N/C |
| 7 | +24V |
| 8 | Gnd |
The library sits on top of the Mbed runtime, altough it is more reliant on the lower level HAL APIs than the Mbed constructs. The bootloader uses a cut-down version of the runtime to allow it to fit within 16kB, however, the cost is that it cannot print to the serial port.
This file contains the base class for implementing 1-Wire® protocol devices. It provides methods to send and receive data on the bus, and handles device enumeration. It consumes Timer6 which it uses to maintain a 1 uS timer for signal timing. It uses the low level HAL APIs for catching state changes on the GPIO line, as the InterruptIn class added too much latency.
This file defines how InfernoEmbedded devices communicate over 1wire. Each device reports a 64 bit type and 64 bit version, so only a single 1-Wire® family code is used (FE).
1wire commands are issued as follows: Master: Command Code (1 byte), Command data (up to 8 bytes), CRC8
Slave: Command good/bad (1 byte)
Slave: device response (chunks of up to 8 bytes)
Or...
Master: Streaming data
A 64 bit status register is provided, and the device will show up in alarm scans if any bits are set. On powerup, bit 0 is set (Power-on), allowing the devices to be reinitialised if they need state from the master. The status register is cleared automatically after each read.
These files provide the device specific implementations. They define the 1-Wire® commands that are accepted, and interact with the user code via Listener classes. to allow designs to scale, the driver will report the number of implementations it supports (eg. switches), so that many physical variants can share the same code.
- Install Eclipse for C/C++ development
- Install System Workbench for STM32 Eclipse plugins
- Clone the mbed sources
git clone https://github.com/ARMmbed/mbed-os.git Build the arm-nano-eabi toolchain by running build.sh in the toolchain directory- Fetch the ARM official toolchain by running build-arm.sh in the toolchain directory
- use the scripts build.(bat|sh) and build-trace.(bat|sh) in the mbed directory to build the thin or trace-enabled builds of Mbed
- Import the mbed Eclipse project
- Import the Eclipse projects from this repository
These will be useful during development
- SWD Programmer
- Sigrok compatible logic analyser
- Nucleo-F030R8
First, consider whether one of the existing device level drivers will do what you need, or can be expanded to achieve your goals (without straying too far from the intent of the driver). If you need to expand it, increment the version so that the client software (eg. OWFS) can identify what commands are available.
Next, create a frontend project that interacts with the device level driver. You may initially want to use a listener that uses the TRACE() macro rather than interacting with the hardware until you are happy with the protocol.
Finally, submit patches to OWFS that implement the new device driver. You can look at owfs/owlib/src/c/ow_ie_*.c to see how the existing drivers work. Important to note are the visibility functions, which allow a single family code to appear as many different devices.