guest87

Микроконтроллеры за общий баланс предсказуемости, периферии, времени реакции и вообще характерные возможности а не скорость саму по себе. А время перегрузки flash -> SRAM случайно не добавляется к времени запуска? Это нужно не всегда, но для МК актуальный параметр. Разгонять МК? Зачем? Их используют для управления и проч, там надежность важна. Какая надежность при разгоне? Покупая оригинал STM32 можно быть уверенным что параметры - как в даташите (и если это не так, поставщик и stm ответят). В отличие от китая, в DS STM'а пессимистичная оценка, если даже будет -40 или +85, эта штука не подведет. STMicro тестирует или характеризует дюжины параметров, важных для разных применений. Выходящий с фабрики соответствует тому что в DS, ключевые параметры проверены, что не прошло тесты - в брак. Китайцы с али врядли делают хотя-бы треть этого. Как не стартующий чип покидает фабрику?! Конечно не все. У китайцев неплохие процессоры приложений в нижнем ценовом сегменте - allwinner и rockchip (и одноплатники на них тоже ничего). И эти производители даже отучились сильно врать в спеках и стали писать хоть какую-то документацию. Но ее качество дрянь. И даже сотрудник фирмы не может ответить на вопросы разработчиков. Берут ценой и гибкостью. Это аргумент, но в этом сегменте требования к надежности и предсказуемости здорово ниже. Так что не все китайцы дрянь, но все-таки халтура и вранье/приукрасы - их визитная карточка. Для микроконтроллеров такой подход довольно чреват.

Обязательно на нем? Если это из соображений "уже есть" - думаете, такая работа будет стоить дешевле чем парочка Pi или сравнимых штук? Или есть какие-то иные соображения почему он? Есть камеры с встроенным микрофоном, отдающие аудио по usb. А у некоторых микрофон аналоговый. И вот тут возможны варианты - у raspi если не ошибаюсь нет микрофонного входа. И какие параметры видео хочется получить? У именно Pi их можно подключить разве что к usb, с довольно хилой скоростью. По тому же usb вебкамера будет поток гнать и эзернет на нем же висит (там на плате хаб делит 1 порт на все). Может сколлапсировать. Кстати я на похожей платке экспериментировал с записью видео только когда движение обнаружено. Некий компромисс в плане потери небольшого кусочка в начале действа, зато место экономится сильно. Записывать пустой неактивный интерьер малоинтересно, разве что ожидается какое-то быстрое внезапное действо и обзор камеры можно очень быстро проскочить. Это еще и с RF приемником и пультом надо заморачиваться. А судя по вашему описанию еще и с цепью управлением питанием от этой "кнопки" (которая на самом деле радио). Это скорее всего потребует микроконтроллера и написания небольшой прошивки. У вас довольно много хотелок, не очень хорошо согласуется с "оперативно сделать". Разве что если вы целую фирму наймете. Умею делать boot на других одноплатниках за 8-10 секунд. Можно сделать и меньше, если развлечение оплачивается. Если не выключать устройство той "кнопкой" насовсем, запись может начинаться и быстрее, в пределах 1-2 секунд (старт/стоп программы по "кнопке"), но тогда устройство будет лопать больше электричества. В таком варианте вместо кнопки (или вместе с ней) можно сделать вебфэйс и хоть с смартфона им командовать. Pi насколько я помню не умеет грузиться с SSD, только с SD-карты. Запустив с карты код можно потом и на SSD переключиться, если это надо. Но поскольку карта всяко нужна, логично на ней систему держать. На емкой и не очень тормозной карте можно при желании и видео хранить. Хоть это и чревато тем что карта однажды протрется и придется брать новую, записывая на нее систему заново. Карту желательно быструю, UHS-I. Хорошо влияет на скорость загрузки и отзывчивость системы. Емкость - на сколько жаба позволит и сколько целесообразно. По питанию? Тогда это заявка на оптимизацию времени загрузки. Стоит понимать что это достаточно квалифицированная работа, которая занимает некоторое время и врядли кто-то займется таким совсем уж дешево. Пожалуй наименьшая из проблем. Вебсервер отдающий диру, например. Мне было бы любопытно услышать хотя-бы примерную вилку бюджета подобного мероприятия. На вид есть два здорово конфликтующих требования: довольно большое количество работ не особо стандартного плана vs "оперативно все сделать".

