Побудова мікромережі на основі проводки 220В

Привіт народ!

Після тривалого мовчання появилось бажання продовжити «генерацію ідей» і, можливо, зайнятись реалізацією.

На цей раз трохи вбік від роботів (dou.ua/...​es/robotics-startup-idea) і ближче до «розумного будинку».

Власне мене зацікавив механізм побудови мікромережі використовуючи наявну електричну проводку.

Побудова безпровідної мережі розглядалася, але цей варіант поки що відкидається.

Можливі опції «Ethernet over Main Power Lines» або «CAN bus over Power Lines».

Думаю, що більш доцільніший 2-й варіант, так як прийдеться лише приєднати (наприклад через Ethernet трансформатор і фільтр) прийомо-передавач CAN вузла до лінії живлення 220В.

Як мінімум тре два вузли, один для пристрою (може бути і більше, теоретично всі однакові), інший для спряження з ПК або сервером (виглядатиме як USB або Ethernet адаптер).

Буду вдячний товариству за змістовні відгуки.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Коментар порушує правила спільноти і видалений модераторами.

поїхали далі.
Яакщо взяти ІС RS-485, і на вхід DE подавати несучу частоту а вхід D дані для передачі, то отримаєм простий модулятор.

Для прийому достатньо поставити випрямляч на діоді з RC ланкою після виходу R і буде простий демодулятор. А далі знову все як було, через трансфрматор (або через конденсатори) врізаємся в мережу живлення. Ну як рішення? Чекаю на критику.

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

Только помню что там точно было кодирование, КАМ — модуляция, преобразование ФУРЬЕ и исследование помехоусточивости)

Не хочется открывать новую тему, а те несколько человек, которые могут ответить, прочитают вопрос и тут.

Не подскажет ли кто-нибудь стандарты/рекомендации/rfc/etc. для реализации протокола CAN over Ethernet/IP/TCP/UDP дабы не ваять велосипед? Непродолжительный гуглинг результатов, к сожалению, не дал. Цель — CAN<->Ethernet network gateway.

Sorry, наверно неясно выразился. Протокол верхнего уровня для CAN уже выбран: en.wikipedia.org/...ki/CANaerospace. Необходимо инкапсулировать полный CAN фрейм, очевидно с timestamp, в TCP/UDP пакет и пробросить из CAN сети через Ethernet сеть на PC и обратно. В идеале компьютер должен быть полноценным утройством в CAN сетке, задача-минимум — наблюдатель.

Нет, стандарта на это нет, каждый делает как ему удобно. Один из заказчиков использовал TCP/IP to Virtual COM port софтинку (RFC 2217) и заворачивал данные из CAN в формат одной из софтинок, которые обеспечивали виртуальный COM-порт.

en.wikipedia.org/...port_redirector

Ясно, спасибо.

Кстати, немного не в тему, но интересно Ваше мнение. Вопрос стандартизации, есть ли отличия между 9-ти выводным разъемом MIL-C-24308 за 10 долларов и обычным DB-9M за 2 гривны? Т.е. если стандарт требует MIL-C-24308 а установлен китайский DB-9M, то, как я понимаю, устройство не соответствует стандарту?

Вопрос стандартизации, есть ли отличия между 9-ти выводным разъемом MIL-C-24308 за 10 долларов и обычным DB-9M за 2 гривны?

Да, отличия есть в материалах из которых изготовлен разъём (зашита от EMI), среде использования, температурный режим, etc.

Т.е. если стандарт требует MIL-C-24308 а установлен китайский DB-9M, то, как я понимаю, устройство не соответствует стандарту?

Я немного не понял, какому стандарту не соотвествтует? В любом случае, если установлен обычный коннектор, то устройство автоматически уже не может иметь никакого другого применения, кроме home or office usage. Т.е. ограничение на область применения задает самая слабая компонента устройства.

Ясно, спасибо. Сэкономить не получится. :)

Устройство должно соответствовать спецификации CANaerospace. Помимо формата сообщений она описывает диапазон напряжений питания, распиновку и тип разъемов и т.д.

Можу сказати, що перше це кліматика, тобто кетай за 2 грн призначений для офісних температур, і не пройде випробування в барокамері у автомотивному або в воєнному діапазоні темперетур та вологості та тиску.

а хіба нема живих адапторів тіпа як Ethernet — RS232 або USB — CAN

Ethernet — CAN?

Конечно есть, но:

1. Они дорогие — отваливать минимум $200 за такую железяку считаю нецелесообразным;

