timonel-py alpha!

[prandeamus]

https://github.com/prandeamus/timonel-py

I've created a proof of concept to show how a PC can be used to upload data to Timonel! Incomplete (very much so), but has some functionality and I can connect t a device, read status and device capabilities, read flash and read and write EEPROM.

This is very much pre-alpha, so just about anything may change, but there's an app that demonstrates what works.

[casanovg]

Cool, great start! I'll take a look at it these days.

Although Python may not be my greatest strength at the moment, I will also try to collaborate where I can. I really liked your presentation page.

[prandeamus]

I've been looking at the format of packets sent by the controller to the Timonel device, and I have some questions. Some of these come from a reverse engineering of the esp32 host code, and some from the timonel bootloader itself

Doc for READEEPR describes the TX content as having a checksum but the the timonel bootloader doesn't seem to check it. In fact four of the commands (READEEPR. WRITEEPR, WRITPAGE and STPGADDR) are documented as having TX checksums and I've having some trouble seeing exactly what they do. I what checksums are for in principle, by the way, not sure about some of the detail here. ANy chance you can clarify this?

I can see that the bootloader can retry packet if the returned checksum in RX packet is unexepected - that's not the problem.

Is there are reason why the WRITPAGE command has different endianness to READEEPR and WRITEEPR? WRITPAGE has LSB first, and the EEPR commands, also STPGADDR have the MSB of address first.

