什么是PIC32MX175？

也许你指的是PIC32 MX174 OrPIC32 MX775？应该有NopIC32 MX175。



      以下为原文

    Perhaps you mean PIC32MX174 or PIC32MX775?
There should be no PIC32MX175.

亲爱的SoBoTeCo，谢谢你的评论。不，我的意思是175——在XC32／V1.44／PIC32-LIbs/PRC和类似的目录中有完整的文件集。因此我的问题！



      以下为原文

    Dear Sobottech,
Thank you for your comment.  No, I do mean 175 - there are full sets of files in the xc32/v1.44/pic32-libs/proc and similar directories in the distribution.  Hence my question!
 

事实上，搜索有点棘手，请参阅第2HTTP：//WW1. Microchip .com /…EVICEDOC/6000 1404A.PDF



      以下为原文

    Indeed the search is a bit tricky
see page 2
http://ww1.microchip.com/...eviceDoc/60001404A.pdf

您应该能够下载并安装可用最新编译器找到的修补文件。那应该做你想做的事。



      以下为原文

    You should be able to download and install the patch file that can be found with the latest compiler. That should do what you want.

谢谢-我应该看到这个。但是，我不确定这个设备是否可用。它不是在微芯片网站或互联网上引用的！所以这是174版本的一个VBAT版本。我有点恼火，因为我想我知道这个设备，但前一段时间。我被互联网搜索中的参考信息弄糊涂了。你知道有什么关于如何把174添加到更老的XC32编译器上的建议吗？还是我在这里鞭打一个死马？VJM



      以下为原文

    Thank you - I should have spotted this.
However, I am not sure if the device is available...  It is not referred to on the Microchip site, or the Internet! So it is a VBat version of the 174.  I am a little annoyed, as I think I knew of this device, but some time ago.  I was (am) confused by the lack of reference in Internet searches.
Are you aware of any advice on how to add the 174 to older XC32 compilers, or am I flogging a dead horse here?
VJM

谢谢-我还没有修补我的编译器一段时间（谨慎…）。我会研究这个……VJM



      以下为原文

    Thank you - I have not patched my compiler for some time (cautious...).  I will look into this...
VJM

谢谢-更新发现。我想知道是否是故意更新旧版本以最小化支持负载，但我接受这些文件将是相同的，无论编译器…问题解决了！



      以下为原文

    Thank you - updates found.  I wondered if it was deliberate policy not to update older versions to minimise support load, but I accept that these files will be identical regardless of compiler...  Problem solved!

HTTP//WW1.MICCHIP.COM/DeLoSt/En/DeVICECD/OC6000 1404A.PDFSEE Page 2VBAT，应该在2018年6月准备好样品。



      以下为原文

    http://ww1.microchip.com/downloads/en/DeviceDoc/60001404A.pdf
see page 2
has Vbat and there should be samples ready in June 2018

事实上，MX175是174设备的VBATT版本。我们现在有硅验证，并且目标是在六月的时间框架内。这些基本上是PIC32 MX1XX系列设备，它们运行在更高的时钟频率（72MHz）上，但在不同的过程中，大约是现有MX设备的一半功率。除了几个寄存器之外，所有的代码都是兼容现有MX设计的100%代码。



      以下为原文

    Hi Folks
 
Yes - indeed - the MX175 is a VBATT version of the 174 device. We have silicon in validation right now and are aiming for availability in June timeframe. 
These are essentially PIC32MX1xx series devices that run at a higher clock frequency (72Mhz) but are on a different process so are about half the power of existing MX devices. Aside from a couple of registers, everything is 100% code compatible to existing MX designs. 

