Forum Rule: Always post complete source code & details to reproduce any issue!
Page 4 of 4 FirstFirst ... 2 3 4
Results 76 to 78 of 78

Thread: Multiple issues using TeensyThreads on T3.5. Dynamic heap allocation problems.

  1. #76
    Quote Originally Posted by joepasquariello View Post
    Good news. Thanks for letting us know. What was your timeslice before?
    I was using 5 ticks (5 ms) for the main thread and the comm thread. For the led blink thread I was using just one tick.

    I wasn't aware that the SPI and I2C communication was non-reentrant, so my reasoning for those short timeslices was that the user would feel more like it's three parallel threads on different cores, instead of three threads taking turns on just one core. Turns out the Teensy is so fast that even if I don't interrupt the thread to do context switching (using a very large timeslice) and only change context using yield or delay, most of the times the threads run for less than 5 ms each anyway. It only takes more time when one particularly slow task which which can't be split in smaller quicker tasks is being executed, like writing to the SSD1306 display via I2C.

    All the Teensies are still running without rebooting or crashing. I think we finally managed to solve the issue! I am very grateful for all the help received from this forum! Thanks!

  2. #77
    Quote Originally Posted by VictorFS View Post
    I was using 5 ticks (5 ms) for the main thread and the comm thread. For the led blink thread I was using just one tick.

    I wasn't aware that the SPI and I2C communication was non-reentrant, so my reasoning for those short timeslices was that the user would feel more like it's three parallel threads on different cores, instead of three threads taking turns on just one core. Turns out the Teensy is so fast that even if I don't interrupt the thread to do context switching (using a very large timeslice) and only change context using yield or delay, most of the times the threads run for less than 5 ms each anyway. It only takes more time when one particularly slow task which which can't be split in smaller quicker tasks is being executed, like writing to the SSD1306 display via I2C.

    All the Teensies are still running without rebooting or crashing. I think we finally managed to solve the issue! I am very grateful for all the help received from this forum! Thanks!
    That's great. By using a time-slice long enough that thread swaps occur only via thread.yield() and thread.delay(), you are avoiding preemption and using TeensyThreads as a cooperative RTOS. That means you don't have to worry about protecting calls to malloc. It should be okay for a thread switch to occur within i/o to I2C or UART as long as ISRs and other threads don't do i/o on the same device. For example, an I2C driver could yield() during a long operation such as waiting for an i/o operation to complete.

  3. #78
    Quote Originally Posted by joepasquariello View Post
    That's great. By using a time-slice long enough that thread swaps occur only via thread.yield() and thread.delay(), you are avoiding preemption and using TeensyThreads as a cooperative RTOS. That means you don't have to worry about protecting calls to malloc. It should be okay for a thread switch to occur within i/o to I2C or UART as long as ISRs and other threads don't do i/o on the same device. For example, an I2C driver could yield() during a long operation such as waiting for an i/o operation to complete.
    Yep, I think not only malloc(), but also the other shared resources I was protecting with locks such as Serial, EEPROM, SD and the command queue don't need to be protected anymore, as one thread always starts and concludes the operation before the other starts. I have checked my code and there are no threads.yield() or threads.delay() while using those resources, so there is no context switch and I think it will be fine.

    One more day has passed and no restarts or crashes

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •