General > General Technical Chat

Microchip MCP3550 - is the data sheet a load of tosh?

(1/5) > >>

peter-h:
Note the order of the OL and OH bits





Did they really design the chip so these bits change around according to the SPI mode (which is anyway detected implicitly, from the clock phase)??

I can confirm experimentally that in Fig 5-7 the bits are depicted wrong. The rest of the bits (including the seven undefined bits on the right) are correct.

Oh and while I am at it, the DR bit is not apparently usable because it is undefined until conversion is complete :) So one starts the conversion and waits (osDelay(90)) for the 80ms conversion time (-50 version) and then just reads out the data.

Other than the above, the device works well.

tszaboo:
Oh no, errata in Microchip PIC and errors in their datasheet. This has never happened before.
I'm happy if I can buy an opamp from Microchip that doesn't have an errata. "Rail to rail doesn't work, Rev A, voltages below 0.5V and above VCC-0.5V result erroneous output voltages. Workaround: connect voltages closer to mid-rail to inputs."

dmills:
Yea, par for the course with them.
They also seem to specialise in buying semiconductor vendors with slightly shit chips, see Micrel ethernet sand for example (Does not meet 802.3 spec : Workaround None, going by memory, but it was something like that on an MDI port), errata longer then the (not very good) datasheet.

Not a company on my preferred vendor list for opamps I have to admit, it just doesn't seem like a natural fit, but then I am still salty about TI buying Burr Brown and the whole Linear/ADI thing.

All datasheets should be read with the understanding that the first few pages were written by marketing, my rule of thumb is that the real thing starts with the fist graph that is not 'typical efficiency' (TI power converters looking at you, also ALL mosfet Ids(on) figures!), and that the rest is a template filled in by the intern with as close to zero understanding as they can get away with.

Errata basically tell you mostly about the state of the battle between marketing and engineering at the vendor, the more embarrassing the errors they will admit to the better that fight is going, but just because something is not in the errata does not mean it works until you have verified the functionality.   

Nominal Animal:
Blargh.

If only they sent (OVL|OVH) and (OVL) instead, you'd have first bit (MSB) signal overflow, and the rest would form a 23-bit two's complement result.  Now, you need to do several bit ops on the MCU to get the correct result.

That was not designed by anyone who has ever written or maintained code that needs to process the results.


--- Quote from: peter-h on October 27, 2023, 02:52:49 pm ---Oh and while I am at it, the DR bit is not apparently usable because it is undefined until conversion is complete :) So one starts the conversion and waits (osDelay(90)) for the 80ms conversion time (-50 version) and then just reads out the data.
--- End quote ---
Well that's stupid for sure.

Could you use mode 3 (1,1) instead? After you start the conversion, you keep SCK high, CS low, and wait for the MCP3550 to drive MISO high. Then, you just do a 24-bit transfer to get the 24-bit result, without the useless DR bit.

In mode 0,0, keeping SCK low while waiting for rising edge of MISO, I'd probably get rid of the useless DR bit by temporarily switching SCK to a GPIO, and doing an extra SCK pulse (⊓) by hand (keeping it high for a minimum of 90ns).

My currently preferred microcontroller, Teensy 4, cannot read the MISO pin while it is assigned to the SPI (LPSPI) – there are two separate GPIO subsystems and each includes their own input part (and only one is DMA-capable); no input part is always connected to the pin – so I'd have to fiddle with the MISO pin control anyway.  Doing some SCK shenanigans on top of that is no biggie.  It's only 90ns plus transitions and pin control setting, fortunately.  On the other hand, Teensy 4 supports 25-bit transfers, so I'd just (EDIT: do mode 3 instead, and) extract OVL|OVH, drop DR, and copy OVL to bits 22-31 to obtain the 32-bit sign-extended twos complement reading.  It might be worth it to use LSB bit order, so these bits would be at the low end –– using the three low bits for a lookup table with eight 32-bit entries, a shift right and shift left to drop the unused bits, an RBIT (Cortex-M7 instruction) to reverse the bit order in the 32-bit word, and do an OR with the looked-up 32-bit entry to fix-up the value with sign extension and all.

On a 8-bit MCU like AVRs, I'd definitely use SPI mode 3.  The MISO pin can be read (PINB bit 3 on ATmega32u4, my favourite 8-bitter), so I'd probably poll it, or electrically connect to a separate input pin that supports rising edge interrupt.


--- Quote from: dmills on October 27, 2023, 05:34:49 pm ---Errata basically tell you mostly about the state of the battle between marketing and engineering at the vendor, the more embarrassing the errors they will admit to the better that fight is going, but just because something is not in the errata does not mean it works until you have verified the functionality.
--- End quote ---
Yep; and this is good for hobbyists like myself to consider when reading datasheets and their errata.

nctnico:

--- Quote from: dmills on October 27, 2023, 05:34:49 pm ---Yea, par for the course with them.
They also seem to specialise in buying semiconductor vendors with slightly shit chips, see Micrel ethernet sand for example (Does not meet 802.3 spec : Workaround None, going by memory, but it was something like that on an MDI port), errata longer then the (not very good) datasheet.

--- End quote ---
I agree. Typically I don't use anything from Microchip in my designs. Flash chips from formerly Atmel and  chips from formerly Microsemi are an exception. The rest is just utter rubbish.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod