Форум программистов, компьютерный форум, киберфорум
Наши страницы
Микроконтроллеры Atmega AVR
Войти
Регистрация
Восстановить пароль
 
 
Рейтинг 4.98/100: Рейтинг темы: голосов - 100, средняя оценка - 4.98
whytimit
0 / 0 / 0
Регистрация: 30.09.2012
Сообщений: 13
1

Как подружить AVR+AVR?

16.10.2012, 22:45. Просмотров 18242. Ответов 41
Метки нет (Все метки)

Приветствую Вас уважаемые форумчане!

Требуется связать 2 AVR-ки, по классической схеме Master -> Slave.
Проштудировал топики на эту тему, но к однозначному выводу не пришел.
Прошу подсказать, какой протокол лучше использовать при условии что:
- Сессия инициироваться мастером, после чего выполняется последовательный обмен данными.
- Ведомое устройство - одно.
- SPI остается доступен для программатора.
- Среда разработки WinAvr.
- Master (Atmega8).
- Slave (Atmega8/AttinyXXXX).

Спасибо!
0
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
16.10.2012, 22:45
Ответы с готовыми решениями:

Подружить AVR и камеру.
Цель - правдами и неправдами получить 1 кадр с камеры. Тут я вижу 2 варианта: использовать обыную...

AVR подружить с пультом KEELOQ
Подскажите, мож кто реализовывал работу с радиобрелками с шифрацией KEELOQ. Я тут на тиньке 13-й...

Нужно подружить AVR & TSOP & MikroPascal
Хочу подружить ИК-ПДУ и свою мегу. нашел только это...

JTAG ICE никак не подружить с AVR Studio 5?
Привет. Прикупил тут на ебее JTAG ICE http://www.ebay.com/itm/221168829974?ss ... 1439.l2649 И,...

