Closed NathanKuo0821 closed 2 years ago
There's also a fundamental bug in
getTimerUpIrq
in regards to detecting which timers exist and returning the interrupt based on that, it uses a#ifdef
on aenum
type value... gotta fix those.
Yes, commenting out && defined(TIMER2_IRQn)
in timer.c fixed the problem.
This is my code (very simple):
HardwareTimer Timer_0(TIMER2);
static volatile bool state = false;
void setup_hardwaretimer(void)
{
pinMode(LED, OUTPUT);
Timer_0.setPeriodTime(500, FORMAT_MS);
Timer_0.attachInterrupt(periodcallback);
Timer_0.start();
}
void loop_hardwaretimer(void)
{
}
void periodcallback(void)
{
digitalWrite(LED, state ? HIGH : LOW);
state = !state;
}
If I switch HardwareTimer Timer_0(TIMER2)
to HardwareTimer Timer_0(TIMER0)
the above example no longer works.
Are you using the very latest Arduino core code from this repo?
Could update again to see if 8fd01ef fixes the issue? You should be using code like https://github.com/CommunityGD32Cores/gd32-pio-projects/blob/main/gd32-arduino-pwm-out/src/main.cpp together with a PWM enabled pin as listed in e.g. https://github.com/CommunityGD32Cores/ArduinoCore-GD32/blob/main/variants/GD32E230F8_GENERIC/PeripheralPins.c#L130-L148
PWM confirmed as working. I have an LED on PB1
which is a pin linked to a timer. By varying the period and duty cycle I can dim the LED by directly driving it, without the captureCompareCallback
attached.
Also tried with the PWM on PA6
and the captureCompareCallback
attached. That works as well.
Are you using the very latest Arduino core code from this repo?
I am, yes.
Timer0 is special with TIMER0_BRK_UP_TRG_COM_IRQn
interrupt that isn't yet correctly handled, let me try a fix.
https://github.com/CommunityGD32Cores/ArduinoCore-GD32/commit/f8dd8513288813c11716b0861b08eec594947b2d tries to fix this, can you retest?
I have been waiting for GD32E230C to support Arduino , Is there a plan to support? schedule? Very thanks.