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

Пpивет, Michael!

*** 10 Jan 07 00:08, Michael Zaichenko wrote to Dmitry Orlov:

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

MZ> Вот, вытащить плату из объекта, воткнуть ее в стенд...

Сделай кнопку, вводящую устройство в режим конфигурирования. Жалко кнопку - поставь джампер. Или разрезную или перекусываемую перемычку.

с уважением Владислав

Reply to
Vladislav Baliasov
Loading thread data ...

Hi Vladislav,

Wed Jan 10 2007 00:16, Vladislav Baliasov wrote to Michael Zaichenko:

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

MZ>> Вот, вытащить плату из объекта, воткнуть ее в стенд...

VB> Сделай кнопку, вводящую устройство в режим конфигурирования. Жалко кнопку VB> - поставь джампер. Или разрезную или перекусываемую перемычку. Конфигурационные режимы у слейвов не удобно. В эксплуатации слейв может находится в десятках метров от хоста. И в неудобном для троганья месте. Заковыреный в герметичную коробку, а коробка в шкафу из нержака. ...

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

Тоесть можно взять два готовых изделия и поменять хосты местами - жить будут.

WBR, Michael.

Reply to
Michael Zaichenko

Привет, Kirill !

09 Jan 07 , 07:53 Kirill Frolov писал к Nickita A Startcev:

KF> Ещё ужаснее. Можно просто предусмотреть "железные" адреса задаваемые KF> разводкой трёх-четырёх ножек на печатной плате. Для чего длинный tiny KF> и предлагается.

нафига? может еще и удвоить вес платы поставив на нее линейку дип-переглючателей?

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... измена - это... ну... паpоль pутовый на институтской боpде вывесить...

Reply to
Nickita A Startcev

Привет, Olga !

09 Jan 07 , 13:45 Olga Nonova писал к Nickita A Startcev:

ON>>> ... таймером в 256-бит никакой коррекции ухода на 10% частоты не ON>>> произвести.

NAS>> Таймер на 256 бит - это пять.

ON> Зря я потратила на Вас время. Hе в коня корм.

логично. Ведь я не конь.

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... Обкурившийся сфинкс, забывший правильный ответ на собственную загадку

Reply to
Nickita A Startcev

Привет, Andrey !

09 Jan 07 , 19:11 Andrey Bivshih писал к Olga Nonova:

AB> А если в сети несколько _полностью идентичных_ девайсов ? Как они AB> определят, кого именно конфигурят в данный момент ?

в первый раз втыкать/включать по одному, как это делают, например, с промышленными АДАМами/HУДАМами, прописывать адрес.

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... мастер Йода, мастер Хлора, мастер Фтора, мастер Брома - галогенмастера

Reply to
Nickita A Startcev

Привет, Michael !

10 Jan 07 , 00:08 Michael Zaichenko писал к Dmitry Orlov:

AB>>> они определят, кого именно конфигурят в данный момент ? DO>> А это можно делать обеспечив физически наличие только одного DO>> устройства в сети. MZ> Вот, вытащить плату из объекта, воткнуть ее в стенд...

купил плату, воткнул в стенд, проверил, заодно и адрес прописал.

MZ> И чем это лучше, чем прощелкать заранее перемычками на MZ> платах и не страдать фигней?

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

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... Hа следующий день сошли на берег, где и передрались меж собой.

Reply to
Nickita A Startcev

Hi Nickita,

Wed Jan 10 2007 02:48, Nickita A Startcev wrote to Michael Zaichenko:

AB>>>> они определят, кого именно конфигурят в данный момент ? DO>>> А это можно делать обеспечив физически наличие только одного DO>>> устройства в сети. MZ>> Вот, вытащить плату из объекта, воткнуть ее в стенд... NAS> купил плату, воткнул в стенд, проверил, заодно и адрес прописал. Покупающий _у_ _нас_ плату не имеет стендов. Покупает _провереную_ и _настроенную_ плату. Чтобы воткнуть и работало. Максимум - три микрика пощелкать, чтобы было также как на прошлой плате. Что внутри у платы и как она устроена заказчику начихать, ему надо чтобы оборудование работало без сбоев.

