Программная реализация интерфейса Опции

[stalknr]

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

[kovigor]

Необходимо программно реализовать интерфейс типа ARINC-429.

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

Сообщение отредактировал kovigor - Apr 11 2011, 18:20

[stalknr]

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

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

[kovigor]

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

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

Сообщение отредактировал kovigor - Apr 11 2011, 18:36

[stalknr]

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

[rx3apf]

Необходимо программно реализовать интерфейс типа ARINC-429.
Последовательный интерфейс. По 1 проводу идут данные, по 2 проводу - синхросигнал (Частота 1,25 МГЦ).
Слово данных состоит из 22 разрядов

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

[stalknr]

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

[kovigor]

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

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

[stalknr]

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

[rx3apf]

а если не трудно можно пример кода для приема а то не очень понятно

Ну что-то типа:
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
.....

[stells]

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

[nk@]

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 шибко умный, ничего не выйдет.

Сообщение отредактировал nk@ - Apr 11 2011, 21:05

[rx3apf]

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

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

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

[=GM=]

По 1 проводу идут данные, по 2 проводу - синхросигнал (Частота 1,25 МГц). Слово данных состоит из 22 разрядов -> 1...6 - адрес (1-младший бит адреса, 6 - старший бит адреса) + 7...22 - данные (7 - младший, 22 - старший). Если нужны уточнения, пишите

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

[nk@]

Как раз наоборот - ведь вывод одного набранного байта это всего лишь один out

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

Однако на 20 MHz, пожалуй, реально. Реально даже если входные пакеты идут без пауз, непрерывно. А вот уложиться в паузу 9 mS - трудновато.

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

Сообщение отредактировал nk@ - Apr 12 2011, 04:34

[777777]

Последовательный интерфейс. По 1 проводу идут данные, по 2 проводу - синхросигнал (Частота 1,25 МГЦ).
Слово данных состоит из 22 разрядов -> 1...6 - адрес (1-младший бит адреса, 6 - старший бит адреса) + 7...22 - данные (7 - младший, 22 - старший).

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

[rx3apf]

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

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

На 20 MHz отправить в UART нереально. Т.е. отправить реально, а принять без ошибок, на 115200 - не выйдет.

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

Сейчас у мамок com-порты отвратительные, с подстройкой фазы все очень плохо (особенно "радуют" мамки на nForce - чуть в сторону и приехали). Потери - гарантированы.

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

[nk@]

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

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

Ой, ну да ладно страсти-то какие-то рассказывать, а ? Какие-такие "подстройки фазы" ?

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

[rx3apf]

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

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

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

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

[nk@]

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

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

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

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

[kovigor]

Когда идет обмен с паузами - все хорошо, а вот дуплекс на большом объеме им не под силу.

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

Сообщение отредактировал kovigor - Apr 12 2011, 11:34

[ILYAUL]

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

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

[=GM=]

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

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

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

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

[rx3apf]

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

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

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

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

Сообщение отредактировал rx3apf - Apr 12 2011, 15:13

[stalknr]

Здравствуйте товарищи!!!!
Докладываю голосом!
Длительность 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 по МК

[zombi]

Ну что-то типа:
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
.....

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

Код

  ldi acc1,0
b7_0:
sbis port,synch
rjmp b7_0
sbic port,bit_IN
ori acc1,$80
b7_1:
sbic port,synch
rjmp b7_1

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

[rx3apf]

Или я ни че не понял или надо вот так:
ldi acc1,0

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

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

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

[zombi]

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

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

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

Код

    ldi  count,8
cc0:sbic port,synch
    rjmp cc0
    lsl  acc1
cc1:sbis port,synch
    rjmp cc1
    sbic port,bit_IN
    ori  acc1,$01
    dec     count
    brne cc0

[rx3apf]

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

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

Сообщение отредактировал rx3apf - Apr 12 2011, 17:58

[stells]

Кстати начальное обнуление вообще не нужно

Код

    ldi  count,8
cc0:sbic port,synch
    rjmp cc0
    lsl  acc1
