C++ version about mcbootflash HOT 4 CLOSED

Cool!

Have you looked at existing C++ HEX libraries, like Intel HEX Class or libintelhex? I haven't used either myself, so I can't speak for them, but HEX parsing seems like a common enough problem that I would expect there to already exist C++ libraries for it.

Since this isn't a bug report or a feature request, I'm going to close it. But thanks for letting me know about your port 😃

from mcbootflash.

Hi, thank you for bringing up Intel Hex C++ libraries! Indeed, I could have considered using them.

However, I came across your discussions with the author of bincopy in this GitHub issue. It seems to me that the C++ Intel binaries might not offer the exact support needed for the very specialized microchip 24-bit format, which includes extended linear segments and other subtleties like having to double some addresses.

Besides, I also wanted to take this opportunity to understand the format myself directly. And be sure to have the minimal amount of code needed for the task.

Given this context, I thought it might be more practical to attempt a direct port of bincopy instead.

By the way, I noticed that in the flash.hex file used for unit tests, we're not testing the extended segments (IHEX_EXTENDED_LINEAR_ADDRESS). I'm not sure if it's necessary to test them in mcbootflash or bincopy, but I'm pointing it out because my hex file had this type of line.
example :

:045e0000ffffff00a1
:020000040000fa.

(It is working correctly)

from mcbootflash.

By the way, I noticed that in the flash.hex file used for unit tests, we're not testing the extended segments (IHEX_EXTENDED_LINEAR_ADDRESS). I'm not sure if it's necessary to test them in mcbootflash or bincopy, but I'm pointing it out because my hex file had this type of line.
example :

I'm pretty sure bincopy has a test for extended linear address records. Testing the same thing in mcbootflash would be redundant, and a violation of separation of concerns; It is bincopy's job to parse the hex file, and mcbootflash's job to send the contents over the wire.

Notice that most of mcbootflash's functionality has no concept of hex files; instead they consume generalized firmware chunks. Mcbootflash only depends on bincopy via the chunked utility function. The firmware chunks could conceivably come from some other source.

The hex files in the unit tests are just a convenient way to store the test data. They could have been pickles or something instead.

from mcbootflash.

You are right, it looks like this issue is about extended segment and a test for this was indeed added here

And you are also right about separation of concerns : each library should focus on its own job. Since I redo bincopy, I should have this test, but this does not apply to this library.

from mcbootflash.