Ок. Я знаю что админы всегда правы, да и цели создавать неудобства у меня нет. Если это получилось - извините. Это уж как вам удобнее, просто мотивы именно такой группировки для меня остались загадкой. Устройства совершенно разные. Arduino типичный микроконтроллер. RasPi - одноплатный компьютер и ближе всего к компьютерам, пожалуй.

Хотя админы тут как я понял не очень дружественны к замеченным упущениям и предложениям, попробую еще разок, на свой страх и риск. Вопрос: а зачем Arduino и Raspberry Pi в одном разделе? Это совершенно разные платформы от разных производителей. С совершенно разной программной "начинкой" и подходами к разработке. Может быть, логичнее был бы форум "Одноплатные компьютеры" (куда входили бы Raspberry Pi и прочие китайцы типа Banana/Orange), а ардуино - где-то в районе микроконтроллеров для начинающих?

68HC11 - моторольский проц, HC25 - IO Expander к нему. По описанию могу предположить что моторольский проц прицеплен через IO Expander к кабелю, на кабель идут IO порты для работы с клавиатурой и дисплеем. Ими моторола скорее всего и изображает все нужное, наверное работу с чем-то типа HD44780 - в те времена для 16x2 кроме него мало что было. В целом не выглядит нереальным, но тогда придется сделать что-то типа эмулятора HD44780 и из него в RS232 (или что вам там удобно) данные гнать.

Врачи меряют пульс там где лучше всего ощущается. Но разлетается по всему телу, можно даже на пальце ощутить. Что прожуют датчики и где их реально можно разместить чтобы потом еще и заработало - мне любопытно. В идеале - на руле, чтобы взял руль - и готово. А погрешность... по идее интересен самый мощный импульс, даже в цифровом формате. Он или поймается выше порога, или нет. Какая-то погрешность при перемещении рук или работе на грани может быть, но для этого надо поэкспериментировать с датчиками и понять что они реально могут вытянуть. Тем емкостным ЭКГ штукам вообще был интересен дифференциал, так что требованием было разнесение электродов на достаточное расстояние. Иногда по утверждениям даташита даже одежда не очень мешает снять сносный ЭКГ т.к. датчик емкостной. Могу себе представить что две таких штуки на руле даже заработают, но там слабый сигнал и нужен крутейший аналог, сохраняющий мелкие детали графика и используются специфичные трюки ЭКГшников с потенциалами. Для замера пульса столько счастья не надо. Наверное, потому что мне не нравится именно такая реализация этой функции и уровень доступности этих данных МНЕ а не проивзодителю какой-то там дряни. Опыт это прекрасно. Если вопрос в этом. И наверное на велофорумах им обмениваться лучше, там полно ездоков всех конфессий и направлений, от матрасников до гонщиков и завзятых ездоков по перилам. А если меня интересовала технология "как это работает" и "как бы мне такое же к своей железке приделать" - наверное интересно было именно ЭТО. Иначе я бы задал другой вопрос, на другом ресурсе. Для обзоров китайского хлама с али есть масса ресурсов. Но мне не нравятся такие товары, с уродской индикацией, функциональностью удобной китайцам а не мне, отсутствием возможности получать данные в понятном мне виде и прочими радостями. А еще у меня есть несколько дополнительных идей для "штуки с микроконтроллером", но у китайцев это реализовать невозможно. Они исходник не дадут, и вообще, одноразовая штука с mask rom. И какая мне радость от очередного уродца с али? Да, его можно купить. И мне он не нужен даже бесплатно, потому что печальная малоинформативная штука с неудобной индикацией и невозможностью вытащить данные в известном мне формате и приделать дополнительные функции.

