[SOLVED] Enable interrupts from inside a timer interrupt

I need another timer to fire

hard to tell what you meant by “fire”.

CMx chips allow priority / subpriority over its interrupts so take a look at the datasheet to see how that can be set-up – the ISRs are re-entrant.

another feature is interrupt-chaining (potentially what you are trying to do), whereby a pending ISR can be executed without the exiting the current ISR, reducing ISR latency.

With that said, generally you don’t need something this fancy so your “problem” potentially has a solution vastly different from your current approach.

By fire I mean when the timer time elapses and calls the interrupt method.
Is not fully re entrant what I want to do as you mention really is interrupt-chaining, since I want Timer B to be called even when Timer A has not finished.

I wish there was a simpler solution but predictable I need to disable the OE at a particular time (just set the output to high), Timer A is executing a bunch of high perf code to build the next frame, so it can’t stop to check if the elapse time to disable the OE is done, basically the check would have to be done at every line and consume more CPU than the code to build the next frame. Also Timer B for the OE has to be started only once the matrix data has been latched, so the Timer B has to start from Timer A interrupt.

As dannyf said different interrupts have different priorities. Check the datasheet to see which of the timers have higher priority, and that one should be able to “fire” within the other one.

Thank you!!!
Setting the priorities did the job.

nvic_irq_set_priority(NVIC_TIMER2, 15);
nvic_irq_set_priority(NVIC_TIMER3, 0);

I’m not convinced yet that you need something that fancy.

the first question should be if the OE pin can be enabled in the middle of a frame transmission. if yes, you can simply drive it with a pwm pin. 0-100% duty cycle.

if the OE pin can only be enabled at the end of a frame transmission, your ISR flow should be like this:

timerA isr:
[optional]disable the OE pin;
transmit the frame; //assuming it is short
enable the OE pin;
enable timerB; //can be done with 1 instruction
exit;

The code that you put in there is almost identical to what I use with two timers, however I’m driving the the matrix on BCM and not on PWM for the tones so before I resume the timerB, on timerA isr I need to set a specific time on timerB since the time to be the OE is dependent of the weight of the bit column that is been process at that time, since I have 16 tones per color, the OE time is enabled in multiple of 2 4 times.

When brightness is at 15 latency is not an issue since, the OE enabled times are 16µs, 32µs, 64µs, 128µs for the 4 bits however definitely latency is an issue when the brightness is at 0 since for the 4 bits I need to enable bit 0 for 1µs, bit 1 for 2µs, bit 2 for 4µs and bit 3 for 8µs, the timerB handler for the bit 0 lags about 700ns so ends up with a pulse of 1.7µs instead 1µs. then when brightness is at 0 colors tones 1, 3, 5, 7, 9, 11, 13, 15 won’t render perfectly but can’t really be noticed.

I thought about driving the OE with PWM however I was afraid (theory) that the display will display artifacts if when OE is enabled/disabled during latching and was looking for something more predictable.

However for testing I’ll try to drive OE with PWM only after latch completed and before the previous frame starts, if that works I don’t need timerB

I uploaded a video to show the current progress of the brightness control, here I set the brightness to zero and the 700ns ISR lag make odd numbers slightly “brighter” when brightness is zero, isn’t noticeable at all however I’ll try to use PWM to control OE

RGB animated matrix
viewtopic.php?f=19&t=3104

.

for indoor applications, duty cycle of 0.1% or lower is indistinguishable from dark, even if high brightness LEDs are involved. that percentage is higher for outdoor applications.

so if you are refreshing your display at 100Hz (way higher than necessary), the minimum on cycle you need to hit is 0.1% * 10ms = 10us. On a 72Mhz mcu, that translates into 720 ticks. shouldn’t be a problem.

if it is, there are other ways to address the minimum dc issue.

I rerouted some pins so OE ends up on a PWM pin, I did a basic test and PWM runs by default at 1Khz which is no even close enough what I need, the matrix produce a huge flickering artifact barely it can be distinguish the content of the animation, I need to run the PWM at least 1000 times faster.

In the case of the RGB matrix and BCM I need to run at least at 200hz refresh rate or artifacts start to present, this is better described here
http://www.batsocks.co.uk/readme/art_bcm_1.htm

The time slice for bit 0 is just 15μs, if I run continuous PWM on OE without care of sync with latch then I would need at least 10 pulses of PWM for every bit to avoid artifacts which would translate on a 1μs period or 1Mhz PWM.

How do I change the default PWM frequency of 1Khz? On Arduino seems to be with setPwmFrequency() however seems this function is not available on STM32.

Another way would be to sync enabling the PWM on the beginning of every bit when the bit latch then I would need fewer PWM pulses since duty cycles will be fair for all bits however the default 1Khz is not even close for that either.

In the image you can see
D: is a whole frame (250Hz)
OE: running PWM at 1Khz (which a single period is taking what it takes 4 pixels to render)
Latch: Is when the data of every bit is send to the matrix, there is a zoom for bit 0 that takes 15μs, if I want PWM to work I need to fit at least 10 PWM OE pulses in there or fewer pulses if I can synchronize with the latch going low.

By the way I’m running the blue pill overclocked at 128Mhz.

Well, I cannot see why you would anyway need BCM, that’s just PWM with repeatedly variable duty cycle.
IMO, this is equivalent to a “normal” PWM with constant duty cycle, wherein you have to keep the total low/high pulse ratio within a BCM period.
What also important, I think, it is the highest allowable OFF cycle to avoid flickering, which would be ~= the total period of a BCD train.