MZ>> И чем это лучше, чем прощелкать заранее перемычками на MZ>> платах и не страдать фигней?

NAS> и чем это лучше, чем воткнув доп. устройство задать ему и логический NAS> адрес и логическую привязку к нужной затычке? Чтобы понять лучше это или хуже, надо знать где это будет применятся. У тебя единственный экземпляр и для себя. Откуда же мне знать какие ты задал критерии?

Hапример зачем вообще ставить пачку мелких камней если это одно неделимое изделие? Может вместо 10 тинек влепить один многоногий арм и пусть рулит кучей движков. И места меньше и дешевле.

WBR, Michael.

Reply to
Michael Zaichenko


Hello, Michael Zaichenko! You wrote in conference fido7.ru.embedded to Vladislav Baliasov on Wed, 10 Jan 2007 00:47:04

+0300:

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

MZ>>> Вот, вытащить плату из объекта, воткнуть ее в стенд...

VB>> Сделай кнопку, вводящую устройство в режим конфигурирования. VB>> Жалко кнопку - поставь джампер. Или разрезную или VB>> перекусываемую перемычку.

MZ> Конфигурационные режимы у слейвов не удобно. В эксплуатации MZ> слейв может находится в десятках метров от хоста. И в

Да хоть в километрах. Адрес-то не при эксплуатации задается.

MZ> неудобном для троганья месте.

А как же перемычки и дип-свичи?

MZ> Заковыреный в герметичную коробку, а коробка в шкафу из MZ> нержака.

И там свичами щелкать?

MZ> У меня уже давно все сделано. Для каждого вида изделия, на

Не у тебя одного.

dima

formatting link

Reply to
Dmitry Orlov


Hello, Michael Zaichenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 10 Jan 2007 00:08:56

+0300:

ON>>>> Утилита настройки специальная прилагается. Стенда никакого ON>>>> не надо, прошивка адреса производится прямо в составе сети.

AB>>> А если в сети несколько _полностью идентичных_ девайсов ? AB>>> Как

DO>> Hеужели про сериализацию при программировании тут никто не DO>> слышал? Hет никаких проблем обеспечить уникальность еще на DO>> этапе изготовления.

MZ> Это несколько не то.

Это именно то. Устройства перестают быть полностью идентичными.

AB>>> они определят, кого именно конфигурят в данный момент ?

DO>> А это можно делать обеспечив физически наличие только одного DO>> устройства в сети.

MZ> Вот, вытащить плату из объекта, воткнуть ее в стенд...

Не надо всю плату, достаточно пары-тройки проводов. И "стенд" - громко сказано, это может быть просто разъем в комп, ну максимум с микросхемкой какой внутри.

ON>>>> разве кого-то напрягает автоматическая процедура ON>>>> установки?

AB>>> Какая-же она автоматическая ? Приучил Билли всех к

DO>> DHCP называется, и делает это не только Билли.

MZ> Хорошо, берем некий объект с десятком приводов, втыкаем MZ> десяток одинаковых слейвов, отличаемых только МАС адресом.

MZ> Подколючаем обьект к хосту. MZ> Hет проблем, все платы получат адреса, настройки и тд. MZ> Теперь скажи, откуда хост узнает что плата с адресом 1 MZ> управляет пневмоцилиндром Х, а плата с адресом 2 управляет MZ> элекроприводом З?

Это зависит от решаемых задач.

MZ> Ведь придется ручками размепить на хосте соответсвие адресов и MZ> механизмов.

А это так или иначе прийдется.

MZ> Потратив время на выяснение - чей это адрес и где живет его MZ> владелец? MZ> И чем это лучше, чем прощелкать заранее перемычками на платах MZ> и не страдать фигней?

Отсутствием перемычек и ножек для них.

MZ> Hе говоря уже про извращение - IP over I2C ради получения MZ> DHCP. Hа копеечном восминогом контроллере :)

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

[Sorry, skipped]

MZ> Сколько было танцев с бубном...

А уж сколько их с перемычками бывает...

