Кто писал под Win CE ? Это вообще реально ?

**RX1AL** · 03.12.2008, 22:56

Само вложение... В первый раз пропало.

**KulibinV** · 04.12.2008, 10:20

Сообщение от RX1AL

Для KulibinV:

Нужна библиотека для СЕ под RS-485, написання на С++ под "чистый" СЕ и есть С для .NET версии.

Ваш предыдущий ответ я понял как предложение сделать не только СУ (хост) под
СЕ , но и контроллеры датчиков . С этим разобрались .
Драйвера контроллера датчика под СЕ нет.Его надо писать .
Сейчас я с ним общаюсь:
1: под ДОС .Все работает , но заказчик не доволен интерфейсом .
2: Через СОМ под ХР . В целом - не работает .

Про переходник USB > COM . У меня такой сделан . С ним экспериментировали . Стандартные его
драйвера (фирмы FTDI)не поддерживают нужного режима - изохронного.
Там только потоковый режим . У него большая пропускная способность, но обмен идет очень
длинными посылками - 1 E-3 [с], как для фулл спид так и для хайт спид . Не проходит
по времени реакции

Микрософт поставляет пакет для написание пользовательских драйверов изохронного режима.
Для ХР . Но стоит он по разным данным 3'000$-5'000$ .

Про два этапа в понятно .Я так примерно и предполагал . Идея подпихнуть и использовать "чужие" драйвера обсуждается.

Статья понятна и очевидна (очень ). Она для микроконтроллеров . Чем я собственно и занимаюсь.
Под ДОС аналогично легко обращался к сом операторами С++ inportb(,) и outportb(,).
Под ХР такой обмен идет через связанные потоки , только он рваный .
Вопрос , останится ли он настолько рваным под СЕ или нет ?

А вот описание этой библиотеки представляло бы максимальный интерес

**RX1AL** · 04.12.2008, 20:47

Сообщение от KulibinV

Ваш предыдущий ответ я понял как предложение сделать не только СУ (хост) под СЕ , но и контроллеры датчиков. Драйвера контроллера датчика под СЕ нет. Его надо писать .
Сейчас я с ним общаюсь:
1: под ДОС .Все работает, но заказчик не доволен интерфейсом .
2: Через СОМ под ХР. В целом - не работает.

Что конкретно не работает? Я не совсем понял... СОМ никогда не поддерживал isochronous transfer и поэтому как он может работать? Во-вторых, попытка взять на себя под ХР управление СОМ - чревата... так как в "исключительном режиме" невозможна по определению. А для того, чтобы работать, надо либо через P/Invoke, либо через wrapper драйвера. Хотя в С++ и есть функции для работы с СОМ, они не предоставляют "искличительного" режима доступа. Все идет через систему. А вам, такое не нужно, так как потеря лишнего времени на обработке.

Начнём, помолясь... И сначала с того, что мне до сих пор непонятно, зачем такой огород городить для работы с датчиками на RS-485? У вас опрос 1 мс, а вы пытаетесь с ними работать, как с датчиками реального времени. Почему? Да ответ на поверхности. Вы пишете, что в связке USB -> COM вам необходим isochronous USB transfer. Открываем документацию по USB 1.1 или 2.0 и читаем:

а) "Isochronous transfers occur continuously and periodically. They typically contain time sensitive information, such as an audio or video stream." - у нас вроде не видео и не аудио данные.
б) "Isochronous transfers provide stream pipe - unidirectional" - вопрос, а зачем нам двунаправленный канал? Мы лишь забираем данные от датчика.

Кроме того, максимальный size data payload ограничен и развен 1023 (full speed device) и 1024 байта (high speed device), что тоже важно. Далее при работе в таком режиме при 1 мс такте, окно для снятия данных всего 250 мкс, согласно спецификации. Тоже критичная величина. Ну да ладно, хозяин - барин, хотя непонятно такое желание.

Теперь поедем по всем вашим трудностям и проблематике:

1. FTDI имеет в своем драйвере поддержку isochronous transfer, как для чипа FTDI-232, FTDI-245В, так и для последующих. Что-то вы упустили, в описании или использовании драйвера. Фрагмент кода и обсуждение здесь (когда-то сам с этим боролся давно):

http://www.motherboardpoint.com/t895...-transfer.html

2. По поводу библиотеки от Микрософт. Во-первых, такая библиотека называется WINDDK (Windows Device Driver Kit) и она совершенно бесплатна, вот весит прилично, один дивидюк полностью. Если вам надо, могу прожечь на болванке и отослать, но думаю в России ее достать также легко.

