BitWizard Wiki - User contributions [en]

Dmx interface for raspberry pi

2025-12-20T12:00:16Z

Rew: /* output mode */

= Introduction =

[[File:DMX_case_complete.jpg‎|thumb|DMX with case]]

The [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi '''DMX interface for raspberry pi'''] allows you to interface a raspberry pi with DMX hardware.

There is also [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi-with-usb-(FT245RL) a version "with FT245"]. That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

= Software =

There are several software packages that can be used with your '''DMX interface for Raspberry pi'''.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

== DMX input on Linux ==

The Unix-derived way of handling tty/uart makes it impossible to do DMX input from userspace. So this option has existed in the hardware for ages, but for Linux there was no software support for DMX input.

I have recently (september 2024) written a driver for the UART in userspace that will actually do DMX input and deliver the DMX universe as a memory mappable file. From there it is easy to export it say to OLA, and hopefully QLC+.

This is a hardware driver, so it depends on the hardware. I've tested it on raspberry pi 3, and that works. I expect minor changes for other versions. It is not worth my trouble if nobody uses it, so if you need it, please let me know. I'll then make sure it works on YOUR raspberry pi and write some more documentation.

== QLC+ and OLA ==

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

=== QLC+ ===

Harold van Hulten wrote a nice "howto". .... link is dead :-( See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

==== our tests ====

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:
https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5
but with one addition:
apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit
plugins/plugins.pro

to remove the hash on the line with "uart" so that it reads:
!macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

=== OLA ===
==== bullseye ====

It seems that once again the stock OLA distribution has a problem with the uartdmx plugin.

To simplify a few steps I recommend to just install ola from the distribution.
We won't use the actual olad binary, but it arranges a few things that are useful.

First this installs the scripts to have ola start at
system boot. Also this will add the olad user we need to run the daemon under.
We do this before compiling
and installing ola from source so that our freshly compiled ola will overwrite
the system binaries with a working one.

To compile ola from scratch from the github current version first install the dependencies:

If you haven't already done so, edit /etc/apt/sources.list

sudo nano /etc/apt/sources.list

and remove the # before deb-src, which is probably the third and last line. Then:

sudo apt build-dep ola

then get the sources:

git clone https://github.com/OpenLightingProject/ola.git

The ola deamon should run under user "olad". Adding that is simple enough:

sudo adduser --system olad

Then configure, build and install:
cd ola
autoreconf -i
./configure --prefix=/usr
make -j4
sudo make install

The build step will take about 20 minutes on a pi4 with a fast SD card. (at least,
that's what happened on mine :-) )

Next I had to add the olad user to the group tty to allow it to write to the device:

sudo adduser olad tty

FYI: A non-working olad (the one in the bullseye distribution) will report
plugins/uartdmx/UartWidget.cpp:180: Failed to set baud rate to 250k
while a working one will report:
plugins/uartdmx/UartDmxThread.cpp:136: Granularity for UART thread is GOOD

Also FYI: The build in bullseye has defines and build flags that result in the baud-rate-setting
code thinking that the calls needed to set the baud rate are not available. In the latest
ola version the conditions that cause the code to think it isn't available have changed a bit
and the "we can't change the baud rate because at compile time the calls weren't available"
code now prints an error message instead of just returning: "couldn't change it for some reason"
resulting in the above "failed to set baud rate" message without further explanation.

If I've missed a step when you try this, let me know.
(also let me know if all this was not necessary on your system, and say your distribution's ola worked.
This hopefully happens in a future debian/raspberry pi OS version).

==== stretch ====

The distribution ola works on Stretch. ''sudo apt-get install ola'' should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

==== Jessie ====
On raspbian jessie installing OLA is easy: ''sudo apt-get install ola'' should do the trick. <s>The downside is however that it doesn't work :-( . </s>

'''update:''' The simple option seems to work now. :-) '''update2:''' Some hints are that it still doesn't work. :-(
Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

<span style="color:#808080">
what does work however is:
#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure
make -j 5 all
sudo make install
<span style="color:#808080">
There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )
</span>

==== wheezy ====
On Wheezy, adding
deb http://apt.openlighting.org/raspbian wheezy main
to ''/etc/apt/sources.list'', and then the ''apt-get install ola'' should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

==== raspberry pi 3 and pi 4 ====

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:
dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:
* change baudrate unexpectedly when the CPU feels hot.
* I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

==== all raspberries ====

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like '''console=ttyAMA0,115200''' there, remove that whole '''console=''' entry. Try not to mess up the rest of that line.

Most importantly: add:
init_uart_clock=16000000
to your config.txt file in the /boot directory. In my tests today (2023) I had a different number on my screen when I was doing this. I used 3x more: 48000000. This works as well (on a rpi4).

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in ''/etc/ola/conf/'', on others ''/var/lib/ola/conf/'', and in some cases: ''/root/.ola/ola-uartdmx.conf'' or ''/home/pi/.ola/ola-uartdmx.conf''. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add ''/dev/ttyAMA0-break = 100'' and ''/dev/ttyAMA0-malf = 100'' . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

==== output mode ====

Then set the board to output mode This is done by making GPIO18 an output and programming it to be high.

The raspberries over the years have had various methods to influence the GPIO pins of the CPU running the show. In case they change it again it might be necessary to google for how to do it from now on. If you find I need to update this again, a tip is appreciated! (Thanks Richard!).

On the most recent operating system releases, it seems you can configure the GPIO pin to be output-high, once and for all by adding:

gpio=18=op,dh

to /boot/firmware/config.txt . On older OS releases:

I would recommend creating a small script (''sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode'') :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then
echo "$0 : on or off?"
exit 1
fi

if [ ! -d $gpio ] ; then
echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:
sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (there is an "exit 0" in there, so put it BEFORE that!)

Or you can install the gpio utility from wiringpi. However this now seems unmaintained and hard-to-get and possibly it doesn't even work on modern pi's. But if it works on your pi the following command allows you view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO 18 pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized ''I'' was getting away with this.... :-) )

= Hardware =

== used hardware pins ==

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

== jumper settings ==