dima

formatting link

Reply to
Dmitry Orlov

Привет!

Sat Jan 06 2007 15:37, Nickita A Startcev wrote to Jurgis Armanavichius:

JA>> Hаиболее очевидный и простой вариант - любая микросхема памяти из JA>> ряда 24CXX на 256 байт. Один в один :-) Суть: передается Старт, байт JA>> адресации (с битом WR), адрес ячейки (т.е. нужный номер регистра), JA>> байт данных (это на запись), Стоп. NAS> то есть, пишем адрес, пишем байт(ы) по этому адресу. NAS> итого, грубо, передается 3 байта.

Первый байт - адрес устройства, с которым мы собрались работать (а также команда: запись/считывание). Далее - грубо говоря, данные. Однако, если нам нужно записать в конкретный регистр (ячейку) данного устройства, то подразумевается, что вторым байтом идет адрес этого регистра (ячейки). Это как раз отлично просматривается в микросхемах памяти. Более того, если ячеек больше 256, то старшие биты номера ячейки тоже передаются (например, если память на 32 или 64 КБ, то для начального адреса ячейки используется уже два байта: второй и третий). Есть и более экзотические случаи, когда старшие биты задвигаются в первый байт (т.е. в байт адреса устройства).

JA>> Hа считывание: Старт, байт JA>> адресации (с битом WR), адрес ячейки, далее повторный Старт, байт JA>> адресации (уже с битом RD), считывается байт данных, Стоп. NAS> то есть, пишем адрес, повторно стартуем, повторно указываем NAS> адрес_устройства, читаем байт(ы) по этому адресу. NAS> Итого, грубо, передается 4 байта.

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

NAS> Итого, при любом обмене первая команда запись адреса, а вторая NAS> действия по этому адресу.

Именно так. Т.е. <адрес устройства с битом RD/WR>, <один или несколько байт адреса ячейки>, <данные>. При этом считается, что считывание всегда производится начиная с _текущего_ адреса ячейки, поэтому для цикла считывания адрес ячейки не передается (если нужно прочитать не из текущего адреса ячейки, то этот адрес задается в предшествующем ему цикле записи, который выполняется не полностью, а прерывается повторным стартом).

NAS> Это стандартизированное поведение? в спеке на и2ц о нем сказано?

Hу так почитай :-) Я дал тебе ссылку на документ. Кроме того, очень хорошо вся эта кухня расписана в I2C-памятях от Atmel.

NAS> Аффтары и2ц не додумались до того, что у одного устройства может NAS> быть более одного 8битного регистра?

Hу так это же и есть в микросхемах памяти! AT24C01 - 128 ячеек (как бы регистров), AT24C02 - 256 ячеек и т.д.

Если рассудить логически, то небольшая избыточность в этой шине нужна для работы с несколькими устройствами, поэтому первым байтом и идет байт адреса устройства. Если регистр в устройстве один - то не надо дополнительного байта номера регистра, т.е. адрес устройства и далее непосредственно данные. А если регистров несколько, то вполне логично передать еще и номер того регистра (вторым байтом после адреса девайса), с которым мы будем взаимодействовать. IMHO, а как иначе?

Юргис

Reply to
Jurgis Armanavichius

Привет!

Sat Jan 06 2007 15:37, Nickita A Startcev wrote to Jurgis Armanavichius:

Да, еще. Я как-то сразу не сообразил. Если у тебя устройство простое, которому достаточно лишь нескольких номеров внутренних регистров, а самих устройств не очень много, то можно биты адресации регистров поместить прямо в поле адреса устройства. Т.е. например, имеется до 32-х устройств, для адресации которых достаточно 5-и бит. Тогда из имеющихся 7 бит адреса устройства можно два младших выделить на номер регистра в данном устройстве. 32 устройства по 4 регистра в каждом. Или 64 устройства по 2 регистра (например, команда/статус и байт данных). Тогда любой цикл обмена (не важно, запись или чтение) будет занимать всего два байта (адрес устройства, объединенный с N регистра и сами данные).

В этом случае одно физическое утройство занимает на шине пул в 2-4 логических адреса:

<устройство N1, регистр N0> - первое устройство <устройство N1, регистр N1> <устройство N1, регистр N2> <устройство N1, регистр N3> <устройство N2, регистр N0> - второе устройство <устройство N2, регистр N1>

и т.д.

Юргис

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

Привет, Michael !

10 Jan 07 , 04:35 Michael Zaichenko писал к Nickita A Startcev:

AB>>>>> они определят, кого именно конфигурят в данный момент ? DO>>>> А это можно делать обеспечив физически наличие только одного DO>>>> устройства в сети. MZ>>> Вот, вытащить плату из объекта, воткнуть ее в стенд... NAS>> купил плату, воткнул в стенд, проверил, заодно и адрес прописал. MZ> Покупающий _у_ _нас_ плату не имеет стендов. Покупает _провереную_ и MZ> _настроенную_ плату. Чтобы воткнуть и работало. Максимум - три микрика MZ> пощелкать, чтобы было также как на прошлой плате. Что внутри у платы и MZ> как она устроена заказчику начихать, ему надо чтобы оборудование MZ> работало без сбоев.

АДАМы и HУДАМы тоже с предустановленными адресами продаете? :)

MZ> Hапример зачем вообще ставить пачку мелких камней если это MZ> одно неделимое изделие?

а) это конструктор б) вязанку проводов через всякие гибкие соединения вести не стоит.

MZ> Может вместо 10 тинек влепить один многоногий арм и пусть рулит кучей MZ> движков. И места меньше и дешевле.

многоногий - это штучная плата, которая получится далеко не с первого раза. (не из-за проблем с травлением, а из-за ошибок в принципиальной схеме и/или недопонимания наводок и/или недопонимания того, как именно будет глючить механика/оптика)

. С уважением, Hикита. ... С сегодняшнего дня этот вопpос y нас - наболевший.

Reply to
Nickita A Startcev

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

Tue Jan 09 2007 18:12, Dmitry Orlov wrote to Michael Belousoff:

MB>> И ничего avrы не yбогие. Hе все ж они tiny...

DO> Hу тогда получается, что убогие те, кто не умеет их применять и DO> выдумывает для оправдания этого неумения всякие страшилки.

"Страшилки" про стабильность опорной частоты для uart выдумывать не надо. Они очень подробно изложены в руководствах по применению асинхронной передач по последовательному каналу. Другое дело, что эти "страшилки" достаточно формальны и описывают самый плохой случай, когда приемник и передатчик ничем не связаны, кроме TxD и RxD и подвержены произвольному дрейфу опорных частот. В этом случае "страшилки" становятся реальностью.

Однако, если приемник и передатчик находятся в одном корпусе, и тем более запитаны от одного источника, то вполне реально ожидать, что RC-осциляторы в них синхронизируются автоматически, через импульсные помехи по питанию. Для этого, конечно, нужно предварительно выровнять битами калибровки номиналы частот у всех кристаллов. Синхронизация наступит на фронтах. И температурный дрейф у всех tiny в одном корпусе следует ожидать одинаковый, т.е. рассинхронизации не произойдет. Только этим и можно обьяснить, прочему у Вас работает асинхронная передача через uart с опорой на встроенные RC-осциляторы. Все дело в едином корпусе и питании.

Кстати, эту догадку очень легко проверить- 1.берем два tiny, -2.запитываем от одного источника, -3. в каждый прошиваем программу меандра на какой-нибудь ножке, -4. битами калибровки выравниваем у обоих номиналы частоты RC-осцилятора и -5.смотрим двухлучевым осцилографом оба меандра. Должны увидеть снхронные колебания.

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

Reply to
Olga Nonova

Привет Dmitry!

09 Янв 07 года (а было тогда 22:13) Dmitry Orlov в своем письме к Andrey Bivshih писал:

DO> Hеужели про сериализацию при программировании тут никто не слышал? Hет DO> никаких проблем обеспечить уникальность еще на этапе изготовления.

Об этом уже говорили, как о лишней операции, которую можно исключить.

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

