Monday, July 1, 2019

Microchip PIC32 Harmony Bare Metal Programming

All Microprocessor manufacturers now provide some sort of factory sponsored C language tool set and they also provide some High Level Abstraction Libraries (HAL) to help users configure and use their parts ‘easily’ without having to spend days wading through register maps in 500 page datasheets.

When Microchip first released their PIC32MX parts they also provided a HAL library that they called the ‘PLIB” or “Peripherals Library” to help users along.

For instance to setup a PIC32MX SPI clock using the original PLIB implementation one would need to call this function,

     SpiChnSetBrg(chn, brg);

This is still better than having to dig into the data sheet to determine all the register names and addresses directly, but it isn't all that friendly either and you still need intimate knowledge of the hardware to set the ‘brg’ register to get the proper SPI clock rate.

After this initial PLIB library was released Microchip correctly realized that the 32 Bit Microprocessor market is a commodity market and that they would have to differentiate themselves in some way. Since the hardware is a commodity, they chose to differentiate themselves with the software layer.

They named this new software “Harmony’ and discontinued the original PLIB concept going forward.

In Microchips marketing literature they touted Harmony as the “Do all, end all Framework” as it encompasses not only configuring the chips peripheral devices but includes a lot of higher level system functions like: File Systems, Graphics, Bluetooth and RTOS support to name a few, all under one roof.

Confusion Reigns, sowing Dis-Harmony

This has all caused some confusion as many people now think that to use Harmony means: Bringing in a lot of ‘Framework Baggage’ - this is simply not the case and since Microchip has not sought to clarify this, the rants about Harmony being just a lot of ‘Framework Baggage’ continue unabated.

What Microchip needed to do was write a simple application note describing how to use Harmony as a simple chip configurator or how to use harmony in ‘Bare Metal’ mode. Harmony is a decent chip configurator, about the same as everyone else’s and it is way better than resorting to the ‘Assembly Language’ approach of writing all the peripheral libraries yourself from register maps.

So I will take it upon myself to write a brief tutorial on what Microchip should have done some time ago to clarify the situation.

Note: This tutorial is based on Harmony 1.4x and 2.0x, Harmony 3 is still being flushed out, but I would expect it will follow that same basic principles as Harmony 1 and 2. Currently (July 2019) the first release of Harmony 3.0 just adds support for the Atmel ARM Chips.

The Missing Application Note: “Using Harmony as a Chip Configurator in Bare Metal Mode”

Using Microchip Harmony as a chip configurator will allow speedy configuration of nearly all of the peripherals in a PIC32 microprocessor and also stub out an application that will at the very minimum will get the chip up and running. Harmony will also setup the proper header paths so that the current High Level PLIB commands correctly target your selected chip. Another advantage of using harmony is in maintenance and updating the application later, since all the links in the libraries will be correctly kept up to date as the chip configuration or even the chip itself changes.

Prerequisites: You should be familiar with both of these Microchip provided tutorials,

     “MPLAB Harmony Tutorial – Creating Your First Project”
     “Creating a “Hello World” application Using the MPLAB Harmony Configurator”

These tutorials will help you in figuring out the steps required in operating the Harmony Configurator IDE and as with every manufacturers configuration solutions, there is at least a days worth of learning curve that needs to be overcome before you can be proficient and get off on your own. The tutorials above will help you through that first day learning process [1].

We will only be discussing the proper setup of the peripherals and how to get the generated application to “Bare Metal Mode” in this note using the SPI as an example.

Setting Up the Clock and IO Pins

Follow the procedure in the tutorials listed above to set the Clock and IO pins. There is no difference between the “Bare Metal Mode” described here and the procedure as described in the tutorials.

Setting Up and Using Peripherals

Microchip provides two types of drivers in Harmony: “Static” and “Dynamic”. Refer to Reference [2] for a discussion of how each driver type works. We will be focused on “Static” drivers here as they provide the expected “Bare Metal” performance with no additional software overhead required.

SPI Example

A basic “Bare Metal” setup would be for a plain old SPI configuration, just “Point and Shoot” with no interrupts, FIFO’s or external buffers, etc.  As you gain experience you can add those later if you wish either by yourself or with Harmony’s help. Configuring most peripherals in Harmony is done in 3 easy steps.

Step 1 - Expand the “Drivers” section as shown below

Step 2 - Expand the SPI section as below,

The settings shown above will be the simplest possible. For instance,

Standard Buffer: Not all PIC32’s have an enhanced (or FIFO) buffer, so using the standard buffer (or FIFO disabled) is safest.

8/16/32 bit Mode: Set this to what your SPI Devices expect as far as bit width. This parameter is easily changed on the fly using other PLIB_SPI commands.

Number of SPI Instances: Set this to the number of SPI peripherals you will be using. Here we will just be using one.

Step 3 - Now you have to configure one or more of the actual SPI hardware peripherals of the chip as shown below,

Here “Instance 0” is set to the Physical Hardware SPI peripheral: “SPI_ID_1”. Most of the other information is as described in the data sheet. Of note: it is nice to be able to set the SPI Clock rate and not have to worry about the frequency setting registers directly. Also of note, just because I set in this example 1 MHz, it does not mean that the SPI clock will end up being exactly 1 MHz. The configurator will simply pick the closest register settings that get closest to 1 MHz. If you want to know exactly the clock rate you can find the clock rate equation on the parts data sheet and calculate what it will exactly be from that.

