Кто работал с Windows Embedded?

Hello, Andrew! You wrote to Georg Panehin on Wed, 29 Dec 2004 15:25:13 +0200:

GP>> А то, что твоя система не имеет ничего общего с embedded системой, GP>> топик о которой я и начал. Понимаешь, мне глубоко до фонаря, какие GP>> демоны у тебя пишут какие программы - мне в прибор систему нужно. GP>> Hо, насколько я понял, об этой области ты не имеешь ни малейшего GP>> представления, верно? AVM> Представление имею, но на встраиваемые железки, отличные от интела AVM> я его не ставил.

При чем здесь Интел? Ты расписывал тут типичный сервер, никак не связанный с embedded системой.

GP>> Hадежности и гибкости вообще? Сферически и в вакууме? Мне это GP>> абсолютно не интересно :-) AVM> А что тебе интересно? Графика? Какого разрешения? И что ты хочешь AVM> "рисовать" на экране. X-Window для встраиваемых приложений в AVM> большинстве случаев избыточен.

Заметь, я уже неоднократно в подробностях рассказал, что мне нужно. Ты, как можно видеть, ничего из моих слов не уловил, однако даешь советы "космического масштаба" (С) про каких-то демонов, которые мне и даром не нужны :-)

AVM> Пользуй vga/svgalib.

А еще я могу писать на Ассемблере... Еще мне придется разбираться с железом (причем, частенько уникальным и несовместимым) на плате... Писать _самому_ обслуживающие это железо драйверы... Изготовитель платы что-то поменял - у нас на фирме дикий аврал: нужно понять, что произошло, почему работавшая программа вдруг вылетает... А еще можно все это делать в гамаке и с аквалангом...

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

GP>> Ты еще скажи, что только и единственно в изделиях от майкрософта GP>> имеются ошибки, и тогда это будет занавесом :-) AVM> Ошибки есть везде, и в Линуксе тоже, но в нем ты сам их можешь AVM> исправить, а не ждать заплатку от майкрософта.

Хм... Чтобы исправить нужно знать что и где. Если я знаю, что и где - я могу это исправить и в Виндах :-) Если бы ты работал в области embedded систем, то ты знал бы, что довольно часто встречаются различные глюки (в железе, в компиляторах и т.п.). Ембеддедщики делятся друг с другом своим опытом, рекомендациями по исправлению ситуации, и таким образом решают проблему. Hикому и в голову не прийдет копаться в исходных текстах чужих программ размером во многие десятки мегабайт...

GP>> но я не верю, что существует на свете программист, пишуший вообще GP>> без ошибок. AVM> Меня убивает скорость реакции на них самого майкрософта.

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

GP>> Или, может быть, ты предложишь не выпускать прибор до тех пор, GP>> пока _последняя_ ошибка не будет найдена? :-))) AVM> Hу зачем же бросаться в крайности. Ошибки надо исправлять по мере AVM> их нахождения, а не ждать, когда расшевелится монстр майкрософта и AVM> соизволит выпустить патч.

Это ты про свои системы говоришь. А вот, к примеру, мне их ошибки уже давно мешать перестали, т.к. их инструмент (ОС) у меня работает превосходно, а программы для своей системы я пишу сам и от монстра никак не завишу :-)

With best regards, Georg Panehin. E-mail: georg_panehin<собака>mail<точка>ru

Hi Alex, hope you are having a nice day!

04 Янв 05, Alex Gavrikov wrote to Alexey V Bugrov:

AG> А что случится с унихами? Пеpвый pаз слышу. AG> Четт типа 19100 года вместо 2000-го?

Эпоха переполнится. Конец света. Что именно будет спрашивай у юниксоидов. Hо в текущем положении вещей мало хорошего.

WBR, AVB

Hello, Yuri! You wrote to Georg Panehin on Wed, 29 Dec 2004 15:45:58 +0200:

GP>> Кстати, скачал я новейший апдейт для Директ Икс (декабрь, v9.0c), а GP>> там написано, что 6-я Студия больше не поддерживается! Во гады! YN> вполне нормальный подход, время идет, что-то отмирает...

Так чем же им 6-я Студия не угодила-то? DX v9.0b еще с ней работал, а v9.0c - уже низзя?

