Список разделов Flyback.org.ru » не HV » Микроконтроллеры и всё, что с ними связано
Тему сейчас просматривают - зарегистрированных: 0, скрытых: 0 и гостей: 0
Зарегестрированные - Нет
Ответить с цитатой

Николай
 


какая интересная штука получается. аврка через hc-12 принимает 30байт (в ascii значения 6 шим-каналов), считает crc8 и если все ОК то выставляет значения шимов. если нет то переспрашивает.
все бы хорошо. иногда. реедко но бывает - срабатывает ошибка по crc. ну ок. бывает.
а вот примерно с 10% вероятностью crc не срабатывает, но в одном или нескольких каналах шима выставляется поебень.
я могу поверить в вероятность такой помехи, чтобы crc сходилась. но эта вероятность должна быть априори меньше чем такой ошибки, когда crc не сходится.

формировал вручную ошибочные посылки - отбрасывает. сыпал в канал мусор - отбрасывает.

как так может быть - каждая десятая примерно посылка ошибочна, но crc8 у ней сходится!?

при присоединении проводным каналом - все заебись.

Добавлено: Sun Jan 20, 2019 5:52 pm
Ответить с цитатой

N1X
 


Возможно баг в коде... Т.е. дело не в crc например...

Добавлено: Sun Jan 20, 2019 6:09 pm
Ответить с цитатой

Break_Neck
 


ну начать с контрольки не с простой суммой, а что нить из серии црц16 с полиномом( она позиционо-зависима - и перестановка даных местами в длином пакете вызывает изменения црц). Неправильная контролька запрещает какие либо манипуляции и обьявляет принятый пакет недействительным, + после проверки обычно порчу(зануляю) црц в массиве что под прием организован. А дальше - уже отладка покажет.

Добавлено: Sun Jan 20, 2019 9:21 pm
Ответить с цитатой

Николай
 


контролька не суммой. crc8 полиномом.

в коде бага нету. он прост как тапок. на эмуляторе гоняется, на проводном канале гоняется. глюков нету.

приемный массив заполняется видом >[addr]********************[CRC]\r (все символы ascii - любые другие отбрасываются)
символ > ставит указатель байта буфера на 0, сбрасывает флаг корректности пакета. символ \r начинает проверку crc, и если все ok то ставит флаг корректности пакета, отсылает мастеру "OK".
если стоит флаг корректности то парсим буфер.

как не старался - руками не могу воссоздать ошибку. кривые пакеты отбрасывает нормально

Добавлено: Sun Jan 20, 2019 9:42 pm
Ответить с цитатой

N1X
 


А если запустить известную последовательность пакетов и при получении неожиданного значения подробно залогировать? Или ответом слать не "ок", а лог транзакции?

Добавлено: Sun Jan 20, 2019 10:02 pm
Ответить с цитатой

Николай
 


панимаш. на столе, без подключения к силовухе глюков нету. а когда стоит на своем месте - он должен отсылать только положенное ему.
повешу паралельно логер.
без шима та же прошивка работает без глюков.
парсер заполняет массив[16] данными из приемного буфера.
переменные 1...10 отрабатывают как должно. а переменные 11...16 - иногда глючат.
проблема в том что тот контроллер который пользует 1..10 и тот, который 11...16 стоят в разных местах. один шимит, воторй нет.
который шимит тот глючит, который релюхами щелкает тот не глючит. прошивки идентичные

сразу скажу - ошибки заборного столба нету. массив на всяк случай размером 18 :-D


Последний раз редактировалось: Николай (Sun Jan 20, 2019 10:21 pm), всего редактировалось 1 раз
Добавлено: Sun Jan 20, 2019 10:16 pm
Ответить с цитатой

Ivani
 


А шум с эфира он случаем не дешифрует?

Вот про CRC16 https://habr.com/ru/post/428746/

Я для себя придумал "подписывать" важные пакеты второй CRC16 с ключом.

Добавлено: Sun Jan 20, 2019 10:17 pm
Ответить с цитатой

Николай
 


> А шум с эфира он случаем не дешифрует?
неа. если нет пакетов для него (с его адресом) - ни единого глюка. хотя в эфире постоянно пакеты бегают (передатчик просто дублирует проводную шину)