For the “Clock Mode” setting there are 4 options, while most people are familiar with the usual SPI terminology of “SPI Mode 0” through “SPI Mode 3” or the slightly more descriptive: “CPOL” and “CPHA” for clock polarity and clock phase [4]. The figures below should help with the SPI setup.

Harmony configurator setting for SPI Mode is selected from one of the 4 options from the dialog as shown above.

Table 1 - The table above will help in translating from the standard SPI Mode number to the Harmony descriptive text.

We have now setup a basic instance of SPI peripheral #1, at this point we should have also configured the clocks and IO pins as per the earlier tutorials, this includes setting the SPI Peripheral #1 to the proper IO pins on the chip. Save and generate the code as per the tutorials, then do a compile to make sure everything is OK.

What Harmony Builds

Before we can get into using our “Bare Metal” SPI we need to decide what portions of the generated Harmony Code we will use.

As can be seen below Harmony builds for us a: main.c, app.c and its corresponding app.h files.

Figure 6 - The most important Harmony built files that we will explore here as shown in the MPLAB-X IDE.

When the program first starts it loads and runs some C startup code, then execution starts at main() and this is located in the file “main.c” as shown,
Figure 7 - The main() as built by Harmony. You can’t get much simpler than this.

Harmony has built a completely working project at this point that will,

1) Configure the clocks and hardware as setup by the user via the function SYS_Initialize().
2) Enter an infinite loop that calls a function called SYS_Tasks().

Taking a look at SYS_Initialize() we see another easy to understand function,

Figure 8 - SYS_Initialize() function as built by the Harmony Configurator. This unction is where all the clocks and peripherals get initialized.

As can be seen in the SYS_Initilize() function above, its function is straightforward. This is where the chip and any peripherals get initialized. First the clocks are initialized, then the ports are initialized, then you can see that the SPI instance is initialized. Note: This SPI initialization function contains all the commands to initialize the SPI that we set on the “SPI Driver Instance 0” Harmony configuration page above, it can be very informative to navigate to and look at this function if you have the need to change anything on the fly later in your program as all the configuration is done via PLIB_SPI functions.

The interrupts (if any) are next. At the very end we see that a call is made to a function APP_Initialize().

APP_Initialize() is located in app.c. APP_Initialize is a great place to set any user initialize functions that your application may need such as, initial conditions or flashing splash screens, etc. It is the place for anything that needs to be run or set once at the beginning of your application.

Figure 9 - As initially built, APP_Initialize() has some comments and sets the default state of the ‘roughed out’ state machine that Harmony builds at first. If you are not going to use the state machine approach, you can delete all of the contents of APP_Initialize() and put in here anything that your application needs to run once at the launch of your application.

Now that we are done with APP_Initialize() and SYS_Initialize() we are back in main().

The next part of main() (See main.c above) is a forever while loop that repeatedly calls SYS_Tasks(), drilling into SYS_Tasks(), which is located in a generated file named: system_tasks.c we find the following code,
Figure 10 - SYS_Tasks() Code as generated by Harmony.

As can be seen in the function SYS_Tasks(), there is a call to “Maintain Device Drivers”, but since we have set the driver to ‘Static’ and will be using the driver directly this function really will do nothing more than check a few flags and the return.

The next call is to APP_Tasks() which is located in the file app.c.

APP_Tasks() stubs out a basic State Machine that we can either use or not as shown below,

Figure 11 - App_Tasks() as the default build generated by Harmony.

Many (Most?) people don’t like to use a State Machine, preferring instead to use a ‘Big Loop’ implementation, no worries, this is easy to fix as shown below,

Figure 12 - APP_Tasks() modified into a ‘Big Loop’ as many people prefer.

If you are familiar with how the Arduino stubs out a sketch (program) then all this should also look familiar to you. Think of APP_Initialize() as the Arduino function: “setup()” and the APP_Tasks as the Arduino function “loop()”. As with the Arduino if you return from ‘loop()’ the hidden Arduino main() will call it again, similarly if you return from APP_Tasks() the Harmony supplied main() will call it again. Many people seem to not like ceding even that much control to Harmony, and alternatively, you can simply put the while(1) big loop in APP_Tasks() directly as shown above.

Adding the “Bare Metal” SPI commands

Harmony has a big advantage on many competitive software HAL’s in that they actually have good and up to date documentation, both printed and in Compiled Help HTML (CHM) formats. The CHM help file is located at,


Naturally, you will have to change the path segment “v2_05_01” to your specific version of Harmony path.

I prefer to use the CHM help file format as it is searchable and example code is easily clipped from it.

Searching the CHM file for SPI leads one to a document titled “Library Interface” which describes all the possible SPI API calls available to you in the Harmony HAL.

Figure 13 - The “help_harmony.chm” compiled help file is very easily searched to find the driver API calls and example code. Here we easily locate the SPI library information.

As an example lets find the call to change the SPI clock speed to contrast how much easier the Harmony PLIB HAL is compared with the original PLIB library call presented earlier.

Figure 14 - A small portion of the help docment that is used to set a SPI Peripherals Clock speed (or as they call it: Baud Rate).

To use this you only need to know the peripheral bus clock speed that you set in the Harmony Clock Configurator, which in my case was 100 MHz as I am using a PIC32MZ chip that is running on a 200 MHz system clock. Then you also input the desired SPI clock speed and the function will do the rest.

