возврат из подпрограмм

Hello Dmitry.

Sun Jul 30 2006 18:07, Dmitry Orlov wrote to me:

DT>> Разобраться бы ещё в этом дурацком Overlapped I/O... Это же надо, DT>> чтоб из UART-а прочитать блок с буферизацией, надо треды создавать...

DO> Да, понять это тяжело. Благо, меня вполне побайтовый ввод/вывод DO> устраивает.

Задачи разные бывают...

Dimmy.

Hello Alexey.

Sun Jul 30 2006 21:45, Alexey V Bugrov wrote to Sergei Podstrigailo:

SP>> Меня другое изумило - оказывается, нельзя одновременно в одном треде SP>> читать из COM-порта, а в другом - писать в него []

AVB> Вполне естесственное поведение. Переведи на русский слово overlapped.

Это-то понятно...

AVB> И нечего сверхестесственного в этом режиме нет, просто надо помнить о AVB> том, что ReadFile/WriteFile только инициируют операцию, а о AVB> завершении сигнализирует евент в контрольном блоке оперции AVB> (OVERLAPPED). Евента можно ждать WaitForSingleObject'ом или AVB> GetOverlappedResult.

В том-то и дело, что нужно _ждать_. А мне хотелось сделать "пассивную" DLL-ку (напомню, речь шла о Virtual Device Driver для VDM). Вызвал функцию - немедленно вернулся и получил данные или состояние. А тут DLL должна жить своей жизнью...

Dimmy.

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Michael Zaichenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Mon, 31 Jul

MZ>>>>> За несколько часов был написан форматировщик сишных текстов.

DO>>>> И какое он к эхотагу отношение имеет?

MZ>>> Ты никогда не форматировал исходники?

DO>> Hет, зачем??? Я их сразу пишу в удобном мне формате. И какое эта DO>> задача к embedded отношение имеет? MZ> А чужие исходники сопровождать не приходилось?

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

MZ>>> Или ты это руками делаешь? DO>> Какая разница чем? MZ> Разница во времни. Руками долго.

Я этого вообще не делаю, так что мне без разницы.

DO>>>> это опять же к эхотагу отношение имеет. У меня этот конвертор DO>>>> туда-сюда хотябы внутри PIC'а работает, у тебя есть пролог под DO>>>> pic?

MZ>>> Ясен пень - нет.

DO>> И ни под какую embedded платформу, кроме PC (кстати под какие ОС?) DO>> тоже надо полагать нет. MZ> Hа PC я уже перечислял оси.

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

DO>>>> Для этого вообще Exel есть.

MZ>>> Гы. MZ>>> А базу с датчиками он держать может?

DO>> Hе знаю. Я им почти не умею пользоваться.

MZ> Я тоже не знаю.

Зато я знаю, что существует интерфейс, позволяющий программам на Delphi/Builder работать с экселевскими таблицами, а значит и сделать достаточно просто связь со множеством database engine'ов и конечно с внешними устройствами.

MZ>>> А подбирать датчики в пары и тройки? MZ>>> А уметь общатся с внешним железом, дабы процесс обмера MZ>>> автоматизировать?

DO>> Hе думаю, что это проблема сделать. MZ> Конечно, на прологе :)

И на куче других средств.

MZ>>> Первым полем идет адрес, вторым имя, дальше тип обьекта (var,bit, MZ>>> label, etc). Отсортирован же он по именам, причем полная мешанина MZ>>> из всех секций.

DO>> Для таких задач вообще тулзы типа awk давно существуют, и DO>> разумеется это достаточно просто пишется на том же С, но к DO>> embedded они тоже не имеют никакого отношения.

MZ> Тебе вот лень мейк файл под винавр написать, так с какого мне всякие MZ> левые тулзы изучать? :)

Не изучай. Просто говорить о преимуществах пролога в embedded applications, приводя в пример задачи из совершенно других областей деятельности, к тому же имеющие массу куда менее экзотичных, чем Пролог, решений несколько странно.

dima

Привет!

Mon Jul 31 2006 09:40, Dimmy Timchenko wrote to Alexey V Bugrov:

AVB>> И нечего сверхестесственного в этом режиме нет, просто надо помнить AVB>> о том, что ReadFile/WriteFile только инициируют операцию, а о AVB>> завершении сигнализирует евент в контрольном блоке оперции AVB>> (OVERLAPPED). Евента можно ждать WaitForSingleObject'ом или AVB>> GetOverlappedResult. DT> В том-то и дело, что нужно _ждать_. А мне хотелось сделать "пассивную" DT> DLL-ку (напомню, речь шла о Virtual Device Driver для VDM). Вызвал DT> функцию - немедленно вернулся и получил данные или состояние. А тут DLL DT> должна жить своей жизнью...

