PIC/CPLD comms

[Iainm]

I've got a project where I'm using a PIC 16f877 to make calculations based on user settings and realtime data and come up with 8*8bit numbers which represent the desired duty cycles (percentage of 256) for 8 PWM outputs. The PWM has to be fairly high frequency, so doing it in software is out, and the pic only has 2 dedicated PWM outputs. I've decided to use a CPLD to do my PWM for me, and transfer the numbers into it from the PIC. My only problem is the best way to transfer the data to the CPLD without using too many pins on the PIC (I'm strapped as it is). Serial transfer is obviously a good idea then, but I don't want to use a whole lot of clock cycles transferring the data across one bit at a time. A compromise that's occurred to me is that I do it one nibble at a time, and use one or two more pins for control. example pseudocode is as follows:

for i=0 to 7
load duty_cycle[i] into w
copy w(7:4) to portA(7:4)
set portA(3)=1
set portA(3)=0
copy w(3:0) to portA
set portA(3)=1
set portA(3)=0
next i

The CPLD will count rising edges on portA(3) and use the counter to address 16*4bit registers, which will be parallel loaded from portA(7:4). Is this sufficient to transfer the data? Possible problems I see with it are that if the CPLD misses a nibble for whatever reason, it will permanently be off by one register, completely stuffing the pwm output. Also, the CPLD might miss the pulse on the control pin without a delay, but the CPLD will be running at a much higher clock frequency than the PIC, so this should be fine.Another possible problem is that the the comparator will be confused if we try to load data while the clock counter is close to the stored value for each channel. I've checked this one out though, and it could only mean that the pwm remains high for one clock cycle more than it should, or drop low for one cycle when it shouldn't - not a problem in this application, as the pwm output will be filtered. The synchronisation does concern me though. I could dedicate another pin to control, but I'd prefer not to. Perhaps I could give it a "start" pattern - eg, if the cpld gets a sustained low followed by a sustained high on portA(3) it knows to clear the address register and start from the first one again. For this to work though I'd need to have the timings worked out between the two devices. I could dedicate another pin to it, but I'd prefer not to. Can anyone see a better way?

 

[bmcculla]

You could use a setup like the 8051 multiplexed external bus. You Have your 4 bus pins, a write strobe, and a Address latch Enable (ALE) line.

You load the address into the port and strobe ALE. The CPLD grabs the address and decodes it. Next you load the data and strobe the write line. The CPLD loads the addressed register.

You could also use handshakeing to ensure the CPLD doesn't miss any data. You need 4 data lines, a data valid line and a data recieved line. So you load the port and set the data valid line high. The CPLD reads the data and then sets the data received line high. The Micro sets the DataValid Line low when is detects the data received line is high which causes the CPLD to set the Data received line low.

Hope this helps
Brent

 

[motion]

If your CPLD is I/O pin limited but you have enough macro cells, it is better to shift in all bits serially. Then you just need a serial Data bit and a CLK bit. You can optionally add a start/reset bit for a total of 3 I/O pins.

A single 64-bit shift register will require as many latches as an 8X8 or 16X4 parallel setup.

The PIC16F877 has synchronous serial port. Maybe you can use it.