We also need to get the proper module_id index, if you touch the blue hyperlink as shown in the figure above, the help file will show you the definition for the SPI_MODULE_ID enum as follows,
Figure 15 - Touching the SPI_MODULE_ID enum hyperlink in the CHM file will bring up the definition of that enum.

We know that we setup the SPI module as the physical peripheral #1 so we would want to use: “SPI_ID_1” in all our code when working with this peripheral.

Let’s add this SPI clock rate set to our APP_Initialize() code as follows,

Figure 16 - Making a PLIB_SPI function call to set the SPI_1 clock speed to 10 MHz. The 100 MHz is the SPI Peripheral bus speed.

You will notice that I did not have to add in any extra header files for this PLIB_SPI function to be recognized. Harmony has done that setup for us the moment we told it to use the SPI Driver library and placed the proper header files in “app.h” for you.

As you go around exploring in Harmony you will also find that you can get the clock speeds through API calls. In this instance you can get the SPI default clock source PBCLK2 value by using the call,


Then the code example can be made more robust to future clock changes by making the call like this,

Figure 17 - Changing the SPI Clock Speed using not only the PLIB_SPI function, but also getting the peripheral bus clock frequency at runtime.

Notice that you do not need to add in any header functions for the library “SYS_CLK” either as Harmony has added those linkages for us in “app.h” when we added the specific driver to the Harmony Configurator.

Now let’s add a SPI write command to the ‘Big Loop’ that we wrote in APP_Tasks(), as shown below,

Figure 18 - The function APP_Tasks() above writes byte 0x55 to the SPI port once every second, forever.

At this point some have asked: “Isn’t using the registers directly faster and smaller than calling these PLIB functions?”, the answer is: “Probably not”. The simple reason is that the definition of most of these PLIB functions is to include an ‘inline’ declaration. This tells the compiler to prefer to ‘inline’ the generated code instead of making a function call. As long as the XC32 compiler optimization level is set to ‘O1’ or greater, then inlining of functions is enabled. Note: You will find that optimization level ‘O1’ is quite aggressive and really minimizes the generated code.

Figure 19 - Almost all of the Harmony PLIB statements are marked to the compiler as “Inline”

PLIB_SPI_BufferWrite() is declared “inline” by this “PLIB_INLINE_API” statement.

PLIB_SPI_BufferWrite() then calls another abstracted function and that function is also declared as ‘inline,’ so the chances of really having these PLIB function calls end up as ‘inline code’ is pretty high.

Other Useful SPI Functions

Browse around the help_harmony SPI “Library Interface” for other useful SPI functionality. Basically if you need to do something with the SPI it will be there, including a function to check to see if the SPI is done transmitting the last character,


This is a useful command to check to see if the SPI hardware is done with the last character being sent before sending another character.

Other Useful PLIB Libraries

Other common PLIB libraries are available for nearly all the PIC32 series peripherals. To find the overview page of all of them, simply search for: “Peripheral Libraries Help” in the help_harmony.chm help file as shown below,

Figure 20 - This simple search will get you to a list of all the PLIB API’s in Harmony. 


I have shown how to use the Harmony Configurator and the Harmony Static Peripheral Libraries as a means to do “Bare Metal” programming on a PIC32 device peripheral. Step by step, the code startup process was described and followed via the Harmony generated application files: main.c, app.h and app.c. Also shown was how to find and use the other “Bare Metal” or as Microchip Harmony calls then the “Static” peripheral drivers.

In future projects you can simply setup everything in Harmony, generate the code, then focus on only App_Initialize() and APP_Tasks() and you don’t have to worry about anything else that Harmony generates or calls first. This is pretty much what every Microprocessor suppliers code configurators do and the advantage of using Harmony is it has setup a consistent HAL layer of software that is portable between projects and even between most chips in the PIC32 series.

Harmony when used this way does not overwhelm the chip with a large or burdensome ‘Framework’ as many people seem to think and fear, in fact the Harmony ‘footprint’ on a PIC32 is quite small and the biggest point of all: The Harmony PLIB’s get your project running quickly with very little detailed knowledge of the hardware registers required.


[1] Microchip also has a Youtube Channel where you can find some useful Harmony Tutorials.

[2] Harmony static and dynamic driver explanation,

[3] Wikipedia article on SPI,

Article By: Steve Hageman /

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.

Note: This Blog does not use cookies (other than the edible ones).

Monday, June 24, 2019

Do Your Customers A Favor – Make your Data Plots Useful

Make your data sheets more useful by providing graphs that actually help your customers. How so? Read on...

Example 1 -

Jim Williams and Guy Hoover designed a low distortion oscillator some time back [1]. This application note made use of a LED controlled Photo Resistor that was used to adjust the gain of the oscillator. This part has since gone obsolete and the replacement part provides a curve of LED Current Vs. Resistance that looks like this,

Technically the above curve is correct, but, the interesting part of the curve is in the range of 0 to 5 mA, that is where all the useful resistance change happens. If the curve is plotted on a log chart then it becomes much more customer friendly or useful as shown below,

Same data, simply plotted with the X-Axis set to logarithmic. Now the curve is useful to the end customer, who incidentally is a circuit designer who needs to know how the resistance changes in the useful control range of LED current. For extra credit: Also plot a curves of the response over temperature as this information is needed for a complete circuit design.

