MCC只是完全浪费时间吗？

我从来没有使用过MCC，但为什么你觉得一个“交换”功能令人困惑？SPI是双向的，你不能只做一个读或写，你总是同时做这两个，因此“交换”。



      以下为原文

   
 
I've never used MCC, but why do you feel an "exchange" function is puzzling?  SPI is bidirectional and you can't do just a read or just a write; you're always doing both at the same time, hence "exchanging".

我使用MCC作为SIME“快速启动包”，为此目的并不是那么糟糕。但是我切换到优化和部分重组-“手工工作”。我不会认为它“毫无价值”，仅仅因为它不传递PUTSH（）/GETSH（），因为这些函数很容易通过调用PtC.（）来实现。GETC.（）它旨在提供一些帮助，但它不能是一些“图形应用程序生成器”。



      以下为原文

    I'm using MCC as sime "quickstart package", for which purpose it is not that bad.
But then I switch to optimizing and partly reorganizing - "manual work".
 
I would not consider it "worthless" just because it does not deliver puts() / gets(), as these functions are easily implemented by calling putc()/getc(). It is intended to deliver some help, but it cannot be some "graphical application generator".

嗨，我的经验是相反的，消息1。在旧的PLIB库中有错误、不一致和错误，并且在MCC生成的代码中，即使在那时，我已经从MCC中得到有用的东西。在我看来，在Plib中使用的宏的使用是晦涩难懂的，而且难以调试。您仍然可以从Microchip存档网页下载（遗留的）PLIB：或者从XC8 V1.33或更早的版本中检索它。预编译库可能需要编译新版本的编译器和相应的设备支持文件。或者只需拾取所需的源代码的部分，并与您的OW集成。PLIB是围绕一个头文件构建的，它定义了在不同设备中存在各种外设的变体。在PLIB维护Endo.MLA已经更新，不依赖于PLIB之后，您必须更新它，并且在某些方面与MCC对齐。MLA的最后版本在它的某些部分被丢弃之前，是MLA V2013-0615，它也可以从存档网页下载。它标示：传统的MLA MysIL



      以下为原文

    Hi,
My experience is somewhat the opposite, of message #1.
There are bugs, inconsistencies, and mistakes both in old Plib libraries, and in code generated by MCC,
Even then, I have got useful stuff out of MCC.
In my opinion, the use of macros that was practiced in Plib is obscure and difficult to debug.
 
You may still download (Legacy) Plib from Microchip Archive webpage:
Or pick it up from XC8 v1.33 or earlier.
Precompiled libraries may need to be compiled with new versions of compiler and corresponding device support files.
Or just pick up the parts of source code needed, and integrate with your own project source.
 
Plib are built around a header file with definitions of what variant of various peripherals are present in different devices. You will have to update it for new hardware released after Plib maintenance ended.
 
MLA have been updated, to not depend on Plib, and is in some ways aligned with MCC.
The last version of MLA before some parts of it was dropped, was MLA v2013-06-15, it may also be downloaded from archive webpage. It is labeled: Legacy MLA
 
   Mysil

HII同意，但OTHH我注意到这些宏生成更好的代码，内嵌函数，至少在使用参数时。当然，这是一个免费版本的XC8，可能有一个PRO许可，结果会更好。至于MCC，我的经验有限，代码生成W。这并不是那么糟糕，而且它很容易理解，尽管一些最少的文档是有用的，至少在声明旁边的注释的形式上是一个像样的函数描述。



      以下为原文

    Hi
 

I agree, but OTOH I've noticed that those macros generate better code that inlined functions, at least when parameters are used.
Of course this is for a free version of XC8, probably with a pro licence the result would be better.
 
As for MCC, by my , somewhat limited experience, the code generated was not that bad, and its quite easy to understand, althought some minimal documentation would be usefull, at least a decent function description in the form of comments alongside the declaration.
 
 
Best regards
Jorge
 