cc1:sbis port,synch
    rjmp cc1
    sbic port,bit_IN
    ori  acc1,$01
    dec     count
    brne cc0

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

[zombi]

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

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

[stalknr]

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

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

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

[zombi]

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

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

[stells]

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

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

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

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

[ILYAUL]

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

Код

    ldi  count,8
cc0:sbic port,synch
    rjmp cc0
    lsl  acc1
cc1:sbis port,synch
    rjmp cc1
    sbic port,bit_IN
    ori  acc1,$01
    dec     count
    brne cc0

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

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

[ILYAUL]

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

CODE

***********************
;/ * *
;/ * ATMega 164P *
;/ * *
;/ ***********************

; Ну def и equ не пишу

;*************************************************
;* ;;/ТАБЛИЦА прерываний;;* *
;*************************************************
jmp RESET ;/Reset

.org INT0addr
sbic PORTX,PXX; Линия данных ARINC-429
inc temp
lsl temp
dec count
brne MAIN
st Z,temp
ldi count,8
dec ZL
brne MAIN

; jmp PCINT0 ; PCINT0
; jmp PCINT1 ; PCINT1
; jmp PCINT2 ; PCINT2
; jmp PCINT3 ; PCINT


;**************************************************
;* ;;/Initialization ExtInterrupr;;* *
;**************************************************

; ЛОВИМ СИНХРОИМПУЛЬСЫ ARINC-429 по INT0
RESET:
ldi temp,1<<INTF0
out EIFR,temp
ldi temp,1<<INT0 ; Разрешаем прерывание INT0
out EIMSK,temp
ldi temp,1<<ISC01|0<<ISC00
sts EICRA,temp ;+ По спадающему фронту
-------------------------------------
ldi count,8

; Не продумывал особо, но на расположение буффера возможно придётся делать ограничение
; Он должен находится в самом начале памяти, в данном MCU = 100
ldwi Z,BUFF ; макрос LDI
; Ниже команду пишу специально , хотя по сути она не нужна, так чтобы была понятно логика
subi ZL,-33
;**************************************************
sei
MAIN: rjmp MAIN

Сообщение отредактировал IgorKossak - Apr 13 2011, 09:55

Причина редактирования: [codebox] !!!

[777777]

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

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

[=GM=]

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

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

[ILYAUL]

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

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

[zombi]

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

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

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

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

программу на асме имитирующую передачу кода МАСТЕРОМ

[Kovrov]

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

[=GM=]

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

[ILYAUL]

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

[rx3apf]

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

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

[Kovrov]

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

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

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

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

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

[ILYAUL]

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

[stells]

Набираем 8 битов, сохраняем...

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

[zombi]

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

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

[ILYAUL]

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

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

[stells]

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

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

Длительность слова = 22р*0,800мкс=17,6 мкс

Сообщение отредактировал stells - Apr 13 2011, 12:53

[rx3apf]

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

Откуда читать-то недопринятый байт ? И, главное, зачем ? Ну добьет его его синхронизация парой нулей или единиц, возьмем на два клока позже. Опять же момент старта - он произвольный, и где сколько битов - изначально непредсказуемо. Равно как и между словами.

[zombi]

по 22 тику чтение 3-го байта

А попадет ли недозадвинутый байт в "READ DATA BUFFER" ?

[stells]

Откуда читать-то недопринятый байт ?

а регистр недоступен?

Ну добьет его его синхронизация парой нулей или единиц, возьмем на два клока позже.

это если синхросигнал непрерывный

[rx3apf]

а регистр недоступен?

Регистр приема - недоступен. Доступен буферный, где лежит собранный байт.

это если синхросигнал непрерывный

Я понял так, что синхра непрерывная. Если нет - то либо USI, либо программно, либо добивать самому через внешнюю логику (как вариант - монтажную).

[stells]

Я понял так, что синхра непрерывная. Если нет - то либо USI, либо программно, либо добивать самому через внешнюю логику (как вариант - монтажную).

