Electronics > Microcontrollers

PIC16F676 three phase waveform generation help

<< < (5/5)

poorchava:
I would consider fully drivinf serial comms with interrupts. Currently you are using
--- Code: ---//Wait till the SSPIF interrupt interrupt is triggered
    __delay_us(2);
--- End code ---

I think this may be source of your problem. Using hardcoded loop-type delay isn't something to do on a resource limited MCU in the first place. On the to of that I strongly suspect that Microchip's implementation of Delay functions may disable interrupts (eg. pending interrupt is not serviced as long as delay loop lasts).

You may implement some kind of queue, write on byte for transmiting and then go to other tastks. When transmit is complete you get an interrupt and send another byte in queue. Of course this would be lower priority than signal generation. This way you omit the hardcoded delay loop and also probably save some CPU cycles.

krish2487:
Actually the comments are self explanatory.

I am using interrupt driven SPI transfer.
If you look at the interrupt routine, you ll see


--- Code: --- //If the serial data is generating the interrupt
    if(SSPIF==1)
    {
        //Clear the interrupt flag and return to main
        SSPIF=0;
       
    }
--- End code ---

i used a small delay of about 3 useconds to make sure that a particular SPI byte transfer takes place and generates an interrupt.

the SPI is set up to run at FoSC/4.
With a 20MHz cyrstal thats about 5 MHz.

the serial clock freq should be about 200ns.

It takes about 1.6us for 8 clock cycles.

I am using a 2 useconds delay to make sure that the interrupt is triggered before the  __delay_us(2) finishes and that the interrupt is attended to.

If you look at the code, in the interrupt section



--- Code: ---Send_Serial_Byte(DAC_LOOKUP_TABLE[R_PHASE_INDEX]);
         Send_Serial_Byte(DAC_LOOKUP_TABLE[Y_PHASE_INDEX]);
         Send_Serial_Byte(DAC_LOOKUP_TABLE[B_PHASE_INDEX]);

--- End code ---

Because all the serial data is sent one after another and the MSSP port being a hardware SPI port, i wasnt sure that between one serial transfer to the next the processor would generate a proper serial byte transfer interrupt. Hence, i assumed it would be prudent to give a small delay between transfers to ensure that the interrupt is definitely generated and serviced.

However, now that you mention it, it might be worth trying to see how it performs without the __delay_us(2) in the serial byte transfer routine.

Navigation

[0] Message Index

[*] Previous page