свалилось на мою голову перед новым годом ...
жеско объявлено - микросхемы интерфейсы ARINC 429 стоят дорого, поэтому и не мечтай.

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

mega64, 14Мгц

приемник кроме слушания шины, должен фильтровать пакеты и зажигать светодиоды

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

ARINC 429 - это ведь USART 32х битный?
Если так, то ничего особо сложного в такой скорости нет. С передачей никаких проблем нет вообще. А с приёмом должно получится. Минимальная частота опроса - в 4 раза выше, чем скороть передачи. Реально, лучше если в 8 раз будет. Посчитаем: 48*8=384 килогерца. При тактовой 14 Мгц - 36 тактов на бит. Если прерывание по таймеру сделать, то в нём в 20 тактов уложится надо - особых проблем я тут не вижу.
Или процессор кроме этого ещё к.л. задачей загружен будет? Если та задача жёсткого реалтайма требует, то проблеммы возникнут.

Делал полудуплексный приемопередатчик, tiny12 (1,2MHz) , скорость 10400, работает без проблем, но все "на пределе", без asm никак , у Вас проще (отношение частоты тактирования к скорости передачи больше). Но почему речь о "софтовом" UART?

А никто про софтовый и не говорил.

Не надо паниковать раньше времени. Сделать можно, и даже на си. Как сделать приём. Подключаете сигнал к ноге INT0 и для простоты ещё к какому-нибудь пину (можно и одной ногой обойтись). По приходу прерывания настраиваете таймер1 на инверсные 437 тактов (1,5*То), таймер1 работает от клоков проца. По прерыванию от таймера сдвигаете 32-битное слово, опрашиваете входную ногу, запоминаете принятый бит, затем настраиваете таймер на 292 (длительность бита То). Ну, про передачу и так понятно. По такому алгоритму у вас проц будет стоять 90% времени.

Единственная возможная проблема может возникнуть - стабильность частот прм-прд должна быть порядка 0,7%.

Я применял микросхемы для ARINC 429 типа HI-8588 + HI-8585, там идет чисто электрическое согласование без мозгов (как в МАХ232, например), это вам тоже на рассыпухе надо делать?

Вместо INT0 лучше использовать вход захвата 16-ти разрядного таймера. Тогда в программе можно будет прерывания запрещать, и это на приём влиять не будет. А потом этот-же вход опрашивать по тому-же таймеру. Но приёмник, выполненный таким способом (хоть INT0, хоть захват), будет иметь крайне плохую помехоустойчивость. Будет запускаться от короткой помехи, и при наличии помехи в середине принимаемого бита примет его неверно.

Если-уж экономить процессорное время и писать на C, то сигнал приёмника нужно на входы захватов обоих 16-ти разрядных таймеров завести (не помню как они у меги номеруются). Один настроить на передний, другой на задний фронт, прерывания разрешить от обоих. Запускать оба таймера нужно синхронно (железо позволяет), считать они должны тактовую частоту. При таком подключении без проблем можно весь сигнал восстановить при минимальных затратах процессорного времени. В т.ч. на C. Я таким образом сделал анализатор шины RS-485. Скорость, чётность, кол-во стоповых - всё на лету определялось. Байты потом восстанавливались. А здесь задача не в пример легче - формат уже известен.
В первом посте я имел ввиду, что даже просто по таймеру сделать можно. С мажоритарной проверкой каждого бита. В этом случае программа существенно проще. Если на асме, то 200 слов, не больше, и проще, чем на C. Но процессор загружать конечно сильнее будет, чем вариант с входами захвата таймеров.

большое спасибо.
буду делать. технология понятна.

А что, какие-то проблемы? Мы и на транзисторах делали, и на КМОП-ключах

физически интерфейс передатчика на двух мультиплексорах сделан которые крест-накрест комутируют +5/-5/0 на два выхода, я с авр буду на адресный вход гнать код сотояния шины. Кстате предатчик уже написал. но не испытывал - плату временно прощить нечем.

Вход захвата ничем не лучше INT0. Челу не надо определять скорость, он её и так знает. К тому же, ресурсов проца потребуется больше.

Что касается помехоустойчивости rs232. Не хотелось бы затевать полемику, но, похоже, это становится общепринятым заблуждением, что якобы можно как-то улучшить устойчивость rs232 к помехам. Последовательный интерфейс rs232 НЕ помехоустойчив ПРИНЦИПИАЛЬНО, независимо от того, делаете вы трёхкратное мажорирование или нет. Да хоть согласованный фильтр ставьте.

Случайно, ни у кого нет документации по ARINC 429 или по совектскому аналогу?

Гугль кучу информации и даташитов вываливает в ответ на ваш запрос
http://www.google.ru/search?q=ARINC+429

Спасибо