Wooden Bits Binary Clock FPGA Port

In attempt to get started with FPGAs and Verilog, I decided to port Wooden Bits to a Lattice IceStick – selected because of the Open-Source IceStorm toolchain. Counters and flip-flops are the first thing one learns when starting with FPGA design, so the project lends itself naturally. I learnt things FPGAs are good at and things they are not so good at – best done on a microcontroller. As the project was educational, there were many learnings along the way and invariably still to be learnt; it is not intended as a best use of FPGAs or implementation.

The most enlightening part of the learning and what finally kicked me to do the project, was the PicoSOC project and in particular, Matt Venn’s addition of a WS2812 peripheral to the PicoSOC. The idea of rolling one’s own peripheral for driving external hardware into a SoC or only adding the required ones is new ground for me. The concept also really helps to cement what is actually going on when accessing registers during development of embedded software.

Binary Clock Counter Design

A binary clock is essentially a frequency divider, which can be formed using D-Type Flip-Flops, each data line clocking the next. In order to reset the 4 bit counter at 9 (or the other digits for time), a modulo 9 counter is created by using an AND gate driving reset with bits 1 & 3 (as it clocks 10). This is assuming the D-Type is asynchronous (will reset on reset edge). If it were synchronous, the AND gate must be connected to bits 0 & 3 (9), such that the reset will be clocked as it would be counting 10. The difference becomes quite important in Verilog, particularly when driving the next digit modules with the reset signal.

24 hour ninary coded decimal (BDC) clock design. LSB/digit on left. A binary clock is first a frequency divider, which can be created by changing Flip-Flops together. A modulo counter is created by using a logic gate driving reset of synchronous D-Type Flip-Flops. The time is 00:03:38 in this screenshot.

It’s good to start with a logic diagram of what one is trying to achieve so I drew one up in Falstad (import this file). To implement this, I designed a counter module for each digit that is asynchronous (reset on reset edge), so that the reset line can directly feed the next digit module. Initially, my approach was synchronous (read reset on clk edge) but this meant having to have a ‘carry’ output on reset to clock the other digits at the correct time (otherwise they would clock one digit a head of the desired value).

Test bench timing diagram for synchronous reset digit module. The reset wire turns the counter into a modulo BCD module. Since the design is synchronous, the reset signal cannot be seen – unlike the asynchronous plot below, where it lasts for one clock cycle. The wire will instantaneously (in theory but not in physics…) reset one digit (causing it to clear) whilst driving the next, since it is hardware logic. This is one of the key differences between microcontroller variables and FGPA design.
The asynchronous Flip-Flop design results in the proceeding digit being one clock out of phase. I did originally remedy this by including a modulo output bit, that asserted as the reset signal was clocked. It is the equivalent of adding an additional Flip-Flop to latch the reset in the simulation as a clock source for the next module.

Interestingly, one could use a single counter register rather than individual modules. I developed an alternative based on this idea, using bit logic to clear/increment bit addresses. The advantage is that it only uses 13 bits rather than 16 bits. Other than this, the modular system synthesis should resolve down to the same thing (something that looks like the Falstad simulation), since the reset inputs driving each module are just wire bit logic as in the massive if, else. I think having modules for each digit helps with readability and helped with learning the module aspect of Verilog.Code variants

The Falstad simulation realised in Verilog as a per digit synchronous reset module.

Alternatively, one module to do all digits but with 13 bits rather than 16 bits.

Binary clock timing diagram over almost 24 hours. The LED matrix wire contains the bits arranged to match how the clock display is wired. They are not in digit order but the half frequency of each bit is quite visible.

For development, the clock input to the first Flip-Flop is taken from a divided down master clock (12 MHz) to form a 1 Hz clock. For actual deployment on the bench, I added an additional clock input pin for driving from an external 1 Hz clock generator such as can be found on RTCs.

WS2812 LED Matrix

My original design uses sixteen one-wire WS2812 LEDs chained through the laser-cut wood to form an addressable LED matrix. WS2812 LEDs simplify wiring and hardware complexity over standard LEDs, at the cost of CPU cycles: The one-wire interface sends 24 bit colour data for each LED by modulating the period of high/low in a serial data stream. Each LED takes the first 24 bits,then sends forwards the rest of the data to the next in line. Since microcontrollers don’t have a peripheral specifically designed to do this, it is normally done using Timers and match/overflow interrupt routines.