Если в конечном устройстве несколько датчиков, тогда как минимум это устройство придется несколько раз включат/выключать при сборке.

AB>> автоматическим программам. DO> И правильно сделал, так и надо.

Hи кто не спорит, плохо только что этот навязчивый сервис ни всегда отключается. И некоторым спецам не нравится, когда с ними обращаются, как с домохозяйками. Кроме того, Билли ведь это сделал не от любви к ближнему, а просто чтоб бобла срубить.

С уважением, Andrey 10 Янв 07 года

formatting link
E-Mail:a_biv<саба>list,ru Jabber:Andrey_B@jabber,ru |СQ:226793191

Reply to
Andrey Bivshih

Привет Olga!

10 Янв 07 года (а было тогда 13:12) Olga Nonova в своем письме к Dmitry Orlov писал:

ON> RC-осциляторы в них синхронизируются автоматически, через импульсные ON> помехи по питанию.

Вот думаю, в каком контексте вышеотквоченое имеет смысл ? :-) И не могу придумать.

С уважением, Andrey 10 Янв 07 года

formatting link
E-Mail:a_biv<саба>list,ru Jabber:Andrey_B@jabber,ru |СQ:226793191

Reply to
Andrey Bivshih

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

Hello, Andrey Bivshih! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 10 Jan 2007 19:37:22

+0300:

DO>> Hеужели про сериализацию при программировании тут никто не DO>> слышал? Hет никаких проблем обеспечить уникальность еще на DO>> этапе изготовления.

AB> Об этом уже говорили, как о лишней операции, которую можно AB> исключить.

Это не операция, а одноразовая правка конфига программатора. И что-то я не видел, чтобы кроме меня кто-то об этом говорил.

AB>>> они определят, кого именно конфигурят в данный момент ?

DO>> А это можно делать обеспечив физически наличие только одного DO>> устройства в сети.

AB> Если в конечном устройстве несколько датчиков, тогда как AB> минимум это устройство придется несколько раз AB> включат/выключать при сборке.

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

AB>>> автоматическим программам. DO>> И правильно сделал, так и надо.

AB> Hи кто не спорит, плохо только что этот навязчивый сервис ни AB> всегда отключается.

Как правило, все отключается (если железо это позволяет). Не всегда очевидным для пользователя образом.

AB> И некоторым спецам не нравится, когда с ними обращаются, как с домохозяйками.

Спецов заставляют пользоваться биллиным продуктом?

AB> Кроме того, Билли ведь это сделал не от любви к ближнему, а просто чтоб бобла AB> срубить.

Это нормально. Не знаю как ты, а я на работу хожу с той же самой целью, хотя и не столь успешно, как Билли. Если бы не необходимость зарабатывать деньги, я бы возможно, и посвятил свободное ото сна время страшному полюбу к ближнему.

dima

formatting link

Reply to
Dmitry Orlov

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

Hello, Olga Nonova! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 10 Jan 2007 10:12:05

+0000 (UTC):

MB>>> И ничего avrы не yбогие. Hе все ж они tiny...

DO>> Hу тогда получается, что убогие те, кто не умеет их применять DO>> и выдумывает для оправдания этого неумения всякие страшилки.

ON> "Страшилки" про стабильность опорной частоты для uart ON> выдумывать не надо. Они очень подробно изложены в руководствах ON> по применению асинхронной передач по последовательному каналу.

Зачем нужны руководства, если это примитивным расчетом определяется?

ON> Однако, если приемник и передатчик находятся в одном корпусе, ON> и тем более запитаны от одного источника, то вполне реально ON> ожидать, что RC-осциляторы в них синхронизируются ON> автоматически, через импульсные помехи по питанию. Для этого,

Питание надо нормально разводить, чтобы неизвестно что с неизвестно чем не синхронизировалось.

ON> конечно, нужно предварительно выровнять битами калибровки ON> номиналы частот у всех кристаллов. Синхронизация наступит на ON> фронтах. И температурный дрейф у всех tiny в одном корпусе ON> следует ожидать одинаковый, т.е. ON> рассинхронизации не произойдет. Только этим и можно обьяснить, ON> прочему у Вас работает асинхронная передача через uart с ON> опорой на встроенные RC-осциляторы. ON> Все дело в едином корпусе и питании.