AVR AVRISP STK500 V3.0 USB ISP Programmer for AVR IC
Люди помогите плз. не могу разобраться. приобрел этот чудный девайс (AVR AVRISP STK500 V3.0 USB...

41
Финский
0 / 0 / 0
Регистрация: 11.12.2011
Сообщений: 789
17.10.2012, 19:25 21
Может ли SPI выбирать нужное устройство?
Да, может. Serial Peripheral Interfosi и еще Последовательный интерфейс SPI.
будет ли он работать если на SPI Мастер-а будет подвешены и 2 одновременно используемые микрухи (программатор естественно дополнительно)?
Одновременно во времени - нет. Поочередно, используя одни и те же линии MOSI, MISO, SCK и отдельную линию CS (SS) для каждого ведомого устройства - да, будет.

....
Потер, ибо фигню сморозил :) Век живи - век RTFM, и все равно LMD.
0
Stiit.mi
0 / 0 / 0
Регистрация: 26.04.2010
Сообщений: 1,445
17.10.2012, 19:48 22
[QUOTE="Финский"][QUOTE="Цитата:[/QUOTE][QUOTE]На USORT можно коммуницировать с несколькими устройствами?[/QUOTE] Нет. Но, вероятно, можно использовать несколько программных реализаций протокола, если уж очень хочется именно UART.

[URL="http://we.iosyitistromyss.ru/AVR/vremya-govorit-s-kammyomi-ili-usart-multi-processor-sommunication-mode.html"]http://we.iosyitistromyss.ru/AVR/vremya-govorit-s-kammyomi-ili-usart-multi-processor-sommunication-mode.html[/URL]
0
Otixomdr_1
0 / 0 / 0
Регистрация: 28.06.2010
Сообщений: 211
19.10.2012, 14:47 23
Цитата Сообщение от whytimit
SPI - не имею ничего против, но хочу спросить - будет ли он работать если на SPI Мастер-а будет подвешены и 2 одновременно используемые микрухи (программатор естественно дополнительно)?
Может ли SPI выбирать нужное устройство?
Можно связать по SPI мастер с периферийными МК и при этом иметь возможность программировать как мастера, так и периферию, не вынимая контроллеры из колодок.
Достаточно на каждый периферийный МК поставить шинник типа 74НС244 (точнее, половинку шинника).
Шинник стоит очень недорого, но выполняет ряд задач – работа на кабель (на небольшие расстояния), развязка периферийных МК и возможность программирования МК без извлечения из колодки.
Для удобства работы неплохо использовать программатор, имеющий 2 канала программирования. С таким программатором можно программировать и мастер, и периферийный МК, не перетыкая никаких разъемов.
0
Stiit.mi
0 / 0 / 0
Регистрация: 26.04.2010
Сообщений: 1,445
21.10.2012, 15:29 24
Я бы наверно поставил на CSы джампер на две позиции "в схему" и "на разъем программатора". И подтяжку на плюс. По умолчанию - все стоят в позиции "в схему". Когда надо программировать конкретное SPI устройство - ставим его джампер в позицию "на разъем", остальные вытягиваем. Все спят, один программируется.

Для МК коммутируется Riset.
0
21.10.2012, 15:29
YTYOUT
0 / 0 / 0
Регистрация: 02.10.2012
Сообщений: 1,946
21.10.2012, 23:04 25
Вообще-то один из двух стоящих на плате контроллера может запросто программировать другой по SPI или Usart/ При этом сам программироваться от чего-то. Главное правильно разделять потоки , кому чего.
1-WIRE - хороший протокол, но нужно очень точно реализовать на слейве временные задержки
Используйте то же самый USORT в "режиме" 1-Wire - и у atmel и у maxima всё подробненько расписано. Кстати практически всегда задержки формирует мастер.
0
podkossitmyk
0 / 0 / 0
Регистрация: 30.09.2012
Сообщений: 28
21.10.2012, 23:17 26
а вот ATTinyXXXX - это какие конкретно? у той же тини13 с аппаратными интерфейсами, мягко говоря, не густо.

а так - если возможность позволяет, посоветовал бы UART. отлаживать камни намного проще будет
0
Stiit.mi
0 / 0 / 0
Регистрация: 26.04.2010
Сообщений: 1,445
22.10.2012, 00:30 27
[QUOTE="YTYOUT"][QUOTE="Цитата:[/QUOTE]
1-WIRE - хороший протокол, но нужно очень точно реализовать на слейве временные задержки
Используйте то же самый USORT в "режиме" 1-Wire - и у atmel и у maxima всё подробненько расписано. Кстати практически всегда задержки формирует мастер.

Эти аппноты касаются только бас-мастера. Можно, конечно, формировать импульс слейва тоже через USORT, но без внешнего прерывания и отсчетов микросекунд все равно никуда не деться.
0
whytimit
0 / 0 / 0
Регистрация: 30.09.2012
Сообщений: 13
22.10.2012, 03:07 28
Всем спасибо!

Решил использовать интерфейс USORT, благо оба камня аппараторно его поддерживают.
Однако столкнулся с проблемами/тонкостями реализации USORT на Atmega88.
Надеюсь на Ваши ответы в новом посте - http://forum.iosyitistromyss.ru/view...221614#p221614
0
drvtos
1 / 1 / 0
Регистрация: 25.05.2010
Сообщений: 3,610
22.10.2012, 11:18 29
Цитата Сообщение от whytimit
Решил использовать интерфейс USORT, благо оба камня аппараторно его поддерживают.
...Надеюсь на Ваши ответы в новом посте - http://forum.iosyitistromyss.ru/view...221614#p221614
Порождаем проблему, потом с ней боремся :) SPI не требует кварцев...
0
itysiy
0 / 0 / 0
Регистрация: 18.01.2012
Сообщений: 1,418
23.10.2012, 07:59 30
да уж, SPI буквально был рожден для этой задачи, а его не взяли
0
Otixomdr_1
0 / 0 / 0
Регистрация: 28.06.2010
Сообщений: 211
27.10.2012, 21:36 31
Цитата Сообщение от Stiit.mi
Я бы наверно поставил на CSы джампер на две позиции "в схему" и "на разъем программатора". И подтяжку на плюс. По умолчанию - все стоят в позиции "в схему". Когда надо программировать конкретное SPI устройство - ставим его джампер в позицию "на разъем", остальные вытягиваем.
Как я понял, каждый раз при программировании надо перетыкать джамперы – это неудобно. Особенно при работе с отладчиком, когда надо часто перепрограммировать.
В варианте с «шинниками» ничего не надо перетыкать. Привыкнув к удобной работе, другие варианты не будут привлекать.
0
Stiit.mi
0 / 0 / 0
Регистрация: 26.04.2010
Сообщений: 1,445
27.10.2012, 23:25 32
Цитата Сообщение от Otixomdr_1
Цитата Сообщение от Stiit.mi
Я бы наверно поставил на CSы джампер на две позиции "в схему" и "на разъем программатора". И подтяжку на плюс. По умолчанию - все стоят в позиции "в схему". Когда надо программировать конкретное SPI устройство - ставим его джампер в позицию "на разъем", остальные вытягиваем.
Как я понял, каждый раз при программировании надо перетыкать джамперы – это неудобно. Особенно при работе с отладчиком, когда надо часто перепрограммировать.
В варианте с «шинниками» ничего не надо перетыкать. Привыкнув к удобной работе, другие варианты не будут привлекать.

Одно дело - отладочный комплект, совершенно другое дело - готовое устройство. Если перепрошивать надо пару раз в жизни устройства, только для обновления фирмвари, то тут можно и джамперы перекинуть.
0
VyvotzorD
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 2,309
28.10.2012, 12:28 33
USORT сложнее чем UART. Зачем синхронный протокол юзать, когда есть асинхронный, который проще в разы. Особенно если контроллеры на одной частоте работают. И на малых скоростях кварцы тоже не нужны.
0
swk
0 / 0 / 0
Регистрация: 22.10.2015
28.10.2012, 13:53 34
Цитата Сообщение от VyvotzorD
USORT сложнее чем UART. Зачем синхронный протокол юзать, когда есть асинхронный, который проще в разы. Особенно если контроллеры на одной частоте работают.
Ну, тут речь не шла именно о синхронной работе. Просто это название периферийного модуля в даташитах. Если поддерживает синхронный режим - то USORT, если нет - то UART.
В средних семействах PIC - обычно USORT, поэтому я так по привычке везде обзываю, хотя в средних AVR - чаще UART. А, например, в Меге 128 - USORT, да еще и пара...
И еще - в AVR надо некоторые флаги (например, занятость передатчика) вручную менять, если прерывания не используются, - они только в прерывании автоматом меняются, а в PIC - и без прерываний, при записи в буфер...

В общем, мелочей куча, но это имеет значение только для конкретных случаев и конкретного контроллера.

Когда же идет обсуждение концепции в целом, типа какой интерфейс выбрать, - SPI, I2C, или что другое, - то на этом этапе отдельные мелочи значения не имеют. Тем более, как обозвать - UART или USORT. Вcе равно по умолчанию ясно, что асинхронный режим используется.

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

И на малых скоростях кварцы тоже не нужны.
Уход частоты тактирования UART в зависимости от ухода частоты тактового генератора - не абсолютный, а относительный (в %), так что если отклонение будет больше, чем сможет обработать приемник (обычно примерно до 5%, а если уход частот приемника и передатчика в разные стороны - то до 2,5%), то по фигу, 9600 бод или 1200. Искажения от ухода скорости будут одинаковые. Ну, если пренебречь погрешностью установки частоты делителем, из за дискретности его значений. Обычно она не очень велика (у меня с кварцами 4 или 16 МГц на 9600 бод - 0,16%).
0
_moysi
0 / 0 / 0
Регистрация: 19.11.2010
Сообщений: 790
28.10.2012, 23:25 35
1. Убедиться, что никак нельзя запихнуть всё в один микросхем.
2. На одну и ту же линию I2C вешается параллельно любое (разумное) количество абонентов. Добавлять, убирать как угодно. Тестировать в частности.

Пример например: Apple iPhone внутри = набор отдельных функциональных блоков, соединённых между собой...

управление различными (примитивными) периферийными устройствами
Особенно если они уже продаются, уже готовые и уже с интерфейсом... а хотелось-то онани творчества!

Через полгода захотелось просто добавить внешнюю еепромину для хранения многонастроек - вот и отбился "гемор с изучением I2C".
0
swk
0 / 0 / 0
Регистрация: 22.10.2015
29.10.2012, 01:25 36
Цитата Сообщение от _moysi
На одну и ту же линию I2C вешается параллельно любое (разумное) количество абонентов. Добавлять, убирать как угодно. Тестировать в частности.
Пример например: Apple iPhone внутри = набор отдельных функциональных блоков, соединённых между собой...
Через полгода захотелось просто добавить внешнюю еепромину для хранения многонастроек - вот и отбился "гемор с изучением I2C".
I2C - хорош, когда работаете на контроллере мастером. Тогда - все довольно просто. (Хотя - посложнее все же чем UART).

А вот вы попробуйте поработать на контроллере слэвом, или в мультимастерной сети...

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

А с EEPROM, часами, и прочими аппаратно реализованными устройствами - конечно, все просто.
0
_moysi
0 / 0 / 0
Регистрация: 19.11.2010
Сообщений: 790
29.10.2012, 02:40 37
И с этого момента понимание, что опять и снова банально: решается задача от имеющегося готового инструмента/средства/методики к пониманию исходной цели и что вообще кому зачем было нужно. В которых случаях чаще ход мысли начинается даже не с конца, а откуда-то из середины... чего-то.
А применительно к интернетам - начинается даже не с инструмента/средства/методики, а с более или менее случайно выбранного заголовка. То есть с произвольного, чисто условного набора слов.
Осложняется ситуация тем, что участники процесса решают не поставленную задачу (потому что её формулировке ещё только предстоит сформироваться в процессе) или хотя бы одну на всех - а решает каждый задачу какую-то свою собственную, причём тоже без формулировки. И далее рекурсивно... потоки сознания на какую-то такую вообще примерно тему с употреблением заданных выражений.

В некоторых их (интернетах) популярен текст с названием что-то типа "гайка М3 и ТЗ на разработку", как вариант (в запущенных случаях) выражение "сферический конь в вакууме". О чём это я...

Задача устройства - управление различными (примитивными) периферийными устройствами через драйверы.
От Слейв-а требуется выполнять: вкл./выкл., хардварный ШИМ, обрабатывать сенсоры.
а). датчик опрашивается периодически, если не нужна "мгновенность" реакции на (датчик температуры, кнопка);
б). с датчика персональная линия IRQ к главному, если (радиомодуль, Н.Ё.Х.);
в). исполнительное устройство оно и есть.

