XC32与XC32 Pro？

高科技C编译器没有被杀死，它被改名为XC8。微芯片C18编译器被击毙。16位和32位编译器是GCC前端。他们会在高科技方面有点与众不同。免费/PRO是一项高科技创新。您可以试用PRO模式来试用代码，看看代码的速度。XC8也一样（但我怀疑它会有这么大的变化）。并不是你现在可以每月租用30美元的编译器。如果你要32位，你会有其他考虑。就像你必须使用和声，这会如何影响你的时间线。你在看哪一个PIC32？



      以下为原文

    The hi tech C compiler was not killed off it was renamed XC8. The microchip C18 compiler was killed off.
The 16 and 32 bit compilers are GCC front ends. They will work a little different the the Hi tech one, out of the box. The free/ pro is a hi-tech innovation. You can try the pro mode for the trial period to see how much faster and smaller the code is. The same for XC8 , ( but I doubt it will change that much).
Not that you can rent compilers for $30 a month now.
If you are going to 32 bit you will have other considerations. Like will you have to use harmony, and how does that affect your time line. Which PIC32 are you looking at?

XC32附带免费模式下的O1优化。我发现它适合我的需要。我有“PRO”版本许可证，所有的优化都启用了。



      以下为原文

    Xc32 comes with O1 optimization in the free mode.
I find it is adequate for my needs.
I do have the "PRO" version license with all the optimizations enabled.
 

你看过PIC18F27 K40了吗？128K闪光灯。从8位到32位不会是公园里的散步。



      以下为原文

    Have you looked at PIC18F27K40... 128K flash. Going from 8-bit to 32-bit won't be a walk in the park.

免费的C18其实相当不错。比免费的XC8要好很多。如果你走32位，你就不用使用谐波。GCC许可证意味着微芯片必须使PRO编译器的源可用。您可能无法得到的是运行时库的来源。



      以下为原文

    The free C18 was actually quite good. Much better than the free XC8 by many accounts.
 
If you go 32-bit you do not have to use Harmony.o
 
My understanding is that the gcc license means Microchip have to make the source for the pro compiler available. What you may not get is the source for the run time libraries.

谢谢你。自由编译器的数量大约是70%的优化，但必须打开它们。O-O1优化（和XC8中的等价物）是很棒的，也是一个很好的开始。SouLangDi希望看到你对C18和XC8JFD的评价。



      以下为原文

    Thanks Jim Nickerson  you are spot on. The free compilers are around 70% of the optimizations by number, but you must turn them on. The -O1 optimizations (and equivalents in XC8) are great and a wonderful place to start.
 
crosland  I'd like to see your evaluation of C18 vs. XC8.
 
jfd

什么帐户？代码是更大和更慢（帐户），并没有按照C标准接近XC8做。它有一个典型的堆栈（和XC8/HiTeo上的选项），这使得它慢一些，因为PIC18没有硬件来支持它。这允许支持重新入侵者。因此，头对微芯片选择了高科技产品，它也不支持PIC12-16它是一个销售足够的产品，许多人使用它多年。



      以下为原文

   


What accounts? The code was bigger and slower (by accounts) and did not follow the The C standard as close as XC8 did.  It did have a typical Stack (and Option on XC8/Hi-Tech)  This caused it to be slower since PIC18 does not have the Hardware to support it.  This allows Re-entrancy to be supported. So Head to Head Microchip chose the Hi-Tech Product.
It also did not support PIC12 -16 
It was a sold enough product that many used it for many years.

嗨，我认为XC8编译器在过去的几年里与原来的HITECH PIC16和PIC18编译器相比有了很大的进步，而且几年来一直很稳定。C18比HiTeCH更成熟，但我觉得XC8已经逐渐重新认识到了这种情况。



      以下为原文

    Hi,
 
I think XC8 compiler has made significant progresses over the years compared to the original HiTech PIC16 & PIC18  compilers and is very stable since few years. 
The C18 used to be more matured than HiTech but i feel XC8 has gradually reveresed the situation
 
Regards

