net

ну да ну да ТВЧ с оператором ну ни видно там ничего - либо камеры должны через 2 метра стоять и при чем тут can? я человеку ответил что можно ожидать. вам просто чтото хочется сказать? у вас проблеммы? давайте поговорим - я вас слушаю :rolleyes: во первых 30 ом окажется + от линиии и пожалуйста приведите BER а не расплывайтесь общими фразами для can BER указан в стандарте не надо ничего рпридумывать

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

это не прокатывает - человек утверждает что когда трубка лежит - то интернета нет когда трубка поднята то все работает 1 однозначно емкость 2 маловероятно - на станции неправильно делается коммутация- вероятность приближается к нулю - но в нашем мире все возможно

да кто ж спорит что работает. конечно работает просто на его смену приходит более современный с лучшими свойствами он более технически сложный - но эта сложность упрятана в дешевый чип никто же не спорит о сложности vga карты вместо esc последовательностей ведь очевидно что сложность vga на порядки сложнее - но вся эта сложность скрыта в электронике и добавляет столько всяких вкусностей что никому в голову не придет это оспаривать хотя для простеньких мониторчиков все с точностью наоборот - но это все уходит в прошлое например сотовый телефон и современные коммуникаторы конечно сотовый имеет массу преимуществ - но они все теряются в невозможности получить другие функции и в современных "телефонах" функция поговорить уже и не самая главная да не вопрос 640*512 за 4-5 секунды получите (без сжатия просто тупо)

вы серьезно так думает? приведите пожалуйста рассчеты по BER когда и что будет работать - чтобы можно было увидеть это на цифрах для can вообще говоря есть даже эта величина в стандарте

поясните каким образом ? вы считает что can не обнаружит сбой чтоли? о чем вы говорите?

вообще говоря в CAN даже когда все на приеме то на импульсную помеху сопротивление 30 ом +сопротивление линии(чтото там)

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

+100500 наверняка конденсатор звонка шунтирует всю линию сплиттер у вас к телефону подключен или к модему? :smile3046:

can есть стандарт на 10 мегабит и при чем тут это? проще только потому что вы имеете набор для таких действий и это аргумент? у меня нет брелка чтобы куда то повесить мне его надо делать = поэтому это очень сложно - это довод? я бы тоже на 220 - исходя только из того что провода тянуть не нужно а может даже и безпроводку использовал с ретрансляторами по дому тут возможно несколько типовых решений и надо смотреть если это типа бизнес нужно иметь варианты решений чтобы можно было при различных условиях их применять однозначного решения тут нет если человек делает конкретно - то ему вообще, что ближе то и нужно ставить. выигрыш он только в своем понимании получит отвественных решений тут как то не наблюдается что касаемо отказа от гальваники это я считаю ошибочным. сказала монашка одевая пр...ив на свечку ж-) если же 485 vs CAN - в моем понимании тут и обсуждать нечего стоимость значения не имеет - а простота реализации на can все покрывает. если же собирать can на ла3 то конечно будет сложно. когда у вас все на одном кристалле то никакой сложности тут нет надежность и бытсродействие, дешевизна can уже доказана на автомобилях и обсуждать это не стоит вообще автомобили это самые сложные условия и стоимостные требования другое дело что и там конструктора дают маху (общение с audi, vw удивляет то как они делают - зато поле для ремонтников ;-) если же рассуждать о ножках микроконтроллера и тд и тп то это отдельная песня

на первое место поставил бы дорого сложность вещ растяжимая

1 вы же понимаете даже если у вас 1 мастер то он должен договориться со слейвом чтобы тот начал передаввать! а это очень большое время 2 еще раз доступ к передаче будет за одинаковое время если 485 мастер. передача в can займет больше времени если вы в 485 не о чем не заботитесь - если вы хотите надежность то разницы никакой нет если стартуете из одинаковых условий. а если вам приспичило чтото передать слейву когда он вам чтото передает? то все 485 в ауте !!! 3 получив тут же? это время огромное по сравнению с CAN который получает потдверждение в процессе передачи. единственное это подтверждение о том что сообщение ктото принял а не тот кто конретно был должен 10 мс вы с умма сошли - это быстродействие? !!! это тупые потери канала!!!! у меня такое ощущение что я рассказываю что волга впадает в каспийское море - а мне оппонент говорит что это не так видимо я не могу вам ничего объяснить. раз вы все читали о чем вы говорите??????

