如何升级到MPLAB X ide和MPLLABXC8编译器

你已经失去记忆了。免费使用更多。如果您有原始版本的许可证，请安装该编译器版本并使用它。其他选项：1。新的每月30美元计划。2。更新当前的许可证3。在不同的计算机上工作。



      以下为原文

    You are out of memory.  Free uses more.
If you have a license for the original version, install that compiler version and use it.
Other options:
1. The new $30 a month plan.
2. Update you current license
3. Work on a different computer.

NKurzman，谢谢你的建议。请帮我仔细考虑一下.1)显而易见，当你说“免费使用更多”时，我想你的意思是CX8编译器的免费版本使用更多内存。然后你暗示，如果我购买了它的许可证，它可能会使用更少的内存，而我的内存错误*可能会消失。我对你的理解正确吗？（顺便说一下，我还没有把我使用的任何东西转移到订阅许可证上。这将是第一个。）2）“更新你的当前许可证”是什么意思？你是指CX8编译器还是高科技？请注意，我有一个高科技许可证回到2002。但那是14年前的事了。在一个已知的下载文件夹中，我通常将许可证密钥和文本文件保存在安装程序的同一文件夹中。我有14年前的下载文件夹，里面有安装程序。但我没有看到任何许可证信息。因此，我可能无法重新授权它。3)是的，我认为你的意思是不同的计算机将允许旧的高科技试验再次运行短期。当然，这不是一个好的长期解决方案。**4**)所以在我看来，对于拥有这个旧IP的客户来说，最好的办法就是继续将它们转移到CX8编译器。这意味着要支付订阅许可证，并希望它能起到作用。这个客户没有给我提供足够的工作来证明长期支付这种许可证是正当的，而且没有直接向客户记账，这的确是我能做到的。特殊问题：我可以开始和停止，开始和停止按需订阅，只使用四分之一，或每年一次，[LOL或十年一次]？顺便说一句，我确实意识到它已经失去记忆了。我现在还记得10年前，为了让项目的高科技编译版本适合可用内存[RAM]，我不得不进行调整和调整。看来这只是对同一个问题的复活，再次感谢。



      以下为原文

    NKurzman,
 
Thanks for your advice.  Please help me think through this very carefully.
 
1) To be explicit, when you say "Free uses more", I assume you mean that the free version of the CX8 compiler uses more memory.  You are then implying that if I purchase a license for it, it *might* use less memory and my memory error *might* go away.  Am I understanding you correctly?  (BTW, I have yet to move anything I use to a subscription license.  This would be the first.)
 
2) What do you mean by "Update you[r] current license"?  Are you referring to CX8 compiler, or Hi-Tech?  Do note that I had a license for Hi-Tech back in 2002.  But that was 14 years ago.  I normally keep license keys and such as a text file in the same folder as the install program, in a known download folder. Well, I have the download folder from 14 years ago, with the install program in it.  But I don't see any license info.  So I may not be able to re-license it.
 
3) Yes, I take it that you mean a different computer would allow the old Hi-Tech trial to run again for a short period.  Of course, this is not a good long term solution.
 
**4**) So it seems to me that the best thing to do for my client, who owns this old IP, is to press on in moving them forward to the CX8 compiler.  That means paying for the subscription license and hoping that it does the trick.  This client doesn't provide me with enough work to justify long term payment of such a license without also billing it straight through to the client, which I can indeed do.  SPECIFIC QUESTION: Can I start and stop and start and stop the subscription on demand, using it only once a quarter, or once a year, [LOL or once a decade]?
 
BTW, I did independently realize it was out of memory.  I do now recall as recently as 10 years ago, having to tweak and tweak and tweak to get the Hi-Tech compile version of the project to fit into available memory [RAM].  So it seems this is just a revival of the same ol' problem.
 
Thanks again.

新的月票执照就像一个付费电话（但没有限制分钟；-）。你每月付30美元。在月底，编译器恢复为空闲。然后任何时候你可以再支付30美元一个月。



      以下为原文

    The new monthly license is like a PayG phone (but without the limit on minutes;-) ). You pay ~$30 for a month. At the end of the month the compiler reverts to free. Then anytime later you can pay for another ~$30 for another month.

Switurn:MigChIP.com。给他们发电子邮件，他们可能有你旧牌照的信息，因为他们买了高科技。如果你仍然有序列号，它会有帮助，否则它注册的电子邮件。每月30美元的许可证每月只需30美元。在XC8上也有免费试用期，如果你想看看它有多大的工作量。



      以下为原文

    SWLicensing@microchip.com.