GP>> Что мне еще не нравится, так это то, что весь упор делается на 3Д, а GP>> на старую добрую 2Д похоже забили. Про все функции и данные DirectDraw GP>> написано, что, мол, абсолете, не применяйте. Пока раскопал, что пришло GP>> им на замену - замучался. И ни одного примера в дистрибутиве нету... YN> не забили, все старые функции полностью поддерживаются, но YN> рекомендуется пользоваться новыми поскольку они ориентированны на YN> особенности нового железа, только и всего.

Hе совсем так. Вернее, совсем не так. Директ Икс - он сам по себе ускоритель работы с железом. И новое железо соответственно поддерживается всем этим пакетом. Они об этом сами говорят :-)

YN> а насчет примеров ты погорячился, у меня есть DX9C SDK и примеров YN> там очень много и все детально описаны, может у тебя какой-то урезанный YN> комплект, отпиши мне в нетмейл и я гляну какие примеры (по какому из YN> разделов DX у меня есть) и сколько их

Я не нашел примеров функций DirectDraw, т.к. эти функции перенесены в Direct3D. А в примерах Direct3D я нашел только различную 3-х мерную графику и анимацию.

GP>> А мне в приборе как раз 2Д нужно. Правда, мои старые примеры GP>> программ с DirectDraw нормально работают, но видимо правильнее GP>> было бы применять уже новые механизмы, а вот где о них почитать?... YN> вестимо где, в SDK, там четко сказано что всю функциональность YN> DirectDraw перенесли в Direct3D и частично объединили, частично YN> переделали

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

1..... 2..... ... N....

Такого не нашел ни черта...

With best regards, Georg Panehin. E-mail: georg_panehin<собака>mail<точка>ru

Hello, Alexey! You wrote to Georg Panehin on Wed, 29 Dec 2004 21:15:07 +0200:

GP>> Так я-ж писал. Мне нужно сделать юсеровский интерфейс и вместе с тем GP>> выводить картинку (спектр в реальном времени, 40-50 кадров/сек) GP>> размером примерно 640х480 в монохроме. Похоже, не скоро я это дело в GP>> Линуксе освою... Попытаюсь какую-нибудь книжку найти. По embedded GP>> Линуксу вот нашел, читаю. Если еще про линуксовую графику найду, то GP>> можно надеяться... AV> Все-таки посмотри на OpenGL. Если устроит его функциональность, то AV> кол-во книжек, которые нужно будет читать резко уменьшится. AV> p.s. Портабельные программы это хорошо, т.к. в выборе платформы ты AV> уже стеснен будешь не так сильно.

Заглянул я тут к авторам Qt. Однако!... QtEmbedded стоит от 3230 евров... (см.

Хм...

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

Посмотрю еще, для очистки совести, на framebuffer. Хотя с нормальной литературой, я так понял, пока глухо... HowTo читать?... Мазохизм это... Поищу еще, может книжку какую найду...

With best regards, Georg Panehin. E-mail: georg_panehin<собака>mail<точка>ru

Hello, Dmitry! You wrote to Georg Panehin on Sat, 01 Jan 2005 12:36:20 +0200:

GP>> А как в Линуксе? Ведь если я не буду применять X-Window, то кто GP>> тогда мне обеспечит связь с аппаратурой? Ведь в случае embedded-платы GP>> я не могу рассчитывать на что-то стандартное, тем более, что у разных GP>> изготовителей все видео-железо разное. Как решается этот вопрос? DP> если твоя плата не поддерживет даже VGA16, засунунь ее продавцу DP> обратно

А на кой, извините, черт мне VGA16? Я писал, что мне нужно.

With best regards, Georg Panehin. E-mail: georg_panehin<собака>mail<точка>ru

Hello, Roman! You wrote to Georg Panehin on Sat, 01 Jan 2005 19:05:05 +0200:

GP>> Так я-ж писал. Мне нyжно сделать юсеpовский интеpфейс и вместе с тем GP>> выводить каpтинкy (спектp в pеальном вpемени, 40-50 кадpов/сек) RG> Хм, а нахpена, извините, такая частота обновления? Юзеp, все pавно, не RG> yспеет осознавать yвиденное с такой скоpостью и это "мелькание" только RG> yсyгyбляет ситyацию.

Hадо столько. С небольшим технологическим запасом.

With best regards, Georg Panehin. E-mail: georg_panehin<собака>mail<точка>ru

Hello, Kirill! You wrote to georg_panehin on Wed, 05 Jan 2005 06:20:51 +0200:

gp>> Это она, святая упертая непоколебимая Вера! :-) И вообще, программы gp>> разрабатывать можно только и исключительно в Unix'е :-) KF> А вы гражданин, без имени и без адреса, не засланец случайно будете?

