Как связать несколько AVR общей шиной (попроще)?

Byte

Привет всем котам и кошкам )))
Я с мелко-контроллерами начал работать недавно, по этому опыта оч. мало.
Есть необходимости связать несколько (возможно разных) AVR'ок общей шиной для обмена данными. Высокая скорость не нужна. Скорее всего будет 1 главный, который будет опрашивать ведомых (штуки 4-5).
Пишу на CodeVisionAVR. Пробовал написать драйвер для TWI (I2C) по даташиту и Atmel'овским аппноутам, передаёт вроде нормально, а принимать не хочет...
Думаю может заюзать 1-wire, но в CVAVR реализован только MASTER, а нужен ещё и SLAVE.
Что посоветуете, господа коты? Мучать дальше TWI (с ним уже весь мозг наизнанку), пробовать писать свой драйвер для 1-wire, или есть ещё варианты?
Может кто уже реализовал что-то подобное для CVAVR - поделитесь плиз...
Или мне выложить свои наработки по TWI - может найдёте в чём косяк?
Заранее спасибо! Мяу!

chief

а чем вас УАРТ не устраивает. Один передает остальные принимают. остальные передают один принимает. Для определения адресанта можно соорудить простую адресацию

Aheir

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

tych

UART можно соединить одним сигнальным проводом, а протокол советую: wake ридико ли - google.com

Byte

Я думал про UART (USART), в принципе должен подойти...
Думаю у пакета должно быть 2 байта заголовка: от кого, кому, комманда (чтение, запись, системные комманды), размер пакета данных. На каждый из 4х составляющих по 4 бита, итого 2 байта. Получается, что на шине может висеть до 16 устройств, размер пакета может быть до 16 байт, а также может быть до 16 комманд включая чтение и запись данных. Другие комманды нужны потому, что не всегда мне нужно что-то передать, часть бывает нужно именно сделать что-либо конкретное, а для этого достаточно такой комманды.
Тоесть когда срабатывает прерывание, все читают 2 байта, если биты размера больше нуля, то читают остальную часть пакета, и освобождают шину.
Одновременный старт исключается, т.к. на шине может быть только 1 мастер.
Tx мастера будет подсоединен к Rx всех слейвов, а Tx всех слейвов к Rx мастера.
По идее должно работать.

Byte

Такой странный глюк: соединил 2 одинаковых, одинаково настроенных МК mega8 по УСАРТ. На одном отправляю байт - другой принимает. А когда отправляю следующий - не принимает. В буфере походу остается первый, а новый не принимается. Тоесть по сути принимает только 1 байт, а больше не хочет. Зато если 1й МК отправил, 2й принял, а потом 2й отправил, а 1й принял - дальше связь идёт нормально. Тоесть если посылать туда-сюда, то отправляет и принимает нормально, а если только в 1 сторону - принимает только 1й байт.
ЗЫ: пишу в CodeVisionAVR, проверял в Porteus. Соединял двумя проводами (Tx в Rx и Rx в Tx соответственно). Пользовался стандартными функциями putchar и getchar, которые сгенерировал мастер начального кода в CodeVisionAVR.
Тоесть если например в 1 МК написать код
putchar('a');
putchar('b');
а во второй написать
lcd_putchar(getchar());
lcd_putchar(getchar());
то 'a' на дисплее появится, а 'b' - нет
А если написать в 1 например
putchar('a');
getchar();
putchar('b');
getchar();
итд..., а во втором
lcd_putchar(getchar());
putchar('1');
lcd_putchar(getchar());
putchar('2');
итд... то будет нормально принимать и отправлять сколько угодно...
Может я просто чё-то недопонял? Почему так происходит?

tych

Наверно буфер для приема надо делать как в задаче 5 под кнопкой "www".

И конечно архив с проектом прикладывать к вопросу. Можно на slil.ru класть.

Mozart

изобретатели велосипеда... разберитесь с и2с... и память будете прикручивать и датчики есть с таким интерфейсом.... и АЦП... правда медленно... но зато с прерываниями можно работать... и пр...

ИМХО: быстрее разберётесь чем напишите свой интерфейс...

Byte

В чём глюк я отловил: при приеме срабатывает ошибка Data OverRun, про которую в даташите я ничё не понял... Что это за ошибка и почему она происходит?

2 tych: что вы имеете в виду "буфер как в задаче 5"? Я вообще по этому курсу начинал "понимать" МК... Задачу 5 я разобрал, единственное отличие - буфер задан оч. большого размера. Я пробовал ставить буфер 100 - не помогло.
Может я что-то пропустил?

2 Mozart: с удовольствием не изобретал-бы, еслиб и2с у меня заработал. Я столько с ним про... ну в общем прозанимался, что можно было не только велосипед изобрести, но и наладить его производство по всему миру... А в данном конкретном случае никаких спец датчиков и прочих девайсов мне не потребуется.

Mozart

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

Byte

