простые последовательные - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Re: простые последовательные
*** Ответ на письмо из carbonArea (carbonArea).

Привет, Vitaly !


 26 Dec 06 , 14:47  Vitaly Nasennik писал к Nickita A Startcev:

 >> Какие есть простые последовательные интерфейсы?
 >> Есть десяток-полтора мелких двигателей, хочется каждому
 VN> задавать/отслеживать
 >> положение/скорость. и2ц вроде бы сложноват программно, СПИ требует
 >> сложной коммутации, что еще остается?

 VN> "Мелкие" - это какие? Точнее, от скольки вольт питаются.

5 вольт, 200 ма, например.

 VN> Каково расстояние?

в пределах метра.

 VN> коллизий на шине. CAN в этом смысле интереснее, поскольку у него нет
 VN> такой заморочки - он представляет собой своего рода дифференциальный
 VN> аналог открытого коллектора. Более того, если ещё и протокол CAN взять
 VN> (есть мелкопроцессоры со встроенным CAN), то ещё и аппаратный контроль
 VN> доставки получишь. Хорошая штучка.

А чем от и2ц отличается?
(в плане сложности/юзабельности)

 VN> Кстати, мож кто знает, в соневской Aibo каким образом связь с
 VN> двигателями реализована?

Hе знаю, подозреваю rs485 или как у серво от hitecrcd.com - ШИМом по третьему
проводу.

.                                                С уважением, Hикита.
... "Hравственность по версии ВОЗ"

Re: простые последовательные
Привет!

"Nickita A Startcev"

VN> аналог открытого коллектора. Более того, если ещё и протокол CAN взять
VN> (есть мелкопроцессоры со встроенным CAN), то ещё и аппаратный контроль
VN> доставки получишь. Хорошая штучка.
NAS> А чем от и2ц отличается?
NAS> (в плане сложности/юзабельности)

На мой вкус - примерно одинаково.

С уважением,

Виталий Насенник



Re: простые последовательные
VN>> (есть мелкопроцессоры со встроенным CAN), то ещё и аппаратный
VN>> контроль
VN>> доставки получишь. Хорошая штучка.
VN> NAS> А чем от и2ц отличается?
VN> NAS> (в плане сложности/юзабельности)

VN> На мой вкус - примерно одинаково.

CAN - все же скорее тот же RS485 в многомастерном режиме и в аппаратной
поддержке функций адресов, CRC и пр. Ну и возможность работы при отрыве
одной из линий.
I2C - это межмикросхемный интерфейс в пределах одной платы. Выносить
его меж блоками - ловить все помехи, тем более от движков.

--
Rifkat < Team /Grave\ >
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Re: простые последовательные
*** Ответ на письмо из carbonArea (carbonArea).

Привет, Rifkat !


 26 Dec 06 , 17:10  Rifkat Abdulin писал к Nickita A Startcev:

 NA>>>> rs485 потребует согласованности частот (кварц в каждый
 NA>>>> приборчик) rs485 потребует внешнего max485 (или как его там)
 NA>>>> хочется обоих этих удорожаний избежать, тем более что 'в
 NA>>>> пределах
 RA>>> одного
 NA>>>> прибора' rs485 вроде как избыточно.

 RA>>> "Вам шашечки или ехать?".
 RA>>> Кварц стоит копейки (ну - пару рублей - особо прецизионный не
 RA>>> нужен).
 RA>>> Если есть желание таскать напрямую ножки контроллера, а не
 RA>>> ставить драйвовую микруху - флаг в руки! ;-) По хорошему - еще бы
 RA>>> и гальванически все развязать

 NA>> Практически в пределах одного ящика с общим питанием и еще и
 NA>> гальванически
 NA>> отвязывать?

 RA> А что значит общее питание?

от одного и того же аккумулятора.
Возможно одним преобразователем, возможно двумя.

 RA> Цепей двигателя и контроллерной части? По
 RA> хорошему - тем более разделить питание не помешало бы

Токи маленькие, двигатели игрушечные. Что на практике даст такое разделение?
(двигатели, прикидочно, 5в 200ма)

.                                                С уважением, Hикита.
... DCLXVI (Русскязычное ругательство о популярной музыке)

простые последовательные
Здравствуйте, Уважаемый Nickita!

Wed Dec 27 2006 11:21, Nickita A Startcev wrote to Rifkat Abdulin:

 NAS> Токи маленькие, двигатели игрушечные. Что на практике даст такое
 NAS> разделение? (двигатели, прикидочно, 5в 200ма)

