I wonder if the MCP2210 supports Open Colector output.

Best Regards

Could you give the example in this post a try? I used it to toggle GPIO0 and it worked fine. Did you try configure each individual pins separately? If you could post your code I can give it a try when I get back tonight.

Once configured for CS, GPIO pins function extremely well for their intended purpose of serving SPI slaves. However, standalone GPIO control for individual pins seems not to work! I first read GET levels, assert a pin level, write SET levels, and read back GET levels for final confirmation and comparison. However, the MCP2210 never responds correctly, even if I configure the device with Microchip’s own utility. Is this chip not intended for general purpose GPIO’s, but specifically for SPI slaves or alternate functions? Microchip documentation points in that direction, and their demo kit seems to fit that model also, since they SPI slave an EEPROM, Temp Sensor, IO Expansion, and A/D.

Thank you, and best regards,
Vic

Thanks for your comments. The way MCP2210 works is that once you have designated a pin as CS, it will automatically select/deselect when you issue SPI command. You can see this in my example here (http://www.kerrywong.com/2012/10/22/mcp2210-library-mcp3204-spi-adc/)

….
//chip select is GP1
def.ActiveChipSelectValue = 0xfffd;
def.IdleChipSelectValue = 0xffff;
….

How should one handle the toggling of GPIO’s after SPI has been configured with one GPIO dedicated to CS for the downstream device (tilt sensor)?
The tilt sensor will be periodically queried for its data, but GPIO changes will be sporadic. The issue is that the GPIO Levels are all set
in two bytes in command 0×30, datasheet p.49, but what does one put for the CS? 0×00?

Thanks! Great work, btw!

Thank you for your work it was a great help.

But there’s something not really clear about how the MCP2210 handles the data size and transmission size:

If I configure the SPI to send 2 bytes per transmission and I want to send let’s say 4 bytes.
Will the MCP trigger 2 transmissions or only one and give up on the remaining data ?
So far it seems the data sent are truncated (not sent) when bigger than a transmission size.

Is it actually how it works ? The only point of the message size is, in case it’s smaller than the transmission size, to allow the master keeping the CS and the clock active until the transmission is done ?

Any information on this would be greatly appreciated !

Yep, that’s the exactly approach you would need. The SPI command needs to be issued continuously until all the data has been received as indicated by the engine status as I mentioned previously. I have found that the number of bytes field does not need to be 0 though (at least from my testing), it seems that that field is not used the subsequent SPI calls are made when retrieving the result.

I’ve got this working. In my particular case, the SPI results are read out during the second byte of a SPI transfer so sending out more clock cycles will not help. It turns out, if you receieve a 0×20 in byte 3, you need to initiate another SPI transfer but set the number of bytes (specified in byte 1) to zero. I got that from Microchip support and it seems to work well.

In the case of an F8 in byte 1, you need to start the whole SPI transfer over as if it never happened. I placed a 25ms sleep before retrying a SPI transfer and this seems to minimize the number of re-trys.

Thanks for looking over my question and giving me your thoughts on it.

I have not run into the problem you described. The SPI clock needs to be issued until the results are received. Did you try this? If you continue issuing the SPI transfer command you should see the engine status comes back as 0×10 eventually.

Anyway, I am putting together a tutorial using MCP2210 SPI and should appear on this blog in the coming days.

Unfortunately, I’ve been having a difficult time getting SPI transfers to work reliably. After writing something like:

42 03 00 00 13 40 00

Part of the time, I get back this:

42 00 00 20

Meaning the write happened but nothing was read back. Part of the time I get this:

42 f8

Meaning the command was received but there was a SPI data transfer in progress. Also, part of the time I get this:

42 00 03 10 00 00 00

Meaning it finished and read correctly. The thing is, I think I have the connection configured synchronously so this sort of thing shouldn’t happen.

Anyway, I know this is a different environment but I thought I would just take a shot at describing it and see if this sounds like a problem you solved.

Yes, I had tested the provided code using multiple chips. One thing I forgot to mention is that you will need to follow signall11′s directions to change device permissions on Linux, otherwise you will need to use sudo to run your code.

Yes, without root access to the devices, you will not be able to manipulate the settings.

Could you let me know if you are able to get it working by using sudo?