How to extend basic functionality of the MBED API?

[hesolium]

I need to generate a signal (PWM) with high frequency. The minimum (standard) period for PWM is 1 uS. How to modify the API to obtain a shorter period?
My board (Nucleo-F401/84 MHz) has the ability to generate a PWM with shorter periods.
Of course, I do not want to program the device (STM32 TIMx)) from the beginning.
I think a better solution would be a slight modification behaviour of the existing API.

For this purpose, I have modified HAL for STMF4 (pwmout_api.c) as follows:

1. I added and exposed additional variable 'short TIMadditionalPrescaler'
2. I added 3 lines in ''pwmout_period_us' function for conditionally increase the standard (1000000) prescaler for 1 uS period.
   In my application before call method 'period_us' I can set suitable value for TIMadditionalPrescaler.
   For example if I need 250 ns PWM period I can set my additional prescaler to 4.

In a similar (easy:) way, we can expand behavior AnalogIn class to add the ability to trigger the measurement via an external GPIO pin.

Now it's time for a general question.

How should we design an MBED API that such minor changes will be possible for the implementation for specific targets? Maybe definitions of each (PMW,AnalogIn, ...) class should contain some elements that enable smooth and easy implementation of additional functionality specific for some target boards. How it should be done from a theoretical point of view?

[dinau]

Just for reference , Erik Olieman's FastPWM.
https://developer.mbed.org/users/Sissors/code/FastPWM/

dinau

[hesolium]

@dinau:"FastPWM"

Oh, no. Build new class (e.g BetterAnalogIn, BetterPwmOut, ...) for every basic MBED class it is horrible solution. I know much better. For example we can add to every basic class new method:
'void *getHardwareDevice()'. This method should return pointer to C structure mapping device control registers (or NULL for standard, empty implementation). Having access to control registers, we can change behavior of the device at any time. Or maybe it would be better to add to each class new methods (attach/detach) like in Ticker class. There are many possibilities. I'm interested in how it should be done in accordance with C++ object design principles.

[hesolium]

I checked several design patterns, and I think that I found the right solution. I think the best is 'Extension Objects Pattern' (http://st.inf.tu-dresden.de/Lehre/WS06-07/dpf/gamma96.pdf). With this pattern, with each object (eg PwmOut) we can statically (or dynamically) tie additional object which provides fields / methods that modify the behavior of the basic object methods. This solution does not interfere with the existing API. We only need to add one method for each basic class: 'int registerExtension (ExtClass object)'.
In my example we can create new class PwmOutExt with one field 'additionalprescaler'. Create object of this class and register this object.

[ciarmcom]

ARM Internal Ref: IOTMORF-129