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.

Summary:
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!

References:
[1] Analog Devices magazine, 1969
http://www.analog.com/library/analogDialogue/cd/vol3n1.pdf

[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”
http://www.analog.com/library/analogDialogue/archives/39-06/Chapter%205%20Testing%20Converters%20F.pdf


Article By: Steve Hageman www.AnalogHome.com

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.


Results

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.


Implementation


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


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.
  


References


[1] Hageman, Steven C., “A Modern DSP Based Lock-In Amplifier”, 2018
http://analoghome.com/articles/a_modern_dsp_lockin_amplifier.pdf

[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 www.AnalogHome.com

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.


Notes:
[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 www.AnalogHome.com

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).

Wednesday, September 12, 2018

How I spent my Summer Vacation

I remember in the 5th Grade, at the beginning of the school year we were tasked with writing 500 or some such words on that very subject. I didn't like the assignment, perhaps because I didn't really do anything that I thought was noteworthy. I do remember listening to many faraway lands on Knight Kit and Magnavox Shortwave radios, plus looking at the Stars and Planets with my trusty Tasco Telescope.

But this year was way more fun than that!



I built this small footprint Data Acquisition System.

  • 32 Bit MCU @ 250 MHz with Floating Point Unit
  • 5 x 16 Bit ADC's
  • 3 x 16 Bit DAC's
  • 3 x DDS Chips
  • +/- 1 Amp Precision Current Source 
  • 6 Analog IO Pins
  • 8 Digital IO Pins
  • Thermometer + Barometer
  • Real Time Clock
  • Onboard EEPROM
  • MicroSD Card for Data Logging
  • 6-30 VDC Input Power @ 1 Watt
  • Reduced 2 x 4 Inch Footprint

Article By: Steve Hageman www.AnalogHome.com

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, June 10, 2018

Improving Code Quality with Microchips MPALB-X IDE and XC32 Compiler

Authors Michael Barr [1], Les Hatton [2], Robert Martin [3] and a host of others basically plead with programmers to use more formal code analysis techniques, such as: “Static Analysis” during the design phase of all embedded projects.

Addition of these steps is not time consuming or even expensive in most cases, the payback is usually justified by preventing even a single problem in shipped code.

Recently I have moved all my Microchip PIC development to their MPLAB-X and XC32 compiler. This saved a nominal sum per year in compiler updates, because this Microchip tool chain is free and it makes my clients also happy to be able to get the development tool chain for really the cost of a very simple programmer / debugger.

The XC32 compiler is a version of the venerable GNU GCC compiler geared especially for the MIPS based PIC32 product line. This tool chain also includes their rather all encompassing ‘Harmony’ software framework that handles all the driver and peripheral initialization and provides a consistent Hardware Abstraction Layer when programming any of the PIC32 devices.

Note: This article applies to MPALB-X version 4.15 and greater and XC32 Version 2.05 and later, the current versions as of June 2018.

Improved Static Analysis for Free:

The first step to better code is to turn all the GCC warnings, this is accomplished by supplying the ‘-Wall’ switch to the compiler options window [4], as shown below.



   Add All Warnings to the XC32 compiler options

‘Wall’ or ‘Warnings All’ will enable all the possible compiler warnings, but it doesn’t go out of its way to mark every library function as a problem. I find that it only adds three or four warnings from a previously cleanly compiled project. The errors it finds are mostly relevant and easy to deal with. You will find unused variables, bad definitions and improperly initialized variables.

I’m not sure what level of warnings are enabled as default in XC32, but you should definitely not compile without ‘all warnings’ turned on. It’s absolutely free, so use it.

GCC supplies a push/pop mechanism to disable specific warnings at various places in the code.

For example the function,

void foo(void)
{
    int32_t unused = 0;
}


will produce a warning: “warning: unused variable 'unused' [-Wunused-variable]”

This warning (or other warnings) can be disabled at the ‘function scope’ like this,

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"
void foo(void)
{
    int32_t unused = 0;
}
#pragma GCC diagnostic pop


The above works to disable this specific warning at the ‘function level’


Trying to disable this warning inside a function will not always work and may be ignored.

void foo(void)
{
    #pragma GCC diagnostic push
    #pragma GCC diagnostic ignored "-Wunused-variable"

    int32_t unused = 0;

    #pragma GCC diagnostic pop
}

The above does NOT work to disable this specific warning inside a function.


If you think about the above example, this makes sense. How could the compiler know that the variable is unused until it hits the final closing brace ‘}’ ? So by extension this example does work,

void foo(void)
{
    #pragma GCC diagnostic push
    #pragma GCC diagnostic ignored "-Wunused-variable"

    int32_t unused = 0;
}
#pragma GCC diagnostic pop


The above does work to disable a specific warning inside a function, but not for a single variable. This will disable the ‘unused variable’ warnings for all variables between the ‘ignored’ and the ‘pop’.


For more information in the GCC diagnostic pragmas see Reference 5. Also note that Microchip makes no mention of this functionality in their documentation so it should be considered: ‘Undocumented’.


Improved Static Analysis for very little cost:

The next level of static analysis is to use a ‘Lint’ program [6]. First developed for UNIX in the mid 1970’s, but not widely used with regularity much of anywhere else because of the lack of suitable executables.

In the mid 1980’s when I first started writing C code, there was a program advertised called PC-Lint [7] and it sold for probably $300 then. That was a lot of money. Today the same program, but updated for 30+ years sells for $400. That’s not so much money when you consider the cost of giving one bug to your customers. In fact now, it’s downright cheap and will pay for itself if it finds a single problem! There are a few open source version of something like Lint, but nothing that compares to a reasonably priced, finished commercial product like PC-Lint.

MPLAB-X contains an optional plug-in to enable PC-Lint functionality inside the MPLAB-X environment. It is fairly easy to get going, but it took me probably 3 hours to get it working inside MPLAB-X the first time. I might be able to save you some time with the following instructions.

Installing the MPALB-X Plug-In:

Start MPLAB-X and install the PC-Lint Plug-In
    Tools - > Plugins - > Available Plugins
    Select: “PC-Lint Plugin”, and finally select: “Install”.


Installing PC-Lint:

With the advent of User Account Controls (UAC) in Windows 7 and later it is much harder to get software to play properly, because many programs need elevated privileges to have access to certain directories, etc.

The default install location for PC-Lint is in “C:\Program Files(x86)\PC-Lint”, this is a problematic directory when running with UAC enabled, and I wasted an hour trying to get configuration files properly written until I gave up and re-installed PC-Lint off the root directory here: “C:\PL-Lint\”, then no problems at all. Just do this and save yourself time!

Even with the very latest PC-Lint version you won’t get the latest XC32 compiler initialization files or ‘.Int’ files. You will need to go to the Gimple website (www.gimpel.com/html/pub90/co-xc32.lnt ) and get this file,

    co-xc32.Int

Save the file in this directory,

    C:\PC-Lint\Int\

Don’t run the PC-Lint supplied configuration file builder (CONFIG.exe) it won’t know about the latest co-xc32.Int file anyway and it will just need to be manually modified anyway.

Instead just make a file named: ‘XC32-std.Int’ in the directory: “C:\PC-Lint\”

Place these lines in the file,

//  Microchip MPLAB XC32 C, -si4 -sp4,
//  Custom lint options file for XC2 V2.x

co-xc32.lnt

C:\PC-Lint\options.lnt  -si4 -sp4
-i"C:\Program Files (x86)\Microchip\xc32\v2.05\pic32mx\include\lega-c"


You may need to modify the exact path and name depending on your circumstances. Here you can see that I am using Harmony Version 2.05 and I use the ‘Lega-c” library and include files.

If you are in doubt as to the exact path to use, just open up your projects ‘stdio.h’ or some other well known system header file and see what the path is by hovering on the file name tab in the GUI, then use that.

Make sure that there is a file called: “Options.Int” in this directory also: “C:\PC-Lint\”. Right now this file can just have a single empty line in it.

Now setup the PC-Lint interface in MPLAB-X. Select: Tools - > Options → Embedded and then select the PCLint tab at the right hand side as shown below. Then click: OK.



Set these options as above on the PC-Lint configuration screen.


Right click on your main projects name, then select: “Generate PCLint Dependency Files” You should see this in the PC-Lint output window.

If the directory is not writable these files will not be written correctly and you will waste another hour trying to figure out why. To be safe, re-generate these files every time you switch and start working on another XC32 project. Just think of it as “Getting Latest” from your source control.


Let’s go Linting:

This step will seem daunting and you will wonder why you did all this in the first place. Why? Because your first ‘Lint’ will produce about 20 pages of warnings.

Let’s try it – Select a small ‘c’ file from your project, like “App.c” for example, right click on its name and select: “Lint this file”.

Have no fear – 99% of those warnings will be the same complaint about some name probem or some header file, etc. These warnings that can be easily suppressed.

Just open the file: “C:\PC-Lint\options.Int” file and start adding errors to suppress the spurious warnings. In 30 minutes, by checking half a dozen of my code modules, I was easily able to get rid of all the ‘chaff’ and get down to those few simple things that should be checked or fixed.

Here is the “Options.Int” file that I ended up with,

// Please note -- this is a representative set of error suppression
//                options.  Please adjust to suit your own policies
//                See  manual (chapter LIVING WITH LINT)
//                for further details.

-w3     // Overall warning level (3=default) Settings 2 and 3 are OK.

-e586   // function 'printf' is deprecated.
-e793   // suppress message about extern identifiers being more than 31 chars long
-e9045  // non-hidden definition of type 'struct
-e9058  // unused outside of typedefs
-e970   // Use of modifier or type '_Bool' outside of a typedef
-e9071  // defined macro '_APP_H' is reserved to the compiler
-e537   // repeated include
-e950   // Note 950: Non-ANSI reserved word or construct: like: '_nop()'

-passes(2) // Make 2 passes on the code


Now that wasn’t so bad after-all – Now I can just Lint my files one by one and see the warnings / errors that really show up. I had a number of iffy initialized variables, some missing ‘defaults’ in Switch statements and a few of the dreaded,

    If(test)
        foo();


instead of,

    If(test)
  {
        foo();
  }

Constructs.

Most importantly I found a few real problems (like copy and paste errors) that would have prevented proper program operation and would have cost me debugging time to fix.


Gimpel offers this sage advice for first time “Linters”,

“If you've never linted your code before, you may want to modify the warning level initially.  Try running with -w1 to report only errors.  After you've fixed the resulting errors (or suppressed those that you don't want reported), run with -w2, and so forth. “


Further Reading:
Hopefully this tutorial will get you at least 80% of the way to where you want to be, in a very short period of time. For more information, the Gimpel website has a FAQ list that provides helpful hints and the PC-Lint manual is full of further in depth information.

You may also want to consider "Breadboarding" your C code on your PC before placing it on your target Embedded System, these two posts show how I accomplish this,

* Breadboarding Embedded Code
* Breadboarding Embedded Code - Part II


References:

[1] Micheal Barr The Barr group. Prolific writer about best ‘C’ practices,
    https://barrgroup.com/content/barr-group-embedded-c-coding-standard-now-available-free-embedded-systems-designers

[2] Les Hatton, Author of: “Safer C”, McGraw-Hill, 1994

[3] Robert Martin is a frequent speaker at programming conferences. Many of his talks can be viewed on Youtube.

[4] There are a number of other compiler options available, I find that this one is the best for catching stupid mistakes without marking every single library function as non-compliant. For other possible options see the XC32 Compiler Users Guide – Yes there is actually a manual and as near as I can tell Microchip keeps it up to date.

[5] GCC Diagnostic Pragmas manual page,
    https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html

[6] LINT    https://en.wikipedia.org/wiki/Lint_(software)

[7] Gimple Software PC-Lint, Version 9.00L is the current version.
    http://www.gimpel.com/html/pcl.htm

PC-Lint has been called the longest continuously available software product in the history of mankind, since it has been available from the 1980’s until now.


Article By: Steve Hageman www.AnalogHome.com

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, December 18, 2017

Custom Build-A-Box

One thing that many Analog Engineers who work on very low noise and low frequency circuits figure out very quickly is that even simple room air currents destroy the achievable accuracy of our circuits.

Most of us first figured this out when we hooked a Strip Chart recorder to our designs output for a day and, much to our surprise (and dismay) the output would invariably track the day and night room temperature variations very well. We managed to build a thermometer when all we really wanted was a very low drift amplifier.

Air is not only good to breathe but, it has a thermal mass, it has a temperature and it has a thermal transfer coefficient. When air circulates around a low noise / low frequency design it either heats or cools the circuit and normally in a not so evenly manner. This gives rise to all sorts of thermocouple effects that are exasperated by the air induced temperature gradients.

The first thing that most of us grabbed when we observed this effect was observed was some cardboard box that was dutifully placed on the circuit in question to keep the room air currents off of it.

But the ‘Fun’ has just begun...

Modern semiconductor packages are so small and thin now that many designs are now sensitive to IR light. Yes the IR light that your fluorescent lights give off is enough to bombard the IC’s transistors with photons because the packages are now transparent to IR light. This can also cause unexplained circuit drifts. Again a ‘Cardboard Box’ is the solution (Keep the circuit in the dark!).

Even light and air currents take a back seat to Long Wave and AM radio stations messing with your circuits. If you have never worked a few blocks from an AM radio transmitter, well let’s just say you have sure missed some fun hours of debugging there [1]. Those Florescent lights are major EMI ‘aggressors’ here too. Not the ones on the ceiling, as they are usually far enough away. The real trouble makers are the ones on your lab bench or even the microscope light. Yes, my microscope light is a real circuit ‘destabilizer’ - a ‘double whammy’ with IR and EMI bombardment!

Even a “Dark Cardboard Box” won’t filter out RF, so naturally, we just wrapped the box with aluminum foil or copper tape! There! A job sorrta well done...

Then Vs. Now

That was then, when our breadboards were spread all over the lab bench. Today our breadboards are finished products and may well ship to customers. This makes finding a suitable “Cardboard Box” to ‘tighten up’ the finished design very difficult indeed.

3D Printing to the Rescue

A 3D printer can quickly make any size or shape “Plastic Box” that you want, when you want it.

In a current design, I needed to get some air current isolation from the main circuit to the very sensitive and high gain Analog Front End. Years ago I would have hacked something together with scissors, an X-Acto knife and the cardboard off the back of a paper tablet. This would take a while and it would have looked pretty amateurish by the time I wrapped it with Electrical or Kapton tape.

For this design I just imported the Step model of the Analog PCB [2] into Design Spark Mechanical [3] as shown in the figure below. In less than an hour I had drawn the top and bottom of the box I wanted fabricated right around the PCB model and exported it as a STL file to my 3D printer.

The Custom Box was designed around a 3D accurate STEP model produced by my Altium PCB software. In less than 2 hours the box was printed as shown below.



The finished design as viewed from Design Spark Mechanical. The design is simply 'drawn' around the 3D accurate exported Altium PCB Model.


The actual finished two halves of the 3D Printed Box. Note the cutouts where the IO connectors have to go. For a real design I would have used Black Material because it looks more ‘professional’ but yellow shows up better in the photos.  


Bottom of the custom 3D box installed on the main board. The Analog Front End IO Connectors fits in the blue connectors that poke through the cutouts that I made in the 3D printed box bottom.
  



The base and top of the 3D box as it fit on the main electronics PCB. Way better fit than cardboard ever was.
 

The custom 3D box covers the analog front end board well. The Analog Input connectors in this particular design are BNC connectors.



Since I wanted EMI shielding also (you never know where your design may end up [1]), I sealed the box together with my some of my favorite copper tape. Be sure to always use the copper tape with conductive adhesive. The Copper tape enclosure is ‘grounded’ by electrically connecting the copper tape to the BNC’s with an overwrap.


Conclusion

3D printers are certainly handy, not only in Robotics Projects but in making custom, 21st Century “Cardboard Box” replacements in less than 3 hours start to finish – and they look better too.

Certainly a more professionally looking finished job and better working instrumentation too boot!


References / /Notes:

[1] I once worked for a company making instrumentation products that had a manufacturing plant in Puerto Rico. About a mile from the plant was a 1000 foot tall Navy Communications antenna. It did not broadcast continually, but when it did you couldn’t test anything at the plant site! Thank goodness the broadcasts happened very infrequently, otherwise we would have had to move!

[2] Altium has native 3D PCB design. Exporting a 3D Step model of any design is a “one click” operation. Then that model can be imported into any modern #d Drafting Package.

[3] Design Spark Mechanical – A very easy too use, free program from RS / Allied.
https://www.rs-online.com/designspark/mechanical-software


Article By: Steve Hageman www.AnalogHome.com

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).

Wednesday, December 13, 2017

An Interesting Breadboard and Circuit – The “Greatbatch Pacemaker”

My good friend Mike Seibel recently reminded me of a breadboard that he saw in my cube when we worked together at HP in the late 1990’s. The breadboard is still around and it intrigued me then as it does now… Here is the complete story,

Decades ago in 1995 I saw an interesting “Breadboarding Technique” that I had never seen before in an issue of the IEEE Spectrum magazine [1]. There was this full page picture of a chap named Wilson Greatbatch holding a manila folder with a simple circuit drawn AND attached to it. Mr. Greatbatch had built the breadboard right on the folder where he drew the schematic. That circuit was one of the first Pacemaker Circuits ever developed. The scan below is a poor quality reproduction, because in the original full page picture I could clearly make out the circuit and component values (Figure 1).

I had never seen anyone build a breadboard on a manila folder like this and I was intrigued by the designs oscillator and charge pump voltage doubler, so I built one of my own using my most common breadboarding technique – parts soldered directly to a piece of copper clad FR-4 (Figure 2).

I really didn’t think the circuit would run all that long, so to “prove my point” - I powered it with a used Lithium cell taken from a flash camera when it would no longer power the camera anymore.

Then I hung the running circuit on my lab wall and every few months I would see it, pull it down and test it to see if it still worked. To my unbelievable surprise it continued to work until about Mid 2010.

That’s around 15 years, even when I gave it every opportunity to fail early by powering it from a nearly dead battery in the first place. As usual, the circuit: “Had the last laugh” on me!

The article about Mr. Greatbatch went on to tell how Mr. Greatbatch developed the first Pacemaker by removing the wrong part from a 1 kHz oscillator that he was trying to build and it started to Squegging at about a 1 Hz rate with a narrow output pulse – and it hit him – “This is a Heartbeat!”. Again, a circuit ‘fail’ had the last laugh and a multi-billion dollar industry was born.

I could only hope that more of my “circuit failures” would lead to good things, but alas, most of my failures just lead to smoke or other parts that die sympathetically in one big chain reaction. At least I have never set a Lab on fire (yet!).

So take note of interesting circuits you see, give them every chance to fail, and they will surprise you every time!



Figure 1 – A poor scan of the original article picture. I was easily able to see the circuit and values in the original picture. What caught my eye originally was the breadboard Mr. Greatbatch drew and built on a Manila folder! (Picture originally copyright 1995, IEEE Spectrum).



Figure 2 – My prototype built with my usual breadboarding style – parts soldered directly to a piece of FR-4 Copper clad. 



Figure 3 – The schematic of Mr. Greatbatch’s original circuit. I especially liked the clever voltage doubler at the output. Mr. Greatbatch’s original circuit had a DC blocking capacitor on the output that I did not include, since I was not going to actually ‘Pacemake’ anything. The original circuit used 2N Something transistors, I used the very popular 2N3904 and 2N3906 transistors in my version. The current source “IG1” at the input is just a ‘kick starter’ that pulses 100 mA for 10 nanoseconds to get the oscillator running for the Spice Simulation.





Figure 4 – The output pulse is 2 x 2.8V peak to peak because of the clever voltage doubler My circuit ran at around 53 Beats per Minute. The width of the pulse is around 1.5 milliseconds.

[1] Adam, John A., “Profile: Wilson Greatbatch”, IEEE Spectrum, March 1995



Article By: Steve Hageman www.AnalogHome.com  

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).