AD7794 long delay

RE: AD7794 long delay

Hugo — Mon, 20 Aug 2018 19:18:27 GMT

Thank you Stian,

I'm actually in vacation. My turn ;)
I'll try this WFE() function within a month.

But atbout OS and scheduler, not every OS has a scheduler, and a scheduler might not be an OS. This is because there is no precise definition of OS. An OS a is just a toolset that can handle hardware. . So saying that the softdevice, which is an OS in my opinion, is not an OS, is not an excuse of providing a nice scheduler or a less good one.
I'm happy to know that the scheduler cannot do what I need, the way I need, because it's a step further. I'm quite scared to use both softdevice which has a scheduler used by bluetooth runtime, and an other scheduler, as they need "to share" interupts from a timer, and they might interract. I'll check if it's possible, when I'll come back.
Thanks for your answer.

RE: AD7794 long delay

Stian Røed Hafskjold — Mon, 20 Aug 2018 11:39:08 GMT

The scheduler is very simple, it does not provide this functionality. It's basically just for transferring execution from interrupt context to main context. You put the event handler in a queue in the ISR, and you execute the handler in main context. That's all. FreeRTOS, linux etc which you mentioned earlier are OS's. If you want similar functionality you can use freeRTOS on the nRF chip, but I think this is a bit too much just for an SPI driver.

A clean and nice solution is to use flag in the GPIOTE interrupt handler and wait for it in the SPI function. Did you try the following?

bool data_ready = 0;

void gpiote_interrupt(){
    //got a MISO falling edge interrupt
    data_ready = 1;
}

void SPI_read_sensor(){
    spi_send_command();
    deinit_spi(); // SPI lines cannot be configured while SPI is enabled
    configure_gpiote_interrupt_on_MISO();
    while(!data_ready){
        __WFE(); //wait for event. CPU sleeps until event
    }
    data_ready = 0;
    deinit_gpiote();
    init_spi();
    spi_read_data();
}

Note that you cannot reconfigure the GPIO pins while SPI is enabled.

Another thing you should be careful with is whether or not the spi_read/write calls are blocking. For example: If the "spi_read_data()" call above is non-blocking, the function will return instantly and the scheduler might continue execute the next function in the queue before the SPI data has actually been read. Or similarly, if the "spi_read_command()" call is non-blocking it will enter the waiting loop before the spi read command is sent.

RE: AD7794 long delay

Hugo — Tue, 14 Aug 2018 10:28:35 GMT

Great, it tooks me, 1mninute on google to deal with it on 3 different scheduler, I still don't know how to do it with the nordic softdevice scheduler. Can you name a function to "wait/block/suspend on a flag/mutex/semaphore"? can you link me an exemple? or the best can you ask me to read the manual, but with a link to the right page of the manual? this would be lovely, and thank you in advance :)

RE: AD7794 long delay

Susheel Nuguru — Tue, 14 Aug 2018 09:49:03 GMT

[quote userid="9573" url="~/f/nordic-q-a/36369/ad7794-long-delay/144098"]In an other hand, I fully agree that the while loop is really ugly and is a great way to block the CPU and everything including the softdevice[/quote]

The while loop does not block softdevice from interrupting your app. That is what we believe is the source of this problem.

There is a solution as I wrote earlier, instead of waiting for the pin state change, your app needs to wait/block/suspend on a flag/mutex/semaphore. Make sure that the flag/mutex/semaphore change their state in the gpio ISR which is making sure that you do not loose this info. I do not see any other way to do this a failproof way.

RE: AD7794 long delay

Hugo — Tue, 14 Aug 2018 08:30:09 GMT

Hin thanks, and congratulation, you found the bug.
Actually, as you see in the 1st screenshot, asking and waiting for a measurement takes 4ms.
When the while loop explodes, the 4ms are not done yet, wich means that if I was waiting for an interrupt, the interrupt woudn't have been called yet.
Maybe you are right, and this is cleaner, but I'm quite sure it won't work, would it?

In an other hand, I fully agree that the while loop is really ugly and is a great way to block the CPU and everything including the softdevice. I'm looking for a softer function, such as:
void no_breaking_delay_ms( int delay_time);
or
void wait_quietly_for_an_event_enjoying_a_mojito_on_the_beach_watching_all_the_other_thread_are_still_running(event_t event_name);
If both functions exist, it would be even better.

As Stian, and I said, there is an other way: cut the function into 3 function, the beginning, the interrup, the end. And of course, cut any function that need to read the adc in two too. Let'ts try to avoid this, please. Lingchi is a programming technic which leads the code to death.

In linux, there is "sleep" and "mutex"
In chibios there is "chThdSleep (systime_t time)" and chEvtWaitOne (eventmask_t mask)
In freeRTOS there is "vTaskDealy" and eventGroups
etc...

Maybe, there is just no solution, is it?

RE: AD7794 long delay

Susheel Nuguru — Tue, 14 Aug 2018 07:38:48 GMT

Hi,

I see atleast one deadlock scenario here. At the below line in your code

    //set the MISO line as input
    nrf_gpio_cfg_input(BSP_SPI_SD0, NRF_GPIO_PIN_NOPULL  );
    //wait fot the line to be down (! ! ! )
    while(nrf_gpio_pin_read(BSP_SPI_SD0)!=0);

You are assuming that your application will be active and able to catch the pin toggle to low in that while loop. But on a multi context system (when using softdevice or scheduler or any other RTOS) it is possible that some other context is running other than your app. I think this is what is happening in your application