宏是调试的可怕（除非你在预处理器和编译器运行之间有某种干预手段），但是肯定能够提供比函数内联更有效的代码（给定某些前提条件同样有效）-不管某些优化级别。o用宏的方式处理。内联函数是进程。单行宏的关注较少——问题是用多行宏开始的。但即使是这些人也有权生活在某些前提条件下（主要是一致性问题）。



      以下为原文

    Macros are scary to debug (unless you have some means of intervention between the preprocessor and the compiler run) but are certainly capable to deliver code that's more efficient than function inlining (same effic8ency given some preconditions) - irrespective of some optimization level.
This has to do with the way macros resp. inline functions are processed.
Single-line macros are of lesser concern - issues start raising with multi-line macros. But even these have their right to live given some preconditions (mostly consistency issues).

嗨，查利，我很惊讶你的评论。我个人节省了很多小时，感谢MCC，因为它让PIC配置如此简单，多亏了图形菜单。此外，有很多例子和驱动程序开发的点击板，使原型更容易。单击可以在这里下载CAMLLE库的板：HTTP://www. MigCHIP.COM/MPLAB/MPLAB-CODE-CONTIORATION/CHIKIC-ITO MCCTEN，这里有许多通用的MCC库，包括一些协议栈：HTTP://www. MyCHIP.COM/MPLAB/MPLAB-CODEL配置器（在当前下载选项卡下）。这里有教程：HTTP://MyCHIPCEngurr.com /问候



      以下为原文

    Hi Charlie,
 
I'm surprised with your comments.
I personally have saved tons of hours thanks to MCC because it has made PIC configuration so simple thanks to the graphical menus.
 
Additionally, there are plenty of examples and drivers developed for click boards which make prototyping much easier.
For the click boards you can donwload the comlete library here :
http://www.microchip.com/mplab/mplab-code-configurator/click-into-mcc
 
Then, you have lots of generic MCC libraries here including some protocol stacks :
http://www.microchip.com/mplab/mplab-code-configurator  (under current download tab).
 
finally you have tutorials here : http://microchipdeveloper.com/
 
Regards
 

我发现MCC是有用的，尤其是当使用一个新的（我）PIC。我遇到了一些问题，但往往是因为我自己对MCC缺乏了解和经验。它可能会让许多头文件和源文件感到沮丧，尤其是当试图在编辑器中查看它们时，很多其他文件都是从其他项目加载的。有一个过滤器可以有选择地排除其他项目的文件。但是我已经学会了只使用边栏中的项目文件列表，然后点击我想检查的内容。有时我从MCC文件中获取相关代码，并将其插入到我的主要C和H文件中，用于小的、简单的项目。但是，创建一个包的所有文件的使用能力是很容易的。



      以下为原文

    I have found MCC useful, especially when using a new (to me) PIC. I have run into problems but often they were caused by my own lack of understanding and experience with MCC. It can be frustrating with so many header and source files, especially when trying to look at them in the editor when many others are loaded from other projects. It would be helpful to have a filter that can optionally exclude files from other projects. But I have learned to just use the list of project files in the sidebar and click on whichever I want to examine.
 
Sometimes I have taken the relevant code from the MCC files and inserted it in just my main C and H files, for small, simple projects. But the ability to create a package of all files used is easy enough.

我从来没有使用过它，但是如果你不知道模块和H/W寄存器的方式，GUI界面看起来是更好的方法。总是有文档。



      以下为原文

    I've never used it but a gui interface seems like a better method if you don't know your way around the modules and h/w registers.
 
There's always docs.