Email them they may have the info on your old license, since they bought hi-tech. If you still have the serial number it would help, other wise the email it was registered to.
The $30 a month licenses just that $30 for every month you use it.
There is a free trial period on xc8 too, if you want to see how much work it is to port over to it.

是的，HI-TECH许可证数据库仍然存在，如果SW.ing@micro..com的人找不到您需要的，您的请求可能会向我传递。（它们有一个与DB的GUI接口；如果需要，我可以输入原始SQL查询。另外，我脑子里还有一堆高科技的历史。）我会留心它的。公司名称和其他任何你能记得的细节也会简化追踪。另外，一定要告诉他们你购买了原始许可证的大概日期（一年就足够了）。



      以下为原文

   
Yes, the HI-TECH license database is still alive, and if the folks at SWLicensing@microchip.com can't find what you need your request will probably make its way to me. (They have a GUI interface to the DB; I can type raw SQL queries if necessary. Plus, I have a bunch of HI-TECH history inside my head.) I'll keep my eye out for it.
 

The company name and any other details you can recall will also simplify tracking it down. Also be sure to tell them the approximate date (year will suffice) that you bought the original license.

感谢许可证的建议。事实上，我可能会回到高科，或者可能调查许可证历史等等。然而，现在，我想再次关注内存使用和可用性。XC8 PRO优化改进了该项目，使其足够适合并工作。然而，在另一个项目中，SC8 PRO优化还不够。详细信息：在BIGRAM类中，psect bssBIGRAM需要0x980单词。自由优化仅具有0x6B0邻接空间。PRO优化是更好的，但仍然只有0x738邻接空间可用。所以我不得不问自己，“为什么XC8编译器有这么小的可用邻接空间？”改写，“XC8编译器浪费这么多内存”在哪里？仅仅为了能够得到一个有意义的地图，我将一个数据包缓冲区从220个条目减少到168个。这允许构建成功，但我不想只用76%的包缓冲器来操作（168/220）。但至少我得到了一个有意义的地图。我把这张地图和从高科技编译器中得到的旧地图进行了比较（使用了220个包缓冲条目，使用了0x97C大字，远远超过了XC8编译器留给我的0x738）。在论坛的代码引文中弄乱了）BANG0到BANK5项目可能是额外或浪费空间的去向。你知道那些是干什么用的吗？我可以消除，减少，或以其他方式使他们不偷这么多的记忆？现在，上面的引文使它看起来像大多数的Box存储器。但是地图的另一部分让我想到了另一种情况：例如，在上面，cstackBANK3从3A9开始，这远远超出了cstackBANK2，cstackBANK2以200开始，长度为DD。最后，作为参考，我附上了OLD HI-TECH和新XC8编译器输出的地图文件。XC8的输出超过了论坛的限制，所以我把它分成两部分。
LCD_LCD_control_P...8MAP（第1部分），txt（426.09KB）-下载116次LCD_LCD_control_P...8MAP（第2部分），txt（122.66KB）-下载115次



      以下为原文

    Thanks for the licensing advice.  I might move back to Hi-Tech in fact, or might investigate the license history, etc.
 
HOWEVER, for right now, I want to focus again on the memory usage and availability.
 
The XC8 PRO optimization improved that project enough to fit and work.  HOWEVER, on a different project, the SC8 PRO optimization was not enough. 
 
Details: There was a need for 0x980 words for psect bssBIGRAM in class BIGRAM.  The free optimization had only 0x6b0 contiguous space available.  The PRO optimization was better, but still only had 0x738 contiguous space available.  So I had to ask myself, "why is the XC8 compiler having such a drastically smaller available contiguous space?"  Rephrased, "where is the XC8 compiler wasting so much memory"?
 
Merely to be able to get a map that made sense, I reduced a packet buffer from 220 entries to 168.  That allowed the build to succeed, but I don't want to operate with a packet buffer only 76% as large (168/220).  But at least I got a map that made sense.

I've compared this map to an old map I had from the Hi-Tech compiler that worked (with 220 packet buffer entries, using 0x97C words of bigbss, far more than the 0x738 that the XC8 compiler left me).
 