Example 2 -

A certain well respected manufacturer of IC’s sells a low noise OPAMP and provides a curve like this one to document the Voltage Noise Vs Frequency. As in the last example the interesting part of the
curve to any designer is the very first data point of this chart, not the 99.9% shown.

This curve is better than most manufacturers in that it seems to be a 'Real' instrument trace instead of the 'Artists Conception' that we normally see on data sheets, but the useful noise detail in the low frequency 1/f region is obscured. This could have been easily solved by switching the instrument to measure ‘Log Frequency' mode. I have yet to see a low frequency FFT analyzer that doe not include this setting.

Usually Voltage Noise versus Frequency of an OPAMP is presented more usefully as this one above that I made for a LT6910-1 at a gain of 100. The interesting portion of the curve is in the 1/f region. Again, Log Scaling for frequency fixes the problem.

Example 3 -

It is important to have some 'domain knowledge' of your customers needs and what you are measuring. Here is a plot for an wide band receiving antenna that is similar to one I once was sent by another engineer. He measured this antenna and sent me the plot as a Smith Chart because that’s what he figured RF engineers wanted to see – a Smith Chart.

The above Smith Chart is a valid plot, but about all you can determine is that the antenna does seem to have several minor resonances going on and at one point, low in frequency it is actually pretty close to 50 Ohms (Where the marker is). Anything else, really is impossible to determine from this presentation.

Better to plot the antenna’s SWR [2] over the same frequency range as above, now you can see that the antenna is resonant at about 300 MHz and has a decent SWR (< 5:1) for receiving applications in the frequency range of 800 – 1200 MHz. Further I can determine what the reactance is at any frequency by the common SWR formula,

Where Zo is the characteristic system impedance which is usually 50 Ohms for RF work and ZL is the load impedance, in this case the antenna impedance at a given frequency [2].


It is really easy to actually help your customers, even if you don’t have the specific domain knowledge that they have. You can (and should) always look at competitors data sheets and use the best available format for each curve or table. As a sanity check, take your data sheet to a few customers and ask them what they think, this will provide immediate and valuable feedback.

As a final note: It is difficult for any manufacturer to keep everything up to date, as silly errors invariably creep in. Hence feedback is essential. Most datasheets that I now see have a HTML link to a help, feedback support site or email printed right on them, usually in the data sheet footer. There is no better way to get feedback than to ask for it and really no better feedback than from your customers right then when they are reading your data sheet and trying to use it.


[1] Linear Technology Application Note 132, “Fidelity Testing for A to D Converters”

[2] Wikipedia article on SWR.

Article By: Steve Hageman /

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.

Note: This Blog does not use cookies (other than the edible ones).

Saturday, June 1, 2019

Tame that Ringing in Switching Power Supplies

I recently read an application note by one of the big three semiconductor companies about a low EMI switching power supply. Normally, low EMI means that the Switching Power Supply IC has controlled slew rates on the power switch to lower the rate of change of the switching voltage to lower the high frequency content of the switching output waveform. This works very well and is a sure step in the right direction of making a EMI quiet design.

This application note showed some actual waveforms and I immediately spotted another source of EMI that was not addressed. The ringing that can be caused over the power switch or catch diode, or in transformer designs it can be exasperated by the leakage inductance in the transformer as shown in figure 1.


Figure 1 – Switching regulator noise is not just confined to the power switch rise and fall times. EMI is also produced by ringing waveforms as shown in the figure clipped from a semiconductor companies application note. This damped ring looks to be about 1 or 2 uSec period which would correspond to a 500 kHz to 1 MHz peak in the EMI signature produced by the design.

The ringing waveform of figure 1 may or may not be an issue in the final design, but I have seen many instances of otherwise well designed switching power supplies being overwhelmed by this type of noise, especially if it is to be used in any type of design that has an intermediate signal processing frequency band that is somewhere around the ringing frequency. For instance, a ring like this would easily be seen in the passband noise floor of my DSP based Lock-In amplifier [1].

Causes of Spurious Ringing

The ringing is caused by parasitic elements in the Power Switch, Catch Diode and output inductor all acting together to to produce a parasitic ring. This ringing in a switching power supply is more frequent when the output inductor runs ‘dry’ or is operating in the discontinuous conduction mode (DCM). The reason being that when the inductor runs dry, the catch diode and main power switch both stop conducting and go to a high impedance state which allows the high frequency parasitic ringing to take place. The ringing is normally not problematic by itself and usually never causes any possible over voltage damage because it is almost always below the switching voltages anyway, so it is often ignored.

The instant the power switch turns on again the circuit impedance is immediately lowered and the ringing is stopped. In transformer based designs the ringing is usually greatly influenced by the leakage inductance of the transformer.

Spurious Ringing Mitigation

To show the ringing, I made a simple model of a buck converter power stage using Tina-TI [2]. I did nothing special and just threw together some appropriately sized components as shown in figure 2. Upon running the simulation, sure enough the ringing appeared right on que, as shown in figure 3.


Figure 2 – A simple Tina-TI SPICE Simulation model of a Buck converter was thrown together to show the ringing.

Figure 3 – A Transient simulation was run and on the circuit of Figure 2. The ringing appeared right on Que!