The jumper block has three (sensible) jumper positions, they can be either on or off.
(We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

== Case ==

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

[[Assembling_the_DMX_case]]

STM32 development board

2025-11-17T13:33:50Z

Rew: /* introduction */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

For those who want to design an add-on board, the connector positions are given in mil. Mil is 0.001 inch and the postions are referenced on the bottom left corner of the PCB.
The mounting holes are 3.0 mm and located at 3,3 mm, 3,47mm, 47,3mm and 47,47mm. The PCB is 50x50 mm.

A "technical drawing" of the board is available here: https://bitwizard.nl/wiki/index.php/File:Stm32_devel_bordje.png

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

Position of this connector: X 1850, Y 425 mil. (you may want to know this if you are designing an addon board that requires both 5V and 3.3V.

=== UART ===

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

Position of this connector: X 1475, Y 100 mil.

=== I2C1 ===

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 500 mil.

=== I2C2 ===

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 300 mil.

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

File:Stm32 devel bordje.png

2025-11-17T13:32:22Z

Rew: STM32 development board. Board outline and sizes (most in mil, some in mm where indicated.)

== Summary ==
STM32 development board. Board outline and sizes (most in mil, some in mm where indicated.)

STM32 development board

2025-11-17T12:10:12Z

Rew: /* SV2 */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

For those who want to design an add-on board, the connector positions are given in mil. Mil is 0.001 inch and the postions are referenced on the bottom left corner of the PCB.
The mounting holes are 3.0 mm and located at 3,3 mm, 3,47mm, 47,3mm and 47,47mm. The PCB is 50x50 mm.

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

Position of this connector: X 1850, Y 425 mil. (you may want to know this if you are designing an addon board that requires both 5V and 3.3V.

=== UART ===

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

Position of this connector: X 1475, Y 100 mil.

=== I2C1 ===

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 500 mil.

=== I2C2 ===

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 300 mil.

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T12:10:00Z

Rew: /* I2C2 */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

For those who want to design an add-on board, the connector positions are given in mil. Mil is 0.001 inch and the postions are referenced on the bottom left corner of the PCB.
The mounting holes are 3.0 mm and located at 3,3 mm, 3,47mm, 47,3mm and 47,47mm. The PCB is 50x50 mm.

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

Position of this connector: X 1850, Y 425 mil. (you may want to know this if you are designing an addon board that requires both 5V and 3.3V.

=== UART ===

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

Position of this connector: X 1475, Y 100 mil.

=== I2C1 ===

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 500 mil.

=== I2C2 ===

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 300 mil.

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T12:09:55Z

Rew: /* I2C1 */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

For those who want to design an add-on board, the connector positions are given in mil. Mil is 0.001 inch and the postions are referenced on the bottom left corner of the PCB.
The mounting holes are 3.0 mm and located at 3,3 mm, 3,47mm, 47,3mm and 47,47mm. The PCB is 50x50 mm.

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

Position of this connector: X 1850, Y 425 mil. (you may want to know this if you are designing an addon board that requires both 5V and 3.3V.

=== UART ===

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

Position of this connector: X 1475, Y 100 mil.

=== I2C1 ===

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 500 mil.

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 300 mil.

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T12:09:47Z

Rew: /* UART */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

For those who want to design an add-on board, the connector positions are given in mil. Mil is 0.001 inch and the postions are referenced on the bottom left corner of the PCB.
The mounting holes are 3.0 mm and located at 3,3 mm, 3,47mm, 47,3mm and 47,47mm. The PCB is 50x50 mm.

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

Position of this connector: X 1850, Y 425 mil. (you may want to know this if you are designing an addon board that requires both 5V and 3.3V.

=== UART ===

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

Position of this connector: X 1475, Y 100 mil.

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 500 mil.

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 300 mil.

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T12:02:03Z

Rew: /* introduction */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

For those who want to design an add-on board, the connector positions are given in mil. Mil is 0.001 inch and the postions are referenced on the bottom left corner of the PCB.
The mounting holes are 3.0 mm and located at 3,3 mm, 3,47mm, 47,3mm and 47,47mm. The PCB is 50x50 mm.

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

Position of this connector: X 1850, Y 425 mil. (you may want to know this if you are designing an addon board that requires both 5V and 3.3V.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

Position of this connector: X 1475, Y 100 mil.

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 500 mil.

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 300 mil.

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T11:44:34Z

Rew: /* IO voltage */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

Position of this connector: X 1850, Y 425 mil. (you may want to know this if you are designing an addon board that requires both 5V and 3.3V.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

Position of this connector: X 1475, Y 100 mil.

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 500 mil.

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 300 mil.

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T11:34:34Z

Rew: /* I2C1 */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

Position of this connector: X 1475, Y 100 mil.

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 500 mil.

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 300 mil.

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T11:34:21Z

Rew: /* I2C2 */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

Position of this connector: X 1475, Y 100 mil.

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

Position of this connector: X 1475, Y 300 mil.

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T11:33:52Z

Rew: /* I2C2 */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

Position of this connector: X 1475, Y 100 mil.

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

Position of this connector: X 450, Y 300 mil.

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T11:33:21Z

Rew: /* UART */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

Position of this connector: X 1475, Y 100 mil.

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T11:32:37Z

Rew: /* SPI */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450, Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T11:32:22Z

Rew: /* SWD */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450 Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Position of this connector: X 1850, Y 1025 mil.

STM32 development board

2025-11-17T11:31:38Z

Rew: /* SV2 */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450 Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100 mil.

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

STM32 development board

2025-11-17T11:31:25Z

Rew: /* SV3 */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450 Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 775, Y 1825 mil .

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

STM32 development board

2025-11-17T11:30:51Z

Rew: /* SV2 */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450 Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

Position of this connector: X 125 Y 1100

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

STM32 development board

2025-11-17T11:30:07Z

Rew: /* SPI */

== introduction ==

The BitWizard STM32 development board is an STM32F072 development board that is a bit more compact than the ST Nucleo boards.

It differs from the Nucleo in that it does not try to break out EVERY pin of the chip, just a useful subset. Some pins that have I2C, SPI, or UART functionality are broken out on connectors specifically tailored for that use case. Many other GPIO pins are broken out on standard 2x10 headers.

The board is available for purchase "on request". It cannot compete with the ST Nucleo boards (on price). But if you want one shoot us an Email and we'll sell you one (or more).

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

=== SPI ===

See elsewhere on this site for the SPI functions of this connector.
It is connected to PB12-15.

Position of this connector: X 450 Y 150 mil.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

STM32 development board

2025-11-17T10:32:46Z

Rew:

Dmx interface for raspberry pi

2025-10-09T14:08:16Z

Rew: /* QLC+ */

= Introduction =

[[File:DMX_case_complete.jpg‎|thumb|DMX with case]]

The [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi '''DMX interface for raspberry pi'''] allows you to interface a raspberry pi with DMX hardware.

There is also [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi-with-usb-(FT245RL) a version "with FT245"]. That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

= Software =

There are several software packages that can be used with your '''DMX interface for Raspberry pi'''.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

== DMX input on Linux ==

The Unix-derived way of handling tty/uart makes it impossible to do DMX input from userspace. So this option has existed in the hardware for ages, but for Linux there was no software support for DMX input.

I have recently (september 2024) written a driver for the UART in userspace that will actually do DMX input and deliver the DMX universe as a memory mappable file. From there it is easy to export it say to OLA, and hopefully QLC+.

This is a hardware driver, so it depends on the hardware. I've tested it on raspberry pi 3, and that works. I expect minor changes for other versions. It is not worth my trouble if nobody uses it, so if you need it, please let me know. I'll then make sure it works on YOUR raspberry pi and write some more documentation.

== QLC+ and OLA ==

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

=== QLC+ ===

Harold van Hulten wrote a nice "howto". .... link is dead :-( See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

==== our tests ====

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:
https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5
but with one addition:
apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit
plugins/plugins.pro

to remove the hash on the line with "uart" so that it reads:
!macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

=== OLA ===
==== bullseye ====

It seems that once again the stock OLA distribution has a problem with the uartdmx plugin.

To simplify a few steps I recommend to just install ola from the distribution.
We won't use the actual olad binary, but it arranges a few things that are useful.

First this installs the scripts to have ola start at
system boot. Also this will add the olad user we need to run the daemon under.
We do this before compiling
and installing ola from source so that our freshly compiled ola will overwrite
the system binaries with a working one.

To compile ola from scratch from the github current version first install the dependencies:

If you haven't already done so, edit /etc/apt/sources.list

sudo nano /etc/apt/sources.list

and remove the # before deb-src, which is probably the third and last line. Then:

sudo apt build-dep ola

then get the sources:

git clone https://github.com/OpenLightingProject/ola.git

The ola deamon should run under user "olad". Adding that is simple enough:

sudo adduser --system olad

Then configure, build and install:
cd ola
autoreconf -i
./configure --prefix=/usr
make -j4
sudo make install

The build step will take about 20 minutes on a pi4 with a fast SD card. (at least,
that's what happened on mine :-) )

Next I had to add the olad user to the group tty to allow it to write to the device:

sudo adduser olad tty

FYI: A non-working olad (the one in the bullseye distribution) will report
plugins/uartdmx/UartWidget.cpp:180: Failed to set baud rate to 250k
while a working one will report:
plugins/uartdmx/UartDmxThread.cpp:136: Granularity for UART thread is GOOD

Also FYI: The build in bullseye has defines and build flags that result in the baud-rate-setting
code thinking that the calls needed to set the baud rate are not available. In the latest
ola version the conditions that cause the code to think it isn't available have changed a bit
and the "we can't change the baud rate because at compile time the calls weren't available"
code now prints an error message instead of just returning: "couldn't change it for some reason"
resulting in the above "failed to set baud rate" message without further explanation.

If I've missed a step when you try this, let me know.
(also let me know if all this was not necessary on your system, and say your distribution's ola worked.
This hopefully happens in a future debian/raspberry pi OS version).

==== stretch ====

The distribution ola works on Stretch. ''sudo apt-get install ola'' should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

==== Jessie ====
On raspbian jessie installing OLA is easy: ''sudo apt-get install ola'' should do the trick. <s>The downside is however that it doesn't work :-( . </s>

'''update:''' The simple option seems to work now. :-) '''update2:''' Some hints are that it still doesn't work. :-(
Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

<span style="color:#808080">
what does work however is:
#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure
make -j 5 all
sudo make install
<span style="color:#808080">
There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )
</span>

==== wheezy ====
On Wheezy, adding
deb http://apt.openlighting.org/raspbian wheezy main
to ''/etc/apt/sources.list'', and then the ''apt-get install ola'' should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

==== raspberry pi 3 and pi 4 ====

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:
dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:
* change baudrate unexpectedly when the CPU feels hot.
* I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

==== all raspberries ====

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like '''console=ttyAMA0,115200''' there, remove that whole '''console=''' entry. Try not to mess up the rest of that line.

Most importantly: add:
init_uart_clock=16000000
to your config.txt file in the /boot directory. In my tests today (2023) I had a different number on my screen when I was doing this. I used 3x more: 48000000. This works as well (on a rpi4).

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in ''/etc/ola/conf/'', on others ''/var/lib/ola/conf/'', and in some cases: ''/root/.ola/ola-uartdmx.conf'' or ''/home/pi/.ola/ola-uartdmx.conf''. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add ''/dev/ttyAMA0-break = 100'' and ''/dev/ttyAMA0-malf = 100'' . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

==== output mode ====

Then set the board to output mode. I would recommend creating a small script (''sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode'') :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then
echo "$0 : on or off?"
exit 1
fi

if [ ! -d $gpio ] ; then
echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:
sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (there is an "exit 0" in there, so put it BEFORE that!)

Or you can install the gpio utility from wiringpi. However this now seems unmaintained and hard-to-get and possibly it doesn't even work on modern pi's. But if it works on your pi the following command allows you view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO 18 pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized ''I'' was getting away with this.... :-) )

= Hardware =

== used hardware pins ==

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

== jumper settings ==

The jumper block has three (sensible) jumper positions, they can be either on or off.
(We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

== Case ==

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

[[Assembling_the_DMX_case]]

Dmx interface for raspberry pi

2024-09-10T18:47:35Z

Rew: /* DMX input on Linux */

= Introduction =

[[File:DMX_case_complete.jpg‎|thumb|DMX with case]]

The [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi '''DMX interface for raspberry pi'''] allows you to interface a raspberry pi with DMX hardware.

There is also [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi-with-usb-(FT245RL) a version "with FT245"]. That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

= Software =

There are several software packages that can be used with your '''DMX interface for Raspberry pi'''.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

== DMX input on Linux ==

The Unix-derived way of handling tty/uart makes it impossible to do DMX input from userspace. So this option has existed in the hardware for ages, but for Linux there was no software support for DMX input.

I have recently (september 2024) written a driver for the UART in userspace that will actually do DMX input and deliver the DMX universe as a memory mappable file. From there it is easy to export it say to OLA, and hopefully QLC+.

This is a hardware driver, so it depends on the hardware. I've tested it on raspberry pi 3, and that works. I expect minor changes for other versions. It is not worth my trouble if nobody uses it, so if you need it, please let me know. I'll then make sure it works on YOUR raspberry pi and write some more documentation.

== QLC+ and OLA ==

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

=== QLC+ ===

Harold van Hulten wrote a nice "howto". See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

==== our tests ====

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:
https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5
but with one addition:
apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit
plugins/plugins.pro

to remove the hash on the line with "uart" so that it reads:
!macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

=== OLA ===
==== bullseye ====

It seems that once again the stock OLA distribution has a problem with the uartdmx plugin.

To simplify a few steps I recommend to just install ola from the distribution.
We won't use the actual olad binary, but it arranges a few things that are useful.

First this installs the scripts to have ola start at
system boot. Also this will add the olad user we need to run the daemon under.
We do this before compiling
and installing ola from source so that our freshly compiled ola will overwrite
the system binaries with a working one.

To compile ola from scratch from the github current version first install the dependencies:

If you haven't already done so, edit /etc/apt/sources.list

sudo nano /etc/apt/sources.list

and remove the # before deb-src, which is probably the third and last line. Then:

sudo apt build-dep ola

then get the sources:

git clone https://github.com/OpenLightingProject/ola.git

The ola deamon should run under user "olad". Adding that is simple enough:

sudo adduser --system olad

Then configure, build and install:
cd ola
autoreconf -i
./configure --prefix=/usr
make -j4
sudo make install

The build step will take about 20 minutes on a pi4 with a fast SD card. (at least,
that's what happened on mine :-) )

Next I had to add the olad user to the group tty to allow it to write to the device:

sudo adduser olad tty

FYI: A non-working olad (the one in the bullseye distribution) will report
plugins/uartdmx/UartWidget.cpp:180: Failed to set baud rate to 250k
while a working one will report:
plugins/uartdmx/UartDmxThread.cpp:136: Granularity for UART thread is GOOD

Also FYI: The build in bullseye has defines and build flags that result in the baud-rate-setting
code thinking that the calls needed to set the baud rate are not available. In the latest
ola version the conditions that cause the code to think it isn't available have changed a bit
and the "we can't change the baud rate because at compile time the calls weren't available"
code now prints an error message instead of just returning: "couldn't change it for some reason"
resulting in the above "failed to set baud rate" message without further explanation.

If I've missed a step when you try this, let me know.
(also let me know if all this was not necessary on your system, and say your distribution's ola worked.
This hopefully happens in a future debian/raspberry pi OS version).

==== stretch ====

The distribution ola works on Stretch. ''sudo apt-get install ola'' should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

==== Jessie ====
On raspbian jessie installing OLA is easy: ''sudo apt-get install ola'' should do the trick. <s>The downside is however that it doesn't work :-( . </s>

'''update:''' The simple option seems to work now. :-) '''update2:''' Some hints are that it still doesn't work. :-(
Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

<span style="color:#808080">
what does work however is:
#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure
make -j 5 all
sudo make install
<span style="color:#808080">
There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )
</span>

==== wheezy ====
On Wheezy, adding
deb http://apt.openlighting.org/raspbian wheezy main
to ''/etc/apt/sources.list'', and then the ''apt-get install ola'' should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

==== raspberry pi 3 and pi 4 ====

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:
dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:
* change baudrate unexpectedly when the CPU feels hot.
* I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

==== all raspberries ====

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like '''console=ttyAMA0,115200''' there, remove that whole '''console=''' entry. Try not to mess up the rest of that line.

Most importantly: add:
init_uart_clock=16000000
to your config.txt file in the /boot directory. In my tests today (2023) I had a different number on my screen when I was doing this. I used 3x more: 48000000. This works as well (on a rpi4).

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in ''/etc/ola/conf/'', on others ''/var/lib/ola/conf/'', and in some cases: ''/root/.ola/ola-uartdmx.conf'' or ''/home/pi/.ola/ola-uartdmx.conf''. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add ''/dev/ttyAMA0-break = 100'' and ''/dev/ttyAMA0-malf = 100'' . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

==== output mode ====

Then set the board to output mode. I would recommend creating a small script (''sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode'') :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then
echo "$0 : on or off?"
exit 1
fi

if [ ! -d $gpio ] ; then
echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:
sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (there is an "exit 0" in there, so put it BEFORE that!)

Or you can install the gpio utility from wiringpi. However this now seems unmaintained and hard-to-get and possibly it doesn't even work on modern pi's. But if it works on your pi the following command allows you view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO 18 pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized ''I'' was getting away with this.... :-) )

= Hardware =

== used hardware pins ==

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

== jumper settings ==

The jumper block has three (sensible) jumper positions, they can be either on or off.
(We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

== Case ==

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

[[Assembling_the_DMX_case]]

Dmx interface for raspberry pi

2024-09-10T08:53:57Z

Rew: /* Software */

= Introduction =

[[File:DMX_case_complete.jpg‎|thumb|DMX with case]]

The [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi '''DMX interface for raspberry pi'''] allows you to interface a raspberry pi with DMX hardware.

There is also [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi-with-usb-(FT245RL) a version "with FT245"]. That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

= Software =

There are several software packages that can be used with your '''DMX interface for Raspberry pi'''.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

== DMX input on Linux ==

The Unix-derived way of handling tty/uart makes it impossible to do DMX input from userspace. So this option has existed in the hardware for ages, but for Linux there was no software support.

I have recently (september 2024) written a driver for the UART in userspace that will actually do DMX input and deliver the DMX universe as a memory mappable file. From there it is easy to export it say to OLA, and hopefully QLC+.

This is a hardware driver, so it depends on the hardware. I've tested it on raspberry pi 3, and that works. I expect minor changes for other versions. It is not worth my trouble if nobody uses it, so if you need it, please let me know. I'll then make sure it works on YOUR raspberry pi and write some more documentation.

== QLC+ and OLA ==

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

=== QLC+ ===

Harold van Hulten wrote a nice "howto". See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

==== our tests ====

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:
https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5
but with one addition:
apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit
plugins/plugins.pro

to remove the hash on the line with "uart" so that it reads:
!macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

=== OLA ===
==== bullseye ====

It seems that once again the stock OLA distribution has a problem with the uartdmx plugin.

To simplify a few steps I recommend to just install ola from the distribution.
We won't use the actual olad binary, but it arranges a few things that are useful.

First this installs the scripts to have ola start at
system boot. Also this will add the olad user we need to run the daemon under.
We do this before compiling
and installing ola from source so that our freshly compiled ola will overwrite
the system binaries with a working one.

To compile ola from scratch from the github current version first install the dependencies:

If you haven't already done so, edit /etc/apt/sources.list

sudo nano /etc/apt/sources.list

and remove the # before deb-src, which is probably the third and last line. Then:

sudo apt build-dep ola

then get the sources:

git clone https://github.com/OpenLightingProject/ola.git

The ola deamon should run under user "olad". Adding that is simple enough:

sudo adduser --system olad

Then configure, build and install:
cd ola
autoreconf -i
./configure --prefix=/usr
make -j4
sudo make install

The build step will take about 20 minutes on a pi4 with a fast SD card. (at least,
that's what happened on mine :-) )

Next I had to add the olad user to the group tty to allow it to write to the device:

sudo adduser olad tty

FYI: A non-working olad (the one in the bullseye distribution) will report
plugins/uartdmx/UartWidget.cpp:180: Failed to set baud rate to 250k
while a working one will report:
plugins/uartdmx/UartDmxThread.cpp:136: Granularity for UART thread is GOOD

Also FYI: The build in bullseye has defines and build flags that result in the baud-rate-setting
code thinking that the calls needed to set the baud rate are not available. In the latest
ola version the conditions that cause the code to think it isn't available have changed a bit
and the "we can't change the baud rate because at compile time the calls weren't available"
code now prints an error message instead of just returning: "couldn't change it for some reason"
resulting in the above "failed to set baud rate" message without further explanation.

If I've missed a step when you try this, let me know.
(also let me know if all this was not necessary on your system, and say your distribution's ola worked.
This hopefully happens in a future debian/raspberry pi OS version).

==== stretch ====

The distribution ola works on Stretch. ''sudo apt-get install ola'' should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

==== Jessie ====
On raspbian jessie installing OLA is easy: ''sudo apt-get install ola'' should do the trick. <s>The downside is however that it doesn't work :-( . </s>

'''update:''' The simple option seems to work now. :-) '''update2:''' Some hints are that it still doesn't work. :-(
Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

<span style="color:#808080">
what does work however is:
#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure
make -j 5 all
sudo make install
<span style="color:#808080">
There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )
</span>

==== wheezy ====
On Wheezy, adding
deb http://apt.openlighting.org/raspbian wheezy main
to ''/etc/apt/sources.list'', and then the ''apt-get install ola'' should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

==== raspberry pi 3 and pi 4 ====

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:
dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:
* change baudrate unexpectedly when the CPU feels hot.
* I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

==== all raspberries ====

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like '''console=ttyAMA0,115200''' there, remove that whole '''console=''' entry. Try not to mess up the rest of that line.

Most importantly: add:
init_uart_clock=16000000
to your config.txt file in the /boot directory. In my tests today (2023) I had a different number on my screen when I was doing this. I used 3x more: 48000000. This works as well (on a rpi4).

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in ''/etc/ola/conf/'', on others ''/var/lib/ola/conf/'', and in some cases: ''/root/.ola/ola-uartdmx.conf'' or ''/home/pi/.ola/ola-uartdmx.conf''. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add ''/dev/ttyAMA0-break = 100'' and ''/dev/ttyAMA0-malf = 100'' . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

==== output mode ====

Then set the board to output mode. I would recommend creating a small script (''sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode'') :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then
echo "$0 : on or off?"
exit 1
fi

if [ ! -d $gpio ] ; then
echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:
sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (there is an "exit 0" in there, so put it BEFORE that!)

Or you can install the gpio utility from wiringpi. However this now seems unmaintained and hard-to-get and possibly it doesn't even work on modern pi's. But if it works on your pi the following command allows you view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO 18 pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized ''I'' was getting away with this.... :-) )

= Hardware =

== used hardware pins ==

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

== jumper settings ==

The jumper block has three (sensible) jumper positions, they can be either on or off.
(We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

== Case ==

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

[[Assembling_the_DMX_case]]

Assembling the DMX case

2023-12-31T15:02:11Z

Rew: /* Step 1 */

= Assembling the DMX case =

[[File:DMX_case_complete.jpg‎|600px|DMX case]]

== Included ==

Included screws and spacers
7x M3X6 6+1 screw
4x M2.5x10 screw
4X M2.5X12MM (If we're our of 12mm, we'll send 16mm)
M2.5x4MM spacer
4X M2.5X20MM FF spacer
4X M2.5X6MM screw

=== OLD: ===
We've switched from M3 sized screws that you have to force through the RPI to M2.5 as was
intended by the RPI people.
10x m3x6
4x m3x12
4x m2.5x10
4x m3x4mm spacer
4x m3x20mm spacer

== Step 1 ==

4x m2.5x6
4x m2.5x12
4x m2.5x4mm spacer
4x m2.5x20mm spacer

[[File:DMX_case_1.jpg‎|400px|DMX case - step 1]]

[[File:DMX_case_2.jpg‎|400px|DMX case - step 1]]

[[File:DMX_case_3.jpg‎|400px|DMX case - step 1]]

[[File:DMX_case_4.jpg‎|400px|DMX case - step 1]]

== Step 2 ==

[[File:DMX_case_5.jpg‎|400px|DMX case - step 2]]

[[File:DMX_case_6.jpg‎|400px|DMX case - step 2]]

[[File:DMX_case_7.jpg‎|400px|DMX case - step 2]]

== Step 3 ==

6x m3x6
4x m2.5x10

[[File:DMX_case_8.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_9.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_10.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_11.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_12.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_13.jpg‎|400px|DMX case - step 3]]

Assembling the DMX case

2023-12-31T15:00:57Z

Rew: /* Included */

= Assembling the DMX case =

[[File:DMX_case_complete.jpg‎|600px|DMX case]]

== Included ==

Included screws and spacers
7x M3X6 6+1 screw
4x M2.5x10 screw
4X M2.5X12MM (If we're our of 12mm, we'll send 16mm)
M2.5x4MM spacer
4X M2.5X20MM FF spacer
4X M2.5X6MM screw

=== OLD: ===
We've switched from M3 sized screws that you have to force through the RPI to M2.5 as was
intended by the RPI people.
10x m3x6
4x m3x12
4x m2.5x10
4x m3x4mm spacer
4x m3x20mm spacer

== Step 1 ==

4x m3x6
4x m3x12
4x m3x4mm spacer
4x m3x20mm spacer

[[File:DMX_case_1.jpg‎|400px|DMX case - step 1]]

[[File:DMX_case_2.jpg‎|400px|DMX case - step 1]]

[[File:DMX_case_3.jpg‎|400px|DMX case - step 1]]

[[File:DMX_case_4.jpg‎|400px|DMX case - step 1]]

== Step 2 ==

[[File:DMX_case_5.jpg‎|400px|DMX case - step 2]]

[[File:DMX_case_6.jpg‎|400px|DMX case - step 2]]

[[File:DMX_case_7.jpg‎|400px|DMX case - step 2]]

== Step 3 ==

6x m3x6
4x m2.5x10

[[File:DMX_case_8.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_9.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_10.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_11.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_12.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_13.jpg‎|400px|DMX case - step 3]]

Assembling the DMX case

2023-12-31T14:59:41Z

Rew: /* Included */

= Assembling the DMX case =

[[File:DMX_case_complete.jpg‎|600px|DMX case]]

== Included ==
7x M3X6 6+1 screw
4x M2.5x10 screw
4X M2.5X12MM (If we're our of 12mm, we'll send 16mm)
M2.5x4MM spacer
4X M2.5X20MM FF spacer
4X M2.5X6MM screw

=== OLD: ===
Included screws and spacers
10x m3x6
4x m3x12
4x m2.5x10
4x m3x4mm spacer
4x m3x20mm spacer

== Step 1 ==

4x m3x6
4x m3x12
4x m3x4mm spacer
4x m3x20mm spacer

[[File:DMX_case_1.jpg‎|400px|DMX case - step 1]]

[[File:DMX_case_2.jpg‎|400px|DMX case - step 1]]

[[File:DMX_case_3.jpg‎|400px|DMX case - step 1]]

[[File:DMX_case_4.jpg‎|400px|DMX case - step 1]]

== Step 2 ==

[[File:DMX_case_5.jpg‎|400px|DMX case - step 2]]

[[File:DMX_case_6.jpg‎|400px|DMX case - step 2]]

[[File:DMX_case_7.jpg‎|400px|DMX case - step 2]]

== Step 3 ==

6x m3x6
4x m2.5x10

[[File:DMX_case_8.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_9.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_10.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_11.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_12.jpg‎|400px|DMX case - step 3]]

[[File:DMX_case_13.jpg‎|400px|DMX case - step 3]]

Bw tool

2023-12-05T09:50:39Z

Rew: /* Basic Example */

= Intro =

The bw_tool is meant to provide a basic commandline access to the bitwizard expansion boards. It was written for the Raspberry Pi, but has now been proven to work on other Linux platforms with an spidev device as well.

= Installation/Compiling =

You can download the bw_tool [https://github.com/rewolff/bw_rpi_tools here]. If you are using git just type
''git clone https://github.com/rewolff/bw_rpi_tools.git''

Nowadays the "bw_tool" is the only directory of interest. Go there and build:
''cd bw_rpi_tools/bw_tool; make''
should work fine. If things went smoothly (which they usually do) you can install the binary so that normal users on your rpi can find it:
''make install''

== Setting up I2C/SPI under Linux ==

The modern way is to do it with raspi-config. Enter raspi-config, select "interface options", select I2C or SPI depending on what you need, and turn it on. After changing this just now, I did not need to reboot to make the setting active.

Below is what raspi-config does behind the scenes, probably updated for later versions of the kernel and the raspberry pi.

On Raspberry pi, raspbian, you first need to edit /boot/config.txt . Near the bottom you will find a line that reads:
#dtparam=i2c_arm=on
You need to remove the hashmark so that it becomes:
dtparam=i2c_arm=on

To activate this a reboot is required.

Then you need to make sure that the i2c-dev module is loaded. For testing, type:
modprobe i2c-dev
but to make it permantently add "i2c-dev" to /etc/modules .

= Basic Example =

The simplest invocation:

bw_tool -t "Hello World!"

will display the shown text on an SPI_LCD on the default SPI bus (SPI0). Options modify the defaults.

For example, if you have an I2C module, add:
-I -D /dev/i2c-1
to switch to i2c-mode and specify the correct device.

If you have a rpi_ui plugged onto your raspberry pi, add:
-a 94

So the complete commandline would become:
bw_tool -D /dev/i2c-1 -I -a 94 -t "Hello world!"

= About Permissions =

The above command needs access to the SPI bus. By default Linux does not know if letting users access this bus is going to compromise the system or not. As a result, Linux chooses to only allow the root user access to the SPI or I2C bus by default. So you have the following choices:

* You can run your whole session as root. Run "sudo -i" to gain root access.
* You can issue only the commands that require spi-bus access as root by prefixing them with "sudo". e.g.:
sudo bw_tool -t "Hello World!"
* If you are using I2C only, you could add yourself to the I2C group (assuming your username is "pi") :
sudo gpasswd -a pi i2c
or:
sudo usermod -a -G i2c pi
You only need to run one of these commands once. Afterwards, log out and back in. To verify if the command succeeded, run:
groups
it should return something like:
pi adm dialout cdrom sudo audio video plugdev games users '''i2c'''
* you can change the permissions on the device files:
sudo chmod 666 /dev/spidev*
sudo chmod 666 /dev/i2c-*

Since the "/dev" filesystem is kept in RAM, you will need to do that again, at every boot. You could add those commands to /etc/rc.local to issue them automatically at every boot, but a better way is to use [https://wiki.debian.org/udev| udev] for this. To do that create (as root) the file /etc/udev/rules.d/70-i2cspi.rules with the following contents:
SUBSYSTEM=="spidev", MODE="0666"
SUBSYSTEM=="i2c-dev", MODE="0666"
and reboot. All I2C and SPI devices should now be world writable.

= Options =

== Options Specifying the Device ==

The option
-I
will switch to I2C mode.

The option
-D <device>
will use that device. Specify /dev/spidev0.1 for the second SPI bus on the raspberry pi for example. Or /dev/i2c-1 to specify the second I2C bus. On revision 2 Raspberry Pi's, the I2C buses are switched, so you need -D /dev/i2c-1, while on the first raspberry pi's -D /dev/i2c-0 is redundant as that is the default.

The option
-a <address>
specifies the address of the device to use. Note that BitWizard uses the full 8 bits that are sent to the device. Add one for "read" operation. In some circles, notably I2C, it is customary to specify just those 7 bits. Thus when the I2C_LCD is at the default address of 0x82, i2cdetect will scan it at address 0x41.

The option
-S
will scan the bus for bitwizard protocol devices. This only works for SPI devices. Use the i2cdetect command (in the package i2ctools) to scan the I2C bus if you have i2c devices.

== Identifying the Device ==
To check for a proper connection to the device, one could use the identify command line switch -i. For instance, a Raspberry Pi UI connected via I2C could be checked with
bw_tool -I -D /dev/i2c-0 -a 94 -i
returnes
I2C_rpi_ui 1.6

== Sending Data ==

the option
-t "text"
will send the text to the device, at port zero. The port cannot be changed, but all BitWizard PCBs that have the option of displaying text have the text port at port zero.

The option
-w <addr>:<byte>
will write the byte to the port at addr. For LCD-equipped boards for example -w 12:50 will set the contrast to 0x50.

The option
-W <addr>:<data>:<type>
will write the data to the port at addr, using the datasize specified in "type": b for byte, s for short (16 bits), i for integer (32 bits) and l for long (64 bits) . For example -W 81:1000:s will write the value 0x1000 to the numsamples port on an analog-equipped board.

== Reading Data ==

The option
-R <port>:<datasize>
reads the data at port from the device. Datasize can be 'b' for byte (default), 's' for short (16 bits), or 'i' for a 32-bit integer.

== Finetuning ==

To test sending data to SPI devices, there is the
--hex [byte...]
option. This simply sends the bytes specified, and reports back what was received. Note that BitWizard boards will not send any data until they have been selected, so the first byte received will represent whatever static is found on the bus.

= Known Bugs =
* The identify command returns two garbled characters when used in I2C mode

Bw tool

2023-12-05T09:49:25Z

Rew: /* Setting up I2C/SPI under Linux */

= Intro =

The bw_tool is meant to provide a basic commandline access to the bitwizard expansion boards. It was written for the Raspberry Pi, but has now been proven to work on other Linux platforms with an spidev device as well.

= Installation/Compiling =

You can download the bw_tool [https://github.com/rewolff/bw_rpi_tools here]. If you are using git just type
''git clone https://github.com/rewolff/bw_rpi_tools.git''

Nowadays the "bw_tool" is the only directory of interest. Go there and build:
''cd bw_rpi_tools/bw_tool; make''
should work fine. If things went smoothly (which they usually do) you can install the binary so that normal users on your rpi can find it:
''make install''

== Setting up I2C/SPI under Linux ==

The modern way is to do it with raspi-config. Enter raspi-config, select "interface options", select I2C or SPI depending on what you need, and turn it on. After changing this just now, I did not need to reboot to make the setting active.

Below is what raspi-config does behind the scenes, probably updated for later versions of the kernel and the raspberry pi.

On Raspberry pi, raspbian, you first need to edit /boot/config.txt . Near the bottom you will find a line that reads:
#dtparam=i2c_arm=on
You need to remove the hashmark so that it becomes:
dtparam=i2c_arm=on

To activate this a reboot is required.

Then you need to make sure that the i2c-dev module is loaded. For testing, type:
modprobe i2c-dev
but to make it permantently add "i2c-dev" to /etc/modules .

= Basic Example =

The simplest invocation:

bw_tool -t "Hello World!"

will display the shown text on an SPI_LCD on the default SPI bus (SPI0). Options modify the defaults.

For example, if you have an I2C module, add:
-I -D /dev/i2c-1
to switch to i2c-mode and specify the correct device.

If you have a rpi_ui plugged onto your raspberry pi, add:
-a 94

= About Permissions =

The above command needs access to the SPI bus. By default Linux does not know if letting users access this bus is going to compromise the system or not. As a result, Linux chooses to only allow the root user access to the SPI or I2C bus by default. So you have the following choices:

* You can run your whole session as root. Run "sudo -i" to gain root access.
* You can issue only the commands that require spi-bus access as root by prefixing them with "sudo". e.g.:
sudo bw_tool -t "Hello World!"
* If you are using I2C only, you could add yourself to the I2C group (assuming your username is "pi") :
sudo gpasswd -a pi i2c
or:
sudo usermod -a -G i2c pi
You only need to run one of these commands once. Afterwards, log out and back in. To verify if the command succeeded, run:
groups
it should return something like:
pi adm dialout cdrom sudo audio video plugdev games users '''i2c'''
* you can change the permissions on the device files:
sudo chmod 666 /dev/spidev*
sudo chmod 666 /dev/i2c-*

Since the "/dev" filesystem is kept in RAM, you will need to do that again, at every boot. You could add those commands to /etc/rc.local to issue them automatically at every boot, but a better way is to use [https://wiki.debian.org/udev| udev] for this. To do that create (as root) the file /etc/udev/rules.d/70-i2cspi.rules with the following contents:
SUBSYSTEM=="spidev", MODE="0666"
SUBSYSTEM=="i2c-dev", MODE="0666"
and reboot. All I2C and SPI devices should now be world writable.

= Options =

== Options Specifying the Device ==

The option
-I
will switch to I2C mode.

The option
-D <device>
will use that device. Specify /dev/spidev0.1 for the second SPI bus on the raspberry pi for example. Or /dev/i2c-1 to specify the second I2C bus. On revision 2 Raspberry Pi's, the I2C buses are switched, so you need -D /dev/i2c-1, while on the first raspberry pi's -D /dev/i2c-0 is redundant as that is the default.

The option
-a <address>
specifies the address of the device to use. Note that BitWizard uses the full 8 bits that are sent to the device. Add one for "read" operation. In some circles, notably I2C, it is customary to specify just those 7 bits. Thus when the I2C_LCD is at the default address of 0x82, i2cdetect will scan it at address 0x41.

The option
-S
will scan the bus for bitwizard protocol devices. This only works for SPI devices. Use the i2cdetect command (in the package i2ctools) to scan the I2C bus if you have i2c devices.

== Identifying the Device ==
To check for a proper connection to the device, one could use the identify command line switch -i. For instance, a Raspberry Pi UI connected via I2C could be checked with
bw_tool -I -D /dev/i2c-0 -a 94 -i
returnes
I2C_rpi_ui 1.6

== Sending Data ==

the option
-t "text"
will send the text to the device, at port zero. The port cannot be changed, but all BitWizard PCBs that have the option of displaying text have the text port at port zero.

The option
-w <addr>:<byte>
will write the byte to the port at addr. For LCD-equipped boards for example -w 12:50 will set the contrast to 0x50.

The option
-W <addr>:<data>:<type>
will write the data to the port at addr, using the datasize specified in "type": b for byte, s for short (16 bits), i for integer (32 bits) and l for long (64 bits) . For example -W 81:1000:s will write the value 0x1000 to the numsamples port on an analog-equipped board.

== Reading Data ==

The option
-R <port>:<datasize>
reads the data at port from the device. Datasize can be 'b' for byte (default), 's' for short (16 bits), or 'i' for a 32-bit integer.

== Finetuning ==

To test sending data to SPI devices, there is the
--hex [byte...]
option. This simply sends the bytes specified, and reports back what was received. Note that BitWizard boards will not send any data until they have been selected, so the first byte received will represent whatever static is found on the bus.

= Known Bugs =
* The identify command returns two garbled characters when used in I2C mode

General I2C protocol

2023-11-06T12:06:48Z

Rew:

BitWizard expansion boards communicate using an I2C protocol.

I2C is a standard protocol, sometimes called "TW" or "TWI" by other manufacturers.
Each I2C slave has its own I2C address. This allows us to daisy chain a large number of boards. The BitWizard I2C boards can be told to use a different I2C address so that you can resolve conflicts if you would otherwise have several devices at one address. Most other commercial products have an I2C address assigned by the manufacturer or a small range that you can configure using strapping pins.

For the pinout of the bitwizard connector: [https://bitwizard.nl/wiki/I2C_connector_pinout look here]

= Timing =

The slaves use an ATTINY44 processor. These have a hardware universal serial interface (USI) module that can be configured as "I2C slave". Many things however have to be processed in software. This means that some time is required between each byte. The hardware of the ATTINY44 will pull the SCL line low while the processing is not finished. If you use a software I2C master, doublecheck that your I2C master supports this feature.

The I2C protocol is specified at 100kHz and 400kHz bit rate. If you lower the pullup resistors a bit and have a short bus, the hardware will probably be able to handle bit rates up to 2MHz. This is not recommended. Use the standard 400kHz.

= Protocol =

To send a sequence of bytes to the slave I2C device, the master starts by creating a START condition: the SDA line goes low while SCL is held high. All slaves are now primed to receive an "address" byte. Next the master sends the address byte.

After this the protocol in theory depends on which slave you are talking to. In practice so far it is convenient to make the slaves talk a similar protocol: the next byte specifies a "register" or "port" address. After this you can send data to that port or register.

If the data can be considered a "data stream" like with the I2C_LCD board, you can call it a "port". If there is just a single value, it is more common to call it a register.

Dmx interface for raspberry pi

2023-10-11T17:35:17Z

Rew: /* bullseye */

= Introduction =

[[File:DMX_case_complete.jpg‎|thumb|DMX with case]]

The [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi '''DMX interface for raspberry pi'''] allows you to interface a raspberry pi with DMX hardware.

There is also [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi-with-usb-(FT245RL) a version "with FT245"]. That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

= Software =

There are several software packages that can be used with your '''DMX interface for Raspberry pi'''.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

== QLC+ and OLA ==

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

=== QLC+ ===

Harold van Hulten wrote a nice "howto". See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

==== our tests ====

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:
https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5
but with one addition:
apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit
plugins/plugins.pro

to remove the hash on the line with "uart" so that it reads:
!macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

=== OLA ===
==== bullseye ====

It seems that once again the stock OLA distribution has a problem with the uartdmx plugin.

To simplify a few steps I recommend to just install ola from the distribution.
We won't use the actual olad binary, but it arranges a few things that are useful.

First this installs the scripts to have ola start at
system boot. Also this will add the olad user we need to run the daemon under.
We do this before compiling
and installing ola from source so that our freshly compiled ola will overwrite
the system binaries with a working one.

To compile ola from scratch from the github current version first install the dependencies:

If you haven't already done so, edit /etc/apt/sources.list

sudo nano /etc/apt/sources.list

and remove the # before deb-src, which is probably the third and last line. Then:

sudo apt build-dep ola

then get the sources:

git clone https://github.com/OpenLightingProject/ola.git

The ola deamon should run under user "olad". Adding that is simple enough:

sudo adduser --system olad

Then configure, build and install:
cd ola
autoreconf -i
./configure --prefix=/usr
make -j4
sudo make install

The build step will take about 20 minutes on a pi4 with a fast SD card. (at least,
that's what happened on mine :-) )

Next I had to add the olad user to the group tty to allow it to write to the device:

sudo adduser olad tty

FYI: A non-working olad (the one in the bullseye distribution) will report
plugins/uartdmx/UartWidget.cpp:180: Failed to set baud rate to 250k
while a working one will report:
plugins/uartdmx/UartDmxThread.cpp:136: Granularity for UART thread is GOOD

Also FYI: The build in bullseye has defines and build flags that result in the baud-rate-setting
code thinking that the calls needed to set the baud rate are not available. In the latest
ola version the conditions that cause the code to think it isn't available have changed a bit
and the "we can't change the baud rate because at compile time the calls weren't available"
code now prints an error message instead of just returning: "couldn't change it for some reason"
resulting in the above "failed to set baud rate" message without further explanation.

If I've missed a step when you try this, let me know.
(also let me know if all this was not necessary on your system, and say your distribution's ola worked.
This hopefully happens in a future debian/raspberry pi OS version).

==== stretch ====

The distribution ola works on Stretch. ''sudo apt-get install ola'' should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

==== Jessie ====
On raspbian jessie installing OLA is easy: ''sudo apt-get install ola'' should do the trick. <s>The downside is however that it doesn't work :-( . </s>

'''update:''' The simple option seems to work now. :-) '''update2:''' Some hints are that it still doesn't work. :-(
Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

<span style="color:#808080">
what does work however is:
#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure
make -j 5 all
sudo make install
<span style="color:#808080">
There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )
</span>

==== wheezy ====
On Wheezy, adding
deb http://apt.openlighting.org/raspbian wheezy main
to ''/etc/apt/sources.list'', and then the ''apt-get install ola'' should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

==== raspberry pi 3 and pi 4 ====

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:
dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:
* change baudrate unexpectedly when the CPU feels hot.
* I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

==== all raspberries ====

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like '''console=ttyAMA0,115200''' there, remove that whole '''console=''' entry. Try not to mess up the rest of that line.

Most importantly: add:
init_uart_clock=16000000
to your config.txt file in the /boot directory. In my tests today (2023) I had a different number on my screen when I was doing this. I used 3x more: 48000000. This works as well (on a rpi4).

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in ''/etc/ola/conf/'', on others ''/var/lib/ola/conf/'', and in some cases: ''/root/.ola/ola-uartdmx.conf'' or ''/home/pi/.ola/ola-uartdmx.conf''. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add ''/dev/ttyAMA0-break = 100'' and ''/dev/ttyAMA0-malf = 100'' . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

==== output mode ====

Then set the board to output mode. I would recommend creating a small script (''sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode'') :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then
echo "$0 : on or off?"
exit 1
fi

if [ ! -d $gpio ] ; then
echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:
sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (there is an "exit 0" in there, so put it BEFORE that!)

Or you can install the gpio utility from wiringpi. However this now seems unmaintained and hard-to-get and possibly it doesn't even work on modern pi's. But if it works on your pi the following command allows you view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO 18 pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized ''I'' was getting away with this.... :-) )

= Hardware =

== used hardware pins ==

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

== jumper settings ==

The jumper block has three (sensible) jumper positions, they can be either on or off.
(We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

== Case ==

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

[[Assembling_the_DMX_case]]

Dmx interface for raspberry pi

2023-10-11T15:00:17Z

Rew: /* bullseye */

= Introduction =

[[File:DMX_case_complete.jpg‎|thumb|DMX with case]]

The [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi '''DMX interface for raspberry pi'''] allows you to interface a raspberry pi with DMX hardware.

There is also [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi-with-usb-(FT245RL) a version "with FT245"]. That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

= Software =

There are several software packages that can be used with your '''DMX interface for Raspberry pi'''.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

== QLC+ and OLA ==

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

=== QLC+ ===

Harold van Hulten wrote a nice "howto". See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

==== our tests ====

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:
https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5
but with one addition:
apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit
plugins/plugins.pro

to remove the hash on the line with "uart" so that it reads:
!macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

=== OLA ===
==== bullseye ====

It seems that once again the stock OLA distribution has a problem with the uartdmx plugin.

To compile ola from scratch from the github current version first install the dependencies:

Edit /etc/apt/sources.list

nano /etc/apt/sources.list

and remove the # before deb-src, which is probably the third line. Then:
sudo apt build-dep ola

then get the sources:

git clone https://github.com/OpenLightingProject/ola.git

Then configure, build and install:
cd ola
autoreconf -i
./configure --prefix=/usr
make -j4
sudo make install

The build step will take about 20 minutes on a pi4 with a fast SD card. Next I had to add the olad user to the group tty to allow it to write to the device:

sudo adduser olad tty

FYI: A non-working olad will report
plugins/uartdmx/UartWidget.cpp:180: Failed to set baud rate to 250k
while a working one will report:
plugins/uartdmx/UartDmxThread.cpp:136: Granularity for UART thread is GOOD

Also FYI: I've compared the sources for the "working" distro-ola and the working-from-git and the only changes are documentation-related. Not a single line-of-code was changed between the two versions.

If I've missed a step when you try this, let me know. (also let me know if all this was not necessary on your system, and say your distribution's ola worked).

==== stretch ====

The distribution ola works on Stretch. ''sudo apt-get install ola'' should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

==== Jessie ====
On raspbian jessie installing OLA is easy: ''sudo apt-get install ola'' should do the trick. <s>The downside is however that it doesn't work :-( . </s>

'''update:''' The simple option seems to work now. :-) '''update2:''' Some hints are that it still doesn't work. :-(
Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

<span style="color:#808080">
what does work however is:
#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure
make -j 5 all
sudo make install
<span style="color:#808080">
There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )
</span>

==== wheezy ====
On Wheezy, adding
deb http://apt.openlighting.org/raspbian wheezy main
to ''/etc/apt/sources.list'', and then the ''apt-get install ola'' should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

==== raspberry pi 3 and pi 4 ====

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:
dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:
* change baudrate unexpectedly when the CPU feels hot.
* I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

==== all raspberries ====

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like '''console=ttyAMA0,115200''' there, remove that whole '''console=''' entry. Try not to mess up the rest of that line.

Most importantly: add:
init_uart_clock=16000000
to your config.txt file in the /boot directory. In my tests today (2023) I had a different number on my screen when I was doing this. I used 3x more: 48000000. This works as well (on a rpi4).

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in ''/etc/ola/conf/'', on others ''/var/lib/ola/conf/'', and in some cases: ''/root/.ola/ola-uartdmx.conf'' or ''/home/pi/.ola/ola-uartdmx.conf''. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add ''/dev/ttyAMA0-break = 100'' and ''/dev/ttyAMA0-malf = 100'' . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

==== output mode ====

Then set the board to output mode. I would recommend creating a small script (''sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode'') :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then
echo "$0 : on or off?"
exit 1
fi

if [ ! -d $gpio ] ; then
echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:
sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (there is an "exit 0" in there, so put it BEFORE that!)

Or you can install the gpio utility from wiringpi. However this now seems unmaintained and hard-to-get and possibly it doesn't even work on modern pi's. But if it works on your pi the following command allows you view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO 18 pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized ''I'' was getting away with this.... :-) )

= Hardware =

== used hardware pins ==

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

== jumper settings ==

The jumper block has three (sensible) jumper positions, they can be either on or off.
(We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

== Case ==

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

[[Assembling_the_DMX_case]]

STM32 development board

2023-10-02T09:07:46Z

Rew: /* SV2 */

== pinout ==

=== IO voltage ===
The "VCCIO" voltage can be set with the jumper "5V/3.3V"

Note that this is "power for the slave device", it does not imply that the outgoing signals will have a 5V level (that's always 3.3V), or that the pins are 5V tolerant.

=== UART ===
(not all pin numbers are typed out fully).

* 1 GND
* PA10 RX
* PA9 TX
* 4 VCCIO

=== I2C1 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB7 SDA
* PB6 SCL
* 4 VCCIO

=== I2C2 ===
(not all pin numbers are typed out fully).

* 1 GND
* PB11 SDA
* PB10 SCL
* 4 VCCIO

=== SPI ===

See elsewhere on this site.

=== SV2 ===

General purpose IO connector.
(not all pin numbers are typed out fully).

* 1 GND
* 2 GND
* 3 PA0
* PA1
* PA2
* PA3
* PA4
* PA5
* PA6
* PA7
* PA8
* PA15
* PB0
* PB1
* PD2
* PB5
* PB8
* PB9
* 19 VCCIO
* 20 VCCIO

=== SV3 ===

General purpose IO connector.

* 1 GND
* 2 GND
* 3 PC0
* 4 PC1
* 5 PC2
* 6 PC3
* 7 PC4
* 8 PC5
* 9 PC6
* 10 PC7
* 11 PC8
* 12 PC9
* 13 PC10
* 14 PC11
* 15 PC12
* 16 PC13
* 17 PC14
* 18 PC15
* 19 VCCIO
* 20 VCCIO

=== SWD ===

* 1 VCC 3.3V
* 2 SWCK PA14
* 3 GND
* 4 SWDAT PA13
* 5 NRST
* 6 BOOT0

Dmx interface for raspberry pi

2023-09-20T19:16:40Z

Rew: /* bullseye */

= Introduction =

[[File:DMX_case_complete.jpg‎|thumb|DMX with case]]

The [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi '''DMX interface for raspberry pi'''] allows you to interface a raspberry pi with DMX hardware.

There is also [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi-with-usb-(FT245RL) a version "with FT245"]. That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

= Software =

There are several software packages that can be used with your '''DMX interface for Raspberry pi'''.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

== QLC+ and OLA ==

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

=== QLC+ ===

Harold van Hulten wrote a nice "howto". See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

==== our tests ====

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:
https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5
but with one addition:
apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit
plugins/plugins.pro

to remove the hash on the line with "uart" so that it reads:
!macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

=== OLA ===
==== bullseye ====

It seems that once again the stock OLA distribution has a problem with the uartdmx plugin.

To compile ola from scratch from the github current version first install the dependencies:

sudo apt build-dep ola

then get the sources:

git clone https://github.com/OpenLightingProject/ola.git

Then configure, build and install:
cd ola
autoreconf -i
./configure --prefix=/usr
make -j4
sudo make install

The build step will take about 20 minutes on a pi4 with a fast SD card. Next I had to add the olad user to the group tty to allow it to write to the device:

sudo adduser olad tty

FYI: A non-working olad will report
plugins/uartdmx/UartWidget.cpp:180: Failed to set baud rate to 250k
while a working one will report:
plugins/uartdmx/UartDmxThread.cpp:136: Granularity for UART thread is GOOD

Also FYI: I've compared the sources for the "working" distro-ola and the working-from-git and the only changes are documentation-related. Not a single line-of-code was changed between the two versions.

If I've missed a step when you try this, let me know. (also let me know if all this was not necessary on your system, and say your distribution's ola worked).

==== stretch ====

The distribution ola works on Stretch. ''sudo apt-get install ola'' should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

==== Jessie ====
On raspbian jessie installing OLA is easy: ''sudo apt-get install ola'' should do the trick. <s>The downside is however that it doesn't work :-( . </s>

'''update:''' The simple option seems to work now. :-) '''update2:''' Some hints are that it still doesn't work. :-(
Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

<span style="color:#808080">
what does work however is:
#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure
make -j 5 all
sudo make install
<span style="color:#808080">
There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )
</span>

