counter

UART Controlled Stopwatch Using an FPGA


Being able to interface an FPGA project with a device that has a serial port allows for a basic means of sending and receiving data between the FPGA and a PC. For this we need to implement a Universal Asynchronous Receiver Transmitter (UART) circuit within the FPGA system. You can then use a PC with an RS232 Serial port (shown above) to interface the FPGA with a PC, assuming your development board has the port and voltage conversion circuitry.

Because RS232 is a dated protocol that sometimes isn’t available on modern PC’s, another option is to use a USB-Serial converter chip, which connects to a USB port.

In this post I will detail a UART controlled stopwatch, designed for the Basys 2, using the same stopwatch implementation as in my previous post. To communicate with the PC through serial  we will implement a UART receiver and transmitter circuit, as well as a master control circuit that routes all the pieces together. We will then be able to control the stopwatch’s start, stop, and clear functions by sending ascii characters from the PC to the FPGA’s UART receiver circuit, and also send the current stopwatch time from the FPGA’s Transmitter circuit to the PC for viewing.

Continue reading →

ATtiny85: Debounce Your Pushbuttons!

The image above exemplifies why you need to debounce your pushbuttons.

When people push a button, they expect one reaction per push. Due to the springy nature that pushes back at you when pressing them, buttons tend to bounce around when pressed and released, which will mess up the signal from them.

For example, let’s say we have a button that we intend to output 0V (logic 0) when pressed, and 5V (logic 1) when unpressed. If we probed the signal coming from the button during the transition from pushing it down to letting go, we would expect an immediate and clean transition from logic 0 to logic 1. What we end up seeing instead is the capture above. Before the signal settles to a flat 5V, it bounces between the two logic states many times.

Imagine if this was the signal your TV received when you pressed a button on your remote. If the signal was taken as is, and a transition from 0 to 1 meant increment the channel, you would probably have an aneurysm trying to navigate to a specific channel. This is why we need to debounce our buttons!

Debouncing attempts to ignore any intermittent jumping between logic states during an actual intended transition from 0 to 1 or 1 to 0. This can be done in hardware, with RC circuits and Schmitt trigger inverters, or in software with just the microcontroller. Let’s focus on software debouncing for now.

In this post we will first consider how to read a pushbutton input and turn on some LEDs in response. Next we will use the same hexadecimal counter circuit used in the previous post, with a pushbutton used to increment the counter, first with an undebounced implementation and then with a software debounced implementation

Continue reading →

ATtiny85: Introduction to Pin Change and Timer Interrupts

Often when a microcontroller is being used, we want it to know when certain things occur, and then have something happen in response. A simple example is to have a pushbutton determine when an LED turns on.

One implementation that would satisfy this is called “polling”. Inside of the main while loop we could test the state of an input pin every loop iteration and turn on an LED depending on its state.

int main(void)
{
	initializePins();
	
	while(1)
	{
          if(pushbuttonPinIsHigh)   
	   turnOffLED; 
	  else                   
            turnOnLED;  
	}
	
	return 0;
}

 

The above psuedocode checks the pin state of an input pin connected to a pushbutton and depending on the state turns on or off an LED.

Polling a pin state becomes tricky when you have to do other things in your event loop, especially things that take a lot of time. If for instance you needed to send or interpret some kind of serial data, doing so would take many clock cycles. This would essentially add latency to the response time of the LED to the pushbutton, as checking the pin state would have the same priority as every other sequential task in the while loop.

Hardware interrupts allow for asynchronous handling of system events. If an interrupt is set for a pin, when the pin state changes the code execution in the main loop halts and the code inside an Interrupt Service Routine (ISR) function is executed.

Continue reading →

FPGA Reaction Timer

Reaction time is the duration of time it takes for the brain to interpret a stimulus and do something in reaction to it. The stimulus may be something visual such as a light turning on, something auditory such as a beep, or a touch cue such as a poke. The time it takes for the brain to interpret a stimulus and respond to it can be used as a basic benchmark to measure and compare mental acuity.

We will be implementing a reaction timer on an FPGA that turns on an LED after a psuedorandom period of time, and uses a pushbutton as a reaction input. There will be 3 input buttons: clear, start, and stop. The system will begin in an idle state waiting for the user to press the start button. When the start button is pressed, a random time interval will elapse before the LED turns on. When the LED turns on a reaction timer will begin counting the number of milliseconds until the user presses the stop button. When the stop button is pressed, the reaction time will be shown on a 4 digit 7-segment display in the format “0.000” seconds, up to a value of 9.999 seconds. The user can then press the clear button to reset the time display and go back to the idle state.

For this project we will be using the Basys 2 FPGA development board to implement the design, as it has the 4 digit display, pushbuttons, and LED that we need onboard.

Continue reading →

ATtiny85: Blinking Without Clock Cycles


In the previous post we learned how to blink an LED with an ATtiny85 by using a _delay_ms() function to halt the program execution after turning on and off the LED. The downside to this approach is that the _delay_ms() causes our code to hang up while the function spins in a loop up to the specified time. This is a waste of CPU clock cycles, and makes doing anything else in the event loop nearly impossible. Let’s stop the pointless spinning.

In this post I will introduce the two timer/counter hardware peripherals that are inside the ATtiny85 chip, and show how we can offload the job of blinking an LED to one of them with the added benefit of using no clock cycles on the task. This frees the CPU up to do whatever else we wish while our LED reliably blinks away. If you are coming from a typical Arduino upbringing, this sort of flexibility and power is what makes learning how to truly program a microcontroller and its peripherals worth the effort.
Continue reading →