The solution to the ringing is as old as switching electronics itself. In old time ‘relay’ or ‘contactor’ switching circuits, to quench the parasitic inductance and capacitance of a contactor that when opened might cause a damaging spark, a circuit called a ‘Snubber’ was included across the terminals to add some controlled impedance that would counteract or swamp out the parasitic elements while at the same time be a DC block so that no steady state DC power was used [3].

In this instance we just need to add enough damping impedance such that the high Q circuit formed by the parasitic elements is damped much sooner than they would be naturally. We can’t always get rid of all of the ‘ring’ but we can sure keep it to one or two cycles at best, thus substantially reducing the EMI footprint.

The basic circuit was modified by adding two Resistance / Capacitance snubbers across the catch diode and the main power inductor as shown in figure 4. Simulation of figure 4 shows that the snubbers have done their job and have substantially reduced the ringing to around a single cycle and at a lower frequency as shown in figure 5.

Figure 4 – Adding two RC ‘Snubbers’ in the buck regulator circuit can really control the ringing. Sometimes a single snubber will work and sometimes several are required it all depends on how exactly your circuit is designed, used, built and even on the layout.

Figure 5 – Running a simulation on the circuit of figure 3 shows a vast improvement in the ringing which is now damped quickly in less than two cycles. This will obviously reduce the EMI footprint of the design.

I knew from experience what values to choose for the Capacitors and I iterated in on the resistor values to minimize the ring. This is actually easier with actual hardware than in software. On an actual hardware circuit I normally get a small, single turn potentiometer of 100 or 200 ohms and solder a reasonably sized capacitor to it (Here I empirically found that 2.5nF was the optimum size), then I tack solder this across the circuit nodes, all using very short leads. In ten seconds I can tweak the potentiometer and see the effect. If need be I can make another snubber by using the same setup and a different capacitor value. In just a few minutes I can have the circuit ‘empirically’ optimized [4].

These values work well for a 100 kHz switching regulator, you might have a capacitor in the range of 1 to 3nF, the resistor values will always be less than 300 ohms, normally in the range of 25-150 ohms. For a 1 MHz switching regulator divide the capacitor value by 10, but the resistor values will still be in the same range.

Similar snubber implementations can also be used to mitigate leakage inductance induced overshoot on the main power switch in transformer based designs and across rectifier diodes to reduce the snap off that happens with diodes from their reverse recovery effects all of which can add to EMI issues with power supplies.


We have seen how the EMI footprint can be improved with the application of a snubber. What are the downsides? The snubbers add AC impedance to the switching nodes and as such they will add AC power loss to the switching waveforms. If a few milliwatts are not a big issue then there is no harm. If power is everything to you, then you have to be careful and carefully trade-off the EMI footprint with you tolerable power loss, which will require more time to optimize everything.

Taking it to the limit

In some killowatt switchers I have seen where the snubbers consumed 10’s of watt’s. This is a lot of power to just waste as heat, and the solution there was to take that snubbed power and add some small DC/DC converters to take that power and convert it back to the input or output circuits to aid in the overall efficiency. The snubber power recovery DC/DC converters are bigger in this instance than most of us use for our main power supply! Wild!


[1] A DSP Based Lock-In Amplifier,  Hageman, Steve,

[2] Tina-TI, SPICE Simulator, Texas Instruments, inc.

[3] The old company Sprague Electric used to make a marvelous array of ‘Snubbers’, one for every common use, some even with built in spark gaps, turning ‘snubbing’ into a true Art form. The term ‘Snubber’ is also used by fluid flow engineers to denote methods alleviate fluctuations and ‘ringing’ in fluid transport pipes.

[4] Yes you can find articles that will go into great detail on how to use circuit analysis to get to at least a nominal starting point for the values of the RC Snubbers, but since a large portion of the ringing is based on poorly specified or even unknown component parasitics, including the PCB layout and even the PC stackup, I find it easier to just empirically get the job done. Your: “mileage may vary” as they say, so approach the problem anyway you want – both will get to a solution eventually.

Article By: Steve Hageman /

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.

Note: This Blog does not use cookies (other than the edible ones).

Monday, May 6, 2019

Electronics Design Lifecycle: From Discrete, to Hybrid, to IC to gone...

While looking for Op-Amp noise articles, I ran across this old Analog Dialog from 1969[1] that had an interesting new product announcement in it.

Press release from the March 1969 issue of Analog Dialog announcing a very fast 10 bit, 1 uSec ADC [1]. Clip copyright Analog Devices, 1969.

In the Analog Dialog there is an announcement that Analog Devices bought Pastoriza Electronics and one of their products was a 10 Bit A/D converter that made a 10 bit conversion in 1 microsecond. The Pastoriza ADC-F was a 4.5 x 2.5 by 1 inch “Plug In” form factor. This was all back in March of 1969.

Interestingly, one of my first projects as an engineer was to do this very thing again. In 1980, I was tasked with designing a 10 bit, PCB mount, modular ADC that would convert 10 bits in 1 microsecond all in a 2 x 4 x 0.4 inch modular package.

Another engineer working for the firm had designed a fast 8 bit R/2R based DAC, so I took that, added 2 more bits and some more precision resistors, an AMD LS-TTL 2502 Successive Approximation Register (SAR) IC, a Precision Monolithics CMP-01 Comparator as I recall plus, some other spices and herbs and a few Tantalum capacitors. It worked decently and probably sold for $150 in 1980 dollars. At that time the majority of the modular business was in 12 to 14 bit data converters that operated at slower data rates.

