Перейти к содержанию

    

SapegoAL

Свой
  • Публикаций

    2 712
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о SapegoAL

  • Звание
    Гуру
  • День рождения 06.08.1966

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Беларусь, Витебск, Строителей 18-4-220
  1. STM32СubeMX и подобные

    Цитата(juvf @ Mar 20 2018, 13:26) нет там хамства, а по поводу квалификации - тоже есть сомнения.... ни чего не скажу про квалификацию кого-либо, но пугает следующее .... К Вам претензий никаких. Всё по теме. Хамство я увидел в посте halfdoom. ЦитатаНе совсем так.... клокирование - галочки в кубе наставил и забыл про клоки. Без кала - там адское клокирование... ковырять битики, вчитываться в описание регистров.... UART - в кубе галкой разрешил - нужные GPIO подсветились, тут же в гуях перекинул на нужные (да и вообще прикинул куда можно прокинуть уарт), на соседней вкладке задал 115200, 8bit, 1stop - и забыл. А без хала крути клоки, gpio, alt_gpio, uart, nvic.... там только задать правильно 115200, при условии что 8МГц кварц, всякие плл и прескалеры.... с халом в лет инит уарта. И не нужно изучать как задается 115200 в уарте, какими регистрами и по каким формулам считается. Вот именно, что не совсем так... Галочки в кубе это хорошо конечно. Но я у себя в проекте, к примеру, запускаю кварц - проверяю - не запустился - запускаю HSI настраиваю PLL - выставляю признак ошибки оборудования. Аналогично поступаю с RTC кварцем. По крайней мере, на момент написания проекта, в библиотеках ST этого не было. Работать с портами через библиотеку ST вообще для меня непонятная вещь. Это уже обсуждалось 10 раз. Есть ряд красивых решений и ST под них ниразу не подходит. Всякие там nvic буквально макросами пишутся CMSIS и хидеров. Но ещё раз говорю - я же не возражаю. Просто это надо изучать. Причём нормально времени потратить. И тогда, правильно, проблем с USART не будет. Если реально это изучить, включая листинги... Ну так извините. Приём с передачей модбаса строк 20 вместе с обработкой регистров. Передача через DMA тоже 10 строк вместе с двумя прерываниями. Работы день... Два вместе с отладкой. Ну скажем, для меня. На изучение HALа, у меня уйдёт больше. Причём при подключении он подтянет 5 библиотек. Возьмём пример. Начал писать bootloader. Решил дабы время не тратить задействовать HAL. Там было буквально пару функций. В результате штук 5 библиотек подтянулось. Глянул даташит... Просто обалдел. Там всего то занести ключ да записать. Короче самописанных 3 процедуры по 5 строчек. Как говорится каждому своё. У одного разбор чужого и изучение нового занимает мало времени и тогда ему HAL просто песня. Для меня , зачастую, это прямая потеря времени. Мне проще самому накропать.
  2. STM32СubeMX и подобные

    Цитата(Quasar @ Mar 16 2018, 18:59) Судя по тому что вы написали, проблема у вас в уровне именно вашей квалификации, а не тех, кто пишет HAL... Судя теме, человек приводит описание ошибок с которыми он сталкивался, а также видно, что он их устранял, доводя проект до конца именно с использованием HAL. То есть не просто накидал, изменённую модификацию тестового примера от ST. Топикстартер просит поделится своим опытом, и картошка делится. А вы, извините, просто переходите на личности, и ссылаетесь при этом на "многих". Вас бы забанить за хамство. Напишите ... я использовал HAL реализовал 500 проектов такойто сложности. Хомутов не встречал. Тогда будет по теме топика. ЦитатаЕсли подитожить, многие здесь на форуме используют HAL, многие в МИРе используют HAL, обсуждений в интернете море. Но есть какой-то процент несостоявшихся гениев, у которых HAL не работает ВООБЩЕ, и поэтому они все пишут сами. Пишут они исключительно самый лучший, безглючный, эффективный и красивый код. Я уверен, это только их проблема, индивидуальная. Давайте будем точны. На самом деле вы не знаете сколько разработчиков в МИРе используют HAL, насколько они его изменяют, насколько они довольны результатами использования. То есть цена данному пассажу = 0. А далее опять банальное хамство. А ведь вас не оскорбляли. Здесь никого не отговаривают использовать HAL, тем более FreeRTOS и прочие вещи входящие в куб. Здесь просто обсуждают плюсы и минусы. На мой взгляд плюс один - достаточно быстрое вхождение. Минус - обратная сторона плюса. HAL является промежуточным уровнем, со всеми вытекающими. А именно: 1. Это новая сущность. Его надо изучить. Иначе как применять? Причём изучение само собой не вытекает из CPU, CPU ВСЁ равно изучить придётся, иначе применять будете коряво. Вот прямо простой пример по тексту обсуждения. По UARTу вам надо знать как он работает (какие режимы, как DMA обслуживается, как обработка ошибок осуществляется и так далее). Кроме того вам надо почитать как работает HAL (чем отличается один вызов от другого. Есть переменные и макросы специфичные). Иногда дополнительные данные ПРЯМО указаны в комментах на HAL, но далеко не всегда. Иногда они дублирующие. Иногда полностью не закрывают твои потребности. Чем лучше ты знаешь HAL - тем грамотнее и удачнее будет его применение. 2. HAL вещь универсальная. Он таким и должен быть. Причём к нему 2 прямо противоположных требования. Быть универсальным и быть простым. А так не бывает. В результате он становится всё более сложным и навёрнутым. Соответственно требует всё больше времени на изучение (см. п. 1). С другой стороны становится всё более громоздким, а значит медленным. И это неизбежно. Это противоречие, которое никогда не будет решено. 3. HAL это составная часть коммерческого продукта. Это маркетинговая программа. Это просто очевидно. ST заплатила нормальную сумму SEGGERу. Что просто так? Из любви к программистам? Заплатила пишущим индусам. Просто так? Ну это даже обсуждать не хочется. При этом одна из целей маркетинга - привязать клиента к своему продукту насмерть. Эта задача решается за счёт выполнения 2 условий: a) Простота использования решений только ST. б) Высокая сложность перехода с решений ST на решения других фирм. Куб справляется с этим заданием на 100%. Я уверен в сделке с SEGGER присутствует прямой запрет аналогичного использования их GUI с другими производителями на аналогичных условиях.
  3. Keil uVision ARM v 5.16a странное поведение

    Странно. Использовал _REV16 и аналогичные и в KEIL и в IAR - не замечал никаких глюков. Оптимизация максимальная по скорости. В кейле я сейчас не работаю. Проект был на старом месте работы. Как меняет IAR эти макросы - могу посмотреть, если хотите.
  4. STM32СubeMX и подобные

    Тоже метрологией занимаюсь. Спорить не буду, но считаю, что гарантом качества и безопасности может выступать только производитель. А всё остальное от лукавого. Все эти сертификаты - лишь бумажки. И лучше разработчика никто не оттестирует изделие. Понятно, что вылизывание - это самая длительная и, соответственно, самая дорогостоящая операция. Любой производитель всегда будет пытаться её минимизировать. Иначе возрастает, цена, неоправданно растут сроки и т.д. Любой производитель может сделать продукт лучше и надёжнее. Вот только вопрос - нужен ли он рынку. По теме вопроса - личное мнение я уже озвучивал. Считаю, что тема не особенно актуальна. Если рассматривать чисто обработку железа - то бишь драйвера - то это несколько процентов от общего объёма проекта. Если рассматривать всякие там GUI, OS и прочие входящие компоненты, то надо понимать, что это совершенно независимые разработки. Применение каждой из них должно рассматриваться в отрыве. Как правило драйвера, в том виде, в котором они написаны - просто не нужны. Я бы сказал бессмысленны и явно избыточны. Например, мне трудно представить проект, где органично бы вписался драйвер USART от ST. Возможно у меня фантазия слабая. Что ещё нехорошо, это то, что все библиотеки завязаны друг на друга. В результате, при использовании одного устройства благополучно подключается несколько других. Таким образом весьма проблематично использовать микс из своих и чужих дров и т.п. Есть проблемы и со своими. Я не заморачивась. Как правило пишу всётаки драйвера под конкретную задачу/ проект. А универсальность чуть повыше обеспечиваю. Правильно тут отмечали - часы должны идти независимо от того, откуда ты получаешь данные. Это же касается и всего прочего. Например, при изменении типа флэши, не должно быть существенного изменения проекта. Добавление нового протокола, не должно менять логику работы устройства и так далее..
  5. Многопроцессорность на STM32f4 STM32f7

    По моему, даже при наличии аппаратного порта (параллельного) с реализацией доступа из нескольких источников, при условии, что источников будет 10.... Ну и учитывая, что хотя бы один из них плотно сидит, то возникнут задержки на арбитраж, которые всю картину попортят. Поэтому напрашивается какой-то аппаратный арбитр с высокоскоростным последовательным интерфейсом на N каналов источников. Он должен обеспечить обмен и арбитраж. Я имею ввиду потратить один камень на разруливание и обмен... ))
  6. Работа с медленной периферией

    По АЦП в принципе согласен. У меня примерно та же картина была и я расчитывал, оказалось, что при spi 2MHz нет смысла городить огород. Накладные расходы по усложнению обработки режут всё в 0. То есть придётся смирится. Можно попробовать организовать аппаратно... Я не пробовал, если честно. У меня правда лишь один АЦП. Это упрощает. По 1820 картина попроще на самом деле. Если почитаете, то там диаграмма по всем слотам может в 2 раза отличаться, так что там критичного ничего нет. Формируйте диаграмму по прерыванию от таймера. 1820 уже не рекомендуют к применению. Это раньше был чудо прибор. Лет 10 назад. А сейчас лучше применять TI. И дешевле и точнее и удобнее. А в целом, тоже склоняюсь к варианту с периферийным процессором. Такие решения делал.
  7. LwIP обработка ошибок

    Давайте упрощу вопрос. Вот здесь http://www.ecoscentric.com/ecospro/doc/htm...h-callback.html вижу, что в событие NETCONN_EVT_RCVPLUS с длиной 0 приходят разные события... и ошибки, открытие и закрытие соединений. Открытие я определяю, так как идёт обращение к коннекту сервера. А как определить закрытие соединения? Кто подскажет?
  8. LwIP обработка ошибок

    Доброго времени суток. В приложении (FreeRTOS + LwIP) обрабатываю TCP/Modbus. Сделал несколько коннектов. Неблокирующее соединение + callback функция. Всё работает, пока всё корректно. Бывает, что при некорректном закрытии соединения (например вис сервера) у меня в callback функцию возвращается ошибка. Что с ней делать - ума не приложу. Глубоко стек копать не могу. У меня ещё, кроме того, если остановку проца в дебаге делаю, то ethernet отваливается. Пытаюсь закрыть соединение, но lwip возвращает ошибку (ERR_VAL -6 /* Illegal value.*/). Порывшись - вижу что pcb = 0, отсюда и ошибка. Собственно вопрос состоит в том, как обработать ошибку, чтобы я смог закрыть коннект и освободить память. Кто сталкивался?
  9. DMA2D в stm32f4хх

    Там можно было бы многое, но нет отрицательного смещения, нет дробного смещения. Иначе можно было бы выводить произвольные линии. А так только вертикальные и горизонтальные.
  10. DMA2D в stm32f4хх

    Цитата(Шаманъ @ Apr 21 2017, 13:26) Могу посоветовать перейти на RGB565, Сразу 2 зайца. И объём вдвое уменьшится и и выборка точки за раз будет осуществлятся. ) Цитататем более Ваш экран 24битный цвет скорее всего не поддерживает. Ну скорее не "не поддерживает", а "реально не отображает"... )
  11. IAR 8.10

    С вылетом разобрался. Короче вылет с крушением происходит в случае, если какой-то символ в файле есть. Скорее какой-то символ завершения файла. Скорее всего при редактировании внешнем редактором такое получилось. Открыл файл notepad-ом обрезал пару строк - сохранил - после этого всё заработало в родной среде. Решил пока не удалять его. Пишу небольшой проект новый. Решил попробовать от начала до конца написать его.
  12. Библиотеки для STM32

    Цитата(Forger @ Apr 19 2017, 09:56) На момент создания всего этого у меня было две задачи: убрать кучу кода инициализации пинов, спратав это внутрь одного файла (Pin.hpp), сохранить скорость работы ногодрыга. Оптимизация - это вторично. Главное - user-код изолирован от реализации Pin, который впоследствии можно безболезненно переделать. Какую кучу инициализации? Вы что бредите? Я пишу свой файл local где детально описываю все ноги, включая неиспользуемые. Описываю оборудование применяемое на ногах. Но не потому, что нет другого выхода. Потому что это способ сразу видеть схему, глазами программиста. Даже через несколько лет, я смогу восстановить схему, с точки зрения программиста. Это очень удобно, в том числе при отладке. То есть этот подход ничего общего не имеет к стилю написания, а имеет прямое отношение к стилю проектирования. Порты инициализирую сразу, а не попиново, но инициализация всё равно имеет мнемонику пинов, что не ухудшает переносимость. "Куча кода инициализации портов" получается 5/6 регистров на порт. Плюс не более 20 макросов управления ногодрыгом. И это на 144 ножный корпус. Причём макросы это не обязательно ногодрыг. Например подключен АЦП на SPI. DIN/DOUT(RDY). Я передаю, потом переключаю линию разрешаю прерывания по готовности и так далее. То есть это уже к класу ногодрыга не совсем относится, но по логике работы общая. Я не ратую за макросы. Сейчас это не рекомендуется. Можно оформить процедурами либо классами. Но зачем увязывать это с портами? И главное, мне не ответили в чём выигрыш? Если класс получается непереносимый, и его нельзя заимствовать? Зачем? Вот главный вопрос.
  13. Библиотеки для STM32

    Цитата(AHTOXA @ Apr 19 2017, 00:33) О, пришла пора мериться пинами! Внесу свою лепту: тынц. И что? Ещё раз повторяю. Совершенно бессмысленно. Приведу пример. Только что делал модификацию прибора. Изменилось количество каналов, полностью переразведена плата, на первой версии стояла отдельный МК который управлял клавой, светодиодами пищалкой и подключен был по I2C. В новой версии применили 595/165 SPI и отдельный таймер на пищалку. Отладку нового проекта производил на старой плате. При переносе старый файл local.h переименовал в local_v1.h. Добавил файл local_v2.h с данными новой платы, и написал local.h где переключатель хидеров. В main.h ввёл макрос выбора версии платы. Написал один файл обработки новой клавы и внёс некоторые изменения в инициализацию - прерывания (так как поменялись таймеры каналы spi и прочее). Думаю всего изменения коснулись строчек 10. У меня в main.h указываются дефайны типа spi_dataflash/ spi_adc. И всё! Проект компилится для двух версий плат. Чем поможет конструкция "PA5::On()"? По всему проекту её ловить? И что такое On? Я сейчас использую двухцветные светодиоды. Очень удобно Конструкция проще, информативность выше. И что даст ко всему этому PA5::On()? То есть нужен ещё слой, чтобы PA5::On превратился в удобоваримое powerled(red) или adc_cs_on. Я сейчас не о стилистике написания, поймите. Пусть стилистика будет ваша. Но применять по тексту основной программы обезличенные данные аппаратных ресурсов - тоже, что писать reg = 5. Это также недопустимо! Ни одной константы по тексту программы. Итак над этой хренью появляется ещё один файл абстракций. Итого 2. А у меня он 1. Сразу аппаратура в абстракцию. ====== Ну хорошо рассмотрим переносимость данного класса и его применимость в другом проекте. Ну и какая она? Громко заявлена, что она pin_stm32F4xx.h. То есть сразу же радуемся, что при использовании этой чудо хрени в stm32f0 мы в пролёте. Более того, при использовании её в f1 там придётся переписать половину. Но и это ещё не всё. Я утверждаю, что эта хрень не заработает даже на всех камнях F4. Почему? Поищите сами. Или наступите на грабли. При переносе на lpc это полностью переписать. И код использующий данный класс - тоже будет полностью переписан. Вот у меня теперь вопрос. В ЧЁМ ВЫИГРЫШ БРАТ?!!!
  14. Библиотеки для STM32

    Использовать универсальные дрова на ногодрыг бессмысленно. Внутри семейства это почти ничего не экономит, внутри одного проекта, наоборот городит, над семействами не живёт. И совершенно бессмысленно на уровне проекта. Так как pina.set или типа pinpwr.set - не создаёт переносимый код. Для этого надо что-то более удобоваримое. Ну типа POWERLED_ON или powerled(RED) по вкусу. А это требует ещё один уровень над той ээээ абстракцией, что вы написали. То есть, получается, что вы написали целый пустой уровень абстракции. Универсальных дров нижнего уровня тоже нет. Они избыточны и плохопереносимы. В результате их всё равно приходится допиливать. Ну там какие-нибудь spi ещё реальны или там i2c на ногодрыге. А уже USART будет колом даже внутри STM. Зато целесообразны дрова второго уровня: AT24, dataflash, modbus и тому подобное. Это действительно живёт годами. А со стилем, очень много - дело вкуса. Главное, чтобы автор хоть иногда смотрел, как пишут другие. Тогда, как правило, вопросов возникает мало.
  15. IAR 8.10

    Я ставил как обычно. То есть восьмёрку, потом активировал, потом сразу 8.1. Ну как бы и с самим приложением какие-то глюки, периодически. Я как бы уже отмечал, что с русским текстом проблема была. Потом так же внезапно прошла. Потом опять возникла и опять прошла. Поиграешься с настройками редактора, ничего не меняя - проходит. При загрузке проекта вылетает непонятное сообщение в лог. Tue Apr 18, 2017 11:26:14: IAR Embedded Workbench 8.10.1 (C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0_2\arm\bin\armproc.dll) Что к чему не понятно. Но проект компилится. Новый проект создавал ... по непонятным причинам начал вылетать при открытии без всяких видимых причин. С закрытием среды. При этом опять слетели настройки среды. Например число табуляций... Пересоздал проект - начал работать. Потом опять. Падает - пропадают настройки редактора. Короче какой-то бред. В настройках проекта появился новый способ подключения CMSIS. На уровне проца. При этом в настройках среды появилась подгрузка толи плагина то ли ещё чего. Пока не разобрался. Короче не работа а одна борьба со средой. Видел обработку UTF правда не заметил с какого момента она подключена. Может и раньше была, я просто не замечал. Раньше просто работала да и всё. Появились опции по работе с кучей. Короче - только лови. Теперь куча компилятора, куча ОС, куча какой-нибудь ещё составной части. Оно всё понятно, но на все эти разборки всё больше и больше времени уходит. Видно что изменений по среде очень много. За всеми этими галочками, что очевидно, стоят изменения в линкере, как минимум и в компиляторе. Видно, что они попытались локализацию на новую высоту поднять... )) Короче, продукт очень сырой, на мой взгляд. Я ещё поковыряюсь немного. Но что-то мне подсказывает, что придётся откатится на старую версию и подождать пока они хомуты устранят. Хотя бы крупные.