Если мы сейчас начнем все косяки перечилсять, то весь день потратим :)
Но почему нет?
Вкратце, что мы нашли:
— Уровней приоритета прерываний 8, а не 16, как у STM.
— В GPIO нельзя просто писать в регистр RXTX, если на этому порту висит JTAG.
— Датчик температуры — не датчик и не температуры, использовать его нельзя.
— Делители частоты АЦП на самом деле идут только до 2048.
— Чтобы использовать прерывание от DMA, нужно запретить прерывания от SSP.
— LSI можно выключить, а от него питается Watchdog.
— Функции для работы с flash-памятью (которую Миландр упорно называет EEPROM) должны располагаться в RAM.
Плюс к этому на 1986ВЕ1:
— Нужно снимать галочку View->Periodic window update при использовании Кейла, иначе будет HardFault.
— Стирать flash из Кейла можно только целиком, посекторное стирание не поддерживается.
— Оператива делится на два куска, при этом код можно запускать только из второго, DMA может работать только со вторым и при прошивании можно использовать только второй кусок.
— SysTick считает медленнее, чем должен.
— Ethernet в SPL сломан, что смогли — пофиксили в форке. Стабильно работает только линейный режим.
— Доступ к внутреннему буферу Ethernet на запись должен быть кратен 4 байтам, если не кратен — то тихо записывается мусор. Соответственно, все счетчики и Delimiter должны быть всегда кратны 4, иначе будет черт знает что и внезапные HardFault'ы.
Мысль интересная, надо будет попробовать. С другой стороны, не хочется все время слышать эхо, а если RE и DE управлять отдельно, то придется еще одну ногу потратить.
Мы у них только готовые процы покупали, так что судить не берусь.
Тем не менее, по сравнению с другими отечественными микроконтроллерами, у Миландра все не так уж плохо — документацию можно скачать с сайта, а не запрашивать, отладочные комплекты можно купить (и даже не за космические деньги), на форуме отвечают хоть как-то, техподдержка тоже в наличии.
Но вообще, я не электронщик и не очень понимаю, что будет, если так сделать. Не уверен, что работа этих ног как-то стандартизирована среди разных микросхем.
Ну, их можно понять. Большая часть процессоров разработана для выполнения ОКР под конкретных заказчиков и их требования. Заказчики в основном военные и космос, им процы нужны под весьма специфические задачи. Эти задачи, судя по всему, процы выполняют.
Все остальное — пластиковые корпуса, форум, бесплатная техподдержка, отладочные комплекты, ПО — это полностью их инициатива, за которую им никто напрямую не платит. Под все это явно не хватает и денег и квалифицированных людей.
Не знаю, о каком именно чипе вы говорите, но, допустим, у 1986ВЕ1T все еще есть неисправленные ошибки в эррате.
Например,
«0011 Ошибка системного таймера
Статус
Будет исправлена только в случае замены ядра.»
Или «0014 Возникновение Hard Fault в режиме run time при отображении
содержимого периферии
Статус
Исследование.»
Плюс есть некоторое количество не столь фатальных ошибок, а, скорее, неприятных моментов. В эррате про них не пишут, на форуме на вопросы отмалчиваются.
Ну и основная документация страдает от некоторой эээммм скажем так недосказанности :).
Обидно, что они не переделывают периферию даже в своих инициативных работах (в смысле в тех, которые без заказчика).
В целом, боль, конечно, но я вынужден признать, что в России — это лучший производитель микроконтроллеров.
Да, мы в итоге так и делаем; почти случайно обнаружили, что «режим шлейфа» — это режим эха.
Тем не менее, постараюсь запилить в ближайшее время, видать, спрос есть :)
Прерывание передатчика работает по фронту, а не по уровню сигнала. В случае, если модуль и прерывания от него разрешены до осуществления записи данных в буфер FIFO передатчика, прерывание не формируется. Прерывание возникает только при опустошении буфера FIFO.
Ох как по больному-то месту вы прошлись сейчас!
У нас были постоянные проблемы с преобразованием UART'a в 485, потому что преобразователь нужно переключать в режим приема только после того, как на линию будет отправлен последний байт целиком.
Но в Миландре нет прерывания «передача завершена», только «буфер передатчика пуст». Для события «передача завершена» есть только флаг.
Если проверять флаг, то можно не успеть и переключиться на прием слишком поздно, когда другое устройство на шине уже начало что-то передавать — слишком позднее переключение отрезает от этой посылки кусочек бита.
Вопрос
Возможно, стоить пилить пост про то, как мы эту ситуацию в итоге разрулили?
Самое обидное, что Миландр не собирается переделывать периферию (по большей части) и этот UART так и будет переезжать в новые процы :(
Еще более странно, что ни в одном зарубежном МК я с такой ситуацией не сталкивался, везде было прерывание по событию «передача завершена». А в миландре — нету.
При этом, у НИИЭТ тоже есть МК на ядре ARM Cortex (К1921ВК01Т), и в тамошнем UART'e тоже нет такого прерывания. Совпадение? Или по Зеленограду кочует один и тот же UART?
А мой пример и на AVR будет работать точно так же :) godbolt.org/z/hKWNlb
Тут как раз стандарт языка дает объяснение:
Спойлер
Переполнение знаковых целых — это неопределенное поведение! Т.е. с точки зрения компилятора это что-то такое, чего никогда не происходит. Ведь программист не допустит неопределенного поведения :)
А раз это никогда не происходит, значит обычный int не переполняется и проверку на это можно не делать.
А вот для беззнаковых переполнение точно определено, оно может произойти, поэтому компилятор вынужден вставлять проверку.
Тем не менее, можно с уверенностью заявить, что интерпретация содержимого регистров и памяти, как без-знаковых чисел, позволяет производить ряд операций (например, сдвиги или расширение значения) с ними проводить быстрее и порождает более компактный код, поэтому может быть настоятельно рекомендована при написании программ для МК, если иное (интерпретация как числа сщ знаком)не является обязательным условием.
Не могу сходу согласиться с таким радикальным предложением, поскольку нашли вы его эмпирически для одной конкретной ситуации.
Взгляните, например, вот на такой пример — godbolt.org/z/lW6rk8 — (courtesy в сторону презентации самого товарища Godbolt'a «What has my compiler done for me lately»).
Даже очень вдумчивое чтение стандартов С, по моему мнению, не заменяет проверки на практике. И зачастую просто смотреть на ассемблер и считать команды тоже недостаточно, особенно на архитектурах с большим конвейером, кэшом и всякими предсказателями переходов. Я понимаю, статья какбы про AVR, но в старших Cortex'ах это потихоньку появляется…
10) своей собственной среды разработки, интегрированной с перечисленными компонентами
Нет, нет, нет, пожалуйста, не надо! Сколько можно клепать убогие среды разработки для каждого чипа, в которых потом 25 лет добавляют простейшие вещи типа автокомплита?
У Миландра уже был такой опыт — для 1886 была (и все еще есть, к сожалению) IDE DevC++ и свой великолепный, ослепляющий своим совершенством компилятор CC7A, который давится строчками длиннее 10 символов.
Спасибо, не надо вот этого вот. Есть условно-нормальные Keil и IAR, есть Eclipse, NetBeans и VSCode, не надо в миллионый раз изобретать IDE с нуля, ничего хорошего из этого не выйдет.
Особенно, если основное направление деятельности — разработка чипов, а не программирование!
У того же Миландра есть примеры под Keil, они компилируются, иногда даже работают сразу — и хорошо, и слава богу.
Ну, я же не говорю, что никогда вообще не нужно на ассемблере писать, порой и правда приходится. Вот только мне кажется, что это происходит настолько редко, что ради этого писать свой редактор — это очень сильно перебор. Мне вот, натурально, это требовалось раза 3-4 за всю жизнь, причем и тогда можно было выехать на интрисинках компилятора, просто я об этом еще не знал.
Компилятор компилятору рознь, тут по всякому бывает в зависимости от множества факторов. Но в большинстве случаев вроде все хорошо. Разумеется, это еще и от задач зависит, у нас хитрой обработки сигналов как-то не попадалось, видимо.
Но вот синус мы уже считаем на этапе компиляции :)
Мне кажется, это можно понять и не программируя на ассемблере самостоятельно :) Например, читать дизассемблерный листинг, который любая IDE для С умеет показывать. Конечно, этот листинг сильно отличается от рукописаного кода на асме, но если все же программировать на С, то навык чтения этого листинга оказывается достаточно полезен сам по себе.
Это я все к тому, что даже с самым божественно-крутым редактором для ассемблера, писать на С все равно проще и легче; а если очень хочется, то можно ассемблерную вставку сделать.
Основной вопрос такой — а вам действительно нужно в 2019 году писать на ассемблере под достаточно мощный и быстрый STM32, вместо того, чтобы писать на С и С++? Т.е. есть какие-то задачи, где С/C++ не подходит? Если так, то не могли бы вы немножко рассказать о своих задачах?
Или вам просто хочется/нравится писать на ассемблере? Если так, то вопросов более не имею :)
Но почему нет?
Вкратце, что мы нашли:
— Уровней приоритета прерываний 8, а не 16, как у STM.
— В GPIO нельзя просто писать в регистр RXTX, если на этому порту висит JTAG.
— Датчик температуры — не датчик и не температуры, использовать его нельзя.
— Делители частоты АЦП на самом деле идут только до 2048.
— Чтобы использовать прерывание от DMA, нужно запретить прерывания от SSP.
— LSI можно выключить, а от него питается Watchdog.
— Функции для работы с flash-памятью (которую Миландр упорно называет EEPROM) должны располагаться в RAM.
Плюс к этому на 1986ВЕ1:
— Нужно снимать галочку View->Periodic window update при использовании Кейла, иначе будет HardFault.
— Стирать flash из Кейла можно только целиком, посекторное стирание не поддерживается.
— Оператива делится на два куска, при этом код можно запускать только из второго, DMA может работать только со вторым и при прошивании можно использовать только второй кусок.
— SysTick считает медленнее, чем должен.
— Ethernet в SPL сломан, что смогли — пофиксили в форке. Стабильно работает только линейный режим.
— Доступ к внутреннему буферу Ethernet на запись должен быть кратен 4 байтам, если не кратен — то тихо записывается мусор. Соответственно, все счетчики и Delimiter должны быть всегда кратны 4, иначе будет черт знает что и внезапные HardFault'ы.
Тем не менее, по сравнению с другими отечественными микроконтроллерами, у Миландра все не так уж плохо — документацию можно скачать с сайта, а не запрашивать, отладочные комплекты можно купить (и даже не за космические деньги), на форуме отвечают хоть как-то, техподдержка тоже в наличии.
По идее, все это болезни роста.
Все остальное — пластиковые корпуса, форум, бесплатная техподдержка, отладочные комплекты, ПО — это полностью их инициатива, за которую им никто напрямую не платит. Под все это явно не хватает и денег и квалифицированных людей.
Например,
«0011 Ошибка системного таймера
Статус
Будет исправлена только в случае замены ядра.»
Или «0014 Возникновение Hard Fault в режиме run time при отображении
содержимого периферии
Статус
Исследование.»
Плюс есть некоторое количество не столь фатальных ошибок, а, скорее, неприятных моментов. В эррате про них не пишут, на форуме на вопросы отмалчиваются.
Ну и основная документация страдает от некоторой эээммм скажем так недосказанности :).
А что за решения вы имеете в виду?
В целом, боль, конечно, но я вынужден признать, что в России — это лучший производитель микроконтроллеров.
Тем не менее, постараюсь запилить в ближайшее время, видать, спрос есть :)
Ох как по больному-то месту вы прошлись сейчас!
У нас были постоянные проблемы с преобразованием UART'a в 485, потому что преобразователь нужно переключать в режим приема только после того, как на линию будет отправлен последний байт целиком.
Но в Миландре нет прерывания «передача завершена», только «буфер передатчика пуст». Для события «передача завершена» есть только флаг.
Если проверять флаг, то можно не успеть и переключиться на прием слишком поздно, когда другое устройство на шине уже начало что-то передавать — слишком позднее переключение отрезает от этой посылки кусочек бита.
Самое обидное, что Миландр не собирается переделывать периферию (по большей части) и этот UART так и будет переезжать в новые процы :(
Еще более странно, что ни в одном зарубежном МК я с такой ситуацией не сталкивался, везде было прерывание по событию «передача завершена». А в миландре — нету.
При этом, у НИИЭТ тоже есть МК на ядре ARM Cortex (К1921ВК01Т), и в тамошнем UART'e тоже нет такого прерывания. Совпадение? Или по Зеленограду кочует один и тот же UART?
Тут как раз стандарт языка дает объяснение:
А раз это никогда не происходит, значит обычный int не переполняется и проверку на это можно не делать.
А вот для беззнаковых переполнение точно определено, оно может произойти, поэтому компилятор вынужден вставлять проверку.
Не могу сходу согласиться с таким радикальным предложением, поскольку нашли вы его эмпирически для одной конкретной ситуации.
Взгляните, например, вот на такой пример — godbolt.org/z/lW6rk8 — (courtesy в сторону презентации самого товарища Godbolt'a «What has my compiler done for me lately»).
Даже очень вдумчивое чтение стандартов С, по моему мнению, не заменяет проверки на практике. И зачастую просто смотреть на ассемблер и считать команды тоже недостаточно, особенно на архитектурах с большим конвейером, кэшом и всякими предсказателями переходов. Я понимаю, статья какбы про AVR, но в старших Cortex'ах это потихоньку появляется…
Нет, нет, нет, пожалуйста, не надо! Сколько можно клепать убогие среды разработки для каждого чипа, в которых потом 25 лет добавляют простейшие вещи типа автокомплита?
У Миландра уже был такой опыт — для 1886 была (и все еще есть, к сожалению) IDE DevC++ и свой великолепный, ослепляющий своим совершенством компилятор CC7A, который давится строчками длиннее 10 символов.
Спасибо, не надо вот этого вот. Есть условно-нормальные Keil и IAR, есть Eclipse, NetBeans и VSCode, не надо в миллионый раз изобретать IDE с нуля, ничего хорошего из этого не выйдет.
Особенно, если основное направление деятельности — разработка чипов, а не программирование!
У того же Миландра есть примеры под Keil, они компилируются, иногда даже работают сразу — и хорошо, и слава богу.
Компилятор компилятору рознь, тут по всякому бывает в зависимости от множества факторов. Но в большинстве случаев вроде все хорошо. Разумеется, это еще и от задач зависит, у нас хитрой обработки сигналов как-то не попадалось, видимо.
Но вот синус мы уже считаем на этапе компиляции :)
Это я все к тому, что даже с самым божественно-крутым редактором для ассемблера, писать на С все равно проще и легче; а если очень хочется, то можно ассемблерную вставку сделать.
Или вам просто хочется/нравится писать на ассемблере? Если так, то вопросов более не имею :)