Добрый вечер форумчане!!!!
Есть вот такая задачка
Необходимо программно реализовать интерфейс типа ARINC-429.
Последовательный интерфейс. По 1 проводу идут данные, по 2 проводу - синхросигнал (Частота 1,25 МГЦ).
Слово данных состоит из 22 разрядов -> 1...6 - адрес (1-младший бит адреса, 6 - старший бит адреса) + 7...22 - данные (7 - младший, 22 - старший).
Помогите реализовать выдачу и прием такого слова микроконтроллером. Желательно на ассемблере.
Заранее спасибо.
Если нужны уточнения пишите.

Обязательно программно ? Если в МК этот интерфейс не поддерживается аппаратно, то программная реализация вас не спасет. 1.25 МГц - это слишком быстро. МК почти наверняка не справится. Или справится, но ресурсов больше ни на что не хватит. Проще говоря, как ни делай, а все равно выйдет посредственно или (скорее всего) не выйдет вообще. Это типичная задачка для простой CPLD. Какая-нибудь MAX3032 + код на AHDL. За день-другой вполне справитесь ...

А больше не чего реализовывать и не надо. Тупо прочитать слова (порядка 37 шт 22 разрядных слов), записать их в ОЗУ, и в определенный момент выкинуть все уартом в комп. Интервал между пачками (37 слов) 7*1,28 мс

И согласитесь говорить что не получиться не сделав даже попытки это как то не спортивно

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

Шустрый AVR уже выбрал - ATmega88. Предельная частота по документации 20 МГц.
Если не трудно подскажите как 22разрядный код описанный код можно первое выдать и второе принять

Точно 22 ? Википедия говорит о 32... 37 принимаемых слов идут подряд без разрывов или хоть какая-та пауза есть ? Если с разрывом, то AVR на 16...20 MHz пожалуй справится - поллингом (sbis/sbic) определяем фронт тактировки, принятый бит заносим в аккумулятор (ori), при этом на организацию цикла приема времени не остается, и для каждого принимаемого бита свой цикл и своя маска ori. А если плотно, без разрыва между словами - может быть, на 20 MHz и удастся, но придется репу почесать...

Это сильно урезанный и переделанный ARINC 429
разрывы между словами есть. завтра измерю точное значение (порядка десятка микросекунд.)
а если не трудно можно пример кода для приема а то не очень понятно

Первым делом - не использовать прерываний. Любое прерывание, возникшее при приеме, снесет приемнику башку. А дальше - вообще не совсем ясно, как это впихнуть в МК, поскольку, если верить описанию интерфейса, он дифференциальный и трехуровневый. Потребуются трансиверы. Они есть ?

есть согласующая схема на ее выходе ТТЛ сигнал Данные (Адрес+Данны) и синхросигнал

Ну что-то типа:
b7_0:
sbis port,synch
rjmp b7_0
ori acc1,$80
b7_1:
sbic port,synch
rjmp b7_1
b6_0:
sbis port,synch
rjmp b6_0
ori acc1,$40
b6_1:
sbic port,synch
rjmp b6_1
.....

16 тактов на прием одного бита - сомнительно, на грани фола

+1 вот-вот
+ время на укладку байтов в FIFO. Да еще и в UART надо запхнуть.

Время между пачками скока? 1.28*7 = 8.96 милисек. Вам, чтоб выпхнуть 37 слов на скорости 115200 потребуется 37*(22/8)*1000/(115200/10) = 9.63 милисека. Нужно параллельно с приемом данных, отправлять в UART. Без прерываний параллельную отпраку не сделать нормально. С прерываниями - софтверный прием обосрётся. Выводы неутешительны. Хотя можно подвесить FTDI-232 и запулить на 1Mbit.

Вижу 3 варианта -
1. Внешний сдвиговый регистр, лучче CPLD, как посоветовал kovigor + UART на повышенной скорости.
2. Берите ARM
3. Cлабая надежда есть, на нестандартное использование модуля TWI - кмк, единственный шанс реализовать на AVR, без внешних схем.
PS: 3-й вариант возможен тока на TWI tinyAVR. Еслиб было 24 бита - можно было-бы использовать SPI, но это не наш случай.
PPS: Щас еще раз глянул даташиты - на tiny должно получиться c TWI. На mega TWI шибко умный, ничего не выйдет.

