STM32 это наверное круто, но так нельзя

[Гость Jaguar]

Добрый день!

Выражаю восхищение людям, таки освоившим разработку для stm32.

Я программирую на С/С++ 20 лет. Профессия это моя, а не хобби. В качестве хобби я играюсь с контроллерами. И на AVR создал радиотабло - связка сетодиодных табло с радиомодулями. Сейцчас они используются на различных мероприятиях.

Пришло время ознакомиться с stm32. Ребята, я за несколько дней не смог добиться blink led!!! Свободные пара часиков после работы. Все ссылки не ведут на точный рецепт... Примеры устаревшие в тексте и видео, в базе примеров нет или не попались на глаза. Бибилиотеки не полные. Компилятор собрать их воедино не может. Я конечно разберусь....

НО НАДО ОЧЕНЬ ХОТЕТЬ И ОСОЗНАВАТЬ, ЧТО БУДУЩЕЕ ЗА STM32, чтобы простому смертному не забросить это дело.

Потом чморят arduin-щиков, за их любовь к своим продуктам, где мое первое знакомство привело к положительному результату за 5 минут.

Программирование контроллеров - должно быть не мозговыносом, а созданием конкретных полезных продуктов.

Не туда уходит энергия мысли и усилие... Да - и не стоит ссылаться на настоящее хардкорное программирование. Я в дестве и на ассемблере херачил, doom2 игрушку перепрограммировал на 386-х, и даже свои игры писал на Агатах на ассемблере, . Во всем должен быть смысл. Не должен я молотить интернет три дня, чтобы производителю stm32 удалось меня подсадить на свою продукцию. Толи еще будет, когда я начну портировать свои наработки под AVR,

p.s.

И нахрена я это написал? Да так.... просто офигеваю от того, как stm32-производители софта нацелены на процесс, а не на результат.

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[mail_robot]

1 час назад, Гость Jaguar сказал:

Программирование контроллеров - должно быть не мозговыносом, а созданием конкретных полезных продуктов.

тогда лучше стм32 вы не найдете ничего

Рецепт софта - CubeMX + Keil (не забудем при установке тыкнуть галки в пакеты под свой проц). Скачиваете все с официального сайта, ставите, приходите сюда. Обьясняю как за минуту написать блинк. Потом как написать блинк под FreeRTOS тоже за минуту. Дальше не думаю что придется обьяснять

STLink Utility тоже поставьте на всякий пожарный и через него обновите драйвера стлинка (там кнопочка есть, все автоматом)

Весь софт без всяких бубнов скачиваем напрямую с официальных сайтов!!! Все будет работать без лицензий. Производитель как раз таки нацелен на результат, а головняки создают бестолковые юзеры сами себе

Изменено 6 октября, 2016 пользователем mail_robot

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[musa56]

3 часа назад, Гость Jaguar сказал:

Пришло время ознакомиться с stm32.

Ничего суперсложного

http://easyelectronics.ru/category/arm-uchebnyj-kurs

[Реклама]

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Гость Jaguar]

Спасибо за ответы, я, конечно, же выбрал tool chain изначально.

Советовали привязаться к Coocox , но имеющиеся в сети доки отстают от версии современой программы, а переработали они репозитарий кардинально.

Хотел без HAL без асбтракций покодить близко в к примитиву и портам - не нашел в составе даже _gpio.h

Стал выцеплять побиблиотечно из интернета - конфликтуют библиотеки.

Поставил stm32cubef4 - изначально много мусора предложила программа, и задала много вопросов, на которые я не в состоянии ответить -  надо читать.

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

В avr-то все элементрано - сколько воткнул - столько и  получил. Тут не так.

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

В общем пришел учиться летать, а вместо учебного кукурузника дали боинг с кучей опций и сказали "лети!"... В итоге не могу добраться даже джо взлетно-посадочной полосы от ангара.

[dm37]

Сам, недавно начал переходить с AVR на STM32 и столкнулся с подобными же проблемами.
Что для себя уже отметил, так это действительно путаница в примерах и обзорах. И связана она прежде всего с тем, что те, кто выкладывает примеры порой не упоминают какую из библиотек используют, приходиться только догадываться (где тут в боинге "включить свет"). Порой код в статье идёт даже без указания подключаемых заголовочных файлов!

