Изучаем STM32 Cortex M3

[eddy]

mikroC PRO for ARM

Зачем каким-то сторонним говном пользоваться, когда gcc и для ARM'ов, и для MIPS'ов компиляет (есть даже для тупых avr'ок зачем-то).

нередко бывает что одинаковая программа на разных языках на выходе дает одинаковую прошивку.

Вероятность такого события исключающе мала.

[DanilinSA]

Там вся прелесть именно в приемлемости линейки компиляторов.

Например для С:

mikroC PRO for PIC32
mikroC PRO for ARM
mikroC PRO for AVR
mikroC PRO for FT90x
mikroC PRO for 8051
mikroC PRO for PIC
mikroC PRO for dsPIC/PIC24

Что-бы люди могли с одного микроконтроллера переходить в другой не покидая привычной IDE.

Нужно видеть выражение лица некоторых товарищей, которые уперли у меня исходники прошивки. А там Паскаль !!! Это бесценно !!!
Так эти альтернативно одаренные еще пытались на С откомпилировать это ... Было весело. Потом с подставного аккаунта на меня пытались выйти.
А я и на "mikroBasic PRO for ARM" мог написать ...

Расскажу по подробнее:
Пригласили меня написать программу для одной технологической установки. Сердцем установки был STM32 чип. Это балбесы полезли в чип в надежде "подкрутить производительность". Прошивка была залочена на чтение. Далее - сам догадались. Полностью снесли прошивку.
Обговорили цену, обговорили сроки.
Опыт подобной работы был, написал относительно быстро. Писал на "mikroPascal PRO for ARM", благо компилятор код генерирует хорошо и и я его хорошо знаю. Рядом с установкой поставили комп, я на нем правил прошивку при отладке.
Но зная этих товарищей - были шансы кидалова. Прошивка работала хорошо. Была да-же лучше прежней. И удобней.
Но прошивка не давала переключить оборудование в один из режимов. Важный режим
Завел разговор о оплате.
Как и следовало ожидать - кинули с оплатой. Решили, что реально я сделал быстро, значит работа несложная и денег сейчас нет, и неизвестно когда будет ... Дали немного на руки и помахали ладошкой вслед.
Очевидно расчет был на то, что исходники прошивки были на их компе, молодежи "считающим себя крутыми прошивкописателями" полно, доработка программы минимальна.
Далее началась комедия:
1) Крутые писатели прошивок "с опытом разработку" увидев Паскаль в исходниках тихо охреневали и исчезали за горизонтом.
2) С огромным трудом нашли программиста, который понимал Паскаль.
3) Вторая засада - без ключа компилятор работает только в "ДЕМО" режиме. С ограничением по размеру кода. И программа туда сильно не влазит. А кряка нет. Вообще нет. Среда не популярная, все кряки - для сильно старых древних версий. Ключ - USB аппаратный. Естественно я его не оставлял. Они думали что это флешка. Это мой личный самодельный ключ.
4) Оборудование стоит. Прибыли не приносит.
5) Скрепя зубами ( ко мне не обращаются - не хотят признаваться в кидалове) нанимается студент для написания прошивки "с нуля". Я в свое время очень душевно поговорил с технологом. Прояснил все особенности и нюансы работы оборудования. А студенты сразу сели писать код ...
6) А потом знакомый (работал в соседнем цехе) мне рассказал, что линию угробили. Блокировки там были по большей части программные, что-там эти орлы напрограммировали - ХЗ.
7) Стоимость восстановления оказалась высокой. И проблемное оборудование ушло в металлом.

Вывод - "кроилово ведет к попадалову".

[eddy]

DanilinSA, тогда уж на brainfuck пишите. Точно никто не разберется...

[Easyrider83]

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

[prinv]

Всех противников SPL и HAL объединяет одно - отсутствие конкретики.

Например, что невозможно сделать используя HAL/SPL? С примерами.

[prinv]

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

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

Второй пример - HAL содержит неиспользуемые усложнения и этот пресловутый HAL_OK. Скажите, много ли людей понимают, что именно надо сделать, когда вдруг будет получен HAL_не_окей? А сколько людей из них понимают, почему вдруг HAL_не_окей?

Квалификация программистов не проблема HAL, не так ли? У вас всё в одну кучу валится - кони, люди

Третий пример - на HAL невозможно написать компактного и быстрого кода, сопоставимого по быстродействию и/или (!!) размеру кода, писанного на CMSIS.

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

Четвертый пример - почти все вопросы и проблемы "помогите, не работает!!" связаны именно с написанием на HAL. Не верите? Пролистайте форумы. 99% проблем у людей - именно HAL.

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

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

Стоило ли было начинать говорить про конкретику и на пол-пути уйти? Как обычно, без конкретики.

[Исбанни]

Упс, косяк редактирования сообщения...