The following section got my attention:  (Sorry the columns get messed up in the code quote of the forum.)
SEGMENTS Name Load Length Top Selector Space Class

                reset_vec 000000 000004 000004 0 0 CODE
                cstackCOMRAM 000001 00005B 00005C 1 1 COMRAM
                intcode 000008 000008 000010 4 0 CODE
                intcodelo 000018 009913 00992B C 0 CODE
                cstackBANK0 000060 000096 0000F6 60 1 BANK0
                cstackBANK1 000100 0000F5 0001F5 100 1 BANK1
                cstackBANK2 000200 0000E4 0002E4 200 1 BANK2
                bssBANK3 000300 0000E2 0003E2 300 1 BANK3
                bssBANK4 000400 0000CE 0004CE 400 1 BANK4
                bssBANK5 000500 0000C8 0005C8 500 1 BANK5
                bssBIGRAM 0005C8 000738 000D00 5C8 1 BIGRAM
                mediumconst 00E7B6 00184A 010000 73DB 0 MEDIUMCO
                idloc 200000 000008 200008 200000 0 IDLOC
                config 300000 00000E 30000E 300000 0 CONFIG

 
 The bank0 to bank5 items may be where the extra or wasted space is going.  Do you know what those are for?  Can I eliminate, reduce, or otherwise make them not steal so much memory?
 
Now, that quote above makes it look like all that bankX memory is mostly used.  But another section of the map makes me think otherwise:
                cstackCOMRAM 1 1 47 1 1
                cstackBANK0 60 60 96 60 1
                cstackBANK1 100 100 E6 100 1
                cstackBANK2 200 200 DD 200 1
                cstackBANK3 3A9 3A9 38 300 1
                cstackBANK4 47E 47E 50 400 1
                bssBIGRAM 5C8 5C8 738 5C8 1
                bssBANK5 500 500 C8 500 1
                bssBANK4 400 400 7E 400 1
                dataBANK3 3E1 3E1 1 300 1
                bssBANK3 300 300 A9 300 1
                bssBANK2 2DD 2DD 7 200 1
                bssBANK1 1E6 1E6 F 100 1
                bssCOMRAM 48 48 13 1 1
                cinit 82A0 82A0 78 C 0
                idataBANK3 992A 992A 1 C 0

 
 In the above, the cstackBANK3, for example, starts at 3A9, which is much beyond cstackBANK2 that starts at 200 and is DD in length.
 
Finally, for your reference, I've attached the map files for the OLD HI-TECH and NEW XC8 compiler outputs.  The XC8 output was over 500MB forum limit, so I broke it into two parts.
   Attachment(s)

LCD (LCD control p...LD HI-TECH MAP.txt (289.17 KB) - downloaded 116 times
LCD__LCD_control_P...8 MAP (part 1).txt (426.09 KB) - downloaded 116 times
LCD__LCD_control_P...8 MAP (part 2).txt (122.66 KB) - downloaded 115 times

我突然意识到bssBANK3从300开始使用A9单词，从3A9开始与cstackBANK3吻合。所有这些“银行”的东西都没有出现在高科技地图上。是银行分割造成我的麻烦吗？例如，我把BANG0BANK4中未使用的空间加起来，得到0x81.恢复可能会增加最近的0x738连续可用到0x7b9。这离0x980更近了一步，尽管还很害羞。我看到BANK0-BANK4自由空间的一些副本，为BIGRAM自由空间指定。我需要把一些内存使用从银行转移到二元内存吗？（尽管我之前的段落表明这还不够。）同时，我注意到BSSBIRAM，我的168个入口包缓冲区适合。BSSBIGRAM从0x5C8开始（减少）长度0x738。这就等于下一个地址为0xD00。但是在地图的顶部，命令行参数表明二元RAM上升到0x0CFF。哦！那是*匹配的。所以我的问题是从0x5C8开始太晚了。XC8编译器（链接器）启动得太晚了，因为…那些银行职员。银行是罪魁祸首。（幽默：记忆银行，而不是华尔街银行。）



      以下为原文

    I do suddenly realize bssBANK3 uses from 300 for A9 words, which dovetails in with cstackBANK3 beginning at 3A9.
However, I original problem still remains.  All this "bank" stuff didn't appear in the HI-TECH map.  Is it the bank segmentation causing my trouble?
 
For example, I add up the unused space in BANK0-BANK4 to get 0x81.  Recovering that might increase the recent 0x738 contiguous available to 0x7B9.  That's a step closer to 0x980 needed, albeit still far shy.
 
I see a somewhat duplication of BANK0-BANK4 free space, specified for BIGRAM free space.  Do I need to move some memory usage away from banks and into bigram? (Even though my prior paragraph suggests it's not enough.)
 
Also, I notice bssBIGRAM, where my reduced 168 entry packet buffer fit.  bssBIGRAM starts at 0x5C8 with (reduced) length 0x738.  That adds up to a next address of 0xD00.  But at the top of the map, command line parameters suggest BIGRAM goes up to 0x0CFF.  Oh!  That *does* match.  So my issue here is that starting at 0x5C8 is starting too late.  And the XC8 compiler (linker) starts so late because of...  those BANK guys.  The BANKs are the culprits.  (humor: Memory Banks, not Wall Street Banks.)