-亲爱的诺瓦克先生，谢谢你的评论-我将向你介绍另一个线程，我正在寻找支持174/175个家庭在旧的PLIB，因为我发现和睦到很大的变化，并使用较早的（和成功的）框架。这个XLP家族是有吸引力的，特别是当它运行在更高的频率上，并且提供一个缓存。你可能有点乐观地指出，差异只是一对寄存器，我不得不分析它，并且我已经在另一个线程中报告了我的观点。有很大的差异，图书馆需要一些修改，但我同意，这并不显得太糟糕，因为我通过它。我可以提供更多的细节，如果这有帮助，但我相信你完全知道这个位置。这将是非常，非常好，如果Microchip是更新这些老图书馆，以支持现有的用户，或使和谐代码更容易获得（我已经放弃试图找到相关的代码I）n这一实施-但这可能是我有限的理解）。如果它是简单的，正如你所建议的，那么它就不应该是一个强加。我对向后兼容性有点担心，因为寄存器中的一些位的功能已经改变了，但是在这个阶段我还没有详细地查看。谢谢你的澄清，以及你的兴趣。祝你好运。VJM



      以下为原文

    -
Dear Mr Novak,
Thank you for your comment - I would refer you to another thread where I am looking at supporting the 174/175 family on older plibs, as I find Harmony to much of a change and use the earlier (and successful) framework.  this XLP family is attractive, especially as it operates at higher frequencies, and offers a cache.
You are perhaps being a little optimistic in stating that the difference is only a couple of registers; I have had to analyse this, and I have reported my views in the other thread.  There are significant differences, and the libraries will require some modification, but I agree that this does not appear too bad as I work through it.  I can provide more detail if this helps, but I am sure that you are fully aware of the position.
It would be very, very nice if Microchip were to update these older libraries in support of existing users, or make Harmony code more readily available (I have given up trying to find the relevant code in this implementation - but that might be my limited understanding).  If it is simple, as you suggest, then it should not be too much of an imposition.
I am slightly concerned about backwards compatibility, as the function of some bits in registers has changed, but I have not looked in detail at this stage.
Thank you for the clarification, and your interest.
Best wishes,
VJM

有趣的是，“你可能有一点乐观地指出，差别仅仅是两个寄存器，我必须分析它，并且我已经在另一个线程中报告了我的观点。”你知道用户BNOKAKE不是用户而是管理员吗？所以我猜，他有背景信息，知道他在说什么吗？微笑：如果有人能说出关于未来产品的事情……



      以下为原文

   

Hm. Funny.
"You are perhaps being a little optimistic in stating that the difference is only a couple of registers; I have had to analyse this, and I have reported my views in the other thread."
You know the user BNowak is no user but Administrator? So I guess, he got background information and knows what he is talking about? Smile:  If someone can tell something about future products ...

谢谢你的评论。我想知道我是否恰当地表达了我的反应……我欣赏诺瓦克先生的立场，只是指出了一个分析寄存器配置的结果，我昨天感兴趣了（我有一点空闲时间）。我还指出了在一个单独的线程中的数据表中的PMP寄存器信息的一些不一致性，（这确实影响向后兼容性），一些需要管理的新功能（深度睡眠，看门狗，附加时钟源），以及全新的块，例如OSCIL。LaTor需要改变（但在MPLAB的PrimaMax窗口中得到了很好的管理）。我确信你已经意识到了这些，所以请原谅我指出了明显的地方，我在有更广泛的兴趣的情况下做出反应。我只是担心这些差异可能比诺瓦克先生暗示的要多一些。多谢，VJM。



      以下为原文

    Thank you for your comment.  I wondered if I had phrased my response appropriately...
I had appreciated Mr Novak's position, and was just pointing out the results of an analysis of the register configuration, which I undertook out of interest yesterday (I had a bit of spare time).  I have also pointed out some inconsistencies in the PMP register information in the data sheets in a separate thread,  (which do affect backwards compatibility), some new functionality (deep sleep, watchdog, additional clock sources) that needs to be managed, and totally new blocks such as the oscillator which require change (but are well managed by the pragma window in MPLAB).
I am sure you are aware of these, so please excuse my pointing out the obvious; I respond in case there is wider interest.  I was just concerned that the differences are, perhaps, a little more substantial than Mr. Novak implied.
Many thanks,
VJM