Skip to content

Commit cdbc4ed

Browse files
committed
Update hex-format.md
1 parent fc89465 commit cdbc4ed

File tree

1 file changed

+13
-9
lines changed

1 file changed

+13
-9
lines changed

software/hex-format.md

Lines changed: 13 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -13,23 +13,27 @@ review-with: carlospa
1313

1414
The .hex file is in [intel-hex format](https://en.wikipedia.org/wiki/Intel_HEX). Intel hex consists of records of data, with the address in memory to store the data at the start. All data is hex-ascii encoded. All lines start with a : character. All lines end with a checksum byte that can be used to verify the integrity of the data.
1515

16-
A micro:bit .hex file usually starts writing data to the same fixed location in memory, so depending on the toolchain, we might expect the first line of the file to start like this:
16+
A micro:bit .hex file usually starts writing data to the same fixed location in memory. Depending on the toolchain, we might expect the first line of the file to start like this:
1717

1818
:020000040000FA
1919

2020
## Universal Hex files
2121

22-
The latest board revision introduces a superset of the Intel-Hex format that enables compatibility across processor variants. A Universal Hex is a file that contains the binary data for both micro:bit <span class="v1">v1</span> and micro:bit <span class="v2">V2</span>, in a format that DAPLink can process to only write to memory the data relevant to its micro:bit board.
22+
The latest board revision introduces a superset of the Intel-Hex format that enables compatibility across processor variants. A Universal Hex is a file that contains the binary data for both micro:bit <span class="v1">v1</span> and micro:bit <span class="v2">V2</span>, in a format that DAPLink can process and write to memory only the data relevant to its micro:bit board.
2323

2424
A **Universal Hex** hex file will work on a v1 or V2 board.
25-
A clear indication that you are working with this format is that a compiled .hex file will be ~1.8Mb as opposed to ~700Kb in size.
25+
A clear indication that you are working with this format is that the compiled .hex file will be ~1.8Mb instead of ~700Kb in size.
2626

27-
A [Universal Hex JavaScript Library](https://github.com/microbit-foundation/microbit-universal-hex) has been written to implement the format and associated detailed [specification of the Universal Hex format](https://github.com/microbit-foundation/universal-hex/).
27+
The following resources will help you implement **Universal Hex** support in your application:
28+
29+
* [Universal Hex JavaScript Library](https://github.com/microbit-foundation/microbit-universal-hex)
30+
* [Detailed specification of the Universal Hex format](https://github.com/microbit-foundation/universal-hex/).
2831

2932
### Cross device compatibility
30-
The Universal Hex format has been developed to ensure the best experience for users when moving between board variants. If a V1 only .hex is detected on a V2 board it will throw an error, but a V2 only hex will fail silently on a V1. This is very confusing to users and should be avoided.
3133

32-
There may be cases where it is not possible to support both boards, for example an accessory that is designed only to target the V2 board variant. In these cases, to ensure the best user experience when flashing a hex file to any board variant, the file should always include an error message to signify board incompatibility to the user.
34+
Including *both* .hex formats within a Universal Hex ensures the best experience for users when moving between board variants. If a V1 only .hex is detected on a V2 board it will throw an error, but a V2 only hex will fail silently on a V1. This is confusing to users and should be avoided.
35+
36+
There may be cases where it is not possible to support both boards, for example an accessory that targets only the V2 board variant. In these cases, to ensure the best user experience when flashing a hex file to any board variant, the file should always include an error message to signify board incompatibility to the user.
3337

3438
We have created a [standalone error hex](/docs/software/assets/stand-alone-error-v1.hex) that can be combined with a V2 only hex to produce a Hex that will work on a V2 board, but error if used on a v1.
3539

@@ -42,7 +46,7 @@ This example shows the worst, best and acceptable (when support for V1 is imposs
4246

4347
These examples show the process of creating a Universal Hex. A V1 and V2 hex can be combined to produce a Universal Hex. If you can only support a V2 board,the standalone error can be combined with a V2 hex to produce a hex that will fail with an error on a V1 board, rather than failing silently.
4448

45-
|Universal Hex format |V2 only Hex format |
49+
|Universal Hex format |V2 only Hex format |
4650
|-----------------------------------------------------------|-----------------------------------------------------------|
4751
| ![Universal Hex error 2](/docs/software/assets/uhex2.png) | ![Universal Hex error 3](/docs/software/assets/uhex1.png) |
4852

@@ -53,8 +57,8 @@ If you are building .hex files for both board variants, you will need to use the
5357

5458
See the [Micropython Hex file reference](https://microbit-micropython.readthedocs.io/en/latest/devguide/hexformat.html) for up to date information.
5559

56-
MicroPython builds take a firmware.hex image (the MicroPython pre-compiled image) and appends your script to the end of it, in a fixed 8K region at a known address. When MicroPythons starts to run on the micro:bit, it looks for a signature at this fixed location, and uses that to determine whether to run the script, or drop directly to the REPL prompt.
60+
MicroPython builds take a "firmware.hex" image (the MicroPython pre-compiled image) and appends your script to the end of it, in a fixed 8K region at a known address. When MicroPythons starts to run on the micro:bit, it looks for a signature at this fixed location, and uses that to determine whether to run the script, or drop directly to the REPL prompt.
5761

5862
## Microsoft MakeCode Editor
5963

60-
Hex files generated by the [MakeCode Editor](https://makecode.microbit.org) have embedded meta-data inside the .hex file. This is a [JSON encoded blob with various data about the script](https://github.com/Microsoft/pxt/blob/437f53ca6311335c7f3f75a062ec1079b4e7806a/docs/source-embedding.md), and also the source code program. This may be compressed, and it is stored inside the flash memory of the micro:bit (but only if space is available in the flash memory). But it is always inside the .hex file. This embedded source code program ensures that when you drag and drop the .hex file onto the originating editor, it can recover the source program again.
64+
Hex files generated by the [MakeCode Editor](https://makecode.microbit.org) include the source code of the program in addition to embedded metadata. This metadata comprises a [JSON encoded blob with information about the script](https://github.com/Microsoft/pxt/blob/437f53ca6311335c7f3f75a062ec1079b4e7806a/docs/source-embedding.md). Both the metadata and source code may be compressed and, space permitting, are stored inside the flash memory of the micro:bit. When you drag and drop a MakeCode .hex file onto the originating editor it can recover the source code, allowing the program to be modified and saved back to a .hex.

0 commit comments

Comments
 (0)