Вместо того чтобы начать мигать светодиодом много времени ушло на выяснении какие библиотеки есть, чем они отличаются и как их идентифицировать.

На сегодняшний день существуют четыре основных способа создания кода для STM32 (существуют примеры в сети):
- непосредственно работа с регистрами в шестнадцатеричном формате;
- использование библиотеки CMSYS (можно считать, что это аналог заголовочного файла AVR);
- использование библиотеки SPL (упрощает жизнь, используется очень широко, в основном все примеры с его использованием);
- использование библиотеки HAL (дальнейшие развитие SPL).

Нужно примеры искать именно для своей серии, например, STM32F4xx. Инициализация периферии отличается, например, код для STM32F1xx не подходит для STM32F4xx.

Для понимания работы STM32 (не для проектов - пока не решил, что буду использовать для проектов) для себя выбрал CMSYS и Reference manual. В принципе уже что-то получается, жаль только, что эмуляторов (при работе без железа) нормальных нет.

Примеры для работы с STM32F4 и SPL  https://www.youtube.com/watch?v=Qqk81seMlHA&list=PL8OgDYWys_b6XtOjCejd37aVv0ic24jqV&index=1

P.S. Тренируюсь на STM32F4DISCOVERY.

[mail_robot]

тупики вы ребята изначально выбираете. И идете в них с завидным упорством даже не понимая, что философия стм кардинально отличается от авр. Вы думаете, что чем ниже уровень библиотеки, тем лучше все будет и быстрее. Но это не так (забегая вперед). В стм нет смысла экономить. Там всего много и хватает этого много в 99,9% случаев. Какой смысл экономить?

Осваивать надо сразу HAL. Он не хуже всего остального, наоборот. В HAL уже давно реализованы макросами все те вещи, которые в SPL надо аккуратно (чтобы не ошибиться!) выписывать руками. Ну и нафига? Зачем изобретать свой велосипед с квадратными колесами?

Примеры для HAL искать не надо в сети. Все они лежат в папке Users/STM32CubeMX. Написаны четко и компилируются 100%. На любой чих там есть пример.

HAL очень экономит время. К примеру написание прошивки для центральных часов реального времени с использованием SPI, I2S, DMA и UART у меня заняло 4 часа. Написание прошивки для электронной нагрузки с растровым дисплеем, кучей кнопок, 6-канальным АЦП с ДМА и кучей математики и меню и ОСРВ в добавок - неделя. Это 100 лапый камень! У которого осталось свободных ну лап 15 от силы. И это при том, что я не программист. На SPL у меня ушел бы месяц минимум. При этом совершенно не важно под какой камень ты пишешь. Код в пределах серии (F1ХХ к примеру) переносится без корректировки. Сам по себе HAL в пределах семейства STM32 отличается только мелкими нюансами и в основном для шикарных камней. Но все "крутые спецы" от чего то ругают хал и тупят вручную все то же самое, только по новой. Забавляет меня их упорство конечно...

Но я ж понимаю, что нормальные герои всегда идут в обход. Давайте.

[dm37]

то mail_robot

не тупики, мы учимся, всё таки STM32 это просто микроконтроллер и его нужно знать на уровне железа. Я с ужасом жду когда микроконтроллеры начнут поставляться с предустановленным linux, тогда всё сведётся к написанию софта используя огромные наработки в этом направлении (я совсем не против linux в uC). А как же творчество, как же в 2 Кб "впихнуть невпихуемое" и радоваться, что у тебя это получилось. Конечно у STM32 полно ресурсов, но иногда приходится и оптимизировать код, думаю HAL здесь уже не поможет, нужно будет лезть в CMSYS и asm. Наверняка вы не раз ругали Windows за его прожорливость и пустую трату ресурсов, ну если есть у нас возможность сделать не так как в Windows, разве это плохо. Да времени на разработку уйдёт больше, но результат может быть лучше (как это называется - "православное программирование", вроде  ).

Я читал ваши выводы по поводу HAL в других ветках, сам использую примеры HAL, но пока только с целью понять, какие регистры как меняются (т.е. то, что относится непосредственно к периферии STM32). HAL больше настроен на быстрый конечный результат (и это хорошо), а не на изучение. Пока необходимо понять идеологию STM32.

