You probably read those threads and (because you know all this stuff inside out, and you know who’s who) you know which posts to pay most attention to. For me, I just see a load of posts with some people saying “yeah that should be possible” and other people saying “no you can’t”. Imagine you’re new to all this for a moment!
You are absolutely right, but you should also see it from my point of view. I can be very helpful to people who want to realize a HW and/or SW project and share it with the community. I’m especially willing to give them the right hints at the beginning before they are starting with an approach which won’t be flexible and powerful enough at the end. I’m just a little bit bored from people who expect that a ready made and perfectly working solution is available, so that they only need to tweak on some parameters (like “number of LEDs”, “PWM resolution”) w/o spending some own thoughts on the topic (or document their findings in the Wiki).
You are not one of those guys (thanks for pro-actively starting a FAQ!), this was hard to estimate after your first posting. Therefore some more infos.
It depends on your design targets, which approach fits your needs.
E.g. you can easily generate PWM with the common MIOS approach (updating a SRIO chain each mS in background of the main application), but experiments have shown, that this doesn’t work flicker-free with more than 3bit resolution.
And than more LEDs should be PWM controlled, than higher the CPU load, than less tasks can be handled in parallel.
For 24 LEDs it should work, but only at 3bit resolution - this doesn’t fit your requirements, and I know that 7bit is important for your plans, therefore simple answer: it does not work this way.
Another solution could be to control the DOUTs in a seperate chain with higher update rate. E.g., in previous (pre-MIOS) projects I used MBHP_CORE:J7 as alternative port for independently controlled DOUTs
The usage of this port is not natively supported by MIOS (there are too different usage models), but it’s easy to control it from the application.
Problem here: you might be able to increase the update rate by factor 2 or 4 (250 uS), but by doing so, there wouldn’t be enough compute power anymore for handling 24 encoders in parallel without loosing “ticks”.
So - this solution works for people who only want to fade 24 LEDs, but it doesn’t work for your intentions.
Next possibility: instead of using a background timer, just control the LEDs in the main task (MIOS: USER_Tick).
Thats basically the same approach like known from most Adruino projects.
Pro: very straightfoward approach, easy to understand, easy implementation.
Con: you will run into troubles once multiple tasks have to be handled in parallel. E.g., receiving and parsing incoming MIDI data, reacting on asynchronous events e.g. rotary encoder movements or high MIDI traffic, outputing LCD messages, etc…
Easy to understand effect: with such a straightforward approach, LEDs would flicker. I don’t think that this is acceptable from your side. 
Concepts need to be changed once “multitasking” is required. And these are the concepts which went into MIOS. They make the implementation a bit more complicated, maybe also a bit more expensive (if additional HW components have to be added), but at the end it gives you more flexibility and a certain guarantee, that your project won’t end into a half-working tinkering solution with a lot of compromisses.
So, what to do: you could simply “outsource” the PWM task to a “slave” PIC, controlling the DOUT chain and waiting for “commands” from the “master” PIC. The master could send LED brightness in form of MIDI events to the slave, or it could be connected to the IIC bus as known from MBHP_IIC_MIDI and MBHP_IIC_SPEAKJET (in such a case, you could also use an inexpensive low-cost PIC derivative)
If the maximum PWM update frequency for handling 24 LEDs from a single PIC is not sufficient, just use two or three PIC16F88, and control them all from the master core.
Another advantage: serial registers (74HC595) are not required anymore. Just connect LEDs directly to the IO pins.
This probably also saves you from using LED drivers.
Disadvantage: more programming skills are required, and everybody who wants to recreate the project needs a PIC burner to program the firmware into the PIC16F88
So - at the end I came to the conclusion, that the easiest and most powerful way for generating high-resolution PWM is the usage of ready made PWM chips.
TLC5940 is a good choice btw.
Too bad, that this topic is continued in another thread. I really hope that users starting to collect more implementation details in the Wiki so that the final conclusions won’t get lost
Best Regards, Thorsten.
Thanks!!