2. Зачем платить если можно сделать? Руки/голова вроде на месте + это хобби + себистоимость получится в пределах $60. Да и по работе сейчас портирую LwIP TCP/IP стек на железяку (позже возьмусь за UDP стек) так зачем информации в голове зря пропадать?

3. Есть надежда потом продать. :)

В голове кстати как раз крутится идея CAN Gateway с Ethernet/RS-232/USB.

В голове кстати как раз крутится идея CAN Gateway с Ethernet/RS-232/USB.

в мене давно крутиться, тільки для чого такий «монстр»?

це вже половина системи керування, а не перетворювач інтерфейсів

Да нет, это только малая часть проекта и по сути только для дебага...

протокол, що тобі треба. Погугли.

ну чому CANbus спитаєте, ну тому що фізика цієї шини на витій парі мені зрозуміла, а от як робить Езернет на замість двох пар на одній — не ясно, як він бореться з колізіями шини, завадами і вирішує проблему арбітража — не зрозуміло

IMHO надо плясать от какого-нибудь распространеного стандарта (DeviceNet, CANopen или другой протокол уровня L3 и выше) иначе эти несовместимые поделки никому не нужны. А там глядишь и L1/L2 подтянутся...

Про количество узлов не совсем понятно, зависит от топологии. Сопряжение с ПК — просто gateway (возможно даже transparent bridge между разными L2 уровнями).

Кстати зря “трохи вбік від роботів”, я пока пилю модули для мобильной платформы (язык не поворачивается называть что-то без мозгов роботом) на CAN Bus с CANaerospace протоколом верхнего уровня — должно получиться неплохо.

а лінк можна на «платформу»?
п.с.

Виявляється ще є куча живих «труъ» ембедеров

Она как бы не очень открытая. Вот ссылка на очень упрощенную hardware diagram (устаревшая версия).

img713.imageshack.us/...arearchitec.jpg

Повторите еще раз и помедленней. Вы, что хотите просто соединить выход приемо-передатчика CAN через ethernet тр-р к сети 220В???????? Я правильно понял?

Удачи, но сначала почитайте что представляет собой CAN на физическом уровне. Не работает CAN через трансформаторы, про 120Ом терминаторы на концах и пр. я вообще молчу.

Не работает CAN через трансформаторы,

А ти перевіряв?
Передача іде таким чином, що пocтійна складова відсутня, не більше шість 0ів або 1ць підряд.
стандарт просить 50..60 ом навантаження, і апаратний драйвер шини не бачить що там висить на дротах — резистор(и) чи котушка, чи дохлий пес.

він моніторить струм та різницю сигналів, щоб визначити стан лінії (домінантний біт чи па сивний чи КЗ/обрив).

п.с.

Езернет «стандарт » теж не передбачає 220в як PHY, чи не так?

А ти перевіряв?

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

Передача іде таким чином, що пocтійна складова відсутня, не більше шість 0ів або 1ць підряд.

Отсутствие постоянной составляющей гарантирует не количество 0 или 1 подряд а равенство количества 0 количеству 1. Как, например в, кодах манчестер.

стандарт просить 50..60 ом навантаження, і апаратний драйвер шини не бачить що там висить на дротах — резистор(и) чи котушка, чи дохлий пес.

Вы уверены? А скажите каким будет импедас линии на частотах порядка 10-100кГц при подключении в нее импульсного источника питания в момент зарядки конденсаторов(т.е. 100 раз в секунду)?

Езернет “стандарт ” теж не передбачає 220в як PHY, чи не так?

Нет, не предусматривает, причем без всяких кавычек.

И кстати почему-бы не использовать ZigBee? Дешево и сердито.

Нет не проверял, есть множество вещей которые я не проверял

Если речь идёт о возможности использования CAN по 220В, то можно я видел такие устройства.

Езернет «стандарт » теж не передбачає 220в як PHY, чи не так?

Нет, не предусматривает, причем без всяких кавычек.

ITU G.9972, расширение IEEE 802.3.

Если речь идёт о возможности использования CAN по 220В, то можно я видел такие устройства.

Вот так просто выход драйвера CAN через тр-р к 220? без адаптера? И кто эти устройства делал? И насколько надежно это работало?

ITU G.9972, расширение IEEE 802.3.

Не знал честно говоря, но опять же здесь идет речь о специально разработанной технологии.

PS вот нашел документ на тему CAN over power line www.isplc.org/...df/0629_001.pdf никаких выход драйвера через транс на 220.

