| General > General Technical Chat |
| Microchip MCP3550 - is the data sheet a load of tosh? |
| << < (3/5) > >> |
| DiTBho:
--- Quote from: Nominal Animal on October 27, 2023, 06:36:16 pm ---That was not designed by anyone who has ever written or maintained code that needs to process the results. --- End quote --- I also usually do these mistakes when I design hypothetical stuff on HDL, but hey? I also usually catch the mistake and fix it as soon as I run the simulator with a piece of usable software. So, probably they just don't check anything and don't get any feedback during the design process :-// |
| Nominal Animal:
--- Quote from: peter-h on October 27, 2023, 07:29:11 pm ---My SPI is shared among a number of peripherals, with re-initialisation as needed (mutexed of course). And it works perfectly. --- End quote --- Right-o; that's why I asked. --- Quote from: peter-h on October 27, 2023, 07:29:11 pm ---I considered reconfiguring the SPI pin to GPIO to detect EOC but it would be messy, and would prevent other SPI devices to work during the 90ms. --- End quote --- Do you have two unused GPIO pins you could use, one input and one output? And room for two additional 5/6-pin cheap ICs? Specifically, 74LVC1G97/74LVC1G58 and a 74AHC1G125? You could do shenanigans with those, namely detaching MCP3550 SDO and SCK from the SPI bus, use one extra GPIO input pin to monitor MCP3550 SDO, and a GPIO output pin to control MCP3550 /CS. Your current /CS would control whether SDO and SCK are connected to the SPI bus or not. The '1G97 would invert the SCK as seen by MCP3550 so it works in mode 1,1 while the SPI bus uses mode 0,0. '1G58 would not invert. Caveat: this is just an idea, extending from how I'd use a separate GPIO pin on AVRs to monitor SDO for conversion completion; I haven't verified this works well in practice. --- Quote from: DiTBho on October 28, 2023, 09:37:02 am ---I also usually do these mistakes when I design hypothetical stuff on HDL, but hey? I also usually catch the mistake and fix it as soon as I run the simulator with a piece of usable software. So, probably they just don't check anything and don't get any feedback during the design process :-// --- End quote --- Yep! I don't do HDL/VHDL myself (yet!), but when creating e.g. library interfaces or tools for others to use, I have to spend some time investigating the use patterns, or they will be horrible to use. Same thing, really: cannot just focus on one aspect and leave the practical aspects for others to deal with. |
| peter-h:
What I don't get is the total lack of QA within Microchip in this area. Other people must have reported this. The latest DS on their website is from 2014. |
| nctnico:
--- Quote from: Nominal Animal on October 27, 2023, 06:36:16 pm ---That was not designed by anyone who has ever written or maintained code that needs to process the results. --- End quote --- It is very possible the solution requires the least amount of silicon area and thus is cheapest to produce. ST is another vendor where you'll find very odd functioning peripherals in their microcontrollers just to cut production costs. |
| peter-h:
I have no issue with a weird bit order; most ADCs etc have weird stuff. The ADS1118 is also weird, for example; look at how it encodes the temp sensor value. But such obvious discrepancies from one DS page to another... |
| Navigation |
| Message Index |
| Next page |
| Previous page |