poltrb.blogg.se

1. Marshmallow dual status clock how to#
2. Marshmallow dual status clock zip file#
3. Marshmallow dual status clock Patch#
4. Marshmallow dual status clock code#

Eventually I tried ets_delay_us(1), which also fixed the problem, and removed the pin toggling. If I removed the gpio_set_direction() from that spot and did it much earlier, the toggling then did not fix the problem. PortBASE_TYPE evt_res = xQueueReceive(p_i2c->cmd_evt_queue, &evt, wait_time) Gpio_set_direction( 5, GPIO_MODE_DEF_OUTPUT) // Redundant after the first time. But that was easy to fix.īTW, I got this compilation warning, which you probably know about:

Marshmallow dual status clock Patch#

Your patch did not quite apply, because the IRAM_ATTR had been removed from the function declarations in the first hunk of the patch. But it might explain why my delay patch works for me, even though it did not work for you (against master?). If you get different results than I did, that would be surprising, and we'd need to check why. You might test my i2c_delay against v4.4, if you have not done so. Perhaps there are FreeRTOS changes you know about from v4.4 to master that might explain the issues. If you backport your current fix to v4.4, it may work for your test, but would not work in our case. Your patch works on v4.4 on the i2c_delay example, but not in circuitpython, which has another, higher-priority task, some core affinity preferences, etc.

Marshmallow dual status clock how to#

So I am not sure how to continue testing in the short run. It would take some more time to bring it forward. I tried advancing circuitpython to master, but there are many deprecations and other changes we have to deal with, and I cannot yet get it to build. It also works reliably at 160 MHz in CircuitPython without my delay patch.

Marshmallow dual status clock code#

But when I went back to the original i2c.c code with just my delay patch and not your changes, it works reliably again. With your patch, re-adding my small delay (as above) also did not help. I experimented with lowering the CPU frequency to 160 MHz to see if that was the issue. In circuitpython, my test runs for a few seconds, but then I get an I2C timeout, and I see that the SDA line is stuck high. But I also tested your patch against circuitpython is also using v4.4, though it's a little behind, at 121ddb8. When I try your fix on my i2c_delay example, and it works. I was testing against c29343e, the tip of release/v4.4 when I last pulled from esp-idf. Thank you you testing against master or against v4.4? The very end of i2c_master_cmd_begin_static() calls i2c_hal_trans_start(): I also discovered that adding a very small delay at a crucial point in the ESP-IDF I2C code will fix the problem. When the clock frequency is 160 MHz, the gaps disappear: If you change CONFIG_FREERTOS_HZ, the gap size will change accordingly.

Marshmallow dual status clock zip file#

When the clock frequency is 240 MHz (the choice in sdkconfig in the zip file above), there are gaps of almost 10 ms between I2C transactions. I picked an arbitrary device, an MSA311, but it does not really matter what device it is, as long as it will ACK writes.

It writes 4 bytes (could be less) to a register on an I2C device over and over again. This example builds for an Adafruit Metro ESP32-S2 board, which is based on the WROVER module, but with only slight changes it should be usable on an Espressif or other dev board. Here is the simple ESP-IDF example, which is a cut-down version of the I2C example in the esp-idf. The key is that I set the clock speed to 240 MHz instead of 160 MHz. It is not a task issue, as far as I can tell.

I am wondering if it is hardware or hardware-setup I have managed to reproduce this with a very simple example. I spent quite a bit of time inside the IDF I2C code, adjusting timeouts ( ticks_to_wait), printing things, and trying various tweaks, and I cannot locate the source of this issue. I have Saleae traces if that is of interest. These forum posts report what sounds like the same issue: Tested in CircuitPython, which currently uses the ESP-IDF version shown above. I was suspicious that 10ms is close to the FreeRTOS tick interval, but the gaps vary sometimes between 9.something and occasionally as low as 7.something, so that may be a red herring. There should not be excessive delays at 100kHz. A colleague tried another device and was able to get it to work at 110_000. In between, only some I2C speeds work others produce glitches that cause the I2C device to fail. Raising to 125_000 causes the delays to go away. Using I2C at 100_000 Hz (standard clock rate) cause ~10ms delays between I2C transactions.