В этой библиотеке есть все, что вам надо для старта. Куча примеров на С++, и кстати под СЕ также.
Смотрите например ссылку: http://msdn.microsoft.com/en-us/library/ms790482.aspx

После инсталляции найдете в папке WINDDK\6000\src\usb\isousb\ весь исходный код того, как такой isochronous transfer должен быть написан. Тест также приведен. Более, чем достаточно.

3. Собственно по библиотекам. Наша вам точно не подойдет. Мы используем нормальный, квотированный обмен с устройством, и я извиняюсь, но так "не извращаемся", ибо в наших задачах все попроще. Но тем не менее, готовых библиотек много и ссылки на них я привожу ниже. Все бесплатные и хорошо описаны:

а) http://www.opencores.org/projects.cg...slave/overview - что поддерживает, видно из описания. Код на исходный текст в статье.
б) http://docs.sun.com/app/docs/doc/819...xfer-9f?a=view - с самой книге (PDF) все разжевано до нельзя со всеми примерами. Как стартовая точка, то, что надо.
в) http://techon.nikkeibp.co.jp/article...29/152601/?P=3 - описание общего принципа для работы с USB в плане embedded. Также очень полезно ознакомиться.
г) http://www.lvr.com/usb.htm - основной старт пункт для всех вопросов.
д) www.sourceforge.net/projects/easyusb - собственно сам драйвер с исходниками, со всеми режимами работы.
е) http://www.opensource.apple.com - Darwin hardware (IOKit) - не надо пугаться, что под Макинтош... я кучу этого кода уже для наших задач адаптировал. Там чистый С++, не более. А главное он хорошо документирован, что немаловажно.

Для начала думаю хватит. Что я точно не хочу делать, так это писать все... но если у вас будут конкретные затыки или проблемы с кодом, здесь пожалуйста.
И последнее: используйте не USB -> СОМ, а USВ -> RS-485 переходник. Не нужно включать дополнительное звено...

Добавлено через 5 минут

Сообщение от KulibinV

Ваш предыдущий ответ я понял как предложение сделать не только СУ (хост) под СЕ , но и контроллеры датчиков. Драйвера контроллера датчика под СЕ нет. Его надо писать .
Сейчас я с ним общаюсь:
1: под ДОС .Все работает, но заказчик не доволен интерфейсом .
2: Через СОМ под ХР. В целом - не работает.

Что конкретно не работает? Я не совсем понял... СОМ никогда не поддерживал isochronous transfer и поэтому как он может работать? Во-вторых, попытка взять на себя под ХР управление СОМ - чревата... так как в "исключительном режиме" невозможна по определению. А для того, чтобы работать, надо либо через P/Invoke, либо через wrapper драйвера. Хотя в С++ и есть функции для работы с СОМ, они не предоставляют "искличительного" режима доступа. Все идет через систему. А вам, такое не нужно, так как потеря лишнего времени на обработке.

Начнём, помолясь... И сначала с того, что мне до сих пор непонятно, зачем такой огород городить для работы с датчиками на RS-485? У вас опрос 1 мс, а вы пытаетесь с ними работать, как с датчиками реального времени. Почему? Да ответ на поверхности. Вы пишете, что в связке USB -> COM вам необходим isochronous USB transfer. Открываем документацию по USB 1.1 или 2.0 и читаем:

а) "Isochronous transfers occur continuously and periodically. They typically contain time sensitive information, such as an audio or video stream." - у нас вроде не видео и не аудио данные.
б) "Isochronous transfers provide stream pipe - unidirectional" - вопрос, а зачем нам двунаправленный канал? Мы лишь забираем данные от датчика.

Кроме того, максимальный size data payload ограничен и развен 1023 (full speed device) и 1024 байта (high speed device), что тоже важно. Далее при работе в таком режиме при 1 мс такте, окно для снятия данных всего 250 мкс, согласно спецификации. Тоже критичная величина. Ну да ладно, хозяин - барин, хотя непонятно такое желание.

Теперь поедем по всем вашим трудностям и проблематике:

1. FTDI имеет в своем драйвере поддержку isochronous transfer, как для чипа FTDI-232, FTDI-245В, так и для последующих. Что-то вы упустили, в описании или использовании драйвера. Фрагмент кода и обсуждение здесь (когда-то сам с этим боролся давно):

http://www.motherboardpoint.com/t895...-transfer.html

2. По поводу библиотеки от Микрософт. Во-первых, такая библиотека называется WINDDK (Windows Device Driver Kit) и она совершенно бесплатна, вот весит прилично, один дивидюк полностью. Если вам надо, могу прожечь на болванке и отослать, но думаю в России ее достать также легко.