==== wheezy ====
On Wheezy, adding
deb http://apt.openlighting.org/raspbian wheezy main
to ''/etc/apt/sources.list'', and then the ''apt-get install ola'' should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

==== raspberry pi 3 and pi 4 ====

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:
dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:
* change baudrate unexpectedly when the CPU feels hot.
* I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

==== all raspberries ====

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like '''console=ttyAMA0,115200''' there, remove that whole '''console=''' entry. Try not to mess up the rest of that line.

Most importantly: add:
init_uart_clock=16000000
to your config.txt file in the /boot directory. In my tests today (2023) I had a different number on my screen when I was doing this. I used 3x more: 48000000. This works as well (on a rpi4).

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in ''/etc/ola/conf/'', on others ''/var/lib/ola/conf/'', and in some cases: ''/root/.ola/ola-uartdmx.conf'' or ''/home/pi/.ola/ola-uartdmx.conf''. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add ''/dev/ttyAMA0-break = 100'' and ''/dev/ttyAMA0-malf = 100'' . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

==== output mode ====

Then set the board to output mode. I would recommend creating a small script (''sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode'') :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then
echo "$0 : on or off?"
exit 1
fi

if [ ! -d $gpio ] ; then
echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:
sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (there is an "exit 0" in there, so put it BEFORE that!)