насчет непрерывности непонятно, а насчет монтажного или я тоже хотел предложить вариант - контроллер сам добивает число клоков до 24

[zombi]

Я понял так, что синхра непрерывная.

О какой непрерывности синхро может идти речь если между словами и пачками есть паузы???

[stells]

О какой непрерывности синхро может идти речь если между словами и пачками есть паузы???

да и как старт обнаружить? нет, синхросигнал тоже на 22 такта... наверняка

[zombi]

насчет непрерывности непонятно, а насчет монтажного или я тоже хотел предложить вариант - контроллер сам добивает число клоков до 24

Думаю можно, и паузы между словами оч. кстати.

[stells]

в общем от контроллера нужно 3 ноги: MOSI, SCK, T0. последние 2 замкнуты и сигнал на них подаем через резистор. по счетному входу считаем до 22, потом переводим его на выход и дергаем 2 раза

[rx3apf]

О какой непрерывности синхро может идти речь если между словами и пачками есть паузы???

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

[zombi]

А вникать в особенности конкретного интерфейса и протокола мне лениво. Если нет синхры - делать ее руками. Если есть - разгребать, что приходит.

Интересно сколько мы еще будем фантазировать???
Может лучше TSра дождаться

[kovigor]

Может лучше TSра дождаться

Или модератора, чтобы переместил эту тему в раздел для новичков, потому как по сути своей проблема примитивна до крайности ...

[stells]

Или модератора, чтобы переместил эту тему в раздел для новичков, потому как по сути своей проблема примитивна до крайности ...

и это после Ваших слов:

Пробуйте,только уж больно все это сомнительно выглядит ...

[=GM=]

Кто-то здесь подсчитал, что при использовании прерываний будет задержка не менее 7 тактов, а при программном опросе (поллинге) - 0-5. Как-то непонятно мне почему так, вроде бы цикл опроса занимает 3 такта, значит и погрешность задержки должна быть не более 3-х. Попробовал сам написать, получил задержку погрешности не более 2-х тактов. Интересно, можно ли довести до 1-го такта. Никто не пробовал?

Также интересно узнать количество тактов по занесению бита, принятого с любого пина порта, в байт, можно ли уложиться в один такт? Я уложился в два.

[zombi]

а при программном опросе (поллинге) - 0-5.

Не было такого! Было 3-5.

Попробовал сам написать, получил задержку погрешности не более 2-х тактов.

Код надеюсь не секретный? можно взглянуть?

[777777]

в общем от контроллера нужно 3 ноги: MOSI, SCK, T0. последние 2 замкнуты и сигнал на них подаем через резистор. по счетному входу считаем до 22, потом переводим его на выход и дергаем 2 раза

Счетчик не нужен. Достаточно перед приемом дернуть SCK два раза, а потом принять три байта.

[=GM=]

Не было такого! Было 3-5. Код надеюсь не секретный? можно взглянуть?

Ну откуда 3-5, если чтение идёт каждые 3 такта?

Конечно покажу, чуть попозже, но хочется немного пообсуждать то, что уже показано.

[zombi]

Счетчик не нужен. Достаточно перед приемом дернуть SCK два раза, а потом принять три байта.

Действительно все гениальное просто! 777777

[stells]

Действительно все гениальное просто! 777777

да, согласен. и от меня пиво

[stalknr]

Привет Господа!!!!
Смотрю пока я на работе был вы тут во всю обсуждаете.
Вообщем по SPI не кошерно такделать. Тобишь дергать ножкой до или после приема.
Во вторых Синхро прерывистый по 22 шт в слове
Мастера делаю на основе уже готового устройства. Мастер нужен для тестирования потом СЛАЙВА
Какие еще вопросы

ДА и еще как вы узнаете когда дергать надо

[stells]

Вообщем по SPI не кошерно такделать. Тобишь дергать ножкой до или после приема.

ДА и еще как вы узнаете когда дергать надо

аргументы? дергать сразу после инициализации и после приема очередного слова

[stalknr]