вот нашел документ на тему CAN over power line

Тут кидається в очі, що використовується схема модуляції ASK (тіпа телеграф — морзянка: є несуча (домінантний біт), нема несучої (рецесивний)), тобто високочастотна несуча модулюється низькочастотним CAN.
Якщо ти знаєш, для брехунця існує так зване провідне мовлення, де передається три канали (один на на низькій частоті, інші 2 канали переносять спектр уверх). Щось подібне тут, тільки не для аналогового а для дискретного сигналу.
Тут постають питання,
1) CENELEC обмеження 148,5 КГц, ,які згадують автори і які вони відкидають, до чого воно взагалі?

2) чому ASK а не FSK або не PSK? — тобто тут ще можна для науки написати кучу актуальних статтей.

никаких выход драйвера через транс на 220.

модулятор — демодулятор намальовані блок схемами, а що в тих коробочках — питай у шановних авторів — професорів, і де там трансформатори.

Коментар порушує правила спільноти і видалений модераторами.

Тут кидається в очі, що використовується схема модуляції ASK (тіпа телеграф — морзянка: є несуча (домінантний біт), нема несучої (рецесивний)), тобто високочастотна несуча модулюється низькочастотним CAN.

Именно так. Это самый простой, самый древний и пожалуй самый не оптимальный способ модуляции цифровых сигналов.

1) CENELEC обмеження 148,5 КГц, ,які згадують автори і які вони відкидають, до чого воно взагалі?

Думаю ответ сокрыт в первом абзаце на странице 260. Если вам интересно на какие именно нормы они ссылаются — разбирайтесь.

2) чому ASK а не FSK або не PSK?

ASK манипуляция наиболее проста в реализации. Поэтому вопрос каких результатов можно добиться используя простейшую реализацию довольно интересен.

— тобто тут ще можна для науки написати кучу актуальних статтей

Можно.

модулятор — демодулятор намальовані блок схемами, а що в тих коробочках — питай у шановних авторів — професорів, і де там трансформатори.

Ога профессора они такие вруны. А тр-р там конечно стоит, куда-же без него, после модема :)

PS Вообще-то вопрос какую модуляцию использовать сугубо теоретический, главное знать что без нее не обойтись. С практической точки зрения все сводится к выбору подходящего PLC модема коих существует великое множество как в виде готовых устройств, так и в виде микросхем.

І ще там в статті два рішення, в одному як писав для 220В спектр переноситься на ВЧ, а другому, для автоматизації, де живлення передається по ліній 24, а CAN драйвера толерантні до нього, тому думаю, що там сигнали з прийомо-передавачів через конденсатор прямо валять на шину живлення.

CAN BUS DATA TRANSFORMER DR331
www.aconie.com/...ls.php?id=16338

як ти думаєш, яке його призначення?

Вы шутите??? Или действительно не понимаете???
Вводите в гуглях «DR331 pdf» первая же ссылка ведет вас к www.bourns.com/pdfs/dr331.pdf где на первой странице читаете читаете:
DR331 Series Surface Mount Data Line Chokes
Applications
■ For the suppression of EMI in data and signal lines, e.g. CAN Bus
Перевожу.
Применение
■ Для подавления электро-магнитных помех в линиях данных и сигнальных линиях, например для CAN шины.
Это ответ на вопрос «як ти думаєш, яке його призначення?»
Если, допустим, не знаете что такое «data line chokes» то спрашиваете у гугля «data line chokes application notes» первый же документ дает вам ответ на вопрос www.epcos.com/...PDF_General.pdf

Скажите ув HW(!!!)/SW Senior(!!!) Developer как вы вообще документацию ищите? Или вы детальки по прайсам подбираете? В общем нет слов...

китайці пишуть «трансформер», то мені пояснювати, що таке трансформер, чи на вікі послати?

Настоятельно рекомендовал бы вам, ув HW/SW Senior Developer не слушать неких абстрактных китайцев, но читать документацию фирмы производителя. Ссылка на которую вам была предоставлена. Это во-первых.
Как настоящему HW/SW Senior Developer-у вам должно быть понятно, что трансформаторы бывают разные. Вам же не придет в голову использовать обычный сетевой изолирующий тр-р вместо ethernet? Это во-вотрых.

И не стоит черпать свои познания исключительно из википедии. Это в третьих.