Померять несколько периодов сигналов и на экран отрисовать вроде не выглядит ужасно сложным, с этим даже ардуинщики могут справиться. Особенно без блютуса и андроида, смысл которых в велокомпьютере мне не понятен. Обычные велокомпы тривиальные железки. Для меня во всей этой истории любопытно какие датчики используют в браслетах для замера пульса. А что "сложно", "нужно" и "купить" - эээ... хмм, я думал что это форум по электронике? Я облажался и регистрировался зря?

А там устаканился какой-нибудь стандартный протокол, чтобы произвольный браслет работал с произвольным велокомпом? Или это надо покупать велокомпьютер и браслет у одного производителя, чего доброго за ужасные деньги? Профессиональное оборудование стоит наверное больше моего вела, да и неужели нет технологии снять пульс прямо с руля, по факту того что я за него держусь? Не очень понимаю: зачем там вообще какие-то браслеты, блютус и андроид вместе взятые. Так мне попадались датчики для ЭКГ, но они крутые, дорогие, требовательные к обработке сигнала и пульс так мерять - перебор . Что в эти браслеты за датчики паяют?

Однако говоря за себя я бы предпочел видеть и каденс и пульс. И, главное, активное и злое предупреждение когда они выходят за разумные рамки. Оно здорово, но это не велокомпьютер и не факт что это просто к велокомпу подключить. Кинуть короткий взгляд на один экран еще куда ни шло. А если пялиться на пять гаджетов, как раз "вывих шеи" схлопотать можно. Быстро и неконтролируемо.

Несколько упущений которые были замечены на форуме свежим взглядом: 1) Когда я только регнулся я не смог создать топик в этом подфоруме. Сейчас вроде могу, т.е. это или уже исправлено или форум дал мне больше прав. Проблема была в том что если у нового пользователя что-то не так, он даже сообщить это не сможет. Надеюсь что админы это исправили. 2) HTTPS криво работает - все время норовит слететь при нажатии на почти все гиперссылки, они на http:// ведут, без "s". Доходит до того что даже форма логина на форум пытается отделаться от шифрования, хотя там оно нужнее всего. 3) WISIWYG цитирование/редактирование в форуме просто издевается. То right-to-left ввод врубается, по принципу который я даже не знаю и еще меньше знаю как вернуть форматирование в обычный вид, то нажатие ctrl+z откатывает половину сообщения за раз (очень злобный undo, это JS форума как я понимаю прикалывается), то попытка стереть пару пустых строк грохает цитату, а когда я жму ctrl-z для отмены - отменяется и почти все остальное, так что из-за одной оплошности можно получить привилегию напечатать весь пост еще раз . В одном месте я лопухнулся с иерархией цитат. Долбался 10 минут но так и не смог понять как закрыть лишний уровень "quote" в визуальном редакторе, который случайно как-то образовался. И весь пост остался сплошной цитатой. Реально убрать чертов WISIWYG при вводе и использовать BBCODE, чтоли? Есть такая настройка? А то с такой помощью в форматировании текста не соскучишься.

Тогда и форум можно наверное закрывать? Электроника существует порядка сотни лет, а до этого без нее прекрасно обходились. Лорд Кельвин вон вообще называл радио бесполезной игрушкой. Хорошо что его не послушали. А что до вела - вопрос в расстоянии. Например 100 км в день вполне доступны здоровому человеку с нормальным велосипедом. Но если крутить неправильно - коленкам крышка.

С таким аппетитом проще сразу Linux брать, его можно перепахать вдоль и поперек, да и плееров полно готовых. И желательно железку Cortex A, иначе вы замучаетесь компиляции ждать. В общем banana pi/orange pi и прочие raspberry на том же али. Если очень хочется сможете даже написать свою операционку, но это будет целая сага, лет на 10+, если вы это серьезно. Посмотрите спеки MPEG4 старых вариантов и подумайте - точно хотите такое програмить да еще единолично?