Мне надо на один пин выдавать ДАННЫЕ (АДРЕС+ПУСТОЙ БАЙТ+ПУСТОЙ БАЙТ) в тут же с другого пина принимать

[stells]

Мне надо на один пин выдавать ДАННЫЕ (АДРЕС+ПУСТОЙ БАЙТ+ПУСТОЙ БАЙТ) в тут же с другого пина принимать

так у Вас дуплекс что-ли? вроде речь шла об обмене в одну сторону?

[stalknr]

так ведет себя МАСТЕР. СЛАЙВ в этот момент принимает ПОСТОЕ СЛОВО и на его основе формирует ответ.

Код

//----------------------------------------------------------------------------
//                  Процедура     _peredacha_slova_PRD
//----------------------------------------------------------------------------
// передаем слово данных ведомому
_peredacha_slova_PRD:
    
//-------------------------------------------------
// выдаем на PORTB.0 6 младших разрядов байта ADRES_OUT
//-------------------------------------------------
_out_ADRES_OUT:
    OUT  PORTB, temp            //50ns   в регистр ввода-вывада (РВВ) передаем R16 PORTB
    ROR  ADRES_OUT                      //100ns  сдвигаем ADRES_OUT вправо причем SREG.C=ADRES_OUT.0
    BRCS C_1                    //150ns  Выдаем
    SBR  temp, (1<<PB1)            // если бит SREG.С=0 то выдаем в выдаем в порт только синхросигнал
    RJMP C_0
C_1:SBR  temp, (1<<PB1)+(1<<PB0)// если бит SREG.С=1 то выдаем в выдаем в порт  синхросигнал и сам бит
    NOP
C_0:NOP
    INC  Nraz                    //400нс  увеличиваем счетчик разрядов на +1
//_________________________________________
    OUT  PORTB, temp            //450нс  в регистр ввода-вывада (РВВ) передаем R16 PORTB
    CLR  temp                   //500ns  чистим темп
    NOP                              //550ns
    NOP                             //600ns
    NOP                             //650ns
    CPI  Nraz, 0x06               //700ns и 750ns  считаем 6 умпульсов
    BRLO _out_ADRES_OUT               //800ns  Nrz < 6  переход по "меньше"
//-------------------------------------------------
    NOP

//-------------------------------------------------
// выдаем на PORTB.0 8 разрядов байта DATA_L
//-------------------------------------------------
_out_DATA_L:
    OUT  PORTB, temp            //50ns   в регистр ввода-вывада (РВВ) передаем R16 PORTB
    ROR  DATA_L                      //100ns
    BRCS C_3                    //150ns  Выдаем
    SBR  temp, (1<<PB1)            // если бит SREG.С=0 то выдаем в выдаем в порт только синхросигнал
    RJMP C_2
C_3:SBR  temp, (1<<PB1)+(1<<PB0)// если бит SREG.С=1 то выдаем в выдаем в порт  синхросигнал и сам бит
    NOP
C_2:NOP
    INC  Nraz                    //400нс  увеличиваем счетчик разрядов на +1
//_________________________________________
    OUT  PORTB, temp            //450нс  в регистр ввода-вывада (РВВ) передаем R16 PORTB
    CLR  temp                   //500ns  чистим темп
    NOP                              //550ns
    NOP                             //600ns
    NOP                             //650ns
    CPI  Nraz, 0x0E               //700ns и 750ns  считаем 6+8 умпульсов
    BRLO _out_DATA_L               //800ns  Nrz < 6+8  переход по "меньше"
//-------------------------------------------------
    NOP

//-------------------------------------------------
// выдаем на PORTB.0 8 разрядов байта DATA_H
//-------------------------------------------------
_out_DATA_H:
    OUT  PORTB, temp            //50ns   в регистр ввода-вывада (РВВ) передаем R16 PORTB
    ROR  DATA_H                      //100ns
    BRCS C_5                    //150ns  Выдаем
    SBR  temp, (1<<PB1)            // если бит SREG.С=0 то выдаем в выдаем в порт только синхросигнал
    RJMP C_4