Вам рекомендую почитати шкільний підручник з рос. мови, та взнати, як пишеться звертання, і не лізти з дурними порадами, коли їх не просять.
Мета не взяти готове стандартне рішеня і зробити так як написав виробник обладнання, а спробувати зробити власне, перед тим проаналізувавши, що є в світі.
п.с.
щиро вдячний Вам за
www.isplc.org/...df/0629_001.pdf

побільше би конструктиву, поменше читання моралі.

п.п.с.

ще знайшов

www.softing.com/...vanchor=3010551

There are two possible methods how to transmit data signals on the power lines: the base band transmission and the modulation.

А це те саме, про що написано в статті.

Мдя... А вы на схемку над этой самой надписью посмотрели? Дроссели Lp на этой схеме видели? Как вы думаете зачем они нужны? Причем замете не только на источнике, но и на потребителе. А нужны они для решения вот-той самой проблемы с импульсными ИП, про которую вам уже говорилось, да и не только с импульсными, а и утюжками всякими. Это не говоря уж о том, что такие схемы обычно применяют в цепях постоянного тока.
А теперь покажите мастер класс сделайте расчет такой катушки для розетки в которую утюжёк включают.

И кстати про проблему с постоянной составляющей не забываем. Она тоже определенные ограничения накладывает.

я здався.

CAN овер 220В — це хвантастика

Еще один проект почил в бозе... Аминь.

да ладно,
має бути якась високк мета, яка рухає попри себе інші діла.
наприклад, що маю в результаті -
1) доробив і запустив другу плату LPT <-> MCP2515
тобто маю дома КАН мережу
2) протестував роботу її на езернет трансформаторах на 1МБіт/с
3) вирішив зробити прогрес USB <-> CAN
для цього дістав із загашників платку із FT2232, та присобачив до неї як в appnote 93LC46 (хоча в оригиналі мала бути 56та) та поганяв код
4) так як колись був код і dll для SPI через LPT на С# та просту прога для тестування LPT <-> MCP2515 (власне тре було запустити асинхронний двигун Altivar маючи опис CANopen функцій на нього), а зара ставити ВізуалСтудію влом, то приглядаюсь, а чи не написати чудо-лібу на QT (заодно освоївши його) для USB <-> CAN на базі пари FT2232D + MCP2515
Маючи перші враження, проаналізувати результат і спробувати понизити біт-рейт для CAN або/і подумати що можна зробити щоб врізатись у мережу 220В (ASK, FSK чи щось подібне).
п.с.
тут анонімні Петі Васічкіни сприймають процес дещо однобоко, не розуміючи, що постановка досить непростої задачі і спроба її вирішити дає кучу досвіда та наробок, які рано чи пізно (хоча би згідно принципу Парето) дають користь.

А так натякнути, що ти ідіот і в тебе нічого не вийде, бо ти, на його думку інфу береш із Вікі, то думаю, дай напишу «фсьо прапало», хай заспокоїться.

Хм... LPT... Хотя сам ищу подходящий PCI-E в LPT для XDS510PP/SPI515 JTAGs. :)

Не будет тормозить если подключить MCP2515 (SPI) напрямую на FTDI? Я решил использовать LPC1769 как контроллер для Network Gateway Module (скорее всего будет уметь Ethernet/USB <-> CAN/RS-232/RS-485), т.к. на борту есть Ethernet MAC (RMII), 2x CAN, USB, UARTs, 512k Flash, 64k RAM, бегает на 120MHz. Сейчас прикручиваю LwIP стек к FreeRTOS на LPCXpresso. После подключения к LAN8720 RJ-45 (MagJack) прием Ethernet пакетов запустился с полпинка. Скоро думаю малевать PCB.

Не будет тормозить если подключить MCP2515 (SPI) напрямую на FTDI?

в порівнянні із parport не буде, хоча би тому. що не тре другати кожен біт окремо, достатньо для FT2322 дати команду на запис/читання та вказати скільки буде бітів/байтів, а FTDI сам відтарабанить і передасть/вичитає буффер. Особливо якщо читати не побайтно, а ганати пачку даних, наприклад прочитати/передати пакет у/з мейлбокс. Можливо будуть проблеми із отриманням даних, так як тре буде пулати регістр переривань (по таймеру віндовс кожну 1мс, для лінукса думаю і кожні 125 мс — реально) хоча, думаю це питання теж вирішується.

Цікаво, маєш замовниика, чи так ваяєш, для загального розвитку?

Я к тому, что это уже будет не совсем real-time CAN.

Заказчика нет, пока просто хобби, от скуки.

P.S. Интересно, откуда значения 1 мс и 125 мс?

