Почвам борба с STM32 и ми е малко мътна...
Основният проблем, е че няма да ползвам техните библиотечки. Целта е да се прехвърлят приложения от други куртекси, демек ще си пишем драйверчета и библиотечките на ST не ми вършат никаква работа.
Сега конкретно първия ми въпрос е за разликите между F1, F2 и F4. Още по-конкретно разликите в GPIO, UART, SPI, ADC и евентуално USB. Интересуваме за кои от тия периферии мога да мина с един драйвер за всички серии и за кои не. То е ясно, че ако изчета всички чаршафи и сам ще го разбера, ама нали е по-лесно да питам

Другия въпрос е за GPIO-та... по принцип нормално се прави дефиниция на един пин или група пинове от един порт. После тая дефиниция се подава като параметър на приложения/драйвери. В общия случай дефиницията е едно число, в което с битове се кодират кой порт, кой или кои пинове, дали да са входове/изходи дали да са пулъпи и т.н.
Хайде за gpio-та някак си ще стане, макар че ST са го направили малко неудобно, но поне ще стане. За функционалните пинове обаче са се осрали с тия мапинги. Нещо не мога да се сетя как от дефиниция на пин да сменям мапинга. А някъде май бях гледал разни С++ класове, но съм забравил къде и не мога да го намеря сега

Значи F1 си е първото поколение M3. Това им беше прощъпулника.

F2 е М3 на малко по-висока честота и с по-богата периферия (камера, USB OTG, второ DMA и пр.)

F4 e M4, а като периферия е почти идентично с F2.

Аз съм копал много на F1 и съвсем малко на F4. От това което аз съм пробвал, имаше някой разлики в GPIO - тата, мапинга е организиран по различен начин. Нещо ме гложди, че имаше и нещо около това как трябва да сетнеш един пин за да е вход на някаква периферия. При F1 трябваше да е просто GPIO вход, докато при F4 май изрично му казваш, че ще се ползва като линия към периферия. Като цяло мисля, че точно около GPIO-тата ще имаш съществен проблем да го направиш универсално за всичките серии.

ADC, UART и SPI не съм забелязал да имат разлики, евентуално ако има някоя допълнителна функция, с която аз не съм се сблъскал.

USB на F4 не съм пускал, но имам усещането, че модула има бая функционални разлики със F1 заради OTG-то.

Като цяло се съмнявам, че ще останеш очарован. Винаги, когато работя с тези контролери усещам, че периферията е мислена от хардуеристи. На мен поне много ми допада, от което си правя извода, че на теб няма да ти хареса.

Аз не съм правил нищо сериозно нито на F1, нито на F4, но съм си играл известно време с тях.
И за GPIO-тата мога да кажа , че са сходни , но се конфигурират по подобен - близък, но различен; начин:

F1: указваш директно какво ти трябва


F4

Първо указваш типа на I/O


отделно Open Drain / Push-Pull , ако е OUT или AF


и отделно дали ще е floating , pull-down, pull-up


Ето я и разликата , за която мисля Цецо говори м/у F1 и F4:
F1

Докато при F4 казваш, че е AF и после вече избираш какъв точно AF (там са изредени и входните AF, и изходните AF фунцкии).

А за USB-то Цецо също е прав, USB OTG-то на F4 се конфигурира различно спрямо F1/F2 ! Преправял съм пример за F1/F2 и ми се наложи да напиша цялата инициализация на OTG-то от нулата.

Успех ! Задачата, която си поставяш е голяма. Да унифицираш достъпа до перифериите на две различни ядра.
Според мен в крайна сметка ще изберете да си опростите задачата и ще си напишете едни драйвери за F1 и едни за F4, които отдолу ще работят различно, но ще ви дават унифициран метод за достъп .

Че не ми харесва не ми харесва, ама не мога да разбера защо обиждаш хардуеристите Не всички хардуеристи мислят като индианци
Както и да е, в случая за мен е важно работата да стане и да има пари, пък "очарованието" ще го оставя за един друг път...




Точно това смятаме да направим, аз и затова питам къде са разликите, за да знам как да си организирам драйверите. Имам разбивка по фамилия/серия и чип. Ако даден драйвер може да стане универсален го слагам на ниво фамилия и един за всички. Въпросът обаче е после да не се окаже после, че драйверът не е толкова универсален и да се налага да разбутвам сорсовете...

Абе и мен ме кефи. Най-вече това, че си има безкрайно много примери за всичко и дори да не разбираш как работи нещо в първия момент, един поглед в примера и веднага ти става ясно.

абе каква беше тази боза с мапингите?

Като гледам по дефаулт на 1 пин излизат много периферии. Демек ако не барам мапинги и почвам да включвам периферии ще стане страшно - конфликт между изходи и т.н.

Като им гледам сорсовете след ресет бичат една камара hex константи по мапингите. Предполагам са ги натамънили някак си тия констати, така че като почнат да включват перифериите да няма фал. Сега тоя вариант да се измуват всички мапинги в приложението звучи логично, ама мен не ме устройства, защото не се знае какво приложение ще се търкаля после и не мога предварително да кажа какви пинове къде ще трябват.