C_5:SBR  temp, (1<<PB1)+(1<<PB0)// если бит SREG.С=1 то выдаем в выдаем в порт  синхросигнал и сам бит
    NOP
C_4:NOP
    INC  Nraz                    //400нс  увеличиваем счетчик разрядов на +1
//_________________________________________
    OUT  PORTB, temp            //450нс  в регистр ввода-вывада (РВВ) передаем R16 PORTB
    CLR  temp                   //500ns  чистим темп
    NOP                              //550ns
    NOP                             //600ns
    NOP                             //650ns
    CPI  Nraz, 0x16               //700ns и 750ns  считаем 6+8+8 умпульсов
    BRLO _out_DATA_H              //800ns  Nrz < 6+8+8  переход по "меньше"
//-------------------------------------------------    

//             КОНЕЦ ВЫДАЧИ СЛОВА     
    NOP
    OUT  PORTB, temp            // ставим на линию данных 0 и на линию синхро тоже 0
    CLR  Nraz                    // обнуляем счетчик разрядов
    INC  Nsl                    // увеличиваем счетчик слов на +1
    CLR  temp
    RET                            // Выход из процедуры _peredacha_slova_PRD   RET=4 маш. циклов
//----------------------------------------------------------------------------



//----------------------------------------------------------------------------
//                  Процедура     _peredacha_slova_PRM
//----------------------------------------------------------------------------
// передаем слово ведомому и принимаем от него информацию
_peredacha_slova_PRM:
    CLR  ADRES_IN
    CLR  DATA_L
    CLR  DATA_H
//-------------------------------------------------
// выдаем на PORTB.0 6 младших разрядов байта ADRES_OUT
// принимаем на PORTB.2 6 младших разрядов байта ADRES_IN
//-------------------------------------------------
_out_ADRES_OUT_and_in_ADRES_IN:
    OUT  PORTB, temp            //50ns   в регистр ввода-вывада (РВВ) передаем R16 PORTB
    ROR  ADRES_OUT                  //100ns  сдвигаем ADRES_OUT вправо причем SREG.C=ADRES_OUT.0
    BRCS C_7                    //150ns  Выдаем
    SBR  temp, (1<<PB1)            // если бит SREG.С=0 то выдаем в выдаем в порт только синхросигнал
    RJMP C_6
C_7:SBR  temp, (1<<PB1)+(1<<PB0)// если бит SREG.С=1 то выдаем в выдаем в порт  синхросигнал и сам бит
    NOP
C_6:LSR  ADRES_IN
    INC  Nraz                    //400нс  увеличиваем счетчик разрядов на +1
//_________________________________________
    OUT  PORTB, temp            //450нс  в регистр ввода-вывада (РВВ) передаем R16 PORTB
    CLR  temp                   //500ns  чистим темп
    NOP                              //550ns  
    SBIC PINB, PB2                //600ns  если PINB.2=0 то пропускаем следующую команду
    SBR  ADRES_IN, (1<<7)               //650ns  ставим 1 в 7 разряде ADRES_IN
    CPI  Nraz, 0x06               //700ns и 750ns  считаем 6 умпульсов
    BRLO _out_ADRES_OUT_and_in_ADRES_IN             //800ns  Nrz < 6  переход по "меньше"
//-------------------------------------------------
    NOP

//-------------------------------------------------
// принимаем на PORTB.2 8 разрядов байта DATA_L
//-------------------------------------------------
_in_DATA_L:
    OUT  PORTB, temp            //50ns   в регистр ввода-вывада (РВВ) передаем R16 PORTB
    LSR  DATA_L                    //100ns
    NOP                            //150ns  
    NOP                            //200ns  выдаем в выдаем в порт только синхросигнал
    NOP                            //250ns
    NOP                            //300ns
    SBR  temp, (1<<PB1)            //300ns
    INC  Nraz                    //400нс  увеличиваем счетчик разрядов на +1