В Вашем варианте я бы делала на I2C. Для одного управляющего master и многих
моторчиков как slave  -это самое простое и гибкое в доработках.

Всего Вам Хорошего
Ольга
  

й


Re: простые последовательные


Hello, Olga Nonova!
You wrote in conference fido7.ru.embedded to Nickita A Startcev on Wed, 27 Dec
2006 10:45:20
+0000 (UTC):

 NAS>> Токи маленькие, двигатели игрушечные. Что на практике даст
 NAS>> такое разделение? (двигатели, прикидочно, 5в 200ма)

 ON> В Вашем варианте я бы делала на I2C. Для одного управляющего
 ON> master и многих моторчиков как slave  -это самое простое и
 ON> гибкое в доработках.

UART - куда более распространенная периферия, чем i2c-slave и программно
реализуется
проще.

dima
http://dorlov.no-ip.com



Re: простые последовательные
Здравствуйте, Уважаемый Dmitry!

Wed Dec 27 2006 16:29, Dmitry Orlov wrote to Olga Nonova:

 ON>> В Вашем варианте я бы делала на I2C. Для одного управляющего
 ON>> master и многих моторчиков как slave  -это самое простое и
 ON>> гибкое в доработках.

 DO> UART - куда более распространенная периферия, чем i2c-slave и программно
 DO> реализуется проще.

Для связи узлов _внутри _одного _корпуса самое простое- это SPI или I2C. Они,
собственно, для этого и были созданы. Вот, если выходить наружу ящика, то Вы
правы.

Всего Вам Хорошего
Ольга


Re: простые последовательные

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Olga Nonova!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 28 Dec
2006 06:26:04 +0000 (UTC):

 ON>>> В Вашем варианте я бы делала на I2C. Для одного управляющего
 ON>>> master и многих моторчиков как slave  -это самое простое и гибкое
 ON>>> в доработках.

 DO>> UART - куда более распространенная периферия, чем i2c-slave и
 DO>> программно реализуется проще.

 ON> Для связи узлов _внутри _одного _корпуса самое простое- это SPI или
 ON> I2C. Они, собственно, для этого и были созданы. Вот, если выходить
 ON> наружу ящика, то Вы правы.


Это так, когда iic slave или spi реализованы аппаратно. UART в мелких
контроллерах встречается чаще, чем iic, а когда его нет, реализуется проще.

dima
http://www.dorlov.no-ip.com
http://dimorlus.dynalias.com



Re: простые последовательные

Quoted text here. Click to load it

Какова схема подключения? ОК? Диодное или? Или просто на резисторах? Есть ли
какой нибудь
серьезный опыт по такому использованию УАРТ как внутренней шины?

Re: простые последовательные
Здравствуйте, Уважаемый Dmitry!

Thu Dec 28 2006 11:20, Dmitry Orlov wrote to Olga Nonova:


 ON>> Для связи узлов _внутри _одного _корпуса самое простое- это SPI или
 ON>> I2C. Они, собственно, для этого и были созданы. Вот, если выходить
 ON>> наружу ящика, то Вы правы.

 DO> Это так, когда iic slave или spi реализованы аппаратно. UART в мелких
 DO> контроллерах встречается чаще, чем iic, а когда его нет, реализуется
 DO> проще.

Если нет аппаратных i2c но есть uart, то Вы правы. Однако, если нет и
аппаратного uart, то из трех вариантов программной реализации: i2c,spi,uart
-,мне представляется, меньше сил и времени уйдет на spi. Да и стабильность с
воспроизводимостью окажется выше.

Всего Вам Хорошего
Ольга


Re: простые последовательные
Привет, Rifkat !


 27 Dec 06 , 09:20  Rifkat Abdulin писал к Vitaly Nasennik:

RA> CAN - все же скорее тот же RS485 в многомастерном режиме и в
RA> аппаратной поддержке функций адресов, CRC и пр. Hу и возможность
RA> работы при отрыве одной из линий. I2C - это межмикросхемный интерфейс
RA> в пределах одной платы. Выносить его меж блоками - ловить все помехи,
RA> тем более от движков.

полметра э.. витой четверки проводов - это 'выносить меж блоками', или таки 'в
пределах одного блока'?

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... купается с круглыми утками

Re: простые последовательные
Привет, Kirill !


 27 Dec 06 , 13:45  Kirill Frolov писал к Nickita A Startcev:

Quoted text here. Click to load it

KF>   А uart рассчитан на соединения точка-точка.