Or you can install the gpio utility from wiringpi. However this now seems unmaintained and hard-to-get and possibly it doesn't even work on modern pi's. But if it works on your pi the following command allows you view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO 18 pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized ''I'' was getting away with this.... :-) )

= Hardware =

== used hardware pins ==

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

== jumper settings ==

The jumper block has three (sensible) jumper positions, they can be either on or off.
(We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

== Case ==

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

[[Assembling_the_DMX_case]]

Dmx interface for raspberry pi

2023-09-20T19:09:41Z

Rew: /* OLA */

= Introduction =

[[File:DMX_case_complete.jpg‎|thumb|DMX with case]]

The [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi '''DMX interface for raspberry pi'''] allows you to interface a raspberry pi with DMX hardware.

There is also [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi-with-usb-(FT245RL) a version "with FT245"]. That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

= Software =

There are several software packages that can be used with your '''DMX interface for Raspberry pi'''.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

== QLC+ and OLA ==

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

=== QLC+ ===

Harold van Hulten wrote a nice "howto". See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

==== our tests ====

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:
https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5
but with one addition:
apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit
plugins/plugins.pro

to remove the hash on the line with "uart" so that it reads:
!macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

=== OLA ===
==== bullseye ====

It seems that once again the stock OLA distribution has a problem with the uartdmx plugin.

To compile ola from scratch from the github current version first install the dependencies:

sudo apt build-dep ola

then get the sources:

git clone https://github.com/OpenLightingProject/ola.git

Then configure, build and install:
cd ola
autoreconf -i
./configure --prefix=/usr
make -j4
sudo make install

next I had to add the olad user to the group tty to allow it to write to the device:

sudo adduser olad tty

FYI: A non-working olad will report
plugins/uartdmx/UartWidget.cpp:180: Failed to set baud rate to 250k
while a working one will report:
plugins/uartdmx/UartDmxThread.cpp:136: Granularity for UART thread is GOOD

Also FYI: I've compared the sources for the "working" distro-ola and the working-from-git and the only changes are documentation-related. Not a single line-of-code was changed between the two versions.

If I've missed a step when you try this, let me know. (also let me know if all this was not necessary on your system, and say your distribution's ola worked).