вы считаете проблеммой то что драйвера которые прилагаются к таким устройствам не имеют функционала COM порта? сделать это не проблемма - но все дело в том что при этом вы потеряете кучу вкусных плюшек поэтому такой огрызок и не делают - но его можно легко реализовать в этом случае CAN станет для вас ценным? смешно для справки advantech делает такой драйвер который полностью совместим и использует теже функции что и com порт выставление скорости и передачи пакета ну и в чем такая ценность сделать классы при заданных значениях по умолчанию это не проблемма

если отвечать по вашей логике то все совсем не так как вы думаете если стоит просто записать в порт то вы правы если цель переслать данные то все совем не так в 485 вам надо сначала получить доступ к шине и договориться со всеми остальными что вы сейчас будете чтото передавать по шине и это чтото будет занимать шину определенное число байт. что существенно медленнее чем это же самое делает в CAN чтобы послать в 485 вы записываете в порт - в can ровно точно также толкьо в порт можно записать сразу до 8 байт формально получается CAN проще - тут не надо ждать когда чтото отправится чтобы записать следующее, работая через прерывания в 485 вы съедаете ресурсы и тормозите очень сильно если вдруг возникнет более приоритетное прерывание и вы для того чтобы послать следующий байт потеряете кучу времени если вообще его получите теперь гарантирование отправления даже внутри одного микроконтроллера конкурирует по ID и вы всегда можете отправить высокоприоритетное сообщение прервав обмен(вклинившись между передачей пакетов) по шине - что 485 невозможно в принципе как то не вижу причин обсудать все это тут - если вы почитаете про can то все это становится совершенно очевидно и не требует никакого обсуждения а уж про синхронизацию - выполнять ее аппаратно в CAN или программно в 485 - я даже не знаю как такое обсуждать? если я вас не убедил - то извините вот если вы говорите о том что послать 1 байт и принять его в системе 1 мастер по 485 - то да это получится быстрее чем в CAN об этом даже и говорить не стоит 485 тут выше всяких похвал. вот только нельзя быть уверенным - 1 что ваш байт ктото принял 2 что ваш байт принят ровно таким каким вы его посылали не находите что это довольно призрачно ебыстродействие? но оно действительно для 485 будет быстрее еще такой момент - в CAN устройства фильтруют пакеты и это позволяет производить передачу на скоростях гораздо выше чем может обрабатывать устройство что я имею ввиду может быть очень быстрый процессор и куча дохлых процессоров и вот этот мощный может пересылать с высоким быстродействием пакеты, а дохлые возьмут только те пакеты которые им принадлежат в 485 все должны принимать все байты и это существенно ограничиваетскорость

просто не надо сравнивать теплое с мягким совместимость с ПК совершенно одинаковая - полно USB-CAN и просто CAN плат. то что они не привычные для обычных пользователей - тут я согласен скорсоть у 485 хуже чем у CAN изза переключения - если вы имеете ввиду дуплекс и точка точка то 485 быстрее и надо учесть что 485 всетаки более раннее произведение чем can и еще как бы 485 имеет мнимую простоту передачи на самом деле он гораздо сложнее так не умеет делать адреса и пакеты и подстройку скорости и целостность данных- откуда вытекает куча проблем которые многие не считают проблемами

не согласен - особенно когда про скорость передачи больших порций данных и детерменированного обмена видимо все кто делают автомобили сильно ошибаются выбрав can

ну значит уже склероз ;-(

надо почитать модель эберса молла из учебника по электроники и как чего в транзисторах работает всякие емкости и эффекты - если вы хотите про транзистор знать хилл он не про это написал(насколько мне память не изменяет)

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

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

вам лучше почитать учебник - тогда у вас получится нормальная картина - а вырванные куски вас только запутают

вам что надо таблицу заменить на функции? ну так метод наименьших квадратов вам в руки когда получили наименьшую ошибку та и функция

видимо стандарты просто так придумали и защиту всякую и тд и тп поставить то можно все что угодно - только потом замучаешься это менять непрерывно и еще вроде как can это логический протокол ;-) в автомобилях то условия идеальные не тебе влаги и соли не тебе искры и разрядов, не тебе скачков напряжения и как там can умудряется работать? вообще говоря can он по 3 проводам работает витая пара от ethernet пойдет, но и землю там не забутьте в этом кабеле выделить

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

я в шоке от таких утверждений даже ничего не могу сказать