This design used through hole components on a double sided PCB that was hand taped by a true artist, it looked great.

Moving up the food chain:
I then went to work for a company that was making Sampling Oscilloscopes for semiconductor testers and they were rebooting their product line to be 10 times faster then before. Since I was responsible for the analog signal processing electronics, I needed to come up with a 10 bit, 1 microsecond conversion ADC to replace the 10 microsecond converter that the previous product used. I knew that they didn't really want to have a design that they would have to calibrate and they had no room for a discrete design, so we turned to a smaller, but more expensive hybrid solution. Datel [2] made the same basic ADC as a hybrid package, probably 1 x 2 x 0.25 inches.

By this time I was testing the ADC on my newly acquired Apple ][ computer using some data acquisition boards that I had hand built - you have to love open architecture hardware and that simple and slow Motorola 6502 bus (and later ISA bus of the first IBM PC).

Using this setup I could measure and plot the transfer function of the whole front end including the ADC using the ADC Crossplot Test that was in use by all the ADC manufacturers at the time [3]. The idea was to dither the input across a few LSB's and convert the ADC LSB output bits to a voltage that was displayed on a standard Analog Scope, later the scope display was replaced with the Apple ][ monitor. With this setup you could find all sorts of “funny” things with ADC's operation like missing codes and non-monotonic behavior. This is still a useful and simple test technique today. The ADC input is basically DC, but the ADC runs at it's full data rate.

The Apple ][ belonged to me and I didn't want to leave it at work. I'm sure it was quite a show to watch me pack it up and take it home every night! Apple had one of the the first ‘portable’ computers. Although you could not carry it all at once.

By 1985 the whole ADC design could be made up of a few IC's (a DAC + SAR + Comparator and Reference voltage IC), bigger but a whole lot cheaper than the Hybrid. By 1995 a single IC could implement the entire ADC and that finally did in the majority of the Module and Hybrid business.

Today you can buy the Analog Devices AD7298, a 10 bit, 1 microecond ADC that is 4x4 mm, costs the less than the price of a Latte and runs off of +3.3 volts. My original design required +/-15 and +5 Volts at probably 500 mWatts total.

Today we mostly use very high quality sine wave ‘tones’ and run automated FFT’s on the converter output to see with our eyes distortion and signal to noise ratios. This is usually much more indicative of actual system performance than the cross plot testing. Although if you are making a 24 bit ADC for a weigh scale, then the Crossplot test is still an excellent method of testing ADC’s.

I found that I was first a ADC builder, then moved on to be a ADC user then I moved on to be a Historian of the whole business cycle.  :-)

Pastoriza was gobbled up by Analog Devices as was Precision Monolithics, Datel Data Conversion died. The companies where I designed the ADC and where I used the next generation of the very same thing I designed also died. Others came and went without so much as a whimper, but the industry chugged on, built on the body of knowledge that these pioneers painstakingly figured out.

The only really, relevant thing today is that Crossplot testing is still a viable technique of testing ADC’s!

[1] Analog Devices magazine, 1969

[2] Datel was another Massachusetts based electronics company making Modular, Hybrid data converters and later modular power supplies. The data conversion side of the business died, but the Modular power supplies still live on in name at least as the Datel division of the Murata brand. Datel also made digital panel meters and this too lives on as Datel Panel Meters of Chandler Az.

[2] See ADC Crossplot Test in, Analog Devices, “Testing ADC Converters”

Article By: Steve Hageman

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.

Note: This Blog does not use cookies (other than the edible ones).

Sunday, December 16, 2018

Low Noise Measurement Preamp


Recently I needed a low noise Preamp to measure voltage noise density of some low frequency amplifier circuits with my custom built FFT Analyzer [1]. This is surprisingly easy to do now with just a few IC’s from Linear Technology.

The basic specifications of what I needed are,
  • DC Coupled
  • Noise at 1 Hz   <=  10 nV/rt-Hz total in the measurement system.
  • Noise at 1 kHz <= 2.5 nV/rt-Hz total in the measurement system.
  • Frequency Range DC-100 kHz.
  • 1k Ohm input resistance.
  • Adjustable gain so that a wide variety of conditions can be measured.
  • Power from +/- 5 Volts.
  • Output Voltage at least +/- 2.5 Volts to drive FFT Analyzer Input
Some back of the envelope calculations suggested that I needed an overall gain of about 5000 for the Preamp to overcome about 90% of the FFT Analyzers input noise. With this in mind and to keep things simple, I picked a 2 stage preamp design consisting of a low noise OPAMP followed by a programmable gain amplifier.

The lowest voltage noise OPAMP for some decades now has been the LT1028 [1]. The low 0.9 nV/rt-Hz midband noise combined with the very low noise 1/f corner frequency was perfect for my needs. To expand the dynamic range of the preamplifier I added a post amplifier using the LTC6910-1 Programmable Gain Amplifier. The LTC6910-1 provides programmable gains of 1,2,5,10,20,50 and 100.

Setting the LT1028's gain to 52.1 V/V combined with the LTC6910-1's maximum gain of 100 combines for a maximum preamp gain of 5210 V/V [3].