как уже писал по поводу библиотек
Для понимания работы STM32 (не для проектов - пока не решил, что буду использовать для проектов)

[mail_robot]

9 часов назад, dm37 сказал:

STM32 это просто микроконтроллер и его нужно знать на уровне железа

если начать вникать на уровне железа в каждую пластмассовую многоножку, то мне жизни не хватит на чтение мануалов. Совершенно не нужно знать стм на уровне железа, так же как и не требуется знать х86 для написания проги под винду. Тут у нас с вами мнения разойдутся кардинально. Мне интересно получать продукт. То есть какую то самоделку, которая работает. Мне не интересно тратить время на очень элегантное и правильное вылизывание кода до мелких мелких деталек, а потом самим же собой гордиться перед зеркалом повторяя про себя - как я все таки круууут! Аж 2 байта сэкономил! Правда кроме себя самого этих трудов больше никто не оценит.

И получится как в том анекдоте - ну и нахрена мне весь этот тюнинг в зоопарке? Нахрена мне тратить время на разучивание регистровых мантр, когда и так будет работать?

 

Очень простой пример. Напишите ка мне на том же CMSIS реализацию функции HAL_UART_TransmitDMA(&huart, *data, size). А потом расскажите сколько у вас по честному ушло на это времени. А я пока займусь зарядным устройством. Там у меня как раз STM32-ой и я планирую потратить на прошу не больше часа чистого времени. Там всего то надо собрать данные по 8 каналам АЦП через мультиплексор НС4051, пропустить через оверсэмплинг и по пороговым значениям зажечь 8 зеленых или 8 красных светодиодиков через SPI. Ну еще отладочную информацию выплюнуть в UART чтобы удобно на компе было смотреть текущие значения АЦП. Часика-полтора с перекурами думаю самое то

[nik182@mail.ru]

HAL это индийский тупик, годный только на быстрые поделки в стиле ардуино. Как только в проекте надо делать что то отличное от примеров HAL приходится лезть в SPL. Простой пример. Статья https://habrahabr.ru/post/279747/ MODBUS на HAL. Цитата :"... портировать UART-layer на STM32 под «чистым» HAL мне не удалось и пришлось лезть глубже."

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

Учить НАL тоже надо. Мануал Description of STM32F4xx HAL drivers 980 листов. Мануал на контроллер чуть больше. Но  изучив его  можно использовать любой вариант создания кода и при этом понимать как что работает. Я не против HAL. Для быстрого создания программы с минимумом ошибок и функционала - наипростейший путь. Для начинающих самое то. Для совсем простого пути есть mbed.com .  Просто, в стиле ардуино, без установки каких либо инструментов, на стандартных платах, можно писать большие приложения и они работают.   

[mail_robot]

13 часа назад, nik182@mail.ru сказал:

https://habrahabr.ru/post/279747/ MODBUS

Если внимательно почитать, то это очень частный случай не совсем тривиальной задачи. И автор все же не стал отказываться от HAL, а просто дополнил код некоторыми своими функциями, которые не определены в стандартной библиотеке HAL, которая собсна и не предусматривает работу UART в режиме MODBUS. HAL обеспечивает работоспособность всех документированных функций STM32 и этого достаточно для решения подавляющего объема задач.

13 часа назад, nik182@mail.ru сказал:

Одно то, что любая инициализация прерывания HAL включает все возможные прерывания и устройство постоянно сваливается в них, где пытается разобраться надо оно или нет и тратит попусту время

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

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

Вообще конечно у каждого программиста свои предпочтения в плане организации собственного труда. Однако тех программистов, которые предпочитают клеймить то или иное решение в свете внешне как будто бы похожего (ардуино) я искренне не понимаю. Шаблонность мышления в данном случае будет только мешать. HAL это далеко не Wire и даже рядом с ним не стоял. Вннешне он имеет довольно громоздкий синтаксис, но как только в него втягиваешься, то начинаешь понимать его смысл. Это сделано просто для того, чтобы любой программист, который возьмет ваш проект или решение смог в кратчайшие сроки вникнуть в код, написанный по сути на понятном человеческом языке и продолжить работу. То есть HAL от SPL отличает еще и прекрасная самодокументируемость. А это согласитесь порой важнее скорости кода (хотя тут очень спорный момент по части кто быстрее). Так что чисто мое мнение - если я упрусь в скорость используя HAL, я лучше сменю камень, но не метод. Или придумаю как решить задачу в стиле автора статьи в первой цитате.