//_________________________________________
    OUT  PORTB, temp            //450нс  в регистр ввода-вывада (РВВ) передаем R16 PORTB
    CLR  temp                   //500ns  чистим темп
    NOP                              //550ns
    SBIC PINB, PB2                //600ns  если PINB.2=0 то пропускаем следующую команду
    SBR  DATA_L, (1<<7)               //650ns  ставим 1 в 7 разряде DATA_L
    CPI  Nraz, 0x0E               //700ns и 750ns  считаем 6+8 умпульсов
    BRLO _in_DATA_L               //800ns  Nrz < 6+8  переход по "меньше"
//-------------------------------------------------
    NOP

//-------------------------------------------------
// выдаем на PORTB.0 8 разрядов байта DATA_H
//-------------------------------------------------
_in_DATA_H:
    OUT  PORTB, temp            //50ns   в регистр ввода-вывада (РВВ) передаем R16 PORTB
    LSR  DATA_H                      //100ns
    NOP                            //150ns  
    NOP                            //200ns  выдаем в выдаем в порт только синхросигнал
    NOP                            //250ns
    NOP                            //300ns
    SBR  temp, (1<<PB1)            //300ns
    INC  Nraz                    //400нс  увеличиваем счетчик разрядов на +1
//_________________________________________
    OUT  PORTB, temp            //450нс  в регистр ввода-вывада (РВВ) передаем R16 PORTB
    CLR  temp                   //500ns  чистим темп
    NOP                              //550ns
    SBIC PINB, PB2                //600ns  если PINB.2=0 то пропускаем следующую команду
    SBR  DATA_H, (1<<7)            //650ns  ставим 1 в 7 разряде DATA_H
    CPI  Nraz, 0x16               //700ns и 750ns  считаем 6+8+8 умпульсов
    BRLO _in_DATA_H              //800ns  Nrz < 6+8+8  переход по "меньше"
//-------------------------------------------------    
    NOP
//             КОНЕЦ ПРИЕМА СЛОВА     
    
    OUT  PORTB, temp            // ставим на линию данных 0 и на линию синхро тоже 0
    CLR  Nraz                    // обнуляем счетчик разрядов
    INC  Nsl                    // увеличиваем счетчик слов на +1
    LSR  ADRES_IN
    LSR  ADRES_IN                // сдивагаем 2 раза чтобы получить 1р адреса в 0р байта (ПОДГОНЯЕМ ПОД ФОРМАТ)
    
    LDI  DATA_L, 0xAA

    LDI  YH, 0x01
    LDI  temp, 0x03
    MUL  temp, ADRES_IN
    MOV  YL, R0

    ST   Y+, ADRES_IN
    ST   Y+, DATA_L
    ST   Y+, DATA_H
    CLR  YL

;    CLR  ADRES_IN
;    CLR  DATA_L
;    CLR  DATA_H
    CLR  temp
    RET                            // Выход из процедуры _peredacha_slova_PRD   RET=4 маш. циклов
//----------------------------------------------------------------------------

ЭТО ЧУДО у меня в протеусе сегодня заработало

КОРОЧЕ в посылке у МАСТЕРА сначало 33 слово только на передачу (СЛАЙВ в это время принимает, складывает это все в ОЗУ и формирует ответ ввиде АДРЕС+2 ПУСТЫХ БАЙТА (НАХРЕНА НЕЗНАЮ)) далее перерыв в 300 мкс и МАСТЕР выдает еще 33 слова на передачу и прием (тоесть формирует для СЛАЙВА синхро сигнал и принимает от него данные) затем идет 6*1,28 мс пауза и все заново начинаеться

[zombi]

ЭТО ЧУДО у меня в протеусе сегодня заработало

Код

//                  Процедура     _peredacha_slova_PRM
// выдаем на PORTB.0 6 младших разрядов байта ADRES_OUT
// принимаем на PORTB.2 6 младших разрядов байта ADRES_IN
...
    OUT  PORTB, temp            //450нс  в регистр ввода-вывада (РВВ) передаем R16 PORTB
    CLR  temp                   //500ns  чистим темп
    NOP                              //550ns  
    SBIC PINB, PB2                //600ns  если PINB.2=0 то пропускаем следующую команду