An FPGA can make light work of this however and my real interest peaked with the idea that one can make a WS2812 peripheral with no processor overhead.

The binary clock face only needs to set LEDs on or off. I created a fork of Matt Venn’s WS2812 module that can access the LED colour register directly so that the code then does a mask operation using the digit registers on each update of the digits (1 Hz in standard operation). The main real overhead driving the LEDs is the size of the colour register that is 24 * N bits, where N is the number of LEDs. The FPGA must latch this data, as it can change at different clock edges. I experimented with various different modifications to the code, each with it’s merits but settled on the direct setting of the RGB register for this project.

Clock Features

Set Button

The set button was easy to port: I added an input to the top module connected to an IO pin and a button with hardware pull-up and debounce – hardware is a key point here, I did both on the uC previously. If the button is pressed, the clock source to the first counter flip-flop changes to one that is running at 1000 Hz (using a counter based divider) and the display colour changes red. Releasing the button returns the clock to the normal state. This allows a user to quickly advance the clock to the correct time.

Whilst it was an easy port, the user interaction is much less refined compared to the software version. My software design features a delay before advancing at accelerated time so one can button press through minutes when near the correct time, or hold the button to advance quickly. It will also wait in set mode for a few seconds on release before setting the new time. Additionally, the set button can be used to set the main display colour.

These advanced interaction would all be possible on the FPGA but the design would become somewhat messy and it would need to be carefully implemented as to avoid FPGA bad practices (there are some big pitfalls I have found!). My take away was that these kind of user interaction features are better done in software – there is minimal overhead compared to driving the LEDs and it is very quick to implement.

Rainbow Colour Cycle

My original clock also fills the display with a rainbow colour routine at midday and midnight. Implementing this on the IceStick became quite challenging as I quickly overran the 1280 LUTs (basically combinational logic). I think this was due to setting a RGB colour for each LED in the colour register, where as before it was just an option between two colours based on whether a bit was high or low. Without the rainbow effect, the sythesis was a simple logic mask but with the addition of full 24 bit colour at run time, it would require much more complicated logic. In addition, the routine works using a pseudo colour wheel that also adds complexity to the logic synthesis, due to three < switches.

Encountering these sorts of problems are useful when learning a new topic.Whilst the base project itself is quite simple, adding in these sorts of features brings up challenges that require further reading. I just managed to squeeze the rainbow effect, after finding areas of optimisation in logic statements and transparent latches.

Discussion

The project grew well beyond the scope of simply getting a binary clock working on the IceStick – I achieved that in less than an hour. What took time was refining how the digit module worked and really understanding how to mirror the simulation; digging into the WS2812 module to add masking and direct colour register set; developing a test bench and methods for capturing specific parts of a design and finally, the user interactions and bonus features.

My take home is that an FPGA is ideal for creating a low-level driver but what one then does with that driver is generally better achieved in software. A binary counter is just as easy and low resource to implement in C and the advantage then is that the button control and advanced features that make the clock unique is much quicker, safer and flexible to incorporate. That code can then directly interface with something like the WS2812 via a FPGA peripheral in this example.

I’m looking forward to trying other high data rate experiments with FPGAs such as LED matrix and HDMI driving, watch this space…

GitHub Project: https://github.com/tuna-f1sh/wooden-bits-fpga

Samsung Frame TV Oak Tripod Stand

Being part of a generation that doesn’t watch TV…except documentaries and films…and YouTube…as well, might as well watch it on a big screen. Got a TV, a Samsung Frame – designed to look like a picture frame.

It can mount flush to a wall or be mounted on an easel inspired stand, which Samsung sell separately for £500.  I decided to have a go at making one myself.

The design is simple but required some thought and trigonometry, in order to get the TV mounted on the VESA mount just at the right position to rest on the joining platform. Photos speak for themselves. 

I planned to get the design CNC cut as I didn’t trust my carpentry skills. Finding someone who could cut planned Oak was difficult however (due to the work holding) and I decided plywood wouldn’t cut the mustard. Instead, I laser-cut templates of the DXF exports and traced them with them jigsaw. It turned out OK; only minor fettling and wood filler involved.