==== stretch ====

The distribution ola works on Stretch. ''sudo apt-get install ola'' should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

==== Jessie ====
On raspbian jessie installing OLA is easy: ''sudo apt-get install ola'' should do the trick. <s>The downside is however that it doesn't work :-( . </s>

'''update:''' The simple option seems to work now. :-) '''update2:''' Some hints are that it still doesn't work. :-(
Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

<span style="color:#808080">
what does work however is:
#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure
make -j 5 all
sudo make install
<span style="color:#808080">
There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )
</span>

==== wheezy ====
On Wheezy, adding
deb http://apt.openlighting.org/raspbian wheezy main
to ''/etc/apt/sources.list'', and then the ''apt-get install ola'' should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

==== raspberry pi 3 and pi 4 ====

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:
dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:
* change baudrate unexpectedly when the CPU feels hot.
* I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

==== all raspberries ====

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like '''console=ttyAMA0,115200''' there, remove that whole '''console=''' entry. Try not to mess up the rest of that line.

Most importantly: add:
init_uart_clock=16000000
to your config.txt file in the /boot directory. In my tests today (2023) I had a different number on my screen when I was doing this. I used 3x more: 48000000. This works as well (on a rpi4).

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in ''/etc/ola/conf/'', on others ''/var/lib/ola/conf/'', and in some cases: ''/root/.ola/ola-uartdmx.conf'' or ''/home/pi/.ola/ola-uartdmx.conf''. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add ''/dev/ttyAMA0-break = 100'' and ''/dev/ttyAMA0-malf = 100'' . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

==== output mode ====

Then set the board to output mode. I would recommend creating a small script (''sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode'') :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then
echo "$0 : on or off?"
exit 1
fi