Изменено 16 октября, 2016 пользователем mail_robot

[nik182@mail.ru]

Хорошо вам. Камень можно выбрать.  

Собственно прерывание одно, флагов много. Скажем dma. Потребовалось прерывание полной передачи. При отладке оказалось что в прерывание сваливается по всем флагам. Все выбраны и нет возможности выбрать то что надо в рамках HAL. 

Ещё раз. Я не против HAL. Возможно это привычка со времени когда надо было бороться за каждый байт и микросекунду. И HAL в этой борьбе не помошник.

[mail_robot]

Я за байты не борюсь. Просто потому что это стало второстепенным. На первом месте скорость и простота разработки, впрочем я об этом уже говорил. На первом месте - чтобы работало. Ну и по поводу разницы между HAL и SPL. Гдето года два назад я писал прошивку под электронную нагрузку. Объемная штука как по работе так и по коду. Сначала взялся на SPL, убил гдето месяца два, довел до ума более менее, но потом... короче долгая история и в итоге тот же код переписал с использованием HAL и FreeRTOS. Размер кода даже немного уменьшился за счет перестройки архитектуры программы. Функциональность при этом существенно возросла. Такой вот парадокс

Ну а в плане скорости, ну давайте все таки порассуждаем - так ли уж сильно тип библиотеки влияет на скорость?

Ну вот я возьму просто запись в порт как это записано в HAL

void HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin, GPIO_PinState PinState)
{
  /* Check the parameters */
  assert_param(IS_GPIO_PIN(GPIO_Pin));
  assert_param(IS_GPIO_PIN_ACTION(PinState));

  if (PinState != GPIO_PIN_RESET)
  {
    GPIOx->BSRR = (uint32_t)GPIO_Pin;
  }
  else
  {
    GPIOx->BRR = (uint32_t)GPIO_Pin;
  }
}

 

Кажется вроде кода много, но! Обратите внимание насколько он грамотно и безопасно написан. Даже если отбросить проверку валидности типов передаваемых аргументов, то мы заметим что изменение состояния порта происходит не за счет записи в ODR, а записью в рекистры BSRR и BRR. А это в свою очередь снижает риск ошибочного возникновения прерывания, если таковое зацеплено на ногу. Вы точно знаете все эти тонкости программирования STM? Готовы поручиться что ваша программа написана так же безопасно как и эта простейшая фигатория? Я нет. И рисковать не хочу.

Ну и потом. Почитаем код

HAL_GPIO_WritePin(GPIOA, GPIO_Pin_6, GPIO_PIN_RESET)

GPIOA->BRR |= (1<<6);

первая строчка кажется приятнее для чтения. Как то человечнее чтоли. А когда такого кода килобайт 100 в листинге, то работать с ним становится в тысячу раз приятнее, особенно после недельного перерывчика.

Представляете себе во что выльется на SPL банальное вот это?:

HAL_I2C_Master_Transmit(&hi2c1, 0xD0, tbuf, 2, 0xFFFF);

И быстрее оно не будет. Можете попробовать. Зато вероятность ошибок возрастет неимоверно, в том числе по железу, когда вы забудете проверить какой нибудь таймаут или оверран и прога ваша будет непонятно от чего то виснуть на ровном месте. Если бы мне предложили выбор на каком самолете лететь - на быстром или на надежном?, я бы однозначно выбрал надежный, тем более что аэроэкспрессы из аэропорта все равно ходят по своему расписанию и смысла прилетать на 20 минут раньше ну никакого.

В общем не знаю. Меня конечно тут давно уже считают навязчивым психом рекламирующим STM32 и HAL, но я считаю что ребята разрабы проделали просто великолепную работу. Каждый раз читая код библиотеки перед тем как вызвать чтото новое, не перестаю восхищаться. Поэтому кмк глупо не пользоваться таким подарком. Можно конечно заниматься выискиванием мелких примелких ну вот прям очень нужных (хрен знает когда) флажочков и заковырочек, уговаривая себя что хал говно и тормоз, но ничего кроме улыбки у меня лично это не вызывает. Нужно сначала вникнуть и попробовать, а потом уже смело заявлять - да, я знаю точно что хал говно, а ассемблер это круто. Полностью с вами согласен ))

 

