12F683 97％完全需要优化反馈

如果您想看到完全优化，可以激活EVE模式。此外，您可以租用完整的专业版，每月30美元。你可以得到一个更大的PIN兼容PIC，如果满足项目。



      以下为原文

    You can activate eval mode if you want to see full optimization. Additionally you can rent the full pro version for $30 per month.
You could just get a bigger pin compatible PIC if that satisfies the project.

范数，1）我已经拥有专业版本2了，不可能有硬件更改。其中300000个小部件的制造成本为30000000（3000万美元），其中2/3个作为太阳能微型逆变器被出售并部署到全世界的家庭拥有者，这意味着仅仅是一个Flash更新。



      以下为原文

    Norm,
 
1) I already have the professional version  
2) There can be no hardware changes.  300,000 of these widgets were manufactured at a cost of 30,000,000 (30 million dollars), and 2/3 of them were sold and deployed to home owners all over the world as solar micro inverters
This means to be a flash update only. 

尽可能保持清洁和简化代码。之后，转到汇编程序。



      以下为原文

    Keep cleaning and simplifying the code while you can. After that, go to assembler.

ASM或查看具有更多闪存的PIC12F1XXX。



      以下为原文

    ASM or look into the PIC12F1xxx that has more flash memory.

这就留下了ASM和完整的ASM功能。



      以下为原文

    That leaves in line ASM and full ASM functions.

XC18？你是说C18吗？只有PIC18，所以PIC12就出来了。来自ISR的函数调用要求ISR存储更多的上下文加上调用和返回，因为您在搜索阶段，将代码直接放在ISR中可能是值得的。



      以下为原文

    XC18? Do you mean C18? It's only for pic18 so the pic12 is right out.
Function calls from an ISR require the ISR to store more context plus the call and return, and since you're at the scrounging stage it's probably worth it to put the code directly in the ISR

第一个XC8不是为像PIC12F63这样的小内存目标做的，它只不过比大多数内存少。这是你所知道但已经忘记的：“PrtTF”的标准C库实现是对资源有限的目标的不合理的Buffice软件。因此，编写自己的PrtTF实现，只支持您需要的格式说明符。XC8将相同的常数字符串组合到单个对象中，因此尽可能避免使用几乎相同的字符串常量。将实现拆分为单独的语句。示例：并在可能的情况下减少或消除字符串常量。



      以下为原文

   
First XC8 is not made for small memory targets like the PIC12F683 it just sucks less than most.
 
This is something you know but have forgotten: The standard C library implementation of "printf" is ungodly bloatware for resource limited targets. So write your own implementation of printf that supports only the format specifiers you need.
 
XC8 will combine identical constant strings to a single object so avoid using nearly identical string constants when possible. Split the implementation in to separate statements.
 
Example:/* Change this: */
 printf("Volts: [%d]n",PV_volts);
 printf("Amps : [%d]n",PV_current);
 printf("Watts: [%d]n",PV_power);
 
 /* To this: */
 printf("%s: [%d]n","Volts",PV_volts);
 printf("%s: [%d]n","Amps ",PV_current);
 printf("%s: [%d]n","Watts",PV_power);
And where possible reduce or eliminate string constants.

我只是很肤浅地看了一下，我的建议听起来可能很傻，但也许你可以节省一些空间，不需要在键盘部分中几乎两个相同的功能。当然，优化器不能区分你的PrTrF只有“…”的区别。



      以下为原文

    I just took a very superficial look and my suggestion might sound silly, but maybe you can save some space by not needing 2x almost identical functions in the keyboard section. For sure the optimizer is not able to distinguish your printf having as only difference the "...".

如果这是函数调用的唯一地方，XC8中的“全知”优化器只会嵌入代码。这就是为什么丹没有注意到这两个版本之间有很大差别的原因。



      以下为原文

   
If that's the only place the function is called, the "Omniscient" optimiser in XC8 will just inline the code.
That will be why Dan didn't notice much difference between the two versions.
 

事实上，通过重写这两个实例，实际上只从LV-Prim.CSO两个地方调用了Prtff。您可以节省5.6%的代码空间。&编辑；Gt；从POST 17中添加了这个建议：然后，在LVILeRevEnStrug中调用了库函数STRSTR。代码空间的3.6%。



      以下为原文

    As it turns out printf is actually invoked from only two places in LV-Print.c

So by rewriting those two instances you can save 5.6% of code space.

