07-01-2009, 16:46
hola a todos, estoy en un proyecto y me he quedado a cuadros cuando me han dicho que tendria que hacer un programilla tipo speedfun es decir que tiene que poder subir y bajar el fbs el multiplicador .... y no tengo ni idea de la fuente donde se guarda dicha informacion para poder tocarla, es decir, como se programaria una bios por ejemplo ??
espero haberme explicado bien si no responderé a cualquier duda
por cierto tiene que ser para windows :S
saludos y gracias
Buenas! La forma de enfocar un problema hardware de este tipo se basa en conocer previamente la arquitectura de éste.
En un sistema basado en microprocesador (como puede ser un PC), tenemos 3 conjuntos básicos: Procesador, Memoria, y Entrada/Salida. Estos tres conjuntos se encuentran conectados entre si mediante buses.
La forma de acceder a cada conjunto se hace mediante instrucciones del procesador que acceden a cierta dirección de memoria, es decir, se trata de ejecutar una instrucción del procesador que hará que ponga dicha dirección en el bus de direcciones y éste recibirá por su bus de datos el resultado de dicho acceso (si es una lectura).
Basicamente tienes que conocer la forma en que gestiona la E/S del sistema en cuestión. Eisten 2 tipos:
1º E/S Mapeada en memoria
2º E/S independiente
Para el primer caso, tenemos una arquitectura típica de procesadores Motorola, y para la segunda típica de procesadores Intel. La diferencia principal entre ambas es que en la E/S independiente se crean dos mapas de memoria virtualmente distintos, es decir, tenemos un mapa de memoria para almacenar direcciones de memoria principal y otro para almacenar direcciones de memoria referidas a periféricos. Para la E/S mapeada en memoria, tenemos un mapa de memoria único el cual se divide en dos partes y la forma de distinguir si se accede a memoria principal o a periférico es exclusivamente por el rango de dirección al cual se accede. Así por ejemplo, en los procesadores Intel para acceder a los módulos de E/S se utilizan instrucciones tipo In/out del juego de instrucciones del procesador. (Por ejemplo hacer OUT 378h,00h accedería a la posicion 378h del mapa de memoria de la E/S y escribiría un 00h en el contenido de esa posición, y si haces MOV EAX,[378h] lo que harías sería acceder a la dirección 378h de la memoria principal, que puede ser por ejemplo la RAM, y el contenido de esa dirección de memoria almacenarlo en el registro EAX del procesador), es decir, tenemos dos direcciones 378h en este tipo de arquitecturas.
La cuestión por tanto a tu pregunta consiste en saber el tipo de gestión que realiza el sistema (E/S independiente o mapeada en memoria), la cual te determina el tipo de instrucción a ejecutar del juego de instrucciones del procesador, y una vez lo sepas, saber la dirección de memoria a la que quieres acceder. En el ejemplo: OUT 378h, 00h en una arquitectura Intel, dicha dirección corresponde al registro de datos del puerto paralelo del sistema, es decir, estamos escribiendo un caracter NULO, en el registro de datos del puerto LPT1.
Ahora bien con ésto no lo tenemos todo... Si el programa que pretendes realizar se ejecuta sobre un sistema operativo sin protección no habrá inconvenientes. Sin embargo los problemas que te podrás encontrar es que si el programa se va a ejecutar sobre un sistema operativo con protección basada en capas o anillos, tal vez dicha protección no te deje acceder directamente al hardware desde una capa o anillo superior, como ocurre por ejemplo en el caso de Windows (a partir de la versión 95/98/ME). La solución es ver por tanto cómo hace el sistema operativo para acceder a dicho hardware. En el caso de Windows o Linux (que si poseen esta protección basada en anillos), es mediante un driver, el cual se ejecuta en modo kernel (o anillo 0).
Otra cuestión a plantear es la forma en la que se acceden a los perifericos. Existen 3 tipos:
1º E/S Programada
2º E/S Mediante interrupciones
3º E/S Mediante DMA.
La primera utilizada sólo en sistemas operativos monotarea, como DOS, sólo tendrás que hacer lo comentado anteriormente (instrucción del procesador y dirección de memoria del dispositivo a acceder).
La segunda, y tercera, utilizadas en sistemas multitarea (actuales). Puedes optar por una o por otra, según el caso. Mediante interrupciones lo que hacemos es esperar a que se suceda cierto evento en el dispositivo (como puede ser la escritura externa de un byte o de un registro). Cuando dicho evento sucede, el periférico activa una linea de interrupción hardware que tiene programada por el fabricante y la arquitectura. Dicha linea recibe el nombre de IRQ, y se encuentra almacenada en un controlador programable de interrupciones (para el caso de la arquitectura Intel el PIC 8259, maestro y esclavo conectados en cascada, lo cual da un total de 16 lineas de interrupcion IRQ). Así por ejemplo el disco duro, o más concretamente la controladora IDE posee asociada las lineas 14 y 15 de IRQ, correspondientes a IDE1 e IDE2.
Usando interrupciones lo que se hace en la aplicación o en el programa es realizar una espera activa, algo como "while(1) o for( ; ; )", en espera de que se active la interrupción. Cuando se produzca, el programa obtendrá el vector de interrupción mediante por ejemplo la función "getvect(...)", y cederá el flujo de ejecución al comienzo de dicha rutina. Cuando esta rutina finalice, volverá a su ejecución normal (el procesador continua ejecutando lo que estaba haciendo antes de la interrupción).
Los vectores de interrupción estandar, se encuentran almacenados en las posiciones bajas de memoria principal (para arquitecturas Intel). Dichos vectores no son mas que direcciones de memoria que apuntan al comienzo de cada rutina de interrupción. Estos vectores se inicializan durante la carga del sistema operativo. No obstante es posible modificar dichos vectores (dichas posiciones de memoria o "punteros"), por otros establecidos por el usuario, es decir, es posible que el usuario pueda crear su propia rutina de interrupción y sustituirla por la estandar del sistema operativo. Para ello se puede usar por ejemplo la función setvect(...) de C.
Evidentemente esto supondría un grave problema de seguridad para el sistema, ya que un usuario malintencionado puede sustituir un vector de interrupción por otro que apunta a una rutina malvada la cual se ejecutará cuando el periférico genere su interrupción por su linea IRQ asociada. (lo que antiguamente se conocia como bombas lógicas). Actualmente esto también se encuentra gestionado por el núcleo del Sistema operativo debido a la arquitectura basada en anillos, es decir, sería necesario realizar un driver para su implementación.
La tercera opción comentada, mediante DMA, consiste en que cuando el dispositivo genera la interrupción por su línea IRQ, el procesador en vez de realizar la transferencia de datos, lo que hace es programar un controlador DMA (en arquitecturas Intel es el controlador 8237), el cual se encarga de adueñarse del bus (operación conocida como bus mastering), y realizar la transferencia, dejando totalmente libre al procesador para que continue con su tarea. Este tipo de mecanismo se realiza cuando la transferencia de datos es muy grande, por ejemplo para el acceso a disco.
La programación tanto del controlador programable de interrupciones (PIC), como del controlador DMA, se hace mediante instrucciones in/out (si es de Intel), y la dirección de memoria donde se encuentran mapeados dichos controladores.
Si lo vas a hacer en C, puedes usar instrucciones tipo: importb, outportb (para la lectura y escritura de bytes o caracteres), pero recuerda que el programa logrará ejecutarse satisfactoriamente, es decir, sin lanzar ninguna excepción siempre y cuando el sistema operativo sobre el que se ejecuta no posea proteccion basada en anillos (como windows o linux). En caso contrario, deberás programar un driver en modo kernel para poder realizar la tarea.
Un saludo.
juas! juas!! gracias por la rapidez !!!
me has aclarado muchas cosas pero vaya percal ...
el driver en modo kernel que comentas ya tiene que estar hecho por algún lado aunque sea de pago supongo, la cosa es encontrarlo porque si tengo que crearlo yo y luego currarme el dichoso programa no termino para la fecha ni en broma
esta noche me pongo a buscar más sobre lo que comentas, juraria haver leido algo parecido en una guia que curiosamente al buscarla y abrirla esta hecha por ti
MUCHISIMAS GRACIAS por tu respuesta larga y muy comprensible haciendo facil lo dificil asi da gusto, un diez
saludos !!
De nada. El enlace a http://logix4u.net/inpout32_source_and_bins.zip que me has mandado por privado, es un driver muy utilizado y socorrido, que te puede servir perfectamente para tu cometido.
El único inconveniente de utilizar este tipo de mecanismos de IN/OUT es que no es viable cuando se trata de dispositivos plug&play, ya que los recursos, tales como IRQ's, canales DMA, etc... son asignados dinámicamente, tal y como ocurre por ejemplo con dispositivos USB.
Un saludo y suerte
Última edición por hystd; 08-01-2009 a las 21:45
Genial, muchas gracias, si al final sale algo decente ya iré poniendo cosillas y seguro que alguna preguntilla más.
Se trataría de tener un único programa para que diga todo el hardware del ordenador y además que puedas hacer overclock desde él sin necesidad de tener mil programas abiertos, si me da tiempo incluso poner benchs en la sección de graficas......
aunque lo veo algo complicado para hacerlo yo sola no se porqué me meto yo en estos follones creo que es el trabajo de sintesi más complicado .. en fin....
me gustaría saber tu opinión crees que es muy complicado para terminarlo en abril??
un saludo
Para generar una lista con todo el hardware del sistema no hace falta complicarse mucho la vida... Piensa que el Sistema operativo debe conocer ya todo el hardware instalado para que pueda funcionar, si esto es así, ¿por qué no preguntarselo y que nos lo diga?
En el caso de Windows, tienes toda esta información guardada en el registro. En concreto en la ruta: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum, tienes toda una lista con interfaces (que son las subcarpetas que aparecen), y cada uno de los dispositivos conectados a esa interfaz. Para obtener el nombre de estos dispositivos (fabricante y modelo), tienes dos opciones: acudir a la clave "DeviceDesc" que contiene una cadena con la descripción del hardware, o bien, obtener el identificador del Vendedor y Producto y traducirlo bajo una cadena propia. Las que crea el sistema operativo por defecto (las que aparecen en "DeviceDesc" se encuentran almacenadas en un fichero denominado "machine.inf", el cual contiene una lista de identificadores y su traducción a cadena legible "a nivel humano".
Un ejemplo sencillo con mi portatil:
Me dirijo a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum, y voy a listar por ejemplo, dispositivos USB conectados...
Me voy a: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB y allí enumero y accedo las subcarpetas... en concreto para mi equipo se obtendría:
Si accedemos por ejemplo al dispositivo con idVendor=05a9 e idProduct=a511, (la que he señalado en azul) y accedemos al contenido (para este dispositivo sería la ruta: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB\Vid_05a9&Pid_a511\5&1a8de16f&0&2\), y leemos la clave: "DeviceDesc", se observa la siguiente cadena: "Video Blaster WebCam 3 USB (WDM)". Que efectivamente corresponde a mi WebCam Creative. Dicha cámara posee un microcontrolador OV511+ de Omnivisión. Se puede comprobar en la lista de identificadores para el estandar USB, y que puedes consultarla aquí: http://www.linux-usb.org/usb.ids). Para el caso de USB, estas cadenas son extraidas de los descriptores de cadena de los dispositivos USB, los cuales se almacenan en una estructura de datos, junto a otros descriptores (como pueden ser el de dispositivo, el de configuraión, interfaz y endpoint), y forman el código grabado en el microcontrolador del dispositivo (el firmware). Los descriptores de cadena "String Descriptors", son aquellos que se transmiten por el endpoint0 de control al HOST (sistema), cuando éste hace una petición de obtención de descriptores "GET_DESCRIPTOR", y son los que aparecen en un mensaje de globito en la bandeja del reloj, es decir, cuando metes por ejemplo un pen drive en un puerto USB, y aparece un mensajito en el systray diciendo "nuevo hardware encontrado", "dispositivo de almacenamiento blablabla" => este último es ya un descriptor de cadena.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB\ROOT_HUB
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB\ROOT_HUB20
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB\Vid_046d&Pid_c040
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB\Vid_05a9&Pid_a511
etc...
Esto mismo que hacemos para la interfaz USB, puedes hacerlo para otra subcarpeta (interfaz), disitnta, PCI, IDE, ACPI, HID, etc... y así obtener una lista completa y detallada (incluso obtener el driver asociado, configuraciones, etc...) de todo el hardware instalado del sistema.
Creo que esta forma de obtener información física del sistema es mucho más eficiente, segura y elegante que intentar interrogar a cada uno de los dispositivos instalados en busca de respuestas. A la vez que sencillo de implementar en nuestra aplicación, ya que acceder al registro se basa en hacer llamadas al sistema mediante funciones de la API WIN32 contenidas en la librería "Advapi32.dll", tales como: RegCreateKey, RegCloseKey, RegEnumKey, etc... Tienes un listado de la especificación y uso de cada una de ellas en la MSDN: http://msdn.microsoft.com/en-us/library/ms724875(VS.85).aspx de Microsoft.
En cuanto al tema de hacer funciones benchmark para tu programa, los consejos que te doy son los siguientes:
Lo más importante es saber que.. TU PROGRAMA NO ES LO ÚNICO QUE SE ESTÁ EJECUTANDO EN EL SISTEMA... esto quiere decir que las mediciones pueden ser erroneas en el sentido de que al ser un sistema operativo multitarea el que está ejecutando la aplicación, puede que durante una medición de tiempo el sistema operativo hiciese un cambio de contexto hacia otra aplicación o programa en ejecución, lo cual invalidaría la prueba.
Para intentar solucionar este problema, lo recomendable es intentar que la rutina de medición sea lo más corta posible, para ello mis recomendaciones son:
1º Escribir dicha rutina en ensamblador
2º Establecer un nuevo hilo de ejecución para efectuar dicha medición
3º Asignarle máxima prioridad a dicho hilo.
Existen instrucciones propias del procesador que te permiten medir tiempos utilizando el contador interno de éste (el Time Stamp Counter o TSC). Dicha instrucción es RDTSC, la cual lee el contenido del contador y lo guarda en los registros EDX:EAX (parte alta en EDX, y parte baja en EAX). Dicho valor es de 64 bits... (edx + eax = 64 bits). La técnica consiste en:
1º leer el TSC
2º guardar EDX y EAX en dos variables locales
3º hacer la rutina de instrucciones hacia el periférico o memoria
4º volver a leer el TSC
5º hacer una resta de 64 bits entre EDX:EAX último leido y las variables locales que guardaban el valor de la primera lectura.
Dicha resta contendrá los ciclos de reloj (CLK's) que han pasado desde la primera instrucción de la rutina hasta la última. Dividiendo con la frecuencia del microprocesador, obtendrás los segundos (o más bien nanosegundos), que han transcurrido en acceder al periférico o a memoria.
Esto te puede servir por ejemplo para medir frecuencias del procesador en un instante determinado, medir tiempos de acceso a un nivel de la jerarquía de memoria (caché L1, L2, L3, RAM, Disco, CD/DVD, etc...), hasta medir tiempos de respuesta de un dispositivo concreto (tarjeta de sonido, gráfica, red, etc...).
Del mismo modo si se conocen por ejemplo las políticas de lecturas y escrituras entre niveles de la jerarquía de memoria, así como mecanismos de ubicación y reemplazos de bloques o líneas entre dos niveles de la jerarquía, no sólo es posible medir tiempos de acceso, sino que también es totalmente viable poder averiguar el tamaño de dicha memoria. Simplemente basta observar un aumento excesivo en el número de ciclos de reloj (o tiempo en nanosegundos), cuando se intenta acceder (o mejor dicho leer) un dato de un tamaño prefijado (por ejemplo un entero de 32 bits), que no se encuentra donde se espera (viola el principio de localidad espacial y produce un fallo de acceso o de lectura a ese nivel de la jerarquia). Este aumento se debe a que cuando el procesador referencia un dato, lo primero es que accede a su primer nivel de la jerarquía (caché L1), si no se encuentra allí, accede a su segundo nivel (caché L2), y si no está alli a su tercer nivel (caché L3 si la tiene, o en su defecto a RAM), y si no está alli, finalmente a disco. Cuando logra encontrar dicho dato, se trae un bloque completo (el dato y los que están consecutivos a él), a su nivel inferior, es decir, si por ejemplo referencia un dato y no está en L1, va a L2 y suponiendo que allí ya lo encuentra, entonces se trae un bloque de L2 y lo ubica en L1 para futuras referencias. El truco consiste en referenciar un dato, de forma que el siguiente que va a ser referenciado no esté ubicado en L1 y tenga nuevamente que acceder a L2. Lo que se observa con ésto es que sólo se accede al siguiente nivel en caso de fallo, y en tal caso, el tiempo de acceso a dicho nivel es la suma de haber fallado en el anterior (penalización por haber fallado) + tiempo de acceder al siguiente nivel. El tiempo de acceder al siguiente nivel, en caso de acierto, es cada vez mayor a medida que vamos avanzando por los niveles de la jerarquía... es decir, el tiempo de acceso a disco es mayor que a RAM, y a su vez éste mayor que a L3 o L2, y a su vez mayor que a L1... (Esto se debe en parte a una tecnología más económica usada y sobre todo a la adaptación de frecuencias de trabajo, tamaño de lineas y buses, etc... Por lo que hay que incorporar mecanismos de sincronización y almacenamiento intermedio (buffers), entre los distintos niveles, como son por ejemplo el caso de los puente Norte (para memoria principal) y Sur (para periféricos). El primero, trabajando con la frecuencia denominada FSB, y sincroniza accesos entre procesador y RAM. Lo cual es un detalle a tener en cuenta a la hora de calcular tiempos de acceso a RAM, o bien para calcular dicha frecuencia.
Por tanto, resumiendo para la realización del benchmark, si forzamos a que los datos referenciados no estén donde deberían, o donde sería más eficiente o ideal que estuvieran, entonces logramos medir experimentalmente dichos tiempos de acceso, tal y como comenté antes.
Habria que tener presentes otro tipo de detalles, tales como el tipo de arquitectura del procesador (segmentado, superescalar, vectorial, etc...), pero de momento no voy a extenderme mucho más
Todo lo que he contado es relativamente sencillo de implementar, y según mi opinión es tiempo de sobra el poder tenerlo antes de abril, incluso en menos de 1 mes si te dedicas a ello unos minutos todos los dias y menos de 2 semanas si te dedicas de lleno en ello.
Un saludo.
Última edición por hystd; 10-01-2009 a las 08:51
waaww eres un monstruo !! cuanta info ...
me ha encantado lo de pedir la info al registro yo pensaba en usar la libreria WMI
mañana estaré todo el dia con el proyecto a ver que tal.
por cierto he ido al taller de programación que tienes en la firma aún está activo? en teoria me salió que estaba en construcción y con la facilidad que veo que me escribes me extrañó un poco jeje
gracias por la ayuda
saludos!!!
Última edición por Renegada; 11-01-2009 a las 02:33
Bueno lo del taller por supuesto que sigue activo. Es un proyecto de esta comunidad, y estamos trabajando para que salga adelante. La web que hay ahora mismo puesta es sólo un prototipo y no tiene por qué ser la definitiva, ya que aún hay muchos puntos que tratar.
Un saludo.
Marcadores