与旧的PLIB帮助文件相比，文档确实是有限的，但是在MCC生成的头文件中，它们总是试图用简短的例子来解释如何使用生成的函数。一旦使用它，它就可以真正节省您的时间。在上面的注释中，以及如何使用发送或接收数据的简短描述，因为SPI在发送/接收数据之间没有真正的差别。可以使用相同的函数来发送和接收数据。由于一个设备发送一个字节数据，所以另一个发送数据：这是SPI.H文件的简短描述：如果您与旧PIC18F外围库兼容，您仍然可以使用它们。您可以从同一个编译器下载区域单独下载它们，它们现在被称为传统的外围库或使用XC8编译器（V1.34或更早版本）的早期版本，但在使用较新的芯片时可能会遇到一些问题。



      以下为原文

    Documentation is really limited compared to the old plib help files but in the MCC generated Header files, they always try to explain some times with short examples how to use the generated functions.
Once you are used to it, it can really save your time.
Like the SPI_Exchange8bit() routine, it explained in the comments above it and a short description how to use to send or receive data because with SPI there is no really difference between send/receiving data. The same function can be used to send and receive data. As one device sends a byte of data so the other transmit data:
This is a short description from spi.h file:

/**
@Summary
Exchanges a data byte over SPI
@Description
This routine exchanges a data byte over SPI bus.
This is a blocking routine.
@Preconditions
The SPI_Initialize() routine should be called
prior to use this routine.
@Param
data - data byte to be transmitted over SPI bus
@Returns
The received byte over SPI bus
@Example

uint8_t writeData;
uint8_t readData;
uint8_t readDummy;
SPI_Initialize();
// for transmission over SPI bus
readDummy = SPI_Exchange8bit(writeData);
// for reception over SPI bus
readData = SPI_Exchange8bit(DUMMY_DATA);

*/
uint8_t SPI_Exchange8bit(uint8_t data);

 
If you are confortable with the old PIC18F peripheral libraries, you can still use them. You can download them separately from the same compiler downloads area, they are now called Legacy Peripheral Libraries or use an earlier version of XC8 compiler (v1.34 or earlier) but you might experience some problems when using newer chips.

我有一个硬限制运行MCC（仍然运行Win XP在我的主机上），但使用-在那里- MCC配置文件中提供的MPLABXPress项目。N.B:经常不止一种方式（ab）使用一些工具。



      以下为原文

    I have a hard limitation running MCC (still running Win XP on my main machine), but use - where available - MCC configuration files provided in the MPLABXpress projects.
N.B.: there's often more than a single way to (ab)use some tool.

HIIT看起来像上次测试时（MCC版本）所改进的东西。这正是我在前一篇文章中提到的。虽然它有一个细节可以解释为什么我看到，在论坛中，一个代码集是SPIXIMALIALIZE（）被调用在一个传输循环内，这是一次。对于每一个交换，OTHH，我会重写传输实例，或者至少添加另一个可能的C，如果我们不需要它，我们总是忽略一个函数的返回值。原来的例子只在不太常用的全双工方案中是有意义的，谢谢您的更新。锗



      以下为原文

    Hi
 
It looks like things improved since the last time (MCC version) I tested.
This was exactly wait I was refering in my previous post.
Althought it has a detail that might explain why I saw, somwhere in the forums, a code snipset were SPI_Initialize() was called inside a transmition loop, this is once for each exchange.
 
OTOH, I would rewrite the transmition example, or at least added another possibility
// for transmission over SPI bus
SPI_Exchange8bit(writeData);
In C we can allways ignore the return value of a function if we don't need it.
The original example only makes sense in the less commom full duplex scenario, 
 
Thank you for the update.
 
 
Best regards
Jorge
 
 