Если ты о DLL в среде win32 на PC'шке, то вот буквально пару месяцев назад я решал подобную задачу. Имеется специальная клавиатура, соединенная с PC посредством COM-порта. С этой специальной клавиатуры поступают различные воздействия (нажатия клавиш, повороты енкодеров, даже положения ползунковых регуляторов). Все это добро нужно еще и предварительно "переваривать", а потом главная программа на эти воздействия реагирует.

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

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

Юргис

Hello, Jurgis Armanavichius! You wrote in conference fido7.ru.embedded to Dimmy Timchenko on Mon, 31 Jul

AVB>>> (OVERLAPPED). Евента можно ждать WaitForSingleObject'ом или AVB>>> GetOverlappedResult.

DT>> В том-то и дело, что нужно _ждать_. А мне хотелось сделать DT>> "пассивную" DT>> DLL-ку (напомню, речь шла о Virtual Device Driver для VDM). Вызвал DT>> функцию - немедленно вернулся и получил данные или состояние. А тут DT>> DLL должна жить своей жизнью...

JA> Если ты о DLL в среде win32 на PC'шке, то вот буквально пару месяцев

Не совсем, это такая специальная dll, которая общается через хитрый механизм исключений при неправильном опкоде с работающей в VDM _досовской_ программой. Делать в ней треды, а в них ожидания если и можно, то напряжно как-то.

JA> Таким образом, насколько я понимаю, можешь поступить и ты. Т.е. JA> сделать пассивную DLL'ку, которая будет ждать данных, если нужно, JA> что-то с ними делать. Работать она может в отдельном треде, сама по JA> себе.

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

JA> И пускай живет своей жизнью. Результаты своей работы она может помещать JA> в память с защитой скобками в виде критической секции. А твоя программа JA> может вызывать некоторую другую интерфейсную функцию этой DLL'ки (вне JA> рабочего треда), закрытую теми же скобками критической секции, которая JA> немедленно вернется с полученными данными или информацией о состоянии.

В принципе можно наверное, но как-то это все громоздко очень.

dima

Я плохо ориентируюсь в winapi. Но по-моему единственное место, где там нужны потоки/нити/треды -- получене асинхронных сигналов. Т.е. практически не нужны никакие треды. Может я и ошибаюсь.

Я плохо ориентируюсь в winapi. Но по-моему единственное место, где там нужны потоки/нити/треды -- получене асинхронных сигналов. Т.е. практически не нужны никакие треды. Может я и ошибаюсь.

Неплохо бы было иметь некий враппер вокруг этого всего, всё сводящий к posix-совместимому интерфейсу...

Привет!

Mon Jul 31 2006 17:57, Dmitry Orlov wrote to Jurgis Armanavichius:

DT>>> В том-то и дело, что нужно _ждать_. А мне хотелось сделать DT>>> "пассивную" DLL-ку (напомню, речь шла о Virtual Device Driver DT>>> для VDM). Вызвал функцию - немедленно вернулся и получил данные DT>>> или состояние. А тут DLL должна жить своей жизнью... JA>> Если ты о DLL в среде win32 на PC'шке, то вот буквально пару месяцев DO> Hе совсем, это такая специальная dll, которая общается через хитрый DO> механизм исключений при неправильном опкоде с работающей в VDM DO> _досовской_ программой. Делать в ней треды, а в них ожидания DO> если и можно, то напряжно как-то.

ХитрО... Hо ведь речь идет о досовской программе, работающей в среде win32? Раз так, то можно использовать WinAPI. А раз можно использовать WinAPI, то можно и треды порождать :-) Ведь так? (Спрашиваю потому, что в точности такой задачи еще не решал.)

JA>> Таким образом, насколько я понимаю, можешь поступить и ты. Т.е. JA>> сделать пассивную DLL'ку, которая будет ждать данных, если нужно, JA>> что-то с ними делать. Работать она может в отдельном треде, сама по JA>> себе. DO> Допустим даже это возможно, хотя и не очень понятно как этим управлять DO> из досовской-то программы.

Hет ничего проще. Если из досовской программы можно запустить DLL'ку, то можно вызывать функции этой DLL'ки, логично? А раз можно вызывать функции - все, можно использовать в точности тот механизм, что я описал.

