Follow along logic analyzer

General
61

image
image649×235 2.86 KB

Happy dance! Finally got I2C protocol working with FALA, still need to verify the demos though.

This has been driving me nuts on-and-off for weeks.

image
image501×160 4.85 KB

Finally I actually noticed what the Bus Pirate was clearly telling me: we’re working at 100kHz, but the logic analyzer is running at 800Hz.

image

Tearing into the guts of the I2C code made no difference because we were returning the raw kHz speed set by the user. The solution is to multiply it by 1000 to return Hz. FALA works now.

Two tasks remain:

  • check the I2C demos (with and without FALA)
  • handle FALA buffer roll-over gracefully (option to capture first bit or last bit)
2 Likes
62

image
image817×487 22.1 KB

I2C chip demos seem ok.

FALA now deals gracefully when the capture buffer is full before the end of the bus operation.

I am not going to add the option too capture the tail instead of the head because it looks like a lot of work. I did create a github issue though.

With this, FALA verification is complete.

63

This is a great learning opportunity:

At its core, the configuration is storing the value in the field named baudrate, but in reality, i2c is storing kHz_rate.

I would recommend changing the mode_config.baudrate field to either store the full baudrate (i.e., not in kHz units), or alternatively to change the field name to reflect it’s in kHz units.

If you want the API to remain similar, avoid unit-free terms. For example, change:
uint32_t hwi2c_get_speed(void)
uint32_t hwi2c_set_speed(...)

into:
uint32_t hwi2c_get_baudrate_kHz(void)
uint32_t hwi2c_set_baudrate_kHz(...)

Unit confusion has caused many mishaps and bugs. It’s worth the verbosity to avoid these issues (imho).