KF>   Если у MCU есть набортные SPI или I2C (вариант: SMBUS) их и стоит
KF> использовать. Если упирается в скорость, то SPI.

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

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... Главное в жизни - эмоциональная окраска, все остальное - лишь средство.

Re: простые последовательные

Quoted text here. Click to load it

  Теперь умножай на 2 и бери attiny2313. Где, вроде как, всё нужное есть.
И ещё 4 ШИМ канала...

Ибо:

  * 6 ножек и из них 4 на моторчик -- хреновато как-то;

  * никаким вменяемым C-компилятором оно не поддерживается.


Quoted text here. Click to load it

  Мой опыт подсказывает, что изобретение самодельных протоколов приводит
к трудно излечимому геморрою (в силу времени проведённому на стуле, в
отладке).
  


Re: простые последовательные
Привет, Rifkat !


 27 Dec 06 , 19:15  Rifkat Abdulin писал к Nickita A Startcev:

RA> I2C - много писали про его гемморойность в программной реализации
RA> (тайминг и пр.). Попробуйте.

с таймингом (если я ничего не путаю) там все не так уж и плохо, а запутанность
скорее на логическом уровне.

RA> Проще и быстрее UART в виде 485го

второй чип, 4кондера, удвоение-упятерение цены простейшего слейва. Это уже
крайний случай.

кстати, подумалось: если взять 'аппаратный уровень' как у и2ц, те же самые
'start' и 'stop' условия, тот же способ ередачи отдельного бита и поправить все
остальное - то вроде как вполне нормально получается, особенно в моем
ограниченном случае:
- мастер один, вся инициатива исходит от мастера
- клок генерирует мастер, данные генерирует передатчик
- формат посылки, например,
<start><addr8><r/w><reg8><err><data8><err><data8><err>...<stop>

то есть, мастер формирует старт, выдает адрес устройства, выдает бит
чтение/Запись, выдает номер регистра в слейве, выдает такт синхронизации,
убеждается что слейв передал неошибочный бит, выдает такты синхронизации для
приема или передачи N байт, выдает состояние <stop>

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... А как выглядит щенок сфинкса?

Re: простые последовательные
Привет, Dmitry !


 27 Dec 06 , 21:15  Dmitry Orlov писал к Nickita A Startcev:

NA>> В (самых) дешевых тиньках ничего нет, нужно эмулировать
NA>> программно и/или аппаратно. Так что, наверное, нечто и2ц образное
NA>> выйдет. (недостаток СПИ - куча линий чип_селект.)

DO> Реализовать программный iic можно фактически только используя
DO> прерывание по изменению порта, а это часто вступает в конфликт с
DO> другим использованием выводов этого порта.

лишние прерывания можно 'игнорировать' если хранить предыдущее и смотреть
текущее состояние порта.

DO> Адресация же устройств с
DO> таким образом написанным iic ничем не проще чем при помощи UART,

можно взять честный и2ц аппаратный уровень и переделать 'под свои задачи'
программный.

DO> только с UART все гибче и аппаратно он много где реализован.

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

DO> Сделать
DO> же на его базе шину - и вовсе тривиально, причем достаточно одного (не
DO> считая общего) провода.

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

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... выкинуть ящик с трубадурами

Re: простые последовательные

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Nickita A Startcev!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 28 Dec
2006 09:58:16 +0300:


 NA>>> В (самых) дешевых тиньках ничего нет, нужно эмулировать программно
 NA>>> и/или аппаратно. Так что, наверное, нечто и2ц образное выйдет.
 NA>>> (недостаток СПИ - куча линий чип_селект.)

 DO>> Реализовать программный iic можно фактически только используя
 DO>> прерывание по изменению порта, а это часто вступает в конфликт с
 DO>> другим использованием выводов этого порта.

 NA> лишние прерывания можно 'игнорировать' если хранить предыдущее и
 NA> смотреть текущее состояние порта.

Можно, я не говорю, что нельзя. Я говорю, что это сложней. А используя
внешнее прерывание и таймер программный uart можно еще более быстрый
сделать, чем используя только таймер. Только программный uart мы тут летом
обсосали и он уже реализован, а iic (причем не стандартный, а только похожий
на него) еще делать надо...

 DO>> Адресация же устройств с таким образом написанным iic ничем не
 DO>> проще чем при помощи UART,

 NA> можно взять честный и2ц аппаратный уровень и переделать 'под свои
 NA> задачи' программный.

