diagrams过渡状态流程图，数据流diagrams微型芯片的和谐

他们是靠字数来支付的，而不是靠质量来支付的。Nick
                    
                    
               
                                                                                      以下为原文

                                                                            They get paid by word count, not by quality.
 
 
Nick

嗨，Nick……但是Pic32 {和下行控制器——DSPIC、PIC24…}数据表、参考手册文档与微芯片和谐性相比，非常好？（虽然图和表提供的PIC数据表是低/少的（打算？）德克萨斯仪器为他们的MSP430控制器提供了非常好的数学表和图表。P.S.：微芯片和声代码的质量是好的-看起来像一个生产代码-虽然他们没有提供重要的文件…
                    
                    
               
                                                                                      以下为原文

                                                                            Hi Nick ...
But PIC32 {and Down Stream Controllers -dsPIC, PIC24...} Datasheet,Reference Manuals Documentations are very good in Contrast to Microchip Harmony ? (though the Graphs and Tables provide in PIC Datasheets are Low/Less(intended?), Texas Instruments provides Very Good Mathematical Tables and Graphs for their MSP430 Controllers)
 
P.S.: The Quality of the Microchip Harmony Code is Good - Looks Like a Production Code - Though They did not provide the Crucial Documents ...

“他们是靠字数来支付的，而不是按质量来支付的。”事实上，我们得到的报酬是开发我们的客户能够迅速进入市场的功能。从客户到客户需要多少文档，Microchip欢迎我们对文档的建设性批评。如果你可以指出错误或需要改进的东西，我会提交一个bug报告，我们将把它修复为资源允许。IHOO，一些和谐文档的部分非常好。例如，查看图形文档或快速入门指南。其他部分需要改进，尤其是从.h文件自动生成的东西。文档中的大部分“膨胀”来自于这一点。
                    
                    
               
                                                                                      以下为原文

                                                                            "They get paid by word count, not by quality." - Actually we get paid to develop functionality that our customers can use to get to market quickly.  How much documentation is needed for that varies from customer to customer.
 
Microchip welcomes constructive criticism of our documentation.  If you can point out things that are wrong or that need improvement I'll file a bug report and we will fix it as resources allow.
 
IMHO,  some parts of Harmony documentation are very good.  For example, look at the graphics documentation or the quick start guides.  Other parts need improvement, especially the stuff auto generated from .h files.  Most of the "bloat" in the documentation comes from that.

“他们肯定是在项目的设计阶段被画出来的。”不可能。和声本来是一组代码生成器结合在一起的以前的注释。（代码生成器现在看来是个大问题），基本的概念并不总是由Harmony Team所遵循。此外，概念随着时间的推移而发展。团队成员显然拥有不同数量的技能。文档是多年来的一个问题。与代码本身的某些部分一样，似乎没有任何驱动器可以返回并修复旧的问题。（我猜一个新的图形库的乐趣，或者把它移植到ARM上更受欢迎）。这是我个人的观点，作为一个外部的观察者，并且可能不符合现实。Mann先生会更加了解公司的实际情况。注：1。和谐是有效的。陡峭的学习曲线会抵消“快速设计”方面的影响，你会看到。2。我觉得通过使用RTOS可以帮助很多应用程序。3。您不需要使用和谐外围驱动程序（UART，I2C，SPI，ECT），那么往往是复杂的和难以使用的。（在我看来，基于V1.xx）PIC32 MX AppNOTES和一些PIC24是可用的，外设是16位。4。如果你对计时器服务有问题，很可能不是你。5。问问题
                    
                    
               
                                                                                      以下为原文

                                                                            "surely they must have been drawn during the Design Phase of the project."
No unlikely.  Harmony was originally a collection of Previous Appnotes brought together with a code generator.   (code generator appear to be the big thing now) The Stated basics concepts were not always followed by the Harmony Team.  Additionally, The concepts evolved over time. The Team member apparently had a varying amount of Skill. 
the Documentation has been an issue going back years. Like parts of the code itself, there does not appear to be any drive to go back and fix old problems.  ( My Guess the Fun a new Graphic library or of porting it to ARM was more favored).
This is MY personal opinion as an outside viewer, and may not match reality.
Mr Mann would be more aware of corporate realities.
 
Notes:
1. Harmony does Work. Does the steep learning curve offset the " Rapid Design" aspects, You will see.
2. I feel many apps would be aided by using a RTOS.
3. You do not need to use the Harmony Peripheral drivers (UART,I2C,SPI,ect)  Then tend to be complex and hard to use. (In my opinion, and based on V1.XX) The PIC32MX appnotes and some PIC24 are usable the Peripherals are 16 bit.
4. If you are having Issues with the Timer Service, it is probably, not you.
5. Ask Questions

我同意人们指出的文件问题。我通常使用“HelpHythOrth.Chm”和关键字搜索来确定哪一个卷可能有我需要的帮助。我认为文档更像是一个参考，而不是一个如何做的事情。有一个非常陡峭的学习曲线和谐。也有太多的bug。像PMP不为PIC32 MZ和其他小东西的图形堆栈工作…除非你使用微芯片演示板和样例代码作为项目的基础。我实际上是在学习和谐，我得出的结论是，现在在客户项目中使用它太头痛了。也许当V3.00出来的时候我会用它（不知道什么时候会发生）。我将继续“玩”它现在。我感谢微芯片技术支持的帮助和家伙在论坛上。这并不都是坏事……我们似乎是“早期采用者”。
                    
                    
               
                                                                                      以下为原文

                                                                            I agree with the documentation issues people are pointing out. I usually use "help_harmony.chm" and keyword search to pinpoint which volume may have the help I need. I think of the documentation more like a reference than a how to do things. There is a very steep learning curve for harmony IMHO. There are also too many bugs. Like PMP not working for the graphics stack for PIC32MZ and other little things ... unless you 're using a Microchip demo board and sample code as the base for your project. I'm actually learning harmony and I come to the conclusion that it is too much of a headache to use in a customer project right now. Maybe I'll use it when v3.00 is out (don't know when that will happen). I'll keep "playing" with it for now.
 
I do thank Microchip tech support for the help and the guys here in the forums. It is not all bad ...we seem to be "early adopters".  
 

一些人从图像/视觉/图表中学习，有些人从阅读课文中学习，有些人已经学会了同时使用这两种语言。作为一名工程师，最好是充分利用所提供的内容。
                    
                    
               
                                                                                      以下为原文

                                                                            Some learn from images/visual/diagrams, some from reading text, some have learned to use both.
As an engineer it might be best to make the most of that which is provided.
 

确切地。无用的描述是C.P和P从相似的描述，甚至不改变函数名称。所以没有人负责文件？没有人浏览生成的文本吗？这说明了一切！给我看一下MHC中所有TCP/IP参数的描述。不存在。快速启动指南可能是好的。我认为这是一种让人们开始用图片进行开发的方法。后来，他们会发现，和谐的文档大多是臃肿的。技术数据表（硬件）是好的，但对和谐没有什么帮助。Nick
                    
                    
               
                                                                                      以下为原文

                                                                           
 
Exactly. Useless descriptions that are c&p from similar descriptions whereby not even changing the function names.

So there is no one responsible for documentation? No one looking over the text generated? That explains it all!
 
Just show me the description of all the TCP/IP parameters in MHC. Doesn't exist.
 
The quick start guides may be OK. I consider this a way to catch people to start developing with PICs. Later, they will discover that the documentation for Harmony is mostly bloat.
 
The technical data sheets (hardware) are OK, but of little help for Harmony.
 
Nick