Building a 5 kHz PIC-based Oscilloscope

In a [»] previous post about the implementation of RS232 connectivity for the PIC to a computer, I briefly talked about a method that could be used to substantially increase the transfer speed between the microcontroller and the computer. At the time it was only a theoretical procedure but I have now validated it through experimentation.

I will propose here to build a 11-bits per sample, 5 kHz oscilloscope/data-logger unit based on a PIC16F688 with a 20 MHz crystal. I will not cover the data acquisition part of the circuit which has already been discussed in the [»] analog resolution doubler circuit post and I will solely focus on how to achieve maximum transfer speed through a technique known as task switching. I will briefly cover hardware interruptions and show how to use them in a quite elegant way.

Building an oscilloscope is relatively simple in its principle because all one has to do is to record analog voltages using an analog-to-digital converter and send it to a computer for display/storage. Some oscilloscopes have fancy features such as gain selection, multiple inputs, high resolution and so on. Here, I will assume a very basic oscilloscope with only one channel input and no gain selection. But you’ll see that it will already be full of surprises.

The basic implementation follows what we just said: read a voltage and send it through the communication channel. However, I have shown in the [»] RS232 implementation post that sending the data as-is is not such a good idea because the communication channel is not safe to data corruption nor data loss. By adding an identification field and a checksum field, we can assess that the data is not corrupted. We may also add a counter field to track data loss: data is considered lost if the clock field from the current packet minus the clock field from the previous packet is greater than one. This allows computing the correct time for each packet by multiplying the clock value by the acquisition speed which is fixed by the microcontroller. Ideally, missed data should not be displayed but they may be required for finite time delta computations such as in Fourier Transforms; if you run into such a case, you may interpolate missing data from the surrounding known ones.

With an 8-bits identification, an 8-bits checksum, an 8-bits clock and an 11-bits data payload, we end up with 5-bytes packets which requires about 0.48 ms to be sent at 115200 bauds. Considering the time required for analog-to-digital conversion (minimum 0.05 ms on a PIC16F688) and the checksum computing (let’s say 0.01 ms for 5 bytes), each sample would require about 0.54 ms to be sent which limits the overall speed to about 1.8 kHz. And that’s all! It’s the maximum speed achievable for an 11-bits data with 5-bytes packets at 115200 bits per seconds. We may increase the speed by a little by packing data such that it fits into a 4-bytes packet but it would only allow going as high as 2.2 kHz. In practice, I have found that the ADC conversion speed is never that good when operating with C compilers so the real speed you would obtain when implementing that will be somewhat lower, like ~1.6 kHz.

But I promised you a 5 kHz acquisition speed, so where is the trick?

If you look at our basic implementation, you will notice that we make a very bad usage of communication bandwidth in terms of payload data because only 30% of the packet contains the sample data bits (35% when packed). If we could add more samples data into one packet, we could save the identification, checksum and clock field for several samples and increase the information ratio in our packets. For example, if we send two samples in one packet we would have 7-bytes packets containing 22-bits of information (40% when packed); 7-bytes would require 0.67 ms to transfer, about 0.1 ms data conversion (2 samples) and let’s say about 0.015 ms for the checksum which make a total of 0.78 ms for two samples and so an average 2.5 kHz transfer speed per sample! So even without packing, we have increased our theoretical limit speed from 1.8 kHz to 2.5 kHz just by grouping samples into a single packet. The situation gets even better as we keep adding more samples such as represented on Figure 1.

With an infinite number of samples per packet, we reach a limit case where the sizes of the identification, checksum and clock field become meaningless in regards to the samples data. In our case, the limit speed is about 5.2 kHz for 2-bytes data (7.6 kHz when the samples are packed together). It is interesting to note that 95% of that theoretical value is already reached with 29 samples per packet. In practice, we will be limited by the memory of the microcontroller which can be quite small (a few hundred bytes in most cases).

However, this is too beautiful to be that simple because we cannot just acquire N samples and then transmit them since we would have burst of data followed by silences such as represented on Figure 2.