Зачем?

 DO>> только с UART все гибче и аппаратно он много где реализован.

 NA> В самых дешевых тиньках его нет. все равно что-то свое руками
 NA> программировать, а если программировать - то можно и 'конькретно под
 NA> задачу' протокол извратить.

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

 DO>> Сделать же на его базе шину - и вовсе тривиально, причем достаточно
 DO>> одного (не считая общего) провода.

 NA> собрать в общую кучу прием и передачу, а разделять программно?

При программной реализации ничего никуда собирать не надо, нужна одна ножка
и внешний pull-up, лучше в виде источника тока, но можно и просто резистором
(одним или несколькими). Хотя если связь внутри одной pcb, то можно и
встроенным pull-up'ом обойтись. Передача и прием естественно разнесены по
времени, ну так они и в iic разнесены. Причем эта разнесенность еще и
упрощает конечный автомат программного uart'а и избавляет от необходимости
свое же эхо фильтровать, как в случае аппаратного uart'а. В качестве
бесплатного бонуса - возможность легко подключить готовый host pc вместо
центрального контроллера для отладки и/или расширения функциональности.

dima
http://www.dorlov.no-ip.com
http://dimorlus.dynalias.com



Re: простые последовательные

Quoted text here. Click to load it

  У host PC как раз проблема с временем. Особенно, если оно через
USB...  Вобщем, там напрашивается достаточно сложный арбитраж, что
сомнительно, чтоб так весело лезло в 512 слов кода attiny12...
Я потому и говорю -- проще взять с аппаратным интерфейсом (attiny2313,
attiny26). Имеется ввиду USI. А на нём хоть I2C, хоть SPI.
RS232 там есть, но выглядит не привлекательно...


простые последовательные
Здравствуйте, Уважаемый Nickita!

Thu Dec 28 2006 09:58, Nickita A Startcev wrote to Dmitry Orlov:

 NAS> В самых дешевых тиньках его нет. все равно что-то свое руками
 NAS> программировать, а если программировать - то можно и 'конькретно под
 NAS> задачу' протокол извратить.

Hу, раз готовы на подвиги, то я поделюсь с Вами приемом, когда можно
совместить простоту программной реализации spi с малым числом проводов, как у
i2c. Предупреждаю- аппаратный SPI использовать не получится, придется master
делать самому тоже программно.

Первая переделка SPI-master заключается в том, что передача и прием данных
будет идти по одному проводу, с разделением по времени. DATA ножка у master
должна быть двунаправленой. Линии CLK остается как была, без изменений.

Вторая переделка касается - убрать линию CS вообще. Hачало и конец пакета
данных определять тем же приемом, как в MODBUS- т.е. по таймауту, например,
тишина на линии CLK-ов в течении N msec. Так slave-ы будут переходить в режим
ожидания нового пакета, в котором первым байтом идет адрес плюс бит  WR/RD
(как в i2с). Один из моторчиков должен понять, что обращаются к нему, а
остальные тупо игнорировать активность на линии вплоть до timeout тишины.

Всего Вам Хорошего
Ольга


Re: простые последовательные
*** Ответ на письмо из carbonArea (carbonArea).

Привет, Rifkat !


 27 Dec 06 , 19:15  Rifkat Abdulin писал к Nickita A Startcev:

 RA> "вы просто не умеете их готовить".

;)

 RA> Можно и без чип-селекта работать.
 RA> Основный недостаток - малейший сбой на 1 бит синхронизации - по петле
 RA> ползет кака. А чтобы слейву передать мастеру, что он принял каку -
 RA> нужно принимать следующую посылку от мастера. Кака, в-общем.

Вот-вот.  Кака.

 RA> I2C - много писали про его гемморойность в программной реализации
 RA> (тайминг и пр.). Попробуйте.

 RA> Проще и быстрее UART в виде 485го

не хочу вторую микруху в тупые оконечные устройства ставить.

.                                                С уважением, Hикита.
... waitfor afterdark (c) QNX

Re: простые последовательные
Hello Olga Nonova!

 DO>> UART - куда более распространенная периферия, чем i2c-slave и
 DO>> программно реализуется проще.

 ON> Для связи узлов _внутри _одного _корпуса самое простое- это SPI или I2C.
 ON> Они, собственно, для этого и были созданы. Вот, если выходить наружу
 ON> ящика, то Вы правы.

UART *уже* есть ...

PS "HЕ ИЗМЫШЛЯЙТЕ ЛИШHИХ СУЩHОСТЕЙ !" (С)


Site Timeline