в эфире постоянно куски пакетов бегают. но в буфере контроллера смешаться не могут. так как символы начала и конца пакета обнуляют все.
а вот в буфере передатчика HC-12 могут. делал паузу в шине, в 5сек. чтобы буфер передатчика ушел в эфир и в нем куски пакетов не накладывались. такая же фигня.

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

а тут наоборот. на сто посылок - 10 кривых но с верной crc, и 1 с кривой crc

вот это не могу объяснить


Добавлено: Sun Jan 20, 2019 10:27 pm
Ответить с цитатой

Ivani
 


Ну логичное объяснение одно - с падением уровня сигнала появляются ошибки приема которые СТМ в приемнике "корректирует" удачно.

Добавлено: Sun Jan 20, 2019 10:38 pm
Ответить с цитатой

Николай
 


но вероятность кривой crc ведь больше чем правильной

Добавлено: Sun Jan 20, 2019 11:02 pm
Ответить с цитатой

Warlock_Wolf
 


если есть время. в дальнем поставь эмулятор пакета. чтоб 100 процентов контроллер слал все правильно. пусть даже один и тот же пакет. а на приеме , пиши все что не так пришло. если за сутки будут только шибки с црс. и все пакеты правильные. значит дело не в канале. в полях с данными, ставишь 0 1 2... 254..0 1 2. если принял не подряд, в лог. если принял с ошибкой црц в лог.

Добавлено: Mon Jan 21, 2019 12:11 am
Ответить с цитатой

Николай
 


нашел! может кому пригодится.
сделал паузы между передачей байт - глючить перестало. потом завел реальные пакеты (без пауз) в непрерывном режиме в эмулятор и смотрел приемный буфер. иногда кусок посылки выкидывало. да так, что crc сходилось. вот это уже интересно. то что схоилась crc это случайное сочетание передаваемых для соседних устройств байт.
а выкидывало потому, иногда контроллер ходил в прерывания и мог проебать хлебную карточку. как оказалось crc тоже не спасает от исчезновения целых нескольких байт.
думал что уж от такого crc точно спасет. но хуй в ухо

вывод - проверяйте DOR.

Добавлено: Mon Jan 21, 2019 3:19 pm
Ответить с цитатой

Анна
 


Можно еще каждый пакет скремблировать изменяющейся (от пакета к пакету) псевдослучайной последовательностью. Тогда даже если наложатся хвосты от разных пакетов, то CRC скорее всего не сойдутся..

Добавлено: Tue Jan 22, 2019 12:47 am
Ответить с цитатой

Николай
 


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

требовалась стабильность частоты при работе в уличном устройстве. без использования кварца. RC гена плывет из-за питания и из-за температуры. первое делать стабильным просто. а второе немного посложнее.
придумал и испытал такой изврат - всем известно что убить выход тиньки коротышем практически невозможно. используем сопротивление выхода в качестве грелки, а внутренний термометр в качестве мерялки.
внутренний термометр конечно показывает в попугаях, но попугаи повторяемы. но нам не абсолютная температура нужна, а ее изменение. соответвенно греем до скажем до 40'C и меряем это значение. на него и завязываем термостатирование.
пользуем ненужную ножку. скажем reset. её нагружаем мелким смд резистором в 5...10ом. и шимим с небольшой частотой. чтобы излишне не перегревать перегрузкой феты выхода.
на корпус махонький кусочек пенопласта.

данная конструкция поддерживала 40 +-2'C при забортной до -20. стабильность частоты была порядка 0.5%

Добавлено: Wed Feb 20, 2019 1:23 am
Ответить с цитатой

N1X
 


Спокойнее всеже мелкий ключ и внешний резистор на крышку чипа )))

Добавлено: Wed Feb 20, 2019 8:33 am
Ответить с цитатой

Николай
 


иногда устройства могут быть маленькими. очень маленькими.

располагаю данными более чем двухлетних ресурсных испытаний на коротыши. тини своей ногой раз в три секунды на 300мс коротит на землю кап 5В 470мкФ. и вообще не парится относительно этого. и не в единичном экземпляре. пока не одна не сдохла
у них довольно высокоомные ключи. использую их в качестве измерительных шунтов для измерения тока ножки без единой дополнительной детали. один канал диф.ацп на питание, второй канал к выходу. при подключении нагрузки к ножке на выходном фете падает напряжение, которое ацп и меряет.

Добавлено: Wed Feb 20, 2019 12:55 pm
Ответить с цитатой

