The “srec_cat” program works on both Windows and Linux.
#IHEX VS HEX SOFTWARE#
This software solution includes a versatile program called “srec_cat”, which make it quick and easy to convert between files in the HEX and SREC format. It is available from the following website. There is an open source software solution called “SRecord”. This article is written for those that need a solution right now. To accommodate these users, the HEX file format support is planned for a future version of the OpenBLT bootloader.
#IHEX VS HEX PATCH#
However, it has been brought to my attention that some users employ custom developed post-build patch tools that only work with HEX files.
#IHEX VS HEX PC#
Therefore I never saw the need to add HEX file support to the PC programs. This article demonstrates how you can easily convert between the HEX and SREC file formats.Īll compiler toolchains that I developed microcontroller software with so far, that support the generation of HEX files, can generate SREC files.
Several users have requested the additional support of the Intel Hex (HEX) format. Both programs expect your firmware file to be in the Motorola S-Record (SREC) format. Wikipedia has a fun list of numeral systems.The OpenBLT bootloader package includes two PC programs for initiating and monitoring firmware updates ( MicroBoot and BootCommander).
Hopefully, I've clarified that the selection of your encoding base is a matter of sliding along a scale until you get the best efficiency you can have before sacrificing what's important to you. Is that a concern for you? If it's not, you could go for something like base62, which is still convenient in HTTP query strings, but is case sensitive and includes zero "0" and "1". So base32 introduces a new concern ease of reproduction for humans. Most of its inefficiency comes from being case-insensitive and avoiding zero "0" and one "1", to mistakes in reproduction by humans. It's 20% less efficient than base64, but is still suitable for use in HTTP query strings. Neither base is inherently better or worse they're just two different points on a scale, at which you'll find different properties that will be more or less attractive in different situations.įor example, consider base32. Notice that this is an additional concern, over and above efficiency. So one reason to favour base16 over base64 is that base16 values can be composed directly into HTTP query strings without requiring additional encoding.
#IHEX VS HEX PLUS#
These can include plus "+" and equal "=". Different implementations use different punctuation characters for indicating padding, and making up the last two characters of the set of 64. There is more to base selection than efficiency.īase64 uses more than just letters and numbers. Other answers made clear the efficiency difference between base16 and base64. It's come to my attention that Ascii85 aka Base85 exists and is slightly more efficient (25% data size growth when encoding as Base85 instead of 33% for Base64): Now you are hopefully wiser after having read this.įun Update: Speaking of other encoding styles with more characters. But the beauty of base64 is how it encodes data so cleanly in chunks of 6 bits, and how you simply have to "read 3 bytes and output 4" to encode, and "read 4 bytes and output 3" to decode. There are obviously ways to create other systems such as perhaps "base81" etc, since you can do anything you want if you create a custom encoding algorithm. Many are control characters such as NULL etc. The answer for that is that base64 is the best we can find, since the lower 128 ASCII characters aren't all printable. You may think "Why not base128 (7 bits of input = 8 bits of output), at just 14% size growth when encoding?". So yes, Base64 always increases data size by 33% (plus some potential padding by the = characters that are sometimes added at the end of the base64 output). And if we divide 8bits/6bits we see where the 33% growth comes from, as mentioned at the top of this post.
Or, described another way, every Base64 character (which is 1 byte (8 bits)) encodes 6 bits of real data.
#IHEX VS HEX FULL#
So 24 bits (3 full 8-bit bytes of input) / 6 bits (base64 alphabet) = 4 bytes of base64. How are those represented in binary? With 000000 (0) to 111111 (63).īingo! Each base64 character represents 6 bits of input data using a single output byte (a single character such as "Z", etc). Why that magic "24 bits" number? Well, base 64 represents the numbers 0 to 63. I was curious how on EARTH base64 can convert 3 input bytes into 4 output bytes for just 33% space growth (whereas hex converts 1 input byte into 2 output bytes for 100% space growth).
0 kommentar(er)