С какого бодуна ваш коллектив взял, что у меня что-то подобное так работает? Я, для начала, применяю PIC'и у которых и стабильности встроенных RC осцилляторов хватает и OSCCAL на ходу можно менять с соответствующим результатом. И устройства у меня часто даже от разных сетей питаются и отстоят друг от друга на десятки, а то и сотни метров, а вовсе не находятся на одной плате.

ON> Кстати, эту догадку очень легко проверить- 1.берем два tiny, ON> -2.запитываем от одного источника, -3. в каждый прошиваем ON> программу меандра на какой-нибудь ножке, -4. битами калибровки ON> выравниваем у обоих номиналы частоты ON> RC-осцилятора и -5.смотрим двухлучевым осцилографом оба ON> меандра. Должны увидеть снхронные колебания.

Вот соберите этот макет и покажите осциллограммы, чем языками тут без толку молотить.

dima

formatting link

Reply to
Dmitry Orlov

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

Thu Jan 11 2007 03:01, Dmitry Orlov wrote to Olga Nonova:

ON>> "Страшилки" про стабильность опорной частоты для uart ON>> выдумывать не надо. Они очень подробно изложены в руководствах ON>> по применению асинхронной передач по последовательному каналу.

DO> Зачем нужны руководства, если это примитивным расчетом определяется?

Иными словами, Вы себя считаете уменее официальных мануалов?

ON>> Однако, если приемник и передатчик находятся в одном корпусе, ON>> и тем более запитаны от одного источника, то вполне реально ON>> ожидать, что RC-осциляторы в них синхронизируются ON>> автоматически, через импульсные помехи по питанию. Для этого,

DO> Питание надо нормально разводить, чтобы неизвестно что с неизвестно чем DO> не синхронизировалось.

Увы, будут одинаковые генераторы синхронизироваться в одном конструктиве, какие бы умные руководящие указания Вы здесь не давали. И только это спасает Ваше решение делать опорой для uart встроенные в кристалл RC-осциляторы.

ON>> ..... Только этим и можно обьяснить, ON>> прочему у Вас работает асинхронная передача через uart с ON>> опорой на встроенные RC-осциляторы. ON>> Все дело в едином корпусе и питании.

DO> С какого бодуна ваш коллектив взял, что у меня что-то подобное так DO> работает?

Hаш здоровый коллектив вывел сие из заявленного Вами приема гонять информацию в полудуплексе ассинхронными передачами по ОДНОМУ проводу. Вспоминаете?

DO> Я, для начала, применяю PIC'и у которых и стабильности DO> встроенных RC осцилляторов хватает и OSCCAL на ходу можно менять с DO> соответствующим результатом. И устройства у меня часто даже от разных DO> сетей питаются и отстоят друг от друга на десятки, а то и сотни метров, а DO> вовсе не находятся на одной плате.

Hа "сотни метров" по одному проводу и раздельным питанием?

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

Reply to
Olga Nonova

Hello, Olga!

ON>>> Однако, если приемник и передатчик находятся в одном корпусе,

Ключевое слово - "если" :)

ON>>> и тем более запитаны от одного источника,

"если" - запитаны от одного источника.

Не слишком ли много "предположений" ? :)

ON>>> то вполне реально ожидать, что RC-осциляторы в них синхронизируются ON>>> автоматически, через импульсные помехи по питанию. Для этого,

DO>> Питание надо нормально разводить, чтобы неизвестно что с неизвестно DO>> чем не синхронизировалось.

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

Зачем столько слов? Приведите осцилограммы синхронизации генераторов по питанию. (в предположении, что блоки питания и трассировку вы делать уже научились).

ON> И только это спасает Ваше решение делать опорой для uart встроенные в ON> кристалл RC-осциляторы.

ON>>> ..... Только этим и можно обьяснить, ON>>> прочему у Вас работает асинхронная передача через uart с ON>>> опорой на встроенные RC-осциляторы.

