STM32 новичку в ARM что к чему

[AVI-crak]

Ну на 16 отдельных линий есно больше получится. Но я точно уверен, что не допущу ошибок и смогу понять код даже через год.
Например такой:

Код: Выделить всё

        gpio_one_pin(zap_gpio.C.pin04.out.speed3.lock_on);                         /// st7735_com
    gpio_one_pin(zap_gpio.C.pin05.out.speed3.lock_on);                         /// st7735_reset
    gpio_one_pin(zap_gpio.A.pin04.v_af05_i2s1_ws_spi1_nss.speed3.lock_on);     /// spi1_NSS
    gpio_one_pin(zap_gpio.A.pin05.v_af05_i2s1_ck_spi1_sck.speed3.lock_on);     /// spi1_scl
    gpio_one_pin(zap_gpio.A.pin07.v_af05_i2s1_sd_spi1_mosi.speed3.lock_on);    /// spi1_mi

Более того, портировать код на другой мк получится ещё быстрее, в среднем за 15 минут.

[a5021]

[uquote="Reflector",url="/forum/viewtopic.php?p=3905297#p3905297"][uquote="a5021",url="/forum/viewtopic.php?p=3905294#p3905294"]Как-бы дофига, если сравнивать с тем, что у меня[/uquote]
У него F7, считай что таким образом один AFR проинитил...[/uquote]
AFR -- два слова, требует четырех команд. Остальные регистры однословные и потребуется, где две, где три команды. Максимально это 15-16 команд на порт. Один фиг, в разы. Плюс нет вызовов и какого-то дополнительного стороннего кода. И быстрее и компактней.

[AVI-crak]

[uquote="a5021",url="/forum/viewtopic.php?p=3905301#p3905301"]Максимально это 15-16 команд на порт.[/uquote]
Да причём тут весь порт? У меня функция для инициализации одного контакта - универсальная, весом 212 байт. Именно столько она занимает в прошивке.
Когда я говорю что невозможно допустить ошибку - я имею в виду именно этот факт (там просто нет других вариантов).

[Oxford]

капец. это ты все ноги описал. Ремап тоже прописал?
А конфигурируешь чип в CubeMX? И потом уже смотришь ноги и программируешь?

[VladislavS]

[uquote="AVI-crak",url="/forum/viewtopic.php?p=3905272#p3905272"]

Код: Выделить всё