Figure 1 – Using a low gain of 52 V/V on the LT1028 sufficiently overcomes the downstream noise and still allows for wide dynamic measurement range on even the highest gain settings. The overall gain can be set from 52.1 to 5210 V/V by programming the LTC6910. 

When measuring the noise floor of anything, the preamp noise is only part of the problem. It is equally important to have extremely well filtered power supplies and control lines to prevent,

#1 Spurious signals coupled in from the power supplies and showing up in the noise floor. As any switching noise that makes it way to the preamp will show up as a spurious peak in the measurement.

#2 Excellent damping and low impedance to prevent power supply feedback coupling and oscillation due to the large gains involved in the preamp. This is also important from one preamp channel to another as this design was ultimately a 2 channel design.

These two requirements are met with the application of the classic, simple and lowest of the low noise regulators, the: “Beta Multiplier” circuit. The circuit in Figure 2 is mounted close to the preamps and is in addition to the per-channel linear regulators on the main board. The combination of the two, then serves to help rid the noise floor of all but the most stubborn spurious signals.


Figure 2 – In any noise floor measuring system the preamp power supply is just as important as the preamplifier design. This adaptation of the classic and very low noise “Beta Multiplier” provides > 40 dB of isolation and very low noise at 100 Hz. The addition of the inductor provides continued rolloff well beyond the 100 kHz measurement bandwidth. High quality Tantalum’s must be used for the 220 uF capacitors.

The one downside of the Beta Multiplier is that it adds about 0.6 Volts of voltage drop. Hence the raw +6 and -5.5 Volt inputs end up being around +5.4 and -4.9 volts at the preamps voltage terminals in this application.

Since the ultimate usage of the preamp was in a dual channel design. To prevent coupling from one preamp channel to another, the circuit of Figure 2 was duplicated for each input channel.

To further prevent noise from coupling into the preamps noise floor, the LTC6910-1 control lines were heavily filtered and isolated from the microprocessors control bus. Control bus isolation was provided by using a MAX7317 I/O Expander in between the analyzer control bus and the preamp channels. This combined with the heavy filtering on the control lines at each LTC6910-1 provided the required isolation.


The preamp was attached to the FFT analyzer and the combined system noise floor was measured by shorting the input of the preamp.


Figure 3 – The overall system noise performance of a LT1028 and OPA140 version of the preamp with shorted inputs. The FFT Analyzers ADC and ADC Driver amplifier also add noise to the overall result.

The LT1028 input is suitable for measuring a large class of circuits since the useful measurement nodes tend to be low Impedance (i.e. regulator or amplifier outputs). However there are instances where the impedance is higher than the optimum source impedance of the LT1028 (which is quite low at around 160 Ohms @ 1 Hz). In these cases a higher impedance preamp is desirable. By simply substituting a JFET OPA140 for the LT1028, circuits up to the Megohm range can be measured. For comparison, the noise performance of both the LT1028 and OPA140 versions of the preamp are plotted together in figure 3.


The base Analyzer that this preamp was designed for has a mezinnine connector for the Analog input and utput circuits, this allows the overall instrument configuration to change with very little work. Just whip up a new Analog Input Board, add jst a few lines of embedded C code to the instrument application to 'teach' it how to run the new hardware, plug in the board. QED!


Figure 4 - The completed Low Noise PreAmp as implemented. The input used BNC connectors and both channels can clearly be seen. Plenty of room left on the board for future expansion.


Bonus Figure: Since Linear Technology does not publish low frequency curves of the LTC6910 Programmable Gain Amplifier. I have measured a typical device and present it here for a Gain of 100.


[1] Hageman, Steven C., “A Modern DSP Based Lock-In Amplifier”, 2018

[2] Linear Technology has a redesigned LT1028, the LT6018 but it doesn’t have significantly lower noise and unlike the LT1028 the noise isn’t 100% tested on every device.

[3] Clever readers will note that the LTC6910-1 does not have a minimum guaranteed Gain-Bandwidth product (GBW) that meets the required 100 kHz bandwidth at a gain of 100. I was only building a few of these preamps and the ones I had do meet the typical specification specification of 11 MHZ GBW, so I went with the typical specifications which met my requirements.

Article By: Steve Hageman

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.

Note: This Blog does not use cookies (other than the edible ones).

Friday, November 23, 2018

PIC32MZ/EF Pin Slew Rate Control

If you look very carefully at the PIC32MZ/EF processor data sheet you will find a few references to the ability to set individual pins Slew Rate. This functionality essentially changes the driver output current in several discrete levels. This then changes the achievable Slew Rate of the pin, or: “How fast the pin transitions from one logic level to another”. This is useful in controlling ringing on traces and meeting EMI emissions requirements.

While FPGA’s have Slew Rate control on nearly all their output pins, the PIC32MZ/EF only has this available on selected pins.

Two registers attached to the port registers control the Slew Rate of the selected pin and each pin can be set independently of the others.

The Slew Rate control registers are,

    SRCON0x, SRCON1x

Where ‘x’ is the port letter designation (A, B, C … K)

Figure 1: Section 12:2 of the PIC32MZ/EF data sheet gives a brief description of the Slew Rate functionality. Also note that the table lists: Slowest, Slow, Medium and Fastest – yet the enumerations in Harmony list these as: Slowest, Slow, Fast and Fastest. Showing just how hard it is to keep ‘comments’ and ‘code’ synchronized, using the same terms!

