galjoen

Чем же это железная реализация надёжнее софтовой? На мой взгляд, как раз наоборот. И периодически вылавливаемые в CAN-овском железе баги это подтверждают. И не известно есть они там или нет. А в софтовой можно все ошибки выгрести - запись логов при работе достаточно сделать. Кстати, для софтового CAN-а можно и ATtiny2313 использовать - ещё дешевле. А для гарантии, при использовании с софтового CAN-а, можно использовать драйвер с ограничением времени доминанты и всё. Поэтому я и написал про его стоимость $1 .

У меня софтовый CAN до 500 килобод живёт на ATmega48 за $1. Для выключателя/лампочки ничего больше и не надо. Неужели $2 ($1 контроллер + $1 драйвер) дорого?

При использовании в CAN девайсах современных защищённых приёмопередатчиков, с ограничение времени доминанты (0), вероятность подвешивания всей сети одним девайсом несоизмеримо меньше, чем при использовании сети с RS485 приёмопередатчиками, которые, к тому же, могут подвешивать сеть и 0 и 1. Хотя, ради справедливости нужно сказать, что если в модбасе заменить все приёмопередатчики на CAN-овские, эффект будет то же. Но это возможно только при использовании достаточно высокой скорости.

Конечно курил оба, иначе бы не писал. От модбаса у меня впечатления какой то убогости осталось. Единственное его преимущество в простоте реализации - любой студент-двоечник осилит. Да ещё на 1816ве48 он запросто реализуется. Ну и если использовать его для соединения точка-точка, то недостатки не так заметны. Но в наше время, делать на нём сеть, да ещё на АРМе - это из пушки по воробьям.

http://electronix.ru/forum/index.php?showt...21258&st=15 А схема там в сообщении N27. Офф. А почему вы без запятых пишите? Понимаю с трудом.

Можно собрать такую штуку, которая будет определять откуда в сеть пришло сообщение. Т.е. можно будет слушать только сообщения, пришедшие от определённого девайса или сегмента сети. Схема на базе CAN-хоста - см. в разделе CAN. Только нужно чуть изменить.

Т.е. пишите в анализатор только то, что послал в сеть VCDS или все сообщения?

Я не экстрасенс, поэтому спрошу... Что не получается? Окно не опускается, или VCDS не посылает, или ещё что-нибудь?

А чем же J1708 не устраивает? Аналог CAN-а во всём кроме быстродействия (9600), а быстродействие там, как я понимаю, ни к чему. Т.е. не во всём, конечно, сказывается ограничение UART-ов. Но эти ограничения в маленькой сети не проявятся. Ну не нужны там тысячи уровней приоритета и т.п. А вот быстродействие, кстати, поднять без проблем можно - просто CAN-овские драйвера поставить и будет мегабит. А по реализации не сильно сложнее модбаса (которому давно на кладбище пора). Кстати, а не является ли модбас переложением J1708? Специфическим переложением, конечно, типа переложения фуги Баха для сольного исполнения на барабане.

Если хотите просто и мультимастерно, то я рекомендовал бы сделать по стандарту J1708 (автомобильный). Там используются трансиверы RS485, но передача идёт по входу DI. Т.е. 0 на шине устанавливается передатчиком, а 1 за счёт резисторов. Для такого применения даже специальные RS485 трансиверы делаются (не нужен инвертор). Соединение - звезда. Общая длина до 50 метров (вроде). Из-за такого включения скорость всего 9600, но надёжность очень велика. Проверена временем в тяжёлых автомобильных условиях... Ещё можно вместо RS485 трансиверов, в таком включении, CAN-овские использовать. Собственно CAN из J1708 то и вырос...

Не понял, вы считаете, что между проверками выполняется ВСЯ программа? Да собственно, и не так важно однократное выполнение битой команды. На 80% это приведёт к срабатыванию ватчдога. Так же может сработать контроль стека, основных регистров и т.д. Но важно, чтобы работа при наличии ошибки не продолжалась. Кстати, у меня всё в лог пишется. Так я ещё ни одного запуска процессора по срабатыванию ватчдога там не видел, тем более ошибки CRC. Но это не значит, что ватчдог не нужен. У меня в той программе пришлось несколько таблиц во второй половине FLASH отдать пользователю, соответственно CRC32 там не считается. CRC32 я считаю по самодельному производящему многочлену, чтобы зная многочлен не изменили область памяти так, что общая CRC32 останется такой же. Странно, а что почитать из кана никто не может? Пусть там даже и зашифровано всё. Поставить фильтр не некоторые ID, и подменять их...