5 часов назад, nik182@mail.ru сказал:

Хорошо вам. Камень можно выбрать.

всем у кого есть карта виза, интернет и паспорт одинаково хорошо вместе со мной )))

Изменено 20 октября, 2016 пользователем mail_robot

[mail_robot]

немножко подумал

конечно у каждой технологии или решения есть свои преимущества и недостатки. Хорошо когда владеешь всеми инструментами и используешь их под конкретную задачу наиболее подходящим способом. Их можно даже сочетать при желании. Так что думаю в плане решений все в руках программиста. Опять же в свете вышесказанного выделить какое то конкретное решение как абсолютно лучшее не получится. HAL прост и удобен, SPL лаконичен, но плохо читаем, ASM аскетичен но быстр. Как то так

[mr_smit]

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

[mail_robot]

Не увлекайтесь чтением умников из интырнэтов. Я лично даже сам себе не очень доверяю

[fr0ster]

В сторону HAL у меня лично есть одна претензия.

Если между SPL и регистрами, а соответственно документацией типа RM можно провести некие связи и параллели, то HAL поворачивает процесс разработки торчком, вводит свои ограничения и главное на этот HAL нет нормальной документации. Чуть только задача оказывается сложнее неких примеров в представлении абстрактного индуса в вакууме, все, изобретай способы обойти ограничения HAL весьма нетривиальным образом.

Плюс одна и та же задача решенная в CMSYS или SPL часто стартует гораздо быстрее, чем решенная в HAL. Оно в принципе не критично, но это означает, что HAL пока сырой.

PS Кто нить проверял проект использующий HAL на соответствие MISRA-C?

[mail_robot]

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

void HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin, GPIO_PinState PinState)
{
  /* Check the parameters */
  assert_param(IS_GPIO_PIN(GPIO_Pin));
  assert_param(IS_GPIO_PIN_ACTION(PinState));

  if (PinState != GPIO_PIN_RESET)
  {
    GPIOx->BSRR = (uint32_t)GPIO_Pin;
  }
  else
  {
    GPIOx->BRR = (uint32_t)GPIO_Pin;
  }
}

Если убрать все лишнее, то останется

void HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin, GPIO_PinState PinState)
{
  if (PinState != GPIO_PIN_RESET) GPIOx->BSRR = (uint32_t)GPIO_Pin;
  else GPIOx->BRR = (uint32_t)GPIO_Pin;
}

Нет? Скобки я убрал, чтобы убрать впечатление громоздкости. Но по сути то тот же SPL, только в красивой обертке, не более. С чего бы это дольше стартовало? Непонятно. Хотите сэкономить еще 6 байт, ну уберите заголовок и вставляйте текст функции инлайн. Будет брутально

То же самое можно сделать практически с любой HAL конструкцией, если это требуется. Но реально от этого мало пользы, так как размер кода практически не изменяется. Макрос assert_param компилируется только если выставить соответствующие ключи. По дефолту они отключены. Вообще HAL по сути это всего лишь набор макросов, основанных на стандартном SPL и CMSIS.

1 час назад, fr0ster сказал:

HAL поворачивает процесс разработки торчком

совершенно согласен. Он начисто избавляет от утомительного ковыряния в мануалах и разбирательств со структурой блоков. С того момента как начал писать на HAL необходимость в постоянном нырянии в UM отпала начисто. За год ну мож раз 6-8 нырнул, только чтобы структурную схемку посмотреть и еще чтото по мелочи. Остальное просто не требуется. Программируя под PIC и AVR мануал был открыт постоянно в фоне и оттуда практически не вылезаешь. Конечно это переворачивает весь процесс с ног на голову. Я вас прекрасно понимаю

Изменено 28 октября, 2016 пользователем mail_robot

[fr0ster]

24 минуты назад, mail_robot сказал:

Программируя под PIC и AVR мануал был открыт постоянно в фоне и оттуда практически не вылезаешь. Конечно это переворачивает весь процесс с ног на голову. Я вас прекрасно понимаю