Вообще, все зависит от конкретного RC-генератора, и его зависимости от температуры. К примеру, у pic16f819 частота от температуры плывет сильно, для uart'a - непригодно, а у pic16f88 - "все стоит как у волка на морозе".

ON>>> Все дело в едином корпусе и питании.

ON> Hаш здоровый коллектив вывел сие из заявленного Вами приема гонять ON> информацию в полудуплексе ассинхронными передачами по ОДНОМУ проводу. ON> Вспоминаете?

Именно так оно и работает, но кто вам, "коллектифф", сказал что оно стоит в одном корпусе и от одного питания работает?! Оно вообще оптронами развязано, так что - "синхронизацию пичками в питании" вы там долго искать будете.....

ON> Hа "сотни метров" по одному проводу и раздельным питанием?

Именно так.

Один мастер, тысяча слейвов, на расстоянии сотни метров. Линия от самого UART'a в каждом слейве оптронами отвязана, и ни с чем в слейве кроме оптронной части вобще не соединятеся. Каждый слейв разумеется, питается от своего внутреннего источника, и тысяча слейвов могут сидеть (и сидят) на разных фазах.

With best regards, Alexander Torres. 2:461/28, E-mail: snipped-for-privacy@yahoo.com [а ночью мы снова, уйдем эскадроном..]

formatting link

Reply to
Alexander Torres


Hello, Olga Nonova! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 11 Jan 2007 10:46:55

+0000 (UTC):

ON>>> "Страшилки" про стабильность опорной частоты для uart ON>>> выдумывать не надо. Они очень подробно изложены в ON>>> руководствах по применению асинхронной передач по ON>>> последовательному каналу.

DO>> Зачем нужны руководства, если это примитивным расчетом DO>> определяется?

ON> Иными словами, Вы себя считаете уменее официальных мануалов?

Чтобы 2 умножить на 2 вы всем коллективом в мануалы лезете?

ON>>> Однако, если приемник и передатчик находятся в одном ON>>> корпусе, и тем более запитаны от одного источника, то вполне ON>>> реально ожидать, что RC-осциляторы в них синхронизируются ON>>> автоматически, через импульсные помехи по питанию. Для ON>>> этого,

DO>> Питание надо нормально разводить, чтобы неизвестно что с DO>> неизвестно чем не синхронизировалось.

ON> Увы, будут одинаковые генераторы синхронизироваться в одном ON> конструктиве, какие бы умные руководящие указания Вы здесь не ON> давали. И только это спасает ON> Ваше решение делать опорой для uart встроенные в кристалл ON> RC-осциляторы.

Бред. Генераторы нормальные надо применять. Точности и стабильности микрочиповских хватает даже без подстройки.

ON>>> ..... Только этим и можно обьяснить, прочему у Вас работает ON>>> асинхронная передача через uart с опорой на встроенные ON>>> RC-осциляторы. Все дело в едином корпусе и питании.

DO>> С какого бодуна ваш коллектив взял, что у меня что-то DO>> подобное так работает?

ON> Hаш здоровый коллектив вывел сие из заявленного Вами приема ON> гонять информацию в полудуплексе ассинхронными передачами по ON> ОДНОМУ проводу. Вспоминаете?

Ну да, общий обычно не считают. И что? Из чего следует, что у них общее питание? Конкретно у меня вообще линия со всех сторон гальванически отвязана оптронами.

DO>> Я, для начала, применяю PIC'и у которых и стабильности DO>> встроенных RC осцилляторов хватает и OSCCAL на ходу можно DO>> менять с соответствующим результатом. И устройства у меня DO>> часто даже от разных сетей питаются и отстоят друг от друга DO>> на десятки, а то и сотни метров, а вовсе не находятся на DO>> одной плате.

ON> Hа "сотни метров" по одному проводу и раздельным питанием?

Конкретно на сотни метров - по двум, на десятки вполне можно один на землю бросить. Хотя при замкнутом на землю одном проводе оно и на сотни работало.

dima

formatting link

Reply to
Dmitry Orlov

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.