On Figure 2 we can see some signal that is being read by the ADC for 12 samples period which are then send to the computer before the next 12 samples are recorded. During that transfer time, samples are missed. This is clearly something that you want to avoid because it will ruin any Fourier Transform algorithm which requires constant time steps and it is also a rather stupid behaviour for an oscilloscope to miss half of its data!

The solution is to use two buffers such that one buffer is filled with data while the second buffer is being sent to the computer. That way, no data are lost. The mechanism is inspired from 3D Graphics technology where awesome 3D scenes are rendered to a front buffer (a copy of your screen display in the RAM) while your screen is actually displaying the content of a back buffer. When the scene has finished displaying into the front buffers, the two buffers are swapped such that the front buffer now becomes the back buffer and vice versa. In 3D displays, this allows prevention of flickering.

I will use here the same terminology, and so a front buffer will be filled with the data being read by the ADC unit while a back buffer loaded with previous samples will be sent to the computer. The only requirement is that the back buffer empties faster than the speed at which the front buffer is being filled (in the other case, we would have a buffer overrun condition). In terms of implementation, we create two buffers (called “Buffer 1” and “Buffer 2”) and two pointers which are the front and back buffer pointers. To swap the front/back buffer, we will then only have to swap the pointers which is much faster than actually swapping all the buffered data. The new acquisition is represented on Figure 3.

On a computer, we would simply implement this using two threads which would run concurrently in an asynchronous way. However, PIC microcontrollers do not have asynchronous capabilities so we have to use a second trick (which is the core trick of this article by the way). The idea is to use hardware interruptions of the microcontroller to create a task switching pattern.

But let’s first review how interruptions work.

Hardware interruptions (or interrupts) are a mechanism that makes the microcontroller jump to a fixed address when some conditions are met. It’s like when you are making coffee and someone knocks on the door: you stop thinking about your coffee cup and go answer. In the case of the microcontroller, it’s exactly the same but with the microsecond precision. It really jumps to the interruption address at the exact moment the condition occurs, not when it considers that it’s idling or that it is now okay to cooperate.

Microchip has implemented a lot of various interrupt conditions in its microcontrollers such as when data is being received by communication channels, analog conversion is done, the timer overflows, ... Here I will use two of them: timer overflow interruptions and “analog conversion done” interruptions. I will set the Timer 0 to create an interruption every 204.8 µs (1024 cycles at 20 MHz) and launch an analog conversion on that occasion. Then the processor will idle until the analog conversion done interruption is triggered so the data can be filled into the front buffer. The processor will then idle until the next timer overflow occurs. The “idle time” will then be used to send the back buffer to the computer. The mechanism is displayed on Figure 4.

That way, data will be sampled every 1024 clock cycles which makes a 4.88 kHz acquisition speed. Technically speaking it is possible to create a timer overflow interruption at faster rate by setting the Timer 0 to a known value after each overflow (for example to 0x06 to create an interruption every 1000 cycles to achieve a pure 5.00 kHz) but this require a precise control of the instructions time which is difficult to get when using a C compiler. When leaving the Timer 0 as it is, we are guaranteed to have a precisely known clock frequency of 5 MHz / 1024. This is the reason I’ve used a 4.88 kHz and not the 5.00 kHz although the circuit could go that far (which I measured to be true).

The code itself is relatively easy and is given below:

It is a retranscription of the concepts described above. I have added a buffer overrun detection which tells the computer if some data are skipped because the sending operations were too slow for the acquisition speed. I found this quite useful when developing the code because it allowed me to check if the data acquisition speed (i.e.: the Timer 0 overflow rate) matched or not the transmission speed.

Concerning the code for the computer, it is based on the post I wrote about [»] RS232 communication and is left without commentary:

Oh, by the way, the signal data from Figure 2 and Figure 3 are actual data got from a [»] 250 Hz sine generator circuit so you can see it’s working pretty fine ;-)