I bet this is going to come up as more and more folk are transitioning to 32-microprocessors like the Due... libraries will need to be updated to reflect the different lengths of bytes, etc. since an int on a Due can hold a greater range of numbers than on a Uno. Anyhow, I wonder if someone could look over this code for a MCP3421 ADC, which offers multiple resolutions, ranging from 12-18 bits that I am trying to use on a 32-bit micro with the Arduino IDE (Teensy 3.0)

The ADC uses a I2C connection, if 18-bits are used, three data bytes are sent, otherwise, only two. The databytes then have to be re-assembled into the signed numbers they represent. My code is an attempt to be flexible, hence I declared a int32_t as the ADC value being computed. As best as I can tell, the code below is OK for the positive portion of the range. However, negative numbers appear to be coming out incorrectly. Could someone more knowledgable see if I got the code right?

//here use signed int32_t and right + left shifts to carry the sign and append the value as needed //for 18-bit operations, only the last bit of the Hi byte is relevant. The remaining bits are sign bits if (Bits == 18) ADC_Value = (((Hi << 30) | (Med << 22)) | (Lo << 14)) >> 14;

//for all other resolutions, the returned value is left shifted based on the resolution to preserve the sign, //then right shifted back, i.e. if 16 bit resolution is needed, left shift Med 24 bits, while 12-byte values //would require a 28-bit left shift. else ADC_Value = ((Med << (40-Bits)) | (Lo << (32-Bits))) >> (32-Bits);

It looks like the sign bit (shown as M in their diagrams) is replicated up to the top of each sample input, whether it be 12, 14, 16 or 18 bits so I would load the bytes as they are read into a 32-bit word and then adjust as needed.The nice thing about the ARM Cortex M4 used in the Teensy3 is that it has a barrel shifter so whether you shift 1 or 31 bits, it still takes one clock cycle.

1. The code is very convoluted. I would keep a flag for data format (3 bytes vs. 2 byte read), and based on that flag, read the bytes out of the device.2. When you reassembly the signed long type, you will need to test for sign (most significant bit of the most significant byte) and reverse the sign if necessary. So the bytes are reassembled to an unsigned long type, and if the number is negative, output its two's complement (aka a negative number).