аналогічно.
ріалтайм для Віндоувз це ще питання, але для відладки «бізнес логіки», саме те що тре.
п.с.
зліпив до купи FT2232 та MCP2515 (при денному світлі спробую сфоткати байду )
Вже можу передавати тестовий пакет з одного нода на другий.
Лишилось малость — написати бізнес логіку.
Але може просто зліпити яку лібу (dll), а решту хай ваяє той кому це буде цікаво?. Що скажеш.

До речі, може би викласти на який ресурс, схему та ті сорси що є, може розвинути який «опен сорс»? Чи воно варте того? Яка з того користь і як його менеджити?

Какой смысл отлаживать «бизнес логику» если нет ни list of requirements ни HLD? Если прибор в принципе не сможет соответствовать поставленным требованиям с реализацией на FTDI то есть ли смысл тратить на это время?

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

Про выложить на ресурс идея неплохая, но надо сначала иметь что выкладывать. FT2232 и подключенный MCP2515 вроде не дотягивает до проекта. :) А вот монитор шины CAN с опторазвязкой интерфейса, питанием +9..36В, Ethernet или USB и программой для анализа принятых фреймов — это интереснее. Причем чтобы это все было с SW/HS документацией, с багтрекингом, репозиторием, поддержкой пользователей (блог и форум) и т.д.

Для этих целей себе купил начальный план на GitHub (есть бесплатные, но там все репозитории открытые), взял хостинг на Godaddy и «поднял» там Wiki, Mantis и блог — этой связки вполне достаточно для ведения проекта на пару человек. Базовые навыки «менеджерения» вроде есть, вот времени и денег пока не особо. :)

А вот монитор шины CAN с опторазвязкой интерфейса, питанием +9..36В,

для цього можна ставити ізолятори серії ADUM (від AD) або ISO (від TI). щодо аналіза фремів, а по якому протокулу аналізити, чи просто давати ID та payload?

Ethernet или USB

так що ліпше,
як на мене USB бо в компі портів більше.
колись пам«ятаю була тема.
Є дядьки, які займаються автоділами, то років 10 тому одни хотів щоб коли їде машина девайс, який сканує все, що твориться на CAN bus, щоб потім розшифровувати. яка система що сигналить.
Тому тут ще можна ММС карточку присобачити для сберігання даних.
Тобто фіч може бути багато.
Як на мене бібліотека краще. Тим більше, колись мав фірмовий USB — CAN, то там ішла дока на лібу і опис функцій які можна викликати (так як liibMPSSE для FTDI), а аплікуху тре було писати самому під конкретну задачу.
Я думаю, що тре зосередитись на homeautomation та CANopen для industrial. Бачив коробочки для PLC щоб керувати асинхронниками. то пропонуються дорогі «фірмові» коробочки для спряження інтерфейсів.

Ще один можливий сегмент.

It doesn’t matter which optocoupler to use, for example in my project I’m using FOD8012 (Fairchild Semiconductor) and ADM3052 (TI). Software should support at least a couple of the most common CAN protocols. For my Network Gateway Module I’m going to implement CANaerospace dissectors for Wireshark.

What about USB/Ethernet/Library it’s really up to you... Depends on project.

ріалтайм для Віндоувз це ще питання

NT-based ядра все реалтайм.

Угм, пока не произойдет любое хардварное прерывание в котором вначале стоит CLI

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

Это ненормально, так как драйвер железа никак не может гарантировать время обработки в течении которого запрещены все прерывания — это должна гарантировать OS. Ну а OS аля венда это никогда и не гарантировала — поэтому даже не смешно называть ее реалтаймовой. В реалтаймовых OS у обработчиков прерываний нет инструкций CLI/STI — используется подход irq pipe (прерывания всегда разрешены) при котором scheduler в состоянии прервать обработку прерывания в любом драйвере в случае если нужно передать выполнение задаче с более высоким приоритетом. Естественно что принцип приоритета обработки прерываний применим и при этом подходе, но поведение системы хотя бы предсказуемо в отличие от венды где никто никому ничего не гарантирует.

Это ненормально, так как драйвер железа никак не может гарантировать время обработки в течении которого запрещены все прерывания — это должна гарантировать OS.

На самом деле это не так. ОС должна предоставить драйверу все возможности, включая блокировку всех прерываний.

В реалтаймовых OS у обработчиков прерываний нет инструкций CLI/STI

Есть и в QNX и VxWorks. В QNX InterruptLock()/InterruptUnlock(), в VxWorks intLock(), intUnlock().

