PIC & software serial bit-banging

[Oznog]

I have a project where I'd sure like to have one PIC talk to another PIC versus serial communication. However, one PIC is already talking to a GPS through the serial port and I'm not going to be getting into those wild PICs with 2 USARTs, the package is not convenient and they're a bit too far out of the mainstream for me.

So one of them can use its free USART but the other would have to bit bang either the GPS or the PIC-to-PIC port in software. That one would be a PIC18F420 running at 40MHz clock (10MHz instruction cycle). Is this even possible? The GPS runs at 4800 baud, which is slow so it sounds easier, but I also wanted to use that connection for the bootloader and it would be somewhat dicey to write this bit banging stuff into the bootloader. So I'd probably lean towards the PIC-to-PIC port which might need to run a bit faster, although my initial estimates show a slower speed might might do the job.

 

[Nigel Goodwin]

It's easy to bit-bang PIC serial ports - see my tutorials for details of the routines I use.

A great deal depends on what the devices are doing though?, the easiest way is to have the receiving PIC continually polling the input pin waiting for a start bit - but this isn't practical if the device is already busy at that time. In which case you would probably have to use an interrupt from the I/O pin.

As for bootloaders, there is code on the net for either hardware based ones, or bit-banging ones - personally I've always used the hardware based ones, but bit-banging gives you the advantage of being able to pick the pins you use.

As you already have a hardware serial port, why not use that for the bootloader?.

 

[evandude]

I can't speak for all of them, but the bootloader I have used (BLoader) was perfectly fine with using a USART that was normally used for something else... you'd just have to temporarily disconnect your GPS. after the bootloader finishes (after loading code, or after a short time if you aren't going to load code on booting...) the USART is free for your program to use like it would be normally. even just adding a DPDT switch to your design to switch between GPS and bootloader would be sufficient if you didn't want to unplug the GPS unit between loadings.

 

[bmcculla]

If you have 2 extra port pins a clocked setup would be a bit easier to deal with than a UART. You have a data and clock line going both directions - 2 clocks and 2 data lines. The PIC sends on one set and receives on the other giving full duplex. If you keep the data rate low you can use a periodic interrupt to send each bit and an edge or level triggered interrupt to receive each bit. This would let you get by with very little processor overhead. The interrupt would be short enough that your code shouldn't be bothered by it. This would let you write your code as though you had a hardware serial module.

 

[evandude]

if you were developing your own bootloader, sure. but it sounds like he wants to find an existing bootloader to use. writing your own bootloader isn't the fastest way to get your project working :wink:

not to mention, using 4 I/O lines just for serial doesn't sound very appealing unless you have tons of I/O that you're not using...

 

[bmcculla]

writing your own bootloader isn't the fastest way to get your project working

True, but I have a bit of a "do it yourself" complex.

using 4 I/O lines just for serial doesn't sound very appealing unless you have tons of I/O that you're not using

But if you do have them the software is simpler and much more tolerant of timing issues.