谢谢大家的友好讨论。让我解释一下我们的产品做了什么，也许这个小组可以提供一些关于我正在尝试做的建议。我们使用18F2685的板基本上是一个智能USB到多协议接口。（智能的意义上，它使用另一个设备使用底层协议，而不仅仅是一个协议转换器）它支持CAN（所以我需要一个CAN控制器在板上，2685个有）RS-485，RS-232，K线（可变比特率从9600到57 K），1-Wire（主从两个，哪一个？是具有挑战性的，以及在基本的串行物理层和CAN物理层上运行的几个自定义协议。在软件中，我综合了所有协议（不包括CAN，并且不包括我们使用USART的FTDI USB芯片的PIC接口）。这是一个具有特定噪声分布的非常嘈杂的环境，所以在协议波形中，我对每个比特内的多个点进行了多个轮询，并且有一些逻辑来确定线路是真正的HI还是低，通过比较多个轮询。因为我有点敲打一切，时间是至关重要的。当我最初创建设计（在2008）时，来自微芯片的免费编译器对于关键时序来说是非常不可用的。不仅函数中的时间不可预测，函数的调用也产生了不同的定时，除了代码臃肿的事实之外。（它根本不是为关键时序应用而设计的）我开始在汇编中编写所有的位敲击代码，然后试用高科技C编译器。真是天赐良机！它不仅导致超薄代码，时间是超级可预测的和可靠的。我看了一些我已经在汇编程序中写的函数，和由高科技创建的汇编程序，它们编译的代码比我写的代码要紧凑。我把微型芯片“高科技”当两个不同的微芯片编译器集成在一起时，我的意思是“杀掉”高科技。取代它的人，他们把它弄坏了。当时所有的编译器都无法使用。（我从2011年左右就没有尝试过任何东西，我们只使用了V965版本，因为在随后的版本中发生了故障）他们似乎失去了高科技的魔力。这就是我所要做的。我想主要的问题是，Microchip是否已经在编写编译器方面取得了更好的效果，特别是在这种类型的应用程序中，紧密的可重复的时序。如有任何反馈，将不胜感激。



      以下为原文

    Thanks all for the good discussion.  Let me explain what our product does so maybe the group can offer some advice relative to what I am trying to do.
 
Our board that uses the 18F2685 is basically a smart USB to multiple protocol interface.  (smart in the sense that it does functions to another device using the underlying protocol, not simply a protocol translator)  It supports CAN (so I need a CAN controller on board, which the 2685 has) RS-485, RS-232, K-line (variable bit rates from 9600 to 57K), 1-wire (both Master and Slave, which is challenging) and several custom protocols running over both the basic serial physical layer as well as over the CAN physical layer.
 
I synthesize all protocols in software, (excluding CAN, and excluding the PIC interface to the FTDI USB chip we use, which I use the USART).  It is a really noisy environment with specific noise profiles, so in the protocol waveforms I do a lot of multiple polling of the lines over several points within each bit and have some logic to determine if the line is truly hi or low with comparisons of the several polls.  Since I am bit-banging everything, timing is crucial.
 
When I originally created the design (in 2008) , the free compiler from Microchip was horribly unusable for critical timing.  Not only was timing unpredictable within a function, calls to functions yielded different timing, besides the fact that the code was bloated. (It simply was not designed for critical timing applications)  I started writing all of the bit-banging code in assembly, then tried out the Hi Tech C compiler.  It was a godsend! Not only did it result in super slim code, the timing was super predictable and reliable.  I looked at some of the functions I had already written in assembler vs the assembly created by Hi Tech, and their compiled code was more compact than what I had written.
 
