С++, метод шаблонного класса как обработчик прерывания Опции

[_pv]

есть базовый класс, пусть будет уарта, которому через шаблон задаётся базовый адрес регистров и размер фифо.
template <int USARTx_BASE, int fifoSize = 32> class UartBase{
void ISRBase();
};

теперь делаем классы под каждый uart, так как немного разная инициализация (как минимум клоки включаются отдельно), и статический обработчик прерывания.

template <int fifoSize = 32> class Uart0 : UartBase<LPC_USART0_BASE, fifoSize>{
Uart0(){...}
static void ISR() { UartBase<LPC_USART0_BASE, fifoSize>::ISRBase(); }
};

вопрос1: как теперь сделать Uart0::ISR() обработчиком прерывания? с шаблоном-то тип у него тип теперь к размеру FIFO привязан.
void UART0_IRQHandler() { Uart0<?????????>::ISR(); }

кроме как убрать шаблон можно по другому это как-то по-человечески сделать?
class Uart0 : UartBase<LPC_USART0_BASE, UART0_FIFO_SIZE>

вопрос2: метод базового класса UartBase<LPC_USART0_BASE, fifoSize>::ISR(); тоже вызываться не хочет из статического метода.
error: cannot call member function 'void UartBase<USARTx_BASE, fifoSize>::ISR() [with int USARTx_BASE = 1074151424; int fifoSize = 32]' without object

наверняка не раз уже обсуждалось, но что-то сходу не нашлось, ткните как с однотипной периферией на плюсах правильно работать.

[sigmaN]

Статические методы в классе нужны крайне редко и практически всегда они имеют квалификатор "private", но исключение составляет, пожалуй, лишь паттерн "Singleton" с его методом ::getInstance().

Категорически с вами не соглашусь. Объединение группы методов под крышей одного типа позволяет очень эффективно решать ряд задач! Часто прямо на этапе компиляции.
Ознакомьтесь с http://easyelectronics.ru/rabota-s-portami...erov-na-si.html

А вот вам моя почти на 100% переработанная и допиленная реализация этой идеи.  neiverio_dxEdition_24_.zip ( 120.61 килобайт ) Кол-во скачиваний: 35
Там только для стм32 пока реализации нет, не дошли руки.
Да, это по сути куча функций, но в данном случае стэйт и инстансы нам и не нужны! И как результат имеем адсолютно отсутствующий оверхед и не отступаем от заветов объектно-ориентированного программирования. Таки пины пркерасно передаются как параметр шаблона куда угодно(в драйвер).. В прочем, всё это описано в оригинальной статье.

P.S.
#include "neiverio.hpp"
и прописать путь к папке с нужной реализацией GPIO (сейчас это AVR, XMEGA или STM8)

[Forger]

И как результат имеем адсолютно отсутствующий оверхед и не отступаем от заветов объектно-ориентированного программирования.

Оверхед, оверхед, оверхед...
Это напоминает автовладельца, которого беспокоит царапина на крыле его авто при том, что ее кузов уже напрочь прогнил
Если только и думать об этом мифическом оверхеде, то никогда не получится создавать действительно полноценный ООП-код.

А вот вам моя почти на 100% переработанная и допиленная реализация этой идеи.

~1Мбайт текста ... для портов I/O

Странно, у меня это все влезает в один файлик в 10кб текста (для одного МК). Мне даже как-то стыдно стало

[Сергей Борщ]

Странно, у меня это все влезает в один файлик в 10кб текста (для одного МК). Мне даже как-то стыдно стало

Да чего уж там стыдиться, показывайте. ваше "это все" можно передавать параметром в шаблон?