Tsvetik

Можно поставить модулятор IrDA, чтобы работал на кабель вместо светодиода и запустить от com-порта на высокой частоте.

Для начала надо понять, соединена ли "земля" на щупе с землей осциллографа. Если не соединена, то можно взяться землей осциллографа за D-. Иначе можно мерить дифференциально двумя лучами. Земли у щупов соединяете вместе и прицепляете к земле USB, далее одним щупом за D+ другим за D- и сделать вычитание лучей.

Что вы имеете ввиду?

СУПЕР!! COBS - это как раз именно то, что мне нужно. и реализация миниатюрнейшая Большое спасибо.

Ну, с одной стороны tiny, а с другой ARM7 или PC при тестах и отладке. Так что требование к DMA вторично. С одной стороны, когда DMA не знает ничего о протоколе будет легко разделить передачу на различные уровни обработки. С другой стороны, добавление уровней обработки часто означает добавление дополнительных буфферов и сильного увеличения уровня вложенности функций.

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

Да вот что-то не нравится мне эта схема вот чем: Длина идет не первым байтом. Если МК с DMA, то нужно будет несколько входов в обработчик прежде чем можно будет включить DMA. Все, что здесь предлагали это какой-то самопал. Неужели нет чего-то более-менее стандартног-популярного? Может, рекомендованного IEC или еще каким-то международным институтом?

Байт-стаффинг и есть экранировать иначе, escape sequence Тайм-ауты нафиг. Медленно и не хочу зависимость от таймера.

За WAKE спасибо.

Те же N символов могут встретиться и в двоичных данных. Например, надо передать AT команду в которой содержится другая AT команда

Нужно передавать массивы двоичных данных по UART между двумя устройствами. Так как полезная нагрузка не помещается в пределы 1 байта, необходимо поверх UART использовать некоторый логический протокол, который будет разделять фреймы и как-то управлять потоком. Следовательно из 256 вариантов байта необходимо зарезервировать несколько значений для признаков начала (или конца) фрейма и, возможно, каких-то других управляющий символов. Один из вариантов это /xon /xoff. Его минусы в том, что символы /xon /xoff могут встретиться в передаваемых двоичных данных и их надо экранировать. Плюс этого метода в том, что экранирование можно проводить "на лету" при приеме. Промежуточный буфер для этого не требуется. Второй вариант использовать для кодирования двоичных данных некоторую кодировку. Например, BASE64 или семибитную кодировку, а старшие биты пристегивать отдельным байтом. Тогда символы, не входящие в алфавит BASE64 или со взведенным старшим битом можно считать управляющими. На них можно повесить функции управления протоколом, начала-конца фрейма, повтора передачи, может-быть и адреса устройства и т.п. Обычно кодирование-декодирование требует промежуточного буфера и вносит дополнительные временные издержки. Так вот, подскажите какие-нибудь популярные реализации логических протоколов поверх UART. Необходимы легковесные протоколы, которые будут работать довольно быстро на Tiny AVR. Да, желательно без 9-го бита UART, чтобы с PC было проще отлаживаться

Да, кинетисы пропустил. Что-то про них хорошее можно сказать?

Для новых проектов выбираю семейство микроконтроллеров на замену AT91SAM7. Конкретно интересуют ядра Cortex-M3, M4, M0. Просмотрел несколько известных фирм, производящих такие МК и отобрал три основных с широким ассортиментом в семействе. Это 1. STM 2. NXP 3. Atmel У Atmel есть некоторое преимущество в том, что их Cortex МК пин-пин совместимы с SAM7. Однако, расстраивает довольно длинный список errata. Как в SAM7 было много ошибок так и в SAM3/SAM4 список не маленький. Впрочем, это не самый главный вопрос. Главный вопрос вот в чем. Когда-то давно у Atmel на AVR видел информацию о надежности их восьмибиток. Графики с числом отказов от времени. Теперь же такие не могу найти ни на их AVR ни на ARM. Разве что кое-какие документы в которых Atmel повествует о том как лихо они тестируют свои МК и вообще следят и регистрируют отказы. Аналогичная информация у NXP и STM с ходу не нашлась. NXP вообще прямым текстом пишет (как я понял из сложного юридического английского), что все, что написано про их МК применять на свой страх и риск и ответственности ни за что не несут. Так вот главный вопрос в том, дают ли эти производители какую-либо информацию о надежности своих МК и где ее можно узнать? Ну или хотя бы ключевые слова для поиска. Ну а второстепенный вопрос, имеют ли МК этих фирм какие-то свои собственные изюминки или особенности, на которые стоит обратить внимание? В частности, смогу ля и использовать свой клон ST-Link для работы с этими МК?

Заинтересовала его ориентированность на параллельные вычисления.

Про GCC не знаю На GreenHills я был, у них действительно есть компилятор ADA95, но я не увидел нигlе укзания на то, что он комплит под ARM Есть ли у кого-нибудь опыт разработки на ADA для микроконтроллеров? По идкк этот язык специально заточен под embedded системы