В этой библиотеке есть все, что вам надо для старта. Куча примеров на С++, и кстати под СЕ также.
Смотрите например ссылку: http://msdn.microsoft.com/en-us/library/ms790482.aspx

После инсталляции найдете в папке WINDDK\6000\src\usb\isousb\ весь исходный код того, как такой isochronous transfer должен быть написан. Тест также приведен. Более, чем достаточно.

3. Собственно по библиотекам. Наша вам точно не подойдет. Мы используем нормальный, квотированный обмен с устройством, и я извиняюсь, но так "не извращаемся", ибо в наших задачах все попроще. Но тем не менее, готовых библиотек много и ссылки на них я привожу ниже. Все бесплатные и хорошо описаны:

а) http://www.opencores.org/projects.cg...slave/overview - что поддерживает, видно из описания. Код на исходный текст в статье.
б) http://docs.sun.com/app/docs/doc/819...xfer-9f?a=view - с самой книге (PDF) все разжевано до нельзя со всеми примерами. Как стартовая точка, то, что надо.
в) http://techon.nikkeibp.co.jp/article...29/152601/?P=3 - описание общего принципа для работы с USB в плане embedded. Также очень полезно ознакомиться.
г) http://www.lvr.com/usb.htm - основной старт пункт для всех вопросов.
д) www.sourceforge.net/projects/easyusb - собственно сам драйвер с исходниками, со всеми режимами работы.
е) http://www.opensource.apple.com - Darwin hardware (IOKit) - не надо пугаться, что под Макинтош... я кучу этого кода уже для наших задач адаптировал. Там чистый С++, не более. А главное он хорошо документирован, что немаловажно.

Для начала думаю хватит. Что я точно не хочу делать, так это писать все... но если у вас будут конкретные затыки или проблемы с кодом, здесь пожалуйста.
И последнее: используйте не USB -> СОМ, а USВ -> RS-485 переходник. Не нужно включать дополнительное звено...

Добавлено через 17 минут
ПЫСЫ: А глюки на форуме продолжаются...

Первый раз послал ответ... сразу залип по сессии, пришлось перелогиниваться. Отрефрешился на страничке топика - ответа нет. Логин тоже слетел. Залогинился и вижу свой ответ в топике, но почему дважды и с разницей в 5 минут... Что за ерунда?

**KulibinV** · 05.12.2008, 20:05

Сообщение от RX1AL

Что конкретно не работает? Я не совсем понял... СОМ никогда не поддерживал isochronous transfer и поэтому как он может работать? Во-вторых, попытка взять на себя под ХР управление СОМ - чревата... так как в "исключительном режиме" невозможна по определению. А для того, чтобы работать, надо либо через P/Invoke, либо через wrapper драйвера. Хотя в С++ и есть функции для работы с СОМ, они не предоставляют "искличительного" режима доступа. Все идет через систему. А вам, такое не нужно, так как потеря лишнего времени на обработке.
?

Изохронные трансакции относятся к USB . Сттандартный сом может генерить прерывания ,
и под досом все работает . Под ХР посылки рваные ,т есть интервалы обмена гуляют .
[/QUOTE]

.

Сообщение от RX1AL

Начнём, помолясь... И сначала с того, что мне до сих пор непонятно, зачем такой огород городить для работы с датчиками на RS-485? У вас опрос 1 мс, а вы пытаетесь с ними работать, как с датчиками реального времени.

Почему? Да ответ на поверхности. Вы пишете, что в связке USB -> COM вам необходим isochronous USB transfer. Открываем документацию по USB 1.1 или 2.0 и читаем:

а) "Isochronous transfers occur continuously and periodically. They typically contain time sensitive information, such as an audio or video stream." - у нас вроде не видео и не аудио данные.
б) "Isochronous transfers provide stream pipe - unidirectional" - вопрос, а зачем нам двунаправленный канал? Мы лишь забираем данные от датчика.

Я не только опрашиваю контроллер датчика , но и должен не позже чем через
350Е-6 залить в него результаты обработки , той же разрядности

Сообщение от RX1AL

Кроме того, максимальный size data payload ограничен и развен 1023 (full speed device) и 1024 байта (high speed device), что тоже важно. Далее при работе в таком режиме при 1 мс такте, окно для снятия данных всего 250 мкс, согласно спецификации. Тоже критичная величина. Ну да ладно, хозяин - барин, хотя непонятно такое желание.