Заказывать на алике сколь-нибудь сложные комплектующие, особенно те которые китайцы явно научились выпускать сами - искать себе проблем. Резисторы и конденсаторы - куда ни шло, их мультиметром можно проверить. И то - тип диэлектрика мультиметром не проверишь. Насыпят какой-нибудь Y5V вместо X7R, потому что он дешевле, а вскроется это когда-нибудь сильно потом, когда вы будете удивляться почему все так плохо. Покупать STM32 в китае... ух, какая-то китайская фирма совершенно открыто F103 передрала, даже название немного другое придумали. Но поскольку технологий не хватило - флеш отдельно от проца. Чудеса по китайски! Multi-chip package дешевле обычного. Но сами понимаете, глюки и надежность будут "made in china". Сейчас в России есть не сильно наглые по ценам фирмы где можно купить настоящие stm32, в приличном ассортименте и даже с доставкой почтой, при том в отличие от подвальчика на али они отвечают за то что поставляют. На али при сильном желании можно найти ответственных и честных продавцов, но это очень непростой процесс. Особенно для штук уровня STM32.

Позволю себе не согласиться. Постоянно встречаю чудаков которые пыхтят заезжая на малейшую горку разве что не стоя на педалях, с микроскопическим каденсом. Хотя у них велосипеды с передачами и вопрос лишь в том чтобы перещелкнуть. Посадить сердце - это с какой скоростью крутить надо? На обычных топталках у обычных людей как мне кажется ноги с педалей слетят намного раньше. Привыкнуть крутить топталки на скорости 60-90 rpm надо специально себя приучать, а некоторые и 120 считают нормальными. Хотя мысль о том что надо бы и пульс мониторить выглядит интересно. Такие велокомпьютеры бывают? И если да то как они датчик пульса делают?

Если обобщенно, сбоить может или физический уровень (на уровне сигналов), или логический (на уровне софта). Или оба сразу, тогда и профи с ума сойдут. Если на отправку битрейт такой же (или выше) - номер катит, но неплохо бы проверить что в момент записи нового байта uart не занят отсылкой предыдущего байта (по флагам, у атмела это бит TxC, чтоли). Отправка в провод не моментальна, если вы придете с новым байтом в процессе отправки прошлого - ничего хорошего не выйдет. У вас свой физический уровень и софт. Сбоить могут оба. В профоборудовании инженеры делали правильно и то и другое. UART не очень помехоустойчив. По ссылочке которую я дал советуют опторазвязку для MIDI. Соединение устройств с разными сетевыми источниками питания может подкинуть сюрпризов из-за текущих по линиям токов которые вы не заказывали. В случае UART при этом может приняться хрен знает чего. Не думаю что проблема в AVR, с такими проблемами в чипе производители долго не живут. PIC после AVR врядли понравится, разве что PIC32. STM? STM32 крутые и веселые, могут в разы больше, даже те что дешевле. Но НАМНОГО навернутее. Такое там можно на DMA выгрузить - DMA сам будет байты таскать. Но это имеет смысл лишь при ОЧЕНЬ больших потоках, DMA все-равно надо программить а промашки в нем чреваты. К тому же STM32-ы 3.3V-only, в миди как я понимаю 5V в почете, в "электрике" добавится костылей. В общем avr как мне кажется достаточно сбалансированный выбор, если возможностей хватает. На лично мое мнение я бы проверил "физику" на безглючность в жестких условиях (типа сцены) и если вы хотите продвинутости типа irq и кольцевого буфера, их придется сделать нормально. Разобравшись как это работает и что реально происходит в системе. Вообще отгрохать такую штуку для любителя - неслабо. Если нормально работает А еще на сцене чего доброго провода длиннее и какая-нибудь силовуха рядом... Можно с второго микроконтроллера послать, хоть в цикле из main без всяких IRQ, конструкцией в духе while (TxC показывает что Tx не занят) {UDR = чтонибудь}. Получите очень плотный поток данных ограниченный только битрейтом. Быстрее некуда. Можно его проредить, воткнув задержки. Это то понятно, но специалисты от любителей отличаются как раз тем что стараются не халтурить, зная что за это потом воздастся массой неочевидных проблем. А кроме того они в курсе типовых проблем из своей области, что спасает их от массы провалов. Подозрительные места которые не понравились мне я и озвучил, не знаю насколько получилось. Я имел в виду "машины состояний". Когда есть состояния протокола и переходы между ними по неким правилам. Можно в виде диаграммы разрисовать. Обработчик IRQ может смотреть на состояния и даже менять их, если это быстро. Зачем? В лучшем случае фоновая программа может получать относительно готовый пакет и неспешно жевать в фоне, не озадачиваясь как он взялся. Но для миди это наверное не пойдет. И да, из irq надо вываливаться быстро. Но быстро и мгновенно разные вещи. До того как будет новый такой же IRQ, пройдет минимум 32 мкс. Можно посчитать сколько команд проц выполнит за это время зная частоту (порядка сотен или даже тысяч). Есть еще расходы на сохранение состояния фона при входе в irq и возврат проца в вид как было при выходе, а еще времени должно остаться фону и irq других железок (если они используются). Вложенные IRQ от одной железки - показатель что вы зашились и не успеваете за реальным временем. Нафиг. Фоновая программа при этом встрянет, кстати, а проц будет только вертеться на прерывания. Поэтому прерывания должны завершаться как можно быстрее и их не должно валиться слишком много. У вас максимум 3125 irq в секунду от uart, на частотах близких к максимуму это вполне ок. Много логики я бы в irq при этом не засовывал.

