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

[stalknr]

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

[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 - трудновато.

[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

[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-овская мама, работает без проблем. Вот такая вечная молодость.

[rx3apf]

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

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

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

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

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

[777777]

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

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

[zombi]

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

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

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

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

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

[rx3apf]

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

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

[stells]

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

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

[rx3apf]

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

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

[stells]

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

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

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

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

[rx3apf]

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

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

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

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

[stells]

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

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