To find the ports/pins that allow this control, search the data sheet for: ‘SRCON0A’, B, C, etc… This should take you to the tables in section 12.5 of the data sheet titled: “I/O Ports Control Registers” (Be careful that you are looking at the proper table for the exact package of the device you are using). The SRCONx bits are currently listed at the bottom of each port register table.

The port pins that allow Slew Rate control on a PIC32MZxxxxEFx064, a 64 pin device can thus be found as follows,

    Port B: RB14, RB10, RB9, RB8 RB5 and RB3
    Port C: No pins
    Port D: No Pins
    Port E: RE3, RE2, RE1, RE0
    Port F: RF1, RF0
    Port G: RG9, RG6
Similar lists can be quickly made for the other package types.

It can be seen that this is not every pin in the PIC32MZ/EF-064 device. So what is the logic here?

#1 – There are a few high speed, 50 MHz SPI ports available on this device and they have specific requirements of what pins must be used for high speed operation.

    • 50 MHz Max on SPI2: Pins RB3 &RB5
    • 50 MHz Max on SPI3: Pins RB10, RB9 & RF0

    These Fast SPI pins are all Slew Rate controllable

#2 – The REFCLKOx pins can be mapped to Slew Rate controllable pins.

#3 – In PIC32 devices that include a DDR SDRAM interface, the drive strength of that interface is also controllable as a whole. See the Harmony enumeration: “DDR_PHY_DRIVE_STRENGTH”.

Controlling the Pin Slew Rate

There are several Harmony 2.x functions available to control the Slew Rate of the pins.

Note: See Harmony Help for exact details on using these functions.

* See if the Slew Rate functionality even exists for your PIC32 device,

* Get the current Slew Rate setting of a port pin,

* Set the Slew Rate for a pin or a group of pins on a port (i.e. Channel),

The Slew Rate is specified as one of the following enumerations,

The ‘channelMask’ is a UINT16 that has a ‘1’ in the pins bit position for the pin you want to change, otherwise the pins strength remains the same and is not changed.

For example, to set just RB3 to the ‘Slow’ Slew Rate,

To Set pins B3 and B5 to the ‘Fast’ Slew Rate,

The various PLIB functions above must be called manually in your PIC32 Project as there are currently no Harmony Configuration Settings for the pins Slew Rates.

This is easy enough to do with a ‘Standard’ Harmony Application in the App_Initilize() function as shown in Snippet 1 below.

Snippet 1 – An example showing how to set an individual pin to a selected Slew Rate in the Harmony App_Initialize() function, this function is located in the file App.c.

What Does Each Setting Do?

The PIC32MZ/EF data sheet is a little vague on the exact nature of the various Slew Rate setting, so I made some measurements on one of my proto boards.

First thing is to compare a normal pin with a Slew Rate controllable pin. Note that the default Pin Slew Rate is set to Fastest for the Slew Rate controllable pins (See the note on the bottom of figure 1).

Using a standard CMOS loading test circuit [1], I measured a normal pin and a Slew Rate controllable pin, a plot is shown in figure 2 and 3. The various Slew Rate settings of a fast pin are shown in figure 4. Table 1 summarizes all the results.

Figure 2 – Rise time comparison of a normal pin and a Slew Rate controllable pin at their fastest settings.


Figure 3 – Fall time comparison of a normal pin and a Slew Rate controllable pin at their default settings.

Figure 4 – Effects of the various Slew Rate Settings applied to a test pin.


Table 1 – Tabulated Slew Rates of the various Pin types and Slew rate settings.

Wrapping It Up

The Overshoot seen in the figures at the fastest pin Slew Rate setting is undoubtedly a result of my test fixture being less than optimal. Normally the Oscilloscope probe would be located very close to the devices driving pin to minimize the parasitic inductance of the trace. In my ‘Quick-N-Dirty’ test jig, I used a MINI32MZ PIC-On-A-Stick module, this interfaced to one of my own breakout boards. The length of the trace from the PIC32 pin to my Oscilloscope probe is approaching 1 inch and even worse for a fast pules is the 0.1” header strip that the pulse has to traverse from the PIC32MZ to my breakout board and test load. These header strips add quite a lot of inductance to the overall path.

This, through leads to a great demonstration of why Slew Rate control adjustments are so useful in digital applications. My less than perfect test fixture is a ‘real’ PCB and I have seen much worse designs than what I had, still look at the amplitude of that ring I was able to make in just an inch!

In the fastest setting shown in figure 4 that little, high frequency ‘ring’ can cause all sorts of EMI emissions issues. In the worst case the ringing can be so bad as show up on the leading edge of the pulse, or be so high in amplitude to possibly cause double clocking.  This is why the PIC32 devices that have an external DDR SDRAM interface have Slew Rate controls on all the pins associated with those ports. It is much easier to set the output pin Slew Rate to control EMI and ringing than to add, then adjust, a bunch of series resistors in each output line on a PCB to control the rise time and overshoot problems.

[1] The standard CMOS loading circuit is 15pF in parallel with 1 Megaohm to ground. The measured rise time of the Oscilloscope used was 1.2 nSec. The Oscilloscope rise time was not corrected for in the rise time plots. It is corrected as noted in the tabular results.

Article By: Steve Hageman

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.

Note: This Blog does not use cookies (other than the edible ones).