When you talk about 200Kz, what exactly is this referring to? To the period of one pulse or the total period of a BCM train?

The F103 timer PWM is very powerful, capable to set up in very different ways. You could also do some sync with other pulses when needed.
Do you have a plot showing how exactly your signals should look like? If possible with periods on it?

I need to run the PWM at least 1000 times faster.

It is certainly possible to run the pwm module at 1Mhz.

But when your requirement becomes that extreme for such a simple task, you may want to re-examine your approach, both software and hardware.

Case in point. Ppm is often used as a software implementation of pwm, when the hardware isn’t available. It is not intuitive to implement ppm through a pwm hardware module.

There is also the option to feed a timer from another timer.
I don’t remember all the details, the datasheet shows what it can do, but perhaps that can remove the need to have 2 ISRs completely and leave only 1.
I think that one of the modes is to enable the second timer to count once the first time reach a certain count, which I understand is more or less what you are trying to do with the 2 timers and the ISR.

I’m not sure when I talked about 200Khz?, only thing I mentioned was that I want to keep the refresh rate above 200Hz.

Still didn’t get any hint how to change the PWM frequency. Do you know how?

Current approach with two timers works fine, and blue pill only take care of rendering so the current approach is good enough, however when brightness is at minimum the isr introduce a 700ns latency which isn’t big deal.

However I keep looking for alternatives, if I can drive PWM at 1Mhz I may not need the secobd timer however from what I read PWM uses a timer as well, so is not that I’m saving a lot other than some code.

Anyway… anything is on the table to change,

How do I change the pwm frecuency?

Thanks!!

Still didn’t get any hint how to change the PWM frequency. Do you know how?
viewtopic.php?f=19&t=3037#p39304
viewtopic.php?f=19&t=3037&start=10#p39347

Handling the OE with PWM works great, as long I keep the PWM above 400Khz it doesn’t produce any artifact for lower tones since even bit 0 which is the shortest will have up to 8 pulses and I don’t need to synchronize with the latching, the reality in my testing I could go down to 200Khz before I started to see some evidence that tones are changing specially when I put a gradient test screen, so I bumped PWM to 400Khz and is rock solid, definitely now with PWM I have a much accurate control of the brightness than ISR chained event.

Thanks!!!!!

By the way now I know where the pink pins info is used in the image
However still I don’t have clear for example, PWM on PB0 is controlled by T3C4 (Timer3 Channel 4) but what means T1C3N next to it???

I uploaded a video to youtube to show how smooth is now the steps in control of the brightness with OE and PWM, the phone I have seems to be really good a low light so in the video can’t be appreciated but there is a huge difference between brightness (0) and (15).

After playing the video several times during second 3 and 4 I see some artifacts that can’t be seeing with the naked eye but on the video looks like some pixel ghosting, I did not have that before, I wonder if the PWM frequency is the problem since is not synchronized with the latching, I’ll see if increment the PWM to 1.28Mhz have the same issue.

On further testing I confirmed what I was afraid, “unsynchronized” PWM on OE brings undesirable artifacts to the display, I bumped the PWM frequency from 400Mhz to 1.2Mhz and is barely noticeable however the artifacts are still there as you can see in the image below with and without PWM.

I would bet anything that is because the PWM is not synchronized with the latch so the OE is going low and enable the display while the data is still feed into the shift register.

Well… going back to the drawing board

My guts tells me if I synchronize the OE PWM start/stop with the latch this problem will go away, also synchronizing will make the number of pulses constants when the display is visible so I suspect that just lowering to 200Khz (about 4 pulses for bit 0) will be more than enough since now the duty cycle will be the fair and same for every bit, it would require some extra lines of code as it did with the 2 ISR timer chained events, however I think it will work.

There is also the option to feed a timer from another timer.

having the master to trigger to slave; or running the slave in single pulse mode….

what means T1C3N next to it???

negative.

Synchronizing the OE with the latching works like a dream and there is no artifact problem at any brightness level and I can go as low as 300Khz for the PWM without any problem. At this point I can’t be happier and don’t think I’ll make any more changes on the display brightness.

Steve wrote,
“Well, I cannot see why you would anyway need BCM, that’s just PWM with repeatedly variable duty cycle.”

From what I researched with BCM I need way fewer instructions to display a frame with 128×32 at 16 tones achieving much higher refresh rate of at least 250Hz.

Currently the main loop to display a frame is basically; cycle for the instructions I put below with barely any extra processing.
Based my work from the explanation http://www.batsocks.co.uk/readme/art_bcm_1.htm however the implementation was initially the Adafruit RGB matrix driver implementation that I heavily end up modifying..

Instructions to create a frame:
(1 x reset PWM OE) + (1 x set latch) + (1 x Row Address = “2 rows per instruction”) + (128 x clock set) (1 x R1G1B1&R2B2G2 data “6 colors set per instruction”) + (128 x clock reset) + (1 x set PWM OE)) x 4 bits x 16 rows = 16704 instructions per frame

so with 16704 instructions I can display a whole RGB frame on the matrix, may be possible but honestly down know how to make it happen with PWM instead BCM.

I would gladly tell you how to set the PWM but I have no idea about your requirements, about the relationship between PWM frequency, refresh rate, display resolution, and about all the required signals (and the synchronization among them) in general.