используется подход irq pipe (прерывания всегда разрешены) при котором scheduler в состоянии прервать обработку прерывания в любом драйвере в случае если нужно передать выполнение задаче с более высоким приоритетом.

Для этого есть CLI/STI, чтобы отобрать у ОС эту возможность. Реалтаймовость при это вовсе не теряется.

Вот поэтому и не отличается ни QNX ни VxWorks от венды в плане надежности. Тут как в анекдоте про динозавра — или OS в состоянии обеспечить соответствие временным условиям или нет. Примеров когда драйвер/обработчик железа вдруг станет timer hog’ом немеряно и при CLI/STI подходе венда и иже с ней демонстрируют missed deadline — т.е. получаем неуправляемую систему. Надеюсь лишне обьяснять, что если, RT задача занята чем-то серьезным, как например управление тяжелым оборудованием или скажем телефонной станцией на многие тыщи абонентов, то данный принципиальный архитектурный недостаток таких OS выливается в дорогостоящие потери.

Вот поэтому и не отличается ни QNX ни VxWorks от венды в плане надежности.

Сильное заявление, даже не буду комментировать. А что тогда отличается и почему тогда оно нигде не используется?

Тут как в анекдоте про динозавра — или OS в состоянии обеспечить соответствие временным условиям или нет.

ОС должна давать эту возможность, а не навязывать, ибо если такое поведение навязано, никто не сможет гарантировать работоспособность драйверов в этой системе.

Надеюсь лишне обьяснять, что если, RT задача занята чем-то серьезным, как например управление тяжелым оборудованием или скажем телефонной станцией на многие тыщи абонентов, то данный принципиальный архитектурный недостаток таких OS выливается в дорогостоящие потери.

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

Сильное заявление, даже не буду комментировать. А что тогда отличается и почему тогда оно нигде не используется?

irq pipe принцип используется в нескольких RT OS, как соответственно и сами OS применяются для решения различных промышленных задач.

ОС должна давать эту возможность, а не навязывать, ибо если такое поведение навязано, никто не сможет гарантировать работоспособность драйверов в этой системе.

RT ОS должна как минимум гарантировать изолированность и работоспособность RT-задач иначе это не RT OS, а черт знает что. Расстановка приоритетов навязывается самой поставленной задачей, а не RT OS, так как единственная функция последней это обеспечение гарантированной реализации этой расстановки.

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

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

irq pipe принцип используется в нескольких RT OS, как соответственно и сами OS применяются для решения различных промышленных задач.

Не самый оптимальный способ, ну да бог с ним. Названия у этих ОС есть?

RT ОS должна как минимум гарантировать изолированность и работоспособность RT-задач иначе это не RT OS, а черт знает что. Расстановка приоритетов навязывается самой поставленной задачей, а не RT OS, так как единственная функция последней это обеспечение гарантированной реализации этой расстановки.

Не должна. Ещё раз, к реалтайм это не имеет никакого отношение, откройте классические учебники, если есть недоверие. То что производитель совмещает эти две (и далеко не только эти две) вещи в одной ОС, это гуд, мы получаем realtime & reliability в одной упаковке.

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

Вы понимаете до конца суть своих заявлений? Т.е. если в системе с уже работающим драйвером появилась задача с более высоким приоритетом, драйвер перестаёт работать. Зачем такая система нужна? А Windows без примеров обсуждать бессмысленно, т.к. я вижу какое-то голое предубеждение не подкрепленное фактами.

Ну раз для Вас надежность применяемой системы не имеет значения, то говорить нам больше не о чем — судя по всему Вы подвержены распространенной иллюзии, что оборудование (винчестер for example) работает вечно.
Названия у этих OS есть ;) И с драйверами, которые прерываются более высокими задачами там тоже все в порядке.

Насчет ведра никаких предубеждений — я честно в свое время проверил что оно ничего не гарантирует и с тех пор не вижу смысла повторять эксперимент. Не верите — попробуйте сами, я кажется уже предложил элементарный способ как это можно проверить.

Ну раз для Вас надежность применяемой системы не имеет значения, то говорить нам больше не о чем

Я просто храню информацию в голове структурированно и не мешаю все понятия в кучу. Надежность важна, несомненно, один из самых важный аттрибутов. Голый реалтайм вообще мало кому нужен. Но как бы мне этого не хотелось, к реалтайм надёжность отношения никакого не имеет.

Названия у этих OS есть ;)

Чувствуется какая-та тайна. Или это как в анекдоте про неуловимого Джо?

