## MAX4372 Sense Input Protection

My initial thought was to stick a Schottky diode across the sense terminal inputs, but John Kasunich suggested that requires a much heftier diode and might not work anyway. He suggested sampling the current-sense voltage through high-value resistors, which will certainly affect the linearity & calibration of the sense voltage.

My sissy circuit has a peak fault current of maybe a few amps, which the diode should shrug off if I’m not stupid about it. But I like the resistor notion, as it dramatically reduces the diode current.

Maxim has a useful Application Note (AN-3888) describing the effect of common-mode filters on the amp’s calibration. A key suggestion: the two resistors should differ by a factor of two to match the input bias currents.

So here’s one approach that might work.

The schematic is a screen snapshot from Linear Technology’s LTSpice IV. The two current sources on the left model the MAX4372 sense amp inputs, with their max bias current values. R1 is the current-sense resistor: a whopping 0.5 ohm for my low-current application.

R2 and R3 isolate the diode from the sense resistor. High values introduce more error due to diode current, while also helping to protect the sense inputs from excessive voltage. Low values reduce those errors, while bypassing more load current through the diode. Ya can’t win.

Running the simulated load current up to 5 A shows that the diode clamps the input voltage to about 330 mV, which is likely good enough. Higher values for R2 and R3 reduce that; 10 and 5 ohms might suffice. The factor-of-two difference is really only important at very low currents for these very low resistors; at higher currents, the diode is all that matters.

What’s of more interest is the error induced by those resistors in normal operation. Here’s a screen snapshot of simulation up to a load current of 500 mA, well above my expected max of 300 mA. Pay attention to the middle trace in each group of three, which shows the results at 30 °C (the others are 20 and 40 °C).

The red traces angling down from the upper left represent the ratio of the diode voltage to the sense resistor voltage It starts a bit over 0.99 and gets down to 0.92 by 300 mA. So, basically this protection network introduces less than 10% error if you ignore temperature effects.

The board I’m building has a calibrated current sink, so (if I were doing this for a real project), I’d be sorely tempted to just build a lookup table on the fly. Then I could work backwards from the desired current setpoints to the PWM voltage outputs required to generate those values. But that’s a simple matter of software, right?

If you care a lot about accuracy, you’ll obviously want to measure the board temperature and tweak the table accordingly.

If you want to see how an actual diode behaves, you can measure it.

## Arduino Command Line Programming: Avrdude Puzzlement

For all the usual reasons, I’d like to compile & download Arduino programs from the command line, rather than through the (excellent!) IDE. That is supposed to work and, for most folks, apparently it does.

Not here, alas.

I’ve installed the 0012 Arduino Java IDE (x86 or x86_64 as appropriate) from http://code.google.com/p/arduino/ on three different systems, all with Kubuntu 8.04:

• Dell Dimension 9150 – x86_64, which seemed like a good idea at the time
• Dell Inspiron E1405
• Dell Inspiron 8100

In all cases the IDE works perfectly, compiles & downloads programs just fine, and behaves exactly as you’d expect. I had a few minor quibbles with sorting out various paths & suchlike, but, on the whole, it has no troubles at all with either a Diecimila or a Sparkfun Arduino Pro (with a Sparkfun FTDI Basic USB gizmo).

I tweaked ~/.arduino/preferences.txt to include:

```console.auto_clear=false
build.verbose=true

Here’s the final step in the IDE compile-and-download dance. Backslashes indicate continuations of the same line; the original is all on single line:

```hardware/tools/avrdude -Chardware/tools/avrdude.conf -v -v -v -v -pm168
-cstk500v1 -P/dev/ttyUSB0 -b19200 -D
-Uflash:w:/mnt/bulkdata/Above the Ground Plane/
2009-06 Solar Data Logger/Firmware/Logger/applet/Logger.hex:i

avrdude: Version 5.4-arduino, compiled on Oct 22 2007 at 13:15:12
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

System wide configuration file is "hardware/tools/avrdude.conf"
User configuration file is "/home/ed/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port            : /dev/ttyUSB0
Using Programmer      : stk500v1
Overriding Baud Rate  : 19200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
AVR Part              : ATMEGA168```

The IDE evidently does the reset-from-USB trick through the standard USB hardware.

I set up the command-line Makefile from http://www.arduino.cc/en/Hacking/CommandLine, although that’s for the 0011 IDE, then made the recommended tweaks. The make section does exactly what you’d expect: compiles the source program.

Running make upload fails every time, on every PC, with both boards. Indeed, in all cases, running avrdude on the command line produces the dreaded “not in sync” errors, showing that it’s unable to communicate with the Arduino board. Blipping the reset button on the Arduino board generally makes the USB transfer work fine, with the failures most likely due to my lack of dexterity & timing precision.

The usual debugging suggestions aren’t relevant, as they all assume there’s a basic communication failure caused by anything from a completely dead board to mysterious library incompatibilities. In this case, however, I have an existence theorem: the IDE works perfectly before and after the command-line failure.

It turns out that the IDE includes a specially patched avrdude, so I tried running that version from the directory where the IDE lives, using exactly the same command-line flags as the IDE does. Surprisingly, that doesn’t work. Again, backslashes indicate continuations of the same line and I added quotes to the file name to protect the blanks…

```hardware/tools/avrdude -Chardware/tools/avrdude.conf -v -v -v -v -pm168
-cstk500v1 -P/dev/ttyUSB0 -b19200 -D
-Uflash:w:"/mnt/bulkdata/Above the Ground Plane/
2009-06 Solar Data Logger/Firmware/Logger/applet/Logger.hex":i

avrdude: Version 5.4-arduino, compiled on Oct 22 2007 at 13:15:12
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

System wide configuration file is "hardware/tools/avrdude.conf"
User configuration file is "/home/ed/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port            : /dev/ttyUSB0
Using Programmer      : stk500v1
Overriding Baud Rate  : 19200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [1e]
avrdude: stk500_getsync(): not in sync: resp=0x1e
avrdude: Send: Q [51]   [20]
avrdude: Recv: . [0f]
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x0f```

There’s no difference between the /opt/arduino/lib/librxtxSerial.so and /usr/lib/librxtxSerial.so libraries, which normally causes some confusion on x86_64 systems. I think that means the x86_64 version of the IDE has the correct library.

I’ve also tried the stock Kubuntu avrdude, which is at V 5.5, to no avail.

Given that the IDE works, that I’m running the same avrdude executable, and that the libraries match, I’m not sure where to go from here.

While I’m generally dexterous enough to run make upload and blip the Arduino board’s reset button with my other hand, I’m bringing up a shield-like board that plugs atop the Arduino and, alas, lacks both a reset button and a hole over the Arduino’s button.

The board is, of course, that one.

Update: As a reasonable workaround, I’ve set the IDE up to use an external editor. Then I can tweak the programming, flip to the IDE, click the Download button, and away it goes. Not quite as easy as a full command-line solution, but close enough.