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

Привет, All !

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

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... ДЕКАH. РОЖДЕHHЫЙ ЧТОБЫ ХОРОШО ПИТАТЬСЯ.

Reply to
Nickita A Startcev
Loading thread data ...

Nickita A Startcev пишет: NA> Привет, All !

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

NA> . С уважением, Hикита.

RS485 + Modbus RTU

Reply to
Rifkat Abdulin
*** Ответ на письмо из carbonArea (carbonArea).

Привет, Rifkat !

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

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

RA> RS485 + Modbus RTU

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

. С уважением, Hикита. ... Up, Down, Strange, Charmed, Beauty, Truth... хорошая была трава

Reply to
Nickita A Startcev

Пpивет, Nickita.

Вот что Nickita A Startcev wrote to All:

NS> Какие есть пpостые последовательные интеpфейсы?

UART.

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

UART -> RS485.

--Michael G. Belousoff-- Yekaterinburg city mickbell(dog)mail(dot)ru

formatting link
... ==== Пpоблемy надо pешать до того, как она появится. ====

Reply to
Michael Belousoff

RA>> RS485 + Modbus RTU

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

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

Reply to
Rifkat Abdulin

Привет!

"Nickita A Startcev"

задавать/отслеживать

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

220/380 - без гальваноразвяки ты огребёшься глюков по полной программе. Каково расстояние?

Есть три варианта. 1-wire, RS-485 и CAN. 1-wire медленный и абсолютно не защищён от помех. У RS-485 требуется протокол с арбитражем, чтобы переключать режим трансивера RS-485 приём/передача и избегать коллизий на шине. CAN в этом смысле интереснее, поскольку у него нет такой заморочки - он представляет собой своего рода дифференциальный аналог открытого коллектора. Более того, если ещё и протокол CAN взять (есть мелкопроцессоры со встроенным CAN), то ещё и аппаратный контроль доставки получишь. Хорошая штучка.

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

С уважением,

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

Reply to
Vitaly Nasennik
*** Ответ на письмо из carbonArea (carbonArea).

Привет, Rifkat !

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

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

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

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

. С уважением, Hикита. ... Копыта очень стройные и добрая душа

Reply to
Nickita A Startcev

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

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

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

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

Reply to
Rifkat Abdulin
*** Ответ на письмо из carbonArea (carbonArea).

Привет, Vitaly !

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

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

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

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

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

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

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

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

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

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

Reply to
Nickita A Startcev

Привет!

"Nickita A Startcev"

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

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

С уважением,

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

Reply to
Vitaly Nasennik

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

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

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

Reply to
Rifkat Abdulin
*** Ответ на письмо из 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 (Русскязычное ругательство о популярной музыке)

Reply to
Nickita A Startcev

Здравствуйте, Уважаемый Nickita!

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

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

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

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

й
Reply to
Olga Nonova

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

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

Reply to
Kirill Frolov

Если прибор -- это не железнодорожный вагон или автомобиль -- то всё перечисленное здесь вообще бред. И про гальваническую развязку в т.ч. Питание, конечно, раздельное ("цифровое" и на двигатели).

Reply to
Kirill Frolov
*** Ответ на письмо из carbonArea (carbonArea).

Привет, snipped-for-privacy@fk0.pp.ru !

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

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

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

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

. С уважением, Hикита. ... Hикого скромнее нет наашего Хасана..

Reply to
Nickita A Startcev


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

formatting link

Reply to
Dmitry Orlov

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

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

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

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

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

I2C - много писали про его гемморойность в программной реализации (тайминг и пр.). Попробуйте. Проще и быстрее UART в виде 485го

Reply to
Rifkat Abdulin

Привет Nickita!

27 Dec 06 16:18, Nickita A Startcev писал snipped-for-privacy@fk0.pp.ru:

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

KF>> Если упирается в скорость, то SPI.

NS> (недостаток СПИ - куча линий чип_селект.)

Можно устройства включать в кольцо, то есть вход от предыдущего, выход - к следующему. Тогда для SPI достаточно одного провода на всех ("начало посылки"), а для UART вообще ничего не надо.

У нас таким образом к одному устройству модули расширения подключаются: каждый может соединяться с двумя другими, а UART задействован только один.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Если долго думать одни и те же мысли, они становятся грязными.

Reply to
Alex Mogilnikov

Пpивет, Nickita.

Вот что Nickita A Startcev wrote to snipped-for-privacy@fk0.pp.ru:

NS> выйдет. (недостаток СПИ - кyча линий чип_селект.)

А если маненько подyмать и отказаться от чип селекта в пользy некоего пpотокольчика повеpх SPI, с адpесацией слэйвов, а? ;-)

--Michael G. Belousoff-- Yekaterinburg city mickbell(dog)mail(dot)ru

formatting link
... ==== Пpоблемy надо pешать до того, как она появится. ====

Reply to
Michael Belousoff

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.