И с драйверами, которые прерываются более высокими задачами там тоже все в порядке.

Значит оно там работает не так как Вы рассказывали.

Кстати проверить насколько ведро является реалтайм OS очень легко — запустите простую led blink RT задачу и выньте на ходу шнурок винчестера ;)

Если вырвать SATA — всё будет отлично, потому что это хотплаг :)

Про винт речь не идет — что будет с RT задачей, вот в чем вопрос ...

Так и я не про винт. Если данные RT задачи находятся не в pageable памяти, то она будет работать как и раньше.

Я бы на Вашем месте сначала проверил данное утверждение — на самом деле RT задача идет лесом вместе со всей системой.

Со всей системой? И что таки много Вы видели висящих виндовых серверов после замены хотплаг винтов?

Давайте исходники своей реалтаймовой задачи, я буду выдёргивать IDE, SATA и SCSI винты в горячую.

В венде я видел висящие RT задачи при клине одного единственного драйвера. Вы опять путаете работоспособность системы и RT задач — RT задача должна выполнятся при любых раскладах OS, будь то проблема в ее драйвере или в другой какой задаче. Именно поэтому в RT OS и используются специальные архитектурные решения и механизмы которые отличают их от не-RT. Особенно прикольно было наблюдать как ведро пыталось бороться с отсутствием файла подкачки и как появляющийся при этом синий экран смерти влияет на RT task. В RT OS ошибка системы будь то ее полная остановка никак не влияет на работоспособность RT задачи, по той простой причине что вся не-RT часть этой OS (куда кстати полностью входит ядро, его модули, обработчики всех не-RT прерываний, драйвера всех подсистем и выполняющиеся не-RT задачи) запускаются шчедулером супервизора как самая низкоприоритетная RT-задача.

Исходная постановка задачи состоят в моргании с частотой 500ms светодиода Caps Lock на PS/2 клаве — я могу привести тлько исходники для своей системы, так как ведро не юзаю по причине бесполезности. Думаю что для Вас не составит труда запустить и проверить эту не хитрую RT задачу, которая состоит обычно из нескольких строк на C.

В венде я видел висящие RT задачи при клине одного единственного драйвера. Вы опять путаете работоспособность системы и RT задач — RT задача должна выполнятся при любых раскладах OS, будь то проблема в ее драйвере или в другой какой задаче.

Я не путаю, есть реалтайм системы, и есть задачи, которые могут быть произвольными, в том числе и реалтаймовыми, и будут выполнятся на реалтайм системе. То, что Вы называете свойством РТ задачи — на самом деле является обычной надёжностью операционной системы и к реалтайму имеет весьма опосредованное отношение.

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

Реалтайм — это всего лишь прогнозируемость, гарантированная реакция за указанный промежуток времени на событие и набор инструментария для её создания. Все остальное к реалтайм не имеет отношения.

Про який рілтайм у Вєнді може бути мова, коли я не можу нормально грати в онлайн ігри. Як тільки починається звертання до диску, все замерзає на кілька секунд, а ігровий сервер каже, що відбулось роз"єднання звязку.

Отключи файл подкачки, если память позволяет.

а заодно відключити всі оновлення всіх можливих програм і самої вінди

Я не путаю, есть реалтайм системы, и есть задачи, которые могут быть произвольными, в том числе и реалтаймовыми, и будут выполнятся на реалтайм системе. То, что Вы называете свойством РТ задачи — на самом деле является обычной надёжностью операционной системы и к реалтайму имеет весьма опосредованное отношение.

Вот именно, а теперь обьясните мне почему в венде именно надежность OS влияет на работоспособность RT задачи ? Ответ прост — это не RT система, так как существуют условия при которых не-RT часть этой OS может привести к неработоспособности RT части, что никак не допустимо в разрезе ее применения для решения какой либо ответственной задачи.

Реалтайм — это всего лишь прогнозируемость, гарантированная реакция за указанный промежуток времени на событие и набор инструментария для её создания. Все остальное к реалтайм не имеет отношения.

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

Вот именно, а теперь обьясните мне почему в венде именно надежность OS влияет на работоспособность RT задачи ? Ответ прост — это не RT система, так как существуют условия при которых не-RT часть этой OS может привести к неработоспособности RT части, что никак не допустимо в разрезе ее применения для решения какой либо ответственной задачи.

Потому что у Windows хорошее реалтайм ядро, но вся ОС не реалтайм система. Я разве говорил другое?

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