/*
    Memory Summary: (Before modification)
        Program space        used   7C1h (  1985) of   800h words   ( 96.9%)
        Data space           used    6Bh (   107) of    80h bytes   ( 83.6%)
        EEPROM space         used   100h (   256) of   100h bytes   (100.0%)
        Configuration bits   used     0h (     0) of     1h word    (  0.0%)
        ID Location space    used     0h (     0) of     4h bytes   (  0.0%)

    Memory Summary: (After modification)
        Program space        used   73Ah (  1850) of   800h words   ( 90.3%)
        Data space           used    5Fh (    95) of    80h bytes   ( 74.2%)
        EEPROM space         used   100h (   256) of   100h bytes   (100.0%)
        Configuration bits   used     0h (     0) of     1h word    (  0.0%)
        ID Location space    used     0h (     0) of     4h bytes   (  0.0%)
*/    
 
/* Functions in LV_Print.c that were modified */
void Eprom_Print_Value16(Uint8 pos, Uint16 value)
{
#if defined(USE_OLD_CODE)
#else
    unsigned char v[5];
    unsigned char vx;
#endif    
    put_eprom_str(pos);
    
    if (print_char)
    {
        putch('-');
        putch(print_char);
        print_char = 0;
    }
#if defined(USE_OLD_CODE)
    printf(":%d ",value);
#else
    putch(':');
    vx = 0;
    
    do
    {
        v[vx++] = '0' + (value % 10);
        value = value / 10;
    } while(value);
    
    do
    {
        putch(v[--vx]);
    } while(vx);
    
    putch(' ');
#endif
    if (rcb1.POK)
    {
        Print_CR1();
        PrintOK();
    }
    rcb1.POK = 0;
}

void Print_Str()
{
#if defined(USE_OLD_CODE)
    printf("%s ",rxStr);
#else
    char * pC;
    pC = rxStr;
    while (*pC)
    {
        putch(*pC);
        pC++;
    }
#endif
}


Added this suggestion from post #17:

Then there is the library function strstr invoked in LV_Receive_String.c

Rewriting this instance you can save 3.6% of code space.
/*
    Memory Summary: (Before modification)
        Program space        used   73Bh (  1851) of   800h words   ( 90.4%)
        Data space           used    5Fh (    95) of    80h bytes   ( 74.2%)
        EEPROM space         used   100h (   256) of   100h bytes   (100.0%)
        Configuration bits   used     0h (     0) of     1h word    (  0.0%)
        ID Location space    used     0h (     0) of     4h bytes   (  0.0%)
       
    Memory Summary: (After modification)
        Program space        used   6E1h (  1761) of   800h words   ( 86.0%)
        Data space           used    5Fh (    95) of    80h bytes   ( 74.2%)
        EEPROM space         used   100h (   256) of   100h bytes   (100.0%)
        Configuration bits   used     0h (     0) of     1h word    (  0.0%)
        ID Location space    used     0h (     0) of     4h bytes   (  0.0%)
*/    
 
/* Functions in LV_Receive_String.c that were modified */
Uint8 str_compare(const char *s)
{
#if defined(USE_OLD_CODE)
    if (strstr(rxStr, s)==0)
        return 0;
    return 1;
#else
    Uint8 Result = 0;
    const char *s2 = rxStr;
    while (!Result)
    {
        if(*s)
        {
            if(*s2)
            {
                Result = (*s++ == *s2++)?0:1;
            }
            else
            {
                Result = 1;
            }
        }
        else
        {
            break;
        }
    }
    return Result;
#endif    
}

XC8已经为你做到了这一点。在上面的代码中，将%d的不必要的使用更改为%u，并注意代码大小的减少。%s不是免费的，所以你必须权衡一下，看看它是否有帮助。



      以下为原文

   
 
XC8 already does that for you.  In the above code, change the unnecessary use of %d to %u and notice the code size reduction.
 

 
Maybe.  %s is not free, so you'd have to do a trade-off to see if it helped.

我还看到了一些其他的事情：在使用无符号字符的循环中不使用简单的“int”。许多特定的延迟例程，可以用编译器的内置例程来代替。使用位字段，节省RAM，但增加代码大小。



      以下为原文

    Some other things I see:  inappropriate use of plain "int" in loops where unsigned char could be used.  Lots of ad-hoc delay routines that might be able to replaced with the compiler's built-in routine.  Use of bit-fields, which save RAM, but increase code size.
 

OPS代码有很多方法可以从大小循环迭代变量适当地改进到更高效的函数实现方法。但是，我确实反对使用编译器内置延迟程序的建议。在我的经验中，XC8内置延迟使用每个实例的代码空间，并且延迟时间必须是常数。需要多于一个延迟时间的应用程序或从多个函数中使用的XC8内置延迟会浪费代码空间。



      以下为原文

   


There are many ways that the OPs code could be improved from sizing loop iteration variables appropriately to more efficient function implementation methods.
 
But I do take exception to your suggestion to use the compiler's built-in delay routine. In my experience the XC8 built-in delay uses code space for each instance and the delay time must be a constant. An application that needs more that one delay time or is used from more than one function the XC8 built-in delay wastes code space.