Мисля си за друг вариант - когато тръгна да включвам някаква периферия да й се подават пинове и за тия пинове да се програмират мапингите. Примерно включвам УАРТ с RX=пинХ и TX=pinY. Настройвам Мапинга за УАРТ-а така че да излиза на тия pinx/y, а останалите мапинги не ги барам.
Ша стане тъй нали? Притесняваме, че ще има конфликти с дефаулт стойности на други периферии, ама докато не съм включил други периферии не би трябвало да има грижи. А пък преди да включа друга периферия на нея ще й оправя мапинга...

Тури някакви маски кой пин се ползва от системата - за digital I/O или за периферия - все тая. И със заявки за заемане и за освобождаване на пина. Ако вече е заето - да връща грешка. Е, може и да назначиш някой цар да конфискува ресурсите, ако някой васал не си плаща. Иначе някой може да заеме пин и да забрави да го освободи.

според мен е добре да има един витруален дивайс 'pin maper', който да се занимава с конфигурацията на пиновете, колизии и т.н.
първо го инициализираш него, после отделните периферии.

така или иначе все повече чипове ще имат някакви варианти на мапване, така че такъв дивайс (част от ОС) ще е нужен. в чипове, които нямат мапване ще е 'винаги готов'

Така е на F1, нищо не ти пречи да сблъскаш изходи на периферии на един пин.

На F4, май точно това беше различно, там нямаше как да стане тоя фал, перифериите са наредени на мултиплексор с един изход. Вероятно не си първия, на който му се е видяло странно решението от F1.

Как да го организираш софтуерно това... незнам дали мога да ти дам разумен съвет. Аз никога не съм правил нещо, на което отначало да не знам кое къде ще е мапнато. Аз винаги си имам една процедура InitPins() и после не ме интерсува повече мапинга. Докато твойто му трябва интелигентност някаква...

Проблемът не е в раздаването и следенето кой какво иска да ползва...

Просто при всички (изключая STM32 F1xxx) един пин може да се конфигурира за дадена периферия и не е нужно да се следи дали е бил ползван от друга. Сменяш му мултиплексора и толкоз.
Примерно ние имаме бутстрап, който е писан преди бая години. Той тръгва, конфигурира си 2-3 UART-а, слухти 100-на милисекунди и ако никой не полира, стартира истинското приложение. През годините обаче се навъдиха много платки, като не всички имат конектори точно на тези UART-и. Съответно някои от пиновете дето не се ползват за UART може да се ползват за друго. Но в общия случай няма конфликти, затова и не бараме бутстрапа. Нищо, че той временно конфигурира някой пин, като тръгне същинския софтуер той си преконфигурира каквото му трябва...
Те при такива ситуации с Ф1 може да има проблем, в смисъл ако бутстрапа е пуснал изход на някой пин, пък после приложението иска пак изход, ама не на УАРТ ами SPI или нещо друго...

Както и да е, Ф1, май няма изобщо да го ползваме, а при останалите тая каша с мултиплесирането са я замазали...

Между другото не виждам power control. Има спиране на клока, има и ресет на периферията, но няма шалтер?

шалтер в смисъл?

шалтер в смисъл да гаси тока...
като няма ток, периферията не е захранена.

Иначе спирането на клока пак намаля консумацията, ама си помни състоянието...

Ами имаш Sleep/Stop/StandBy режими. Последния гаси и вътрешния регулатор и всичко умира.

стр. 64 от юзер мануала на F1. На F4 толкова дълбоко не съм копал.

ти говориш за централния шалтер
При другиге производители има шалтер за всяка периферия. На мен не ми трябва, просто на всяка периферия си дефинирам едно число, което определя кой бит (в случая на RCC регистрите) трябва да ползвам за да захраня /клокна или ресетна въпросната периферия. За целта ми е важно позицията на бита да е една и съща при всички операции/регистри.
Нали ще пиша драйвери та гледам дали ще стане всичко само с един параметър...

Още едно чудене... Гледам за клоковете ползват магьосници. Тва не ме кефи много, дали някъде някой не е написал функцийка, която да й дадеш с параметър каква честота искаш и тя да включва/изключва PLL-и и каквото е нужно?

не е толкова важно, ама ще ми спести доста чесане по тиквата

описанието на всяка периферия започва с точка x.x.1 Enabling XXXXX, в която се описва кой/кои битове на съответния регистър трябва да се сетне, за да запали съответнната периферия. Някои периферии са по-особени (DAC примерно), при който отделно се пали DAC-а, отделно изходния буфер.

в електрическите параметри, в секцията Power consumption има табличка коя периферия колко милиампера харчи. общо взето обаче тия чипове не са за ниска консумация. ядрото харчи 3 до 5 оъти повече от всичките периферии накуп. което не значи, че по някакви (теологични) причини не трябва да се гасят