Cómo desarrollar y probar controladores de dispositivos en Windows CE 5.0
Este artículo describe cómo desarrollar y probar controladores de dispositivos Windows CE 5.0. Este artículo paso a paso describe cómo crear un controlador de transmisión, cómo crear una prueba personalizada del kit de prueba de Windows CE
(CETK) y cómo escribir una aplicación para probar el controlador. Esto tarda aproximadamente 60 minutos en completarse.
Contenido de esta página
Parte 1: Creación del controlador del dispositivo
Parte 2: Prueba del código de prueba del controlador de transmisión
Tercera parte : Verificación del controlador
Parte cuatro: uso
Kit de prueba de Windows CE
Parte cinco: creación de una prueba CETK personalizada
p>
Parte 6: Determinar quién es el propietario del controlador Stream
Resumen
Parte 1: Crear el controlador del dispositivo
En este ejercicio, utilizará Platform Builder para agregar el proyecto como controlador de dispositivo.
Antes de comenzar a escribir un controlador, debe comprender el propósito de un controlador de dispositivo. Los controladores abstraen el hardware subyacente del sistema operativo, haciéndolo más accesible para los desarrolladores de aplicaciones. Los desarrolladores de aplicaciones no necesitan
conocer los detalles del hardware de visualización o del hardware serie; por ejemplo, si el dispositivo serie se implementa mediante un receptor/transmisor asíncrono universal (UART)
o utilizando una matriz de puertas programables en campo (FPGA)
implementada. En la mayoría de los casos, los desarrolladores de aplicaciones no necesitan saber en absoluto cómo se implementa el hardware.
Microsoft Windows expone interfaces de programación de aplicaciones
(API) para que los desarrolladores llamen al hardware sin necesidad de conocer el hardware físico. Por ejemplo, para escribir datos en un puerto serie, un desarrollador de aplicaciones simplemente llama a CreateFile( ) en COMx (donde x
representa el número de puerto serie que desea abrir, por ejemplo, COM1 representa el puerto serie 1). luego llame a WriteFile() para escribir algunos bytes de datos en el puerto serie y luego llame a
CloseHandle() para cerrar el puerto serie. Independientemente del hardware serie subyacente (y del sistema operativo Windows que esté ejecutando), las API se ejecutan en el mismo orden.
Lo mismo se aplica a otras API: si desea dibujar una línea en la superficie de visualización, simplemente llame a PolyLine( ), MoveToEx( ) o LineTo(
). . Como desarrollador de aplicaciones, la mayoría de las veces no necesita conocer el hardware de la pantalla. La API llamada aquí devolverá las dimensiones de la superficie de visualización, la profundidad del color, etc.
La buena noticia es que los desarrolladores pueden llamar a un conjunto consistente y conocido de API. Estas API
abstraen sus aplicaciones del hardware subyacente. Esto es fundamental porque los desarrolladores de aplicaciones no tienen forma de saber si la aplicación se está ejecutando en una computadora portátil, una tableta
o una computadora de escritorio. Ya sea que la computadora esté funcionando con una resolución de 1024 × 768 o 1600 × 1200, los desarrolladores de aplicaciones pueden consultar la resolución de la pantalla y la profundidad del color en tiempo de ejecución, por lo que no es necesario crear programas que solo se ejecuten en un hardware específico. aplicación.
El controlador es sólo una biblioteca de vínculos dinámicos (DLL).
Carga la DLL en el espacio de direcciones del proceso principal; luego, el proceso principal puede llamar a cualquier interfaz expuesta desde la DLL. Normalmente, el proceso principal carga el controlador llamando
LoadLibrary( ) o LoadDriver( ). LoadDriver no solo carga la DLL en el espacio de direcciones del proceso principal, sino que también garantiza que la DLL no se "pagina".
¿Cómo sabe el proceso de llamada qué API o funciones están expuestas desde su DLL o controlador? El proceso principal llama a GetProcAddress(), que obtiene el nombre de la función y hInstance de la DLL cargada. La llamada devuelve un puntero de función si la función existe, o NULL si la función no está expuesta desde la DLL.
El controlador de transmisión también expone un conjunto de funciones bien conocido. Para un controlador de transmisión, querrá poder escribir una secuencia de bytes en el dispositivo o leer una secuencia de bytes desde el dispositivo. Por lo tanto, en el ejemplo del puerto serie usado anteriormente, es posible que desee exponer el siguiente conjunto de funciones de su controlador: Abrir, Cerrar, Leer
y
Escribir. Los controladores de transmisión también exponen algunas otras funciones: PowerUp, PowerDown, IOControl, Init
y DeInit.
Puedes utilizar una imagen del sistema operativo existente con la plataforma del emulador (la plataforma Basic Lab MyPlatform es ideal). Luego puede agregar
proyectos DLL/controladores a la plataforma.
Después de haber creado y descargado la plataforma (lo que indica que el sistema operativo está funcionando correctamente), debe crear su controlador troncal. Puede crear una DLL de Microsoft Windows CE utilizando el comando Plataforma
Creador de nuevo proyecto o archivo en el menú Archivo. No hay diferencia entre crear una DLL que expone funciones o recursos y crear una DLL que funciona como controlador; las únicas diferencias son qué funciones expone la DLL y cómo se registra o utiliza la DLL en la plataforma.
Además, una forma de crear una aplicación internacionalizada es crear primero una aplicación base con un conjunto básico de cadenas de idioma, cuadros de diálogo y recursos, y luego crear muchas
DLL externas. , cada uno de los cuales contiene cuadros de diálogo, cadenas y recursos para una ubicación específica. Luego, la aplicación puede cargar los recursos de idioma correspondientes en tiempo de ejecución. Puede agregar un idioma a su aplicación simplemente agregando un archivo DLL
. Los temas relacionados con este y algunos otros temas interesantes se describen en el libro Developing International
Software, que está disponible en el sitio web de Microsoft Press.
Agregar un proyecto como controlador de dispositivo
Abra un espacio de trabajo de MyPlatform existente con Platform Builder.
En el menú Archivo, haga clic en Nuevo proyecto o Archivo.
Seleccione la biblioteca de vínculos dinámicos WCE, asígnele un nombre apropiado (por ejemplo, StreamDrv) y haga clic en
Aceptar, como se muestra en la imagen siguiente.
Complete parte de la información que necesita en la página que se muestra a continuación y luego haga clic en Siguiente.
Haga clic en Un proyecto DLL simple de Windows CE, como se muestra en la siguiente figura.
Haga clic en Finalizar para completar el asistente.
En este punto, la DLL solo contiene una función DllMain vacía
. Puede exponer algunas funciones a las que llama su aplicación y exponer algunos recursos (quizás haciéndolos parte de una aplicación que reconoce el idioma/cultura) o convertirlo en un controlador de dispositivo. En este artículo, utilizará el
Asistente del controlador de transmisión de Windows CE para crear su controlador de transmisión troncal.
En Windows CE, abrir un controlador de secuencia es como abrir un archivo con un prefijo único de tres letras (por ejemplo, COM).
Elija un identificador único de tres letras para su conductor. Ingrese la ruta completa al controlador de transmisión que creó anteriormente en el cuadro Ubicación
. O utilice el botón "examinar" para navegar hasta el directorio PBWorkspaces
en su instalación de Platform Builder, busque la plataforma que creó anteriormente y luego busque el nombre del controlador de transmisión (en el ejemplo anterior, esta ruta era PBWorkspaces\TuxPlat\StreamDrv).
Ingrese el nombre del controlador en el cuadro Nombre de archivo del controlador. Como se muestra en la imagen a continuación, use el mismo nombre que usó anteriormente (StreamDrv)
para asegurarse de que se sobrescriba el archivo original creado en Platform Builder.
Presione Ir y se generará el código fuente del controlador de transmisión.
Volver al principio
Parte 2: Prueba del código de prueba del controlador Stream
Ahora que ha escrito un controlador de flujo personalizado para el código básico de Windows CE. En este punto, el controlador aún no está conectado a ningún hardware.
Después de escribir el controlador, debe proporcionar una forma para que los desarrolladores lo prueben. Windows CE viene con el kit de prueba de Windows CE
(CETK), que proporciona pruebas de controladores para varios tipos de controladores, incluida la conectividad de red, Bluetooth, puertos serie y pantalla. El controlador que escribió es un controlador de transmisión personalizado que no expone la misma funcionalidad que las pruebas de controlador existentes, por lo que necesita escribir una prueba personalizada para el controlador. Si bien definitivamente podría escribir una aplicación para ejercitar el controlador, podría ser mejor proporcionar un módulo CETK que pueda usarse durante el desarrollo y que también esté disponible para que los clientes lo utilicen durante el desarrollo. el hardware ensamblado.
En esta parte del ejercicio, realizará el siguiente proceso:
Crear un módulo troncal Tux
Agregar el código de prueba del controlador personalizado a la DLL de Tux Medio
Reconstruir el sistema operativo
Establecer puntos de interrupción
Crear el módulo troncal Tux
En Platform Builder, haga clic en el menú Archivo Haga clic Nuevo proyecto o archivo.
Seleccione WCE TUX Dynamic-Link Library, escriba TuxTest como nombre del proyecto, ingrese una ubicación, haga clic en
Proyecto de espacio de trabajo y luego haga clic en Aceptar, como se muestra en la imagen a continuación. (En realidad, puede elegir cualquier tipo de proyecto; para este artículo, haga clic en
Proyecto de espacio de trabajo).
Complete parte de la información que necesita en la página que se muestra a continuación y luego haga clic en Siguiente.
Lea la información en la pantalla que se muestra a continuación y luego haga clic en Siguiente.
En la última página, puede optar por seleccionar
CETK en Tipo de versión, como se muestra en la imagen a continuación. Esta opción desactiva ciertas optimizaciones binarias para mejorar la eficiencia de la depuración. Haga clic en Finalizar.
Haga clic en Ver | Vista de archivo y luego expanda el árbol de Proyectos para mostrar el código fuente de tux
, como se muestra a continuación.
Los archivos importantes a tener en cuenta en la figura anterior son:
ft.h: este archivo contiene la tabla de funciones utilizada por la DLL de tux.
test.cpp: este archivo contiene procedimientos de prueba llamados desde esta tabla de funciones.
TuxStreamTest.cpp: este archivo contiene DLLMain y ShellProc, el último de los cuales se llama desde Tux.exe
.
Agregue código de prueba de controlador personalizado a la DLL de Tux
Abra el código fuente Test.cpp.
Utiliza CodeClip para obtener el código fuente de Tux_Custom_Test |
Reemplaza el contenido en la función TestProc con el código en CodeClip.
Notarás que el código en Test.cpp carga un controlador llamado Demo.dll. Para este artículo, creó un controlador llamado StreamDrv
. Debe modificar el código fuente para cargar el controlador StreamDrv.dll.
Ubique la ubicación del código fuente que llama a LoadLibrary en Test.cpp y luego cambie el nombre del controlador que se cargará de Demo.dll
a StreamDrv.dll.
En la vista de archivos de Platform Builder, haga clic derecho en el proyecto TuxTest y haga clic en Crear proyecto actual
.
También deberá agregar los componentes del kit de prueba de Windows CE desde este directorio.
En Controladores de dispositivo, ubique el componente del kit de prueba de Windows CE en el directorio y seleccione
Agregar el kit de prueba de Windows CE para agregar el componente a su plataforma.
Nota: Agregar este componente a su plataforma no agrega ningún archivo a la imagen final del sistema operativo; agrega los archivos del lado del cliente a la carpeta de versión de compilación
. Puede descargar la aplicación Clientside desde Platform Builder y ejecutar la aplicación en el dispositivo de destino.
Ahora necesitas reconstruir tu sistema operativo para incorporar estos cambios.
Reconstruir el sistema operativo
En Platform Builder, seleccione Build OS |
El proceso de construcción tardará aproximadamente 5 minutos en completarse.
Es útil establecer un punto de interrupción en el punto de entrada del controlador de flujo para observar cuándo se carga el controlador.
Establecer puntos de interrupción
Haga clic en Vista de archivos, abra el proyecto StreamDrv y luego abra los archivos de origen.
Localiza y abre StreamDrv.cpp.
Ubique DllMain, luego busque y haga clic en la instrucción de cambio.
Presione F9 para establecer un punto de interrupción.
Haga clic en Destino | Adjuntar para descargar el sistema operativo al entorno de simulación.
Verá el siguiente resultado de depuración y se habilitarán los puntos de interrupción. Tenga en cuenta que esto sucede mucho antes de que se cargue la interfaz de usuario (UI) del sistema operativo.
4294780036 PID: 23f767b6 TID: 23f767e6 0x83fa6800: gt;gt;gt; Cargando módulo
streamdrv.dll en la dirección 0x01ED0000-0x01ED5000
Símbolos cargados para
'C:\WINCE500\PBWORKSPACES\DRVDEMO\RELDIR\EMULATOR_X86_DEBUG\STREAMDRV.DLL'
Haga clic en la instrucción switch y presione F9 para deshabilitar el punto de interrupción.
Presiona F5 para permitir que el sistema operativo continúe cargándose.
Ahora que ha creado un sistema operativo Windows CE 5.0 que contiene un controlador de secuencia personalizado y ha visto el controlador durante la secuencia de inicio del sistema operativo, se carga el programa.
Volver al inicio
Parte 3: Verificación del conductor
En esta parte de los ejercicios, realizarás los siguientes procedimientos:
Utilice herramientas de línea de comandos para ver las funciones expuestas desde el controlador
Utilice la herramienta Información remota del sistema para verificar el controlador
Asegúrese de que el controlador esté cargado
La primera forma de verificar el controlador de dispositivo que creó es observar las funciones expuestas en el controlador. Windows CE viene con una herramienta de línea de comandos llamada Dumpbin
que puede usarse para verificar el contenido importado a una aplicación o módulo, o exportado desde una DLL (o controlador).
Utilice herramientas de línea de comandos para ver las funciones expuestas desde el controlador
En Platform Builder, haga clic en Build OS | Open Release
Directorio. Esta acción abre la ventana del símbolo del sistema en la carpeta de lanzamiento de compilación para el espacio de trabajo actual.
Escriba dumpbin exports StreamDrv.dll
El resultado se muestra en la imagen siguiente. Puede ver que todas las funciones requeridas del controlador de transmisión están expuestas desde el controlador; las funciones están expuestas desde la DLL (a través del archivo .def del proyecto).
Escriba Salir para cerrar la ventana del símbolo del sistema
El contenido del archivo StreamDrv.def se muestra a continuación.
LIBRARY DemoDriver
EXPORTACIONES
DEM_Init
DEM_Deinit
DEM_Open
DEM_Close
DEM_IOControl
DEM_PowerUp
DEM_PowerDown
DEM_Read
DEM_Write
DEM_Seek
CustomFunction
CustomFunctionEx
La segunda forma de verificar un controlador es a través de la herramienta Información remota del sistema.
Verifique el controlador con la herramienta Información del sistema remoto
En Platform Builder, haga clic en Herramientas | Sistema remoto
Información.
Seleccione Plataforma predeterminada de Windows CE | Dispositivo predeterminado y haga clic en
Aceptar, como se muestra en la siguiente figura.
Este proceso conecta la aplicación Información remota del sistema a la plataforma actualmente activa que utiliza Platform Builder. La siguiente imagen muestra los resultados.
También puede utilizar la lista de módulos cargados para determinar que su controlador se ha cargado.
Asegúrese de que el controlador esté cargado
En Platform Builder, use la ventana Target Control (gi mod) o Ver |
Depurar módulos y símbolos de Windows |
La siguiente imagen muestra los resultados de este proceso.
Volver al principio
Parte 4: Uso del kit de prueba de Windows CE
El kit de prueba de Windows CE incluye componentes del lado del dispositivo y componentes de escritorio. El componente del lado del dispositivo se llama Clientside.exe y puede agregar el componente del lado del dispositivo a su espacio de trabajo agregando el componente CETK
desde el directorio. Tenga en cuenta que agregar la aplicación Clientside.exe
al espacio de trabajo no agrega ningún archivo a la imagen final del sistema operativo, pero sí copia la aplicación a la carpeta de lanzamiento de compilación.
Antes de ejecutar CETK en una computadora de escritorio, debe iniciar la aplicación Clientside.exe en el dispositivo. La razón por la que no hay herramientas vinculadas (como Remote Tools) es que CETK
también se ejecutará en dispositivos de ensamblaje (minoristas) (como Pocket PC).
En esta sección de los ejercicios, realizará los siguientes procedimientos:
Examinar la interfaz de usuario del kit de prueba de Windows CE
Ejecutar una prueba estándar
Verifique la interfaz de usuario del kit de prueba de Windows CE
En Platform Builder, en el menú Herramientas, haga clic en Kit de prueba de Windows CE
.
Este paso inicia la aplicación Windows CE Test Kit, como se muestra en la siguiente figura. Tenga en cuenta que esta no es una herramienta remota estándar. La mayoría de las herramientas remotas incluidas con Windows CE utilizan la capa de transporte independiente del kernel (KITL), un transporte que abstrae las herramientas del hardware de comunicaciones subyacente para que las herramientas puedan ejecutarse a través de Ethernet, puerto serie, 1394, USB u otro transporte.
Aunque a partir de Windows CE 5.0, el kit de prueba de Windows CE normalmente se conecta a través de sockets, las herramientas se han actualizado para admitir KITL.
En el Kit de prueba de Windows CE, haga clic en Conexión | Iniciar
Cliente.
Este paso muestra el cuadro de diálogo Conexión del dispositivo, donde puede elegir si desea conectarse a través de un enchufe o KITL.
Asegúrese de que la casilla de verificación Usar Windows Sockets para la comunicación cliente/servidor
esté desactivada, como se muestra en la imagen a continuación.
Haz clic en Conectar.
En la interfaz de usuario estándar de Herramientas remotas (KITL), seleccione Plataforma predeterminada de Windows CE | Predeterminado
Dispositivo y haga clic en Aceptar, como se muestra en la siguiente imagen.
Este proceso inicia Clientside.exe en el dispositivo de destino y se conecta al dispositivo de destino. Después de completar la conexión, CETK enumera los dispositivos compatibles en la plataforma de destino y desactiva los dispositivos que no son compatibles con CETK
.
Después de que CETK se conecta al dispositivo de destino y enumera el dispositivo, la interfaz de usuario se parece a la imagen a continuación. Tenga en cuenta que algunas clases de hardware están deshabilitadas, como Bluetooth, puerto IR
y módem.
Antes de agregar una prueba personalizada a CETK, puede ejecutar una prueba estándar para ver cómo funciona.
Ejecutar pruebas estándar
En CETK, expanda Windows CE (x86).
Busca y expande Puerto serie.
Haga clic con el botón derecho en Prueba del controlador del puerto serie y haga clic en Inicio rápido.
Este paso solo ejecuta esta prueba y aún no ha ejecutado las otras pruebas seleccionadas. La interfaz de usuario indica que la prueba está en progreso, como se muestra en la imagen a continuación.
CETK proporciona actualizaciones del proceso de prueba y de los resultados de la prueba. También puede examinar el resultado de la depuración en Platform Builder para ver el progreso de la prueba, como se muestra en el siguiente ejemplo.
405910 PID: 83d4ee4a TID: 83ea5a8a *** Nombre de la prueba: establezca la máscara del evento y espere a que
el hilo cierre el identificador del puerto de comunicaciones
405920 PID: 83d4ee4a TID: 83ea5a8a *** ID de prueba: 1007
405920 PID: 83d4ee4a TID: 83ea5a8a *** Ruta de biblioteca: \serdrvbvt.dll
405920 PID: 83d4ee4a TID: 83ea5a8a ** * Línea de comando:
405920 PID: 83d4ee4a TID: 83ea5a8a *** Resultado: Aprobado
405920 PID: 83d4ee4a TID: 83ea5a8a *** Semilla aleatoria: 15595
405930 PID: 83d4ee4a TID: 83ea5a8a *** Número de subprocesos: 1
405930 PID: 83d4ee4a TID: 83ea5a8a *** Tiempo de ejecución: 0:00:05.110
405930 PID :83d4ee4a TID:83ea5a8a ***
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Si CETK UI
Indica simulación Si el Las pruebas del puerto serie en el servidor han fallado (como se muestra en la imagen a continuación), entonces es posible que la falla no se deba a una falla completa de cada prueba. Puede indicar que solo una parte de todo el conjunto de pruebas ha fallado y que esta parte es en realidad el comportamiento esperado.
Haga clic con el botón derecho en Prueba del controlador del puerto serie [Error] y haga clic en Ver
Resultados.
Aparece la ventana que se muestra a continuación.
Al observar los resultados que se muestran arriba, puede ver que se han ejecutado 10 pruebas distintas. Todas estas pruebas han pasado excepto Establecer y verificar el tiempo de espera de recepción
.
Para más información, puedes hacer clic en pruebas individuales.
Volver al principio
Parte 5: Creación de una prueba CETK personalizada
Puede crear una CETK personalizada utilizando el asistente de prueba definido por el usuario de Platform Builder
Prueba. Esta prueba verificará las funciones exportadas del controlador de transmisión personalizado (que también agregó a la plataforma).
En esta parte del ejercicio, realizará el siguiente proceso:
Enumerar pruebas de controladores de transmisión personalizados en CETK
Ejecutar pruebas de programa de controladores de transmisión personalizados
Enumerar pruebas de controladores de flujo personalizados en CETK
En CETK, haga clic en Pruebas | Definidas por el usuario.
Este paso inicia el Asistente de prueba definido por el usuario. La primera página del asistente es solo información.
Haga clic en Siguiente como se muestra a continuación.
Haga clic en Agregar una nueva prueba y luego haga clic en Siguiente, como se muestra en la imagen a continuación.
Ingrese la siguiente información y luego haga clic en Siguiente:
· Escriba Custom Stream Driver Test en el cuadro Nombre de la prueba
· En el módulo Tux (DLL ), navegue hasta el directorio
C:\Wince500\PBWorkspaces\MyPlatform\RelDir\Emulator_x86_Debug y seleccione
test.dll o TuxTest.dll (dependiendo de dónde se encuentre en Platform Constructor El nombre de la prueba Tux
utilizada).
· En el cuadro Línea de comando, deje la configuración predeterminada para la prueba actual.
·Escriba x86 en el cuadro Procesador
La siguiente imagen muestra cómo aparece la información en la página actual del asistente.
Haga clic en Copiar los archivos al directorio para pruebas definidas por el usuario y luego haga clic en
Siguiente, como se muestra en la imagen siguiente.
Debe copiar la prueba del controlador personalizada (su DLL) en la carpeta de prueba definida por el usuario. Si elimina un espacio de trabajo existente, las pruebas de controladores personalizadas permanecen intactas.
Haga clic en Siguiente como se muestra a continuación.
Haga clic en Finalizar, como se muestra en la siguiente figura.
Las aplicaciones CETK no se actualizan automáticamente con nuevas pruebas. Debe volver a sincronizar la aplicación de escritorio para ver las pruebas recién agregadas.
Haga clic derecho en Windows CE (x86) y haga clic en Redetectar periféricos.
Este procedimiento agrega una nueva categoría de controlador llamada Pruebas de usuario. Solo agregó una prueba, por lo que cuando expande el proyecto, solo verá la Prueba personalizada
del controlador de transmisión.
Tenga en cuenta que la DLL para la prueba del controlador de flujo personalizado se ha copiado en la siguiente ubicación: C:\Program Files\Windows CE Platform
Builder\5.00\CEPB\wcetk\user \x86 .
Ejecute una prueba de controlador de transmisión personalizada
Expanda Pruebas de usuario en la lista de pruebas disponibles.
Haga clic con el botón derecho en Prueba del controlador de transmisión personalizada y haga clic en Inicio rápido.