20001D2C	ldr	r0, [pc, #524]	; (0x20001f3c <SystemInit+1480>)
20001D2E	blx	r4

[/uquote]Таки я оказался прав. Загрузка константы и вызов функции.

[uquote="AVI-crak",url="/forum/viewtopic.php?p=3905272#p3905272"]Сама функция zap_gpio_one_pin() весит 212 байт, и является частью многократно вложенного макроса.[/uquote]Вы сделали достаточно сложную работу по расчёту константы на этапе компиляции. Осталось функцию, объединяющую всё это по портам, туда же увести и будет зачётно.

ЗЫ: Кстати, куб ведь по каждому чипу подобную базу имеет. Он в графическом интерфейсе по каждому пину все допустимые варианты показывает. Наверняка оттуда дёрнуть можно.

Добавлено after 33 minutes 50 seconds:
[uquote="AVI-crak",url="/forum/viewtopic.php?p=3905299#p3905299"]Но я точно уверен, что не допущу ошибок[/uquote]Да, такой ценой, но цель достигнута. Хейтеров не слушайте, они в паре битов ошибаются.

Добавлено after 57 minutes 45 seconds:
[uquote="AVI-crak",url="/forum/viewtopic.php?p=3905286#p3905286"]GCC очень оптимизированный язык.[/uquote]Боюсь спросить, а на чём-то кроме GCC это собирается?

[Oxford]

VladislavS по факту этого ничего не нужно. Достаточно cmsis и си. но ты можешь дальше стряпать либы

[VladislavS]

Oxford, аргументация есть или кто последний сказал тот и прав?

[Oxford]

А какая аргументация нужна? Периферию и порты я и так настрою без либушек, периферия никуда не скачет. Я раз настрою и код юзаю повторно. А читать мануал всегда придется чтобы как минимум 1 раз разобраться и набросать код.
А раз ты уже разобрался и напрогал то че его помнить то, когда у тебя вылизанный код имеется

Вот я бы не отказался от кода на cmsis для ov5642 и ethernet который скриншот отправляет на комп с минимальной задержкой. При чем без всяких либушек минимальный код.

[VladislavS]

Хорошо вам, чип один и тот же, код тоже - ксерь себе да ксерь. А тут и чипов целый зоопарк и проектов ни одного похожего.

[Oxford]

Да схера ли один чип то у меня? Да в любом случае под каждый чип ебошиш код. Есть чипы где архитектура вообще отличная от стм32, стмки вообще козлячьи чипы, начать с того что привязка к пинам периферии железная плюс пересечения периферии все это усложняет трассировку платы.
Если девайс разрабатывается ты же выбрал конкретный чип и прошивку пилишь ему и потом обновляешь. Кроме чипа еще дохера всякой чуши обслуживать надо.
Я вообще скажу настройка периферии у меня не занимает много времени, основное это сама прошивка, графика если есть, логика, всякие драйверы внешних микрух, алгоритмы, стеки и прочее дерьмо которое жрет 90 процентов времени.

[Reflector]

[uquote="Oxford",url="/forum/viewtopic.php?p=3905387#p3905387"]Периферию и порты я и так настрою без либушек, периферия никуда не скачет. Я раз настрою и код юзаю повторно.[/uquote]
Очередной простой пример, на этот раз с SPI дисплеем:

Код: Выделить всё

using spi1 = Spi1<PA5, PA6, PA7, PB0>;
using lcd = LcdSpi<ST7735, LcdOrient::LandscapeRev, spi1, PA8, PA10>;
//using lcd = Lcd<RM68140, LcdOrient::Portrait, PB7, GpioB<0xFF00>, PB2, PB0, PB1, PB6, 0, 4>;
lcd::init(SpiBaudRate::Presc_4);

Теперь представим, что нет никаких либ, все это написано чисто на регистрах для твоего любимого F1 и этот один раз настроенный код переезжает на F0/F3/F4/F7.... Порты другие? Совсем другие, плюс появились AF. Режимы для пинов SPI тоже другие, сам SPI отличается не кардинально, но правки делать придется. У H7 принципиально отличается и SPI. Если используется DMA, то их тоже две основные разновидности. А мой код работает везде, AF подставляются автоматически, если на один из пинов невозможно заремапить нужный пин SPI - это ошибка компиляции. Замени вторую строку третьей и все продолжит работать с другим дисплеем, оставь обе строки и добавь второй init() - получишь два одновременно работающих дисплея.

[Oxford]

Reflector нахрен ты мне это обьясняешь? Я прогал под эти серии . Мне похеру какой чип прогать по мануалу и либы твои мне даром не нужны, завтра открою пик, силабс, инфенион, авр и прочее и буду прогать на си и регистрах. Для меня никакой разницы нет. Мне больше заняться что ли не чему как сидеть какие то говнолибы строчить.

[Reflector]

[uquote="Oxford",url="/forum/viewtopic.php?p=3905423#p3905423"]Мне похеру какой чип прогать по мануалу и либы твои мне даром не нужны, завтра открою пик, силабс, инфенион, авр и прочее и буду прогать на си и регистрах.[/uquote]
О чем и речь, никаким раз настрою и юзаю повторно тут и не пахнет.

[Oxford]

Ты че такой тугой то? Ну естественно что серии разные со своими особенностями и со своим набором периферии. В рамках серии что у тебя изменится то? в 100 FSMC добавиться? Ну бля тут уж поди запрогай его если тебе он нужен.
В любом случае программируешь по мануалу на конкретный чип и так делают все без исключений абсолютно все инженеры и даже те кто вам пишет говнолибушки, калокубушки ))