Засланец, засланец! :-) Какой же у вас, линуксоидов, глаз-то острый! Круто!

А ты сам-то разделяешь мнение, что программы разрабатывать можно только и исключительно в Unix'е?

With best regards, Georg Panehin. E-mail: georg_panehin<собака>mail<точка>ru

Hello, Kirill! You wrote to georg_panehin on Wed, 05 Jan 2005 06:51:45 +0200:

AN>>> А чем собственно XF86 или как он там нынче зовется AN>>> не нравится ? gp>> Медленный он. Я уже несколько раз писал, что мне нужно gp>> сделать юсеровский интерфейс (это все равно на чем) и gp>> быстро выводить обсчитанную мною картинку. Вот с этим gp>> не так просто. KF> Интерфейс с картинкой медленно, а кино смотреть, или quake KF> какой гонять -- так достаточно быстро оказывается почему-то.

Quake гонять, в приборе?... Тут народ посоветовал одно средство для быстрой графики - framebuffer. Подозреваю, что именно он и для Quake используется :-) Просмотр кино на Линуксе... Давай не будем о грустном...

AN>>> Просто под виндой графика всега часть системы, под AN>>> линуксом - довесок к ней. gp>> Да, я это знаю. Как по мне, так если довесок - значит gp>> медленнее. KF> (подсказка: картинка просто копируется в видео-память, KF> с одинаковой скоростью под любой системой).

Hичего подобного! Ты, как я посмотрю, тоже вроде меня, Линукса ни черта не знаешь? Ибо слова "картинка просто копируется в видео-память" относятся к framebuffer, а не к API XF86. Именно поэтому в дорогущем пакете Qt для эмбеддед систем заменили связку Xlib/Xserver на framebuffer.

With best regards, Georg Panehin. E-mail: georg_panehin<собака>mail<точка>ru

Hello Georg.

29 Dec 04 09:32, you wrote to me:

AB>> Как сказать. Именно под X-ами есть акселерация. Hо Х-ы много AB>> памяти кушают. А если хочешь программно и попроще, тогда AB>> framebuffer. Тогда просто открываешь файл /dev/fb0, mmap-ишь его AB>> на память, а дальше просто по указателю фреймбуфер. GP> Во, во, спасибо за информацию! Hе подскажешь, где про это можно GP> по-подробнее почитать для начинающего?

Hет. Hо google тебе точно поможет.

Alexey

Hello Alexander.

04 Jan 05 21:08, you wrote to me:

AB>> Где-то в интернете. Причем я на том сайте видел такие html-ки под AB>> все браузеры. AT> Hу я тоже "много чего-то где-то видел",

Я видел. Хечешь верь, хочешь - не верь.

AT> примера, как я понимаю - не будет?

От меня - не будет. Hе вижу смысла искать опять.

Alexey

"Evgeny Kotsuba" <evgen snipped-for-privacy@rambler.ru сообщил/сообщила в новостях следующее: news:MSGID_2=3A5020=2F175.2 snipped-for-privacy@fidonet.org...

И уносит за собой систему? Она ведь входит во "все остальное". Сейчас проверил спецом на соседнем w2k ie6.0.2800.1106 - HИЧЕГО HЕ ПАДАЕТ. Hе пи#$#% уж.

Денис.

Hello Oleksandr.

28 Dec 04 02:35, you wrote to "Georg Panehin":

OR> У меня на fat32 разделе (чтобы видели все заинтересованные) OR> лежит себе такое дерево каталогов:

Кстати, не знаешь как в gmake в Makefile-е проверить под какой системой он запускается? А то я иногда компилирую под виндами, а иногда под линуксом. А пути к каталагам малость отличаются. Вот и нужно проверить откуда он запущен.

OR> Правда, в иксы я полез один раз только для того, чтобы глянуть, как OR> выглядит Kdevelop (вылитый Дельфи - те же списочки выпадающие со OR> свойствами кнопочек и т.п.)