Не только внешний eeprom, я о тех случаях, когда программа пишется для уже имеющегося устройства, причём чужой разработки. Не знаю, как вы считаете шансы, м.б. объясните, но у меня получается более 50%. 1. Запорчен код исполняемой команды, которая выполнилась не правильно -> ватчдог, зацикливание на подсчёте CRC. 2. Запорчен код исполняемой команды, которая не выполнилась -> зацикливание на подсчёте CRC. 3. Запорчены данные в таблице -> зацикливание на подсчёте CRC. В моём случае это была защита от продолжительной работы с испорченными данными в таблице. Вот это самое страшное, что может случится. Цикл подсчёта CRC32, которая считается по байту за раз, для всего флеша составляет 1..2 секунды. Ну вот и получается, что через 2 секунды такая ситуация будет отловлена. А за 2 секунды ничего страшного в принципе случится не может. Ну а самый главный аргумент, это то, что такая защита делается очень просто. Побитное вычисление CRC32 по слову за раз, с вызовами, таблицами и т.д. - у меня это 88 строчек на асме, и 6 байт ОЗУ. И кочует из проекта в проект. Не понимаю, о чём тут спорить?

У меня так: А в доступных для АВРСИМУЛЯТОР 2 кристаллах не вижу ни одного с 128 кбайт флеша и чтобы у него RAMPZ0 был bit0 по адресу 0x3B. А м.б. 1000 слов мало для сбоя? Вот у меня на 2-м блоке сбивается: 0x7E...0x1CB6 - это 0x1C38 = 7224 слов 14448 байт.

Раз уж зашла речь по автомобили, то там как раз это нужно. Допустим кто-то написал прошивку для ЭБУ, откатал на машине, и не хочет чтобы другие таблицы его настроек меняли (тюнинговали). А прошивку эту зашифровать в принципе невозможно - ну нет в загрузчике у стандартного ЭБУ никакого шифрования. И таблицы скрыть/зашифровать тоже невозможно, т.к. прошивка на 70% из них состоит. Да на расшифровывание и времени нет. Вот тут как раз проверка приложением собственной целостности и нужна. Ну ладно, что то мы от темы отошли. Пока не проверил я АВРСИМУЛЯТОР2 - нет доступа к широкому каналу интернета, чтобы последнюю версию AVR Studio скачать.

Хотел MD5 в загрузчике считать, но там места для этого не хватило. А зачем защиту в процессоре ломать, если можно просто обновлённое приложение в виде hex-файла скачать? Хоть и в зашифрованном виде. А уже потом сломать. Ресурс флеша 10000 записей... Вот тут MD5 в загрузчике помогла бы, но нет её с сожалению... А во многих случаях как раз от изменения нужно защищать, а не от копирования. На примере простейшего загрузчика с шифрованием, который здесь выкладывался, расскажу как защиту ломать. У того загрузчика просто ксорились страницы flash таблицей 256 байт. Тут уже некоторые байты известны т.к. в таблице переходов наверняка jmp/rjmp стоят. Но даже и без этого можно сломать. Достаточно менять по 1 байту до тех пор пока не попадёшь на какое-нибудь сообщение во flash. А у 99% сообщения из flash выводятся. Ну вот, сразу и будет видно какая там таблица ксоров. А дальше уже просто на другой странице свой кусочек кода добавляется.

Да, повышает, и ирония тут не уместна. Если по 1-му байту за раз потихоньку CRC считать. И запускать подсчёт по нечастому событию, только не по таймеру. И по несовпадению флаг выставлять (через указатель), а реагировать на него в других местах... При размере прошивки в несколько десятков килобайт такую защиту найти нереально. И, соответственно, в такой прошивке изменить что-либо нереально. Ах да. Ещё нужно какой-нибудь малоизвестный производящий многочлен использовать. Можно даже самодельный. Иначе изменят так, что CRC совпадёт...

Эти запреты с целью защиты от копирования сделаны. Там, даже прерывания разрешаются только если таблица прерываний в загрузчике. Т.е. это защита от восстановления кода команды по произведённым ею изменениям. А я о том, что программа должна с любым загрузчиком работать. И при отсутствии загрузчика вообще. Переносимость. Да и запустить программирование FLASH, при работе с несоответствующим загрузчиком есть вероятность. В т.ч. поэтому вызовов быть не должно. А считать собственное CRC приложение просто обязано - не только контроль FLASH, но без этого защита от копирования крайне малоэффективной становится... Спасибо, нашёл. Там у меня AT90CAN128 в списке нет. Сейчас посмотрю у кого, из тех, что есть, 128 FLASH и RAMPZ0 на том же месте. Нет, сначала новую версию скачаю. М.б. там есть?

Доступ к загрузчику из приложения д.б. запрещён!