On a casual reading of Reply_WRITPAGE() in the bootloader, I can see some logic to check ranges (line 532 in current master branch, starting #if CHECK_PAGE_IX). I'm a bit confused about this, and it's certainly possible I've missed something, but if there's a safety rollback at line 528, reply[1] is set to zero. Now, if reply[1] also being used as checksum return, how can a caller tell the difference between an error condition and value where the return checksum is legitimately zero? As I say, it's possible I'm misreading this, and it's the first time I've studied the way ATTINY bootloaders do self-programming, so may have missed something.

Any clarifications would be appreciated. Thanks!

[casanovg]

I've been looking at the format of packets sent by the controller to the Timonel device, and I have some questions. Some of these come from a reverse engineering of the esp32 host code, and some from the timonel bootloader itself

I know how hard and unease can be to follow code written by someone else, please feel free to ask whatever you need, I'll try to answer as clearly as possible. It even takes me some time to go back through the code I wrote 2-3 years ago and remember why I did this or that, which today may seem inconsistent.

Doc for READEEPR describes the TX content as having a checksum but the the timonel bootloader doesn't seem to check it. In fact four of the commands (READEEPR. WRITEEPR, WRITPAGE and STPGADDR) are documented as having TX checksums and I've having some trouble seeing exactly what they do. I what checksums are for in principle, by the way, not sure about some of the detail here. ANy chance you can clarify this?

You are right about READEEPR and the others, the checksum is not used by the bootloader.

The story is more or less like this: when I add new functionality, I start by analyzing what is needed, then I create the new command and its expected reply on the worksheet, then I write the bootloader code and, in the end, the i2c master side code and I do the tests.

Generally, in the original idea, I foresee the possibility that the bootloader can detect whether the memory address the master is trying to request (or any other data) has been modified by noise. But, if in practice it is shown that these problems seldom happen, I end up removing such controls from the bootloader code to shrink its size as much as possible.

However, I normally leave the command with the recovery handshake ready to be implemented later if necessary, and sometimes the master side implementation also stays, since a few more code lines on it have a lower cost.

This of course is not written on stone, so it could be reviewed to remove stuff not currently in use from the protocol worksheet and master side code if it would add clarity. So far, since I've been the only contributor to this project, so it hasn't been really a problem, but as I said, this practice could change. What do you think?

I can see that the bootloader can retry packet if the returned checksum in RX packet is unexepected - that's not the problem.

OK!

Is there are reason why the WRITPAGE command has different endianness to READEEPR and WRITEEPR? WRITPAGE has LSB first, and the EEPR commands, also STPGADDR have the MSB of address first.

I've been going through the code trying to remember if there was any specific reason for this, but I couldn't find a good one. I think it is simply due to the time the functions were implemented. WRITPAGE is one of the rationales behind the bootloader, which is why it was implemented very early in the project, and I guess that, at that time, maybe I tried to follow the order the RJMP instruction is stored in flash.

On the other side, EEPROM functions are a kind of "nice to have", included in the latest versions. So I have to conclude that this inconsistency is due to a lack of attention to this detail when I've retaken development. Maybe it would be a good time to harmonize the functions byte order before releasing v1.6. If you see this as a priority right now, just open a PR on the v1.6 branch, or let me know to change it.

On a casual reading of Reply_WRITPAGE() in the bootloader, I can see some logic to check ranges (line 532 in current master branch, starting #if CHECK_PAGE_IX). I'm a bit confused about this, and it's certainly possible I've missed something, but if there's a safety rollback at line 528, reply[1] is set to zero. Now, if reply[1] also being used as checksum return, how can a caller tell the difference between an error condition and value where the return checksum is legitimately zero? As I say, it's possible I'm misreading this, and it's the first time I've studied the way ATTINY bootloaders do self-programming, so may have missed something.

Any clarifications would be appreciated. Thanks!

That's a very good observation! Yes, a checksum precalculated by the i2c master is received by the bootloader in a data packet's last byte. On a defensive approach, the bootloader also sums the received bytes to calculate the checksum by itself, just in case. If the received and calculated checksums don't match, then a safety flash deletion is flagged to execute and a checksum = 0 is returned to the master.

Returning 0 is just a decision I've taken since you have to return something, but you're right, in case the master checksum calculation is 0 (I would say rather uncommon), there can be a misunderstanding between parties. This can be solved on the master side by running GETTMNLV to know the user app start address after an upload, if it's 0, then you know that something went wrong on the bootloader side.

This is something highly advised after any upload on production setups anyway. If the bootloader runs a safety deletion, it will restart, as usual. So the only risk is that the master side switches to an "application running state" without checking since the running program on the AVR would be Timonel. By decision, this verification is not implemented on the "TimonelTwiM" demo i2c master library though.

[prandeamus]

Thanks. Software evolves and sometimes we all do things that are inconsistent when we look back. First and foremost it's your project, but here are my suggestions.

• It would be nice if the documentation for the protocol was consistent with implementation, i.e. if you've found from experiences that function X doesn't need checksums, and they aren't implemented in the bootloader to save space, get it written down somewhere if you can. Or maybe make checksums a config option? That quite a lot of complexity, probably not worth it. My advice would be to doc and move on.
• With regard to checksum of 0 for WRITPAGE being ambiguous, yeah it's a problem but as you say you can run GETTMLV to validate the start address to overcome it, and the default bootloader behaviour (not doing a write if the inbound data looks bad) is safe enough.
• The thing I really think you should do is amend the EEPROM read and write to use native (for Atmel instructions) byte ordering. This has the advantage of consistency and makes me feel happy, but also allows you to further optimise the C code. I'll explain below, but probably that's the only think I would recommend changing at this point.

Imagine that that word address is two consecutive bytes at Command[1] and Command[2]. Today this is big-endian so you have code such as

addr = (Command[1] << 8) | (Command[2]);

Now (I think I'm getting this right, if the Atmel byte order is actually little-endian

addr = (Command[2] <<8) | (Command[1])

You can encourage the compiler by taking the address of Command[1], casting the pointer to tells the compiler that that data starting at Command[1] actually is native 16-bit value, and that no shifts are needed to get the X Y or Z register loaded from two consecutive databytes.

addr = *(uint8_t *)(&Command[1]);

TLDR - you might be able to squeeze a few more bytes from the bootloader size. I don't have access to a compiler and target system for a while, so can't produce a PR in a hurry. I'll leave it with you to decide what you want to do. If there are not many users, we can always fix it another time.

• Final question, am I correct to think the byte order for STPGADDR is also inconsistent, or maybe I just don't quite understand that this is for? I should go back and study this.

[casanovg]

I buy it, your arguments sound good! Also, after seeing the current commands' endianness inconsistencies so well exposed in your summary table, you have activated my OCD mode, and now I can't live another minute knowing that it looks ugly because of me :-)

I should have included something like this to document the protocol, my worksheet approach is helpful for designing, but somewhat hides those details.

So, I'll do the following:

• I'll annotate in the worksheet where the command checksums are not implemented on the bootloader side, and that they are kept for future use.

• I'll reverse the endianness of the READEEPR, WRITEEPR, READFLSH, and STPGADDR commands on the Timonel v1.6 branch.

• I'll open a new NB_TimonelTwiM v1.3.0 branch (I2C Master Library for Arduino on ESP8266) to support the endianness inversion of the commands mentioned above. I'll also make comments where the checksums are not implemented by the bootloader, and possibly leave those bits of code as comments. I'm not going to make them selectable options, for now, it adds too much complexity, as you comment. Obviously, this branch will only merge with the main branch when the bootloader v1.6 branch merges with its main branch, to avoid breaking communication between the parties.

Final question, am I correct to think the byte order for STPGADDR is also inconsistent, or maybe I just don't quite understand that this is for? I should go back and study this.

Well, it is consistent with all commands except WRITPAGE :-)
Now seriously, yes, STPGADDR is also inconsistent considering AVRs work saving data words in little-endian format.

As for what STPGADDR is for, it sets the base address of a flash memory page before executing some other commands. For instance, using this command becomes mandatory for the I2C master when Timonel is set with AUTO_PAGE_ADDR = false.

In that case, the master side firmware upload function should indicate a given page address before sending the data bytes. You can see this from line 300 of TimonelTwiM.cpp: when "auto page calc" is disabled on the bootloader, the I2C master runs with said bootloader configuration.

twi_errors + = SetPageAddress (start_address + (page_count * SPM_PAGESIZE));

[prandeamus]

This is how to get people to do things for you: appeal to their OCD... seriously, this seems fine. Thank you.

[casanovg]

I'm afraid I have not so good news, with respect to ...

I've been going through the code trying to remember if there was any specific reason for this, but I couldn't find a good one. I think it is simply due to the time the functions were implemented. WRITPAGE is one of the rationales behind the bootloader, which is why it was implemented very early in the project, and I guess that, at that time, maybe I tried to follow the order the RJMP instruction is stored in flash.

I'm starting to find the possible reasons for the inconsistency. Just by modifying the Reply_READFLSH function endianness, the bootloader size increases 10 bytes ...

With the current byte order:

// Point the initial memory position to the received address, then
// advance to fill the reply with the requested data amount.
const __flash uint8_t *mem_position;
mem_position = (void *)((command[1] << 8) | command[2]);

You get:

[Hexfile] Take "data" size to calculate the bootloader's start address!
text    data     bss     dec     hex filename
   0    1534       0    1534     5fe tml-t85-test-comm.hex

However, reversing the order:

// Point the initial memory position to the received address, then
// advance to fill the reply with the requested data amount.
const __flash uint8_t *mem_position;
mem_position = (void *)((command[2] << 8) | command[1]);

you get:

[Hexfile] Take "data" size to calculate the bootloader's start address!
text    data     bss     dec     hex filename
   0    1544       0    1544     608 tml-t85-test-comm.hex

The tests were done with the bootloader version of GitHub's v1.6 branch, compiled with avr-gcc version 8.3.0 for Windows.

I think the changes need a bit more analysis before going forward. If you have a suggestion to achieve endianness consistency between functions, but without increasing the bootloader size, please let me know so I can test it.

[prandeamus]

OCD? I'll show you OCD! (smile)

Consider a function that stores a value in an address (like POKE in days of BASIC). And let's imagine that, like Timonel, the address is stored as the second and third bytes of a data packet. Well, [1] and [2] anyway, because we're zero based. That's not identical to Timonel but it's close enough to look at the code that is generated.

WARNING - this code not actually TESTED, I'm just looking at code generation! Reading AVR assembler gives me a headache, and obviously there's no point in highly optimised code that fails. So this is designed to make us think about code size, that's all.

3 versions of the function

• One has MSB first & does shifts to generate the address
• One has LSB first & does shifts to generate the address
• One uses native ordering and some little pointer casts to force the compiler to load the [1] and [2] bytes as if they were a pointer already
  It is structured to show different ways of extracting the address from the command data packet. The actual "poke" is the same in each block and doesn't try to use flash memory, to keep the analysis simple.

/* endian.c */

#include <stdint.h>

void PokeMSBFirst(uint8_t *command, uint8_t val) {
    uint16_t addr = (command[1] << 8) | (command[2]);
    *((uint8_t*)addr) = val;
}

void PokeLSBFirst(uint8_t *command, uint8_t val) {
    uint16_t addr = (command[2] << 8) | (command[1]);
    *((uint8_t*)addr) = val;
}

void PokeNative(uint8_t *command, uint8_t val) {
    uint16_t addr = *(uint16_t*)&command[1];
    *((uint8_t*)addr) = val;
}

Unravelling compilers is never an easy job, but if you compile with

avr-gcc -Wa,-adhln -g -c endian.c > endian.lst

then PokeNative is smaller. If we put in optimisations such as -O2, which lets face it is more realistic

avr-gcc -O2 -Wa,-adhln -g -c endian.c > endian.lst

Everything is smaller, but the PokeLSBFirst and PokeNative are smallest and generate identical code, which shows how clever compilers can be. I am using avr-gcc 5.4.0 and your stats may be different.

Is this useful? I'd be nterested to see your thoughts.

Furthermore on the subject of optimisation, if we assume the the code doesn't need to be made re-entrant/multi-threaded, then if you stop passing "command" as a stack parameter, but have it as a global buffer shared by all the apps. I am willing to bet that code gets smaller and faster again, because you can read command[1] and command[2] from static locations known at link time. If you've been brought up on modern architectures and programming styles there may be a revulsion to shared global memory, but sometimes programming a microcontroller needs skills that were last used in the 60s with FORTRAN programs.

[prandeamus]

Postscript on fixed buffers, and I realise this is a diversion but:

void PokeNative(uint8_t *command, uint8_t val) {
    uint16_t addr = *(uint16_t*)&command[1];
    *((uint8_t*)addr) = val;
}

volatile uint8_t fixedBuffer[8];

void PokeAddrFromFixedBuffer(uint8_t val) {
   uint16_t addr = *(uint16_t*)&fixedBuffer[1];
   *((uint8_t*)addr) = val;
}

Poke Native

 168 0026 A82F      		mov r26,r24
 169 0028 B92F      		mov r27,r25
 170 002a 1196      		adiw r26,1
 171 002c ED91      		ld r30,X+
 172 002e FC91      		ld r31,X
 173 0030 1297      		sbiw r26,1+1
 174 0032 6083      		st Z,r22
 175 0034 0895      		ret

Poke from fixed buffer

0036 E091 0000 		lds r30,fixedBuffer+1
 196 003a F091 0000 		lds r31,fixedBuffer+1+1
 197 003e 8083      		st Z,r24
 198 0040 0895      		ret

Will go away and rest, because my brain is overheating. It was all so simple in my youth when you only had X Y A registers to worry about :)