谢谢大家的有趣想法。在我的情况下，我有一个现有的项目，我需要端口到一个新的处理器。发生的事是我需要有一个i2S总线升级的音频芯片。因为我没有任何驱动程序或软件的I2S，我希望MCC可能有一些东西。嗯，它不是。你可以通过它设置寄存器，但是没有实际使用它的帮助。交换数据的概念对我来说并不陌生，但实际上有效地实现它是一项不平凡的尝试。然后，我发现我所有的I2C和UART例程现在都被破解了！我设法把旧的SPI例程固定在新的芯片上，但是其余的仍然是非常坏的。当然，我不能最终编译我的代码，它不会加载到我的板上进行调试。它说它加载，但调试控制台说，负载失败。当然，微芯片技术支持不再提供电话支持…



      以下为原文

    Thank you all for interesting ideas.  In my case, I have an existing project that I needed to port to a new processor.  What happened was I needed to have an I2S bus for an upgraded audio chip.
 
Since I didn't have any drivers or software for I2S, I hoped that MCC might have something.  Well, it doesn't.  You can set up the register through it, but no help in actually USING it.  The concept of exchanging data was not foreign to me, but actually implementing it efficiently is a non-trivial exercize!
 
Then, I found that all my I2C and UART routines were now broken!  I managed to fix my old SPI routines on the new chip, but all the rest are still pretty much broken.
 
And of course, not that I can finally COMPILE my code successfully, it won't load onto my board for debug.  It says it loads, but the debugging console says the load failed.  And of course, Microchip tech support no longer provides telephone support...

我发现在打开一个支持的情况下，我收到一个案件号码，通常在一天左右的情况下，一个电话号码和电话号码的技术支持代码。



      以下为原文

   
I have found after opening a support case I receive a case number and usually within a day or so a case number and a phone number access code for technical support.

MCC是一个很好的“想法”，但仍然充满bug，奇怪的行为，例如，在项目之间切换、关闭、保存时，有时我更喜欢关闭MPLABX并再次重启它，并且非常非常非常缓慢。我希望他们能改进它。



      以下为原文

    MCC is a very good "idea" but still full of bugs, with strange behaviors, for example when changing between projects, closing, saving; sometimes I prefer shutdown MPLABX and restar it again; and very, very, very slow. I hope they can improve it.

你没有提到你使用MCC的哪一个处理器家族。想确定我们是在谈论同一头大象。我对微芯片PIC来说是比较新的，并且使用MCC给我快速启动了PIC18，一个8位处理器。我发现MCC比较完整，非常喜欢它如何自动地处理频率和时间设置。自动处理配置冲突对芯片上新的人也有帮助。我想我只发现了一个bug，花费了我一段时间（PIO有一个模拟设置，但是在PIN管理器中缺少复选框）。在MCC在PIC18上成功之后，我认为移到PIC24会很容易。没有机会。PIC24的MCC与PIC18的MCC相比是非常不完整的。所有省去了查找外围设备所有位控制的宏都不见了。不一致的编码风格。很多只是平原失踪的功能。我已经开始为头文件编写包装器来添加丢失的位设置宏，这些宏设置在PIC18中用于MCC。在生成的代码和UI中都有更多的bug。我必须不断检查DMA配置，因为UI总是忘记了我设置的设置。所以我认为你需要记住MCC不是所有处理器的相同产品。



      以下为原文

    You didn't mention which processor family you are using MCC for.  Want to make sure we are talking about the same elephant.
 
I'm relatively new to Microchip PICs and used MCC to give me a quick start on a PIC18, an 8 bit processor.  I found MCC to be relatively complete and really liked how it automatically took care of frequency and time settings.  Automatically taking care of configuration conflicts was also a help to someone new to the chip.  I think I found only one bug that cost me a some time (PIO had an analog setting but the checkbox was missing in the pin manager).
 
After the success with MCC on the PIC18, I thought the move to a PIC24 would be easy. Not a chance. MCC for the PIC24 is very incomplete compared to MCC for the PIC18. All the macros that saved me from looking up all the bit controls for the peripherals were missing. Inconsistent coding styles. A lot of just plain missing functions. I've taken to writing wrappers for the header files to add the missing bit setting macros that I had grown used to in MCC for the PIC18. And a lot more bugs in both the generated code and the UI.  I have to constantly check the DMA configuration because the UI keeps forgetting the settings I put in.
 
