Comments 61
Так надо понимать, что реакция Миландра на эти проблемы чисто совковая: вот вам изделие и разруливайте проблемы сами.
Ну, их можно понять. Большая часть процессоров разработана для выполнения ОКР под конкретных заказчиков и их требования. Заказчики в основном военные и космос, им процы нужны под весьма специфические задачи. Эти задачи, судя по всему, процы выполняют.
Все остальное — пластиковые корпуса, форум, бесплатная техподдержка, отладочные комплекты, ПО — это полностью их инициатива, за которую им никто напрямую не платит. Под все это явно не хватает и денег и квалифицированных людей.
Все остальное — пластиковые корпуса, форум, бесплатная техподдержка, отладочные комплекты, ПО — это полностью их инициатива, за которую им никто напрямую не платит. Под все это явно не хватает и денег и квалифицированных людей.
Думаю, отношение к оборонке точно такое-же. Аппаратно-то все соответствует. А все остальное — это уже проблемы программиста.
Мы у них только готовые процы покупали, так что судить не берусь.
Тем не менее, по сравнению с другими отечественными микроконтроллерами, у Миландра все не так уж плохо — документацию можно скачать с сайта, а не запрашивать, отладочные комплекты можно купить (и даже не за космические деньги), на форуме отвечают хоть как-то, техподдержка тоже в наличии.
По идее, все это болезни роста.
Тем не менее, по сравнению с другими отечественными микроконтроллерами, у Миландра все не так уж плохо — документацию можно скачать с сайта, а не запрашивать, отладочные комплекты можно купить (и даже не за космические деньги), на форуме отвечают хоть как-то, техподдержка тоже в наличии.
По идее, все это болезни роста.
Полностью так. И приходится городить костыли (у нас было реализовано задержкой просто). Ну и еще — очень классно, когда вместо прерывания по фронту GPIO-input есть только по уровню.
Если мы сейчас начнем все косяки перечилсять, то весь день потратим :)
Но почему нет?
Вкратце, что мы нашли:
— Уровней приоритета прерываний 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'ы.
Но почему нет?
Вкратце, что мы нашли:
— Уровней приоритета прерываний 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'ы.
Ну Ethernet хоть как-то работает. А то когда на вопрос «а как с вашие езернетом работать?», получаешь «а мы его сами не проверяли, если заставите — напишите нам как у вас это получилось», лицо несколько перекашивается и в голову лезут неприличные извращенные мысли с участием разработчиков камня.
Дело в том, что в Миландре почти всей разработкой занимаются только что закончившие ВУЗ студенты. Некоторые модули были взяты с минимальными переделками из предыдущих серий их PIC процессоров.
Причем все это в Зеленограде, где еще остались специалисты — разработчики.
Причем все это в Зеленограде, где еще остались специалисты — разработчики.
Звучит правдоподобно, конечно, хотя и бездоказательно.
Ходит еще шутка, что спецификации студенты за зачет пишут, слишком уж опечаток много. И из-под картинок иногда вылезали «оригиналы» на английском.
Ходит еще шутка, что спецификации студенты за зачет пишут, слишком уж опечаток много. И из-под картинок иногда вылезали «оригиналы» на английском.
Ну есть ещё старички — мой хороший знакомый предпенсионного возраста там трудится например. Зрелые разработчики в самом расцвете сил конечно там особо не задерживаются.
Если они делают по спецификации Cortex, то должно быть все, что указано в спецификации, CMSIS должен работать у всех производителей, хоть у Миландр, хоть у LPC, разве нет?
Иначе это нарушение спецификации и слово «кортекс» надо брать в кавычки, это обычный «Почин», где у них «Группен-секс», а мы им ответим нашим «бригаден-семером».
Иначе это нарушение спецификации и слово «кортекс» надо брать в кавычки, это обычный «Почин», где у них «Группен-секс», а мы им ответим нашим «бригаден-семером».
Ааа, вот тут очень хитро :) Единственная ошибка, вроде бы относящаяся к ядру — это ошибка тактирования SysTick. Но она есть только у 1986ВЕ1. А он, видите ли, не Cortex! Официально там «высокопроизводительное RISC-ядро», которое совершенно случайно практически идентично Cortex-M0. Абсолютно случайно.
совершенно случайно практически идентично Cortex-M0. Абсолютно случайно.
Очень напоминает одного моего китайского поставщика кабелей с проприетарными разъемами. Продают как то, что должно работать, по факту имеем такие допуски, что кабель приходится из эталонной «мамы» плоскогубцами вытаскивать. Но вообще совместим, да.
Мне почему-то помнится, что в ве1 ядро Cortex M1, которое предназначено для применения в плисинах. Оригинальный камень. В одном изделии использовали их для Ethernet стыка. Ради справедливости должен отметить, что по сравнению с теми же Элвисовскими камнями миландровские изделия исключительно user-friendly как с точки зрения документации, так и технической поддержки в форуме.
Задачи настолько специфические что не используют обмена по UART?
Уверен, что там и с SPI и с I2C косяков не меньше, только бороться ембеддерам с ними ещё сложнее.
Что касается миландра, то зачем им париться. Военные и ФСБшники всё равно купят, у них нет выбора, а ни один коммерческий проект в здравом уме и памяти всё равно их замечательные изделия использовать не будет по причине полной неконкурентоспособности.
Так что у них вполне разумная маркетинговая политика.
которая теперь мне не светит — заплаченные мной налоги. Я бы мог их не платить и сделать накопления на старость самостоятельно, но у меня нет альтернативы, приходится вместо этого финансировать Миландры.
Но мы ушли в сторону. TIк примеру вроде тоже никто не платит, за исходники, примеры и даже даташиты. Но они их делают, потому что их цель сделать полноценный продукт для конкуренции на глобальном рынке.
По этой причине мне в кошмарном сне не привидится разработать устройство на Миландре, ну а работающие на ВПК будут вынуждены и дальше тратить своё время и деньги не столько на программный продукт, сколько на костыли для обхода багов. Однако им же даёт их, и щедро даёт, государство. Полетит или не полетит ракета сегодня особо никого не волнует, всё равно поставят на вооружение — ядрёная то война психологическая, а не реальная. Это вот с самолётами проблема — они реально летать должны. Видимо именно поэтому новых моделей даже в эпоху «прорыва» что то не видать. В основном модификация того, что успели сделать коммунисты продвигаясь по своему «особому пути» до тех пор, пока не надорвались под тяжестью военных расходов.
Уверен, что там и с SPI и с I2C косяков не меньше, только бороться ембеддерам с ними ещё сложнее.
Что касается миландра, то зачем им париться. Военные и ФСБшники всё равно купят, у них нет выбора, а ни один коммерческий проект в здравом уме и памяти всё равно их замечательные изделия использовать не будет по причине полной неконкурентоспособности.
Так что у них вполне разумная маркетинговая политика.
ПО — это полностью их инициатива, за которую им никто напрямую не платит— надо избавляться от такого подхода. Вы ещё напишите что пенсии нам государство платит. Нет, пенсия
Но мы ушли в сторону. TI
По этой причине мне в кошмарном сне не привидится разработать устройство на Миландре, ну а работающие на ВПК будут вынуждены и дальше тратить своё время и деньги не столько на программный продукт, сколько на костыли для обхода багов. Однако им же даёт их, и щедро даёт, государство. Полетит или не полетит ракета сегодня особо никого не волнует, всё равно поставят на вооружение — ядрёная то война психологическая, а не реальная. Это вот с самолётами проблема — они реально летать должны. Видимо именно поэтому новых моделей даже в эпоху «прорыва» что то не видать. В основном модификация того, что успели сделать коммунисты продвигаясь по своему «особому пути» до тех пор, пока не надорвались под тяжестью военных расходов.
Задачи настолько специфические что не используют обмена по UART?Так UART-то работает. И RS-232 или 422 тоже спокойно работал бы. Я полагаю, что оригинальному заказчику просто не нужен был 485.
И с остальными косяками наверняка такая же история.
Что касается миландра, то зачем им париться. Военные и ФСБшники всё равно купят, у них нет выбора, а ни один коммерческий проект в здравом уме и памяти всё равно их замечательные изделия использовать не будет по причине полной неконкурентоспособности.
Но мы ушли в сторону. TI к примеру вроде тоже никто не платит, за исходники, примеры и даже даташиты. Но они их делают, потому что их цель сделать полноценный продукт для конкуренции на глобальном рынке.
Насколько мне известно, американские производители микроэлектроники (те же TI в том числе) лет 30-40 точно так же жили за счет ВПК и госзаказа, смогли развернуть производство, подготовить кадры и т.д.
Просто это началось в 60-е. И сейчас у них совсем иная ситуация на рынке, потому что ВПК уже весь поделен и приходится бороться за потребительскую электронику.
У нас же аналогичные процессы только начинаются. И конкуренция у Миландра тоже есть — НИИЭТ, НИИСИ, Модуль (хотя с их продукцией я дела не имел).
Если что, я за Миландр не топлю, не подумайте :) Просто осознаю, что в текущих обстоятельствах действительно сложно сделать лучше. Видно, что они стараются.
ПО — это полностью их инициатива, за которую им никто напрямую не платит
— надо избавляться от такого подхода.
Я с вами полностью согласен! Но при этом отмечу, что к моему огромному неудовольствию, очень мало производителей микроэлектроники следует хорошим практикам разработки ПО.
Библиотеки от STM — это просто кладезь маразма, которые прячут другие макросы, которые прячут другие макросы и так без конца, динамическая память льется рекой. Публичного багтрекера нет, о косяках приходится писать на ооооочень медленном форуме где его может быть заметит модератор. Может быть. И перепостит во внутренний багтрекер.
Пока что радует только ARM, которые CMSIS на гитхаб выложили и следят за ним. И Кейл перетаскивают с самодельного компилятора на Clang.
Но в целом эмбеду еще очень далеко до хороших софтовых практик. Юнит-тесты? Пфф, компилируется — значит работает! Код-ревью? А зачем? Вжух-вжух и в продакшен!
У моего поста не было цели наезда на «Миландр». Скорее даже наоборот, я пытался объяснить что экономико-политическое устройство определяет политику компаний. И другими они в сегодняшних российских реалиях быть и не могут. Их продукция конкурентоспособна только в узком кругу. В условиях самоизоляции нет воможности выхода на глобальные рынки, без этого не опустишь цену. Нет у них ресурса и стимула на «допил» продукта. Немногочисленные клиенты уже изучили их косяки и научились подставлять под них костыли. Новых всё равно нет. В таких условиях лучше направить ресурс на клонирование следующего, более современного камня, чем доводить до ума старый.
Тут вынужден согласиться. Кроме того замечу что и у ведущих производителей с новыми камнями немало косяков случается, но они их фиксят, выпускают ерраты и в следующей ревизии исправляют ошибки
Проблема в том, что мир за 40 лет стал другим. Он стал глобальным и такая тактика уже лет 20 как не работает. Сейчас высокие технологии рождаются в гражданских фирмах, а потом их заимствуют военные. В сегодняшнем мире попытки развития технологий по шаблону 40 летней давности не сработают, а только увеличат отставание и разорит страну.
Библиотеки от STM — это просто кладезь маразма
Тут вынужден согласиться. Кроме того замечу что и у ведущих производителей с новыми камнями немало косяков случается, но они их фиксят, выпускают ерраты и в следующей ревизии исправляют ошибки
Насколько мне известно, американские производители микроэлектроники (те же TI в том числе) лет 30-40 точно так же жили за счет ВПК и госзаказа, смогли развернуть производство, подготовить кадры и т.д.
Проблема в том, что мир за 40 лет стал другим. Он стал глобальным и такая тактика уже лет 20 как не работает. Сейчас высокие технологии рождаются в гражданских фирмах, а потом их заимствуют военные. В сегодняшнем мире попытки развития технологий по шаблону 40 летней давности не сработают, а только увеличат отставание и разорит страну.
Если вы можете себе позволить перемычку (в идеале – управляемую) между ногами RX и TX, то всё тоже хорошо.
Так она у вас УЖЕ ЕСТЬ. Вам же достаточно повесить nRE на землю и всё — у вас на выходе ресивера появится всё, что вы передаёте.
В том конкретном случае мы так сделать не могли, потому что плат уже изготовлено много, они под лаком, а ноги nRE и DE объединены.
Но вообще, я не электронщик и не очень понимаю, что будет, если так сделать. Не уверен, что работа этих ног как-то стандартизирована среди разных микросхем.
не очень понимаю, что будет, если так сделать
Просто ресивер не выключается и продолжает принимать все данные с шины — как свои, так и чужие.
Не уверен, что работа этих ног как-то стандартизирована среди разных микросхем.
По сути стандартизирована — практически все драйвера RS485 pin-to-pin compatible.
Мысль интересная, надо будет попробовать. С другой стороны, не хочется все время слышать эхо, а если RE и DE управлять отдельно, то придется еще одну ногу потратить.
не хочется все время слышать эхо
Почему нет? В прерывании по приходу байта проверяем — мы в передаче или нет. Если нет — обрабатываем. Если в передаче — смотрим — последний это байт или нет, если нет — сразу выходим. При таких скоростях нагрузка на процесор никакая.
Как бы то ни было, мы не можем опустить RE-DE сразу по входу в это прерывание, потому что так мы «отрежем» от нашего последнего байта стоп-бит или часть стоп-бита.
Вообще-то можем, если на линии RS485 предусмотрели смещение.
Почему нет? В прерывании по приходу байта проверяем — мы в передаче или нет. Если нет — обрабатываем. Если в передаче — смотрим — последний это байт или нет, если нет — сразу выходим. При таких скоростях нагрузка на процесор никакая.Ну, это понятно, просто на каждый отправленный байт будет по два прерывания.
Вообще-то можем, если на линии RS485 предусмотрели смещение.Вас не затруднит раскрыть эту мысль? Боюсь, я не понял, как это поможет.
Дело в том, что смещение принудительно переводит свободно висящую линию в состояние «1», а стоп-бит — это как раз «1» на линии. Поэтому даже если мы отключаем передатчик от линии во время стоп-бита, то на линии продолжает висеть «1» за счёт смещения.
Главное — чтобы другая сторона не начала передачу во время стоп-бита, иначе будет ошибка фрейминга (не знаю — детектируется она здесь или нет). Но это уже проблемы другой стороны :)
Главное — чтобы другая сторона не начала передачу во время стоп-бита, иначе будет ошибка фрейминга (не знаю — детектируется она здесь или нет). Но это уже проблемы другой стороны :)
просто на каждый отправленный байт будет по два прерывания
Можем тупо отключить прерывание на приём до тех пор, пока оно не будет нужно.
Когда-то программировал для контроллера СКУД, порты на контроллере могли переключаться в режимы 232/422/485. Ридер карточек подключался по двум проводам, вроде как в режиме 485. Если на контроллере включать режим 485, то связи не было. Пришлось на контроллере просто соединить RX-TX по линиям +- в режиме 422. И после отправки команды условно в 20 байт, приходилось первые 20 пришедших байт ответа просто отбрасывать.
Советский союз всегда умел скопировать устройство правильно, дешево и качественно, сейчас же даже скопировать толковые вещи не могут! Видно что создаются вещи только что б выкачивать деньги через дырку в гос. бюджете называемую «Оборонпром», являющиеся приоритетной при составления затрат на год!
Пруф
Я хоть и с Украины, но я б лучше купил русский аналог добротный, чем китайский оригинал, но увы не в этом столетии с такими то чиновниками и программами!
Пруф
Я хоть и с Украины, но я б лучше купил русский аналог добротный, чем китайский оригинал, но увы не в этом столетии с такими то чиновниками и программами!
Строго говоря, у большинства Миландров честно купленное ядро Cortex — и оно работает как и должно. Почти все проблемы в периферии, а она вроде как не копированная ни с кого, а собственной разработки.
Насколько я понял из документации на контроллеры от Миландра, модуль UART там тоже покупной — ARM PL011. Вот его документация: ссылка.
Там прямо структурные схемы в документации от Миландра и ARM практически совпадают.
Я бегло просмотрел документацию на PL011, и не увидел информации о наличии нужного прерывания.
Там прямо структурные схемы в документации от Миландра и ARM практически совпадают.
Я бегло просмотрел документацию на PL011, и не увидел информации о наличии нужного прерывания.
А вот это интересная информация! Действительно, выглядит похоже. А где вы в документации Миландра это разглядели?
То есть Миландр даже и не виноват, получается, это ARM — редиски! Вот это поворот.
То есть Миландр даже и не виноват, получается, это ARM — редиски! Вот это поворот.
Да не то чтобы редиски… Повторюсь лишний раз про старый добрый 16550, который в свое время считался «золотым стандартом», и были даже такие странные люди, которые вопили «в новом микроконтроллере от %company name% контроллер UART полностью 16550-совместимый!», так что я не удивлюсь, если это задумка такая — не делать ничего, чем не баловали во времена старых бородатых эмбеддеров.
Случайно обнаружил документацию на PL011, когда гуглил что-то связанное с UART. Названия регистров там везде одинаковые.
Вот здесь прямо PL011 упоминается, кое-где гуглинг выдает упоминания PL010.
Замечу, что там вроде бы не только UART покупной, но и еще какие-то модули, когда-то на форуме Миландра находил такую информацию.
Вот здесь прямо PL011 упоминается, кое-где гуглинг выдает упоминания PL010.
Замечу, что там вроде бы не только UART покупной, но и еще какие-то модули, когда-то на форуме Миландра находил такую информацию.
Очень похоже на работу SPI в stm32f030, там тоже SPI_SR_BSY ловить, но [вроде] можно и в прерывание по приёму слова с того-же пина. По даташиту так получается, но пока не пробовал.
Как ни странно, ни разу не испытывал потребности в прерываниях от SPI, всегда хватало просто задрать скорость и тупо флаги поллить блокирующе.
Обычно нужно перекинуть два-три байта, вполне можно себе позволить.
Обычно нужно перекинуть два-три байта, вполне можно себе позволить.
и режим FIFO, на мой взгляд, совершенно бесполезный. Если кто-нибудь понимает, зачем он нужен, расскажите, пожалуйста!
Как это бесполезный? Если допустим у вас запрос-ответ протокола 16 или меньше байт — вы закидываете весь пакет в FIFO и вызываете только одно прерывание, когда сработал TXFE и остался последний байт в передатчике. Или например надо передать большой блок данных. У вас получается в 15 раз меньше вызовов прерывания.
— Оператива делится на два куска, при этом код можно запускать только из второго, DMA может работать только со вторым и при прошивании можно использовать только второй кусок.
Так делается у всех Cortex с Ethernet, эта память работает на частоте ядра и именно туда удобнее складывать данные с Ethernet.
Так делается у всех Cortex с Ethernet, эта память работает на частоте ядра и именно туда удобнее складывать данные с Ethernet.
Подозреваю, что у других Cortex это более доходчиво написано в даташите :)
Как это бесполезный? Если допустим у вас запрос-ответ протокола 16 или меньше байт — вы закидываете весь пакет в FIFO и вызываете только одно прерывание, когда сработал TXFE и остался последний байт в передатчике. Или например надо передать большой блок данных. У вас получается в 15 раз меньше вызовов прерывания.
Почему-то я был уверен, что FIFO на прием работает как-то не так, но за давностью лет в упор не помню, в чем там была проблема.
Так делается у всех Cortex с Ethernet, эта память работает на частоте ядра и именно туда удобнее складывать данные с Ethernet.
У STM32F107(Cortex-M3, есть интегрированный MAC) не припомню такого.
Во-первых спасибо за статью, надо Хабр разбавлять подобным!
Во-вторых все-таки должен сказать, что повторная попытка пнуть лежачего все так же неубедительна. Я чесгря не в курсе был прошлый раз, что вы имеете в виду под «шлейфовым режимом» (т.к. «Миландр» — не моя тема), а оказалось, что это более чем няшка, решающая вопрос весьма элегантно. Но и без него норм, вам An_private расписал ровно то, о чем я в комментариях в прошлый раз говорил. Наверное мне просто повезло, но в основном всегда можно было сделать петлю уже на «физике», управляя сигналами DE/RO.
В одной из плат была реализована хитрость, деталей которой я уже не помню, когда DE управлялся де-факто потоком данных, правда для этого использовалась некоторая логика (там как раз пол-CPLD без дела простаивало, туда и пристроили), ну и конечно смещение на стороне «физики» было. Правда это уж совсем костыль, как по мне, к тому же «железячный» (что как бы не круто).
В этом месте я подумал, что вы издеваетесь… Как это зачем?!
Если проблемы были именно с приемом, то там могли быть некорректно работающие или, что вероятнее, некорректно использованные interrupt reasons. У тех же 16550 были весьма кучерявые режимы выдачи прерываний, как-то плохо уже их помню, но хитрости были, да. И это общее место у многих других контроллеров UART. К слову, я лично обнаруживал, что у нативного SerialPort в дотнете threshold входного буфера на некоторых компах работает некорректно, что со слов одного чувака якобы имеет восходит корнями к кривым СОМ-портам на материнках и не менее кривым драйверам оных.
Во-вторых все-таки должен сказать, что повторная попытка пнуть лежачего все так же неубедительна. Я чесгря не в курсе был прошлый раз, что вы имеете в виду под «шлейфовым режимом» (т.к. «Миландр» — не моя тема), а оказалось, что это более чем няшка, решающая вопрос весьма элегантно. Но и без него норм, вам An_private расписал ровно то, о чем я в комментариях в прошлый раз говорил. Наверное мне просто повезло, но в основном всегда можно было сделать петлю уже на «физике», управляя сигналами DE/RO.
В одной из плат была реализована хитрость, деталей которой я уже не помню, когда DE управлялся де-факто потоком данных, правда для этого использовалась некоторая логика (там как раз пол-CPLD без дела простаивало, туда и пристроили), ну и конечно смещение на стороне «физики» было. Правда это уж совсем костыль, как по мне, к тому же «железячный» (что как бы не круто).
режим FIFO, на мой взгляд, совершенно бесполезный. Если кто-нибудь понимает, зачем он нужен, расскажите, пожалуйста!
В этом месте я подумал, что вы издеваетесь… Как это зачем?!
Если проблемы были именно с приемом, то там могли быть некорректно работающие или, что вероятнее, некорректно использованные interrupt reasons. У тех же 16550 были весьма кучерявые режимы выдачи прерываний, как-то плохо уже их помню, но хитрости были, да. И это общее место у многих других контроллеров UART. К слову, я лично обнаруживал, что у нативного SerialPort в дотнете threshold входного буфера на некоторых компах работает некорректно, что со слов одного чувака якобы имеет восходит корнями к кривым СОМ-портам на материнках и не менее кривым драйверам оных.
Спасибо :)
Если я правильно помню, то FIFO не зашел, потому что у какого-то девайса был ответ неизвестной заранее длины. Или прерывание не вылезало, когда должно было. Не, не помню, хоть тресни; впечатление осталось, а причину забыл.
Ну и аппаратная петля, конечно, вполне себе вариант, но у нас на момент обнаружения этого косяка было около 50 плат под лаком, с оформленным РКД и военной приемкой :)
Если я правильно помню, то FIFO не зашел, потому что у какого-то девайса был ответ неизвестной заранее длины. Или прерывание не вылезало, когда должно было. Не, не помню, хоть тресни; впечатление осталось, а причину забыл.
Ну и аппаратная петля, конечно, вполне себе вариант, но у нас на момент обнаружения этого косяка было около 50 плат под лаком, с оформленным РКД и военной приемкой :)
Ну и аппаратная петля, конечно, вполне себе вариант, но у нас на момент обнаружения этого косяка было около 50 плат под лаком, с оформленным РКД и военной приемкой
Тогда в дело идет упомянутый «шлейфовый режим» — и вперед!
Я только вот чего не пойму — что это за такие лояльные воены, которые на 485-й согласились вместо чего-нибудь фимозного/легаси? Они ж любят всякое эдакое…
Тогда в дело идет упомянутый «шлейфовый режим» — и вперед!Ну он и пошел, собственно :)
Я только вот чего не пойму — что это за такие лояльные воены, которые на 485-й согласились вместо чего-нибудь фимозного/легаси? Они ж любят всякое эдакое…
По 485 подключались покупные датчики, которые мы сами выбирали :)
Я правильно понял, что "военная приёмка" — это чистой воды профанация? Иначе как объяснить наличие 50 неработающих плат, которые прошли такую приёмку?
Видимо под лаком и военной приемкой скрыт еще один баг. В такой организации шины стоп бит и идле шины не отличимы. И выключение драйвера не должно было что то менять. Видимо на шине нет подтяжек, чтобы пустая она была в 1. И эти треть бита нужны были чтобы успели включиться драйверы внешних датчиков.
И вам везет что по приему вы успеваете включить свои драйверы до отключения внешних и шина не проваливается в непонятное ничто.
И да, потенциально вы порождаете конфликты на шине.
А может проще было на четырёхпроводку перейти? Линии приёма и передачи будут разделены, или там затейливая топология?
Sign up to leave a comment.
RS-485 на отечественных микроконтроллерах от фирмы Миландр