Нет, я не говорил про переворачивание с ног на голову, а говорил про поворачивание торчком. Это например ограничение способов корректного использования HAL.

Избавляет HAL от необходимости читать доки по используемому МК? Однозначно нет.

27 минут назад, mail_robot сказал:

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

В принципе при таком подходе какой смысл вообще в использовании HAL?

 

30 минут назад, mail_robot сказал:

Вообще HAL по сути это всего лишь набор макросов, основанных на стандартном SPL и CMSIS.

Как раз нет, это не только макросы, но и определенный паттерн программирования, рекомендованный к использованию по умолчанию

 

33 минуты назад, mail_robot сказал:

Он начисто избавляет от утомительного ковыряния в мануалах и разбирательств со структурой блоков.

Разве? Ну допустим структуры ладно, хотя какое разбирательство было в случае CMSYS? А мануалы? Вы какие именно имеете ввиду?

[mail_robot]

Я кстати с вами не спорю. Мне очень интересно узнавать мнения программистов по этому поводу и вести аргументированную полемику. Так что ничего плохого не думайте. Просто излагаю свои мысли на основе индивидуального опыта. Не более того.

16 минут назад, fr0ster сказал:

Избавляет HAL от необходимости читать доки по используемому МК? Однозначно нет.

однозначно нет. Но делать это приходится значительно реже. С этим фактом трудно спорить.

16 минут назад, fr0ster сказал:

В принципе при таком подходе какой смысл вообще в использовании HAL?

ну заглядываю я далеко не в каждую функцию. Это просто абсурдно было бы. И смотрю только тогда, когда в мануале не совсем понятно написано или выискивать флаги в тексте дольше, чем обратиться к обьявлению типа и посмотреть доступные значения. Думаю все так делают. Это просто экономия времени. Или когда надо написать чувствительную ко времени функцию, я просто беру и вручную правлю то что мне надо в копии библиотеки. В CubeMX есть опция копирования экземпляра библиотеки в проект, этим и пользуюсь для кастрирования ненужного. Но в подавляющем большинстве случаев пользуюсь стандартной реализацией. Как то так

16 минут назад, fr0ster сказал:

Как раз нет, это не только макросы

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

16 минут назад, fr0ster сказал:

А мануалы? Вы какие именно имеете ввиду?

Ну какие... Референцы конечно же. Остальные то программисту зачем? Когда что-то проектирую использую мануалы по железу. Но они скучные, там одни токи, напряжения да частоты с таймингами фронтов.

А с SPL и CMSIS разборок кстати совсем немало. И про регистры надо почитать и про зависимости и структурную схемку блока посмотреть. К примеру как вы мне организуете подключение энкодера к TIM1 с железным декодированием без ковыряний? А с HAL я ету фичу реализовал легко и просто. Открыл структурку, посмотрел что ничего особенного, подключил энкодер и через 10 минут получил шаг и направление. Фотопруф девайса. Спроектировал, закодил и пользуюсь. На код ушло 2 недели по вечерам после работы. Но там операционка и меню и куча режимов и вообще все не просто. (внешнего вида не пугайтесь, это прототип)

 

Изменено 28 октября, 2016 пользователем mail_robot

[fr0ster]

3 минуты назад, mail_robot сказал:

однозначно нет. Но делать это приходится значительно реже. С этим фактом трудно спорить.

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

 

34 минуты назад, mail_robot сказал:

А как "паттерн программирования" влияет на конечную эффективность кода по вашему?

Паттерн влияет не только на эффективность кода, но и на эффективность написания кода. Причем влияние на эффективность кода в том, что варианты корректного использования HAL ограничены и гораздо сильнее, чем например CMSYS.

36 минут назад, mail_robot сказал:

Референцы конечно же. Остальные то программисту зачем?

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

38 минут назад, mail_robot сказал:

А с SPL и CMSIS разборок кстати совсем немало. И про регистры надо почитать и про зависимости и структурную схемку блока посмотреть.

Разборки есть, но вы же не каждый раз разбираетесь, когда подобную задачу решаете?

39 минут назад, mail_robot сказал:

К примеру как вы мне организуете подключение энкодера к TIM1 с железным декодированием без ковыряний? А с HAL я ету фичу реализовал легко и просто.

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