The finished article!

Is Bristol Choking – Air Pollution Web App

I had some of my Nixie Pipe displays showing air pollution data collected by the council, using a Python web scraper at an art trail and people seemed very interested and unaware of the data. I considered how good it would be to have live displays at the air monitoring sites for people to see, but decided a web app was more feasible as a weekend project and less risky!

Is Bristol Choking? is the result. You may wonder what I mean by choking: I’ve classed an area as choking if the current 15 minute average NO2 value is greater than the annual mean legal limit set by the EU of 40 µg/m³ and as stated in the WHO guidelines. Check the website during rush hours and weekend daytime and most are choking. Have a read of the choking and about sections for more.

I used it as a means to learn Python Flask and Python web app tech in general and hope it is clearer and easier to understand than the council site. There is an about section that should add some context to the numbers, which I feel the council site was lacking.

I enjoyed the process of creating the app and learnt quite a lot. Initially, I was scraping the data in the same function call as the main landing page route, which created a short delay with no feedback for the user; it appeared as if the page was taking a while to load. Instead, I ended up using WebSockets with Flask to asynconously scrape the data from the Bristol Air Quality site so that Flask could render the template index.html with a scraping loading animation, then populate the fields via json passed from Flask to a Javascript socket event.

Adventures with Flippy the Flip-dot Display

Considering my next project, I wanted to make an electromechanical display using magnets. I turned to the internet for inspiration and quickly came across Flip-dot displays; solenoid driven pixels. A good starting point for what I wanted to do, I looked further.

I found a 900mm, 56×7 display on eBay from a bus salvager (who know such a thing existed!). The displays used to be common on public transport – prior to being replaced my dot matrix LEDs – to display the route number and destination. It cost me £170, which may seem expensive to some, but for 392 individually mechanically actuated pixels that are quite a feat of engineering, I thought it cheap.

Manufactured by Hanover Displays and with a basic datasheet to hand, I took the plunge. Continue reading Adventures with Flippy the Flip-dot Display

Nixie Pipe – Modern Day LED Nixie Tube

Nixie Pipe is my interpretation of a modern day Nixie Tube – the cold-cathode vacuum gas-filled tubes from the 1960s.

The project came about when I decided to make a clock for my kitchen, with specific requirement for an egg timer function! I’ve always wanted to make a Nixie Tube clock but having completed a Nixie Tube project recently and one pipe failing after around 6,000 hours, I wanted to come up this something better. Something that didn’t require high voltages, special driving circuitry, could be easily interfaced and was modular, but which maintained the unique visual depth of a Nixie Tube. Continue reading Nixie Pipe – Modern Day LED Nixie Tube

Raspberry Pi Data Logger with InfluxDB and Grafana

A need popped up at work for a data logger for various lab tasks. Quickly looking at the market, I failed to identify a lab tool for data logging (cheap, easy but powerful setup, remote access); something for researchers and scientists. I decided a Raspberry Pi with some input buffering would be ideal for the task. This is my roll your own data logger, put together on Saturday – showing what is possible quickly and potential with more development time.

Continue reading Raspberry Pi Data Logger with InfluxDB and Grafana

Chess Table

We needed a coffee table for our new house but had yet to find the right thing. I found this tired black circular table outside a neighbour’s house and was inspired to create a nice top for it.

Whitterm-220 Clever Serial Terminal

21/12/18 UPDATE: Hello to Hack a Day readers. This project was shared when I did it but re-posted recently. It is 2.5 years old and there are many things I would do differently. I am considering work on a IO board specific to the project (RS232 driver, GPIO break-out, proper RX/TX LED buffers and potentially internal LiPo UPS). Glad there is renewed interest in the project as I still use it day to day :).

The Whitterm-220 (WT-220) is my latest project. It’s a clever terminal, in the sense that it aims to emulate the dumb terminals of the 80s but with the versatility of something produced now. The name comes from my inspiration for the project: failure to win a VT-220 on eBay. I decided it would be fun to make a homage to the VT-220, that would actually be useful – a not so dumb, or clever terminal – that would do more than simply parsing RS232 levels into Ascii characters.

Continue reading Whitterm-220 Clever Serial Terminal