统一主机应用程序数据传输在UART捕获了数据时没有得到编译器创建的类似的HEX文件

由于您已经读取了Bootloader生成器的用户指南，所以您知道主机通过协议与PIC通信。既然你选择使用“擦除重置向量”的方法来检测引导加载的需要，那么你知道最后一个Flash写入是重置向量，它是编译器十六进制输出中的第一个。你确实读过了用户指南，对吧？



      以下为原文

    Since you have read the Bootloader Generator User's Guide you know the host communicates with the PIC through a protocol. And since you selected to use the "erase reset vector) method of detecting the need for bootloading you know that the last flash write is to the reset vector, which comes first in the compiler hex output.
 
You did read the user's guide, right?

在开发引导加载程序时，是的，我确实阅读了指南，并根据我的项目需要进行了详细的挖掘。但我仍然没有明白你的意思（也许我没有经验了解这一点）。我已经看过了发送和接收两个微控制器都得到了十六进制仍然我不知道如何获得类似的文件，如一个由XC8编译器。如果我寻找数据，那么我找不到所有的数据，但是很多数据字节（我的意思是排除前8个CHARCHER和校验和）在HEX文件中通过实词捕获但未排序，而我没有得到它们在十六进制中排序的方式，即通过实词捕获的方法。



      以下为原文

    While developing the boot-loader, Yes i did read the Guide and also digged into details as far as it was needed for my project. But still i did not get your point (Probably i am not that experienced to understand the point). I have read the Transmit and Receive both of the micro controller have got both hex still i don't get that how to get a similar file like the one made by XC8 compiler. If i look for data then i don't find all of it but many of the data Bytes(with lines i mean Excluding the first 8 charecters and checksum) are presented in the Hex file captured via Real Term but unsorted and i am not getting the way they are sorted in this Hex i.e. the one captured via Real Term.

也许正规化会有帮助？



      以下为原文

    Maybe Normalize would help ?
   Attached Image(s)

您的原始帖子说，您希望引导装载器输出与HEX文件相同。如果你理解了两者，你就会明白为什么不能这样做。你了解HEX文件格式吗？每行16字节，字节寻址。您了解引导装载协议吗？它每写一个命令发送一行。从HEX文件看，你使用的是PIC16，每行有32个单词。寻址是寻址。对于PIC16，一个字是14位，它需要两个字节来表示。因此，每个写入命令必须是64字节。因为一个字需要两个字节，引导加载字地址是十六进制文件字节地址的一半。最后的十六进制数据（在重新定位的复位向量）最后写入。否则，数据的顺序是相同的。



      以下为原文

    Your original post said you wanted the bootloader output to be laid out the same as the hex file. If you understood both you would realize why this can't be.
 
Do you understand the HEX file format? It's (up to) 16 bytes per line, with byte addressing.
 
Do you understand the bootloader protocol? It sends one row per write command. It looks from the hex file that you are using a PIC16 with 32 words per row. The addressing is word addressing. For your PIC16, one word is 14bits which takes two bytes to represent. Thus each write command must be 64 bytes.
 
Since one word requires two bytes, the bootloader word addresses are half the hex file byte address.
 
The first hex data (at the relocated reset vector) is written last. otherwise the order of data is the same.
 

嗨，吉姆，谢谢你的回复。这个问题实际上存在于通过真实术语捕获的十六进制文件中。用XC8或者你可以说MPLAB X IDE交付的文件我没有发现任何这样的问题。



      以下为原文

    Hi Jim,
 
Thanks For the Reply.The problem actually exists in the hex file captured via Real Term. With XC8 or you can say the file delivered by MPLAB X IDE i don't find any such problem.

如果你看了照片上的附件，然后用蓝色标记顶部的十六进制是我从编译器中得到的一个（即排序），在结尾包括校验和，代表8个字节的字节，下一个4个RP地址，和最后两个，即00个RP：它不是最后一行数据。）另一方面，当我通过统一的Bootloader主机应用程序发送这个应用程序，然后通过Realterm来捕获数据时，用红色标出的那一个是我得到的。在实际使用的HEX文件中，数据没有被正确地排序，有些数据在不同的地方丢失，或者在一条数据线之间有一些额外的东西。我正在使用另一个系统，这是必要的，当我发送数据，那么它应该是相同的，即类似于十六进制文件Xen的XC8或至少数据排序一样的文件没有额外的字符之间，因为你可以看到在红色标记的十六进制数据。现在的问题是请指导我如何做到这一点。或者哪种方法是获得我想要的最好的方法？



      以下为原文

    If you have a look on the photo attached then the Hex on TOP with blue marking is the one i am getting Out of compiler (i.e. sorted and includes checksum at the end with the initial 8 characters representing no. of bytes, next 4 rep address, and last two i.e. 00 rep: it is not the last line of data). On the other hand the one marked with RED is the one i am getting when i send this app via Unified bootloader host application and then capture the data via Realterm. In this Hex File got by real Term the data is not sorted properly, some of the data is missing at different places or has some extra stuff in between one data line. i am using another system for which it is necessary that when i send the data then it should be identical i.e. similar to the Hex file gen by XC8 or atleast the data is sorted like that file without the extra character in between as you can see in the Red marked hex data. Now the point is please guide me how to do that. or which is the best approach to get what i am looking for?
 
 



   Attached Image(s)