Здрасте у золота не цена а курс )) Экономика батенька. Недавно оно стоили 250 за унцию

Реально на BF532 но только в партии 10000 штук они тогда по 5.32

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

Знаю но все они подороже стоят немного так )) А на него встает линукс и все задачи решаются, тоесть разработка софта сводится к простой компиляции uClinux с параметрами + небольшая програмка которая сохраняет /etc в пару разделов флешки. ARM стоит дороже. MIPS редко получалось быстро собрать ядро и запустить переферию.

Сообщение отредактировал Mihail Gluhowchenko - Jan 12 2009, 09:23

Совать сюда Blackfin - это наиболее бредовая идея из всех предложенных.
Blackfin-ы одни из самых неэффективных процессоров для сетевых приложений.
Греются как утюги, не технологичный корпус, требуют три разных питания, отсутствие внутренней Flash-и, средства отладки либо дубовые либо дорогие.
В программном плане более глючного решения чем uLinux придумать даже трудно.
Как виснет линукс темы возникают регулярно чуть ли не каждую неделю: http://electronix.ru/forum/index.php?showtopic=57717
Скорее всего такие дивайсы сами будут требовать постоянного наблюдения за собой.

Если нужен один ICMP то это потянет любой микроконтроллер с RAM в объеме до 2Кб еще и операционка поместится.
Это могут быть и AVR-ы и MSP и PIC-и и т.д.
Но рекомендовал бы ARM-ы на ядре Cortex как наиболее продвинутые и позволяющие лучше сохранить инвестиции.
Например STM32F101C6T6 стоит те самые 5$ в партии от 200 шт. и могут с успехом изобразить и ICMP и SMTP и Telnet и все что нужно.

Другое дело что я сильно сомневаюсь, что челу действительно нужен просто пинг.
Никогда дело этим не кончалось.
Когда обнаруживалось что роутеры виснут, клиенты всегда хотели знать почему виснут.
Обычно выдвигаются две версии - плохая температура эксплуатации и плохое питание.
И сразу же встает проблема серьезного мониторинга и другая тема: http://electronix.ru/forum/index.php?showtopic=57061

Лично я человеку банальный отвечатель на ICMP-пакеты не предлагал. Я ему предлагал - http://shop.wild-mix.com/images/docs/PWD.doc

Хуже всего то, что я на Украине, он в России. Я пока не могу решить вопрос отправки ему даже двух девайсов для теста - имеется в виду, чтобы не два месяца шли. Проводники, щусята, отказываются две коробочки передать...

Неплохой у вас дивайс.
Неужто всего за пару десятков баксов продаете?

Кстати не пробовали web страницы во Flash делать?
Например используя среду разработки Adobe Flex.
Можно получить шикарный дизайн и пользовательский интерфейс как у standalone приложения.

200 штук по $21.6. Розница $25. В эпоху стабильности было даже дешевле (в цену комплектухи трейдеры не закладывали неизвестность завтрашнего курса бакса).



Нет. Пользуюсь java-script и XMLHttpRequest. Ну и еще небольшим гейтом HTTP<->MySQL, на данный момент сделаном на IIS+JScript. Хотя, с тем же успехом, это может быть апач+пхп, там 15 строк кода.

А как кстати сейчас с Flash'ом на младших братьях - в смысле, на КПК? Дело в том, что Опера 9.5 работает совершенно одинаково (имеется в виду Javascript, DOM, фичи HTML5) , что на большом брате, что на младшем, нет проблем с переносом, одни и те же веб-страницы с file://localhost/ работают. Из КПК прикольные беспроводные ДУшки получаются

Надо же какой демпинг!
А зачем "гейт" если там у вас трапы посылаются? Или что такое "гейт" у вас?

На Flash и перешел именно из-за переносимости, тяжеловато приводить JavaScript и HTML к единому виду в IE, FF, Хроме и Опере
Опера у меня в телике стоит, Flash в ней работает.

Никакого демпинга. Оно примерно столько и стоит в серийном производстве.



Трапы там исключительно для тех, кто жить не может без snmp.

А вообще, изначально это мост Modbus over TCP - over serial line. Потом я решил для других своих модулей телеуправления сделать систему сбора данных, пользуясь технологией ajax (надоел кривой, непортабельный и не модифицируемый софт, писанный приглашаемыми на каждый проект писюковым кодерами).

В результате была сделана трансляция http - modbus. Потом туда был прикручен функционал ребутера. Потом добавилось имитация устройства модбас для получения состояния реле и аналоговых входов. Потом был написан модуль (на хтмл+жабаскрипт), который обслуживал именно этот девайс, как устройство модбас.
Потом был прикручен слив полученных из модулей данных в базу, реализованную на mysql.

Вообщем это выглядит так:

Структура страниц у меня там примерно такая. Есть корневой хтмл, который грузит мой фреймворк для работы с мостом хтмл - модбас, в нем делается необходимое количество iframe'ов, в каждый грузится хтмл, уникальный для каждого типа приборов, который производит визуализацию и обработку органов управления конкретно для данного типа девайсов. Конфигурация, зависящая от объекта (адреса модулей на шине модбас, доменные имена мостов, имена таблиц архивов в мускуле и т.д.) передаются из корневого хтмл через урлы загрузки подчиненных страниц.

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

Хм, если понял правильно вашу технологию,
то скажем клиенту в обсуждаемом случае придется сделать страницу содержащую 200! iframe ради возможности управлять всеми дивайсами одновременно.
Каждый из iframe должен как-то из JavaScript организовать ping.
Хотя я не знаю как с помощью JavaScript можно сгенерировать ping. Ведь это не HTTP поверх TCP, а более низкий слой.
Зная проблемы стабильности JavaScript в броузерах и неудобные средства отладки это очень опасное решение.
Может оказаться, что вообще 200 потоков скриптов не смогут в броузере работать.

Если речь идет об MySQL то тут наверно дивайсы в вашей технологии сами должны слать пакеты на IIS.
Т.е. сервер должен открыть публичный порт для некоего приложения у себя написанного под IIS.
Самого приложения для Ping-ов как я понял еще нет.
Странно что предлагая ставить ваши устройства в отдельный VLAN у вас нет настройки тега VLAN в устройствах.

Это все к вопросу о конечной цене решения.
Она далеко не так ясна как кажется.
Программист даже "средней руки" бесплатно работать наверно не будет.

А вот ActionScript в технологии Adobe Flash может создать сокетное подключение с любым бинарным протоколом и реально мог бы из броузера управлять двумя сотнями дивайсов.

А не нужно. Если девайс отвечает на HTTP-запросы, то, значит, коннект с ним есть Пингать в него - это лишнее.



javascript в браузерах исполняется в один поток (по крайней мере в пределах одного окна). Никакой многопоточности.



Ну тут я делаю примерно так - аварийные ситуации, которые летят по snmp, можно сливать в мускул банальным выполнением insert через консоль СУБД. Т.е. в конфигурации snmptrapd делается выполнение mysql -e INSERT blablabla по приходу моих трапов. Это предназначено только для сохранения текущих событий.

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



Да оно и не нужно. См. выше.



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

Да и вообще. Устройство расказывает от своем состоянии через Modbus over TCP. Можно прикрутить к любой SCADA-системе. Например сюда - http://oscada.diyaorg.dp.ua/index.php?id=2&L=1

Хм. Всегда считал, что ajax-запросы выполняются параллельно (Максимум одновременно - количество одновременных соединений к сайту в настройках)

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

P.S. А если уж очень хочется совместимость SCADA и прочими системами, то неплохо было бы реализовать протокол OPC. Хотя лично я слабо себе представляю, как его реализовать в простых контроллерах.

Запросы - да. А вот само исполнение javascript'а - один поток.

Параллельность там из-за того, что после .send() надо ждать DOM-сообщения. В это время можно запустить еще один запрос, или что-то другое сделать. Но, если, например, после .send() сделать for(;;), то сообщения Вы никогда не получите, потому как поток - один.



Да берется просто готовый OPC-сервер протокола Modbus over TCP и все.

Не, я понимаю, что за такие деньги клиент никогда не получит то что он попросил,
но весь базар начался с того дескать как элементарно пинги сделать, но готового решения то никто и не предложил!

HTTP понятно, но они требуют выделения на дивайс IP и возню с ними, в то время как Ping можно было бы в роутере редиректить на дивайс и все дивайсы могли бы иметь одинаковый IP и сильно уменьшились бы расходы на обслуживание и конфигурацию.

Движок скрипта в одном потоке выполняет лишь процедуры реакции на ивенты написанные в HTML странице.
А по сути асинхронные запросы (AJAX) выполняются в отдельных потоках.
Т.е. каждый HTTPRequest вызывает образование нового потока. Это свободно можно наблюдать c помощью ProcessExplorer
И вот эти потоки реквестов и есть основная причина торможения и зависаний броузеров ибо логика таймаутов там на рудиментарном уровне пока еще.

Не скажу что решение вообще неработоспособно, но такой винегрет из опенсорсных утилит, MySQL и скриптов наверно и достоин быть оценен в 20$

Человеку было предложено более правильное решение - не пингать в устройства из центра на места, а пусть устройства пингают до ближайших роутеров и ребутят свичи (или другое оборудование), если пропала связь. А дальше - любой каприз, хотите - ловите трапы (устройства отправляют их при изменении состояния реле и входов), хотите - ходите к устройствам через HTTP. Хотите - через 502й порт.

Более того, вынужден процитировать фразу заказчика после прочтения им описания:


А мы с Вами можем обсуждать философию построения таких систем/устройств хоть до китайской пасхи, лично мне беседа с Вами приносит только удовлетворение, всегда приятно поговорить с умным человеком

Можем, в частности, попросить модераторов отделить обсуждение в отдельную ветку, где и продолжим. Тут это, все-же, оффтоп.