[mail_robot]

я бы с вами согласился, кабы сам не начинал с SPL, с тех же оберток и библиотек. Потом пришел к выводу, что при том объеме периферии и возможностей, которые дает 32-ой некоторые проекты начинают просто тонуть в коде. Править код становится сложно, а масштабирование задач увеличивает трудозатраты уже не линейно, а в квадрате. Осознав это я переключился на C++. Позагонял все в классы и вроде полегчало, но как только дело касалось смены платформы все труды тут же умножались на ноль, потому как несмотря на максимальную преемственность всеж таки у железа есть свои нюансы.

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

Теперь кодинг по стм ничего кроме радости и удовольствия не приносит. И времени уходит в десятки раз меньше. Я рад

Изменено 28 октября, 2016 пользователем mail_robot

[fr0ster]

@mail_robot Я с вами спорить тоже не буду, так как серебряной пули не бывает, каждая парадигма оправдана на своем месте

2 часа назад, mail_robot сказал:

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

Если посмотреть на опыт программирования не только для МК, а вообще, можно заметить, что проблемы объемов кода, в которых тонешь, это не столько технические проблемы выбора CMSYS/SPL/HAL/WINAPI/Qt/GTK/DotNet/ et cetera, а больше проблема административная Не факт, что завтра вы не столкнетесь с проблемой утапливания в коде уже с HAL. В общем как писал папа С++, нужно накапливать свои библиотеки обертки и сниппеты, которые можно повторно использовать без изобретения велосипеда.

2 часа назад, mail_robot сказал:

Я просто еще раз изобретал велосипед с квадратными колесами.

Велосипед можно изобретать и с HAL, можно неизобретать и с CMSYS.

 

[mail_robot]

1 минуту назад, fr0ster сказал:

 Не факт, что завтра вы не столкнетесь с проблемой утапливания в коде уже с HAL

думал об этом. И были такие опасения. Но есть одно обстоятельство, которое пока не позволяет состояться данному факту - ограниченные ресурсы контроллера. Максимально что мне туда удастся залить в обозримой перспективе скорее всего не сможет выйти за рамки возможностей доступного инструментария. Тем более что я практически постоянно подкрепляю эту уверенность использованием ОС в своих проектах. Она значительно выравнивает код и затраты на администрирования снижаются до минимума. Не использую ее только в контроллерах класса F030 с обьемом оперативки меньше 4К. Хотя сами 030-е идут как семечки на базаре вместо 8-биток. (конкретно STM32F030F4P6). Считаю их реальными убийцами 8-биток. Задачи посложнее пока укладывались в семейство F103 (максимум VET6). Вот там уже неиспользование ОС видится как неразумная экономия ресурсов.

Пока справляемся в общем )

[fr0ster]

В принципе для избегания утопления в коде первым шагом стоит сделать не выбор между CMSYS/SPL/HAL, а подбор определенного набора МК.

То есть не просто решить "я использую STM32", и даже не "я использую STM32F0/STM32F4", а определиться, что использую пару МК - STM32F072RBT6 и STM32F407VGT6. Я тут слегка утрирую и говорю чисто к примеру. Это в чем то ограничит возможности, зато снимет кучу проблем именно административно. Заодно позволит избежать постоянного изобретения велосипедов и повторно использовать код (в случае его грамотного написания).

А главное уже будет все равно, используете вы HAL или CMSYS  вы сможете в большинстве ситуаций играть на своем поле, где вы определяете ваши правила

[Shalfey]

Я в контроллерах новичок. Люблю и железо изучать, но  STM это вам не Z80 восьмидесятых. Тут регистров тысяча. Пока их изучите, поседеете. Кстати, на кокосе у меня любые проекты запускаются из инета.  Кейл капризный,то ему драйвер не тот....то ишо чего нибудь. Ну и на Кейле выходит. У жены ноут покруче моего компа, там Кеил идёт, на моём старом с ХР, не идёт. Зато Кокос на моём шпарит.По поводу HAL. Отличная библиотека или как его назвать. Сub это супер. Но я не "дремучий ардуинщик". Читаю железо STM, мне даже в кайф, что сложно.

Изменено 9 марта, 2018 пользователем Shalfey