[casanovg]

Thanks for the examples and disassembly, you did a lot of work!

I understand your point that PokeMSBFirst results in a larger size than PokeLSBFirst / PokeNative with -O2. I even tried it myself and, in fact, it is exactly as you say, the compiler generates the same code for the last two, smaller than MSBFirst.

But, maybe I'm getting dumber than usual as I get in trouble writing a Reply_READFLSH function complete with little-endianness, flash read, and pointer increment, and still get a smaller code size than the original big-endian version. This is what I did (although I keep passing the command as a parameter, one step at a time :-)

inline void Reply_READFLSH(const uint8_t *command) {
    const uint8_t reply_len = (command[3] + 2);  // Reply length: ack + memory positions requested + checksum
    uint8_t reply[reply_len];
    reply[0] = ACKRDFSH;
    reply[reply_len - 1] = 0;  // Checksum initialization
    // Point the initial memory position to the received address, then
    // advance to fill the reply with the requested data amount.
    const __flash uint8_t *mem_position = (uint8_t*)(*(uint16_t*)&command[1]);
    for (uint8_t i = 1; i < command[3] + 1; i++) {
        reply[i] = *(mem_position++);                   // Actual memory position data
        reply[reply_len - 1] += (uint8_t)(reply[i]);    // Checksum accumulator
    }
    reply[reply_len - 1] += (uint8_t)(command[1]);      // Add Received address MSB to checksum
    reply[reply_len - 1] += (uint8_t)(command[2]);      // Add Received address LSB to checksum
    for (uint8_t i = 0; i < reply_len; i++) {
        UsiTwiTransmitByte(reply[i]);
    }
}

