Hello, Alexey! You wrote to Georg Panehin on Sat, 08 Jan 2005 18:05:02 +0200:
GP>> Большое спасибо, Алексей! Похоже, что ситуация постепенно меняется GP>> к лучшему? Попробую почитать на своем Линуксе (у меня RH 8-й вроде). AB> Если хочешь работать под линуксом - то RH8 - безнадежно устарел. (плюс AB> имеет набор противных глюков и проблем)
Хм... В самом начале этой ветки ("Кто pаботал с Windows Embedded?") меня принялись хором убеждать, что разрабатывать приборную программу под Виндой - ацтой, а Линукс - фарева.
Что же тогда получается? Линукс, вышедший совсем недавно, причем уже
8-й версии, т.е. достаточно хорошо вылизанный, безнадежно устарел?! Елки палки! Так на хрена тогда уже второй месяц мне расписывают преимущества Линукса, если он "безнадежно устарел"?! :-)
GP>> Мне и нужно-то для начала просто окно создать, кнопочку какую GP>> поставить, поле ввода породить, да в нем "Hello? World!" написать :-) AB> Hет. Дельфей под линуксом нет (то что есть - сырое и тебе не подойдет) AB> Обычно начинают с программ типа printf("Hello world\n");
А на кой мне писать программу printf("Hello world\n");, если я это делаю уже второй десяток лет? :-) Более того, эта самая printf давно живет во всех моих приборных программах (правда, в собственной интерпретации, чтобы места гораздо меньше занимала. Я сделал свой вариант, sprintf, который полностью совместим со стандартной, и вывожу на экран полученную строку символов). Мне интересно в графической среде (да еще с окошком с "живой" картинкой) написать на экране что-нибудь. Без "Дельфей" это сделать гораздо труднее :-)
AB> Тебе нужно просто найти хороший редактор и им пользоваться.
В последнее время пользую UltraEdit. Подсветка синтаксиса доброго десятка форматов, запуск внешних программ, перехват сообщений компиляции и т.п. Хороший редактор.
AB> В конечном итоге нет необходимости писать программу сидя под AB> линуксом. Можно найти или сделать gcc, который будет работать под AB> виндой, а компилировать программу для линукс.
Я это знаю. Я сам себе скомпилировал gcc (2.95.3) для моего 16-разрядного микроконтроллера и пользуюсь им под Виндой. Однако имеется загвоздка. Если, как ты предлагаешь, я буду писать под Виндой программы для Линукса, то как я буду их отлаживать?! Это, типа, скомпилировал, перезагрузил комп, запустил программу под Линуксом, увидел, что что-то не так, обратно перезагрузил комп, исправил, снова перекомпилировал, снова перегрузил...
Хм... Я не женщина, мне терпения не хватит... А два компа в параллель (на одном компилировать, на другом пробовать запускать) мне не дадут...
GP>> Да, еще хотел спросить. Мне, в общем-то, без разницы, на чем писать GP>> юсеровский интерфейс (что первым освою - то и хорошо :-) Скорее GP>> всего это будет X-Window, т.к. в одной из книжек, которые у меня есть, GP>> имеется коротенькое описание программирования под X-Window). AB> Тут нужно знать, что из себя представляет система X Window. X-сервер - AB> это графический сервер, который выполняет команды отрисовки, AB> посылаемые программами-клиентами. Hу, плюс, управление окнами, AB> и обработка ввода с клавиатуры и мышки, события о которых посылаются AB> от сервера к клиенту. То есть программа клиент подключается к серверу AB> по TCP/IP и они обмениваются сообщениями. Hа этом, собственно, все.
Большое спасибо за разъяснение! Этот механизм как-то ускользал от моего внимания. Т.е. я краем уха слышал, что там TCP/IP используется, но теперь я это немного лучше представляю. Спасибо!
AB> Для организации элементов управления (кнопочек и так далее) поверх AB> библитеки графических примитивов существуют отдельные библиотеки AB> (Widget Toolkit-ы). Из используемых чаще всего для прикладных программ AB> - GTK и Qt. Hо они весьма тяжеловаты для Embedded Linux'а (Кстати, а AB> какие у тебя аппаратные ресурсы). Для embedded, обычно, применяют AB> тулкиты попроще и полегче. Типа X Athena Widgets, FLTK, Fox Toolkit, и AB> др.
Собираюсь попробовать на PC-совместимой плате, что-то типа Celeron 1 GHz или около того. В общем, я так понимаю, проблем с памятью не будет. Сейчас они все делаются со 128-256-512 МБайт на борту.
GP>> Однако, меня интересует вопрос: сохранится ли совместимость GP>> framebuffer-а с X-Window или какой другой подсистемой GUI? Hадеюсь, GP>> их использование не является взаимоисключающим? AB> Э, я не совсем понял вопрос, объясню как есть. framebuffer - всего лишь AB> метод доступа к аппаратуре - памяти видеокарты. С одной видеокартой AB> может работать одна программа. Если это твоя программа - то она AB> использует его монопольно. Сама все рисует и т.д. Если на фреймбуфере AB> работает X-сервер - то твоя программа не сможет получить доступ к AB> фреймбуферу.
Все... Это катастрофа... Я надеялся применить что-то стандартное для разработки юсеровского интерфейса и framebuffer для вывода картинки. Капут... Кнопочки я сам рисовать точно не буду (я и так сыт по горло собственной графикой :-)
AB> Тот же Qt Embedded работает через фреймбуфер, но у него есть какие-то AB> свои средства управления доступом нескольких программ к одному AB> фреймбуферу и управления окнами, но я не знаю какие.
Да, они там все полностью сами делают. Только больно уж дорого...
Получается, что Windows Embedded... О чем я, собственно, с самого начала и говорил :-)
With best regards, Georg Panehin. E-mail: georg_panehin<собака>mail<точка>ru