1) you set MISO as input

2) wait for pin to go low.

3) something interrupts your app (softdevice or interrupt)

4) When something else is running other than your app, then the MISO pin toggles to 0 and toggles back to 1

5) your application gets control back from (softdevice or interrupt) and it has missed the toggle it waits for and sees that the pin is still at 1 and continues the while loop.

5) Since your app is stuck in this loop it is not sending read commands to the sensor and hence the MISO pin will not toggle anymore.

This is clearly a deadlock in your app.

You need to make sure that when your app is in the background and something else is running, then the pin toggle is captured somehow. It is wise to configure the pin to generate interrupt at this time when the pin goes low and then set a flag in the interrupt. You can wait for this flag in the while loop instead of waiting for pin to toggle. If you set the flag the the interrupt then you make sure that this toggle is not lost and captured as a flag value change in ISR.

RE: AD7794 long delay

Hugo — Mon, 13 Aug 2018 12:46:31 GMT

Hi,
The function is called by a app_timer (from app_timer_create), depending of the state of the bluetooth state machine(if connected, timer is on fast, if off, it's on slow). So the main tread, on the main loop just check the scheduler and low power the module.

    for (;;)
    {
        app_sched_execute();
        power_manage();
    }

For now, I use the timeout of the timer as interrupt, but the reading rate is just ok (5ms/measure so 33Hz).
On every scheduler I ever met, there was a function "delay" and "wait_for_event", and even on linux, there is mutexs, and and non-crashing "sleep" function for threads. That's all what I want :
-Or a way to create and wait for an event
-Or a way to wait for some specific time, but without limit but max value of an integer.
-Or both
And if they don't exist:
-whats the limit of time, for a function called on a timer, without any hulk risk, and why, and how to change it, if it's possible?

RE: AD7794 long delay

Stian Røed Hafskjold — Mon, 13 Aug 2018 12:15:29 GMT

If you want to wait quietly for something, the way to do it is to exit the function, return to idle, and wait for an interrupt. This interrupt could be the GPIOTE telling you SPI driver that data is ready, or an app_timer continuously polling the SPI lines. Blocking the main thread waiting in a for loop is generally not a good idea, so why it asserts is hard to say, it would require some debugging to know exactly why it fails.

If these sensor readings are something you do continuously, I would suggest to use the app_timer to trigger the reading instead of the scheduler. Also if the time it takes for the MISO line to go low after the command has been issued is somewhat deterministic (i.e. you can say that it is always less than 12ms) maybe it's better to hard code the waiting time using the app_timer and initiate a read sequence in the app_timer timeout interrupt.

RE: AD7794 long delay

Hugo — Wed, 08 Aug 2018 08:48:40 GMT

thanks for your answer.
I can do this but I must split my function at least into 2 parts. I don't like it.
look this is want to be able to do:

void my_lovely_function()
{
  uint32_t summer_temperature[6];
  uint8_t i;
  what_a_nice_day();
  I_love_summer();
  let_s_enable_temperature_sensors();
  let_s_wait_a_delay_to_stabilise_them();
  for(i=0;i<6;i++)
    summer_temperature[i]=check_ext_adc(i);
  switch_temperature_sensor_down();
  if(do_I want_to_send_this_temperature_by_bluetooth(summer_temperature))
    send_bt_data(summer_temperature);
  this_was_my_pleasure_to_deal_with_you();
  thanks_for_reading_all_this();
  return;
}

If I split "check_ext_adc", I still must wait for its result, which will still break the scheduler.
I can make some ugly stuffs, but I love code that I can understand without comment and chart.
What's the max time lengh of a function and why? How can I say in a function, "let's pause and wait quietly for something (time, event, whatever)"? what's the min time I should free the scheduler for it to be happy? (bluetooth connected).
Kind regards,

RE: AD7794 long delay

Stian Røed Hafskjold — Tue, 07 Aug 2018 13:55:09 GMT

Hi, sorry for the late response. Vacation time.. What if you do it like this:

Initialize SPI
Do the SPI write sequence
De-initialize SPI
Set up GPIOTE on the MISO line and trigger on falling edge.

Then in the GPIOTE event handler:

Initialize SPI again
Do the SPI read sequence

This will also be a more power efficient solution as the CPU is running in a while loop, and is not blocking other things from running.

RE: AD7794 long delay

Hugo — Mon, 16 Jul 2018 18:09:43 GMT

I found and wrote a very very ugly solution:
-I create an init function, which request a value to the AD7794
-I schedule a function that read the value, switch to the next one, and request it. Then just stop
I read the value every 4ms+wait for slave select. This is extra quite short, if it happens.

the good things are:
-I can read the 6 values and send a packet every 6 of them.
-I can be in power save during the wait (saving energy is important for me)
the bad things are:
-This is really ugly
-I can't just read a selected value when I want
-I can't schedule is as: "get the 6 values as fast as I can, then shout it on bluetooth", all this every n ms.
-if it happens that a value arrives like 8ms after request, the chip falls into a broken state.
-if I want to mix ready order, or add other sensor, it might be mind-blowing.

So I'm still interested to know the official way to do it

RE: AD7794 long delay

Hugo — Fri, 13 Jul 2018 11:45:04 GMT

Some precision, all is actually working with the softdevice, the problem is when it's called from scheduler timer.