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

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

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

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

RS485 + Modbus RTU

Привет, Rifkat !

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

RA> RS485 + Modbus RTU

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

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

П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

RA>> RS485 + Modbus RTU

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

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

Привет!

"Nickita A Startcev"

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

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

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

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

С уважением,

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

Привет, Rifkat !

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

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

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

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

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

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

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

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

Привет, Vitaly !

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

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

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

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

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

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

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

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

Привет!

"Nickita A Startcev"

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

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

С уважением,

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

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

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

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

Привет, Rifkat !

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 -это самое простое и гибкое в доработках.

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

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

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

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

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

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

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

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

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

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

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

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

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

dima

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

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

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

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

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

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

Привет Nickita!

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

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

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

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

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

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

П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