How to convert PID output into meaningful result to feed into controller

Thanks you all, the reason I have PIC an pocketbeagle is because, PIC handles ZeroCross detection and creates software PWM according to the value supplied by pocketbeagle, which handles PID. I need to have USB,WiFI n LCD display and embedded webserver functionality that's why I chose poketbeagle and since it can't handle zero cross detection or any real time processing (unless I dive into PRU codes, which is a bit of a learning curve that I would want like to avoid at this stage), I moved the ZCD code to PIC. Unfortunately I can't post all the code here because it belongs to the company.

I fought with the PIC code for it to accept a string and then change that string to integer, I am doing the same at the moment but just for a single character instead of a string. If I can get a string and then itoa(str) then, I can have a bigger resolution instead of just 0 to 9  and that may solve the problem. For some reason the PIC halts or at least it stops activating the tirac used to switch coil. It always stops the coil and never gets stuck in ON position. Here is my PIC code.

#include <xc.h>
 #include <stdlib.h>
#include <math.h>
#include <stdint.h>
#include "main.h"
#include "UART.h"


// BEGIN CONFIG
#pragma config WDTE = OFF       // Watchdog Timer Enable bit (WDT disabled)
#pragma config PWRTE = OFF       // Power-up Timer Enable bit (PWRT enabled)
#pragma config BOREN = ON       // Brown-out Reset Enable bit (BOR enabled)
#pragma config LVP = OFF        // Low-Voltage (Single-Supply) In-Circuit Serial Programming Enable bit (RB3 is digital I/O, HV on MCLR must be used for programming)
#pragma config CP = OFF         // Flash Program Memory Code Protection bit (Code protection off)
#pragma config FEXTOSC = OFF    // External Oscillator mode selection bits (Oscillator not enabled)
#pragma config RSTOSC = HFINT1  // Power-up default value for COSC bits (HFINTOSC (1MHz))
//END CONFIG
int i=0;
int my_delay = 10000;
int t, value=0;
char zc;
char result[2];
char foo, buffer[3] ; // 10(0x0D))
char counter=0; 


void interrupt ISR(void)
{
    if(INTF) // check if RA2/INT interrupt is triggered.
        INTF=0;
         GIE=0;
        zc = 1;
        if(INTEDG)
            INTEDG =0;
        else
            INTEDG =1;
        GIE =1;
}


setup(void)
{
    TRISA4 = 0; //Set as output 
    TRISAbits.TRISA2 =1;
    ANSELAbits.ANSA2 =0;
    INLVLAbits.INLVLA2 = 1;
    INTPPS = 0x02;
    INTE =1;
    INTF = 0;
    INTEDG = 1;
    
    zc = 0; 


    PEIE =1;
    GIE=1;          //Enable Global Interrupt
    
   delay_ms(500);
}


delay_ms(unsigned int ms)
{
    while(ms > 0)
    {
        __delay_ms(1);
        ms--;
    }
}
void delay_10us(unsigned int us_count)
 {
    while(us_count!=0)
      {
        for(int i=0;i<11;i++)
        {
         __delay_us(1)  ;
us_count--;
        }
   }
   }






ser_process()
{
   char str[8];
   {
   UART_Read_Text(str,8);
   delay_ms(200);
   UART_send_string(str);
    }


#if 0 
    if(RC1IF)
    {


   foo = UART_get_char();
   buffer[counter]=foo;
   counter++;
   if(foo==0x0D)
   {
   buffer[counter]=0x00; // remove 0x0D
   my_delay = atoi(buffer);
   if(my_delay>9) // make sure not to overshoot
       my_delay=9;
   UART_send_string(buffer);
   itoa(result,my_delay,10);
   
   for(int i=0;i<3;i++)
   {
       buffer[i] =0x00;
      
   }
    counter = 0;
   
   }
             }


#endif
            
}
void main(void) 
{
  
    OSCCON1bits.NDIV = 0; // necessary 
    OSCFRQbits.HFFRQ = 0b011; // 8MHz
    
    Initialize_UART();
    setup();
    my_delay = 1;


        while(1)
            
        {


#if 1
            while(zc==0);
            
            {     
            delay_ms(0);  //THIS IS WHERE THE VALUE FROM PID SHOULD GO
            RA4 = 1;
            }
            __delay_us(500);
            RA4 = 0;
            zc = 0; 
#endif


          ser_process();
    
    

        }


    
    return;
}