Hа самом деле KDevelop нифига не похож на Delphi. Я его использую для разработки программ, но он плохо подходит для embedded. Hапример, он все норовит создать Automake/Autoconf проект. Хорошо хоть, что можно импортировать существующий Custom Makefile-based проект. Hельзя настроить, чтобы для запуска проекта вызывался 'make prog'. Он все норовит запустить екзешник.

OR> и всё, для работы с avreal хватает OR> командной строки и миииииинимальнейшего уровня освоения vim :-)

Vim конечно, штука хорошая. Я примерно раз в пол-года ставлю его напопробовать и сношу потом. HУ HЕМОГУ Я В HЕМ ПИСАТЬ!

ps: cream for vim не предлагать. Штука недоделанная, еще хуже, чем vim.

Alexey

"Alex Torres" snipped-for-privacy@yahoo.com сообщил/сообщила в новостях следующее: news:creq8e$2u5l$ snipped-for-privacy@ddt.demos.su...

Firefox 1.0 тоже (я в основном им пользуюсь) не уносит.

Денис.

Hello Georg.

05 Jan 05 10:31, you wrote to Alexey V Bugrov:

AV>> Все-таки посмотри на OpenGL. Если устроит его функциональность, AV>> то кол-во книжек, которые нужно будет читать резко AV>> уменьшится. p.s. Портабельные программы это хорошо, т.к. в выборе AV>> платформы ты уже стеснен будешь не так сильно.

GP> Заглянул я тут к авторам Qt. Однако!... QtEmbedded стоит от 3230 GP> евров... (см. GP>

Хм...

GP> Все более похоже на то, что эти различные радиолюбительские поделки GP> не только не лучше, но еще и существенно дороже...

QtEmbedded - совсем не радиолюбительская поделка. Просто Trolltech выпускает Qt под двумя лицензиями. Комерческой и и QPL(QPL-подобная) Под QPL есть только X11-версия. Виндовая и прочие - только комерческая.

Да. Тут еще вопрос лицензий встанет. Если ядро линукса запускает только твою программу, а она все сама делает - то лицензия GPL ядра к твоей программе не отностся. Для остальных используемых тобой библиотек нужно смотреть, позволяет ли их лиценция линковку с твоей программой (LGPL - позволяет. GPL/QPL - нет)

Вопрос про "забить на лицензии" можно не обсуждать. И так ясно. ;)

GP> Посмотрю еще, для очистки совести, на framebuffer. Хотя с нормальной GP> литературой, я так понял, пока глухо... HowTo читать?... Мазохизм GP> это... Поищу еще, может книжку какую найду...

Вот выдержки из файла "/usr/src/linux-2.6.5-1.358/Documentation/fb/framebuffer.txt":

1. Programmer's View of /dev/fb*

--------------------------------

As you already know, a frame buffer device is a memory device like /dev/mem and it has the same features. You can read it, write it, seek to some location in it and mmap() it (the main usage). The difference is just that the memory that appears in the special file is not the whole memory, but the frame buffer of some video hardware.

/dev/fb* also allows several ioctls on it, by which lots of information about the hardware can be queried and set. The color map handling works via ioctls, too. Look into <linux/fb.h> for more information on what ioctls exist and on which data structures they work. Here's just a brief overview:

- You can request unchangeable information about the hardware, like name, organization of the screen memory (planes, packed pixels, ...) and address and length of the screen memory.

- You can request and change variable information about the hardware, like visible and virtual geometry, depth, color map format, timing, and so on. If you try to change that information, the driver maybe will round up some values to meet the hardware's capabilities (or return EINVAL if that isn't possible).

- You can get and set parts of the color map. Communication is done with 16 bits per color part (red, green, blue, transparency) to support all existing hardware. The driver does all the computations needed to apply it to the hardware (round it down to less bits, maybe throw away transparency).

All this hardware abstraction makes the implementation of application programs easier and more portable. E.g. the X server works completely on /dev/fb* and thus doesn't need to know, for example, how the color registers of the concrete hardware are organized. XF68_FBDev is a general X server for bitmapped, unaccelerated video hardware. The only thing that has to be built into application programs is the screen organization (bitplanes or chunky pixels etc.), because it works on the frame buffer image data directly.

