CLI 1.18.0 Takes up extra memory for BIN file?

I compared a compile of the same firmware between versions 1.17.1 and 1.18.0 and the 1.18.0 seems to be adding an extra 1.5K to the bin.

Any thoughts?

Hi @wesner0019,

Are those compiled against the same system firmware versions? ( I think 060 might have been released in that time window )

You can read the metadata off the binaries using the binary-version-reader here ( https://github.com/spark/binary-version-reader )

I hope that helps!

Thanks,
David

1 Like

@Dave, it look like it is now compiling to the 0.6.0 version. Any reason the new 0.6.0 version adds 1.5k to bin when compiling?

Hi @wesner0019,

Good question, I’m not sure, but I pinged the firmware team to see if they could weigh in.

Thanks!
David

For reproducible builds, you can pin which firmware you compile against by doing

particle compile p1 . --target 0.5.3

When you are ready to update system firmware because of features you need you can change your build target.

@jvanier, I was more curious to why when building against the 0.6.0 that user firmware increased by 1.5k. Our current firmware was compiling around 129,500 on 0.5.3 then we compiled against 0.6.0 and then our bin was near 130,900.

Which is valuable memory that was taken up by something else when compiling to the new version.

The best person to give this answer is out for Thanksgiving. We’ll get back to you after the holiday, ok?

2 Likes

Sounds good

It’s because of new global USBKeyboard and USBMouse handlers. In the next release we will upgrade the compiler version which produces smaller binaries, offsetting this increase. We may also be able to reduce this in 0.6.1 with some optimization techniques also.

If your application stops compiling due to space constraints, please let us know!

2 Likes