Есть такая штука CMSIS - библиотека стандартизировнная, организует средний уровень, как я понимаю. А вроде как находил инфу, что она поддерживает семейство LPC23xx, но больше какой-либо вменяемой инфы я на сайте NXP не могу найти. Может есть альтернативы?

Конечно есть. Забыть про этот CMSIS и программировать регистры МК напрямую, периодически заглядывая в руководство. Кстати, ничего страшного в этом нет.

Официально CMSIS существует только для серии Cortex-M, но есть реализация для 23xx от команды mbed.

Ага отличное решение, так и делаю и такой подход прекрасно запутвает код, мне нужна корректная абстракция. Надоело переписывать код то под один УАРТ, то по под другой, та же история с таймерами, и прочей перефирией. Я разделил как мог на модули, и путаница просто в каждом модуле, но это меня не устраивает.

2 scifi Ваша ссылка ведет в никуда =(. Но будем искать

Ссылка от igorsk рабочая.

А что, этот самый CMSIS содержит драйверы UART, таймеров и проч., к тому же совместимые по API между разными МК? Моё не очень компетентное мнение: это утопия.
При наличии некоторого опыта можно придумать свой минимальный достаточный API и все свои драйверы заточить под него.

Прошу прощения перепутал ники, а ссылка не завилась - инет корявый.

Почему утопия как раз я и хочу получить API на семейство(оно ведь довольно популярное), может этот минимильные API уже кто-то сделал. Не хочется изобретать велосипед, потому как я боюсь в этом закопатся.

Но гипотетически я все же склонен написать такую штукую. Проблема в том, что я не знаю в какую сторону смотреть: реализовывать это на классах(я больше прикладник), или на структурах и фнукциях. Может кто предложить вменяемую архитектуру исходя из своего опыта?

API должно быть заточено под применения. Нужно выбирать баланс между объёмом функционала и простотой реализации.
К примеру, для UART возможны функции: init(всякое-разное или пусто), setrate(rate), getrate(), putchar(byte), getchar(), gettxbuf() - свободное место в буфере, getrxbuf() - число принятых, но не считанных байтов. Все эти функции, кроме init(), могут не менять интерфейс при переходе на другой МК. Конфигурировать (размеры буферов, к примеру) можно макросами. Кроме того, во многих применениях setrate() и getrate() не нужны.
С таймером тоже надо смотреть на применения. Простой небыстрый периодический таймер может иметь всего две функции: init(), poll() - возвращает !0, если был очередной тик.
Ну а классы - это избыточность, на мой взгляд. Хотя признаюсь, у меня на C++ аллергия :-)

Я собственно для каждого класса переферии думаю использовать структуру с набором полей соотвествующих адресам регистров, а ее отображать на задефайненный базовый адрес переферии. соотвественно гипотетический интерефейс функций Read и Send uart



ну вот гляжу доку на этот mbed оч занималтельно наглядно и красиво +)))) но на классах
Я классы остерегаюсь применять - боюсь производительность потерять, но очень хочется. Хотя описанный мной подход не сильно отличаетсяот ООП подхода.

Я так понимаю, это вариант реализации драйвера UART с поддержкой нескольих каналов. Можно и так, вполне симпатично. Только ещё нужно обыграть буферы (у каждого канала свой и, возможно, разных размеров). Так что может оказаться, что без номера канала не обойтись.


Вполне симпатичное API.


В моём понимании тут ООП и не пахнет. ООП - это виртуальные функции, всякие хитрые наследования и т.д. В этом применении это всё, естественно, не нужно. Можно разве что из соображений единообразия с остальной программой классы прикрутить.
А по поводу производительность волноваться раньше времени очень вредно. Так как проблема скорее всего надуманная, а вот головная боль и потерянное время будут настоящими. Сначала запустите программу. Если будет тормозить, то оптимизируйте. Иначе это пустая трата времени.

ну собственно в mbed все в таком виде и построенно, правда не удается собрать с ним проект под кейл 4 ругается на скатер файл

D:\mbed\LPC2368\LPC2368.sct(4): error: L6235E: More than one section matches selector - cannot all be FIRST/LAST.




даже не знаю куда копать

Возможно, две секции отмечены как First. Секция может быть отмечена как First в ассемблеровских исходниках и в командной строке линкера. Вот там и нужно искать дублирование.

http://mbed.org/forum/mbed/topic/518/?page=1#comment-9113

Там в теме есть проект под кейл, но под 1768 пытался его перенастроить под 2368 опять ругается на 6235E: More than one section matches selector - cannot all be FIRST/LAST.

Если выкинуть скаттер то ругается что не описанна секция. Ктонибудь может объяснить что вобще эти строчки значат?



ЗЫ в проекте нет стартап файла *.s

CMSIS это жесть такая. Выкинуть его и дело с концом.