Ого, понятно. Тогда про блоки придется забыть. А вы запрограммили именно такой baud rate на стороне МК, с точностью не хуже 2%? Уж простите я не помню как у атмела синтез baud делается. Понятно. А если для начала без прерываний читать в tight loop из регистра, без задержек (ориентируясь на флаг приема) ничего с данными не делая - ошибки будут? Если да - похоже на проблему "железного" характера. Если нет - логика буферизации. Если проблема с железом - у вас сделана опторазвязка как советуют на https://learn.sparkfun.com/tutorials/midi-tutorial/all ? Без этого есть шанс собрать солидные наводки и принимать черти-что, у вас наверное провода длинные. Спасибо если только это - хорошая наводка на длинный кабель может и порт вынести. В случае опторазвязки нет левых токов в порты, да и убить транзистор малореально в отличие от порта IO. Нет смысла прятать проблему под ковер. Она от этого не пропадет - стоит понять в чем причина. Мне не нравится что обработчик и main живут своими жизнями настолько независимо что одурачивают друг друга внезапными сменами переменных. Хотя у вас и аппаратная проблема может быть. Да я уж посмотрел. Хоть и не занимался именно миди, но протокол нашел по быстрому. Там и правда все побайтово. Но сказать что пакетов нет - не совсем так. Есть некое состояние - байты описывающие что это такое и потом 1 или несколько ожидаемых байтов для некоторых команд как я понимаю. Это не совсем независимые байты и вывод о том получили ли все что хотели сделать можно. Кстати данных немного и можно наверное вообще в tight loop ловить все и там же парсить. Или если хочется по фэншую, с прерыванием и буфером, наверное в прерывание вынести немного логики разбора midi, как минимум понимание где начало очередной команды, сколько байтов ждать и поймали ли всю команду или нет. И анонс main что все что хотели - приехало. Или если вся команда за разумное время не приехала - забываем и ждем новую. На самом деле может быть по куче причин, от несовпадения baud и длинного шнура поймавшего помехи до кривой логики буферизации. Я бы попробовал для начала получать байты как есть без прерываний глупым poll. Это фи по использованию ресурсов, зато все предельно просто и ошибиться негде. Кстати 31250 битов в секунду это 3125 байтов в секунду (8-N-1=10 битов). У вас есть 1/3125 секунды (=32мкс) чтобы с байтом что-то сделать, не потеряв следующий. Это не то чтобы очень много, но для простых вещей хватит. Да, тут уж увы, если это миди - тогда так. И тут только добиваться приема без ошибок. Что на стороне железа что на стороне софта. Но все-таки анализ флагов типа ошибок фрейминга или что там атмел умеет - позволит понять есть ли проблемы "железного" характера. Ну как, в идеале ошибок фрейминга и проч быть не должно и если они есть это повод посмотреть что с "железом". Однако ж начать с довольно продвинутой работы с прерываниями и чем-то типа кольцевого буфера - замах весьма солиден. И хотя ряд вещей вызывают подозрения, общая идея работы с прерыванием какая-то такая. Вот только такой кольцевой буфер вам наверное вообще не надо. А переменные которые меняет ISR стоит указывать как volatile. Иначе си может оптимизировать доступ к ним на свою голову, оформив переменную как значение регистра а не адрес в памяти. ISR же не в курсе такой подляны, он вызывается железом, регистры в этот момент уже другое и можно потенциально огрести глюков. Но это "в си и МК вообше", я не помню насколько это критично для атмела, но все с чем имеет дело IRQ стоит декларить как volatile. Однако аппаратные UART нечто подобное в виде оверсэмпла делают. Так устойчивее.0 Не очень понимаю что дадут именно 3 буфера. Я еще могу понять если поток данных очень большой, обработка очень сложная, то можно получать в один буфер пока разбирать другой. Но в этом случае опять же IRQ должен немного заняться "состояниями протокола" чтобы кормить того кто разбирает командами целиком, чтоли. Я бы попробовал для начала тупым poll из регистра UART читать все что валится и посмотреть насколько то что валится (не)правильное для понимания виновато ли железо в чем либо. За 32 мкс до следующего байта (быстрее он не приедет чисто физически) можно успеть и флаги ошибок посмотреть и даже что-то сделать (например в второй uart загнать если у него baud выше, отфорвардив на комп). Но поскольку я атмеги видел давно и все забыл и с миди не работал - я наверное не лучший специалист в этом. Просто я с уартами работал и некоторые проблемы знаю.