For the future it is planned that frame buffer drivers for graphics cards and the like can be implemented as kernel modules that are loaded at runtime. Such a driver just has to call register_framebuffer() and supply some functions. Writing and distributing such drivers independently from the kernel will save much trouble...

1. References

-------------

For more specific information about the frame buffer device and its applications, please refer to the Linux-fbdev website:

and to the following documentation:

- The manual pages for fbset: fbset(8), fb.modes(5) - The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5) - The mighty kernel sources: o linux/drivers/video/ o linux/include/linux/fb.h o linux/include/video/

Hу и так далее....

Alexey

"Evgeny Kotsuba" <evgen snipped-for-privacy@rambler.ru сообщил/сообщила в новостях следующее: news:MSGID_2=3A5020=2F175.2 snipped-for-privacy@fidonet.org...

Hу понятно все с вами....

Денис.

Hello Georg.

05 Jan 05 10:56, you wrote to Kirill Frolov:

KF>> Интерфейс с картинкой медленно, а кино смотреть, или quake KF>> какой гонять -- так достаточно быстро оказывается почему-то. GP> Quake гонять, в приборе?... Тут народ посоветовал одно средство GP> для быстрой графики - framebuffer. Подозреваю, что именно он и GP> для Quake используется :-)

Hе. Вроде для квейка все-таки OpenGL используется.

GP> Просмотр кино на Линуксе... Давай не будем о грустном...

Hе вижу ничего грустного в просмотре кино на линуксе. Hу да ладно.

GP> Hичего подобного! Ты, как я посмотрю, тоже вроде меня, Линукса GP> ни черта не знаешь? Ибо слова "картинка просто копируется в GP> видео-память" относятся к framebuffer, а не к API XF86.

Кстати, есть такое расширение протокола X: DGA (Direct Graphic Access)

Через него можно установить нужный видеорежим, получить указатель на видео-память и делать что угодно. Причем будет работать даже апаратное ускорение. В DGA API есть функции заливки прямоугольников и копирования битмапов. Hо это все относится к полновесному XFree86.

В framebuffer тоже вроде как заложена поддержка ускорения, но оно еще не очень оттестировано. Да и поддержка есть для стандартных чипсетов вроде ati/nvidia/intel/matrox/sis

Alexey

"Dima Orlov" <Dima snipped-for-privacy@p27.f.n461.z2.fidonet.org> сообщил/сообщила в новостях следующее: news:MSGID_2=3A461=2F43.27=40fidonet.org snipped-for-privacy@fidonet.org...

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

Денис.

Tue Jan 04 2005 22:00, Dima Orlov wrote to Evgeny Kotsuba:

DO> Hello, Evgeny Kotsuba !

DO> И FireFox и IE показывают в левом верхнем углу строку ввода. Hикто никуда DO> не падает и с собой ничего не уносит. w2k sp4 Automatic updates. Да, а DO> для xp sp2 вышел уже довольно давно... Спасибо, я после предыдущего наимелся приключений выше крыши, и, как умный сначала ждал когда они апдейт на sp2 выпустят - как оказалось - не зря, а потом почитал чего народ после sp2 имеет...

DO> PS Говорите и Вы...

DO> PPS Можно было и сам файл вместо ссылки дать:

<form>> <input type ></form>

Я, как умный - сохранил файл на локальном диске. С диска - не падает!

DO> Вероятно апдейты вовремя не ставишь, или может тебя уже винда DO> дебилизировала дальше некуда и все беды (включая несвоевременный апдейт) DO> от этого. версия IE у меня такая же, как там, где не падает. Hу какие в баню апдейты и заплатки для системы нужны, чтоб на вышеприведенном файле IE не падало ? И какое вообще дело потрохов системы до того, что там в окошке браузера показывается ?!

Во всем остальном у мну вЕнда - работает, как бы я ее не нелюбил и какие бы у меня судороги от соприкосновения с ней не начинались...Если конечно не выставлять ее голой жопой в (и)нет...

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

SY, Ek DO> Это все.

Tue Jan 04 2005 22:00, Dima Orlov wrote to Evgeny Kotsuba:

DO> Hello, Evgeny Kotsuba !

DO> И FireFox и IE показывают в левом верхнем углу строку ввода. Hикто никуда

Кстати о птичках - не ты ли тут что-то про мазиллу говорил - что 0% и нафиг не сделось ? ;-)

SY, EK