装配中的PIC32MZ Bootloader应该用哪一个环境来编写汇编代码

也许你可以看看从和谐C引导加载程序的程序集列表输出。



      以下为原文

    Maybe you could have a look at the assembly listing output from the Harmony c bootloader.

非常感谢你的回复，吉姆。我不太清楚这是什么，或者我会在哪里找到“汇编列表输出”。它是什么？是从C文件中生成的汇编文件吗？在文件夹里我得到了什么？我在XC32环境中打开和编辑它吗？



      以下为原文

    Thank you so much for your response Jim. I dont quite know what that is though or where I will find it ''assembly listing output". What is it? Is it the assembly file produced from the c files? Where in my folders do I get it? Do I open and edit it in the XC32 environment?

如果您阅读了XC32和MPLAB X的详细手册，答案就在里面。



      以下为原文

    If you Read The Fine Manual for xc32 and Mplab X the answers are within.
From Mplab X IDE
Window, Debugging, Output, Disassembly ...

酷吉姆，但它只是一个狗的早餐，集会，评论和恐惧…这里有没有人为PIC32写了一个完整的汇编语言程序？



      以下为原文

    Cool Jim, but its just a dog's breakfast that , assembly, comments and funk... Is there anyone here who's wrote a complete assembly language program for a pic32?

只有少数几个。您可能想搜索PIC32 ASM线程。



      以下为原文

    There are only a few. You may want to search for PIC32 ASM threads.

谢谢你，NKurzman。我想在程序集中构建Bootloader，因为HootBootloader太难理解了，我很舒服地发布了一个代码，我对代码的理解很少。微芯片为什么要看垃圾组件？当然，我们用C编写大多数程序，但是ASM有它的位置，不是吗？让人们在集合体中发展，如果他们想要的话！



      以下为原文

    Thank you NKurzman. I want to build a bootloader in assembly because the harmony bootloader is just too much to understand, I am comfortable releasing a product with code I have little understanding of. Why is microchip looking to trash assembly? Sure we write most programs in C, but ASM has its place doesnt it? Let people develop in assembly if they want! 

也许你需要一种不同的方法。阅读BooLoad并了解它们是做什么的。与组成引导程序的各种组件一起玩，比如通过UART发送或接收命令，或者EEPROM（I2C/SPI）等，用于程序数据的外部存储，读取和写入目标设备的程序存储器等。然后，也许你可以开始理解如何将它们组合起来，形成一个引导程序。所有这些事情在汇编中都是可以实现的，因为最终一个更高级的语言，比如C，在被翻译成机器代码之前，将被翻译成汇编。当缺少一些高级语言提供的便利时，使用汇编可能更难实现。



      以下为原文

    Perhaps you need a different approach. Read about bootloaders and understand what it is that they do. Play around with the various components that make up a bootloader, like sending/receiving commands via UART, perhaps EEPROM (I2C/SPI) etc for external storage of program data, reading and writing the program memory of your target device, etc.
 
Once you understand how to make all of those things work independently of each other, then perhaps you can start to understand how to put them together to form a bootloader.
 
All of these things are achieveable in assembly, because ultimately a higher level language like C will be translated to assembly before being translated to machine code. It may just be more difficult to implement using assembly when you are missing some conveniences that higher level languages offer.

酷Tims，非常感谢，我试过了，我真的需要开发一个自己的引导程序。



      以下为原文

    Cool tims, great thanks, Ive tried that and I really see the need to develop a bootloader of my own

我不会责怪你被纯粹的和谐所驱使。但是，您想写什么类型的引导加载程序？你有什么样的装配经验？你有大量的事情要处理，你不需要在32位处理器上，比如说L1缓存。从汇编中从头开始写USB主机驱动程序甚至都不算微不足道，我不想在你厌倦了它之后继续维护它。如果你真的无法忍受和睦，为什么不写呢？E或适应MZ的例行程序，它们比和谐更美味。问题的一部分是，不会有一个真正好的生态系统来支持你使用所有的原始装配。很抱歉，这样写起来，但是编写和维护程序集似乎是累人的，你将是唯一能在合理的时间内完成这段代码的人。http://BrGry.com／EMB……



      以下为原文

    I don't blame you for being put off by the sheer bulk of harmony.  However, what type of bootloader are you trying to write?  What type of assembly experience do you have?  You have a ton of stuff to deal with that you don't have to on sub 32 bit processors, take L1 cache for example.
 
Writing a u*** host driver from scratch in assembly isn't even moderately trivial, and I don't want to maintain it after you get tired of it.
 
If you really can't stand Harmony, why not write or adapt MAL routines to the MZ, they are more palatable than harmony.  Part of the problem is that there isn't going to be a real good ecosystem to support you in using all out raw assembly.  Sorry to be so dampening, but writing and maintaining assembly seems tiring, and you'll be the only one that can do so to this piece of code in a reasonable amount of time.
 
https://barrgroup.com/Emb...sembly-vs-C-Comparison

