Комментарии 31
НЛО прилетело и опубликовало эту надпись здесь
Да, спасибо за уточнение. Мы имели в виду, что это триггер для вызова обработчика SSI.
поскольку в случае постоянного обновления страницы (как предлагается в статье)
То ли мы очень непонятно написали, то ли Вы не внимательно прочитали.
Мы как раз предлагаем использовать SSE, в противовес к тому что сейчас обычно используется!
Собственно в статье и написано что устанавливается один раз соединение keep-aliveи поэтому не нужно перегружать статью.
Там же в статье гифки приведены, как раз для сравнения. Посмотрите видео, может станет понятнее.
НЛО прилетело и опубликовало эту надпись здесь
Глаз зацепился именно за фразу из заключения: Да SSE потребует немного больше ресурсов чем SSI.
…
а если ЦП и ОЗУ самого МК — то тут уж без вариантов :)
Поясню, SSI сейчас используется на микроконтроллерах. Поскольку он (точнее его реализация| есть в lwIP. Все очень примитивно поскольку можно выполнять обработчик последовательно, прямо в том же потоке. То есть нужно вставялять обработчик прямо в ваш код сервера, это не отдельное приложение или скрипт как в Embox. Следовательно Вы абсолютно правы в том что ЦПУ требуется больше( гораздо), при этом еще и забивается сеть ненужным трафиком. Но в случае ОЗУ, когда у вас есть 64 кБ нужно экономить, а для процесса (потока) нужен отдельный стек, то есть в этом месте и получается экономия.
Но повторюсь, мы пытались показать что SSE гораздо лучше, в том числе и для микроконтроллеров.
На WebSocket пробовали делать?
Нет, не пробовали, посчитали что SSE проще будет для полу-дуплесного соединения. В плане WebSocket'ов немного смотрели со стороны поддержки в Embox WebThings от Mozilla.
Вспомнил, какие микроконтроллеры валяются в ящике, теперь думаю, на чём лучше запускать – на atmega или на attiny13
:-D
Неплохо было бы хотя бы примерно обозначить целевой МК и описать, как на нём всё это поднять. А то человек, который всё это умеет – и описанное в статье сумеет сделать сам.
Неплохо было бы хотя бы примерно обозначить целевой МК и описать, как на нём всё это поднять. А то человек, который всё это умеет – и описанное в статье сумеет сделать сам.
На счет целевого МК, наверное нет какого то определенного критерия. Ну есть упоминания что на STM32F4 запустились, но не в этом суть.
Скорее статья посвящена тому, что если тебе нужен веб-интерфейс на твоем изделии, то можно это сделать хорошо. Цели показать что HTTP сервер работает на микроконтроллерах конечно не было. В первом же (вводном) абзаце об этом говорим. И дальше рассказываем, надеюсь доступно, чем лучше SSE и что для этого можно сделать, чтобы получить легко. Если кто то сделает сам, это хорошо. Если ему не нужно для этого читать статью, то тоже ниего плохого :)
Ну и да еще попутно, объясняется преимущества разработки на обычном хосте, а не через специализированный сервер на микроконтроллере. Но мне кажется естественным что если вам нужет какой то функционал, вы из этих требований и выбираете МК. Если конечно речь не идет речь о том что смотрите как я могу, но это уже другая песня.
Да берите mongoose и всё влезет, и всё будет.
Спасибо за наводку. Выглядит хорошо. Нужно будет ее изучить подробнее.
Возможно Вы ответите на пару ламерских вопросов, которые не смог взглянув на проект.
Проще говоря, это продвинутая версия lwIP?
Возможно Вы ответите на пару ламерских вопросов, которые не смог взглянув на проект.
- Первый Заявлена поддержка обычных платформ и ардуино, но для ардуино какой то плагин нужен. Для виндоус и других десктнопов, нужно запускать специальный сервер входящий в их состав.
- Второй Вы написали все будет, все влезет, у проекта заявлено все, но вот на счет влезет, имеется в виду что нужно брать их mongoose OS
Проще говоря, это продвинутая версия lwIP?
Вы о чем? Это C-файл. Скомпилировали под любую платформу и работает. Я его включаю и в консольное windows-приложение, и в GUI-шное, и в *nix утилиту. В Ардуино, честно, не пробовал, но должно влезть…
То есть Вы включаете С-файл в проект. И появляется веб сервер? А сайт в каком виде подключается, тоже С-файл? Я собственно это и спрашивал, получается аналог (продвинутый) lwIP? Там тоже есть сервер С-шник который можно скомпилить, и есть утилита которая представляет содержимое папки в виде массива (С-файл). Там в принципе тоже есть обработчики CGI и SSI (вебсокетов и SSE нет вроде). Но эти обработчики также должны вызываться напрямую из этого приложения. Мы показали, как в том числе и CGI скрипты отлаживать на хосте. Никто не спорит, что возможно запустить сайт на MCU. Мы показали один из вариантов, на мой взгляд он достаточно простой и сайты получаются приличные.
Но мы с помощью Embox легко вместились в STM32F4
Эээ… Моя любимая разработка AMS:
— работает на десятке микроконтроллерных платформ
— поддерживает работу с HTML, CSS, Javascript, Ajax и т. д. и т. п.
— имеет встроенный язык (макросы)
— содержит «из коробки» 8 сайтов в дистрибутиве, каждый со своей топологией, функционалом и дизайном
И всё это работает даже на ATmega 2560 с 8-ю килобайтами памяти.
www.youtube.com/channel/UCzwiCsCitrMphSTIEr8It_w
Спасибо за информацию.
Это Aurduino Mega Server?
Тогда мне кажется это слегка другое. В статье показано, что вы не используете ничего специального. Разрабатываете сайт на хосте, а потом запускаете на целевой платформе.
3D сцены выглядят круто, но все же цель была сделать устройство с современной веб мордой
Эээ… Моя любимая разработка AMS:
Это Aurduino Mega Server?
Тогда мне кажется это слегка другое. В статье показано, что вы не используете ничего специального. Разрабатываете сайт на хосте, а потом запускаете на целевой платформе.
3D сцены выглядят круто, но все же цель была сделать устройство с современной веб мордой
Не очень понял ваш комментарий — в случае AMS сайт разрабатывается с помощью стандартных веб-инструментов и просто копируется на SD карту. У меня на хостинге сайта hi-lab.ru и в микроконтроллерах на ATmega 2560 используются одни и те же куски кода (HTML, CSS, Javascript, Ajax).
По поводу «веб морды» — посмотрите самый длинный ролик — там «современной веб морды» хоть отбавляй.
По поводу «веб морды» — посмотрите самый длинный ролик — там «современной веб морды» хоть отбавляй.
Я и не спорю что там современные морды. Но посмотрите в статью, на хосте отлаживались и CGI скрипты. Как вы их на флешку перенесете?
И конечно, тут дело вкуса, если вам нравится именно эта технология, то ее и используйте! Я не сказал что она плохая.
И конечно, тут дело вкуса, если вам нравится именно эта технология, то ее и используйте! Я не сказал что она плохая.
Но посмотрите в статью, на хосте отлаживались и CGI скрипты. Как вы их на флешку перенесете?
А зачем? Я же написал, что AMS сервер содержит встроенный язык (макросы) и может как динамически (как угодно) формировать веб страницу при загрузке, так и интерактивно с ней взаимодействовать при помощи Ajax-а или веб-сокетов.
Кроме того, сравните ресурсы и память STM32F4 и ATmega 2560.
P.S.
Я тоже не говорил, что ваша технология плохая, я просто веду с вами академическую дискуссию.
я просто веду с вами академическую дискуссию.
:) дискуссия это всегда полезно. Позвояет рассмотреть разные подходы и мнения.
Я тоже не говорил, что ваша технология плохая,
Так ч том то и дело, мы же не преложили технологию разработки веб-сайтов. Как раз предожили использовать обычные технологии на микроконтроллерах. Хотя если рассматривать как технологию Embox, то да, он как раз и позволяет запихнуть функциональность Linux на микроконтроллер. Linux на F4 можно запустить но только из внешней памяти и Flash и SDRAM, у нас все внутри.
А зачем? Я же написал, что AMS сервер содержит встроенный язык (макросы) и может как динамически (как угодно) формировать веб страницу при загрузке, так и интерактивно с ней взаимодействовать при помощи Ajax-а или веб-сокетов.
Вашей же фразой, А зачем? Если есть обычные средства, а вам для разработки сайта нужно изучать что то новое. Ну и согласитесь гораздо больше времени потребуется чем в случае если проффесиональный веб-дизайнер накидает сайт, а эмбендыд программист займется в чем он профи.
Кроме того, сравните ресурсы и память STM32F4 и ATmega 2560.
Я бы сказал так, сравнивать нужно накладные рассходы, то есть если нужен какой то функционал, то он нужен. А в накладных расходах Embox, даст фору очень многим
И нужно учитывать, что STM32 это только пример, также сайт запустится и на других микроконтроллерах!
Было бы интересно узнать о самом процессе переноса на контроллер.
Какие контроллеры поддерживаются? Где взять этот конфиг?
Естественно все эти манипуляции нужно делать с конфигом для платы. После этого собираем и запускаем.
Какие контроллеры поддерживаются? Где взять этот конфиг?
Было бы интересно узнать о самом процессе переноса на контроллер.
Процесс переноса описан в статье. Это по сути дела просто копирование вашего сайта в файловую систему Embox (cont/rootfs или модуль отдельный). Предполагается что скрипты требуемые уже оформлены на С и они включены в конфиг
Какие контроллеры поддерживаются?
Не полный список STM32 https://github.com/embox/embox/wiki/STM32-MCU-Eval-Tools
Где взять этот конфиг?
Обычно он составляется самими разработчиками, но есть некоторое количество дефолтовый в папке platform/stm32/templates
Посмотреть список всех готовых можно make confload. Но все таки обычно на основе существующих разрабатывается свой. Добавляется вся функциональность для устройства, а затем включается отлаженный на хосте сайт
Для создания такого простого ВЕБ интерфейса не стоило идти таким сложным путем. Есть возможность сделать устройство с достойным интерфейсом другим способом. Вот пример ВЕБ интерфейса на МК. Хочется отметить большое количество настроек, динамическое формирование вида страницы, в зависимости от настроек, динамическое отображение процессов происходящих в системе, фейдеры управления, кнопки и много чего еще. Одна из страничек ВЕБ интерфейса
Сам девайс cvg.ru/tovar/diga/power_logic
Сам девайс cvg.ru/tovar/diga/power_logic
Было интересно почитать, но есть вопросы.
Какую именно особенность разработки сайтов для микроконтроллеров вы хотели отразить в статье? Из того с чем я сам сталкивался, это:
— как сделать сайт когда у тебя нет свободной RAM;
— как сделать красивый сайт когда у тебя нет свободной Flash.
Так-то получается что оптимизация по RAM отсутствует. Angular раздувает размер самого HTML файла (и сколько ему самому Flash надо?).
128Кб RAM — это на всю ОС с сервером или только сервер? А python http.server сколько памяти кушает? А сам python3 сколько Flash занимает? А сколько будет потреблять основное приложение?
Просто хотелось бы понять на какой STM32F4 это все рассчитано. В предложенном варианте сайт не влезет уже в 5 из 12 линеек STM32F4 и еще в двух останется только 64KiB RAM для основного функционала. Остаются только дорогие варианты.
Какую именно особенность разработки сайтов для микроконтроллеров вы хотели отразить в статье? Из того с чем я сам сталкивался, это:
— как сделать сайт когда у тебя нет свободной RAM;
— как сделать красивый сайт когда у тебя нет свободной Flash.
Так-то получается что оптимизация по RAM отсутствует. Angular раздувает размер самого HTML файла (и сколько ему самому Flash надо?).
Естественно за это придется расплачиваться. Да SSE потребует немного больше ресурсов чем SSI. Но мы с помощью Embox легко вместились в STM32F4 причем без оптимизации и использовали всего 128 кб ОЗУ. Меньше просто проверять не стали.
128Кб RAM — это на всю ОС с сервером или только сервер? А python http.server сколько памяти кушает? А сам python3 сколько Flash занимает? А сколько будет потреблять основное приложение?
Просто хотелось бы понять на какой STM32F4 это все рассчитано. В предложенном варианте сайт не влезет уже в 5 из 12 линеек STM32F4 и еще в двух останется только 64KiB RAM для основного функционала. Остаются только дорогие варианты.
Было интересно почитать, но есть вопросы.
Спасибо.
— как сделать сайт когда у тебя нет свободной RAM;
— как сделать красивый сайт когда у тебя нет свободной Flash.
Наверное никак.
То есть если нужен веб-интерфейс для вашего умного устройства то стоит выбирать соответсвующую платформу. Но на самом деле МК сильно подросли и развились (в плане энергопотребления) и использовать 8 разрядные МК наверное можно, но для очень узкого класса задач и уж не стоит к ним хороший веб-интерфейс привешивать (возможно, но будет стоить больше чем взять платформу побольше). Отвечая на вопрос про потребление. Вся система целиком, посмотрите видео, там есть много чего, влезла в 128кб ОЗУ. Думаю что можно даже в 64 уместиться было, но это могло потребовать лишнего дня разработки, а смысла не было видно. Следовательно, наверное можно считать что если вам нужен приличный сайт нужно 256 кБ ОЗУ и 64 кБ ПЗУ
128Кб RAM — это на всю ОС с сервером или только сервер?
конечно вся система, отдельный сервер не имеет смысла измерять, интересна работающая система с осмысленной функциональностью.
А python http.server сколько памяти кушает?
python это вообще на хосте запускался, можно было любой другой стандартный сервер использовать для отладки хоть apache. Суть то в статье что сайт разрабатывается на хосте, и затраты (по памяти) на МК крайне низкие.
Просто хотелось бы понять на какой STM32F4 это все рассчитано. В предложенном варианте сайт не влезет уже в 5 из 12 линеек STM32F4 и еще в двух останется только 64KiB RAM для основного функционала.
Уже ответил выше, что минимальными можно считать 256 кб ПЗУ и 64кб ОЗУ, выше будет только комфортнее. На сайте основное место занимают не текстовые файлы а картинки, соотвественно если вам нужен сайт с картинками, уж ничего не поделаешь, либо сайт на SD карту помещать, либо внешний флешь, ну либо побольше камень брать.
Какую именно особенность разработки сайтов для микроконтроллеров вы хотели отразить в статье?
Что на микроконтроллерах можно запускать такие же сайты как и все остальные. и разрабатывать их быстро и удобно на хосте,
Я использую микроконтроллеры PIC18, PIC32 и TCP/IP стек от микрочипа это аналог lwIP и они имеют много общего.
Такой веб интерфейс, как показан в примере, легко размещается в памяти самого процессора, даже PIC18 восьмибитного. Все делается без ОС.
Для более продвинутых интерфейсов используется внешняя SPI память и доработанный вариант MPFS и HTTP. Это позволяет разрабатывать ВЕБ интерфейс с использованием различных программных средств, а также позволяет создавать страницы с динамическими данными, такими как индикаторы уровня сигнала, изменяющиеся элементы, всплывающие банеры, изменяющиеся кнопки и индикаторы.
Я использую для продвинутых интерфейсов ajax технологии. Это позволяет обновлять только необходимые элементы интерфейса, очень низкая нагрузка на микроконтроллер, которая позволяет выводить даже индикаторы уровня сигнала, или анимированные изображения при помощи CVG графики.
Использование POST запросов позволяет вести взаимодействие ВЕБ и МК без обновления страницы.
К сожалению пока нет видеоперезентации что бы показать, но готовим, и скоро будет что показать.
Такой веб интерфейс, как показан в примере, легко размещается в памяти самого процессора, даже PIC18 восьмибитного. Все делается без ОС.
Для более продвинутых интерфейсов используется внешняя SPI память и доработанный вариант MPFS и HTTP. Это позволяет разрабатывать ВЕБ интерфейс с использованием различных программных средств, а также позволяет создавать страницы с динамическими данными, такими как индикаторы уровня сигнала, изменяющиеся элементы, всплывающие банеры, изменяющиеся кнопки и индикаторы.
Я использую для продвинутых интерфейсов ajax технологии. Это позволяет обновлять только необходимые элементы интерфейса, очень низкая нагрузка на микроконтроллер, которая позволяет выводить даже индикаторы уровня сигнала, или анимированные изображения при помощи CVG графики.
Использование POST запросов позволяет вести взаимодействие ВЕБ и МК без обновления страницы.
К сожалению пока нет видеоперезентации что бы показать, но готовим, и скоро будет что показать.
Спасибо.
но как написано в статье у нас полнофункциональная система с веб-интерфейсом. Мы конечно не специалисты по веб-дизайну, но я не понимаю почему вы говорите что сайт простой (и что он проше чем приведенный вами).
Еще в статье написано, что никого не удивишь HTTP не микроконтроллерах, мы лишь указали что есть простой способ это сделать, причем с обычными средствами, ничего специфичного для микроконтроллеров.
это хорошо, а то не очень понятно, что о чем именно вы говорите.
но как написано в статье у нас полнофункциональная система с веб-интерфейсом. Мы конечно не специалисты по веб-дизайну, но я не понимаю почему вы говорите что сайт простой (и что он проше чем приведенный вами).
Еще в статье написано, что никого не удивишь HTTP не микроконтроллерах, мы лишь указали что есть простой способ это сделать, причем с обычными средствами, ничего специфичного для микроконтроллеров.
К сожалению пока нет видеоперезентации что бы показать, но готовим, и скоро будет что показать.
это хорошо, а то не очень понятно, что о чем именно вы говорите.
Я также не специалист по ВЕБ дизайну, я схемотехник и программист МК.
Разработка ВЕБ интерфейса на МК сводится к нескольким шагам:
1. Содается эскиз страниц и определется какие данные нужно отображать на веб интерфейсе. Это могут быть значения датчика температуры, состояние входов, состояние кнопок управления и различные индикаторы. Определяется какие данные необходимо передавать с веб интерфейса в контроллер, как правило, это настройки и изменение органов управления устройством.
2. Определяется структура json файла, так же POST запросы.
Далее процес распараллеливается — ВЕБ программист пишет свою часть. т.е. делает веб интерфейс привычными ему средствами. А программист МК пишет обработчик POST запросов и вывод в json файл. На этом этапе как у ВЕБ программиста, так и программиста МК много средств для отладки и контроля работоспособности кода.
Программист МК составляет таблицу переменных для обеспечения работы ВЕБ интерфейса и переменных, задействованных непосредственно в логике работы устройства.
3. Загружаем файлы ВЕБ проекта в память по FTP или через ВЕБ интерфейс по uploud и проверяем и отлаживаем ВЕБ интерфес уже непосредственно в МК.
Такой подход позволяет разрабатывать проект двумя командами, каждый использует удобный набор инструментов, что сокращает время разработки.
Разработка ВЕБ интерфейса на МК сводится к нескольким шагам:
1. Содается эскиз страниц и определется какие данные нужно отображать на веб интерфейсе. Это могут быть значения датчика температуры, состояние входов, состояние кнопок управления и различные индикаторы. Определяется какие данные необходимо передавать с веб интерфейса в контроллер, как правило, это настройки и изменение органов управления устройством.
2. Определяется структура json файла, так же POST запросы.
Далее процес распараллеливается — ВЕБ программист пишет свою часть. т.е. делает веб интерфейс привычными ему средствами. А программист МК пишет обработчик POST запросов и вывод в json файл. На этом этапе как у ВЕБ программиста, так и программиста МК много средств для отладки и контроля работоспособности кода.
Программист МК составляет таблицу переменных для обеспечения работы ВЕБ интерфейса и переменных, задействованных непосредственно в логике работы устройства.
3. Загружаем файлы ВЕБ проекта в память по FTP или через ВЕБ интерфейс по uploud и проверяем и отлаживаем ВЕБ интерфес уже непосредственно в МК.
Такой подход позволяет разрабатывать проект двумя командами, каждый использует удобный набор инструментов, что сокращает время разработки.
Я также не специалист по ВЕБ дизайну, я схемотехник и программист МК.То есть обсуждают два не специалиста? Прикольно.
Разработка ВЕБ интерфейса на МК сводится к нескольким шагам:
Так я же и говорю, что не нужно ничего специального делать для МК
А программист МК пишет обработчик POST запросов и вывод в json файл. На этом этапе как у ВЕБ программиста, так и программиста МК много средств для отладки и контроля работоспособности кода.
Простите Вы мне кажется противоречите сами себе. POST запрос это же из области HTTP, зачем программисту МК вообще об этом знать, он специалист в другом. Если специались во всем то…
Программист МК составляет таблицу переменных для обеспечения работы ВЕБ интерфейса и переменных, задействованных непосредственно в логике работы устройства.Где он это составляет, что за таблица вообще?
Загружаем файлы ВЕБ проекта в память по FTP
А это еще зачем, то вы говорите что влезли в PIC18, то у вас какой то FTP (сервер или клиент) на МК крутится
Такой подход позволяет разрабатывать проект двумя командами, каждый использует удобный набор инструментов, что сокращает время разработки.Какой подход? В статье написано, что берешь и запускаешь на хосте. У вас какой подход?
А это еще зачем, то вы говорите что влезли в PIC18, то у вас какой то FTP (сервер или клиент) на МК крутится
Совершенно верно: на МК крутится FTP и HTTP сервер. А иначе как МК будет взаимодействовать с ВЕБ интерфейсом? И POST запросы МК обрабатывает, а иначе как МК получит данные с ВЕБ интерфейса? Можно и GET запросом делать, но тогда страница будет обновляться.
Статья называется «Разрабатываем web-site для микроконтроллера» вот это и сбивает с толку. Если ВЕБ для МК, тогда и стоит показать как на МК реализовать ВЕБ. А у вас целевой МК очень жирненький для многих применений, где может потребоваться настройка девайса через веб интерфейс.
Совершенно верно: на МК крутится FTP и HTTP сервер. А иначе как МК будет взаимодействовать с ВЕБ интерфейсом? И POST запросы МК обрабатывает, а иначе как МК получит данные с ВЕБ интерфейса? Можно и GET запросом делать, но тогда страница будет обновляться.
Статья называется «Разрабатываем web-site для микроконтроллера» вот это и сбивает с толку. Если ВЕБ для МК, тогда и стоит показать как на МК реализовать ВЕБ. А у вас целевой МК очень жирненький для многих применений, где может потребоваться настройка девайса через веб интерфейс.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разрабатываем web-site для микроконтроллера