Sometimes when setting a channel callback the callback fires immediately,
even if the compare register is set to a value far into the future. This
happens when the free running counter has previously been equal to what
happens to be in the compare register.
This patch make sure that there is no pending interrupt when setting a
callback.
ExtInt, Timer and CAN IRQ callbacks are made to work with the scheduler.
They are still hard IRQs by default, but one can now call
micropython.schedule within the hard IRQ to schedule a soft callback.
It turns out that TIM1 and TIM8 have their own Capture/Compare
interrupt vector. For all of the other timers, the capture/compare
interrupt vector is the same as the update vector.
So we need to add handlers for these vectors and enable them
when using capture/compare callbacks.
During testing of this, I also found that passing a channel callback
into the channel constructor would not enable interrupts properly.
I tested using:
```
>>> pyb.Timer(1, freq=4).channel(1, pyb.Timer.OC_TOGGLE, callback=lambda t: print('.', end=''))
```
I tested the above with channels 1, 4, and 8
USB CDC no longer needs TIM3 (which was originally used for LED(4) PWM)
and so TIM3 has been freed for general purpose use by the user. Hence
LED(4) lost its PWM capabilities.
This patch reinstates the PWM capabilities using a semi-generic piece
of code which allows to configure a timer and PWM channel to use for any
LED. But the PWM capability is only configured if the LED is set to an
intensity between 1 and 254 (ie only when needed). In that case the
relevant timer is configured for PWM. It's up to the user to make sure
the timers are not used if PWM is active.
This patch also makes sure that PWM LEDs are turned off using standard
GPIO when calling led.off() or led.intensity(0), instead of just setting
the PWM counter to zero.
TIM3 is no longer used by USB CDC for triggering outgoing data, so we
can now make it available to the user.
PWM fading on LED(4) is now gone, but will be reinstated in a new way.
Previous to this patch the USB CDC driver used TIM3 to trigger the
sending of outgoing data over USB serial. This patch changes the
behaviour so that the USB SOF interrupt is used to trigger the processing
of the sending. This reduces latency and increases bandwidth of outgoing
data.
Thanks to Martin Fischer, aka @hoihu, for the idea and initial prototype.
See PR #1713.
The first argument to the type.make_new method is naturally a uPy type,
and all uses of this argument cast it directly to a pointer to a type
structure. So it makes sense to just have it a pointer to a type from
the very beginning (and a const pointer at that). This patch makes
such a change, and removes all unnecessary casting to/from mp_obj_t.
This is a hack to free up TIM3 so that it can be used by the user.
Instead we use the PVD irq to call the USB VCP polling function, and
trigger it from SysTick (so SysTick itself does not do any processing).
The feature is enabled for pyboard lite only, since it lacks timers.
Using SysTick to do the counting and dispatch of the flash storage idle
handler is more efficient than requiring a dedicated hardware timer.
No new counter is needed, just the existing uwTick variable. The
processing is not actually done in the SysTick IRQ, it is deferred to
the flash IRQ (which runs at lower priority).
py/mphal.h contains declarations for generic mp_hal_XXX functions, such
as stdio and delay/ticks, which ports should provide definitions for. A
port will also provide mphalport.h with further HAL declarations.
This allows the DAC to use a user-specified Timer for the triggering
(instead of the default Timer(6)), while still supporting original
behaviour.
Addresses issues #1129 and #1388.
Previous to this patch the printing mechanism was a bit of a tangled
mess. This patch attempts to consolidate printing into one interface.
All (non-debug) printing now uses the mp_print* family of functions,
mainly mp_printf. All these functions take an mp_print_t structure as
their first argument, and this structure defines the printing backend
through the "print_strn" function of said structure.
Printing from the uPy core can reach the platform-defined print code via
two paths: either through mp_sys_stdout_obj (defined pert port) in
conjunction with mp_stream_write; or through the mp_plat_print structure
which uses the MP_PLAT_PRINT_STRN macro to define how string are printed
on the platform. The former is only used when MICROPY_PY_IO is defined.
With this new scheme printing is generally more efficient (less layers
to go through, less arguments to pass), and, given an mp_print_t*
structure, one can call mp_print_str for efficiency instead of
mp_printf("%s", ...). Code size is also reduced by around 200 bytes on
Thumb2 archs.
In particular, make sure that the globals are all initialized
before enabling the interrupt, and also make sure that the timer
interrupt has been initialied before enabling the NVIC.
The function is modeled after traceback.print_exception(), but unbloated,
and put into existing module to save overhead on adding another module.
Compliant traceback.print_exception() is intended to be implemented in
micropython-lib in terms of sys.print_exception().
This change required refactoring mp_obj_print_exception() to take pfenv_t
interface arguments.
Addresses #751.
This patch enables output on the complimentary channels (TIMx_CHyN).
For timers 1 and 8, deadtime can also be inserted when the channels
transition. For the pyboard, TIM8_CH1/CH1N and TIM8_CH2/CH2N can
take advantage of this.
Found these by compiling stmhal with mp_uint_t of type uint32_t instead
of unsigned int. This actually makes a difference to the code, but just
a curiosity.
Timers now have the following new features:
- can init freq using floating point; eg tim.init(freq=0.1)
- tim.source_freq() added to get freq of timer clock source
- tim.freq() added to get/set freq
- print(tim) now prints freq
Eg pyb.freq(120000000) sets the CPU to 120MHz. The frequency can be set
at any point in the code, and can be changed as many times as you like.
Note that any active timers will need to be reconfigured after a freq
change.
Valid range is 24MHz to 168MHz (but not all freqs are supported). The
code maintains a 48MHz clock for the USB at all times and it's possible
to change the frequency at a USB REPL and keep the REPL alive (well,
most of the time it stays, sometimes it resets the USB for some reason).
Note that USB does not work with pyb.freq of 24MHz.
Teensy doesn't need to worry about overflows since all of
its timers are only 16-bit.
For PWM, the pulse width needs to be able to vary from 0..period+1
(pulse-width == period+1 corresponds to 100% PWM)
I couldn't test the 0xffffffff cases since we can't currently get a
period that big in python. With a prescaler of 0, that corresponds
to a freq of 0.039 (i.e. cycle every 25.56 seconds), and we can't
set that using freq or period.
I also tested both stmhal and teensy with floats disabled, which
required a few other code changes to compile.
Fix stmhal and teensy print routines to report actual prescaler an period.
Fix teensy build to use soft-float
Add USE_ARDUINO_TOOLCHAIN option to teensy build
This allows to set the pulse width (for PWM mode) as a ratio relative to
the period of the timer. Eg, 0.5 is a 50% duty cycle. You can set the
ratio in the channel init, or using channel.pulse_width_ratio; the
latter can also read the pulse width as a ratio.
Damien George