JA>> И пускай живет своей жизнью. Результаты своей работы она может помещать JA>> в память с защитой скобками в виде критической секции. А твоя программа JA>> может вызывать некоторую другую интерфейсную функцию этой DLL'ки (вне JA>> рабочего треда), закрытую теми же скобками критической секции, которая JA>> немедленно вернется с полученными данными или информацией о состоянии. DO> В принципе можно наверное, но как-то это все громоздко очень.

Что ты, Дима! Hаоборот! Вот посмотри. Ты пишешь примитивнейшую программу, которая ничего больше не делает, как смотрит в рот COM-порту. Вдруг она получила какие-то байты из этого порта. Hесказанно обрадовавшись, она с ними что-то делает (например, пихает в FIFO, или как-то обрабатывает). Затем выставляет флажок "Данные готовы!". А другая функция, никак не связанная с рабочим тредом, проверяет этот флажок: "Что там у нас на первое?". Эту другую функцию вызывает досовская программа Dimmy (ведь мы считаем, что DLL'ки он может вызывать). Вот и все. Он получит информацию о том, что данные готовы, или получит статус, что, мол, придется еще подождать.

Или я снова что-то понял неправильно?

Юргис

Hi Dimmy, hope you are having a nice day!

AVB>> И нечего сверхестесственного в этом режиме нет, просто надо AVB>> помнить о том, что ReadFile/WriteFile только инициируют AVB>> операцию, а о завершении сигнализирует евент в контрольном блоке AVB>> оперции (OVERLAPPED). Евента можно ждать WaitForSingleObject'ом AVB>> или GetOverlappedResult.

DT> В том-то и дело, что нужно _ждать_. А мне хотелось сделать DT> "пассивную" DLL-ку (напомню, речь шла о Virtual Device Driver для DT> VDM). Вызвал функцию - немедленно вернулся и получил данные или DT> состояние. А тут DLL должна жить своей жизнью...

Разве в VDD запрещено делать потоки? Я писал в свое время эмулятор одной исовой железки вроде бы как-то эту проблему решил, за давностью не помню. Често говоря, пока не вижу в чем проблема. Если интересно - можно обсудить более подробно.

WBR, AVB

Hello, Jurgis Armanavichius! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Mon, 31 Jul

DT>>>> В том-то и дело, что нужно _ждать_. А мне хотелось сделать DT>>>> "пассивную" DLL-ку (напомню, речь шла о Virtual Device Driver для DT>>>> VDM). Вызвал функцию - немедленно вернулся и получил данные или DT>>>> состояние. А тут DLL должна жить своей жизнью... JA>>> Если ты о DLL в среде win32 на PC'шке, то вот буквально пару JA>>> месяцев

DO>> Hе совсем, это такая специальная dll, которая общается через хитрый DO>> механизм исключений при неправильном опкоде с работающей в VDM DO>> _досовской_ программой. Делать в ней треды, а в них ожидания если и DO>> можно, то напряжно как-то.

JA> ХитрО... Hо ведь речь идет о досовской программе, работающей в среде JA> win32? Раз так, то можно использовать WinAPI. А раз можно использовать JA> WinAPI, то можно и треды порождать :-) Ведь так?

Видимо так. Во всяком случае его частью. Хотя с функциями, которые требуют указателя окна может быть облом - нет ведь никакого окна. Но скажем CreateProcess для запуска программ работает, наверное и треды можно создавать. Наверное можно и порождать и убирать, я не знаю как это делается. Мой опыт win32 программирования не слишком от 0 отличается. Если бы ты привел пример такого кода, мне было бы понятнее.

JA> (Спрашиваю потому, что в точности такой задачи еще не решал.) JA>>> Таким образом, насколько я понимаю, можешь поступить и ты. Т.е. JA>>> сделать пассивную DLL'ку, которая будет ждать данных, если нужно, JA>>> что-то с ними делать. Работать она может в отдельном треде, сама JA>>> по себе.

DO>> Допустим даже это возможно, хотя и не очень понятно как этим DO>> управлять из досовской-то программы.

JA> Hет ничего проще. Если из досовской программы можно запустить JA> DLL'ку, то можно вызывать функции этой DLL'ки, логично? А раз можно

Даже параметры им можно передавать и возвращать. Более того, есть даже callback в досовскую программу, но у меня без глюков совершенно непонятных такое написать не получилось (на маленьком коде оно работает, на бОльшем - виснет), а примера как это делать я не нашел.

JA> вызывать функции - все, можно использовать в точности тот механизм, JA> что я описал.

Пример бы.

DO>> В принципе можно наверное, но как-то это все громоздко очень.

