Multiple threads with nRF9160

Hi, 

I have a project with 3 threads running on a nRF9160.  I am using nRF Connect SDK v1.8.0.  Basically I borrowed the code from "mqtt_simple", "location" and "threads".  One of my threads is running "location" with priority of 3.  Another thread is running "mqtt_simple" with priority of 2.  The 3rd thread is reading an accelerometer through SPI with priority of 1.  All 3 threads run correctly when running by itself alone.  Then I have the "location" and "mqtt_simple" thread running together without any problem.  I also have the "location" and the accelerometer thread running together without any problem.  However, when I have the "mqtt_simple" and the accelerometer thread running together, the SPI reading is correct before mqtt client is connected.  But as soon as mqtt client is connected, all SPI readings become wrong. Same problem when I have all 3 threads running together.  Has anyone have problems running multiple threads together, especially with SPI?

Looking at the log messages.  It seems everything is fine upto calling the mqtt broker_init function.  As soon as the IPv4 address is found, then all SPI readings become 0.

Thank you,

Floyd

Parents
  • Hi Einarh,

    Here is my SPI funtion.

    static void spi_send(void)
    {
    gpio_pin_set(dev, spi_cs, 0);
    spi_transceive(spi_dev, &spi_cfg, &tx, &rx);
    gpio_pin_set(dev, spi_cs, 1);
    }

    spi_cs is just i/o pin P0.08.  And in my prj.conf I have

    CONFIG_SPI=y

    So basically I have a while loop calling the spi_send to read the accelerometer continuously.  I need to determine if a sudden change has occurred and respond immediately.  I could potentially read from a FIFO based on an interrupt.  But I am afriad that might mess up my timing.

    Regards,

    Floyd

  • Right, so if I understand this correctly, you send a message requesting gyro data, then wait for an immediate answer correct?

    In that case I would definitely set up an interrupt instead.

    I suspect your timing is getting messed up because you don't have an interrupt.

    Your program is probably busy with the networking thread while you want it to receive gyro data, which wouldn't be a problem if your SPI code was interrupt based.

    -Einar

Reply
  • Right, so if I understand this correctly, you send a message requesting gyro data, then wait for an immediate answer correct?

    In that case I would definitely set up an interrupt instead.

    I suspect your timing is getting messed up because you don't have an interrupt.

    Your program is probably busy with the networking thread while you want it to receive gyro data, which wouldn't be a problem if your SPI code was interrupt based.

    -Einar

Children
Related