and I get this ...

   text    data     bss     dec     hex filename
      0    1540       0    1540     604 tml-t85-test-comm.hex

Still 6 bytes larger than the original, do you think you can help me with this? If the byte-order change to this function results in the same 1534 bytes as the original, I'll be happy to change it to little-endian, as well as the others.

I may not be in my brightest days, but I am not able to figure it out. By the way, I am responding slowly because this time of year is a bit busy for me, and from time to time I have to show my employer why they pay me :-)

[prandeamus]

No need for false modesty on your part. There's tons of good stuff in this code base and I couldn't have done this at all. Please, please, don't feel under any pressure to respond to a timescale. This is a hobby thing for me and there's nothing time-critical. Don't get fired because of it :) OK?

I have a few thoughts about this method as it stands that you might want to look at, and they may help to simplify things

uint8_t reply[reply_len];

Looks innocent but is more complex than it appears because reply_len is a variable. Older C compilers like K&R or C89 wouldn't permit this, and used constants only. It's nice to see that newer C/C++ compilers do it, because it's convenient, but it may well have more run-time overhead than is immediately obvious.

uint8_t reply[32 /* Or whatever max size is */];

allocates more efficiently on the stack and the compiler can see which offsets from stack are fixed.

const __flash uint8_t *mem_position = (uint8_t*)(*(uint16_t*)&command[1]);