if [ ! -d $gpio ] ; then
echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:
sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (there is an "exit 0" in there, so put it BEFORE that!)

Or you can install the gpio utility from wiringpi. However this now seems unmaintained and hard-to-get and possibly it doesn't even work on modern pi's. But if it works on your pi the following command allows you view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO 18 pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized ''I'' was getting away with this.... :-) )

= Hardware =

== used hardware pins ==

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

== jumper settings ==

The jumper block has three (sensible) jumper positions, they can be either on or off.
(We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

== Case ==

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

[[Assembling_the_DMX_case]]

Dmx interface for raspberry pi

2023-09-20T18:49:21Z

Rew: /* output mode */

= Introduction =

[[File:DMX_case_complete.jpg‎|thumb|DMX with case]]

The [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi '''DMX interface for raspberry pi'''] allows you to interface a raspberry pi with DMX hardware.

There is also [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi-with-usb-(FT245RL) a version "with FT245"]. That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

= Software =

There are several software packages that can be used with your '''DMX interface for Raspberry pi'''.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

== QLC+ and OLA ==

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

=== QLC+ ===

Harold van Hulten wrote a nice "howto". See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

==== our tests ====

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:
https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5
but with one addition:
apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit
plugins/plugins.pro

to remove the hash on the line with "uart" so that it reads:
!macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

=== OLA ===

==== stretch ====

The distribution ola works on Stretch. ''sudo apt-get install ola'' should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

==== Jessie ====
On raspbian jessie installing OLA is easy: ''sudo apt-get install ola'' should do the trick. <s>The downside is however that it doesn't work :-( . </s>

'''update:''' The simple option seems to work now. :-) '''update2:''' Some hints are that it still doesn't work. :-(
Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

<span style="color:#808080">
what does work however is:
#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure
make -j 5 all
sudo make install
<span style="color:#808080">
There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )
</span>

==== wheezy ====
On Wheezy, adding
deb http://apt.openlighting.org/raspbian wheezy main
to ''/etc/apt/sources.list'', and then the ''apt-get install ola'' should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

==== raspberry pi 3 and pi 4 ====

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:
dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:
* change baudrate unexpectedly when the CPU feels hot.
* I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

==== all raspberries ====

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like '''console=ttyAMA0,115200''' there, remove that whole '''console=''' entry. Try not to mess up the rest of that line.

Most importantly: add:
init_uart_clock=16000000
to your config.txt file in the /boot directory. In my tests today (2023) I had a different number on my screen when I was doing this. I used 3x more: 48000000. This works as well (on a rpi4).

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in ''/etc/ola/conf/'', on others ''/var/lib/ola/conf/'', and in some cases: ''/root/.ola/ola-uartdmx.conf'' or ''/home/pi/.ola/ola-uartdmx.conf''. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add ''/dev/ttyAMA0-break = 100'' and ''/dev/ttyAMA0-malf = 100'' . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

==== output mode ====

Then set the board to output mode. I would recommend creating a small script (''sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode'') :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then
echo "$0 : on or off?"
exit 1
fi

if [ ! -d $gpio ] ; then
echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:
sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (there is an "exit 0" in there, so put it BEFORE that!)

Or you can install the gpio utility from wiringpi. However this now seems unmaintained and hard-to-get and possibly it doesn't even work on modern pi's. But if it works on your pi the following command allows you view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO 18 pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized ''I'' was getting away with this.... :-) )

= Hardware =

== used hardware pins ==

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

== jumper settings ==

The jumper block has three (sensible) jumper positions, they can be either on or off.
(We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

== Case ==

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

[[Assembling_the_DMX_case]]

Dmx interface for raspberry pi

2023-09-20T18:43:08Z

Rew: /* all raspberries */

= Introduction =

[[File:DMX_case_complete.jpg‎|thumb|DMX with case]]

The [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi '''DMX interface for raspberry pi'''] allows you to interface a raspberry pi with DMX hardware.

There is also [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi-with-usb-(FT245RL) a version "with FT245"]. That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

= Software =

There are several software packages that can be used with your '''DMX interface for Raspberry pi'''.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

== QLC+ and OLA ==

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

=== QLC+ ===

Harold van Hulten wrote a nice "howto". See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

==== our tests ====

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:
https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5
but with one addition:
apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit
plugins/plugins.pro

to remove the hash on the line with "uart" so that it reads:
!macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

=== OLA ===

==== stretch ====

The distribution ola works on Stretch. ''sudo apt-get install ola'' should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

==== Jessie ====
On raspbian jessie installing OLA is easy: ''sudo apt-get install ola'' should do the trick. <s>The downside is however that it doesn't work :-( . </s>

'''update:''' The simple option seems to work now. :-) '''update2:''' Some hints are that it still doesn't work. :-(
Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

<span style="color:#808080">
what does work however is:
#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure
make -j 5 all
sudo make install
<span style="color:#808080">
There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )
</span>

==== wheezy ====
On Wheezy, adding
deb http://apt.openlighting.org/raspbian wheezy main
to ''/etc/apt/sources.list'', and then the ''apt-get install ola'' should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

==== raspberry pi 3 and pi 4 ====

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:
dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:
* change baudrate unexpectedly when the CPU feels hot.
* I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

==== all raspberries ====

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like '''console=ttyAMA0,115200''' there, remove that whole '''console=''' entry. Try not to mess up the rest of that line.

Most importantly: add:
init_uart_clock=16000000
to your config.txt file in the /boot directory. In my tests today (2023) I had a different number on my screen when I was doing this. I used 3x more: 48000000. This works as well (on a rpi4).

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in ''/etc/ola/conf/'', on others ''/var/lib/ola/conf/'', and in some cases: ''/root/.ola/ola-uartdmx.conf'' or ''/home/pi/.ola/ola-uartdmx.conf''. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add ''/dev/ttyAMA0-break = 100'' and ''/dev/ttyAMA0-malf = 100'' . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

==== output mode ====

Then set the board to output mode. I would recommend creating a small script (''sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode'') :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then
echo "$0 : on or off?"
exit 1
fi

if [ ! -d $gpio ] ; then
echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:
sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (IIRC there is an "exit 0" in there, so don't put it AFTER that!)

Or you can install the gpio utility from wiringpi and use the following command to view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized ''I'' was getting away with this.... :-) )

= Hardware =

== used hardware pins ==

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

== jumper settings ==

The jumper block has three (sensible) jumper positions, they can be either on or off.
(We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

== Case ==

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

[[Assembling_the_DMX_case]]

Dmx interface for raspberry pi

2023-09-20T18:41:15Z

Rew: /* raspberry pi 3 and pi 4 */

= Introduction =

[[File:DMX_case_complete.jpg‎|thumb|DMX with case]]

The [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi '''DMX interface for raspberry pi'''] allows you to interface a raspberry pi with DMX hardware.

There is also [http://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi-with-usb-(FT245RL) a version "with FT245"]. That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

= Software =

There are several software packages that can be used with your '''DMX interface for Raspberry pi'''.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

== QLC+ and OLA ==

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

=== QLC+ ===

Harold van Hulten wrote a nice "howto". See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

==== our tests ====

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:
https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5
but with one addition:
apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit
plugins/plugins.pro

to remove the hash on the line with "uart" so that it reads:
!macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

=== OLA ===

==== stretch ====

The distribution ola works on Stretch. ''sudo apt-get install ola'' should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

==== Jessie ====
On raspbian jessie installing OLA is easy: ''sudo apt-get install ola'' should do the trick. <s>The downside is however that it doesn't work :-( . </s>

'''update:''' The simple option seems to work now. :-) '''update2:''' Some hints are that it still doesn't work. :-(
Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

<span style="color:#808080">
what does work however is:
#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure
make -j 5 all
sudo make install
<span style="color:#808080">
There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )
</span>

==== wheezy ====
On Wheezy, adding
deb http://apt.openlighting.org/raspbian wheezy main
to ''/etc/apt/sources.list'', and then the ''apt-get install ola'' should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

==== raspberry pi 3 and pi 4 ====

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:
dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:
* change baudrate unexpectedly when the CPU feels hot.
* I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

==== all raspberries ====

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like '''console=ttyAMA0,115200''' there, remove that whole '''console=''' entry. Try not to mess up the rest of that line.

Most importantly: add:
init_uart_clock=16000000
to your config.txt file in the /boot directory.

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in ''/etc/ola/conf/'', on others ''/var/lib/ola/conf/'', and in some cases: ''/root/.ola/ola-uartdmx.conf'' or ''/home/pi/.ola/ola-uartdmx.conf''. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add ''/dev/ttyAMA0-break = 100'' and ''/dev/ttyAMA0-malf = 100'' . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

==== output mode ====

Then set the board to output mode. I would recommend creating a small script (''sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode'') :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then
echo "$0 : on or off?"
exit 1
fi

if [ ! -d $gpio ] ; then
echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:
sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (IIRC there is an "exit 0" in there, so don't put it AFTER that!)

Or you can install the gpio utility from wiringpi and use the following command to view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized ''I'' was getting away with this.... :-) )

= Hardware =

== used hardware pins ==

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

== jumper settings ==