Как раз наоборот - ведь вывод одного набранного байта это всего лишь один out, один лишний такт (а там определенный запас есть). Хотя одним не обойтись - если данные буферизовать в SRAM, то и на сохранение по два такта на байт, и на извлечение 2 (+1 на out). Однако на 20 MHz, пожалуй, реально. Реально даже если входные пакеты идут без пауз, непрерывно. А вот уложиться в паузу 9 mS - трудновато.

Принять на такой скорости не проблема, или вы хотите полный дуплекс? Можно взглянуть на временные диаграммы? И уточните, на какой скорости хотите передавать данные в писюк?

Это если у Вас скорость порта заведомо выше скорости поступления данных, но у нас как раз наоборот(1.25Mbit ! против даже 1Мbit c FT-232). Прийдется организовывать FIFO, и по прерываниям с UART забирать данные, либо полингом смотреть статус UART в основном цикле, а это несколько больше одного out

На 20 MHz отправить в UART нереально. Т.е. отправить реально, а принять без ошибок, на 115200 - не выйдет. Сейчас у мамок com-порты отвратительные, с подстройкой фазы все очень плохо (особенно "радуют" мамки на nForce - чуть в сторону и приехали). Потери - гарантированы. Нужно либо кварц типа 14.7456 или 18.432, либо паять FT-232 и на нестандартной скорости шпарить через "виртуальный com port".
И все-же советую tiny (например 2313) и заюзать TWI. Я уже так делал - нужно было принимать последовательности по 28 бит. Почему не использовать аппаратный сдвиговый регистр? Код найти постараюсь сегодня вечером, по крайней мере, метода проверена
PS: Я уже решал подобную задачу, и тут прийдется сильно поэкономить тактики

А почему бы не использовать для этого SPI? И что с этим словом делать дальше?

Про конкретную скорость UART пока речи не было. Никто не мешает, например, отдавать байт в UART на каждый второй собранный входной байт. Главное, чтобы успевал уходить.


На 115200 - прекрасно, ошибка менее двух процентов. И на 230400 тоже.

Ой, ну да ладно страсти-то какие-то рассказывать, а ? Какие-такие "подстройки фазы" ?
К тому же - ну какие тут 115200 (входные по порядок шустрее), когда и 230400 мало. Значит, никаких аппаратных COM, а только USB.

Вы возьмите и посчитайте. 115200 вполне достаточно, если правильно организовать обмен. Вы ветку сперва прочитайте, а потом уже высказывайтесь.

Вот благодаря таким знаниям, мы имеем неработающие com-порты.

А если достаточно, то и тем более нет никаких поводов для беспокойства. В 9-ms паузу такая посылка не уложится, будучи "размазана" на весь принимаемый поток - вполне.


Я не знаю, какие там неработающие порты _Вы_ имеете, но больше пока никто не жаловался. Вы занимаетесь натуральным сочинительством на ровном месте.

Прошу прощения, за резкие слова, день, мля, тяжеловатый выдался
По теме: Я выше писал про FIFO и параллельную обработку итд итп. Если правильно реализовать, то общего времени приема "пачки" данных + время паузы достаточно, для выпихивания всего блока на 115200. FIFO потребуется не менее размера одной "пачки". Если все реализовать тщательно, то должно получится.

С SPI не получится, тк клок внешний, бит 22, а он байт-ориентированный. Было-б 24 бита - самае оно, но увы.

По качеству портов. У меня есть проект, где через com в устройство нужно загрузить firmware порядка 3.5МБ. Там протокольчик дуплексный вопрос-ответ, не я делал.
Так вот у меня, на 2-х компах (чипсет nVidia), это получается через раз. Причина - в этих самых 1-2% отличия скорости (кварц 4МГц). Когда идет обмен с паузами - все хорошо, а вот дуплекс на большом объеме им не под силу. Единственный комп, в котором стоит Intel-овская мама, работает без проблем. Вот такая вечная молодость.