我喜欢编写汇编，作为一个挑战。本质上，自从我开始使用MPLAB X作为最近的例子在C.编写我的代码以来，我写了一个库来读写I2C EEPROM。我最初是为PIC18编写的，但后来开始用PIC24进行项目。一些IFDEF后来添加了PIC24的细节，至少90%的原始代码是未被触摸的。如果我在汇编中已经写好了，我可能会从头开始重新执行整个库来满足。两个汇编语言变体之间的差异。也许你把这个Bootloader想象成一个PIC32上的当前项目，但是也许稍后你会想在另一个PIC家族中使用它，或者可能是另一个供应商的部分。你真的想要Doub吗？LE /三/四/更多的努力，每次你改变如何引导引导程序工作，或者可能只是IFF一些处理器的细节，在现有的代码库，如果你改变平台？



      以下为原文

    I like writing assembly, as a challenge.
 
Essentially ever since I started using MPLAB X Ive been writing my code in C. As a recent example, I wrote a library to read/write I2C EEPROMs. I originally wrote it for PIC18, but then started doing projects with PIC24's. A few ifdef's later to add PIC24 specifics and at least 90% of the original code was untouched.
 
If I had written that in assembly, I would likely be re-implementing the entire library over again from scratch to cater for the differences between the two assembly language variants.
 
Maybe you picture this bootloader you want to write as being for a current project on a PIC32, but maybe later down the line you will want to use it on another PIC family, or perhaps another vendors parts entirely.

Do you really want to double/triple/quadruple/more the effort each time you make a change to how the bootloader works, or perhaps just ifdef a few processor specifics in to an existing codebase if you change platforms?

我认为这种重新可用性的想法被严重夸大了。你在嵌入式项目中所做的大部分工作都是为了使不同的部分协同工作。因此，当您将某个平台从一个平台移植到另一个平台（甚至在同一种CPU上从一个项目到另一个项目）时，您可能需要调整它以满足您的需求。例如，您可能需要使用DMA，您可能需要考虑可以访问同一I2C线的其他任务。因此，通常是有益的，而不是将一个不合适的代码移植到其他项目中。当然，您可以创建一个覆盖一个代码的代码。可能的情况，但你的代码将过于复杂和难以使用（例如和谐）。在这种情况下，最好放弃通用代码，写一些适合你的特定情况的小东西。



      以下为原文

   


I think this re-usability idea is seriously overrated.
 
Most of the work you do in an embedded project is related to making different parts working together. Therefore, when you port something from one platform to another (even from one project to another on the same kind of CPU), you may need to tweak it to meet your needs. For example, you may need to use DMA, you may need to take into account other tasks which may access the same I2C line etc. Therefore, it is often beneficial to write the whole thing in scratch rather than porting an ill-fitting code from other project.
 
Of course, you can create a code which covers all the possible situations, but then your code will be overly complex and hard to use (e.g. Harmony). In this situation, it might be better to abandon the universal code and write something small which fits your particular situation perfectly.

我认为这将取决于情况。如果需要足够的改变，使得现有的代码开始变得更加复杂，那么当然，也许从头开始是更好的事情。但是在我的项目中，迎合寄存器名称的差异和ER中的一些增强。RoR检测等简单到足以覆盖IFDES。如果你可以用一个可能覆盖两个不同平台的Bootloader来实现同样的事情，我不明白为什么你不会做同样的事情。



      以下为原文

    I think it would depend on the situation.
 
If enough changes are needed such that the existing code starts to become more complicated, then sure, maybe starting from scratch is the better thing to do.
 
But in the case of my project, catering for differences in register names and some enhancements in error detection etc were simple enough to cover with ifdefs.
 
If you can achieve the same thing with a bootloader that might  cover a couple of different platforms, I dont see why you wouldnt do the same thing?

因为PIC32有足够大的USB引导块，或者UXP，如果是免费模式的XC32。ASM是个人的选择。在C实现中不需要C.和声。



      以下为原文

    Since the PIC32 has a big enough boot block for USB, or UDP with XC32 if Free mode.  ASM is a personal choice.  It would Fit in C.  Harmony is Not required for a C implementation.
 

当我想重复使用的东西，我只是复制和粘贴（或移动整个文件），然后根据需要做更正。但是，当我编写代码时，我不担心，如果我可以在将来的项目中重新使用它。我担心它如何符合我目前的计划。因此，如果我觉得它在汇编程序中做得更好，我会在汇编程序中完成。如果我觉得C是更好的，我会在C.这样做，这给了我自由，最后，加快了速度。当然，有一些独立于平台的代码，它应该到处工作。这个ONEI写一次，然后再作为一个整体使用，但它肯定不会依赖于硬件。这种方法在PC上效果最好，我可以在很多不同的项目中重新编写一些东西。IMHO，Bootloader当然不属于这一类。



      以下为原文

   


When I want to re-use something, I just copy and paste (or move the whole file) then do the corrections as needed. But when I write code, I don't worry much if I can re-use it in a future project or not. I worry how it fits in my current project. Therefore, if I feel it's better done in Assembler, I'll do it in Assembler. If I feel C is better, I'll do it in C. This give me freedom, and, in the end, speeds things up.
 
Of course, there are some platform-independent code which is supposed to work everywhere. This one I write once and then re-use as a whole, but it certainly won't depend on the hardware. This approach works best on PC where I can write something which gets re-used in dozens of different projects. IMHO, bootloader certainly doesn't fall into this category.