The jumper block has three (sensible) jumper positions, they can be either on or off.
(We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

== Case ==

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

[[Assembling_the_DMX_case]]

FT2232H breakout board

2023-07-26T16:20:40Z

Rew: /* Overview */

FT2232H breakout board

2023-07-26T16:15:49Z

Rew: /* Pinout */

FT2232H breakout board

2023-07-26T16:15:22Z

Rew: /* Changelog */

FT2232H breakout board

2023-07-26T16:15:11Z

Rew: /* Future hardware enhancements */

FT2232H breakout board

2023-07-26T16:14:40Z

Rew: /* Changelog */

FT2232H breakout board

2023-07-26T16:13:33Z

Rew: /* Jumper settings */

FT2232H breakout board

2023-07-26T16:09:38Z

Rew: /* Pinout */

FT2232H breakout board

2023-07-26T16:03:22Z

Rew: /* Overview */

= FT2232H breakout board =

This is the documentation page for the FT2232H breakout board.

== Overview ==

The FT2232H breakout board has an USB connector, two 6 pin SPI connectors, two 4 pin I2C connectors and a general purpose connector. Besides that there are two jumpers for enabling the I2C ports, and a selector jumper that allows you to chose between 3.3V or 5V on the IO connectors.

== External resources ==

* [http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf Datasheet]
* [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI product page]

== Pinout ==

The SV1 connector is designed to be connected to the 40 pin expansion connector of Terasic FPGA boards. This can be done with a standard 40 pin IDE cable, provided that it isn't too long.

40-pin connector SV1 is connected as follows:
<table border=1>
<tr><td>ACBUS5</td><td>1</td><td>2</td><td>NC</td></tr>
<tr><td>NC</td><td>3</td><td>4</td><td>NC</td></tr>
<tr><td>ADBUS0</td><td>5</td><td>6</td><td>ADBUS1</td></tr>
<tr><td>ADBUS2</td><td>7</td><td>8</td><td>ADBUS3</td></tr>
<tr><td>ADBUS4</td><td>9</td><td>10</td><td>ADBUS5</td></tr>
<tr><td>5V</td><td>11</td><td>12</td><td>GND</td></tr>
<tr><td>ADBUS6</td><td>13</td><td>14</td><td>ADBUS7</td></tr>
<tr><td>ACBUS0</td><td>15</td><td>16</td><td>ACBUS1</td></tr>
<tr><td>ACBUS2</td><td>17</td><td>18</td><td>ACBUS3</td></tr>
<tr><td>ACBUS4</td><td>19</td><td>20</td><td>ACBUS5</td></tr>
<tr><td>ACBUS6</td><td>21</td><td>22</td><td>ACBUS7</td></tr>
<tr><td>BDBUS0</td><td>23</td><td>24</td><td>BDBUS1</td></tr>
<tr><td>BDBUS2</td><td>25</td><td>26</td><td>BDBUS3</td></tr>
<tr><td>BDBUS4</td><td>27</td><td>28</td><td>BDBUS5</td></tr>
<tr><td>3V3</td><td>29</td><td>30</td><td>GND</td></tr>
<tr><td>BDBUS6</td><td>31</td><td>32</td><td>BDBUS7</td></tr>
<tr><td>BCBUS0</td><td>33</td><td>34</td><td>BCBUS1</td></tr>
<tr><td>BCBUS2</td><td>35</td><td>36</td><td>BCBUS3</td></tr>
<tr><td>BCBUS4</td><td>37</td><td>38</td><td>BCBUS5</td></tr>
<tr><td>BCBUS6</td><td>39</td><td>40</td><td>BCBUS7</td></tr>
</table>

Connectors SV4 and SV5 are designed to be compatible with the 20-pin IO connectors also found on other BitWizard boards.

20-pin connector SV4 is connected as follows:

<table border=1>
<tr><td>GND</td><td>1</td><td>2</td><td>GND</td></tr>
<tr><td>ADBUS0</td><td>3</td><td>4</td><td>ADBUS1</td></tr>
<tr><td>ADBUS2</td><td>5</td><td>6</td><td>ADBUS3</td></tr>
<tr><td>ADBUS4</td><td>7</td><td>8</td><td>ADBUS5</td></tr>
<tr><td>ADBUS6</td><td>9</td><td>10</td><td>ADBUS7</td></tr>
<tr><td>ACBUS0</td><td>11</td><td>12</td><td>ACBUS1</td></tr>
<tr><td>ACBUS2</td><td>13</td><td>14</td><td>ACBUS3</td></tr>
<tr><td>ACBUS4</td><td>15</td><td>16</td><td>ACBUS5</td></tr>
<tr><td>ACBUS6</td><td>17</td><td>18</td><td>ACBUS7</td></tr>
<tr><td>3V3</td><td>19</td><td>20</td><td>3V3</td></tr>
</table>
20-pin connector SV5 is connected as follows:

<table border=1>
<tr><td>GND</td><td>1</td><td>2</td><td>GND</td></tr>
<tr><td>BDBUS0</td><td>3</td><td>4</td><td>BDBUS1</td></tr>
<tr><td>BDBUS2</td><td>5</td><td>6</td><td>BDBUS3</td></tr>
<tr><td>BDBUS4</td><td>7</td><td>8</td><td>BDBUS5</td></tr>
<tr><td>BDBUS6</td><td>9</td><td>10</td><td>BDBUS7</td></tr>
<tr><td>BCBUS0</td><td>11</td><td>12</td><td>BCBUS1</td></tr>
<tr><td>BCBUS2</td><td>13</td><td>14</td><td>BCBUS3</td></tr>
<tr><td>BCBUS4</td><td>15</td><td>16</td><td>BCBUS5</td></tr>
<tr><td>BCBUS6</td><td>17</td><td>18</td><td>BCBUS7</td></tr>
<tr><td>3V3</td><td>19</td><td>20</td><td>3V3</td></tr>
</table>
=== LEDS ===

* led1 is connected to VCC

== Jumper settings ==

==== For 2.0 ====

SV2: 3V3 supply selection<br>
1-2: Direct from FPGA board (through 40-pin connector)<br>
2-3: From regulator (see SV3 settings)<br>

SV3: Regulator power source selection<br>
1-2: Powered from USB<br>
2-3: Powered from FPGA board (through 40-pin connector)<br>

==== For 2.1 ====

J1: 3V3 supply selection<br>
1-2: Direct from FPGA board (through 40-pin connector)<br>
2-3: From regulator (see J2 settings)<br>

J2: Regulator power source selection (physical position is the same as in 2.0, only numbering has changed)<br>
1-2: Powered from FPGA board (through 40-pin connector)<br>
2-3: Powered from USB<br>

== Future hardware enhancements ==

== Changelog ==

2.1
* Renamed SV2 to J1
* Renamed SV3 to J2
* Jumper settings marked on PCB
* Moved center of mounting holes to 3mm from PCB edge

2.0
* Initial public release

FT2232H breakout board

2023-07-26T16:02:11Z

Rew: /* Overview */

= FT2232H breakout board =

This is the documentation page for the FT2232H breakout board.

== Overview ==

The FT2232H breakout board has an USB connector, two 6 pin SPI connectors, two 4 pin I2C connectors and a general purpose connector.

== External resources ==

* [http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf Datasheet]
* [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI product page]

== Pinout ==

The SV1 connector is designed to be connected to the 40 pin expansion connector of Terasic FPGA boards. This can be done with a standard 40 pin IDE cable, provided that it isn't too long.

40-pin connector SV1 is connected as follows:
<table border=1>
<tr><td>ACBUS5</td><td>1</td><td>2</td><td>NC</td></tr>
<tr><td>NC</td><td>3</td><td>4</td><td>NC</td></tr>
<tr><td>ADBUS0</td><td>5</td><td>6</td><td>ADBUS1</td></tr>
<tr><td>ADBUS2</td><td>7</td><td>8</td><td>ADBUS3</td></tr>
<tr><td>ADBUS4</td><td>9</td><td>10</td><td>ADBUS5</td></tr>
<tr><td>5V</td><td>11</td><td>12</td><td>GND</td></tr>
<tr><td>ADBUS6</td><td>13</td><td>14</td><td>ADBUS7</td></tr>
<tr><td>ACBUS0</td><td>15</td><td>16</td><td>ACBUS1</td></tr>
<tr><td>ACBUS2</td><td>17</td><td>18</td><td>ACBUS3</td></tr>
<tr><td>ACBUS4</td><td>19</td><td>20</td><td>ACBUS5</td></tr>
<tr><td>ACBUS6</td><td>21</td><td>22</td><td>ACBUS7</td></tr>
<tr><td>BDBUS0</td><td>23</td><td>24</td><td>BDBUS1</td></tr>
<tr><td>BDBUS2</td><td>25</td><td>26</td><td>BDBUS3</td></tr>
<tr><td>BDBUS4</td><td>27</td><td>28</td><td>BDBUS5</td></tr>
<tr><td>3V3</td><td>29</td><td>30</td><td>GND</td></tr>
<tr><td>BDBUS6</td><td>31</td><td>32</td><td>BDBUS7</td></tr>
<tr><td>BCBUS0</td><td>33</td><td>34</td><td>BCBUS1</td></tr>
<tr><td>BCBUS2</td><td>35</td><td>36</td><td>BCBUS3</td></tr>
<tr><td>BCBUS4</td><td>37</td><td>38</td><td>BCBUS5</td></tr>
<tr><td>BCBUS6</td><td>39</td><td>40</td><td>BCBUS7</td></tr>
</table>

Connectors SV4 and SV5 are designed to be compatible with the 20-pin IO connectors also found on other BitWizard boards.

20-pin connector SV4 is connected as follows:

<table border=1>
<tr><td>GND</td><td>1</td><td>2</td><td>GND</td></tr>
<tr><td>ADBUS0</td><td>3</td><td>4</td><td>ADBUS1</td></tr>
<tr><td>ADBUS2</td><td>5</td><td>6</td><td>ADBUS3</td></tr>
<tr><td>ADBUS4</td><td>7</td><td>8</td><td>ADBUS5</td></tr>
<tr><td>ADBUS6</td><td>9</td><td>10</td><td>ADBUS7</td></tr>
<tr><td>ACBUS0</td><td>11</td><td>12</td><td>ACBUS1</td></tr>
<tr><td>ACBUS2</td><td>13</td><td>14</td><td>ACBUS3</td></tr>
<tr><td>ACBUS4</td><td>15</td><td>16</td><td>ACBUS5</td></tr>
<tr><td>ACBUS6</td><td>17</td><td>18</td><td>ACBUS7</td></tr>
<tr><td>3V3</td><td>19</td><td>20</td><td>3V3</td></tr>
</table>
20-pin connector SV5 is connected as follows:

<table border=1>
<tr><td>GND</td><td>1</td><td>2</td><td>GND</td></tr>
<tr><td>BDBUS0</td><td>3</td><td>4</td><td>BDBUS1</td></tr>
<tr><td>BDBUS2</td><td>5</td><td>6</td><td>BDBUS3</td></tr>
<tr><td>BDBUS4</td><td>7</td><td>8</td><td>BDBUS5</td></tr>
<tr><td>BDBUS6</td><td>9</td><td>10</td><td>BDBUS7</td></tr>
<tr><td>BCBUS0</td><td>11</td><td>12</td><td>BCBUS1</td></tr>
<tr><td>BCBUS2</td><td>13</td><td>14</td><td>BCBUS3</td></tr>
<tr><td>BCBUS4</td><td>15</td><td>16</td><td>BCBUS5</td></tr>
<tr><td>BCBUS6</td><td>17</td><td>18</td><td>BCBUS7</td></tr>
<tr><td>3V3</td><td>19</td><td>20</td><td>3V3</td></tr>
</table>
=== LEDS ===

* led1 is connected to VCC

== Jumper settings ==

==== For 2.0 ====

SV2: 3V3 supply selection<br>
1-2: Direct from FPGA board (through 40-pin connector)<br>
2-3: From regulator (see SV3 settings)<br>

SV3: Regulator power source selection<br>
1-2: Powered from USB<br>
2-3: Powered from FPGA board (through 40-pin connector)<br>

==== For 2.1 ====

J1: 3V3 supply selection<br>
1-2: Direct from FPGA board (through 40-pin connector)<br>
2-3: From regulator (see J2 settings)<br>

J2: Regulator power source selection (physical position is the same as in 2.0, only numbering has changed)<br>
1-2: Powered from FPGA board (through 40-pin connector)<br>
2-3: Powered from USB<br>

== Future hardware enhancements ==

== Changelog ==

2.1
* Renamed SV2 to J1
* Renamed SV3 to J2
* Jumper settings marked on PCB
* Moved center of mounting holes to 3mm from PCB edge

2.0
* Initial public release

Bridgetimer

2023-01-14T15:53:46Z

Rew: /* Technical details */

= Bridgetimer =

== Introduction ==

A bridge tournament consists of a number of rounds and short breaks in between rounds to allow the players to switch tables. The Bridgetimer counts down the time remaining for each round as well as the remaining break time and provides several audiosignals:

* The starting signal of a round, doubling as the ending signal of the break time
* A warning signal indicating the round is about to end
* The ending signal of a round, doubling as the starting signal of the break time

== Features ==

The BitWizard Bridgetimer has several distinctive features:

* Large display
* Visible difference between "remaining round-time" and "remaining break time".
* Different sounds signals for "end-of-round", "Warning, end-of-round is nearing" and "Start of round".
* Five preset programs. Allowing you to quickly change between different settings (e.g. for the beginners-evening where the rounds are longer).
* Easy to use interface for adjustments.
* On-the-fly adjustment of the playing and changeover (break) time.
* Mounting holes on the back enabling you to mount the timer on a wall

[[File:Bridgeklok_EN.png|600 px|]]

== Contents ==

Within the box you will find:

* The Bridgetimer
* A 15V adapter
* An extension cord

Use the Bridgetimer exclusively with the supplied adapter.
If necessary a similar adapter can be used, with the + on the center pin. The voltage should be between 12 and 15V, however no guarantees are made regarding the brightness of the screen when not using the supplied adapter.

== Using the Bridgetimer ==

The Bridgetimer is simple to use. Just plug it in with the supplied adapter, turn it on and it starts running the first program called "P1" at 10 seconds left of "change time". These ten seconds give you time to adjust the break time or to press the '''pause''' button (5) to pause the clock before the first round timer starts.

The timer always starts with program P1 selected. The default settings for all programs are 30 minutes of playing time, a warning signal when 5 minutes of playing time remain and 3 minutes of break time.

A different program may be selected by pressing '''mode''' (2) and subsequently either '''up''' (3) or '''down''' (4) in order to select the desired program.

The Bridgetimer may be paused at any time by pressing the '''pause''' button (5).

If the current break or round time needs to be adjusted at any point this can done by pressing '''up''' (3) or '''down''' (4) to respectively increase or decrease the time by 1 minute.

A warning signal sounds when the end of a round approaches, a different signal sounds at the end of a round, and a third signal sounds when the break time is over and the next round begins.

During break time the leftmost digit of the display will show a single moving segment symbolizing the players walking around. This way the difference between break and playing time can easily be distinguished.

== Creating custom programs ==

To adjust the clock press '''mode'''. Now '''up''' and '''down''' will select the preset-program. The programs show as P1 through P5. Press '''pause''' to start the selected program, or press '''mode''' again to make adjustments to the selected program.

For each program there are three settings: time to play, warning time, and changeover (break) time. Each is adjusted with the '''up''' and '''down''' keys. The changeover time is adjusted with 20 second increments. The other two with 1 minute increments.

Pressing '''mode''' will move to the next option. Any changes are automatically saved.

Unused programs start out at the default of 30 minutes playing, 5 minute warning and 3 minute changeover time.

To adjust the brightness of the numbers, turn off the clock, press and hold the '''pause''' button, and turn the clock on. The display should now show an "I" (from Intensity) as well as the current value. You may adjust (using the '''up''' and '''down''' buttons) from 0 to 99. The default of 33 seems good for normal use. During daytime or outside even brighter might be useful. Each '''up''' or '''down''' keypress adjusts the intensity value by 3 units. The lowest intensities will show a visible flicker in the display. Don't use those.

== Suggestions for use ==

When you turn on the clock it will always start back at P1. The reason is that when for example there are two weekly events that require different settings, starting back up on the old settings guarantees that you will ''always'' start with the wrong settings active. Starting back at P1 all the time means we stand a chance of getting it right some of the time....

If the program that your club uses is always the same, just adjust the default P1 program. You can do this once and then adjust the change time before the first round or the first round itself on each event.

If you share the clock between two events that have different timings, I recommend programming the schedules for those events into P2 and P3. People who are not familiar with the clock will quickly adjust P1 to whatever event is then being played. If you know what you're doing you can even quicker just select the proper program. In my experience P1 gets messed up "by the other players" all the time.

== Changing the volume ==

The volume can be adjusted with the use of a small screwdriver, both flat and cross head screwdrivers may be used. On the back of the Bridgetimer a total of 4 holes can be found, the two uppermost are used to mount the Bridgetimer on a wall, the outermost is used for field upgrades of the firmware. The innermost (closest to the speaker) is used for adjusting the volume.
As the circuit board and the potentiometer are positioned relatively deep within the timer, some effort may be required to locate the potentiometer. In order to prevent short-circuiting it is advised to search for the potentiometer only when the the timer is unpowered.

== Feedback ==

BitWizard is a small company headed by a bridge-playing CEO. When his bridgeclub wanted a new clock we build one.

We're not specializing in "bridge products" and we don't have the money to fund a big requirements interview among a large number of clubs. So we build what WE need and what we think you will find useful. If you feel something could be improved, feel free to let us know, we'll take it into consideration! It is entirely possible that due to a different way of playing a drive, your club has different requirements. We might even be able to help you with the hardware you've already bought in the form of software changes.

As mentioned above, we welcome feature requests. No guarantees can be made that we implement all of them, but we love to hear them.

Features that have already been requested and are currently being implemented are:
* Multiple clocks in master-slave configuration
* Remote control

Also, if you think a device with four big numbers like this is useful in another context, be sure to let us know.
It is entirely possible the hardware is already capable of performing the task and as specified earlier, the installed software can be switched out for something you require. So if you have an idea, let us know.

Feedback may be send to us by e-mail to info@BitWizard.nl .

== Technical details ==

(the geeks may want to read this, the others can safely ignore it).

The initial version of the clock used to run on 15V, but at one point we realized that 12V also worked with the latest components (led segments: The original required 12V for them alone, more modern ones only about 8).

The USB port on the bottom can be used for upgrading the firmware.

The two PCBs inside are identical, only one is populated as the master, the other as the slave. (The slave can sometimes be another, older (or newer) model than the master, this will not affect performance). Future versions might have only one PCB (for ease of assembly) (starting later in 2023 or maybe 2024).

Version 1 of the hardware runs on an at90USB162 processor and has TLC59025 constant current led drivers to drive the segments. The segments are not multiplexed. Version 2 of the hardware has an STM32F072 processor (As of May 2017 Version 2 is still under development). As of 2023 version 3 is under development using an RP2040. As of january 2023 there is exactly one of those (i.e. half of two).

Pwm16

2022-03-10T12:01:11Z

Rew: /* pinout */

== PWM16 ==

The board comes in two variants, the -b suffix has bigger FETs.

=== specifications ===

* PCA9685 PWM chip.
* Each channel drives a N-channel mosfet.
** Note when switching a load with an N-channel mosfet, the load is wired with its positive directly
connected to power and the mosfet will switch the negative terminal of your load.
* For ease of hooking up, each channel has a power and a switched connection.

The small fets can handle 1A each. Running a total of 16A through the whole board will heat it up a bit, but should still work. Slightly more than 1A is permissible, provided it doesn't last too long. But keep in mind that electronics works on a different timescale. "a second" Is already a very long time for such a small component.

The big fets can handle 5A each. But running 80A through the whole board is going to heat it up beyond permissible limits. Again a bit more for a short period can be permitted, but timescale of "a few milli seconds" and not "a few seconds".

=== pinout ===

Bottom edge has outputs 1-8, each with a <output> <V+> . Each is marked as such on the back of the PCB, as the front was full with components.

Top edge has outputs 9-16, each with a <output> <V+> . Each is marked as such on the back of the PCB, as the front was full with components.

The right edge of the PCB has 6 connections: GND, V1, V1, GND, V2, V2. The power connections are separate. This alows you to run one side of the PCB at a different voltage than the other side. Say 5V on V2 for the top edge of the board, and 12V for the bottom edge. There are two Vx connectors to make it easy to connect one powersupply by looping a sort wire from the second V1 to V2.

The i2c connector pinout is documented here: https://www.bitwizard.nl/wiki/I2C_connector_pinout
(note that the pin1 (and marking) is closest to the PCA chip).

The J1 jumper block allows you to configure the address of the PCA chip. No jumper is 0, a jumper is 1. A0 is the position closest to the PCA chip, A3 is the furthest.

If your board has a second i2c connector, you can use it to chain multiple boards on one I2C bus. Make sure you configure each board for a different address in that case.

=== Usage ===

For full documentation see the PCA9685 datasheet.

To initialize:
* set register 0xfe to 5
* set register 0 to 0x20.

Now the chip is initialized and will do about 1500Hz PWM

To set a channel, write 4 bytes to an address 6+ 4*<channel number> . The first two bytes are the turn-on-timestamp. Write 0x00 0x00. The second two are the turn-off-time. So values 0...0x0fff will set the PWM value (low byte first!). The highest value now will still have the output "off" for 1/4096 period. To turn the output fully on, you need to set the "always on" bit, which is in the "turn on" register that we've been setting to zero. So to turn it fully on send 0x00 0x10 0x00 0x00.

OPTIONAL: if you don't understand this, ignore it.

There are different ways to configure the chip. For example, if you want to set five channels to 0x203, 0x405, 0x607, 0x809 and 0xa0b, the above recommendation works, but it loads your powersupply a bit weird. I've chosen the PWM values a bit wonky so that you can see where the differnt parts go: So above would send '''00 00 03 02, 00 00 05 04, 00 00 07 06, 00 00 09 08, 00 00 0b 0a''' (if the channels are consecutive you can send all that in one go!). In this configuration all five loads are loading the powersupply from 000 to 0203 in each PWM period. And none are loading the powersupply from 0a0b to 0fff.

But slightly easier on the power supply would be: '''00 00 03 02''': First channel is on from 000 to 0203. Then '''03 02 08 06''': second channel is on from 0203 to 0608. Then '''08 06 0f 0c''': third channel on from 0608 to 0c0f. Then '''0f 0c 18 04''': the fourth channel wraps around: it is on from 0c0f to 0418! Continue with '''18 04 23 0e''' and now from 000 to 0e23 two loads are loading the powersupply and from 0e23 to 0fff only one: The variation in load on the powersupply is much less. This strategy works very good when the loads are all identical. When the loads are not identical the calculations become more complex.

Pwm16

2022-03-10T11:41:02Z

Rew: /* pinout */

== PWM16 ==

The board comes in two variants, the -b suffix has bigger FETs.

=== specifications ===

* PCA9685 PWM chip.
* Each channel drives a N-channel mosfet.
** Note when switching a load with an N-channel mosfet, the load is wired with its positive directly
connected to power and the mosfet will switch the negative terminal of your load.
* For ease of hooking up, each channel has a power and a switched connection.

The small fets can handle 1A each. Running a total of 16A through the whole board will heat it up a bit, but should still work. Slightly more than 1A is permissible, provided it doesn't last too long. But keep in mind that electronics works on a different timescale. "a second" Is already a very long time for such a small component.

The big fets can handle 5A each. But running 80A through the whole board is going to heat it up beyond permissible limits. Again a bit more for a short period can be permitted, but timescale of "a few milli seconds" and not "a few seconds".

=== pinout ===

Bottom edge has outputs 1-8, each with a <output> <V+> . Each is marked as such on the back of the PCB, as the front was full with components.

Top edge has outputs 9-16, each with a <output> <V+> . Each is marked as such on the back of the PCB, as the front was full with components.

The right edge of the PCB has 6 connections: GND, V1, V1, GND, V2, V2. The power connections are separate. This alows you to run one side of the PCB at a different voltage than the other side. Say 5V on V2 for the top edge of the board, and 12V for the bottom edge. There are two Vx connectors to make it easy to connect one powersupply by looping a sort wire from the second V1 to V2.

The i2c connector pinout is documented here: https://www.bitwizard.nl/wiki/I2C_connector_pinout
(note that the pin1 (and marking) is closest to the PCA chip).

The J1 jumper block allows you to configure the address of the PCA chip. No jumper is 0, a jumper is 1. A0 is the position closest to the PCA chip, A3 is the furthest.

=== Usage ===

For full documentation see the PCA9685 datasheet.

To initialize:
* set register 0xfe to 5
* set register 0 to 0x20.

Now the chip is initialized and will do about 1500Hz PWM

To set a channel, write 4 bytes to an address 6+ 4*<channel number> . The first two bytes are the turn-on-timestamp. Write 0x00 0x00. The second two are the turn-off-time. So values 0...0x0fff will set the PWM value (low byte first!). The highest value now will still have the output "off" for 1/4096 period. To turn the output fully on, you need to set the "always on" bit, which is in the "turn on" register that we've been setting to zero. So to turn it fully on send 0x00 0x10 0x00 0x00.

OPTIONAL: if you don't understand this, ignore it.

There are different ways to configure the chip. For example, if you want to set five channels to 0x203, 0x405, 0x607, 0x809 and 0xa0b, the above recommendation works, but it loads your powersupply a bit weird. I've chosen the PWM values a bit wonky so that you can see where the differnt parts go: So above would send '''00 00 03 02, 00 00 05 04, 00 00 07 06, 00 00 09 08, 00 00 0b 0a''' (if the channels are consecutive you can send all that in one go!). In this configuration all five loads are loading the powersupply from 000 to 0203 in each PWM period. And none are loading the powersupply from 0a0b to 0fff.

But slightly easier on the power supply would be: '''00 00 03 02''': First channel is on from 000 to 0203. Then '''03 02 08 06''': second channel is on from 0203 to 0608. Then '''08 06 0f 0c''': third channel on from 0608 to 0c0f. Then '''0f 0c 18 04''': the fourth channel wraps around: it is on from 0c0f to 0418! Continue with '''18 04 23 0e''' and now from 000 to 0e23 two loads are loading the powersupply and from 0e23 to 0fff only one: The variation in load on the powersupply is much less. This strategy works very good when the loads are all identical. When the loads are not identical the calculations become more complex.

Pwm16

2022-03-10T10:21:18Z

Rew:

== PWM16 ==

The board comes in two variants, the -b suffix has bigger FETs.

=== specifications ===

* PCA9685 PWM chip.
* Each channel drives a N-channel mosfet.
** Note when switching a load with an N-channel mosfet, the load is wired with its positive directly
connected to power and the mosfet will switch the negative terminal of your load.
* For ease of hooking up, each channel has a power and a switched connection.

The small fets can handle 1A each. Running a total of 16A through the whole board will heat it up a bit, but should still work. Slightly more than 1A is permissible, provided it doesn't last too long. But keep in mind that electronics works on a different timescale. "a second" Is already a very long time for such a small component.

The big fets can handle 5A each. But running 80A through the whole board is going to heat it up beyond permissible limits. Again a bit more for a short period can be permitted, but timescale of "a few milli seconds" and not "a few seconds".

=== pinout ===

Bottom edge has outputs 1-8, each with a <output> <V+> . Each is marked as such on the back of the PCB, as the front was full with components.

Top edge has outputs 9-16, each with a <output> <V+> . Each is marked as such on the back of the PCB, as the front was full with components.

The right edge of the PCB has 6 connections: GND, V1, V1, GND, V2, V2. The power connections are separate. This alows you to run one side of the PCB at a different voltage than the other side. Say 5V on V2 for the top edge of the board, and 12V for the bottom edge. There are two Vx connectors to make it easy to connect one powersupply by looping a sort wire from the second V1 to V2.

=== Usage ===

For full documentation see the PCA9685 datasheet.

To initialize:
* set register 0xfe to 5
* set register 0 to 0x20.

Now the chip is initialized and will do about 1500Hz PWM

To set a channel, write 4 bytes to an address 6+ 4*<channel number> . The first two bytes are the turn-on-timestamp. Write 0x00 0x00. The second two are the turn-off-time. So values 0...0x0fff will set the PWM value (low byte first!). The highest value now will still have the output "off" for 1/4096 period. To turn the output fully on, you need to set the "always on" bit, which is in the "turn on" register that we've been setting to zero. So to turn it fully on send 0x00 0x10 0x00 0x00.

OPTIONAL: if you don't understand this, ignore it.

There are different ways to configure the chip. For example, if you want to set five channels to 0x203, 0x405, 0x607, 0x809 and 0xa0b, the above recommendation works, but it loads your powersupply a bit weird. I've chosen the PWM values a bit wonky so that you can see where the differnt parts go: So above would send '''00 00 03 02, 00 00 05 04, 00 00 07 06, 00 00 09 08, 00 00 0b 0a''' (if the channels are consecutive you can send all that in one go!). In this configuration all five loads are loading the powersupply from 000 to 0203 in each PWM period. And none are loading the powersupply from 0a0b to 0fff.

But slightly easier on the power supply would be: '''00 00 03 02''': First channel is on from 000 to 0203. Then '''03 02 08 06''': second channel is on from 0203 to 0608. Then '''08 06 0f 0c''': third channel on from 0608 to 0c0f. Then '''0f 0c 18 04''': the fourth channel wraps around: it is on from 0c0f to 0418! Continue with '''18 04 23 0e''' and now from 000 to 0e23 two loads are loading the powersupply and from 0e23 to 0fff only one: The variation in load on the powersupply is much less. This strategy works very good when the loads are all identical. When the loads are not identical the calculations become more complex.