Странноватый код. Я правда не помню когда я атмел последний раз видел, так что тапками не кидаться, но все-таки: 0) Вы уверены что инициализация UART правильная? Как минимум, проверьте что ошибка в baud rate на разных сторонах линка не более 2%, иначе будут глюки. Из вашего сорца не видно какой baud вы пытаетесь получить и все такое. 1) Delay какой-то в основном цикле. Он несет какой-то смысл? Обработчик прерывания свое время сам урвет. На то оно и прерывание что вышибет основную программу. Похоже на костыль маскирующий истинную проблему. 2) Размеры буфера - по размеру максимального пакета который вы хотите жевать за раз (и доступной памяти). Это зависит от того что вы намереваетесь делать с данными и какими порциями они имеют смысл. Кроме того, лимит в 100 байтов в обработчике при 128 байтах буфера приводит к тому что 28 байтов оперативки сжираются под буфер но никогда не используются, поскольку при достижении 100 обработчик делает разворот. Оставшиеся байты на вид вроде бы просто потеряны, а у атмела не настолько уж огромная оперативка. 3) В вашем коде нет никаких способов понять где начало передачи данных и все такое прочее. Ну то-есть если алгоритм начал вкалывать с середины передачи с той стороны - он что-то конечно примет. С произвольного места. А вот имеет ли принятое смысл - отдельный вопрос. 4) При малейшей неидеальности ваш код вероятно рассинхронизируется с передатчиком и врядли вернется в синхронизм. Ну как, протокола у вас нет, чексум нет, анализа ошибок UART тоже нет. Причина ошибок останется загадкой, просто потому что никто нигде не проверяет ошибки и не заморачивается ре-синхронизацией по допустим протокольному таймауту (т.е. сброс состояния протокола на исходное по таймауту например). 5) Подозрительно выглядит main loop, например sei вы сделали, а потом if (Count>=Max) Count=0; - а если между сравнением и присвоением приедет IRQ, то чего? IRQ не в курсе намерений сделать Count = 0, он что-то сделает с Сount, наверное не просто, вернется. А тут вы хлоп Count в 0 когда выполнение вернулось обратно main. Но хотели вы наверное не этого? Похоже на race condition вроде. 6) Неплохо бы чтобы у протокола еще и чексуммы какие-то были для понимания что данные побились. Или если это интерактив через терминалку то короткие команды и выход по таймаутам или характерным маркерам типа перевода строк на исходное состояние "ждем команду". 7) Что до дребезга, железо UART обычно делает oversampling порядка 8 отсчетов на бит и принимает решение что за бит по мажоритарному принципу. Как оно у атмела написано в их даташите. И если у вас все настолько плохо что uart ловит мусор и вас беспокоит дребезг - где хотя-бы обработка framing error и проч? Да и после того как вы узнали что ошибка - часть данных возможно потеряна. У вас на этот счет был план? Если UART поймает стартовый бит там где его не было, вся последовательность будет сдвинута. UART поймает сколько-то данных, в конце концов заметит framing error, когда STOP в нужном месте не окажется. Часть данных окажется порушена, часть не принята. Если вы хотите работать в окружении где ошибки норма, придется сделать какой-нибудь протокол. Если данные ценные, их придется попросить у отправителя еще раз. Если не очень - хотя-бы выйти на исходное состояние. 8) Сразу 3 массива - да вы эстет. Вы хотите слать данные 3 раза и выбирать по мажоритарному принципу? А оно надо? К тому же при framing error uart может принять что-то из середины битового потока и не сразу заметить проблему. В конце концов он скорее всего отхватит framing error, не найдя STOP вовремя, но сколько данных до этого приедет и что в них будет - никто не обещает. И трояная посылка одного и того же байта может в этом случае не помочь. А так для повышения надежности можно слать не абы что а пакет с характерным маркером начала, указанием длины и чексумой, возможно маркером конца. И подтверждать отправителю что получили, если это важно. Если подтверждения нет - слать пакет еще раз. При этом понятно и где начало данных (маркер должен совпасть, иначе пропускаем мусор мимо ушей пока правильный маркер не появится), и получили ли мы все что хотел послать отправитель (по размеру пакета и возможно маркеру конца), и правильно ли это приехало (по чексуме). При этом и хардварные проблемы будут видны не в виде нежданчиков а в виде какой-нибудь статистики протокола. Кстати все это актуально и для второй стороны линка. Особенно забавно когда там компьютер с многозадачной ОС, там некоторые забавные особенности есть.

Может, человек на самом деле RFID хочет? Метка RFID вообще живет вечно, своей батарейки там обычно нет, питается от излучения транспондера. Подошел с транспондером - считал - посмотрел - можно сразу в какие-нибудь компьютерные системы загнать. А экранчик один - на считываетеле-транспондере. Характерный пример - карточки метро. Всегда можно посмотреть баланс на устройстве с экраном, сама же карточка полностью пассивный объект. Тем не менее она помнит как минимум свой серийник, а может и еще что-нибудь, там как минимум энергонезависимая память есть, у некоторых и свой процессор (МК) может быть.

Мне кажется что идея с разрядами неудачная. Пропихать то их можно, хоть через шубу, если надо - достаточно напряжение повыше. Но вот вопрос здоровья получающего разряды периодически остается под вопросом. Подкоротит человеку нерв какой-нибудь - и вы по судам устанете бегать. Вибра значительно безопаснее в этом плане.