What I meant by  Microchip "killing off" Hi Tech, when they integrated the Hi-Tech stuff into the two different Microchip compilers that replaced it, they broke it.  All the compilers at the time became unusable.  (I haven't tried anything they have put out since about 2011 or so, and we have only used the V9.65 version as the breaking happened in the subsequent versions)  It seemed they lost the Hi Tech mojo.
 
So that is what I am looking to do.  I guess the main question is if Microchip has gotten any better at writing compilers, especially with respect to tight repeatable timing in this type of application.  Any feedback would be most appreciated.

VIS7070高科技是一个编译器改写。（OCG）现在不好，但现在还可以。您可以将代码编译为当前XC8中的代码。你看不到太大的差别。可以使用更新的图片。PIC24将是GCC。如果时间是关键的，PIC32 MZ可能不适合你的需要。有缓存。这意味着时间是不可预测的。你需要使用计时器来确保计时。



      以下为原文

    V9.70 ish hi-tech was a compiler rewrite. (OCG) It was not good but is ok now. You can take your code a compile it in the current XC8. You should not see much difference.
By could use newer PICs. Pic24 an up will be GCC. If timing is critical a pic32mz may not suit you needs. Is has cache. That means timing is less predictable. You would need to use a timer to insure timing.

嗨，我同意以前的帖子。PIC32不适用于关键时刻。PIC24是一个更好的选择。



      以下为原文

    Hi,
I agree with previous post. PIC32 is not suitable for critical timings. PIC24 is a much better alternative in that perspective.
Regards
 

这取决于时机。由于芯片速度更快，较长时间的误差可能并不重要。程序员需要设计它。



      以下为原文

    It depends on the timing.  Since the Chip is faster, the error in longer timing may not matter.  
The Programmer would need to engineer it.

谢谢你的反馈。现在，我所有的时间都是按位字节叠加的，并且总是精确的和可重复的。有了足够快的处理器，（32个），我就可以使用计时器来创建一个参考，如果缓存妨碍了做堆栈的时间。PIC32有多个定时器，是吗？不过，我会再看看PIC24家族。



      以下为原文

    Thanks for the feedback.  Right now, all my timing is stacked per bit-banged byte, and is always accurate and repeatable.  With a fast enough processor, (which the 32 is) I could maybe use timers to create a reference along the way if the cache gets in the way of doing timings stacked.  Pic32 has mulitple timers, yes?
 
I will look at the Pic24 family again though.

是的，很多计时器。一个自由运行的MIPS核心定时器，在半个钟头运行。这也适用于短时间。



      以下为原文

    Yes Many Timers.  And a free running MIPS Core Timer that runs at half the Clock.  That is also good for short timing 

原来没有PIC24 MCU的CAN，但是有很多的DSPIC33家庭处理器，谁能评论这个家庭？似乎他们的目标是汽车控制和汽车与这个家庭，所以也许这将是一个很好的契合？



      以下为原文

    Turns out that there are no Pic24 MCU's with CAN.  
 
But there are plenty of dsPIC33 family processors with CAN, anyone care to comment on this family?  Seems they target motor control and automotive with this family, so maybe it would be a good fit?
 

关于PIC 32的定时和BITBUG：确保使用SET、CLR和IV-SFR偏移地址（RealStSt集＝BITYMASE），而不是寄存器。位＝1。前者是原子的，需要1个指令，后者不是原子的，使用几个离散的指令。原子部分对于SFR来说尤其重要，它可以受到硬件和软件（例如中断标志）和寄存器的影响，这些寄存器可以由几个预先清空的代码CON访问。文本（看似）同时进行（例如不同的优先级中断和RTOS任务）。/ Ruben



      以下为原文

    Regarding timing and bitbanging for PIC 32: Make sure you use the SET, CLR and INV sfr offset addresses (registerSET = bit_mask) instead of register.bit=1. The former is atomic and takes 1 instruction, the latter is not atomic and uses several discrete instructions.
 
The atomic part is especially important for sfrs that can be affected by both hardware and software (e.g. interrupt flags) and registers that can be accessed by several pre emptied code contexts (seemingly) at the same time (e.g. different priority interrupts and RTOS tasks).
 
/Ruben

这是非常好的信息，谢谢！



      以下为原文

   


This is excellent information, thanks!
 

至少有14个不同的PIC24 WHH一个或多个CAN模块。尝试PIC24HJ GP和PIC24EP GP和GU。大多数情况下它们与没有DSP核心的DSPIC33相同。



      以下为原文

   
There are at least 14 different PIC24 wih one or more CAN modules. Try PIC24HJ GP and PIC24EP GP and GU.
 
For the most part they're about the same as the dsPIC33 without the DSP core.


 

有CAN的PIC24 CPU。我用PIC24HJ带罐头。



      以下为原文

    There are PIC24 CPUs with CAN. I used a PIC24HJ with CAN.

啊，是的，我依靠微芯片可怕的选择指南。相当数量的他们目前生产的产品没有出现在指南中。我不知道这是否是一种微妙的方式来表明他们想要淘汰那些不包括在选择器指南中的产品？



      以下为原文

    Ah, yes, I was relying on Microchips horrid selector guide.  Quite a number of their current in-production products don't show up in the guide.  I wonder if this is a subtle way to indicate they want to phase out those products that are not included in the selector guide?