Не сочтите за издевательство, но все-таки осмелюсь спросить, включено-ли у вас управление потоком ? Хотя-бы XON/XOFF ? Описанного вами эффекта лично я не видел никогда. Думаю, что он едва ли возможен, поскольку при получении каждого нового байта (!) приемник пересинхронизируется ...

Это почему? А Вы в Sram разве не байтами будете писать?! И разве SPI не может работать как slave? А уж передовать тем более

115200 недостаточно, немного не хватает.


Не придумывайте, и с аппаратным SPI , и программно получится принимать на скорости 1.25 Мбод.

Это, простите, ошибка в ДНК. Самая что ни на есть натуральная. Чтобы рассуждать о "качестве" портов и связи этого "качества" с чипсетом, надо иметь хоть минимальные представления о устройстве этих портов (с этим у Вас совсем плохо). А в данном случае у меня лично никаких сомнений, что имела место банальнейшая потеря данных при отсутствии управления потоком. Дуплекс тут вообще не при чем (прием и передача функционально разные части), а вот косвенно влияет (из-за влияния на загрузку процессора при обработке прерываний).
Я-то думал, что Вы нас порадуете какими-то откровениями на предмет PLL и тактировки MIO-чипа, а тут такая банальщина. "У меня не работает, значит и у других не работает". Но Вы первый додумались до влияния чипсета, с чем и поздравляю


Изначально разговор был про программную реализацию. SPI slave тоже можно, благо что приемник имеет двойную буферизацию. Байтовую синхронизацию, правда, придется обеспечивать ручками. И границы слов тоже. Но чтобы быстренько все это дело скушать и куда-то отдать - вполне, и 22 бита вместо 24 тут нисколько не помеха. Накладные расходы на сборку-отправку резко сокращаются. А синхронизацией пускай PC занимается. Я так понимаю, что речь о каком-то сниффере протокола, и задача засосать в PC этот самый входной поток. Вариантов реализации по крайней мере два-три...

Здравствуйте товарищи!!!!
Докладываю голосом!
Длительность 1 разряда = 0,800 мкс
Длительность слова = 22р*0,800мкс=17,6 мкс
Пауза между словами в пачке =11.2 мкс
Количество слов в пачке 33
Длина пачки ==33сл*17.6+32паузы*11.2=580.8мкс+358,6мкс=939,2мкс ну короче 940мкс (по осциллографу)

Далее сам протокол для МАСТЕРА ...ПАУЗА 6*1,28мс \ПАЧКА ПЕРДАЧИ\ пауза 300мкс \ПАЧКА ПРИЕМА\ ПАУЗА 6*1,28мс \ПАЧКА ПЕРДАЧИ\ пауза 300мкс \ПАЧКА ПРИЕМА\ ПАУЗА 6*1,28мс....
В пачке передачи на СЛАВЕ передаются слова с адресами с 0 по 32 + информация
В пачке приема на СЛАВ идут адреса с 33 по 63, 33, 34 для синхронизации СЛАЙВА , а по другой паре проводов (D и С) поступают данные от СЛАЙВА
для слайва ...ПАУЗА 6*1,28мс \ПАЧКА ПРИЕМА\ пауза 300мкс \ПАЧКА ПЕРЕДАЧИ\ ПАУЗА 6*1,28мс \ПАЧКА ПЕРДАЧИ\ пауза 300мкс \ПАЧКА ПРИЕМА\ ПАУЗА 6*1,28мс....

ЦЕЛЬ УСТРОЙСТВА
надо сделать СЛАЙВ и МАСТЕР на 2 контроллерах.
Складывать информацию надо в SRAM МК и потом ее оттуда передавать по UARTу в ПК, ну и наоборот от ПК по UARTу в SRAM по МК

Ни че не понял! кроме ORI нет ниче!? т.е. всегда будет 0xFF?
Или я ни че не понял или надо вот так:


А если частота проца 20MHz что в 16 раз больше сихро то мне кажется можно цикл и не разворачивать. 16 тактов должно хватить.

Начальное обнуление необходимо, это как бы самоочевидно...