Опять. Причём тут надёжность к реалтайм? Надёжность — это не аттрибут реалтайм системы.

Надёжность — это не аттрибут реалтайм системы.

Как говорил Остап Бендер — вопросов больше не имею.

А зря. Учиться никогда не поздно.

Ну да, только учеба разная — для одних она называется «на своих ошибках», а для других «на чужих».

ти ще не бачив що китайці витворяють
тому із намагаюсь докопатися, бо вони можуть щось таке вчудити, що не відповідає стандартам, але працює
п.с. і ще якщо людина цікавиться якимось нестандартим рішенням, це ще означає що вона долбойоб

тільки ельфи 80 рівня все знають, вони нічого в нікого не питають, а на будь яке питання у них завжди готова будь-яка відповідь.

А вы у плохих китайцев не учитесь, вы у хороших учитесь. И не путайте нестандартное техническое решение с элементарной технической безграмотностью.

PS А «бо вони можуть щось таке вчудити» откровенно повеселило.

До речі, приліпив езернет трансформери.
Тільки біда, дані на 1Мбіт спотворюються так, що в «listen mode» отримую не те що посилав.
От думаю, що далі робити, чи понижати бітрейт і дивитися що буде, чи перетворювати цифровий сигнал в більш приємний для трансформаторів, тобто в яку синусоїду а потім відтворювати з неї дискретний сигнал.

Або відложу експеременти до кращих часів.

А смысл ? Решение получается дороже/гембельней чем WiFi и медленней чем Ethernet (1 Gbit).

Там не потрібно великого потоку медіаданих.

Тема в тому, щоб використовувати мережу для контролю апаратури, наприклад електролічильник із можлвістю включити-виключити якийсь пристрій, або лічильник газу із запорним клапаном — не заплатив, пали патиками.

Тогда это толстое решение — имеет смысл смотреть в сторону дешевых радио-модулей и сверху набросать свой протокольчик. Или изучить соответствующие стандарты и клепать уже в их рамках, а то может так случиться, что выключить стандартный девайс, сделанный в какой-нить Европе, не будет никакой возможности.

IMHO, я бы рассмотрел реализацию по стандарту EHS/KNX :

en.wikipedia.org/.../KNX_(standard

Сам стандарт реализуется софтварно на MCU аля Atmega/MSP, хардварно используются FSK трансиверы ST7537/8

Все остальное IMHO или безбожно устарело (X10), или для штатов (Echelon/Insteon) или умерло не родившись (Powerline).

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

www.dynamix.ua/...mix-pl200av.htm
DYNAMIX PL-200AV
Знято з виробництва

З якого дива?

Без понятия, наверное мало кому было нужно. Как пример, у меня в квартире 5 фаз: электроплита, розетки в кухне (холодильник, электрочайник, etc), освещение во всех комнатах, розетки во всех остальных комнатах, ванная (стиральная машина, etc.). Т.е. кухня и ванная полностью электрически изолирована от всех остальных комнат. Некоторые в доме делали розетки и освещение в каждой комнате независимыми. Вот вся затея с передачей по сети лопается.

тре робити між фазами мости-репітори

По слухам, обычные конденсаторы между фазами сгодятся.
А затея эта може для какой-то большой виллы актуальна.
Для обычной квартиры хватает вайфая. Если чем-то управлять то железка с персобранным ядром + 10 баксовый вайфай (итого 60-70$ c точки).

Дешево и удобно.

А тут можна подетальніше, який можна взяти девайс, так щоб «перезібрати перснальне ядро» (наприклад OpenWRT) із запускався «своїм» модулем/драйвером або програмкою контролю залізачкою

Можно взять роутер от асуса и прошивку от Олега. Если мне не изменяет склероз, там поддерживается gpio чипа (через ключи можно чем-то управлять или снимать данные) + spi и rs232 можно запользовать. Из плюсов быстро + все красиво в одной коробке.

Для чего то более специфического плата на атмеловском арме с Линуксом + какой-то делинковский адаптер для вайфая.

Кросс компилятор для mipsel (wl500gp) ставил отсюда «deb www.emdebian.org/debian lenny main»

Есть еще вариант с пробросим ком порта по воздуху. Есть готовые чипы с минимумом обвязки. Но с ними можно попасть в лапы СБУ. Могут открыть уголовное дело «за контрабанду спец средств связи».

80 баксів за сплітер — дорогувато.

крім того. хотілось би щоб були там які ЦАП-АЦП та цифрові входи/виходи.

Підписатись на коментарі