...

Т.е. Вы полагаете что слейв успеет за 150нс детектировать синхро, принять бит данных и еще на передачу чето выдать?
Может стоит начать работу с написания слейва? тогда не пришлось бы тратить время на написание мастера.

[stalknr]

в начале пачки идет пустое слово (для синхроназации)
тоесть получив такое слово СЛАЙВ в свои ADRES_OUT и DATA_L, DATA_H запишет значения которые надо передавать когда придет следующее слово от МАСТЕРА.
тоесть реально СЛАЙВ будет ждать прихода синхро сигнала

ПРИШЕЛ СИНХРО
OUT PORTB, temp //выдаем бит данных и бит синхро
IN temp, PIND //читаем что нам МАСТРЕ прислал
формируем бит для следующей посылки и обрабатываем принятую информацию

[zombi]

Ну откуда 3-5, если чтение идёт каждые 3 такта?

Считал по коду своего Сообщения #28

ПРИШЕЛ СИНХРО

Ваш слейв собирается тратить время на анализ "ПРИШЕЛ СИНХРО" ?

[stalknr]

Интересно а как он узнает когда ему данные надо прочитать

_M1:
SBIS PORTD, PIN_SINX
RJPM _M1
OUT PORTB, temp //выдаем бит данных и бит синхро
IN temp, PIND //читаем что нам МАСТРЕ прислал
........

[zombi]

Т.е. слейв тоже может формировать синхро?
Нее шото я совсем запутался

[stalknr]

Может. МАСТЕР и СЛЕЙВ связаны линиями ПК1 и ПК2
ПК1 синхро и данные от МАСТЕРА к СЛЕЙВУ
ПК2 синхро и данные от СЛЕЙВА к МАСТЕРУ

[zombi]

Может. МАСТЕР и СЛЕЙВ связаны линиями ПК1 и ПК2
ПК1 синхро и данные от МАСТЕРА к СЛЕЙВУ
ПК2 синхро и данные от СЛЕЙВА к МАСТЕРУ

ОПУПЕТЬ! Т.е. линии двунаправленные?

По 1 проводу идут данные, по 2 проводу - синхросигнал (Частота 1,25 МГЦ).

Мы Вам шо здесь телепаты ???

[stalknr]

Нет линии не двунаправленные
ПК1 - 2 провода (синхро и данные) от МАСТЕРА к СЛЕЙВУ
ПК2 - 2 провода (синхро и данные) от СЛЕЙВА к МАСТЕРУ

[stells]

да уж, тем более, что от arinc 429 остался только полный дуплекс:
http://ru.wikipedia.org/wiki/ARINC_429

[stalknr]

По ПК1 МАСТЕР кидает данные и синхро СЛЕЙВУ а по ПК2 принимает от СЛАЙВА данные и синхро

[zombi]

Нет линии не двунаправленные
ПК1 - 2 провода (синхро и данные) от МАСТЕРА к СЛЕЙВУ
ПК2 - 2 провода (синхро и данные) от СЛЕЙВА к МАСТЕРУ

Алекс - Юстасу ( ПК1 и ПК2 это четыре провода)!
Согласитесь чтобы догадаться об этом (на основании Ваших сообщений) просто необходимо обладать хотябы минимальными телепатическими способностями!

[stalknr]

ЦЕНТЕР-ГЕРЕНГУ
Нас спалили переходим на нелегальное положение.

Что то от темы отклонились

[zombi]

Что то от темы отклонились

А что собственно интересует? Вроде на все уже ответили вдоль и поперёк.

[stalknr]

да кстате Господа как сформировать сигнал длительность 1,28 мс и периодом повторения 10,24 мс. Я так понимаю это надо делать на таймере подскажите как это на асме реализовать

[zombi]

да кстате Господа как сформировать сигнал длительность 1,28 мс и периодом повторения 10,24 мс. Я так понимаю это надо делать на таймере подскажите как это на асме реализовать