Because this is created after the dynamically sized reply[] buffer it may have to generate more code? It might be a fun idea to move this line before reply[] is allocated. Depends, as usual, on exactly what the compiler does. If variables are allocated on the stack strictly in order of declaration, it was often considered a good idea to declare them last. Your mileage, etc. may vary

finally if you use

reply[reply_len - 1]

as the checksum accumulator, it's debatable whether the compiler can determine it's just a simple byte value. if you create a stack variable uint8_t chk=0 at the start of the code, and then chk+=each_byte, and only assign to reply[reply_len-1] just before the UsiTwiTransmitByte loop, it might give the compiler enough hits to generate tighter code.

[prandeamus]

I have also just realised that my test code generation was using the generic codegen settings for avr-gcc which probably line up with the processor in the original Arduino by default, rather than the reduced instruction set used by Attiny. That may be a reason why your not seeing the gains that I expected. The tiny version of the instruction set has some instructions removed (e.g. no hardware multiply) and fewer registers to play with (see https://gcc.gnu.org/wiki/avr-gcc#Reduced_Tiny)

Sorry about that. I think I'm distracting you from other things,

[casanovg]

I'm back, only on weekends until June 30, I'll be disappearing intermittently due to some deadlines I have :-)

Thanks for the clarification on your avr-gcc configuration, those things happen. Anyway, for completeness's sake, I have tested your suggestions. My tests only consisted of doing the replacements you suggested, compiling, and verifying the size obtained (and that the function works of course). I have not gone down to analyze the results at assembler level because I honestly do not have the time to do it and also, somehow, I do not think it is my function to review what the compiler does. "I want to believe" that the GNU guys do things well and better than me. This stance, as well as the choice of C, have been decisions made quite early in this and other projects, because of accessibility and maintainability reasons, and possibly influenced a bit by this Aussie dude's remarks. This, of course, does not prevent me from being open to all suggestions that come as a ready-to-implement recipe to get smaller code, or other ideas (like the replacement of "+" by "|" that you suggested before), or better, if directly you implement it and open a PR.