So I think you need to keep in mind that MCC is not the same product for all processors.

HI RDSJLIFE，我想知道PIC18和PIC24之间的一些差异，不是因为MCC，而是因为设备支持文件LT；xc.h & gt的不同。这些不是MCC的一部分，它们是与编译器一起维护和安装的。对于PIC18和8位设备，在控制寄存器中有大量的宏来处理单个位，并且比特被记录在数据表中，例如TMR3ON，允许写入像TMR3ON＝1；在PIC24和其他16位PIC设备中，可能有5个或更多的定时器，它们非常相似，并且可以被记录。对于TXCON寄存器与吨位的描述一起，对于一些实例，如果一些更复杂的外围设备，更难有唯一的单位名称。然后最好使用寄存器和位名称，像REGISTERbits.BITNAMEIt一样，大多数建议使用Stutt表达式来解决这些设备中的寄存器，例如：对于某些寄存器，可能有单个位宏，主要用于一类的第一个外围设备。对于PIC18和其他8位设备，也有不同之处。也就是说，对于不同的PIC单片机家族，MCC之间存在差异，这也是我的印象，一些更复杂的外围设备不如MCC所支持的那样好。迈西尔



      以下为原文

    Hi RDS_Cliff,
 
I wonder if some of the differences experienced between PIC18 and PIC24, isn't due to MCC at all,
but instead is due to differences in the device support files  .

These are not part of MCC, they are maintained and installed together with the compiler.  For PIC18 and 8 bit devices, there are a lot of macros to address single bits in control registers, and bits are documented in datasheet like TMR3ON, allowing to write like TMR3ON = 1;
 
In PIC24 and other 16 bit PIC devices, there may be 5 or more timers, that are very similar, and may be documented together, with description of  TxCON register with TON bit. 
For these devices with several instances if some more complicated peripherals, it is more difficult to have single bit names that are unique. It is then better to use Register and Bit name together, like REGISTERbits.BITNAME
It is mostly recommended to use struct expressions to address registers in these devices, like this:
   T3CONbits.TON = 1;  
There may be single bit macros defined for some registers, mostly for the first peripheral of a kind.
 
These struct definitions are also available for PIC18 and other 8 bit devices.
 
That said, there are differences between MCC for different PIC microcontroller families,
it is also my impression that some of the more complicated peripherals are not as well supported by MCC as they could be.
 
   Mysil

吉姆，只是因为你有一个电话接入号码（什么是与3小时延迟得到一个！）这并不意味着你将达到一个技术。我有四个开放的案例，如果我不是一个设计伙伴，可以结束他们的运行，我将永远不会接到一个电话。我开了一个30天的箱子，但是如果你打进来的话，从来没有人能找到。



      以下为原文

    Jim,
Just because you have a telephone access number (What is with the 3 hour delay to get one!) doesn't mean you will reach a tech.  I have four open cases, and if I wasn't a Design Partner and could do an end run on them, I would never receive a call.  I had one case open for 30 days, but if you called in, there was never anyone available.

查利，这不是我的经验，“没有终点跑”，但那时我最多只有一个时区。



      以下为原文

    Charlie,
That has not been my experience, "without an end run".
But then I am only at most one time zone away.

在我的经验中，MCC几乎完全是浪费时间。对于我来说，MCC最好的例子提供了仔细研究、逆向工程和固定的示例代码，提供了寄存器设置和低效API来操作片上硬件功能块。似乎我的建设项目的直觉相反，但也许我与现代编码实践脱节。



      以下为原文

    In my experience the MCC is almost a complete waste of time.
 
For me the MCC at its best provides example code that on careful study, reverse engineering and fixing provides the register settings and inefficient APIs to manipulate the on chip hardware function block.
 
The "application" methods MCC uses seem counter intuitive to my way of constructing a project, but perhaps I'm out of touch with modern coding practice.