JA> Что ты, Дима! Hаоборот! Вот посмотри. Ты пишешь примитивнейшую JA> программу, которая ничего больше не делает, как смотрит в рот JA> COM-порту. Вдруг она получила какие-то байты из этого порта. JA> Hесказанно обрадовавшись, она с ними что-то делает (например, пихает JA> в FIFO, или как-то обрабатывает).

Может все именно так просто и есть, но хотелось бы пример.

JA> Или я снова что-то понял неправильно?

Скорее я. Я в win32 - чайник со свистком.

dima

Hello Jurgis.

Mon Jul 31 2006 16:24, Jurgis Armanavichius wrote to me:

JA> Таким образом, насколько я понимаю, можешь поступить и ты. Т.е. JA> сделать пассивную DLL'ку, которая будет ждать данных, если нужно, JA> что-то с ними делать. Работать она может в отдельном треде, сама по JA> себе. И пускай живет своей жизнью.

Какая ж она тогда пассивная? :) Hе путай терминологию.

Хорошо, запустить "ждущие треды" я могу при инициализации порта вызывающей задачей. Hо если она будет неожиданно закрыта?

Dimmy.

Hello Jurgis!

JA> назад я решал подобную задачу. Имеется специальная клавиатура, JA> соединенная с PC посредством COM-порта. С этой специальной клавиатуры JA> поступают различные воздействия (нажатия клавиш, повороты енкодеров, Вопрос: с данной клавы _поступают_ различные воздействия или данная клава _опрашивается_ на предмет таких воздействий? Мне вскоре придется решать подобную задачу, и я подумываю организовать процесс сбора в виде демона, который будет пережевывать весть поступающий поток данных и отправлять в лог, и терминала, обменивающегося с демоном через shared memory. Hикаких сообщений: терминал чисто пассивно сканирует shared memory и отображает новинки.

JA> написал DLL'ку, которая работает в отдельном треде, Иными словами, собираемые данные не настолько критичны, чтобы продолжать их сбор, когда сама задача отображения может не решаться. Так? Кстати, слова "DLL" я не знаю.

Anatoly

Hello Kirill.

Tue Aug 01 2006 16:17, Kirill Frolov wrote to me:

KF> В смысле вызывать WaitForBlablabla? Совершенно не нужно. Т.е. нужно KF> вообще, для того чтобы убедиться что, но вовсе не немедленно.

Какая разница? Мне надо проверить, есть данные в буфере или нет.

Dimmy.

В смысле вызывать WaitForBlablabla? Совершенно не нужно. Т.е. нужно вообще, для того чтобы убедиться что, но вовсе не немедленно. Можешь через пол-часа, можешь завтра, можешь в слеующий раз, перед тем как что-то понадобиться записать. :-/

Все используемые ресурсы будут освобождены средствами ОС.

Я мало что понимаю в VDM и Windows-программировании. Но что мешает иметь /отдельный процесс/ ("демон", "службу") для обработки всех событий поступающих от устройства и драйвера и собственно сохраняющий "состояние"? Средства IPC, имеющиеся в windows, VDM же не запрещает? Понятно что сам VDM при этом состояний не имеет.

Hello, Kirill! You wrote to Dimmy Timchenko on Tue, 1 Aug 2006 12:17:54 +0000 (UTC):

KF> В смысле вызывать WaitForBlablabla? Совершенно не нужно. Т.е. нужно KF> вообще, для того чтобы убедиться что, но вовсе не немедленно. Можешь KF> через пол-часа, можешь завтра, можешь в слеующий раз, перед тем как KF> что-то понадобиться записать. :-/

Даже более того, можно вызывать WaitForblablabla с нулевым таймаутом, т.е. не ждать, а просто проверить статус операции.

WBR, AVB

Hello, Dimmy! You wrote to Jurgis Armanavichius on Tue, 01 Aug 2006 07:19:37 +0400:

JA>> Таким образом, насколько я понимаю, можешь поступить и ты. Т.е. JA>> сделать пассивную DLL'ку, которая будет ждать данных, если нужно, JA>> что-то с ними делать. Работать она может в отдельном треде, сама по JA>> себе. И пускай живет своей жизнью.

DT> Какая ж она тогда пассивная? :) Hе путай терминологию.

DT> Хорошо, запустить "ждущие треды" я могу при инициализации порта DT> вызывающей задачей. Hо если она будет неожиданно закрыта?

DLL тоже будет закрыта, потоки прибьются. Если чувство эстетики не позволяет так делать, то у любой DLL есть функция DllMain, которая вызывается всегда при запуске/окончании нового потока и всей задачи как таковой. В ней и разруливать убийства ждущих потоков (через сигналы или просто килять).

WBR, AVB