About the tests (I opened a temp "alt" branch for them):

1-I tried making "command" a global var to avoid passing it as a parameter, risking myself being thrown to the stake by anti-global-variable purists. But the compiler seems to have done a good job with the current code since the hex size obtained is exactly the same.

2-I also tried to make the "mem_pack" struct global just in case, again with bad results in terms of size: 2018 bytes instead of 1534 for the "test-comm" setup.

3-Moving const __flash uint8_t *mem_position = (uint8_t*)(*(uint16_t*)&command[1]); before the reply[] allocation doesn't change a single byte on the iHex size either, unfortunately.

4-Regarding uint8_t reply[reply_len]; it is true what you say about it being a variable, therefore less efficient than a constant. In fact, I have tried with uint8_t reply_len = (SLV_PACKET_SIZE + 2) and "test-comm" compiles in 1522 bytes, 12 less than with the former. The point is that there is a variable there for a reason, if you take a look at it, its value comes from the I2C master command, so it allows it to control the packets' size returned by the bootloader. This is so to be able to somehow "fall back" to smaller sizes in case of noise and recurring errors. It's a feature that I wouldn't want to lose. Luckily, as you say, modern compilers allow it, otherwise, it would have to be done by hand with a dynamic arrangement, or similar.

Now, going back to the original motivation for all this, perhaps it would better to change the WRITPAGE endianness if the code size does not increase, given that it is the only one different from the others. I'm going to do these tests today to see how it goes, then I'll let you know.

Regarding doing the opposite, reversing the byte order of READEEPR, WRITEEPR, READFLSH, and STPGADDR, I have not managed to do it without increasing size on flash, if you find a way to do it, we can go that way, just let me know.

[prandeamus]