Честно сказать - не знаю. А где выбирается симулятор? М.б. у меня и нет АВРСИМУЛЯТОРА 2? Версия AVR Studio то старая, а не обновлял т.к. давно АВРом не занимался. Да ещё боюсь, что в новых версиях новые глюки... Вон в ассемблере Version 1 - если в .dw неописанную метку поставить, он не ругнётся, а просто 0 туда подставит. А какой глюк в Version 2 я уже не помню. Какой то сложный, что то с арифметическими вычислениями, с деленим на 0 что ли? Но главное, что у них глюки разные. Т.е. если обоими оттранслировать, и там и там чисто, то и в действительности всё нормально. А руки с мылом перед едой имеет смысл мыть? Девайс не для атомной, а для дизельной станции.

.SET BgLd=LARGEBOOTSTART-0x1000; начало таблицы CRC16 1021 (2110) .SET Lo1021=high(BgLd<<1); ук-ль на 256 младших байт .SET Hi1021=high((BgLd<<1)+0x100); ук-ль на 256 старших байт ..... .org BgLd .db 0x00, 0x21, 0x42, 0x63, 0x84, 0xA5, 0xC6, 0xE7; т.е. это Lo1021 00e000 2100 00e001 6342 00e002 a584 00e003 e7c6 .... .db 0x00, 0x10, 0x20, 0x30, 0x40, 0x50, 0x60, 0x70; т.е. это Hi1021 00e080 1000 00e081 3020 00e082 5040 00e083 7060 Бут тоже считает CRC приложения. Но это приложение работает не выключаясь месяцами (т.е. в бут не заходит), хотя 80% времени спит, просыпаясь по часам раз в секунду на пару милисекунд. Проверяет не нужно ли поработать, и в 99.9% случаев снова засыпает. Но если решит, что нужно поработать, то перед работой посчитает свою CRC, а также CRC ОЗУ. Там есть ещё множество подобных фич, но они к теме не относятся... И вообще, предлагаю не отклонятся от обсуждения глюка в отладчике.

Вот таблица с CRC_Bx и CRC_Ex. Это обычные метки, стоящие в начале и конце блока, в котором считается CRC TbFlAd:; таблица адресов подсчёта CRC у Flash 001cab 0000 001cac 004a .dw CRC_B1, CRC_E1; начало (включительно) и конец (исключительно) 001cad 007e 001cae 1cb6 .dw CRC_B2, CRC_E2 001caf 1cb9 001cb0 2859 .dw CRC_B3, CRC_E3 001cb1 2880 001cb2 5e53 .dw CRC_B4, CRC_E4 001cb3 5e80 001cb4 64b2 .dw CRC_B5, CRC_E5 001cb5 ffff .dw 0xFFFF; признак конца этой таблицы Вот таблица правильной CRC и пример установки меток CRC_Xx: CRC_E4:; конец 4-го блока во FLASH, где надо считать CRC TbCRC16: .db 0x2C, 0xA8; CRC-16 Flash (для контроля), тут CRC не считаем CRC_B5:; начало 5-го блока во FLASH, где надо считать CRC Вот адрес FLAC и несколько строк после FLAC3: FlAC:; готовимся к подсчёту CRC-16 FLASH Приложения 001a45 24cc eor RBN0,RBN0; обнуление CRC .......... FlAC3:; CRC-16 подсчитано - сравним с тем, что д.б. 001a70 e7e0 ldi ZL,low(TbCRC16<<1); Z = адрес 001a71 e3f9 ldi ZH,high(TbCRC16<<1); правильного CRC-16 001a72 91a5 lpm XL,Z+ ; м.б. того, что д.б. 001a73 91b4 lpm XH,Z ; с.б. того, что д.б. 001a74 25ac eor XL,RBN0 ; порксорим тем, 001a75 25bd eor XH,RBN1 ; что получилось 001a76 2bab or XL,XH ; =0 -> совпало 001a77 f479 brne ChBd16 ; Z=0 - CRC не совпало И что же там такого оригинального? На мой взгляд совершенно тривиальный подсчёт CRC16. Приложение считает свою CRC. А дырки в нём возникают потому, что стоят .org для выравнивания адреса или, как в примере, само значение CRC для контроля. Маленькие куски действительно считаются и отлаживаются нормально. А большие - нет. Причём независимо от попадания адреса на сам считающий CRC код. http://electronix.ru/forum/index.php?showt...&hl=galjoen ЗЫ А вообще, здесь принято обращаться на вы.