[ARV]

Код: Выделить всё

using spi1 = Spi1<PA5, PA6, PA7, PB0>;
using lcd = LcdSpi<ST7735, LcdOrient::LandscapeRev, spi1, PA8, PA10>;

оно-то красиво... но тут вопрос в том, что понять это сложно. мало иметь поверхностное представление о С++, классах и ООП, тут надо очень глубоко знать именно тонкости С++, очень глубоко. скажем, со стороны видно, что во второй строке первым "параметром" шаблона указывается тип контроллера дисплея. очевидно, где-то этот самый контроллер уже описан от и до... но сколько нужно усилий для того, чтобы самому описать соответствующим образом другой контроллер? боюсь, усилий потребуется слишком много... или нет? или в этой "либе" уже все контроллеры определены - бери и пользуйся?

[Oxford]

ARV А еще отладка и анализ кода C++, а еще долгая компиляция C++ кофе можно попить пока компилит более менее проект, а еще то что на разной платформе по разному C++ может работать и поддержка C++ не всеми компиляторами, тогда как ANSI С утюг поддерживает. Я и должен изучать C++ чтобы в регистр записать конфиг?

[VladislavS]

[uquote="Oxford",url="/forum/viewtopic.php?p=3905387#p3905387"]Вот я бы не отказался от кода на cmsis для ov5642 и ethernet который скриншот отправляет на комп с минимальной задержкой. При чем без всяких либушек минимальный код.[/uquote]И в чём проблема? Даташит есть, Си и CMSIS тоже. Взял да сделал.

[Oxford]

VladislavS Да я всегда так и делаю. И ты так же сделаешь возьмешь мануал и будешь ебошить. Так все программируют. Только я сразу ебошу напрямую и не пишу говнолибу.

[Reflector]

[uquote="ARV",url="/forum/viewtopic.php?p=3905430#p3905430"]оно-то красиво... но тут вопрос в том, что понять это сложно. мало иметь поверхностное представление о С++, классах и ООП, тут надо очень глубоко знать именно тонкости С++, очень глубоко. скажем, со стороны видно, что во второй строке первым "параметром" шаблона указывается тип контроллера дисплея. очевидно, где-то этот самый контроллер уже описан от и до... но сколько нужно усилий для того, чтобы самому описать соответствующим образом другой контроллер? боюсь, усилий потребуется слишком много... или нет? или в этой "либе" уже все контроллеры определены - бери и пользуйся?[/uquote]
ST7735 - это класс на сотню строк содержащий функции типа init() и setWindow(), которые для каждого дисплея обычно отличаются. Дополнительно там есть класс-обертка обеспечивающий унифицированное чтение. Имея один такой класс можно его переделать под другой контроллер, например, у ST7789 свой init() и отличаются функции чтения, остальное без изменений. Какие дисплеи через меня проходили, я добавлял, один даже удаленно

[Dimon456]

Я далек от этих классов, для примера скачал примерчик вот отсюда
В папке mcucpp/ARM/ есть куча папок, наверное под каждый МК, даже и AVR запихнули
Если сравнить файлики ports.h в папках Stm32f100 и Stm32f0x то они разные.
Скажите вы его, этот ports.h, сами пишите? или компилятором поставляется?

Не спорю, это во многом упрощает, не плохо бы иметь такую библиотеку на СИ.
Потом как нибудь поиграюсь, посмотрю что это все стоит, а так пока не вижу ни какого плюса, так как все упирается опять же в конечные функции, например

Спойлер

из файлика Stm32f0x/usart.h

Код: Выделить всё

static void Write( uint8_t c )
      {
        while (!TxReady( ))
        ;
        Regs( )->TDR = c;
      }

      static uint8_t Read( )
      {
        while (!RxReady( ))
        ;
        return Regs( )->RDR;
      }