Двигать маску, проверять счетчик цикла, переход в цикле... Может быть и хватит, но смысла в этом практического нет, все и так на грани, а будет еще хуже. Зачем ? Ради спортивного интереса съэкономить память кода ?

А что, кроме начального обнуления других изменений нет?

А если всетаки цикл понадобиться то может быть вот так:
Кстати начальное обнуление вообще не нужно

А, ну да, это я как-то невнимательно писал, синхра синхрой, но и входной бит проверить не мешает

кстати, этот Ваш кусочек кода в худшем случае на 20 тактов

Пока нет временной диграммы данных и синхро это все вообще очень примерно!!!
Но где Вы 20 тактов насчитали?
А если сихро не меняется то этот кусочег кода будет вечным

Господин ZOMBIK временная диаграмма выложена мною в сообщении номер 25
Хоть иногда читайте чужие сообщения а не только свои

А за идею ловить синхро и данные спасибо. Очень даже может помочь в работе

Сегодня уже начал писать программу на асме имитирующую передачу кода МАСТЕРОМ вроде хорошо получается и даже такты свободные остались.

Мда...
Господин STALKNR, я читал Ваше сообщение номер 25.
И никакой информации о форме синхро сигнала там не нашел!

насчитал тупо, не особо вдаваясь в подробности


с мастером всегда проще

Нет это очень много. 8 команд вместе с записью в Sram. Частота кварца 18.432 , что бы с погрешностями не заморачиваться в дальнейшем Вот такая идейка. Завтра вечером дам этот вариант. На работе не дадут.....поработать

Вот их очередность
sbic
inc
сдвиг
dec count
brne main
st z
dec
brne main
Просто оформить надо, а сейчас лень.
Но похоже при таком ТЗ -APMом попахивает

Вот код , по идее сможем поймать биты. Но посчитать не успеваю

Я так понял, что программная реализация - это чисто спортивный интерес. Практически же этим заниматься глупо, на SPI это можно сделать проще на порядок, а может и на два. Потому что вынуть байт из SPI - это пара команд, а для программного приема каждого бита требуется не меньше десятка.

По идее, в вашем коде надо бы стек корректировать после каждого прерывания.

Согласен , но это не обязательно делать , пока отлавливаем посылку

А какже быть с 22 битами данных?


На мой взгляд при програмной реализации приема по SPI необходимо прочитать линию данных как можно ближе к фронту синхро сигнала (D-триггер это делает синхронно).
Если делать по опросу синхро то чтение линии данных произойдёт в лучшем случае через 3 такта, в худшем через 5 тактов процессора.
Если использовать прерывание то линию данных проц прочитает в самом лучшем случае через 7 тактов.
Но чтобы ответить на вопрос возможна ли реализация этого протокола нужна временная диаграмма сигналов SYNC и DATA.
TS никак не хочет ее предоставить или сам не знает, но уже пишет

А почему не хотим внешний приемник данных организовать например на группе внешних последовательно- параллельных регистров ?

Зачем нужен внешний, если есть встроенный сдвиговый регистр spi?

Коллеги! Там ТЗ , как то поменялось уже - посмотрите топик #25

Да так же, как и с началом принимаемого слова. Программно, иначе никак. А какие проблемы ? Набираем 8 битов, сохраняем... А потом программная обработка. Причем лучше уже на хосте (PC), который гораздо быстрее.

я особо не вчитывался, но показалось что то не устроило автора в SPI.
а так то конечно...



да - я бы также поступил
если не заморачиваться -
через spi берем данные из интерфейса и транслируем их через UART
а уже на другой системе анализируем..

или взять Xmega- spi завести на DMA
и уже можно сделать анализ локально..

с третьим байтом (17-22 биты) неувязка получится - он не заполнится и прерывание не сформируется. поэтому клок нужно еще на счетный вход завести - по 22 тику чтение 3-го байта

Дык мастера нет? его тоже нужно делать?
А нафига тогда 22 бита? Делаем 24 по SPI и никаких проблем.

Там их уже 33 см. 25 топик

ну значит счетчик на 33, без разницы
там, кстати, 22: