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

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

Инструментарий для чего ? Для написания программы к АRM ? или для создания странички ? так тут и в блокноте можно делать.
Советую начать с изучения HTTP протокола, потом HTML + ajax, потом написание самого сервера.

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

Какай вопрос такой ответ, для начала вам нужет только компилятор для ARM, браузер, и блокнот

операционка Linux
просто на CGI такое можно сотворить?
страницы планирую хранить в файловой системе нв SD карте

Ну так с этого и надо начинать, а АРМ там или х86 уже не имеет значения. Тут я вам не помогу.

Так только на CGI такое и делают. На чем еще?

Но еще нужно сами страницы генерировать, не статически же их создавать. А то потом уйдет куча времени на их постоянные модификации.

У меня такой подход:
Еще на этапе создания приложения создается база данных переменных, событий и сигналов приложения.
Прямо в MS Access и создаю.
Потом пишу на VBA в том же MS Access небольшие функции которые из базы данных генерят ini файлы для операционки непосредственно хранящие значения переменных читаемых приложением, потом генерятся HTML страницы для встроенного WEB сервера с иерархией согласно иерархии переменных, дополнительно генерятся JSON файлы и MIB файлы с описанием все тех же переменных для других сетевых сервисов.
HTML правда содержит включениря динамически обрабатываемые сервером для правильного представления разных типов переменных разными виджетами.

Т.е. инструмент - MS Access и Basic
Ну и Dreamweaver от Adobe напоследок чтобы навести дизайн и создать .CSS файл управляющий представлением.

Пример взглянуть можно?
Почему не PHP?

P.S. Чт у вас с сайтом - все интересные проекты, старые тексты (со старого вашего сайта) файлы - поубивали? Если так - жаль...

Вот мой пример. Это не окончательная версия, для примера думаю сгодится.
Что-то меня дернуло сделать там кодировку КОИ8, не делайте так, лучше используйте UTF-8.
Я принципиально не использую разные верстальщики HTML (от них много мусора), все страницы верстались в текстовом редакторе.
Вроде в eclipse с плагинами делал.
Используется AJAX с JSON. CGI на С и на shell.
PHP для железки это по-моему уж слишком. Зачем он там?
Еще из плюшек использую библиотеки javascript это jquery, jquery datatables - для создания таблиц в html(http://www.datatables.net/), jquery impromptu - для всплывающих окон (http://trentrichardson.com/Impromptu/#Examples) и js файлы выдранные из своего домашнего роутера DIR-400 для проверки валидности IP адресов.
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Забыл скрипты вложить
Для работы с cgi была использована библиотека cgihtml, она была в комплекте моего ucLinux.
Вебсервер boa тоже был в комплекте
Нажмите для просмотра прикрепленного файла

Лет 7 тому назад писал web сервер на C++ объектно под Windows и назвал метод удаленным пользовательским интерфейсом. Все что видит пользователь на страничке в браузере, это отдельные объекты C++. Более сложные объекты обычно производны от простых.
Такой метод я считал более рациональным и функциональным чем существующие на тот момент методы, мною был создан полноценный WAP WEB интернет сайт. Данные хранились в БД SQL сервере.
Незнаю, прижилось ли нечто подобное? Помнится Микрософт делали нечто подобное на C#.
Для микроконтроллеров буду использовать только такой метод, только без ОС. Делал попытки, но пока сложности с размерностью буфера в котором будет создаваться объектная WEB страничка, под те контроллеры которые использую нужна внешняя SRAM память. В PC то память была практически неограниченной, аж 512 мб.
Извините за лирическое отступление от темы. Просто мне так думается по этому вопросу. PHP тогда мне казался очень ущербным при работе со значительными массивами данных. делал многопользовательскую справочную систему где одни пользователи данные вносили, а другие пользователи данные просматривали. Но скорее всего, просто не хотелось осваивать еще и PHP после письма PC программ на С++. погружаться в несколько ограниченную среду очень не хотелось. А так писал тоже самое что и программы под Windows, только с окошком в браузере. Почти таж надстройка над MFC , только для реализации браузерных окошек.
Это я к тому, что можно делать WEB интерфейс и на языке написания системных программ.

Можно, если веб-сервер свой, а это случается

Если веб-сервер стандартный (boa, apache,...) то, ИМХО, лучше воспользоваться "стандартными" средствами (блокнот, что там еще?), оттестировать все на "большом" брате, а затем перегнать на целевую плату...

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

В моем случае web сервер был просто модулем обработчиком HTTP протокола. Для микроконтроллеров наверное вполне логичен такой подход.
Сейчас подобное есть в библиотеке Микрочип TCP/IP Stack, использую для 8-бит микроконтроллеров в организациии WEB сервера. Например для простого ввода параметров в устройство из окна браузера по сети. В случае интернет-радиоприемника, ввожу названия и адреса интернет-радиостанций. позапрошлогодний проект.




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

зачем так сложно ? JS + Ajax + JSON. JSON легко генерируется/парсится на любом языке.

В те годы я не знал таких технологий
а с чего вы взяли что обьектное программирование C++ это сложно? Я же сказал, делал в таком духе потому как небыло времени переучиваться на традиционное веб программирование, оно казалось очень сложным. просто переложил технологию создания окон виндовс, в область ВЕБ. создал десяток простых обьектов, по типу как оконные обьекты виндовс (кнопки, менюшки, списки) и сделал так, чтоб эти обьекты были видны в окне браузера по HTTP, потом в своих программах использовал эти обьекты как базовые. чисто идеологически, написание web вервиса мало чем отличалось от написания оконного виндовс приложения, по этому не надо было переучиваться на веб программиста.

Что-то вы в кучу все сбили. И тут похоже называют одни и те же вещи разными именами.

Во первых AJAX требует XML. И скорее всего во встраиваемых серверах AJAX не имеет смысла ибо вообще нет такого объема структурированных данных которые бы требовали XML. Во вторых JSON есть аналог XML.
Т.е. по сути AJAX и JSON это несколько конкурирующие технологии и применять их одновременно можно только от большого ума (в хорошем смысле ).
В третьих это никак не влияет на применение CGI который на встраиваемых WEB серверах применяют все.
Ну и в четвертых реакцию на CGI на стороне встроенного WEB сервера по любому логичнее писать на C или C++ поскольку там это можно в отличии от серверов на сторонних хостингах и это удобней и гибче чем со скриптами типа PHP.

ошибаетесь, давно не требует http://www.ibm.com/developerworks/ru/library/wa-ajaxintro10/ , http://api.jquery.com/jQuery.getJSON/
да в принципе все равно на чем писать, но с Ajax проще - весь интерфейс это набор статических файлов, а генерация JSON проще чем генерация статического HTML

Да видать смысл аббревиатуры AJAX уже прочно исказился.

Но тем не менее роль CGI не только в том чтобы сгенерировать ответ в виде HTML страницы или JSON набора данных, но еще и выполнить действия непосредственно в микроконтроллере. Только на нативном языке это и можно сделать.
А сам Ajax по сути нужен только для добавления динамики в страницы. Если речь идет о редактировании параметров, то Ajax не при деле.

Да XML я думаю уже давно устарел. JSON имеет ряд преимуществ перед XML, например, меньший размер при том же объеме полезных данных. Но ключевое для меня это простота, мне читать JSON при отладке куда проще чем XML. Кстати для отладки из браузеров Opera, Mozilla и Chrome последний кажется мне наиболее удобным.
JS использую потому-что считаю необходимым проверять валидность данных до их отправки на сервер.
Да и без JS наверно невозможно сделать всплывающие окна и обновление лишь части html страницы, например в моем случае обновление состояния датчиков.
Javascript очень простой язык, а с jquery становится еще приятней.
Обновлять все страницу целиком как-то не серьезно.

почему ? Например после загрузки страницы JS шлет запрос и получает данные в виде JSON, парсит и заполняет поля данных. При нажатии кнопки - проверяет валидность, пакует данные обратно в JSON и отправляет серверу.

Я сторонник минимализма и концентрации как модно говорить "бизнес логики" в одном месте.
Проверка валидности данных в HTML странице перед отправкой, приводит к тому, что при изменении
структуры данных придется править две программы: в микроконтроллере и в скрипте на странице.
Пока данных мало или проект одиночный то можно терпеть.
Но скажем если параметров под сотню ( а это уровень сложности скажем так рядового частотного преобразователя в автоматизации), то проблема как говориться встает.
Вообще увлечение скриптами на стороне клиента чревато всегда двойной работой.
Хотя jquery сам люблю и применяю.

Я делал интерфейс без файлов. Интерфейс был одно приложение. В будущем планировалось отдельные модули упаковать в отдельные динамические библиотеки или СОМ объекты.

полностью динамический контент, все GET запросы пользователя обрабатывались и генерировался контент на ходу, согласно C++ программы и данных из БД.
Модуль который генерировал тот или иной объект видимый пользователю, так же и обрабатывал клики пользователя по этому объекту, разбирая POST запросы от пользователя. 100% объектно-ориентированный подход.

Для динамических страниц применение скриптов на стороне клиента оправдано - памяти то не бесконечно(на микроконтроллере). Проще формы и статический контент грузить в код, а динамически менять через ajax переменные-параметры. При этом ускорение работы страниц (из-за уменьшения объема обмена в десятки раз) огромное, правда скрипты загружаются долго в самом начале, зато потом даже сложная тяжелая форма летает . Например для маленьких микроконтроллеров без MMU linux и прочего по другому вообще никак, если хотите веб морду с серьезным дизайном (а не поделку на голом html). Да, и никто не запрещает написать генератор кода (например пишу для создания кусков страниц на Си в CGI из HTML контента) чтобы не делать как вы говорите - двойной работы. Я сторонник того чтобы программист пиал как можно больше утилит и программ )) Это повышает его умения.

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

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

Вы не поняли, я говорил о том что под скрипты на стороне клиента, нет полной гарантии что клиент сможет пользоваться сервисом. Только с помошью протестированного рекомендованного ПО

а где могут быть проблемы ? TCP - очень надежный протокол.
вот генерация HTML контроллером - это да, костыли еще те...

У вас проект интернет радио где нибудь в интернете лежит?

У меня на Linux уходило гораздо больше времени чтобы заполнить буфер данными чем на запуск ОС, без этого получите не интернет-радиоприемник а интернет-радио-заику

Нет. Но вы можете посмотреть Микрочип AN1128
Я встраивал интернет-радиоприемники в другие более сложные устройства. Просто радио, есть только этот пробный экспонат, но я его так не не довел до ума.




Я использую буфер 64 кБайта, этого хватает на несколько секунд воспроизведения при обрыве потока данных, без заикания.

Что-то слишком мало 64 кб, не помню точно сколько делал - у меня уходило на заполнение секунд 5, в Linux пару мегабайт отдать - ничего не значит плеер этот http://mpd.wikia.com/wiki/Music_Player_Daemon_Wiki им можно по сети управлять. Помоему 2 метра и отдавал под буфер а играть начинал после заполнения 20%.

Ну так это ж для случая рационального использования. Для звукового потока до 256 кбит/сек.
Обычно, если поток 128 кбит/сек, после отключения сетевого шнура продолжает играть несколько секунд.

При пакетной передаче gprs/edge задержки могут быть очень лихие, а если еще поток 320 kbps ? вся система - ядро, рантайм сишный, VPN клиент, WEB сервер, плеер при этом даже половину RAM не занимали, так что чего тут жадничать

Я не занимаюсь устройствами под управлением ОСей как минимум лет семь, если потребуется увеличить буфер, впаиваю еще пару микросхем SRAM и внесу изменения в ПО устройства.

Стоить это будет в итоге дороже чем arm с Linux, работать хуже, не достигнете даже 10 части функциональности и при этом вам практически недоступны дешевые USB модемы. Когда вы наконец научитесь считать деньги, может прозреете

Ошибаетесь.
минимальное интернет радио стот не дороже 1000 руб.
работает однозначно лучше, так как нет ничего лишего кроме обработчика интернет радио.
функциональность только та, как задумано разработчиком.

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







Кста, там есть и WEB интерфейс к настройкам ванной комнаты и включению режимов, таких, как например заблаговременный набор ванной перед приездом домой жарким летом, тоступ с помошью браузера сотового телефона

картинки напомнили известную историю - только не обижайтесь