Вылетает на адрес сброса. Если там установлен 0, то с 0 начинает команды выбирать. Если установить 0xF000, то пишет, что оттуда неверный опкод прочитан (это приложение, у меня загрузчик в другом проекте) Сейчас ещё поэкспериментировал. Оказывается вылетает на подсчёте CRC16 FLASH. .DEF RBN0=R12 .DEF RBN1=R13 FlAC:; готовимся к подсчёту CRC-16 FLASH Приложения eor RBN0,RBN0; обнуление CRC eor RBN1,RBN1; аккумулятора ldi ZL,low(TbFlAd<<1); Z - ук-ль на таблицу блоков ldi ZH,high(TbFlAd<<1); с подсчётом CRC во FLASH movw R1:R0,ZH:ZL; сохраним адрес в R0, R1 FlAC1: movw ZH:ZL,R1:R0; ук-ль на таблицу адресов lpm YL,Z+ ; адрес начала lpm YH,Z+ ; очередного блока add YL,YL ; перейдём от rol YH ; слов к байтам ; при увеличении кода сверх FFFF так работать не будет brcs FlAC3 ; C=b15=1 -> посчитано, на сравнение lpm XL,Z+ ; адрес конца lpm XH,Z+ ; очередного блока add XL,XL ; перейдём от rol XH ; слов к байтам movw R1:R0,ZH:ZL; сохраним адрес таблицы в R0, R1 sub XL,YL ; X = конец - начало (в байтах) sbc XH,YH ; = кол-во байт в блоке (сч-к) FlAC2:; цикл вычисления CRC байта из FLASH wdr ; сбросим Watchdog (попытка справится с отладчиком) movw ZH:ZL,YH:YL; адрес во FLASH (байтовый) adiw YH:YL,1 ; inc адреса счётных байт lpm ZL,Z ; очередной байт из FLASH (токо до FFFF!) eor ZL,RBN1 ; проксорим данные с.б. старого CRC ldi ZH,Hi1021; там с.б. таблицы 2110 elpm RBN1,Z ; это с.б. т.к. таблица переставлена eor RBN1,RBN0; получили с.б. нового CRC ldi ZH,Lo1021; там м.б. таблицы 2110 elpm RBN0,Z ; м.б. CRC просто из таблицы ; вычислено CRC очередного байта sbiw XH:XL,1 ; уменьшим счётчик brne FlAC2 ; циклимся (подсчёт CRC-16 блока) rjmp FlAC1 ; циклимся (переход к след. блоку) FlAC3:; CRC-16 подсчитано - сравним с тем, что д.б. ..... TbFlAd:; таблица адресов подсчёта CRC у Flash .dw CRC_B1, CRC_E1; начало (включительно) и конец (исключительно) .dw CRC_B2, CRC_E2 .dw CRC_B3, CRC_E3 .dw CRC_B4, CRC_E4 .dw CRC_B5, CRC_E5 .dw 0xFFFF; признак конца этой таблицы RAMPZ0=1, поэтому lpm обращается к 1-й половине FLASH, а elpm ко 2-й. Во второй половине по адресу Hi1021 лежит выровненная (мл. байт адреса =0) таблица ст. байтов CRC 1021. Lo1021 - соответственно младшие байты. Но это, скорее всего, не сыграет. Всё остальное в 1-й половине FLASH. Когда подсчитывается небольшой блок, то всё нормально. Но при большом отладчик вылетает на адрес запуска. Кстати, а не при подсчёте ли того блока, в котором находится эта самая программа? Надо будет проверить. Прерывания запрещены, введение сброса WD в цикл не повлияло... Ах да, процессор AT90CAN128. Последними билдами AVR Studio не пользовался т.к. вообще давно AVR не занимался. Но судя по тому, что глюк с невозможностью программирования загрузчика из hex-файла с помощью AVRISPMK2 кочует из версии в версию, думаю, что и этот глюк присутствует в поздних версиях...

Новые темы создаются не только с вопросами. Но и с новостями и т.д. Прочитайте правила...

Вот пришлось вернуться к своему старому проекту на AVR (на асме написанному). Когда его ваял - пользовался AVR Studio v3.56. А сейчас использовал v4.16. Слегка изменил перетранслировал - всё нормально. Там у меня кое какие вычисления делаются. Такая же программа и для компа есть. Но куда то я задевал её. Но на AVR то тоже самое считается. Ну и решил в симуляторе запустить. Запускаю - через некоторое время вылетает. Думал я что то попортил. Отлаживал и так и сяк - всё равно вылетает. Такое ощущение, что WD срабатывает. Сброс его поставил - всё равно вылетает. Кучу времени на это убил... Потом от безъисходности решил AVR Studio v3.56 попробовать. Запускаю в симуляторе - всё нормально считается! Сравниваю hex-файлы той и другой студией сделанные - одинаковые. Т.е. явно в симуляторе ошибка... Как у более новых студий не знаю. Давно с AVR дела не имел...

Я ничего не эмулирую. Форматирует винда. Я только туда логи в виде файлов пишу. Для винды они read only. Вот винда эти файлы и кэширует, ну не понимает она, что там может что-то без неё изменится. И стандартными программами перечитать не получится...