Электромонтёр
Экспериментатор


Народ, а кто-нить пробовал прогать ARM Cortex-M0 на асме? Ткните в мануал по GCC AS, а то методом тыка приходится синтаксис изучать, почему-то при указании -mthumb нужно синтаксис ARM писать. Имеется в наличии российский кристалл К1986ВК234 на оном ядре с голым даташитом, изготовитель не заморачивался библиотеками для него... Сабж поддерживает только голый thumb, вроде бы и проц и мощный, но кастрированный донельзя. Подробное описание команд здесь http://www.gaw.ru/html.cgi/txt/doc/micros/arm/a...m_thumb/index.htm наши ещё адреса периферии неудобно (для этого кристалла) раскидали.

Добавлено: Tue Mar 26, 2019 6:05 am
Ответить с цитатой

sergh
 


говорят что в Венесуэле недавно Блэкаут был вроде из-за активации вируса для контроллеров Siemens - Stuxnet
И типа пол-мира им заражено, особенно пром. объекты стран, неугодных США.
Вообще инфа в статьях из инета не профешнл, для обывателя:

https://www.securitylab.ru/contest/448355.php

https://m.habr.com/ru/post/123030/

хотя, вспоминая пакостный древний Siemens S5, думаю что с такими контроллерами и без вируса могло.

Добавлено: Wed Mar 27, 2019 10:07 am
Ответить с цитатой

Николай
 


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

Добавлено: Sat Jun 08, 2019 2:28 pm
Ответить с цитатой

Анна
 


Оно с али?

Добавлено: Sat Jun 08, 2019 2:30 pm
Ответить с цитатой

Николай
 


нет. с али никогда ничего не беру. с чипа. но уже много лет ничего не глючило никогда
маркировка та же. отличий от старых в мелкоскоп не вижу

Добавлено: Sat Jun 08, 2019 2:46 pm
Ответить с цитатой

Анна
 


Мне тут тоже попалась фигня, правда с "ядерным" глюком. Всё вроде работает, но не проходит команда инкремента, причем только с нижним банком регистров (r0..r15). Если задаешь команду на инкремент регистра из верхнего банка (inc r17 например), то работает. Если из нижнего - тупо ничего не происходит... регистры не изменяются. Вот такая печалька.

Что-то современные авки мне перестают нравиться.
Или это после того как Атмел отдался Микрочипу, они сливают эти авки... или просто уровень производства свалился... Или идут массовые сбросы отбраковки...

Раньше работало всё дубово и железобетонно, хоть "5" лепи...

Добавлено: Sat Jun 08, 2019 3:31 pm
Ответить с цитатой

SilverRay
 


Тоже столкнулся с проблемами в работе периферии свежих мег 128А. Сильное ощущение, что микрочип специально гробит авры

Добавлено: Sat Jun 08, 2019 3:49 pm
Ответить с цитатой

Николай
 


Затестил. Таймер тикает. А вот две переменные дотикивают до FF и дальнейший инкремент не обнуляет их. Т.е. FF+1=FF БЛЯ.
Надеюсь что это чип говна закупил. Поеду туда, где оригинальность гарантируется прямыми закупками у микрочипа. И надо самотестирование сделать

328 в дипе из чипдипа не работали половину портов на выход. У всех моделей при компиляции винавром. А avrstudio норм. Думал глючный винавр. А потом залил тоже самое в соик коопус - все заработало. Чудеса. Такое чувство что это копии чипов.
Хотя в чипе давали посмотреть бобину. Там реквизиты микрочипа вроде нормальнын

Добавлено: Sat Jun 08, 2019 10:53 pm
Ответить с цитатой

Dizel
Хаотично добрый эльф


Николай писал(а):
Там реквизиты микрочипа вроде нормальнын - а может китайцы сделали подделку совсем похожую на оригинал ?
вскрыть корпус и посмотреть в микроскоп ?

Добавлено: Sat Jun 08, 2019 11:15 pm
Список разделов Flyback.org.ru » не HV » Микроконтроллеры и всё, что с ними связано
На страницу Пред.  1, 2, 3 ... 119, 120, 121 ... 151, 152, 153  След.     Просмотр темы целиком



Лицензионное соглашение

(c)Flyback.org.ru
Российское общество любителей высоких напряжений.
Использование материалов с данного сайта и форума возможно только с разрешения администрации.