Опросили оборудование — не получили ответ несколько раз — дропнули соединение.
Если на стороне железки — то у модема есть нога состояния подключения к сети, можно ее отслеживать и ребутать модем при пропадании связи.
Вы определитесь проездной или деньги. Деньги — другая статья, там четко написано что подделка незаконна. С ПО — немного по другому. Так что тут все чисто перед законом.
Подделка — не преступление, преступление начинается в тот момент когда кто то расплатился поддельным проездным, тем самым нанеся ущерб.
Если я дома при помощи ридера смог разобрать алгоритм записи данных о поездках на карту и описал этот алгоритм здесь — это не преступление (не этично, но не критично) это реверс. А вот когда кто то будет использовать этот алгоритм чтобы обмануть систему — это уже преступление.
Они не ответят. Статьи выкладывает специально обученный человек, который видимо не особо понимает в сути вопроса. Соответственно не берет на себя ответственность по ответам на вопросы. Даже в личке
Гладко было на бумаге…
Тема TDD актуальна и для МК, но проблем такой подход (прогон тестов на ПК а не на целевом МК) иногда добавляет.
Например: Написали заглушку для записи во флеш, откатали бизнес логику на ПК (допустим пусть это будет какой нибудь хитрый протокол для обновления прошивки МК), залили код на целевую железку — погоняли на столе в режиме точка-точка — все работает. Привезли прибор на объект — воткнули в стойку с оборудованием — «все сломалось», почему? А вот оказывается что именно это семейство МК 4 байта пишет во флеш за 1 мкс, 16 байт за 2 мкс, а при попытке записать блок из 256 байт повисает аж на 1-5 миллисекунд (время — чистый рандом). За это время срабатывает вотчдог и портит всю оттестированную картину. Производитель МК говорит что такое видит первый раз, но добавит в эррата щит этот баг.
Или еще вариант — пишем TCP клиента на всем любимой связке LwIP + FreeRTOS, используем Socket вариант (то есть рассчитываем что все как в linux).
Отлаживаем на ПК логику — код работает, работа с сокетами почти не отличается.
Начинаем тестить в железе — сначала работает — потом падает.
Причем день работает, два работает, неделю и падает.
А бывает и пол дня не работает.
Оказалось — сделали heapsize 16 мегабайт, тестили с heapsize 16 мегабайт, а рамку в плату запаяли на 4 мегабайта.
А TDD что, все тесты passed…
Никоим образом никого не хочу обидеть, просто накипело.
Хоть отдельную статью про вылезшие баги пиши.
Для вашего случая можно прикинутся 4х портовой MOXOй и работать через ее родной драйвер. (можно реализовать даже на данной плате как мне кажется, если wiznet умеет в неблокирующиеся сокеты для TCP)
Хотелось бы в следующей статье увидеть использование данной методологии на конкретном рабочем примере. Например реализуйте простейшую мигалку на ws2812b и покажите что можно отследить тестами, а чего нельзя.
Многие делают пауков, но никто не пишет про ПО.
Ну вот собрали его, а что дальше? Как оживлять? Есть же готовые фреймворки с правильным движением конечностей, но нигде нет статей как это все оживить.
Ну, а минусующие дегенераты … Что ж поделать? На быдлохабре чуть ли не 99% пользователей — быдло тупое, которое вообще ни публикаций, ни комментариев не оставляет, но любит поминусовать. Эффект толпы, однако.
Где ваша шпага, сударь?
В очередной раз флудите в комментариях, переходя на оскорбления, а сами даже ни про что ни написали. Ни одной статьи!
Сдаётся мне сударь, вы пустозвон
Подбирать только один раз надо. Особых проблем с этим не было.
Пока не было
Вам правильно выше описали, что значения АЦП надо фильтровать или усреднять.
Для примера:
Вы считываете значение кнопки — а в этот момент дядя Вася в соседнем боксе варит самопальной сваркой. В ваш диапазон можете и не попасть, просто потому что значения будут прыгать из за наводок.
А завтра вам завезут другие резисторы с другой погрешностью — и может так случится что вы не попадете в диапазон.
А еще контакт кнопки может окислится — у вас же мойка и влажно — сопротивление уйдет и уплывут значения АЦП.
Если на стороне железки — то у модема есть нога состояния подключения к сети, можно ее отслеживать и ребутать модем при пропадании связи.
Вы определитесь проездной или деньги. Деньги — другая статья, там четко написано что подделка незаконна. С ПО — немного по другому. Так что тут все чисто перед законом.
Если я дома при помощи ридера смог разобрать алгоритм записи данных о поездках на карту и описал этот алгоритм здесь — это не преступление (не этично, но не критично) это реверс. А вот когда кто то будет использовать этот алгоритм чтобы обмануть систему — это уже преступление.
Это реверс инженеринг, он не запрещен
Они не ответят. Статьи выкладывает специально обученный человек, который видимо не особо понимает в сути вопроса. Соответственно не берет на себя ответственность по ответам на вопросы. Даже в личке
Почему в формуле 7 — корень из разности квадратов
а в
формуле 14 — просто разность
?
Тема TDD актуальна и для МК, но проблем такой подход (прогон тестов на ПК а не на целевом МК) иногда добавляет.
Например: Написали заглушку для записи во флеш, откатали бизнес логику на ПК (допустим пусть это будет какой нибудь хитрый протокол для обновления прошивки МК), залили код на целевую железку — погоняли на столе в режиме точка-точка — все работает. Привезли прибор на объект — воткнули в стойку с оборудованием — «все сломалось», почему? А вот оказывается что именно это семейство МК 4 байта пишет во флеш за 1 мкс, 16 байт за 2 мкс, а при попытке записать блок из 256 байт повисает аж на 1-5 миллисекунд (время — чистый рандом). За это время срабатывает вотчдог и портит всю оттестированную картину. Производитель МК говорит что такое видит первый раз, но добавит в эррата щит этот баг.
Или еще вариант — пишем TCP клиента на всем любимой связке LwIP + FreeRTOS, используем Socket вариант (то есть рассчитываем что все как в linux).
Отлаживаем на ПК логику — код работает, работа с сокетами почти не отличается.
Начинаем тестить в железе — сначала работает — потом падает.
Причем день работает, два работает, неделю и падает.
А бывает и пол дня не работает.
Оказалось — сделали heapsize 16 мегабайт, тестили с heapsize 16 мегабайт, а рамку в плату запаяли на 4 мегабайта.
А TDD что, все тесты passed…
Никоим образом никого не хочу обидеть, просто накипело.
Хоть отдельную статью про вылезшие баги пиши.
а вы точно сможете научить студентов чему то толковому?
Где?
Ну вот собрали его, а что дальше? Как оживлять? Есть же готовые фреймворки с правильным движением конечностей, но нигде нет статей как это все оживить.
Где ваша шпага, сударь?
В очередной раз флудите в комментариях, переходя на оскорбления, а сами даже ни про что ни написали. Ни одной статьи!
Сдаётся мне сударь, вы пустозвон
Пока не было
Вам правильно выше описали, что значения АЦП надо фильтровать или усреднять.
Для примера:
Вы считываете значение кнопки — а в этот момент дядя Вася в соседнем боксе варит самопальной сваркой. В ваш диапазон можете и не попасть, просто потому что значения будут прыгать из за наводок.
А завтра вам завезут другие резисторы с другой погрешностью — и может так случится что вы не попадете в диапазон.
А еще контакт кнопки может окислится — у вас же мойка и влажно — сопротивление уйдет и уплывут значения АЦП.
20, 300, 315… 640, 420, 480 — что это? количество попугаев?
setRele(1), setRele(2), setRele(3) — какие то реле видимо.но за что отвечают?
Мне кажется весь смак в том, чтобы подготовить датасет, а не тупо скормить чей то готовый сетке
Можно натренировать нейросетку и детектить отклонение от нормы.
habr.com/ru/post/481436/?reply_to=21045638#comment_21045602