Flowcode Support Board

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

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. working program:

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

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 If I turn it 90 deg an other axis goes to -16300 and z-axis goes to zero so I turn 180 deg axis goes to goes to +16300 mod program to send String to uart

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

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

Hi Martin

Your program works fine even if I add some more commands My program give a watchdog error if I write to I2C even in at loop an begin

Hi Stefan

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

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

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

However the code generated is (for example):
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:
and then in a code block: 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

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