Communicating with the Pic 16F913

Question

I asked this question over at stack overflow but found this in a few of the comments on some of the microchip questions, https://stackoverflow.com/questions/3276297/communicating-with-the-pic-16f913

Here is my issue, it appears that all the communication lines for the PIC 16F913 reside on the same set of pins, this is convenient in that I don't have to sacrifice GPIO pins just to do comms, however the problem I'm having now is if I'm using the SPI on the chip, how can I send information to the RS232?

The reason this issue came up, is that I just bought a CAN bus chip that communicates over SPI, and I would really like to see the data on RS232, so I can see messages. (I really don't know much about CAN yet, so who knows if this even makes sense yet).

Here are the options I see, and maybe someone else has better ideas that I'm just simply missing.

Somehow setup a time scheme that will switch between SPI and RS232 every time I get data, -- This doesn't seem hard and should work, but supposing I don't want to miss a message, what if a message is written while I'm writing to RS232, is it possible I'll miss it?

2.. I can always use SPI, but then build my own comm bus over 8 of the GPIO lines, to another PIC 16F913, using only the GPIO lines and then since the RS232 lines are free on the second PIC I can simply read the data and spit it out.

-- This one is doable but now we're wasting 2 chips, AND all the GPIO lines,

There has to be a better way. Or is there?

Any help is greatly appreciated.

I would like to also clarify, obviously one solution is using a completely different chip (which may in fact be what I end up doing, if I can get the 18F programmed), however, I'm interested in worst case scenario, in which I am limited in resources and only have some 913's, is the way described above the only way to do it with this chip, or is there a better way?

Answer 1

You could use those pins for SPI, and implement a software UART on another pair of pins. I've done that before now when I needed two UARTs on a chip that only had one hardware UART.

You need to "bit-bang" the software UART. I tried to post some code I've used but it doesn't get formatted properly. Here is an example.

Answer 2

To answer the first question I got to. If you have a device on SPI and after reading from it you are writing to UART.

You cannot "miss" a message while writing to UART because if you are master on SPI the other device must wait for you. If it is a device that samples quickly and constantly you just have to ensure that you sample it more often then it will replace it's values. If it is a device that holds data for you in a buffer you should be able to switch back and forth easily.

I am quite used to doing this action, at work We have a device with two communication channels. One channel has 5 different devices it can control, 4 on SPI, one on UART. The other channel has two. One on SPI, one on UART. The code is a bit more complex, as the firmware controllers for each device must ask for access to resources and receive them before doing anything, but the system still works perfectly.

I would suggest you take a quick shot at just switching. You should be able to implement it fast enough.

The other option is to make a software UART. This can be quite doable. It is called bit-banging normally and is very common practice if it is just for debug and not needed for a final product.

I would suggest bit banging to be lazy. People often overlook bit-banging.