2 Mozart: и и2с тоже доделаю, когда руки до него дойдут. Промучался я с ним наверно часов 20, может и не много, но и время у меня не безгранично... Сейчас у меня нормально работает передача по УСАРТ, за исключением одной выше описаной ошибки.

Mozart

ну 20 часов это нормально... мало конечно)) шучу...
может быть лучше спросить про и2с?? и схему по которой вы подключали и2с показать?
и сам код конечно хотелось бы увидеть, который вы написали для и2с... тогда можно смотреть...
может не идти передача по и2с из-за превышения допустимой ёмкости

The number of devices that can be connected to the bus is only limited by the bus capacitance limit of 400 pF and the 7-bit Slave address space.

moLCHec

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

Mozart

собенно в промышленных сетях где между собой аппаратура общается

не CAN разве используется в пром сетях? кажется это будет по надёжнее...
I2C - сам по себе медленный интерфейс... да не глюкавый он... нормальный он...

К тому же у Евстифеева описан режим UART с адресаецией как в I2C, он мегами поддерживается.

ну понятно... и как быстро это всё работает??

Byte

Да ладно вам спорить... Лучше скажите по какой причине на приемнике USART может ошибка DOR (Data OverRun) срабатывать, если из буфера регулярно вычерпываю (переполнений не бывает)?

Mozart

сли из буфера регулярно вычерпываю (переполнений не бывает)?

спросил как отрезал... сейчас посмотрим...

This bit is set if a Data OverRun condition is detected. A Data OverRun occurs when the receive buffer is full (two characters), it is a new character waiting in the receive Shift Register, and a new start bit is detected. This bit is valid until the receive buffer (UDR) is read. Always set this bit to zero when writing to UCSRA.

вопрос номер один: вы читаете из приёмника по прерыванию?
вопрос номер два: вы получаете данные и сразу обрабатываете? или записываете в какой-то промежуточный буффер?

Byte

2 Mozart:
по прерыванию у меня из приемника все складывается в большой буфер (так сгенерил мастер начального кода в CVAVR). А уже из него я при необходимости забираю данные процедурой getchar (которая тоже сгенерирована мастером). Так вот если проверять бит DOR - он после первого приема данных всегда срабатывает. Если проверку DOR убрать - всё нормально работает, передает, принимает итд... Вообще без проблем. Меня оно не сильно напрягает, просто интересно почему так происходит?
Если нужны куски кода - выложу.

Mozart

да взглянуть хотелось бы... на код...

Прошу прощения, вклинюсь в сообщение ради целостности картины Ниже цитатой - сообщение smbd в другой. очень похожей теме, которую было решено объединить с этой Aheir

smbd писал(а):Всем доброго времени суток!

Осваиваю потихоньку атмеловские МК, зачитываюсь всякой документацией. Но вот, казалось бы, доков много, но большое их разнообразие только запутывает.
Хотел бы прояснить свое сознание по поводу способов коммуникации, доступной для МК. Я в курсе, что можно изобрести новый велосипед самому, но мне пока интересны уже изобретеные велики (т.е. те способы коммуникации, которые в МК реализованы "железно", а не "софтверно").
Углубляясь в доки, получаю кучу аббревиатур и названий. Где-то UART, где-то - USART, SPI, USI, TWI, I2C. По последним двум вроде все понятно, но первые четыре вносят путаницу.
Как я понимаю, UART-USART - это "железки" (это одно и то же?), а SPI и USI - интерфейсы (протоколы), т.е. правила передачи, которые поддерживаются UART/USART-ом, так?
А что из этого можно применить, дабы связать несколько МК (в пределе до 1024 и больше, среди них как tiny2313, так и 8515, 8535, mega16) шиной и чтобы можно было через max232 подключить все это к ком-порту ПК и на нем принимать данные?
В аппноутах нашел №307, который вроде расписывает порядок работы с UART, только пример там на C. А нет ли где по другим ссылкам примерно того же, только с примером на асме?

Заранее всем спасибо!

Mozart

ничего не понял... много букв... столько не знаю... в чём вопрос??
USART - universal synchronous/asynchronous receiver transmitter
UART - universal asynchronous receiver transmitter
TWI - two wire interface = I2C (чтобы соблюсти "лицензию" или как она там называется забыл...)
SPI - serial peripheral interface
USI - universal serial interface

smbd

Я так понимаю, UART/USART - аппаратные железки, а остальное - интерфейсы/протоколы, т.е. формальные правила передачи (ну и способы организации шины)?
Ну и, собсно, старые вопросы: что из этого можно применить, дабы связать несколько МК (в пределе до 1024 и больше, среди них как tiny2313, так и 8515, 8535, mega16) шиной и через max232 подключить все это к ком-порту ПК и на нем принимать/передавать данные?

В аппноутах нашел №307, который вроде расписывает порядок работы с UART, только пример там на C. А нет ли где по другим ссылкам примерно того же, только с примером на асме?