Ну, если можно на 422 перейти, то проще, конечно. Но если покупное изделие хочет 485, то тут ничего не поделать. Особенно, если оно уже 100 раз утверждено и закуплено.
Нет-нет, что вы. Там «высокопроизводительное RISC ядро» :) Просто регистры совпадают с Cortex M1. И система команд. И в примерах почему-то есть core_cm1.h. Но это просто совпадение, разумеется.
Задачи настолько специфические что не используют обмена по UART?
Так UART-то работает. И RS-232 или 422 тоже спокойно работал бы. Я полагаю, что оригинальному заказчику просто не нужен был 485.
И с остальными косяками наверняка такая же история.
Что касается миландра, то зачем им париться. Военные и ФСБшники всё равно купят, у них нет выбора, а ни один коммерческий проект в здравом уме и памяти всё равно их замечательные изделия использовать не будет по причине полной неконкурентоспособности.
Но мы ушли в сторону. TI к примеру вроде тоже никто не платит, за исходники, примеры и даже даташиты. Но они их делают, потому что их цель сделать полноценный продукт для конкуренции на глобальном рынке.
Насколько мне известно, американские производители микроэлектроники (те же TI в том числе) лет 30-40 точно так же жили за счет ВПК и госзаказа, смогли развернуть производство, подготовить кадры и т.д.
Просто это началось в 60-е. И сейчас у них совсем иная ситуация на рынке, потому что ВПК уже весь поделен и приходится бороться за потребительскую электронику.
У нас же аналогичные процессы только начинаются. И конкуренция у Миландра тоже есть — НИИЭТ, НИИСИ, Модуль (хотя с их продукцией я дела не имел).
Если что, я за Миландр не топлю, не подумайте :) Просто осознаю, что в текущих обстоятельствах действительно сложно сделать лучше. Видно, что они стараются.
ПО — это полностью их инициатива, за которую им никто напрямую не платит
— надо избавляться от такого подхода.
Я с вами полностью согласен! Но при этом отмечу, что к моему огромному неудовольствию, очень мало производителей микроэлектроники следует хорошим практикам разработки ПО.
Библиотеки от STM — это просто кладезь маразма, которые прячут другие макросы, которые прячут другие макросы и так без конца, динамическая память льется рекой. Публичного багтрекера нет, о косяках приходится писать на ооооочень медленном форуме где его может быть заметит модератор. Может быть. И перепостит во внутренний багтрекер.
Пока что радует только ARM, которые CMSIS на гитхаб выложили и следят за ним. И Кейл перетаскивают с самодельного компилятора на Clang.
Но в целом эмбеду еще очень далеко до хороших софтовых практик. Юнит-тесты? Пфф, компилируется — значит работает! Код-ревью? А зачем? Вжух-вжух и в продакшен!
Звучит правдоподобно, конечно, хотя и бездоказательно.
Ходит еще шутка, что спецификации студенты за зачет пишут, слишком уж опечаток много. И из-под картинок иногда вылезали «оригиналы» на английском.
Ну как сказать — работает. В примере от Миландра, где все через регистры, волшебные числа и написано очень странно — да, работает :) А через их же библиотеку — не работает.
Тогда в дело идет упомянутый «шлейфовый режим» — и вперед!
Ну он и пошел, собственно :)
Я только вот чего не пойму — что это за такие лояльные воены, которые на 485-й согласились вместо чего-нибудь фимозного/легаси? Они ж любят всякое эдакое…
По 485 подключались покупные датчики, которые мы сами выбирали :)
Если я правильно помню, то FIFO не зашел, потому что у какого-то девайса был ответ неизвестной заранее длины. Или прерывание не вылезало, когда должно было. Не, не помню, хоть тресни; впечатление осталось, а причину забыл.
Ну и аппаратная петля, конечно, вполне себе вариант, но у нас на момент обнаружения этого косяка было около 50 плат под лаком, с оформленным РКД и военной приемкой :)
Так делается у всех Cortex с Ethernet, эта память работает на частоте ядра и именно туда удобнее складывать данные с Ethernet.
Подозреваю, что у других Cortex это более доходчиво написано в даташите :)
Как это бесполезный? Если допустим у вас запрос-ответ протокола 16 или меньше байт — вы закидываете весь пакет в FIFO и вызываете только одно прерывание, когда сработал TXFE и остался последний байт в передатчике. Или например надо передать большой блок данных. У вас получается в 15 раз меньше вызовов прерывания.
Почему-то я был уверен, что FIFO на прием работает как-то не так, но за давностью лет в упор не помню, в чем там была проблема.
Строго говоря, у большинства Миландров честно купленное ядро Cortex — и оно работает как и должно. Почти все проблемы в периферии, а она вроде как не копированная ни с кого, а собственной разработки.
Ааа, вот тут очень хитро :) Единственная ошибка, вроде бы относящаяся к ядру — это ошибка тактирования SysTick. Но она есть только у 1986ВЕ1. А он, видите ли, не Cortex! Официально там «высокопроизводительное RISC-ядро», которое совершенно случайно практически идентично Cortex-M0. Абсолютно случайно.
Почему нет? В прерывании по приходу байта проверяем — мы в передаче или нет. Если нет — обрабатываем. Если в передаче — смотрим — последний это байт или нет, если нет — сразу выходим. При таких скоростях нагрузка на процесор никакая.
Ну, это понятно, просто на каждый отправленный байт будет по два прерывания.
Вообще-то можем, если на линии RS485 предусмотрели смещение.
Вас не затруднит раскрыть эту мысль? Боюсь, я не понял, как это поможет.
И с остальными косяками наверняка такая же история.
Насколько мне известно, американские производители микроэлектроники (те же TI в том числе) лет 30-40 точно так же жили за счет ВПК и госзаказа, смогли развернуть производство, подготовить кадры и т.д.
Просто это началось в 60-е. И сейчас у них совсем иная ситуация на рынке, потому что ВПК уже весь поделен и приходится бороться за потребительскую электронику.
У нас же аналогичные процессы только начинаются. И конкуренция у Миландра тоже есть — НИИЭТ, НИИСИ, Модуль (хотя с их продукцией я дела не имел).
Если что, я за Миландр не топлю, не подумайте :) Просто осознаю, что в текущих обстоятельствах действительно сложно сделать лучше. Видно, что они стараются.
Я с вами полностью согласен! Но при этом отмечу, что к моему огромному неудовольствию, очень мало производителей микроэлектроники следует хорошим практикам разработки ПО.
Библиотеки от STM — это просто кладезь маразма, которые прячут другие макросы, которые прячут другие макросы и так без конца, динамическая память льется рекой. Публичного багтрекера нет, о косяках приходится писать на ооооочень медленном форуме где его может быть заметит модератор. Может быть. И перепостит во внутренний багтрекер.
Пока что радует только ARM, которые CMSIS на гитхаб выложили и следят за ним. И Кейл перетаскивают с самодельного компилятора на Clang.
Но в целом эмбеду еще очень далеко до хороших софтовых практик. Юнит-тесты? Пфф, компилируется — значит работает! Код-ревью? А зачем? Вжух-вжух и в продакшен!
Ходит еще шутка, что спецификации студенты за зачет пишут, слишком уж опечаток много. И из-под картинок иногда вылезали «оригиналы» на английском.
То есть Миландр даже и не виноват, получается, это ARM — редиски! Вот это поворот.
По 485 подключались покупные датчики, которые мы сами выбирали :)
Если я правильно помню, то FIFO не зашел, потому что у какого-то девайса был ответ неизвестной заранее длины. Или прерывание не вылезало, когда должно было. Не, не помню, хоть тресни; впечатление осталось, а причину забыл.
Ну и аппаратная петля, конечно, вполне себе вариант, но у нас на момент обнаружения этого косяка было около 50 плат под лаком, с оформленным РКД и военной приемкой :)
Подозреваю, что у других Cortex это более доходчиво написано в даташите :)
Почему-то я был уверен, что FIFO на прием работает как-то не так, но за давностью лет в упор не помню, в чем там была проблема.
Не уверен, что делать так — это хорошая идея, но инфа интересная.
Вас не затруднит раскрыть эту мысль? Боюсь, я не понял, как это поможет.