По спецификации (стр. 205), синхронизирующие посылки (Start Of Frame (SOF) packet each and every 1ms)
идут через 1 мс. Упрощенные варианты обработки собирают весь пакет между синхроимпульсами ,
заталкивают его в буфер и лишь потом с ним работают .
По крайней мере так было некоторое время назад. Вариантов когда CRC начинает автоматически
вычислятся отдельной аппаратной веткой при начале пакета и что бы после аппаратного обнаружения
конца пакета (укороченного) мне пока неизвестно . Следующий обмен инициируется только апппаратно
по началу SOF.

По крайней мере , это соответствует исследованию осциллографом обмена через драйвера FTDI

**KulibinV** · 06.12.2008, 11:55

Для RX1AL .
По одной из Ваших ссылок нашел указания на "правильные" драйвера.
Только похоже , что они не родные . По крайней мере там упоминается
аналогичная моей проблема с виртуальным СОМ портом .
Буду читать дальше . К сожалению там не просто на английском
(техническом), а на разговорном , с оборотиками .

**RX1AL** · 06.12.2008, 13:51

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

Касательно ссылки по драйверам и проблем с английским. Кидайте отрывок... переведу.

**KulibinV** · 06.12.2008, 19:25

Сообщение от RX1AL

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

Касательно ссылки по драйверам и проблем с английским. Кидайте отрывок... переведу.

Контроллер сам не справится (да и программировать больно мудрено
выходит ). Хотя задумка такая есть .
Сам буду переводить . Надо малость подучиться . А то одни даташиты
читать умею . Впрочем уже понял , что речь идет о микрософтовской программе
написания драйверов . Дорогая она .

**RX1AL** · 06.12.2008, 20:48

Для KulibinV:

Контроллер сам не справится"... - что за контроллер такой, что с простой задачей вычислений не справится? Уж всяко лучше решать это средствами контроллера, чем средствами самой системы. Насчет DDK, WDK и Kernel-Mode Driver Framework (KMDF). Ну кто вам сказал, что они стоят денег? Со сне приснилось?

Я вот ну никак не понимаю людей, которые не знают, но упорно считают, что они "понаслышке" правы - "денег стоит, дорогой"... Да бесплатно! Скачивайте за ради бога все, только зарегистрируйтесь на сайте у Микрософта:

1. http://connect.microsoft.com/ - основной вход.
2. http://www.microsoft.com/whdc/DevTools/default.mspx - все про WDK и так далее.
3. http://www.microsoft.com/whdc/driver/wdf/KMDF.mspx - Kernel-Mode Driver Framework.
4. http://forums.microsoft.com/MSDN/Sho...85068&SiteID=1 - Онлайн туториал.

Этого думаю будет более, чем достаточно. Надо будет чего еще, скажите.

**KulibinV** · 07.12.2008, 18:04

Сообщение от RX1AL

Для KulibinV:

Контроллер сам не справится"... - что за контроллер такой, что с простой задачей вычислений не справится? Уж всяко лучше решать это средствами контроллера, чем средствами самой системы. Насчет DDK, WDK и Kernel-Mode Driver Framework (KMDF). Ну кто вам сказал, что они стоят денег? Со сне приснилось?

Я вот ну никак не понимаю людей, которые не знают, но упорно считают, что они "понаслышке" правы - "денег стоит, дорогой"... Да бесплатно! Скачивайте за ради бога все, только зарегистрируйтесь на сайте у Микрософта:

1. http://connect.microsoft.com/ - основной вход.
2. http://www.microsoft.com/whdc/DevTools/default.mspx - все про WDK и так далее.
3. http://www.microsoft.com/whdc/driver/wdf/KMDF.mspx - Kernel-Mode Driver Framework.
4. http://forums.microsoft.com/MSDN/Sho...85068&SiteID=1 - Онлайн туториал.

Этого думаю будет более, чем достаточно. Надо будет чего еще, скажите.

dsPIC33.......
вопрос о быстродействии тонкий . Несмотря на то , что датчики дискретные ,
их разрядность напрямую превышает разрядность контроллера .
С учетом избежания проблем , PC работает (переменные выбраны) во float .
Чтоб обеспечить вычисления на контроллере , обработка данных во флоат (хоть его и
можно заявить , он эмулируется) не проходит по скорости - эксперементально
проверено .
Программу на контроллере можно написать в целочисленной арифметике , но так как
там используются приличные массивы , для экономии памяти данных (по програмной большой запас), придется мешать кучу типов - long, short и char причем последние
2 будут как unsigned так и signed . Заставить нормально работать эту мешанину
можно лишь путем очень длительной отладки .
Расчет на потребность (размер внутренненго ОЗУ) я делал , проходит только в варианте
такой каши .