Nicen up I2C buffer assembly a bit, also yields smaller binaries

[therealprof]

Signed-off-by: Daniel Egger daniel@eggers-club.de

[jamwaffles]

Does this work on the hardware you're using? I've tried running the blinky_i2c example (both in debug and release mode) on my stm32f103 and it crashes with the error stm32f103xx_hal::i2c::Error::Acknowledge. using Rust 1.27.0 nightly. Smaller binaries is good!

[therealprof]

Weird. I'm not really using the F103 (as a host MCU that is) much since I have so much more interesting hardware here. But it certainly works fine on my Nucleo-F042 I'm using to test this stuff.

[jamwaffles]

Look, it was £1.20 off AliExpress ok. What's not to like ;)

Looks like I was having grounding issues on my breadboard. False alarm!

[therealprof]

Aww, the dreaded Bluepill. :-D I do have those lying around, too but then I'll need to dig out a programmer or fool around with serial stuff. I kind of like the convenience of all-in-one-boards for development and if they're not available I design one myself. ;)

[jamwaffles]

The programmer is dirt cheap too! They're not the greatest dev boards nor the beefiest chips but I think they're a good intro to the world of arm micros on a budget :)

---

Just out of curiosity, this is the output of xargo bloat --release --example blinky_i2c --wide --full-fn:

File  .text   Size Name
0.0%   2.4%   108B [13 Others]
0.3%  22.1%   976B ssd1306::command::Command::send::hd5b484c8bec993ba
0.2%  14.9%   658B blinky_i2c::init::hba5dc584f1630531
0.2%  13.3%   590B <stm32f103xx_hal::i2c::I2c<stm32f103xx::I2C1, PINS> as embedded_hal::blocking::i2c::Write>::write::hdaecc94ffdb00145
0.1%   9.6%   424B cortex_m_rt::reset_handler::hf0bbd8ccb7786ac1
0.1%   6.9%   306B <ssd1306::mode::graphics::GraphicsMode<DI>>::flush::h1b0010c12b9f28a9
0.1%   5.1%   226B <stm32f103xx_hal::i2c::I2c<stm32f103xx::I2C1, PINS>>::init::h846befd441d24a8d
0.1%   4.2%   186B __aeabi_memcpy4
0.1%   3.8%   166B __aeabi_memset4
0.0%   3.4%   152B blinky_i2c::draw_square::h74ab5ac364d72ba6
0.0%   3.1%   138B cortex_m_rtfm::atomic::h1a689967eebc5f3e
0.0%   3.0%   134B <ssd1306::mode::graphics::GraphicsMode<DI>>::set_pixel::h37843e96e79879fb
0.0%   2.3%   100B memset
0.0%   2.2%    96B memcpy
0.0%   1.9%    82B blinky_i2c::idle::h06fd4aa2963c6eb0
0.0%   0.7%    30B blinky_i2c::main::h67b81545236a9c9a
0.0%   0.2%    10B __aeabi_memset
0.0%   0.2%    10B core::result::unwrap_failed::he8ec54871ce4b2bd
0.0%   0.2%    10B core::panicking::panic::hbe4c471254a60e66
0.0%   0.2%    10B core::panicking::panic_bounds_check::h41954b572615b0bd
0.0%   0.2%    10B SVCALL
1.4% 100.0% 4.3KiB .text section size, the file size is 301.0KiB

Not a huge difference from what we've found in #42.

[therealprof]

Yeah, indeed not much difference. I was trying to make it really efficient but got cock-blocked by the unsafety lint. 😏 Everything else I tried did not work with random transmit buffer sizes and I did not want to use the next best thing, the nightly ExactChunks iterator which might work better to get rid of the annoying bound checks... So I just made it cleaner and accepted the 30 bytes or so improvement as a gift.

[jamwaffles]

Better than a huge regression 😌