SoloCodigo

La velocidad para realizar los procesos es mayor en assembler, ya que los compiladores no minimizan al maximo el tamaño de codigo, cosas que si eres tu el que programa y sabes te saldra un codigo mucho mas compacto y por tanto mas veloz en ejecucion, para encender un led da igual pero habra procesos en los que el tiempo es critico.

Los procesadores tipo Risc como los Pics se caracterizan por optimizar codigo por dos
caminos (Tamaño o Tiempo de ejecucion).Caso curioso que para lograr la mayor velocidad hay que evitar compactar codigo, si no crees revisa los ejemplos de Microchip
para tamaño y velocidad,te daras cuenta que para velocidad no escatiman en el gasto de memoria.Asi que no va lo de mas compacto = mas velocidad por el contrario.

Assembler te permite entender y comprender mejor a los microcontroladores y tener un dominio mayor sobre ellos, en C se pierde un poco la esencia del micro: el tener que configurar registros, activas bits de un registro...por ejemplo el configurar el adc, en assembler tienes que saber en cada momento que significa cada bits de los registros implicados y como configurarlo, en c tienes que configurar pero de una forma menos completa(ya te lo hace el)

El entendimiento de un micro no te lo da su asembler sino el conocimiento de bloques y modulos,caracteristicas electricas de sus puertos,etc.
No se si tiene algun sentido en estos tiempos sumergirse (lo hice en el pasado) en los detalles de que el bit5 del registro N hace tal o cual cosa si existe una funcion en
C que lo configura en forma correcta (si esto no es un dominio mayor, no se que lo es) de acuerdo a los parametros que le entregas para despues trabajar en forma eficiente con ese modulo que C configuro y que te funciona a la primera.
 

quiero decir es que se pierde de vista el concepto del hardware y en gran parte de su funcionamiento y configuracion.

No es cierto por que el Hardware que estas programando lo diseñaste y construiste tu mismo por tanto estas siempre ligado a su esencia.

la prueba es que cualquiera puede programar en C pero no en assembler

Durante años programe para varios micros (Z80,8031,68000,6800,Pics,ARM) en asembler se lo que es lidiar con asemblers de diferente tipo pasando horas revisando rutinas que parecian optimas y que no funcionaban por que colocates datos en un registro o memoria ya ocupada del cual no te diste cuenta.Ahora con el cambio a C (que no es una moda sino una necesidad) no retorno al asembler.

Microsoft ha ido cerrando Dx para lenguajes no producidos por ellos.

Discrepo con Tirol el asembler te estreza (debes concentrarte mucho con cada linea de codigo para no llevarte por delante un registro o celda de memoria que ya esta ocupado).En cambio C te permite concentrarte unicamente en la aplicacion y que el compilador se las arregle con los bancos de memoria y asignacion de registros.

Gracias Gandalf_Galaga7  

Otra cosa comiensa desde ya a a probar con interrupciones si es que aun no lo has hecho ,te sera de inmensa  ayuda .

Yo pienso que C y sus derivados son como la rueda seguiran moviendo al mundo por varios años..

Yo uso una tecnica que me a dado buenos resultados en DX desconosco OpenGl pero la
operatoria no deveria variar mucho.

los nombres son solo como referencia

1.-General una clase ObjetoEnPantalla.

2.-Dentro de ObjetoEnPantalla declara una variable para cordenadas ScreenX y otra ScreenY.

3.- tambien puedes crear dentro de la clase  ObjetoEnPantalla un metodo para Rendear el objeto en pantalla usando para ello las cordenas  ScreenX, ScreenY.

3.-instancia la clase ObjetoEnPantalla con dos objetos.
    El objeto Mano.
    El objeto Cosa.
Ahora ambos objetos (Mano y Cosa) tendran variables ScreenX ScreenY ademas de un metodo(funcion,subrutina) Rendear por separadopara cada objeto instaciado en la clase ObjetoEnPantalla.

como usar Ejemplo:
 
Mano.ScreenX = 500; posicion pixel 500 (horizontal)
Mano.ScreenY = 400; posicion pixel 400 (vertical)


Cosa.ScreenX = 500; posicion pixel 500 (horizontal)
Cosa.ScreenY = 300; posicion pixel 300 (vertical)

if(Mano.ScreenX == Cosa.ScreenX && Mano.ScreenY == Cosa.ScreenY)
   {

     ......bla bla bla


    }


Mano.Rendear();dibuja Mano
Cosa.Rendear();dibuja Cosa

puedes leer y escribir las cordenadas antes de rendear para asi tomar tus decisiones en el programa.

Como te dije antes no conosco la mecanica de OpenGl pero a nivel de lenguaje esta
manera es eficiente.


Espero que este patron te sirva.

Saludos.

no importa el procesador por que el control de temperatura es una funcion de bajo nivel
que se encuentra en la bios la cual lee un conversor del tipo ADC que a su vez esta conectado con un sensor de temperatura tipo PTC . Esa informacion  se usa para regular la velocidad final del los ventiladores conectados a la MB o cortar la alimentacion de la misma por poblemas termicos.

Siempre me ha intrigado por que algunos insisten el crear por codigo los modulos que
existen por hardware en versiones de chips posteriores al que estan usando .

1.-Por costo dicen algunos :
 El codigo que posteo nuestro amigo tiene cara de pic16F84 y este micro es reemplazado con creces por el pic16F877 con un costo en dinero no muy mayor que F84
y con prestaciones de modulos de hardware(UART,ADC,PWM,TIMER,COUNTERS) que haran que el codigo sea mas poderoso y eficiente .Por que los que cren que ahorran dinero entre un modelo y otro, la verda es que lo  gastan tratando de  implementar los modulos que necesitan por codigo   dejando poca  memoria para la aplicacion es si misma, bajas prestaciones y largos tiempo de desarrollo.  

2.- Por espacio dices Otros.
Donde cave uno de 16Pines cave uno de 28Pines sin grandes coseciones de espacio.

3.-Por aprender mas.
Si se acostumbran a las malas pacticas de querer reinvertar la rueda su vida laboral sera dificil y llena de proyectos a medio terminar.

Como humilde desarrollador de sistemas embebidos con 15 años de experiencia les aconsejo elegir sus chip de acuerdo a los requerimientos reales de su proyecto y no ahorren centavos pensando que lo solucionaran todo por codigo .

Recuerden cliente satisfecho = fama y fortuna.

Saludos.

El overlock es aumentar la velocidad original de procesador por un factor determinado y
una de las formas de conseguirlo es variando el factor de escala del PLL que el procesador trae en su interior mediante un programa,pero este aumento de velocidad trae consigo un aumento el la corriente final consumida por la CPU y aumentado tambie con ello la temperatura teniendo que recurrir a metodos especiales y mas costosos de refrigeracion por que ya no basta la ventilacion tradicional.

Tengo entendido que para DX9.x  se utiliza VS2003 o VS2005 (tener instalado el VC++ solo ya no se usa). Te recomiendo VS2003 y DirextX 9 Managed sobre C# (con C# el DX corre aproximadamente un 7%  mas lento que con C++ no administrado pero en las maquinas de ahora resulta un margen aceptable). C# es mas amigable que C++.net y full POO yo lo huso con DX9 y no tengo quejas hasta ahora.

Saludos

Despues de varios intentos fallidos (Hace dias que estoy con esto) lo solucione .

Gracias de todas maneras.

Saludos.

Si no te corren los tutoriales los mas probable es que este mal configurado el DirectX

en el Vc

revisar este link claro que es para VS 2003 pero el seting es parecido al VC

http://www.codigoverde.com/Space%20Invaders%201.htm