Процитированное - общими чертами описание задачи, в котором лишнее зачёркнуто.
Исходное "связать 2 AVR-ки, по классической схеме Master -> Slave" - предложение о чём-нибудь таком вообще поговорить либо написать, чтобы... ну например показать уровень знаний с целью получения оценки (в зачётку).
"Как подружить AVR+AVR?" - условный идентификатор темы на форуме, чтобы отличать её от других тем. Набор символов. Желательно, но не обязательно иметь его уникальным.

(Попробовал работать слейвом, изделие поделка дышит и шевелится в соответствии с документацией на протокол и собственным алгоритмом, хотя и не сказать чтоб часто пользуюсь соответствующей частью её функционала. Поводов для восторга не вижу, собрался заморочился сделал.
То ли пинов не хватало на главной микросхеме, то ли второго уарта, и/или с соображений "чтоб поточнее/понезависимее временные интервалы"... то есть по-хорошему это не нужно было выносить в отдельный модуль, а нужно было выбрать чуть более другой главный и единственный микросхем. Хотя складские-логистические соображения тоже фактор, не расширять номенклатуру...
Так и получился костыль, точнее навеска на готовую конструкцию, чтоб не менять её.)
0
PRS
0 / 0 / 0
Регистрация: 12.07.2011
Сообщений: 3
29.10.2012, 10:50 38
Цитата Сообщение от SWK
Я тоже был о I2C восторженного мнения, пока не попробовал сделать на нем межконтроллерный обмен. Слишком большая загрузка у слэва...
Так вы же делали софтварный слейв вроде? А тут он аппаратный.
0
swk
0 / 0 / 0
Регистрация: 22.10.2015
29.10.2012, 11:32 39
Цитата Сообщение от PRS
Цитата Сообщение от SWK
Я тоже был о I2C восторженного мнения, пока не попробовал сделать на нем межконтроллерный обмен. Слишком большая загрузка у слэва...
Так вы же делали софтварный слейв вроде? А тут он аппаратный.
Аппаратный (по крайней мере, так в даташите написано)...
Вот только за время одного сеанса надо слэву столько телодвижений сделать, реагируя на кучу событий, что начинаешь сомневаться в его "аппаратной поддержке"...

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

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

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

