Continuing on from the previous PYNQ-Z2 Workshop - Session 1 blog,  this blog continues to investigate the topics covered in the Element 14 workshop session PYNQ-Z2 Workshop: Getting Started with PYNQ led by Adam Taylor, where we took an introductory look at the PYNQ-Z2 development board produced by the Tul Corporation.

 

Previously I had looked at using the logictools overlay and more specifically the Pattern Generator and Trace Analyzer in relation to a 4-bit gray code. This time I'm using it with the DMX512 protocol which is widely used for entertainment control purposes.

 

Once the PYNQ-Z2 development board is powered up and connected to the local network, we can use a web browser to log into Jupyter running on one of the microprocessor cores of the ZYNQ 7000 series device.

 

Here we create a new notebook and start interacting with the PYNQ framework.

 

First we download the logictools overlay supplied with the PYNQ-Z2 board image:

screenshot of Jupyter notebook

Then we create the WaveJSON waveform in WaveDrom mark-up:

screenshot of Jupyter notebook

In this instance we are creating a start frame plus 5 frames of data.

  • start frame is set to 0x00 to indicate dimmer frames
  • channel 1 is set to a value of 0
  • channel 2 is set to a value of 1
  • channel 3 is set to a value of 127
  • channel 4 is set to a value of 128
  • channel 5 is set to a value of 255

Annotations have been added to help illustrate the DMX512 format making use of the WaveDrom features.

  • m.a.l.c mark-after-last channel (minimum duration of 0s but only if at least 24 channels are present to comply with the minimum packet duration)
  • m.a.b mark-after-break (minimum duration of 88μs / two frames)
  • m.b.f mark-between-frames (minimum duration of 0, max of 1s)

The minimum permitted duration for a DMX512 packet is 1196μs, so this example would either need an additional 19 channels adding or alternatively an extended mark-after-last channel to pad out to 1196μs.

 

The 88μs break may also need extending to the recommended 100-200μs to accommodate receiver tolerances.

We can now display the waveform:

screenshot of Jupyter notebook

This is just the first 17 bits, the full 120 bits can be seen further down after the analysis has been captured and added.

 

We can now instantiate the pattern generator and trace analyzer objects to make use of this waveform data.

screenshot of the Jupyter notebook

The analyser is set to capture 120 bits of data.

 

The pattern generator needs to be configured with the stimulus and analysis group wave names, the mode and the frequency.

By default the generator runs at 10MHz which is too fast for DMX512. Unfortunately its configurable range out of the box is 251.95kHz to 100MHz which is still slightly too fast for the 4μs pulses used in in DMX512, however not an issue with simulation, but would make the 88μs break too short to be recognised by some receivers.

The mode can be set to single shot or continuous looping. At this stage it is set to single shot, however looping will be required for a receiver test.

screenshot of Jupyter notebook

In order for the trace analyser to capture the pattern generator output, a jumper cable requires connecting between D0 and D19 on the Arduino interface to provide a loopback signal.

 

We can now run the pattern generator and trace analyzer and display both the generated (Tx) and captured (Rx) waveform:

screenshot of Jupyter notebook

screenshot of Jupyter notebook

screenshot of Jupyter notebook

screenshot of Jupyter notebook

screenshot of Jupyter notebook

screenshot of Jupyter notebook

screenshot of Jupyter notebook

After the capture we can stop the pattern generator:

screenshot of Jupyter notebook

 

As with the previous blog, this was fairly easy to configure and run. The Jupyter notebook environment is convenient to work with, and WaveDrom is quite flexible  once you get the hang of it.

 

Unfortunately the PYNQ documentation is a bit vague on how to use the logictools pattern generator with either of the PMOD (or the Raspberry Pi) interfaces as I have a PMOD RS-485 module sitting here eager to participate. It may have to be patched into the Arduino interface instead.