Absolutely! Thanks for looking at this! On 20 Jun 2021 15:00, Gustavo Casanova ***@***.***> wrote: I'm back, only on weekends until June 30, I'll be disappearing intermittently due to some deadlines I have :-) Thanks for the clarification on your avr-gcc configuration, those things happen. Anyway, for completeness's sake, I have tested your suggestions. My tests only consisted of doing the replacements you suggested, compiling, and verifying the size obtained (and that the function works of course). I have not gone down to analyze the results at assembler level because I honestly do not have the time to do it and also, somehow, I do not think it is my function to review what the compiler does. "I want to believe" that the GNU guys do things well and better than me. This stance, as well as the choice of C, have been decisions made quite early in this and other projects, because of accessibility and maintainability reasons, and possibly influenced a bit by this Aussie dude's remarks. This, of course, does not prevent me from being open to all suggestions that come as a ready-to-implement recipe to get smaller code, or other ideas (like the replacement of "+" by "|" that you suggested before), or better, if directly you implement it and open a PR. About the tests (I opened a temp "alt" branch for them): 1-I tried making "command" a global var to avoid passing it as a parameter, risking myself being thrown to the stake by anti-global-variable purists. But the compiler seems to have done a good job with the current code since the hex size obtained is exactly the same. 2-I also tried to make the "mem_pack" struct global just in case, again with bad results in terms of size: 2018 bytes instead of 1534 for the "test-comm" setup. 3-Moving const __flash uint8_t *mem_position = (uint8_t*)(*(uint16_t*)&command[1]); before the reply[] allocation doesn't change a single byte on the iHex size either, unfortunately. 4-Regarding uint8_t reply[reply_len]; it is true what you say about it being a variable, therefore less efficient than a constant. In fact, I have tried with uint8_t reply_len = (SLV_PACKET_SIZE + 2) and "test-comm" compiles in 1522 bytes, 12 less than with the former. The point is that there is a variable there for a reason, if you take a look at it, its value comes from the I2C master command, so it allows it to control the packets' size returned by the bootloader. This is so to be able to somehow "fall back" to smaller sizes in case of noise and recurring errors. It's a feature that I wouldn't want to lose. Luckily, as you say, modern compilers allow it, otherwise, it would have to be done by hand with a dynamic arrangement, or similar. Now, going back to the original motivation for all this, perhaps it would better to change the WRITPAGE endianness if the code size does not increase, given that it is the only one different from the others. I'm going to do these tests today to see how it goes, then I'll let you know. Regarding doing the opposite, reversing the byte order of READEEPR, WRITEEPR, READFLSH, and STPGADDR, I have not managed to do it without increasing size on flash, if you find a way to do it, we can go that way, just let me know. —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[casanovg]

I spent a big chunk of this weekend doing several cross tests, and I am finally concluding on the bootloader functions' transmission endianness.

And the winner is (drum roll) ... Little-endian everywhere!

After creating two Timonel versions on the "Alt" branch, a BE one, and a LE one, and compiling all the configurations of both with ./make-timonel --all, the results are what I add below. It can be seen that with the LE version, all the configurations compile in smaller (or equal) size than with BE.

So, if you agree with this, I would close this point and move on. I'm going to change the v1.6 bootloader code before its release, along with a new version of the I2C master TimonelTwiM library, to be compatible with this change. If you want to, you could also change your documentation to reflect this.

These are the iHex sizes obtained with the BE Timonel version for all configs:

Big-endian
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1506       0    1506     5e2 tml-t85-full.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1646       0    1646     66e tml-t85-full-auto.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1590       0    1590     636 tml-t85-full-usetplpg.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0     830       0     830     33e tml-t85-small.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0     900       0     900     384 tml-t85-small-autorun.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1114       0    1114     45a tml-t85-small-dump.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0     962       0     962     3c2 tml-t85-std.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1270       0    1270     4f6 tml-t85-std-dump.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1196       0    1196     4ac tml-t85-std-norun-dump.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1492       0    1492     5d4 tml-t85-test-comm.hex
------------------------------------------------------------------------

And with the LE version:

Little-endian
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1500       0    1500     5dc tml-t85-full.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1640       0    1640     668 tml-t85-full-auto.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1582       0    1582     62e tml-t85-full-usetplpg.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0     824       0     824     338 tml-t85-small.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0     894       0     894     37e tml-t85-small-autorun.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1108       0    1108     454 tml-t85-small-dump.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0     962       0     962     3c2 tml-t85-std.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1270       0    1270     4f6 tml-t85-std-dump.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1192       0    1192     4a8 tml-t85-std-norun-dump.hex
------------------------------------------------------------------------
   text    data     bss     dec     hex filename
      0    1478       0    1478     5c6 tml-t85-test-comm.hex
------------------------------------------------------------------------

[prandeamus]

That's fantastic, and thanks for spending so much time on the analysis. It feels "right" because it aligns the data format with the processor's endianness, it's consistent across the protocol, and saves a few more bytes in some configurations. Nice work.
I've been diverted over to paying work in recent weeks and haven't done much work on my end, but I'll get my doc notes into sync with 1.6 and there will an opportunity to do some work at my end after the 1.6 release.

[casanovg]

Great! let's move on this way then ...