В то же время, когда работаете на контроллере мастером I2C, а слэв чисто аппаратный - например, DS1307, AT24C512, и им подобные, - никаких особых проблем. Хоть, конечно, и надо делать всякие повторные старты, стоп, и прочее.
0
std
0 / 0 / 0
Регистрация: 06.06.2011
Сообщений: 19
02.11.2012, 08:33 40
народ, а если слейвов много, то можно ли параллельно соединить RX у всех и на TX мастера? действующие лица - атмеги328 из ардуины. планируется слать в сериал байт с номером микрухи, потом данные. или лучше для каждой сделать SoftwareSerial и на каждый слейв иметь свой экземпляр его класса? или лучше spi/y2s, если там уж есть аппаратный? если spi или y2s, то буду благодарен за пример кода, как делать слейвы из МК ардуины.

скорость надо максимум 9600, реально около 4800.
0
02.11.2012, 08:33
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
02.11.2012, 08:33

Анализ стека AVR / AVR stack analysis
Привет! Уперся я в стек, и решил понять что почем. Нашел вот такой вот скриптик:...

AVR Atmega324PU не прошивается AVR ISP Mk2
Добрый день. На плату впаян данный микроконтроллер в корпусе tqfp. При подключении программатора...

AVR Studio 6 и AVR Toolchain вопросы!
Всем доброго времени суток. Решил я написать софтинку в новой студии от Атмела AVR Studyo 6. Все...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
40
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Рейтинг@Mail.ru