ESP32 read i2c or i3c in IRQ macro

[mnfisher]

Hi Stefan,

You need the TaskId from xTaskCreatePinnedToCore - to pass to notify..

I think it is the last but one parameter - and you'll need to pass the address of a FC variable..

So if the variable is SaveToSDTask (needs to be a UINT32) - then pass &FCV_SAVETOSDTASK - the 'drag' variable to the C block is good here....
& - gets the address..

If you use Notify to wake the task then it shouldn'tneed a delay....

Martin

[stefan.erni]

Hi Martin

Yes I dont need a delay and there is no watchdog fired. Just change the command like this.

The cornumber needs to be on the end and the variable b4.

2025-04-24_14-09-47.PNG (32.76 KiB) Viewed 2464 times

working program:

Uart_int.fcfx

(25.02 KiB) Downloaded 50 times

[mnfisher]

For interest - I wanted to see if the accelerometer is returning 'meaningful' data....

I added a 'SaveData' macro - although in this case it outputs the first 4 6 value samples from the save buffer to UART... I went with using accel_data[0..499] as buffer 0 and [500.999] as buffer 1.
The ReadSample macro - notifies the SaveData macro when a buffer is full.

The values change more dramatically when I move the sensor - but I'm not much the wiser?

Martin

[stefan.erni]

Your IRQ handling is working fine. And reading faster I2C also!
I adjust for my hardware and let it run


If the sensor is flat on the table the z-axis has +16400 digit

2025-04-25_11-06-56.PNG (6.06 KiB) Viewed 2421 times

If I turn it 90 deg an other axis goes to -16300 and z-axis goes to zero

2025-04-25_11-09-19.PNG (7.86 KiB) Viewed 2421 times

so I turn 180 deg axis goes to goes to +16300

2025-04-25_11-11-23.PNG (7.3 KiB) Viewed 2421 times

mod program to send String to uart

lsdm3_int4.fcfx

(31.81 KiB) Downloaded 32 times

[mnfisher]

Thanks Stefan,

That's very helpful - I'll have a look and see if I can spot the pattern in my sensor's returns.

Martin

[mnfisher]

Just tested - and yes. The results look sensible...

Saving buffer 0 - (182,1678,-16281)
Saving buffer 1 - (154,652,-15675)
Saving buffer 0 - (-16348,436,500)
Saving buffer 1 - (-16326,482,950)
Saving buffer 0 - (-34,16344,-922)
Saving buffer 1 - (2,16330,-965)

With the board 'aligned' in each of the 3 planes. I set the delay between samples to 10ms - to allow a more sedate update rate...

Martin

[stefan.erni]

Hi Martin

Your program works fine even if I add some more commands

lsdm3_int4.fcfx

(38.56 KiB) Downloaded 56 times

My program give a watchdog error if I write to I2C even in at loop an begin

IMU_POST_sd_card_wave.fcfx

(282.82 KiB) Downloaded 50 times

2025-05-09_16-03-10.PNG (100.87 KiB) Viewed 1135 times

[mnfisher]

Hi Stefan

Not entirely sure why the wdt is getting fired - but in main() - you have a loop

2025-05-09_22-16-16.PNG (59.51 KiB) Viewed 946 times

Oops - sorry a bit larger than expected!

Which doesn't exit - is this intended? It has a delay - so wouldn't expect the wdt issue though (although the program won't progress?)

Martin

[mnfisher]

I notice a slight oddity. The Enable timer interrupt - describes microseconds support as 'experimental'.

However the code generated is (for example):

Code: Select all

      // 60 HZ (16mSec)  62.5Hz
      FC_CAL_Timer_Period = 16;
      FC_CAL_Timer_Multiplier = 1000;
      FC_CAL_Timer_Init(0, FC_CAL_Timer_Period * FC_CAL_Timer_Multiplier, FC_CAL_Timer_0_ISR);

i.e - all the timer interrupts actually use microsecond delays (and to test - setting a timer to 10s -> 10 x 1000000 as the delay).

So - I'd question the 'experimental' - it might also be worth checking if there are more efficient options for longer delays.
It might not actually check every microsecond (RTOS might optimise this?)

It also gives the chance to use a calculation to calculate the delay:

Code: Select all

.tDelay = 1000000 / frequency_in_Hz

and then in a code block:

Code: Select all

FC_CAL_Timer_Init(0, FCL_TDELAY, FC_CAL_Timer_0_ISR);

It also means that using milliseconds isn't necessary (there is no advantage to doing so) - so in the above example - a much closer approximation to 60Hz could be generated using 16666 us as the timer length.

Martin

[mnfisher]

Just tested - and it does work as expected

As pointed out previously - I don't think stopping / restarting interrupts works. The esp timer handlers do allow this (with things like one_shot and periodical timers) - and also allow multiple 'interrupts' (or callbacks) per timer.

A very simple example that allows a pin to be toggled at a given rate - it doesn't handle rates slower than 1Hz (every 10s say) - but it could be handled with some simple changes.

Setting the divider on the timer would be the answer for lower frequencies.

Martin