Чтобы перечислить хотябы половину конкретики, тут не хватит ограничения на макс.кол-во букв в сообщении.
Один из примеров - в HAL невозможно задать собственный алгоритм поведения. Вся свобода ограничена жесткими рамками поведения, заложенного в ф-циях HAL. Второй пример - HAL содержит неиспользуемые усложнения и этот пресловутый HAL_OK. Скажите, много ли людей понимают, что именно надо сделать, когда вдруг будет получен HAL_не_окей? А сколько людей из них понимают, почему вдруг HAL_не_окей?
Третий пример - на HAL невозможно написать компактного и быстрого кода, сопоставимого по быстродействию и/или (!!) размеру кода, писанного на CMSIS.
Четвертый пример - почти все вопросы и проблемы "помогите, не работает!!" связаны именно с написанием на HAL. Не верите? Пролистайте форумы. 99% проблем у людей - именно HAL.
Пятый пример - мануал по функциям HAL по объему ничуть не меньше референс-мануала на весь микроконтроллер целиком! Поэтому, гораздо быстрее написать на голом CMSIS, пощелкав регистры, чем #$#ться с тысячестраничным мануалом HAL. Тут даже без обсуждений.
Шестой пример - проект, генерируемый Кубом, выглядит настолько диким образом, содержит такую $%#ую структуру файлов, а сами файлы настолько изобилуют комментами в виде /* USER CODE BEGIN */, что разобрать за ними действительный код становится непросто чисто визуально. Это пример говнокода индусского.

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

---------------------
Короче, по всем пунктам prinv отвечу коротко и по-русски ёмко и железно - HAL-оводы - вечные лузеры и профаны. Почему? ПАТАМУШТА! Патамушта они лузеры и профаны.
prinv даже невкурил в тему, что я ему ответил. А посему у меня нет желания объяснять повторно какому-то сраному лузеру, что он всего лишь сраный лузер. Чувак, я тебе очень конкретно обрисовал конкретику. Но потому что ты лузер, ты так и не вкурил эту конкретику, просто потому, что даже не врубаешься в содержание конретики.

Ладно, еще раз. prinv, я тебе очень предельно конкретную тему наметил - что ты будешь делать с HAL_не_OКей и понимаешь ли ты, какие события к этому приводят? Так вот, 99,999% этого даже близко невкуривают, а посему, это на 99% лишняя херня.

Поясняю сразу - я на HAL/SPL не пишу, и срал я с высокой колокольни на всех HAL-овщиков вместе взятых. ЛЮБУЮ ф-цию или алгоритм я напишу быстрее, оптимальнее и проще, чем ЛЮБЫЕ ДЕСЯТЬ HAL-оводов, сидящих все вместе. И БЕСПОЛЕЗНО МЕНЯ ПЫТАТЬСЯ ПЕРЕУБЕДИТЬ. Потому что HAL-оводы - лузеры малоопытные, что они могут сказать КОНКРЕТНОГО в противовес мне? Да НИЧЕГО.
бессмысленные фразы типа "читабельнее код" - ЭТО НЕКОНКРЕТИКА, это субъективизм, ничем не подкрепленный. Обычная НЕКОНРЕТНАЯ фраза HAL-оводов.

[sat_art]

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

Любой пример

  /* Wait till HSI is ready */
  while (READ_BIT(RCC-›CR, RCC_CR_HSIRDY) == RESET)
  {
    if ((HAL_GetTick() - tickstart) › HSI_TIMEOUT_VALUE)
    {
      return HAL_TIMEOUT;
    }
  }

Можно тупо заменить на

  /* Wait till HSI is ready */
  while (READ_BIT(RCC-›CR, RCC_CR_HSIRDY) == RESET);

А таких кусков кода на лишний килобайт.

Что мне делать если вернулось HAL_TIMEOUT в данном случае?

И т.д. и т.п.

МК STM32 слава Богу не ATTiny что бы за каждый байт биться.

Вот с этого все и начинается.

[Исбанни]

Вот я о чем и толкую. Многие ли ЗНАЮТ, что делать с HAL-не_ОКей, какие действия к нему приводят и что вообще это означает?

За каждый байт биться не надо, ибо архитектура ARM такова, что она и без того слишком вольно обращается с байтами программного кода.
Но вот знать, на что именно уходит процессорное время и как избежать ЛИШНИХ и НЕОПРАВДАННЫХ потерь времени/объема - знать нужно и полезно.

Продолжая тему истечения таймаутов.
С HSI это неактуально. Он в любом случае рано или поздно запустится, а если не запустился, значит, МК неисправен или неисправно аналоговое питание и МК не может дальше полноценно работать, даже если запустить от HSE. Ошибки от неисправностей полезут в других местах.
Истечение таймаута HSE прописано даже в CMSIS и означает, что внешний кварц поломался, но можно запустить от HSI. Действия при истечении таймаута HSE - переход к настройке делителей и прочего тактирования от HSI, и возможно, вывод каких-либо предупреждений, кодов неисправностей, запуск в аварийном ограниченном режиме.

Ну а кто знает, что делать при прочих "НЕ_ОКей" ситуациях, мм? Ну-ка, HAL-овщики, пошевелите остатками мозгов, сообразите, а?

[prinv]

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

Причём здесь HAL?