А нужно ли оно на таймере? Если проц всеравно ниче не делает. Не проще ли сделать цикл на 25.600 и 204.800 тактов соответсвенно.

[=GM=]

Обсуждения не получилось, ну да ладно. Давайте поговорим о ловле начала синхронизации. Прежде всего надо условиться о терминологии. Вы согласны, что в вашем коде чтение синхроноги идёт каждые 3 такта?

Код

getsyn: sbis porta,synpin
        rjmp getsyn

То есть, после завершения кода можно сказать, что переход 0-1 наступил не позднее 3 тактов назад.

[zombi]

Обсуждения не получилось, ну да ладно. Давайте поговорим о ловле начала синхронизации. Прежде всего надо условиться о терминологии. Вы согласны, что в вашем коде чтение синхроноги идёт каждые 3 такта?

Код

getsyn: sbis porta,synpin
        rjmp getsyn

То есть, после завершения кода можно сказать, что переход 0-1 наступил не позднее 3 тактов назад.

А как Вы считаете эти такты?

[Hmm]

О чем это все. Для 'ARINC-429' скорость максимум 100 кбод. Обязательно отклонение частоты, но не более 1%. Если это для отечественного применения, то необходимо "вкурить" РТМ1495 (изм.3). Реализуется программно без проблем.

[zombi]

О чем это все. Для 'ARINC-429' скорость максимум 100 кбод. Обязательно отклонение частоты, но не более 1%. Если это для отечественного применения, то необходимо "вкурить" РТМ1495 (изм.3). Реализуется программно без проблем.

Необходимо программно реализовать интерфейс типа ARINC-429.

Может слово типа не просто так?

[stalknr]

Привет всем!!!
Есть идея для слайва. Поставить внешний 22 разрядный сдвигающий регистр и с помощью него принимать информацию от МАСТЕРА а в контроллер загонять уже параллельный код.

[_pv]

Вообщем по SPI не кошерно такделать. Тобишь дергать ножкой до или после приема.
Во вторых Синхро прерывистый по 22 шт в слове
Мастера делаю на основе уже готового устройства. Мастер нужен для тестирования потом СЛАЙВА
Какие еще вопросы
ДА и еще как вы узнаете когда дергать надо

если взять USART в синхронном режиме вместо SPI, у него в атмеге можно менять длину слова от 5 до 9 бит, то есть принять два байта по 8 бит, а потом поменять длину принимаемого байта на 6.

[Hmm]

Может слово типа не просто так?

Может и так скорее всего ... Плотно этим уЖе занимается 'ELCUS', а уж про "прикладным" задачам по авионике здесь "не место" (ИМХО), остальное - ширпотреб или очередной "курсовик"
+
Кстати можно подумать о использовании MSPI режима ...

[zombi]

Привет всем!!!
Есть идея для слайва. Поставить внешний 22 разрядный сдвигающий регистр и с помощью него принимать информацию от МАСТЕРА а в контроллер загонять уже параллельный код.

Аааа... Наконец то ...
Вам это во 2-м посте предложили.

[stalknr]

Только вот не очень хочется ставить 6шт кр555ИР16 может порекомендуете какой нибудь регистр. Требования: возможность последовательной и параллельной загрузки данных, выходы параллельных данных с третьим состоянием

[kovigor]

Только вот не очень хочется ставить 6шт кр555ИР16 может порекомендуете какой нибудь регистр. Требования: возможность последовательной и параллельной загрузки данных, выходы параллельных данных с третьим состоянием

А я не случайно сразу написал: CPLD. Вы бы уже разобрались как там и чего за то время, что пытаетесь "превратить карася в порося" ...

[=GM=]

А как Вы считаете эти такты?

Ну как, по рабоче-крестьянски. Если synpin=0, то sbis выполняется за 1 такт, потом выполняется rjmp за 2 такта, опять читается, и опять, и опять. Т.о., чтение ноги осуществляется через каждые три такта, согласны? Можете сделать чтение через два такта?