不确定是否有用，黑客的一点……在StruxCube（）中，而不是使用STRSTR，你只能比较几个字符，比如说第一个、第三个和最后一个（例如，调试用的dBG，RAMP1的RM1……查找第一个字符匹配并比较REST 2。当然，这意味着D？B？G将匹配调试，就像我说它是一个黑客毕竟。显示粗略更改后的92%个用法



      以下为原文

    Not sure if helpful, bit of a hack...
 
In str_compare() instead of using strstr you could compare only a few chars, lets say the first, third and last (e.g. DBG for DEBUG, RM1 for RAMP1... look for first char match and compare rest two). Of course this means the D?B?G would match DEBUG, like I said it a hack after all. Shows 92% usage for me after rough changes

你可以尝试从10到8改变样本数，这样平均值可以用3个位置的简单移位来计算。或者直接使用10个样本的和。它仍然适合一个最大值为10230的整数。我也不确定你在这里做什么，但是任何可以避免数学函数的地方都可以节省空间：



      以下为原文

    You might try changing NUMBER_OF_SAMPLES from 10 to 8, so that the average can be calculated with a simple shift of 3 places. Or maybe use the sum of 10 samples directly. It would still fit an integer with maximum value of 10230.
 
Also I'm not sure what you are doing here, but anyplace you can avoid math functions can save space:
        // DGA calulate PV voltage from ADC reading  - 72 cell potential divider less
        cbyte.tmpIntA = 460;
        if (pv_adc < 122)
            cbyte.tmpIntA = 450;
        cbyte.tmpIntB = (pv_adc *100) / cbyte.tmpIntA;

去掉Struts（）会有一个很好的保存：原件：修改（未经测试，确保PARAM S终止，而不是用终止符开始）：



      以下为原文

    Getting rid of strstr() results in an a good saving:
 
Original:Program space used 7B8h ( 1976) of 800h words ( 96.5%)
Data space used 6Bh ( 107) of 80h bytes ( 83.6%)
 
Uint8 str_compare(const char *s)
{
    if (strstr(rxStr, s)==0)
        return 0;
    return 1;
}
 
 
Modified (untested, make sure param s is terminated and does not start with a terminator):Program space used 751h ( 1873) of 800h words ( 91.5%)
Data space used 6Bh ( 107) of 80h bytes ( 83.6%)
 
Uint8 str_compare(const char *s)
{
    const char * s2 = rxStr;
 
    do {
        if (*s == '') {
            return 1U;
        }
    } while (*s++ == *s2++);

    return 0U;
}

对不起的。。。是的，我指的是C18



      以下为原文

    Sorry ... Yes I meant C18

丹1138，你是个天才…做得好。这两个变化…去除PrtTf确实减少了大约6%的尺寸。



      以下为原文

    dan1138,
Your a genius ... Well done.  those two changes ... getting rid of the printf did yield a roughly 6% reduction in size.

关于延误…这些函数α-DelayMySo（）.YelDayaySU.（1），它们假定FoC被校准，并使内联NOPS得到延迟时间-每个唯一的调用导致NOPS的单独功能被创建或插入。它使用的是8MHz的内部振荡器。数据表意味着图片被校准并且在合理的公差之内。那不是真的。事实上，我看到的范围是+或20%。更糟的是，MPLAB（和IPE实用程序）有一个菜单选项用于校准，但它什么也没做。实际上，我必须花2个星期的时间来解决故障问题，直到我意识到单元有多远。我必须在ISR中使用一个GPIO引脚，并使用一个SeopeTo来测量每秒2400个时钟。然后，我必须编写一个特殊版本的固件来校准和存储EEPROM存储器中的偏移量。所以你把校准固件闪到PIC中，把它连接到发送回车的主机上，这个“校准”问题比人们意识到的要差得多。这12F63有这个寄存器用于校准，所以我发现这个寄存器没有足够的调整。在一些单位，不是全部，这个登记册的调整不够远。单位为15至20%关。所以，我最后做的只是调整写入到Time0的值。如果单位是频率48，十进制应该是精确的数字，以每秒9600滴答。但在一些单元中，由于OSCTUNEbits.TUN没有足够的调整，所以它需要被抵消多远。我不使用OctTuneButsTun，对吗？下面是我对OsCuteBITS的理解。TunRealStices是一个5位有符号整数。最有效的位，当SET是否定的。SoDeMybit 0在OSCTUNEbits.TUNis中减去OsTuntBITS。Tunas，虽然它是一个整数，它开始下陷。我想……把它设置为数字15是最快的频率设置，它对数字31来说是最慢的。我有点倒退吗？移动…LVHSYNC。C是校准码。只有当您有条件地编译固件的专用版本来校准单元时，才会编译。因为没有足够的空间。它应该开始设置OSCTUNEbits.TUNto的最高可能值，然后加倍Time0的两倍快，因为它应该是。这个想法是开始尽可能高，然后寻找ACRACEGE返回-如果接收到的字节不是CD，然后它减少了一个计数的计时器。在第一次看到CR时，它通过保存临时整数中的Time0值来设置高水位标志。它继续扫描等待更多的CRS，直到接收到的字符不再匹配CR。它在不同的整数中设置低水位标志。执行一个FunkySalk，然后将偏移量写入EEPROM。这个校准代码工作得很好。使用我的范围上的GP测试引脚，我总是看到平均在1至2%的频率。我必须玩一个特定的“FunkySalk”代码来获得一些单位来校准。好的，所以当这个固件被编译为校准大小并不重要——大多数运行时代码是被编译的，所以我没有任何内存大小的问题。校准码。好了，现在回到特设的延迟，你指的是简单的内存标签变量，这些计数器是用9600个TIC定时器或其他代码分成2400个递增的计数器。实际上，没有编译代码空间，相反，编译程序延迟函数在NOPSDan使用空间编译。



      以下为原文

    About delays ... these functions  
__delayms()
__delayus()
 
#1 they assume the FOSC is calibrated and cause inline NOPS to get a delay time - Each unique call causes a separate function of nops to be created or putinline. 
 
#2 This PIC12F683 is on a daughterboard and has no crystal.  It is using the internal oscillator at 8mhz.   The datasheet implies the Pics are calibrated and within reasonable tolerance.  That is not true.  As a matter of fact I am seeing a range of +or - 20%.  Worse, MPLAB (and the IPE utility) has a menu option for calibrate but it does nothing. 
 
I actually had to spend 2 weeks troubleshooting timing problems before I realized how far off units were.  I had to use a GPIO pin in the ISR and use a scope to measure 2400 ticks per second.
 
I then had to write a special version of firmware just to calibrate and store the offsets in EEPROM memory.  So you flash the calibration firmware into the PIC, connect it to host computer which sends Carriage returns
 
This "calibration" problem is far worse then people realize. 
This 12F683 has this register for calibration
 
OSCTUNEbits.TUN
 
So what I found is that this register does not have enough adjustment.  In some units, not all, this register did not adjust far enough.  On units as far as 15 to 20 %off.    So what I ended up doing was simply adjusting the value written to TIMER0
If the unit was on frequency 48 decimal should be the precise number to get 9600 ticks per second.  But in some units it is crazy how far it needs to be offset because OSCTUNEbits.TUN doesn't have enough adjustment.   
 
 
Look at LV_EEprom.c   ...
void Write_OscTune_EEPROM()
void Write_Timer0_EEPROM()
These write the combination of OSCTUNEbits.TUN and timer0_reg  to get the precise calibrated frequency.
Perhaps I'm not using OSCTUNEbits.TUN right?  
 
Here is my understanding of the OSCTUNEbits.TUN  register
 
Its a 5 bit signed integer.  The most significant bit when set means negative.  
So decimal 0 written to OSCTUNEbits.TUN  is in the middle - decrementing OSCTUNEbits.TUN  as though it was an integer
it starts going down one notch.   
 
I thought ....
 
Setting it to the number 15 is the fastest frequency
Setting it to the number 31 is the slowest frequency
 
Do I have something backwards ?
 
Moving on ...
LV_SYNC.C  is the calibration code.  It only gets compiled in when you conditionally compile a specialversion of the firmware to calibrate the units.  Because there is not enough room.  It is supposed to start by
setting OSCTUNEbits.TUN  to the highest possible value and then doubling timer0 twice as fast as it should be.  The idea is start as reasonably HIGH as possible and then look for a CARRIAGE RETURN - If the byte received is not a CD then it decrements the timer by a count of one.  The very first time it sees a CR it sets a HIGH WATER MARK by saving the timer0 value in a temporary integer .  It continues scanning waiting for more CRs until the characters received it no longer match CR.  It sets a low water mark in a different integer.  Performs a funky average and then writes the offsets to EEPROM.
 
This calibration code works very well.    Using my scope on the GP test pin I always see frequency within an average of 1 to 2 percent.  I had to play  around with the adhoc " funky average" code to get some units to calibrate.
 
OK so when this firmware is compiled for calibrate size doesn't matter - most runtime code is condtionally compiled out so I don't have any memory size problems. 
 
I'm sure there is lost of room for improvement with the calibrate code.
 
OK so now back to the adhoc delays you reference
 
They are simply memory tag variables used as counters that are incremented with either the 9600 tic timer or the further code that divides down to 2400.
 
Either way these adhoc delays are giving me precise timing that works and they are using virtually no code space.
 
In contrast the compiler__delay  functions use allot of space compiling in NOPS
 
Dan