SPI Master setup for PIC12 series

[Mike_C]

I'm a senior in Electrical Engineering at a major university, but I'm new to embedded systems design. I'm trying to get a PIC12F1822 configured as an SPI master device capable of passing a short list of configuration commands to an already designed (and functioning) slave system.

I've seen a handful of examples for more elaborate PIC18F series devices, but the product I'm designing has to be only a couple centimeters in size, so I can't use a 20+ pin PIC in my implementation. I need to stick with small chips. Has anyone ever seen any sample code for a series 12F PIC being configured as an SPI master? The datasheets spell out up and down that the device is capable of everything I need it to do, but I can't find any code samples or other guiding principles to get me started.

Many Thanks!

 

[Los Frijoles]

I have some assembly code that I wrote a while ago for a PIC16F628A. It is a temperature logger than interfaces to an RTC and a temperature sensor over I2C. It has been at least 5 years since I have even read this code and I don't remember a lot of it. However, I was able to locate it and put it up as a gist. It isn't incredibly well commented, but I was able to follow it after pretty much not remembering even how it worked.

The code (at least the I2C parts) should be able to run on a 12F with no problem. It just needs to have the port definitions changed. This utilizes a 100% software implementation for I2C, so there is no hardware support. Also, forgive any errors I may have since I didn't have a lot of experience with debugging and coding practices (I may have been in high school at the time).

The code is here: https://gist.github.com/kcuzner/5329144

Relevant parts of the code for I2C (line numbers):
* 90-91: Port definitions
* 317-462: The I2C Methods
* 150-173: Writing to an I2C device
* 228-234: Reading from an I2C device

As for doing it in C or something, I find the wikipedia page quite descriptive as to the exact protocol.

 

[Los Frijoles]

I apologize for my previous post. For some reason, every time I read over the topic I read "I2C" instead of "SPI". I am now unable to edit it, so I will post my addendum here:

Rolling your own SPI Master should be just about the same (if not less) level of complexity of doing your own I2C as my code above illustrated. I have found that rolling your own bus implementations can be pretty easy if you read over the specs carefully and use an oscilloscope (or a DLA, but that makes it a little more difficult for busses that rely on pull-ups like I2C) to observe what you have got so far.

In my opinion, your main hurdle will be the minimal number of pins. While a 12F generally has 4 usable pins as far as I know, programming the device in-circuit could cause false SPI signals to appear since you would most likely share some pins with the ISCP interface. A potential way around this would be to put a resistor on the slave-select line pulling it to the "nothing selected" state when it goes to High-Z state (as would occur during programming). You would also have to put that pin on a non-ISCP pin.

There are some implementations of SPI that do not require the use of SS (slave select), but if they do require it or you need to select one of multiple devices, I would find an I2C-based port expander and use those pins to implement the bus (albeit at a significantly lower speed than would be possible directly operating it off the 12F's pins.

As for programming it, I would start here: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Operation and then continue to the datasheets for the devices you are using. The datasheets most likely contain a definition of SPI and specifics about their exact implementation. I have done SPI before, but it was on an 18F and I can't remember if I used the hardware module or not (I actually think I didn't because I was using the hardware module for I2C since that's more complex than SPI, so it was more economical to program the SPI and leave the I2C to hardware). Every time I have had to re-roll the interfaces either because I didn't like the last way I did it or I am using a different MCU, I have found the datasheets to be the best source for doing the protocol.

Also, if you have done this in Verlog or VHDL before (assuming a lot since you say you are almost done with a EE degree and I have no idea what the program at your university covers), you may find that this isn't a horribly difficult task since I honestly have found it easier to program bus interfaces in software rather than writing a description for the hardware.