I played around with it and found that even if I try to receive individual characters, it can't handle more than than three characters and then it gets stuck, the code still responds to UART but the heating coil stays off. In the above code I have hard coded for it to stay on (delay_ms(0)), and still it goes off, and  this is where I would want to use __delay_us instead, to get higher resolution, so I can send inputs e.g 34587, instead of just 3. So the question is why above code would suddenly turn the heating coil off ? while continue to respond to UART. Thanks

I get the feeling you are new to all this embedded stuff.

My first bit of advice is that you should never leave an unexplained observation to fester.

You say that the triac turns on and then turns off unexpectedly. You need to know why.  You haven't posted a circuit so I can't help you work that out.

You need to get a scope on it ( EXTREME CAUTION - IF YOU ARE CONNECTED TO MAINS POWER).

Start with the simplest of PIC code that just switches the triac on for a 20 cycles and then off, get that working.

Your UART code doesn't work but you are calling  functions like UART_Read_Rext() which we can't see - are they any good.

Which of the many PIC processors are you using and which debugger. All modern PICs support hardware debugging - you need to use it to see what is going on.

If your system is mains powered then for development I very strongly suggest that you use low voltage  AC (like 24V) from  a transformer.

If you are not using opto coupled drivers (possibly with built in zero crossing detection) - why not - unless you are going to build many thousands of this thing it is a totally false economy to direct drive a mains switching triac.

Do you actually need cycle by cycle control or could you use integral cycle "pwm" - if your thermal time constant is long enough (greater than about 20 seconds) then you can - then you could use a nice, safe, ready made solid state switch.

Finally, a point of ethics, if you are working on a commercial project you should say so and give a little detail (like the area of business) - many people on E14 will still help you if this is your paid work, but might not wish to do so or may have ethical reservations about some areas of work.

Hope some of this helps.

MK

Thanks Michael, I am not new to this embedded stuff, I have about 10 years of experience in electronics and maintain an RTOS product as part of my full time work, what I am not good at is explaining things on forums.

Yes I  am using optocouplers to drive triac and yes I have tested it with basic code etc.

The UART works fine, that's why I didn't add the code for UART.

The PIC is 16F15323. I am using PID because that is client requirement -- so yes this is a commercial project.

Finally I figured out what is causing the problem, I still haven't figured out how to solve it. -- The problem is by the time UART finishes receiving three or more char, a zero cross interrupt had already occurred, so the TRIAC misses the opportunity to get triggered, I think it's just about resetting the trigger flag at the right place. -- a little break and a fine cup of tea, that's all I needed to see things more clearly.

Thanks everyone for the help.  

Thanks Michael, I am not new to this embedded stuff, I have about 10 years of experience in electronics and maintain an RTOS product as part of my full time work, what I am not good at is explaining things on forums.

Yes I  am using optocouplers to drive triac and yes I have tested it with basic code etc.

The UART works fine, that's why I didn't add the code for UART.

The PIC is 16F15323. I am using PID because that is client requirement -- so yes this is a commercial project.

Finally I figured out what is causing the problem, I still haven't figured out how to solve it. -- The problem is by the time UART finishes receiving three or more char, a zero cross interrupt had already occurred, so the TRIAC misses the opportunity to get triggered, I think it's just about resetting the trigger flag at the right place. -- a little break and a fine cup of tea, that's all I needed to see things more clearly.

Thanks everyone for the help.