Forum Rule: Always post complete source code & details to reproduce any issue!
Page 16 of 16 FirstFirst ... 6 14 15 16
Results 376 to 379 of 379

Thread: Teensy 3.x multithreading library first release

  1. #376
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Portland, OR
    Is it possible to set a thread priority using this library, such that a higher priority thread will preempt a lower priority thread?

  2. #377
    Senior Member
    Join Date
    Jul 2014
    New York
    Me again Brian.

    Been digging into c++ threads again for another project and I don't think c++11 or c++14 implements a setPriority command, so I doubt that TeensyThreads does it either. I think it is supported in Windows or Linux implementations of threads. So unless fritas implements in his library don't think the current version has a command to setPriority.

  3. #378
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    I didn't see it in my following - github doesn't address Priority - except first lock blocked item will be called next.

    Adding selectivity to time order queueing would really impact overhead of what seems to be a simple thread switcher.

  4. #379
    Junior Member
    Join Date
    Aug 2018
    I just wanted to say thanks for this library. It's solved a problem with my POV wheel project. You see, It's spinning about 900rpm (planning to go faster), and has 32 APA102 leds divided up into 360 segments per rotation. I was struggling with too much CPU use during the "render" phase, that was causing skips of some of the output segments. Even overclocked to 120, 144 or 168Mhz wasn't enough. I'm using a simple double-buffer. Rendering to one one buffer while the other is read for outputs to the LEDs. Some of the animations and graphics I'm rendering at about 5fps needed more CPU cycles than I had to spare between segment outputs. I was doing every trick in the book to speed up the rendering, like having a ATAN, SIN and COS lookup table. A lookup table for converstion of a polar coord to a cartsean coord. That sort of thing. I was even starting to plan out my own "half-assed" threading scheme. All I needed was to break up the rendering phase into chunks until it was done, then flip the buffer. After lots of failed "Arduino" searches, I found this thread.. and Voila!! I can take as long as I need on my rendering thread now, and almost no impact on the output thread at all. I even removed the COS and SIN lookup tables and everything is working perfectly.

    I still have couple of math precision issues to work out, and the fact that I have to be sure to leave enough clock-ticks for the FastLED library to send it's output. But, other than that, it's looking good!!

Posting Permissions

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