# ASM, basic , C y otros



## fernandob (Jul 1, 2010)

hola a vecs me pongo a "ojear" alguno que comenzo un curso aca de algo y se fue a poner ejemplos y responder consultas, pero dejo de lado la organizacion y la meticulosidad que requiere un curso, eso sin decir que nadie lo termina de verdad.

pero bueno, para que alguien se meta a aprender un lenguaje *LO PRIMERO* es saber que lenguaje aprender.
yo aprendi ASM , no quiero que en este tema enseñen ningun lenguaje y les pido que solo quienes sepan de esto escriban asi no se llena de respuestas y concretamente podemos saber que es cada cosa.

*cual es la diferencia , las posibilidades de cada lenguaje ??*
esta es la pregunta.
un ingeniero se dedica a esto, o un tecnico que tiene como oficio programar seguido , pero para muchisima gente esto es algo esporadico, asi que el lenguaje que aprendan con ese se quedaran , nadie se va a poner a comenzar de nuevo un lenguaje para hacer un diseño en su vida , y menso sabiendo otro.
asi que , la cosa es saber antes de tirarse a la pileta que posibilidades da cada uno y que complejidad es el programa . 


por ejemplo:

*ASM:*
las instrucciones son faciles de aprender, en este lenguaje si o si hay que dedicar mucho tiempo, estudiar la data de el micro que son cientos de hojas , conocer todos los registros ya qu ehay que definir TODO , uno no se puede confiar que algo salga solo por que seria jugar a la carambola.
si no vas a usar A/D no tocas el registro que lo involucra......pero mejor mirar que tienen , a ver si algun bit si te afecta , o de fabrica viene ese pin como ana y vos lo queres digital.
en fin.
es arduo , yo por lo menos no me gustaba dejar nada al azar asi que me los revise todos.
luego el programa :
primero el flujo para ver que uno va a hacer.
luego el asm .
instruccion por instruccion .
como dicen todos : uno tiene el control de las cosas eso si , pero vieron que se dice que para sonreir se usan no se 40 musculos??
imaginen que quieren ejecutar :
SONREIR.
bueno , son 40 instrucciones que terminan cansando.
hay trucos, pero .........
es un fastidio.
se ve cuando uno termina y imprime el programa y no sabes si esta saliendo el mismo o un rollo de papel higienico se abre.
ademas , si es largo, mejor aprende a estructurarlo, por que cuando tenes que buscar algo luego de un tiempo.........huu.....a sumergirte en ese mosntruo que hiciste.

*ASI QUE  ASM :*
tenes que aprenderte las instrucciones.
a usar el mplab que si no sabes ingles no es moco de pavo.
como funciona el micro y todos sus registros que estaan dispersos en esas cientos de hojas de la datasheet.
amor por la electronica y no tener novia.
una buena idea de programacion , diagramas de flujo y eso.



*BASIC ......C*

bueno, aca les toca a uds. alguno que sepa ambos podra hacer una comparativa.

algunas dudas que serian interesantes saber:

1 -- en alguno de estos NO es necesario saber mucho de el micro ??
uno quiere que sonria y solo pone :
SONREIR .
o quiero un retardo o un timer o alguna operacion matematica y con una o 2 instrucciones la invoco ??
sin por ello dejar al micro atorado o clavado en ella .
cosas que con ASM usaria 10 o 20 instrucciones.

2 -- derroche de memoria ??
siempre dicen que con ASM se aprovecha mas, pero hoy dia son pocos los  que usan toda la memoria de un micro, y si no te alcanza , el que tiene el doble de memoria o el cuadruple solo sale un par de dolares mas, asi que no le veo a eso algo importante.

3 ---  se puede hacer con estos lenguajes todo ?? l que con ASM ?? y mas ???

4 -- enlaces a buenos cursos de cada lenguaje

5 -- programas seguros y oficiales para bajar y usar .

6 --- cuantas instrucciones son ?? en cada lenguaje 
que complejidad tiene ??
comentarios como puse con el ASM y mas.


saludos y gracias


----------



## cosmefulanito04 (Jul 2, 2010)

Yo creo que si sabes programar en un lenguaje y tenes las nociones basicas de un buen programador, no creo que te resulte muy dificil entender otro lenguaje (tambien dependera cual, pero podriamos decir que casi todos).

Yo por ej. empece viendo pascal en la secundaria (lenguaje viejo y poco util diriamos hoy en dia), despues me enseñaron el lenguaje C , y es hasta el dia de hoy que le sigo sacando jugo a pesar de ser un lenguaje viejo en lo que a Pc se refiere y moderno (por decirlo de alguna forma) en el mundo de los uC's. 

En ambos casos, la forma de programar no cambiaba demasiado, simplemente tenias que adaptarte a los nuevos comandos (no importa como se llame un comando o que argumento necesita, siempre te las arreglas con un help o google).

Despues dandome maña y con un libro, aprendi lo basico de java que tiene muchas cosas parecidas (hermano menor de C++), pero fundamentalmente cambia en la forma de encarar el programa, ya que es un lenguaje orientado a objetos (un especie de encapsulamiento), y si bien no lo aprendi de la noche a la mañana, muchos de los conceptos aprendidos en C y la forma de encarar algoritomos fueron los mismos.

Por ultimo, ahora estoy viendo algo de assembler aplicado a la arquitectura IA32, y nuevamente muchos de los conceptos aprendidos en C son aplicables en assembler, obviamente que hay que pedalear muchisimo mas para hacer cosas relativamente complejas, pero a la larga es siempre igual.

De los lenguajes mencionados, podria decir esto:

Assembler: 

Pros: 
- Mayor velocidad
- Menor peso en codigo y en datos
- Maximo control y saber exactamente lo que esta haciendo el uC o uP

Contras: 
- Tedioso a la hora de trabajar, ya que las herramientas son a muy bajo nivel, para realizar ciertas cosas tenes que reinventar la rueda.
- Toma mayor tiempo realizar un programa.
- Tener que controlar absolutamente todo, por ej. que no se desbalanceen las pilas.
- Complicado de entender a la hora de leer, poco estructurado, y normalmente con un codigo que tiene jmp/goto o cosas similares por todos lados.
- Incompatibilidades con distintos uP/uC.

C:

Pros: 
- Toma menor tiempo realizar un programa.
- Muchas de las funciones que se necesitan ya existen.
- Mucha mayor compatibilidad con distintos uP/uC.
- Lenguaje estructurado, si se programa bien solo deberias tener una entrada y una salida, con lo cual resulta mas sencillo de entender cuando se lo lee.

Contras: 
- Mucho menor control sobre el uC/uP.
- Mayor peso en codigo y datos.

Java:

Pros: 
- Lenguaje super moderno, que tiene clases para todo.
- Orientado a objetos a diferencia del C que es estructurado.
- Muy usado hoy en dia en Pc's.
- IDE's muy modernos, que programan casi solos  . 
- Maxima compatibilidad con diferentes sistemas, y arquitecturas, debido a una plataforma intermedia.

Contras: 
- Cero control sobre el uC/uP, ni te enteras que pasa, ya que usa una plataforma intermedia.
- Mucho mayor peso en codigo y datos.

De esos 3 lenguajes, hoy en dia para uC se usan los 2 1eros, y para Pc diriamos que java, los otros 2 son obsoletos.

Si tuviera que recomendar por un lenguaje para uC, y por cuestiones de tiempo solo queres aprender un lenguaje, sin duda que lo mejor seria C, ya que te permite aplicarlo a cualquier uC moderno de hoy en dia, y dejaria al assembler para algo mucho mas avanzado que requiera extremo control sobre el hard.


----------



## cristian ayuso (Jul 2, 2010)

Poes en mi opinion, Basic es el mas comodo, pero claro, ocupa mucha memoria, y assembler es el mejor, pero hay que echarle ganas para hacer un programa sofisticado. yo la verdad me quedo con C, porque tienes el programa muy bien estructurado y cuando quieras, sobre el progama en C puedes poner sentencias en assembler directamente


----------



## KanonOfGeminis (Jul 2, 2010)

Yo me quedo con el Assembler, ya que desde que empece la carrera de electronica los docentes solo nos permitian usar y aprender el lenguaje assembler por el simple hecho de que tenemos que pensar como una maquina lol
Actualmente muchos optan por usar software`s que usen interfaces mas simples de entender.   

ASM lo maximo!!!


----------



## fernandob (Jul 2, 2010)

hola, alguno que use o sepa o haya usado C y basic para poder comparar ??? 
y detallen las diferencias .

mcuhas gracias.


----------



## lubeck (Jul 2, 2010)

Ya lo he dicho en varias ocasiones que no son comparables... pero bueno... en mi opinion...

ASM:
Ventaja mayor velocidad
Desventaja mayor tiempo de programación
Orientado a Programadores profesionales. 

C:
Ventaja mediana velocidad
ventaja mediano tiempo de programación
Orientado a Programadores semi-profesionales.
Incorporacion de Asm

Basic:
DesVentaja mínima velocidad
ventaja mínimo tiempo de programación
Orientado a programadores eventuales.
Incorporacion de Asm

Saludos....


----------



## ByAxel (Jul 3, 2010)

Si el compilador es solo orientado para microcontroladores estoy de acuerdo con *lubeck*, pero no podemos generalizar.
Pero en cuanto al C, me quedo con el compilador del Hi-Tech que me a dado mejores resultados, obteniendo un HEX comparable a hacerlo todo en ASM. 

Por supuesto que no todo es color de rosa.


----------



## Dr. Zoidberg (Jul 3, 2010)

lubeck dijo:


> C:
> Ventaja mediana velocidad
> ventaja mediano tiempo de programación
> *Orientado a Programadores semi-profesionales.*
> Incorporacion de Asm



Disculpá que disienta en lo que he marcado, pero yo lo pondría así:

*Orientado a programadores profesionales que desean resolver el problema en forma efectiva y no perder tiempo reinventando lo que ha sido desarrollado hace 40 años.*


----------



## ByAxel (Jul 3, 2010)

Bien dicho *ezavalla*, después de todo para eso están los compiladores de alto nivel para hacernos la vida más fácil y poner mayor atención al desarrollo del sistema en si...
Claro que debemos confiar en el mismo y para eso se debe usar compiladores que realmente tengan renombre y no preocuparnos en los bugs ...
Como sea el C es más aceptable .


----------



## lubeck (Jul 3, 2010)

> Disculpá que disienta en lo que he marcado, pero yo lo pondría así



No EZ si estoy deacuerdo contigo.... pero es bien difícil generalizar.... en cuanto estas comparaciones... puntualizar las diferencias en cuanto a cada uno y hacer estadisticas de uso seria prácticamente imposible y para cuadrarlas en una clasificación me pareció así lo mas adecuado... 

Saludos...


----------



## thenot (Jul 3, 2010)

c para profesionales??? no jodas ezavalla!! los profesionales programan en assembler!! con ello pueden saber exactamente lo que se esta haciendo, o quizás para mi (y las personas que conozco) un programador profesional es otra cosa...
Para mi si lo que quiero que haga el micro no es algo preciso, programo en basic, si necesito tiempos exactos y saber donde estoy en cada momento, assembler. C me lo salto, para mi C o basic son lo mismo, ambos los usaría si lo que quiero hacer algo en que la precisión no sea de importancia, pero me quedo con basic.


----------



## Dr. Zoidberg (Jul 3, 2010)

thenot dijo:


> *c para profesionales??? no jodas ezavalla!!* *los profesionales programan en assembler!!* con ello pueden saber exactamente lo que se esta haciendo, o quizás para mi (y las personas que conozco) un programador profesional es otra cosa...



    
Bueno...si opinás así, decíselo a los cientos o miles de programadores que desarrollaron el kernel de LINUX o FreeBSD o algunos de los unixces o aún del mismo Windows. Te aseguro que te van a mirar así ""...bueno...no solo te van a mirar...



thenot dijo:


> Para mi si lo que quiero que haga el micro no es algo preciso, programo en basic, si necesito tiempos exactos y saber donde estoy en cada momento, assembler. *C me lo salto, para mi C o basic son lo mismo*, ambos los usaría si lo que quiero hacer *algo en que la precisión no sea de importancia*, *pero me quedo con basic.*



  
Bueno...sin palabras....

Lamentablemente, cuando la única herramienta que uno tiene es un martillo...todo se parece a un clavo


----------



## lubeck (Jul 3, 2010)

> decíselo a los cientos o miles de programadores que desarrollaron el kernel de LINUX o FreeBSD o algunos de los unixces o aún del mismo Windows.



En lo que si yo haria un poco de diferencia es que a profesionales... no me refiero a ello... me refiero a programadores de la NASA o desarrolladores de tecnologías de punta... pero de igual forma... es muy dificil...

lo mas importante es que la mayoría y *no digo todos* aqui somos amateurs y basic es una excelente opción....
asi que a mi gusto... muchos deberian considerarlo como un buen lenguaje... 

Saludos...


----------



## Dr. Zoidberg (Jul 3, 2010)

lubeck dijo:


> lo mas importante es que la mayoría y *no digo todos* aqui somos amateurs y basic es una excelente opción....
> asi que a mi gusto... muchos deberian considerarlo como un buen lenguaje...



No es que Basic sea malo, al menos para los microcontroladores, el problema es que NO ES ESTANDARD y hay un par de millones de versiones según la idea de cada empresa que desarrolla un compilador, lo que te exige aprender casi el 50% del lenguaje cada vez que encarás un procesador diferente. En cambio al C solo lo estudias una vez...


----------



## lubeck (Jul 3, 2010)

> lo que te exige aprender casi el 50% del lenguaje cada vez que encarás un procesador diferente.



En eso si tienes bastante razon... estoy metiendome en esto de los micros... y baje varios compiladores para seleccionar el mas adecuado... 

si tienen diferencias muy marcadas.... 

pero por otro lado... e insisto y creo que queda clara mi postura... la ventaja es que en no mas de tres o cuatro dias ya hice mis primero simulados en tres compiladores de basic diferentes.. entonces si yo no pretendo hacer muchos circuitos y maquinas o lo que sea, esta bien... si mi intencion fuera competir en un mercado... definitivamente optaría por un compilador de C.... esa es toda la diferencia y la mas importante en mi criterio...


----------



## Tomasito (Jul 3, 2010)

Pregunta: Con los micros *potentes y baratos* que hay hoy en día, ¿Vale tanto la pena programar en assembler?

Obviamente, sé que hay aplicaciones donde *hay* que usar assembler, pero creo que para muchísimas aplicaciones, un lenguaje de alto nivel como C sirve perfectamente, es más eficiente en cuanto al tiempo para programar, depurar, es modular, mucho más legible...
Yo creo que si no se precisa una velocidad excepcional o una cantidad de memoria ínfima, el C está bien. Además a veces se puede incluir código en assembler dentro del C para ciertas cosas (obviamente depende del micro, del lenguaje y del IDE).
Para dar un ejemplo, el AVRUSB (Implementación de USB por software para AVRs), está portado al Arduino  (que se programa en C, pero está incrustado el código en asm dentro del C, osea que permite modularidad inclusive con ASM).


Yo por ahora, con C ando más que bien, he pensado en aprender ASM, pero la verdad, todavía no he tenido nunca una aplicación donde lo necesite y no pueda usar C.


----------



## cosmefulanito04 (Jul 3, 2010)

thenot dijo:


> c para profesionales??? no jodas ezavalla!! los profesionales programan en assembler!! con ello pueden saber exactamente lo que se esta haciendo, o quizás para mi (y las personas que conozco) un programador profesional es otra cosa...
> Para mi si lo que quiero que haga el micro no es algo preciso, programo en basic, si necesito tiempos exactos y saber donde estoy en cada momento, assembler. C me lo salto, para mi C o basic son lo mismo, ambos los usaría si lo que quiero hacer algo en que la precisión no sea de importancia, pero me quedo con basic.



No podes decir que C no es importante.

Que pasa si estoy usando un 8051, y el dia de mañana quiero pasarme a un ARM, PIC o cualquier otro, ¿podria hacerlo con el lenguaje basic? ¿tendran todos estos uC las mismas funciones? (incluso el 8051 ni se si tiene basic)

Yo justamente, de los 3 posibles lenguajes (assembler, C y basic), al que menos bola le daria es al basic.


----------



## fernandob (Jul 3, 2010)

hola a todos, yo creo que lo que dice ezevalla es correcto, lo que pasa , como ya dijeron aca hay mas que nada hoobystas.
creo que hay que distinguir : EL : *¿PARA QUE LO USO ??* 
un PROFESIONAL no se la va a pasar diseñando manejo de reles o displays simples , alguna vez entra alguno que DE VERDAD esta terminando la facu y hace alguna pregunta y quedan todos callados (de culo ) por que ni siquiera entienden de que habla, hay aplicaciones donde realmente se requiere esos 32K o mas de memoria de programa, y se necesitan hacer operaciones complejas.
Miren en el tema de acertijos de logica y comprension, cuando se ponen alejandro y eduardo que si tienen estudios superiores, ........los demas ......ni j.
es asi la cosa, hay niveles, por algo se inventaron los micros de mas de 8 bits y los DSPIC , son aplicaciones que ni entendemos de que hablan.
POR ESO DISTINGAMOS NIVELES DE APLICACIONES.

hay que saber distinguir que es lo que llaman profesional.
*pero no es lo importante el querer competir en eso, tratemso de aclarar los lenguajes.*

me pareceria interesante saber las diferencias entre C y basic, algunas ya las han puesto:

*BASIC*
1 -- es mas sencillo o no ?? en cuanto a instrucciones y forma de verlas ?? (ver punto 4 , segun que nivel de aplicaciones) 
2 -- hay que conocer la data del PIC ?? me refiero a todos los registros, donde anda el stack manejo de tablas, saltos , etc. , o no ??
3 -- ya han puesto que no es muy universal ni portable .
4 -- el basic es mejor HASTA QUE TIPO DE DESARROLLOS ?? me refiero, si yo soy tecnico , y se que nunca hare ni algo de USB, solo manejo de reles o triacs , o luces, o como mucho manejar un display sencillo inteligente o no y un teclado, en ese orden de cosas andare, nada mas .........es mucho mas sencillo elegir un basic?? 
o mejor igual el C ?????


*C*
por defecto lo contario .
indiquen otros que consideren relevantes.


hay algunas cosas que ya se ven solas, pero quisiera aclaracion:
un ingeniero que necesita usar un PIC18 o PIC 24 o ARM o DSP ,,,,,,.........usa asm ?? o basic ?? 
que usa ?? que opciones ?? 


tengan en cuenta que la cosa nunca es blanco o negro, o esto sirve para todo,por eso la idea es dejar bien claro este tema, hay quienes quisieran aprender un lenguaje y saben que nunca necesitaran mas que tal tipo de proyectos, no solo por su aplicacion sino que ademas por sus conocimientos:
yo no se derivadas ni integrales, se me olvidaron y no quiero volver a eso, asi que un desarrollo complejo no solo involucra saber "EL LENGUAJE" , sino que tambien "LA TEORIA" y "las matematicas " para poder desarrollarlo.

.

saludos


----------



## lubeck (Jul 3, 2010)

Hola fer...
tu juzga...
estoy empezando con los micros y utilice este codigo de basic (picbasic pro) para entenderlo...


```
@ device xt_osc 
define osc 4    
led var portb.0                       
inicio:
HIGH  led   
goto inicio 
end
```

es todo lo que se necesita para encender un led...
no me encontrado ninguno de C seria interesante que alguien pusiera un codigo en C para encender unicamente un led...

Saludos

Pd... y se puede simplificar mas aun...

```
@ device xt_osc ; se le dice al compilador que se va a utilizar un osc externo
define osc 4    ; se define la frecuencia del oscilador 4Mhz
HIGH  portb.0   ;se pone en alto del puerto b el primer bit 
end  ;finaliza programa
```


----------



## fernandob (Jul 3, 2010)

lubeck ponele que estas eligiendo un PIC determinado, no necesitas definir lso registros iniciales ??
que ports seran I/O , que flags tenes que tocar??
definir las variables que usaras , etc, etc.......(re inchapelo......) 

tomas cualquier PIC , le pones eso y listo ???

es interesante ver el mismo programa en distintos lenguajes, pero no es solo eso, entre otras cosas hay que saber (como pregunte mas arriba ) que pasara cuando hago un progrmita un poco mas largo,  o otras cosas.

yo solo pregunto, NO se basic ni C .


----------



## lubeck (Jul 3, 2010)

Fer...

Te digo voy empezando.... 
se supone que asi es para cualquier Pic... lo seleccionas y el compilador hace lo suyo... ya ya es todo...
te genera el archivo .HEX y al simulador... eso es todo...  segun yo no hay mas... claro que entre mas complejo aumentan las instrucciones como cualquier lenguaje...

saludos...

Agrego:
cabe aclarar que  no hay archivos .inc  nada de nada...


----------



## Dr. Zoidberg (Jul 3, 2010)

fernandob dijo:


> como ya dijeron aca hay mas que nada hoobystas
> ...
> *un PROFESIONAL no se la va a pasar diseñando manejo de reles o displays simples*



Es que eso se hace a menudo, pero para manejar un display hay que concentrarse en que querés mostrar y como querés que se vea, no en generar un pulso de 3.25 us para activar una función del display...ni mucho menos estar cargando registros de direccionamiento de bloques de memoria cuando solo querés cargar un valor en una variable y hacer *A=10*!!!

Y no hay ningún problema en que haya hobbystas...de hecho, es mejor, por que no es gente entrenada para andar desculando que corno hace una instrucción que debe *rotar 3 bits a la derecha pasando por el bit de carry en el registro de estado*, sino que solo hace algo del tipo A>>3 y listo... en cualquier uC o uProcesador! en lugar de aprender una instrucción que varía de nombre y estructura de operación para cada CPU que hay en el planeta.

Lo malo es la gente que no tiene sentido común y pretende usar el assembler por que los que usan assembler son re-machos y los que programan en lenguajes de alto nivel (y meten assembler en contados casos, desde el mismo código) son unas mariquitas que se la comen ...digo, mas o menos traducido al Argentino básico 



fernandob dijo:


> me pareceria interesante saber las diferencias entre C y basic, algunas ya las han puesto:



Primero hay que aclarar de que BASIC estamos hablando, pero supongamos que es para los uControladores, y aclaro que para este caso SI HAY QUE CONOCER LOS REGISTROS DEL CHIP, por que son los que fijan alguna operaciones que no necesariamente pueden enmascararse detrás de una función o macro.

*BASIC*


*Sintaxis bastante simple*.
Imposibilidad de usar punteros.
Imposibilidad de mezclar con assembler (esto es hasta donde me acuerdo).
No es estándard en los tipos de datos.
Permite manejar todos los periféricos on-chip.
Estructuras de código en funciones y subrutinas.
 *C
*

*Sintaxis medio complicada* hasta que se aprende.
Uso completo de punteros, incluso punteros a funciones.
Admite la inclusión de bloques en assembler dentro del código C.
Tiene los tipos de datos y otras muchísimas cosas más estandarizadas por ANSI.
Permite manejar todos los periféricos on-chip.
Estructuras de código solo en funciones.
Seguro que me olvido de muchas cosas, pero para elegir uno u otro, creo que es suficiente.


----------



## lubeck (Jul 3, 2010)

> Imposibilidad de mezclar con assembler (esto es hasta donde me acuerdo).



Aqui creo que si puedes estar equivocado...

Desde TurboBAsic o QuickBasic incluso en picbasic pro se pueden incluir librerias en ASM
No de igual forma que C pero si es posible....

Alguien se anima con un codigo en C, para dejar la comparacion en el tema...

Saludos


----------



## Dr. Zoidberg (Jul 3, 2010)

lubeck dijo:


> Aqui creo que si puedes estar equivocado...
> 
> Desde TurboBAsic o QuickBasic incluso en picbasic pro se pueden incluir librerias en ASM
> No de igual forma que C pero si es posible....



See...es probable, por que la verdad es que no me acuerdo...
*Creo *que solo en MikroBasic podías incluir el assembler junto con el código BASIC, pero no me acuerdo que lío había con el registro que cambia el mapa de registros del PIC...


----------



## cosmefulanito04 (Jul 3, 2010)

lubeck dijo:


> ...
> 
> Alguien se anima con un codigo en C, para dejar la comparacion en el tema...
> 
> Saludos



Encender un led no creo que aporte mucho, creo que en los 3 casos es muy simple de hacerlo.

Seria bueno comparar por ej. algoritmos, o por tirar algo por ej. como harias en los 3 lenguajes para recibir un dato por puerto serie y escribirlo en un display 7 segmentos, ahi si se verian cosas interesantes.


----------



## lubeck (Jul 3, 2010)

Va el codigo para poner algo en un lcd en picbasicpro


```
@ device xt_osc 
define osc 4 
DEFINE LCD_DREG PORTC 
DEFINE LCD_DBIT 4     
DEFINE LCD_RSREG PORTC
DEFINE LCD_RSBIT 1    
DEFINE LCD_EREG PORTC 
DEFINE LCD_EBIT 2     

LCDOUT $FE, 1
LCDOUT $FE, 1, "Lubeck"
```

Lo de serie todavia no se jejejej... denme chance tengo 2 dias de experiencia..
pero creo que las instrucciones son SERIN y SEROUT no creo que tampoco sea dificil... para USB es USBIN y USBOUT en este ultimo creo que si tiene que ser los pic 18f2550 f18f4550

Ojo... no quiero que nadie cambie su parecer con respecto a su compilador preferido... nada mas intento al igual que fer mostremos los algoritmos....y los beneficios/desventajas de cada uno...

Es que esto es como si yo fuera a una Agencia de vehiculos y pidiera un vehiculo... el vendedor me va ofrecer por ejemplo un Ferrari y me va a insistir e insistir e insistir hasta que le diga... oye pero lo quiero para el campo....  entonce me va a decir que un todoterreno.... y si le digo que no hay caminos  me va a decir que una motocross... asi esta esto... no hay mas...


----------



## cosmefulanito04 (Jul 3, 2010)

Bueno ahi le pasas el trapo en facilidad al C porque ya tenes las funciones cocinadas, en C la tenes que hacer vos o usar funciones ya hechas por otros. 

EN --> P3.7 (puerto 3, pin 7)
RW --> P3.6 (puerto 3, pin 6)
RS --> P3.5 (puerto 3, pin 5)

Datos al LCD --> P2 (puerto 2, pines del 0 al 7)

En un 8051 con C la cosa seria asi:


```
#include <reg51.h>

//--------------------------------------
sbit EN=P3 ^ 7;
sbit RW=P3 ^ 6;
sbit RS=P3 ^ 5;
sbit P2_7=P2 ^ 7;
//---------------------------------------


unsigned char Lcdwait() // Espera a q el display este disponible y devuelve la direccion actual de la memoria
{	 
	 unsigned char aux;
	 RS=0;RW=1;
	 while(P2_7==1); // Espero
	 aux=P2;
	 EN=0;RW=0;
	 P2=0x00;//Funciona como salida
	 return aux;
}

void Lcddata(unsigned char dato,unsigned char flag)	  // Con Flag=0 Datos 
{
													  // Con Flag=1:
	if (!flag)										  // Dato + 0x80 => direccion
		RS=1;										  // Dato=1 borro pantalla (DB0=1)
	else											  // Dato=2 o 3 => Cursor a Home
		{RS=0;}							              // Db2=1 => Configuro cursor: Db1=1 => derecha, con Db0 => el display cambia
     												  // Db3=1 => Db2=1 Lcd on, Db1=1 cursor on, Db0=1 el cursor parpadea
	P2=dato;										  // Db4=1 => Db3=1 display shift, Db3=0 cursor move; Db2=1 shift right
	EN=1;EN=0;										  // Db5=1 => Db4=1 datos de 8 bits, Db4=0 datos de 4 bits; Db3=1 2 filas; Db2=1 letras de 5x10, Db2=0 letras de 5x8
	Lcdwait();
}

void Lcdinit()	// Inicia el display
{
	Lcddata(0x38,1); // Modo de 8 bits y caracteres de 5x8
	Lcddata(0x38,1); // Habilito 2da linea
	Lcddata(0x0C,1); // Display on, cursor off, cursor blinking off
	Lcddata(0x06,1); // Cursor hacia la derecha
	Lcddata(0x01,1); // Borrar pantalla		
}

void print(char texto[],unsigned char clear)   // Escribe texto en pantalla
{
	unsigned char cont=0,aux,dir;
	aux=strlen(texto)-1;	
	
	if (clear)
		Lcddata(0x01,1); // Borrar pantalla	
	

	while (cont<=aux)
		{
		Lcddata(texto[cont],0);	
		dir=Lcdwait();
		if (dir==0x10)
			Lcddata(0xC0,1);
		if (dir>=0x50)
			Lcddata(0x80,1);
		cont++;
		}
}


void main ()
{ 
	P3&=0x1B;// Pongo en 0 b7,b6,b5,b2
	Lcdinit();

	 print("Texto a mostrar...",0)

	while(1);
}
```

En este caso uso el bit del LCD que indica que esta ocupado, pero tambien habia hecho un codigo con una rutina de espera usando for para no tener que usar un puerto para ese bit. Si uno tuviera que hacerlo en assembler el codigo seria bastante similar.

Tene en cuenta nuevamente que las funciones Lcdinit(), print() y Lcddata() las tuve que hacer yo, ahi esta lo que mencione en su momento en tener que reinventar la rueda para hacer lo mismo, pero en este caso sucede entre C y Basic un lenguaje de mayor nivel; este tipo de cosas es muy comun en assembler, fijense que nunca me preocupo por las pilas, o por donde van a parar las variables y ni que banco uso (en el 8051 uno tiene 4 bancos de 8 registros que funcionan como registros tipo ax,bx, etc).


----------



## Tomasito (Jul 3, 2010)

Bueno, puedo aportar mi granito de arena desde lo que sé, que es C para arduinos.

Por ejemplo, para mostrar lo que se recibe en el puerto serie en un lcd, sería así:


```
#include <LiquidCrystal.h>

LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

void setup(){
	lcd.begin(16, 2);
	Serial.begin(9600);
}

void loop()
{

  if (Serial.available()) {

    delay(100);

    lcd.clear();

    while (Serial.available() > 0) {

      lcd.write(Serial.read());
    }
  }
}
```


Y para hacerlo con un display de 7 segmentos:


```
void setup(){

  pinMode(0, OUTPUT);
  pinMode(1, OUTPUT);
  pinMode(2, OUTPUT);
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  pinMode(5, OUTPUT);
  pinMode(6, OUTPUT);
  Serial.begin(9600);

}

const byte numDef[10] = { 63, 6, 91, 79, 102, 109, 124, 7, 127, 103 };

void loop()
{

  if (Serial.available()) {

    delay(100);

    while (Serial.available() > 0) {

    setSegments( numDef[Serial.read()] );
    delay(250);

    }
  }
}


void setSegments(byte segments)
{
  for (int s = 0; s < 7; s++)
  {
    int bitVal = bitRead( segments, s );
    digitalWrite(s, bitVal);
  }
}
```

O para prender un led:



> void setup()
> {
> pinMode(10, OUTPUT);
> }
> ...





Se nota lo simple que es, en assembler me parece que sería muchísimo más complejo. Usando las librerías en C, lo hacés en dos segundos.


Lo demás, le indicás qué micro usas al IDE (entorno de programación, el programa que usas para programar) de una lista desplegable, las variables definís cuáles vas a usar (creo que se pueden usar variables dinámicas creo que se le dicen, osea, sin definirlas, pero no recuerdo bien, depende el lenguaje y el IDE), y los pines, definís cuáles van a ser entradas y/o salidas (y también si digitales, analógicas o PWM), sólo las que vas a usar.

Todo esto, hablando de los arduinos, que es lo que uso yo (ATMega8, ATMega168, ATMega328 y un par más, con un bootloader).


Si alguien quiere poner ejemplos de código en otros lenguajes, yo puedo aportar poniendo ese código en C (de otros lenguajes no conosco, solo basic pero para PC).


----------



## cosmefulanito04 (Jul 3, 2010)

Ahi es mas interesante, porque en tu caso las liberias del IDE son mas completas y tenes funciones ya resueltas, con el costo de no tener idea que pasa ahi, salvo que las inspecciones.

Con el 8051 tendria que meterme con las interrupciones del puerto y configurar los timers para configurar la velocidad.

Pero es interesante ver, que con C dependiendo como encares, tenes la opcion de tener la funcion ya armada y lista, o agarrar y pelearte un poco mas adentro con el uC.


----------



## lubeck (Jul 3, 2010)

Entonces con el ejemplo de Tomasito se podria decir que esta apreciacion no es valida???
o mas bien tambien aplicada a C???



> el problema es que NO ES ESTANDARD y hay un par de millones de versiones según la idea de cada empresa que desarrolla un compilador,



otra cosa que quisiera puntualizar sobre Basic... es que en sus inicios fue pensado para principiantes... pero de acuerdo a su aceptacion fue evolucionando y casi de su nombre poco queda ya es casi tan complejo como cualquier otro lenguaje... segun mi apreciacion....
Hasta que punto y en que casos no lo se...

http://es.wikipedia.org/wiki/BASIC


----------



## thenot (Jul 3, 2010)

ezavalla dijo:


> Bueno...si opinás así, decíselo a los cientos o miles de programadores que desarrollaron el kernel de LINUX o FreeBSD o algunos de los unixces o aún del mismo Windows. Te aseguro que te van a mirar así ""...bueno...no solo te van a mirar...
> 
> 
> 
> ...



Bueno aquí yo me quedo sin palabras.. que tienen que ver los desarrolladores de windows o de linux o con programar un microprocesador????? como dije al parecer, para mi, ser un profesional en esto no es lo mismo que para ud. yo conozco gente profesional que se dedica a esto (Programar MICROCONTROLADORES!) por ello doy mi opinión.
Y no me digas que cuando uno la única herramienta que tiene es un martillo todo se parece a un clavo, conmigo estas muy equivocado, soy Ing. de ejecucion en Computacion e Informatica, asi que de lenguajes de programación no me vas a venir a dar charla, si digo que C y basic son iguales, lo digo desde mi punto de vista y para el uso que yo le doy. Una función de C o basic para mi es algo que no conozco (como esta programado) por lo cual no es algo de confianza para mi el saber si es preciso o no (cuando lo requiero), por ello utilizo asm, al fin al hablar de que algo no tenga precision, hablo de lo que mayormente se hace acá, y como se dijo ya, osea cosas que hacen hobbistas, o sea prender un led, hacer una alarma o que se yo, para ello me quedo con basic, y si hay alguna función que necesite y no este en basic o en el programa que uso, me aplico al C, claro si es que la tiene. Para cosas mas precisas o cuando la funciones que necesito no están, el asm es del único que me puedo fiar.
Aclaro: Digo esto para programar microcontroladores, para programar en pc se habla de otra cosa que no entra en este topic!!!:enfadado:
De lo que e leído con Lubeck es el que quien mas concuerdo en todo.


----------



## cosmefulanito04 (Jul 4, 2010)

thenot dijo:


> ...que tienen que ver los desarrolladores de windows o de linux o con programar un microprocesador????? ....



Todo, ¿o acaso los kernel de linux o windows no se basan en la arquitectura IA32?



thenot dijo:


> ...Una función de C o basic para mi es algo que no conozco (como esta programado) por lo cual no es algo de confianza para mi el saber si es preciso o no (cuando lo requiero), por ello utilizo asm....



Depende de como programes vos, si lees los mensajes anteriores notaras la diferencia, fijate en el codigo que presenta Tomasito y en el codigo que presento yo, en uno ya esta todo digerido por librerias del IDE, en cambio en el otro todas las funciones se hicieron a pedal de la misma forma que lo harias con assembler, sin preocuparte por la pila, que registros usar, etc y en dichas funciones si sabes lo que estas haciendo.

Y por ultimo mira el codigo que presenta lubeck, ¿te parece lo mismo basic que C?



			
				lubeck dijo:
			
		

> Entonces con el ejemplo de Tomasito se podria decir que esta apreciacion no es valida??? o mas bien tambien aplicada a C???



Nuevamente, dependera del grado de compromiso con el que quieras meterte vos, si usas librerias ya definidas, es muy probable que con otros modelos de uC no te sirvan, pero si usas tus propias funciones tal como detalle arriba, la modificacion de ese codigo hecho para un 8051 (uC viejo), es muy sencillo pasarlo para que funciones en un ARM, porque las funciones son propias y se como funcionan.

Eso es una ventaja que te puede dar C, la de elegir hasta que punto me involucro con el hard.


----------



## lubeck (Jul 4, 2010)

> Bueno, puedo aportar mi granito de arena desde lo que sé, que es C para arduinos.


Esto es lo que no me queda muy claro.....
Según lo que entendí es para arduino o puedo agarrar ese código para un pic16f877?

Ahora comparando los archivos HEX para el del LCD que puse en el mensaje 26 seria este


```
:10000000B2016B28A700071187108710831607110C
:10001000871087100F30870583122708B2182E2803
:100020003A30A100983052203330A60042201330DD
:10003000A100883052204220643051204220643098
:1000400051202230A600422028302D200C302D20B7
:1000500006302D20B21427082E283214A600321C98
:100060003C288710033C031C412841200730A10095
:10007000D0305220031408003214FE3C03196628C5
:100080008714321C321007150F3087052608F03907
:1000900087040711A60E321842283230512003146B
:1000A0000800A101E83EA000A109FC30031C5B2868
:1000B000A00703185828A0076400A10F582820188B
:1000C0006128A01C6528000065280800831303131D
:1000D000831264000800FE308A01022001308A0188
:1000E0000220FE308A01022001308A0102204C30B9
:1000F0008A01022075308A01022062308A010220C2
:1001000065308A01022063308A0102206B308A0147
:1001100002203A308A01022020308A010220423037
:100120008A0102206F308A01022074308A01022085
:100130006F308A0102206E308A01022063008A013A
:020140009E28F7
:02400E007D3FF4
:00000001FF
```
se podria comparar si el de C es menor y se pudiera decir que si es mas chico es mas rapido o no seria comparable????

Tomasito:
Por otro lado yo tengo una interface Phidget(similar a arduino) que su driver es una libreria .dll para Basic o C y en Basic es mil veces mas sencillo utilizarla que en C... arduino no es similar???


----------



## Eduardo (Jul 4, 2010)

thenot dijo:


> ... Una función de C o basic para mi es algo que no conozco (como esta programado) por lo cual no es algo de confianza para mi el saber si es preciso o no (cuando lo requiero), por ello utilizo asm, al fin al hablar de que *algo no tenga precision*, hablo de lo que mayormente se hace acá, y como se dijo ya, osea cosas que hacen hobbistas, o sea prender un led, hacer una alarma o que se yo, para ello me quedo con basic, y si hay alguna función que necesite y no este en basic o en el programa que uso, me aplico al C, claro si es que la tiene. *Para cosas mas precisas* o cuando la funciones que necesito no están, el asm es del único que me puedo fiar.


Serías tan amable de aclarar cual es tu concepto de *"precisión"*?

Porque si tomamos literalmente ese párrafo, estarías responsabilizando al lenguaje y su entorno de la incompetencia del programador.


----------



## Tomasito (Jul 4, 2010)

Lubeck: Ese código que postee, es exclusivo para arduino. Así nada más cómo está, compila en cualquier micro que tenga arduino.
Se podría portar a C para pic, pero habría que ver qué diferencias tienen los dos lenguajes, y de ahí, adaptar. Que sean los dos "C", no quiere decir que sean iguales.

Las demás preguntas muy bien no las entendí (acabo de despertar  ), si podés, explicate un poco más.

Edit: *Eduardo*: Calculo que se referirá a la velocidad de cálculo que tiene un micro al usar un lenguaje interpretado o compilado, contra usar lenguaje de máquina. Pero vuelvo a lo que dije anteriormente: ¿Vale la pena preocuparse *tanto*, cuando por unos dólares tenemos micros impresionantemente potentes?


----------



## lubeck (Jul 4, 2010)

> Las demás preguntas muy bien no las entendí (acabo de despertar  ), si podés, explicate un poco más.


Basicamente con tu mensaje aclaraste mi duda entre la diferencia de la Phidget con Arduino y su forma de operacion... creo que si detallamos mas ese punto nos salimos mucho del tema....

La pregunta iba orientada para saber si hay mas de un "modismo" de C igual que como lo hay en Basic hablando de micros...


----------



## Dr. Zoidberg (Jul 4, 2010)

lubeck dijo:


> La pregunta iba orientada *para saber si hay mas de un "modismo" de C* igual que como lo hay en Basic hablando de micros...



C hay uno solo: el C ANSI y todos los compiladores lo respetan si pretenden decir que "compilan lenguaje C".
Las diferencia sno está en el lenguaje, sino en las bibliotecas que acopañan al compilador, de las cuales hay un conjunto que es estándard y otro que es propio de cada fabricante.
Para los PICs, la mayoría de los compiladores están acompañados de una serie de bibliotecas que facilitan la programación para el uso de dispositivos externos al PIC, tal como displays LCD en 4 y 8 bits, I2C por software, comunicacione serie por software, etc, etc, etc.
Pero esos no son "modismos", son bibliotecas de soporte para cada tipo de procesador.


----------



## thenot (Jul 5, 2010)

Eduardo dijo:


> Serías tan amable de aclarar cual es tu concepto de *"precisión"*?
> 
> Porque si tomamos literalmente ese párrafo, estarías responsabilizando al lenguaje y su entorno de la incompetencia del programador.


creo que dejo bien claro en lo que expuse a que me refiero con precisión, "o sea prender un led, hacer una alarma o que se yo" para eso que expuse, acaso se requiere precisión? que eso se ejecute en cierto ciclo, o cada tantos ciclos pero justos, o que la lectura del sensor sea de una precisión inmensa? son cosas, que un poco de error en la ejecución "no importan en nada", o sera lo mismo que por ejemplo decodificar un tono?(se entiende lo de precisión??)
Y quizás C sea mas preciso que basic, pero YO no me fió. prefiero hacer yo mis propias rutinas, por ultimo hacerme mi propio compilador, que no me costaría mucho (claro obvio con lo que yo uso), pero con tener mis rutinas en assembler me basta y se exactamente lo que hago en cada ciclo, y en cosas como decodificar un tono, lo que hagas en cada ciclo si que importa. Si tu o alguien puedes hacer eso con en basic o C, bien yo no me fió y lo hago en Assembler. Pero si es algo como activar una carga cuando leo un sensor como para una alarma o al obtener datos por RF con algún modulo, no hay sentido hacerlo con ASM y para ello uso Basic, por que no C? bueno por que me gusta mas la estructura del Basic y su programación rápida, y si tengo recursos de sobra en memoria en el micro que me importa que gaste mas memoria o menos si esta haciendo lo que quiero?. Si no se entiende, no estoy diciendo que C sea malo o ineficiente y que basic también,o que basic sea mejor que C, solo es mi opinión personal y la forma en que hago mis cosas.

A todo esto, yo solo postie para explicar (por conocimiento) que los profesionales (quienes se dedican a esto y se ganan la vida con esto) usan el assembler como lenguaje cuando lo que quieren o les mandan a hacer tienen que tener una gran precisión (ojala se haya entendido a que me refiero con precisión), no como se dijo aqui que el C es un lenguaje para profesionales (quizás lo usen para cosas no tan "precisas"), lo demás fue mi opinión personal (que lo deje claro desde el comienzo) que supongo que a los que ya saben de esto no les interesa mucho.

Y con lo de:


			
				cosmefulanito04 dijo:
			
		

> Todo, ¿o acaso los kernel de linux o windows no se basan en la arquitectura IA32?


No se a que quieres llegar con eso, pero sera lo mismo un procesador que su velocidad es 20, 48 Mhz  a uno que se ejecuta a 1.6 GHz (por lo bajo)??? Son cosas muy pero muy distintas ....

Saludos a todos!!!


----------



## lubeck (Jul 5, 2010)

Yo creo que este tema no tiene para mas.....

ya se dijo lo mas importante... que cada uno formemos nuestra opinion.....

 y sobretodo... aquellos que se inician en esto de los micros... no pierdan la objetividad... que nadie les diga que es mejor o peor utilicen el que se ajuste a sus necesidades y sus planes...

y no se avergüencen de decir que usan uno u otro (sobretodo Basic que es mas atacado)...

Un ejemplo bien claro es que he desarrollado y vendido mas software en Basic que muchos que programan en C y ASM... o mas claro aun... cuantos hobbistas han programado en Basic mas micros que uno que programa en ASM...

Mi consejo: vean cuales son sus objetivos... para que lo nececitan... no que es mejor o peor....
si empiezan con Basic y su producto se vende... y sacan plata ese es el mejor si se deja de vender porque hay competencia en velocidad utilicen C y si de plano quieren que este en otro nivel haganlo en ASM... ese es el objetivo final la $$$$Plata$$$$$$.


----------



## Dr. Zoidberg (Jul 5, 2010)

thenot dijo:


> Y quizás C sea mas preciso que basic, *pero YO no me fió. prefiero hacer  yo mis propias rutinas, por ultimo hacerme mi propio compilador*, que no  me costaría mucho (claro obvio con lo que yo uso), pero con tener mis  rutinas en assembler me basta y se exactamente lo que hago en cada  ciclo



Hummmm.....con esa forma de pensar.....



thenot dijo:


> Y con lo de:
> 
> 
> 
> ...



Y cual es la terrible diferencia? La frecuencia de reloj?

NO HAY DIFERENCIA en la programación entre un uP y un uC. Punto
De hecho, es mas complicado programar para un procesador IA32 o IA64 que para un microcontrolador, por que al no tener integrados los periféricos hay que accederlos mapeados en espacio I/O o en memoria y usar recursos como DMA para algunos de ellos mas algunas otras cosas.

Hay programas que se ejecutaban en DOS en una 486 de 25MHz y los mismos  programas se ejecutan igual en un dual-core a 2.2GHz o más....solo que  más rapido. Los únicos que fallan son los que están hechos por los  "sabios" de la programación que para hacer un retardo usan un loop "en  assembler" u otro leguaje basados en los tiempos de ejecución de las  instrucciones en una versión particular de un procesador...en lugar de  usar alguno de los timers del 8253 o similar, que está para eso, o las  instrucciones de lectura de los contadores de ciclos de la CPU en uP mas  modernos.

Y todo esto puede hacerse en C, excepto las lecturas de los contadores de ciclos, que requieren un par de instrucciones en assembler...que pueden embeberse dentro del código C.


----------



## thenot (Jul 5, 2010)

ezavalla dijo:
			
		

> thenot dijo:
> 
> 
> 
> ...


Con esa forma de pensar se cambian las cosas, y no te quedas estancado en lo mismo, o acaso si tienes un problema, esperas que alguien que piense = que tu te haga las cosas???? me daría pena saber que piensas así. Para mi que los que pensaron en arduino son tontos......

Por lo demás no seguiré discutiendo, aya uds. si dicen que es lo mismo programar un pc o un microcontrolador, como dije no me van a venir a dar clases, que ya las tuve..

Finalmente ,lo que dijo Lubeck en su ultimo comentario es la mejor conclusión que se puede sacar a este tema.

Con esto me despido, seguire trabajando mejor  ..

Saludos!!


----------



## Dr. Zoidberg (Jul 5, 2010)

thenot dijo:


> Con esa forma de pensar se cambian las cosas, y no te quedas estancado en lo mismo, o acaso si tienes un problema, esperas que alguien que piense = que tu te haga las cosas???? me daría pena saber que piensas así.



Seee...por eso voy a diseñar y construir mi propio microcontrolador, por que no me fío de lo que hace Microchip y yo se mucho mas que que todos los ingenieros y científicos que tienen trabajando ahí....

Psssss......


----------



## thenot (Jul 5, 2010)

y que esperas?? si sabes del tema no te cuesta nada.. quizás les puedas hacer la competencia. Yo se del tema de programación así que no me cuesta mucho trabajo hacer un compilador, pero si no me fió de lo que hace microchip bueno jodido estoy, no tengo grandes conocimientos en electrónica (no es mi campo) y menos las herramientas para ello, lo contrario que pasa con lo de programación, tengo el conocimiento y las herramientas, ganas y mente para trabajar.


----------



## lubeck (Jul 5, 2010)

> por eso voy a diseñar y construir mi propio microcontrolador, por que no me fío de lo que hace Microchip y yo se mucho mas que que todos los ingenieros y científicos que tienen trabajando ahí....



Lo pregunto en buen plan EZ....
es cierto eso o muy apegado???

ya me había dado cuenta de que tienes muchos conocimientos en la materia... pero tantos???
por acá conozco un ingeniero que estudio en Alemania en no se que cosas de la fabricacion de integrados y materia primas y da cursos de no se que en no se cuantas partes del mundo... bien y te podria interesar que se contactara contigo....
si estas interesado le podria echar una llamada para que se conozcan y ahi ustedes se entienden ... por que yo no le entiendo ni una palabra de lo que habla solo se que si es Español j...

lo encontre, no creo que le importe si pongo estos datos... jejej
http://www.cinvestav.mx/Administraci%C3%B3n/Directorio/tabid/172/language/es-MX/Default.aspx
mmmmmmmmm... lo pense bien.... habia puesto el nombre pero si estas interesado te lo mando por otro medio y le hablo... da cursos en ese centro de investigacion...
Saludos


----------



## cosmefulanito04 (Jul 5, 2010)

> Lo pregunto en buen plan EZ....
> es cierto eso o muy apegado???



Me parece que esta siendo ironico.



> > Todo, ¿o acaso los kernel de linux o windows no se basan en la arquitectura IA32?
> 
> 
> No se a que quieres llegar con eso, pero sera lo mismo un procesador que su velocidad es 20, 48 Mhz a uno que se ejecuta a 1.6 GHz (por lo bajo)??? Son cosas muy pero muy distintas ....



Vos pusiste esto:



> ...que tienen que ver los desarrolladores de windows o de linux o con programar un microprocesador????? ....



Yo te respondo, no es asi, los kernel de linux por lo menos (el de windows no sabria decirte, por ser privado), estan hechos en C y assembler.

Vamos por pasos, que es la arquitectura IA32:

http://es.wikipedia.org/wiki/IA-32

En resumen, todo uP de 386 para adelante se puede decir que pertenenecen a esa arquitectura, salvo los IA64 que casi estan discotinuados.

Aca tenes info sobre el kernel de linux:

http://es.wikipedia.org/wiki/Núcleo_Linux#Lenguajes_de_programaci.C3.B3n

Y si no sabes de que la juega un kernel, aca tenes info:

http://es.wikipedia.org/wiki/Núcleo_(informática)

Basicamente es el encargado de administrar los recursos de la Pc, ahora si C fuera tan malo, o mejor dicho, si fuera tan desconfiable, ¿como los programadores pudieron elegir semejante lenguaje para encargarse de una parte tan importante del SO que es el kernel?


----------



## Tomasito (Jul 5, 2010)

thenot dijo:


> Con esa forma de pensar se cambian las cosas, y no te quedas estancado en lo mismo, o acaso si tienes un problema, esperas que alguien que piense = que tu te haga las cosas???? me daría pena saber que piensas así. *Para mi que los que pensaron en arduino son tontos......*



Y para mí la verdad que vos sos medio estúpido.
No te conozco, pero me parecés el típico tipo que porque estudió ingeniería es dios y se las sabe todas, y eso acá no va.

No tenés ni un poco de humildad al hablar, eso habla bastante de la dotación de neuronas que tendrás...
Si sabés programar un compilador, bien por vos, muchos de acá también pueden hacerlo y sin embargo no lo andan escribiendo en todos sus posts.

Y si no te fías de la supuesta "precisión" del C, entonces no sé para qué estudiaste. Que C no sea eficiente como assembler no te lo discuto, pero de ahí a que me digas que es "impreciso" porque _no sabés cómo está echo_, o qué otra cosa, hay un mar de diferencia. Y si tenés tus dudas, ¿qué te impide ver el código de fuente del compilador? Te cuento que tanto arduino como gcc y avr-gcc como muchos otros son de código abierto.


Y los que pensaron en Arduino no son ningunos tontos, le dieron una plataforma de desarrollo tanto a hobbistas como a profesionales, muy fácil de programar, barata, portable, y lo mejor de todo, opensource.


Perdón si agredí en el mensaje, pero me revienta ver gente así. :enfadado: (Los que me conocen en el foro saben que debe ser el primer mensaje en el que digo una mala palabra).



Saludos.


----------



## thenot (Jul 5, 2010)

Tomasito dijo:


> Y para mí la verdad que vos sos medio estúpido.
> No te conozco, pero me parecés el típico tipo que porque estudió ingeniería es dios y se las sabe todas, y eso acá no va.
> 
> No tenés ni un poco de humildad al hablar, eso habla bastante de la dotación de neuronas que tendrás...
> ...



No te voy a ofender ni nada, pero si sabes leer, veras claramente que es una ironía lo que recalcas, (que por mas encuentro que quienes crearon arduino es la gente que se necesita en este mundo) y si digo que soy capaz de hacer un compilador no digo por creerme ni por nada, como te digo si sabes leer, veras de que salio todo ello. Y nuevamente siguen mezclando lo que es programación de PC con programación de microcontroladores, si me preguntas por Pc te dijo C si me preguntas por micros, ya e dado la respuesta y e explicado mi punto de vista varias veces, y no me cuesta mirar como esta hecho, pero YO prefiero hacerlo de nuevo y tener un conocimiento 100% de lo hago.

y después de todo, parece que hay gente que le molesta que los demás tengan su opinión sobre que lenguaje usar, yo partí exponiendo, por conocimiento de gente profesional en el tema, que el lenguaje para profesionales es ASM(profesional= gente que se dedica, estudio y se gana la vida con esto), y luego expuse que es lo que yo uso, y di las razones, en ningún momento dije C es malo, Basic mas o menos y ASM es lo máximo, solo di mi opinión de por que uso uno y por que no uso otro, y al parecer a los demás (hablo por algunos) no les gusta eso y defienden su lenguaje con diente y garras y quieren que los demás piensen igual. Si yo pienso que C no es exacto en que te influye a ti? dejo claramente expresado que es mi opinión, y si quiero inventar la rueda para perfeccionarla (o echarla a perder), problema mio, es mi opinión y siempre e escuchado que todas las opiniones son validas cuando se tienen argumentos, los mio son no me fio de C ni de Basic y me fio de ASM cuando requiero precisión. Esta es la no se que vez que explico lo mismo, espero esta vez se entienda mi postura.


----------



## lubeck (Jul 5, 2010)

> Me parece que esta siendo ironico.


??????????

EZ yo lo digo en serio... y no digo mas... si te sirve Adelante la esposa de el y la mia eran uña y mugre en la escuela yo poco lo conozco pero si lo suficiente para saber que es buen tipo....

Saludos...


----------



## Dr. Zoidberg (Jul 5, 2010)

lubeck dijo:


> Lo pregunto en buen plan EZ....
> es cierto eso o muy apegado???



Todo bien! Te pido disculpas pero me olvidé de activar el modo <ironia> cuando puse ese comentario 

Fué tan solo para decir: "por que pretendería yo, pobre e ignorante mortal, hacer algo que los grupos de especialistas vienen haciendo - y muy bien -  desde hace muchísimos años? Es preferible que utilice lo que ellos ya han construido y aporte en otras áreas mas cercanas a mi nivel raciocinio, a justificar mis probres conocimientos tratando de re-inventar la rueda a cada paso que debo dar para poder decir...soy igual o mejor que ellos!"

En fin...el que quiera entender...que entienda.


----------



## cosmefulanito04 (Jul 5, 2010)

thenot dijo:


> No te voy a ofender ni nada, pero si sabes leer, veras claramente que es una ironía lo que recalcas, (que por mas encuentro que quienes crearon arduino es la gente que se necesita en este mundo) y si digo que soy capaz de hacer un compilador no digo por creerme ni por nada, como te digo si sabes leer, veras de que salio todo ello. Y nuevamente siguen mezclando lo que es programación de PC con programación de microcontroladores, si me preguntas por Pc te dijo C si me preguntas por micros, ya e dado la respuesta y e explicado mi punto de vista varias veces, y no me cuesta mirar como esta hecho, pero YO prefiero hacerlo de nuevo y tener un conocimiento 100% de lo hago.
> 
> y después de todo, parece que hay gente que le molesta que los demás tengan su opinión sobre que lenguaje usar, yo partí exponiendo, por conocimiento de gente profesional en el tema, que el lenguaje para profesionales es ASM(profesional= gente que se dedica, estudio y se gana la vida con esto), y luego expuse que es lo que yo uso, y di las razones, en ningún momento dije C es malo, Basic mas o menos y ASM es lo máximo, solo di mi opinión de por que uso uno y por que no uso otro, y al parecer a los demás (hablo por algunos) no les gusta eso y defienden su lenguaje con diente y garras y quieren que los demás piensen igual. Si yo pienso que C no es exacto en que te influye a ti? dejo claramente expresado que es mi opinión, y si quiero inventar la rueda para perfeccionarla (o echarla a perder), problema mio, es mi opinión y siempre e escuchado que todas las opiniones son validas cuando se tienen argumentos, los mio son no me fio de C ni de Basic y me fio de ASM cuando requiero precisión. Esta es la no se que vez que explico lo mismo, espero esta vez se entienda mi postura.



Nadie te esta atacando, simplemente tratamos de refutar cosas que no son del todo correcta a manera de ver de varios usuarios, incluyendome.

Me parece perfecto que uses assembler, pero no confundamos profesionalismo en funcion del lenguaje que voy a usar, porque por lo menos para mi eso es un error, no importa el lenguaje que uses, ya sea assembler, C, C++, o basic, si con cualquiera de ellos conseguis el objetivo que te propusiste, todas las opciones son mas que validas.

De hecho, la manera que tengo de ver a un Ing. es aquel que se encarga de hacer las cosas de la manera mas practica y sin dar vueltas, y obteniendo los mismos resultados.


----------



## thenot (Jul 5, 2010)

cosmefulanito04 dijo:


> Nadie te esta atacando, simplemente tratamos de refutar cosas que no son del todo correcta a manera de ver de varios usuarios, incluyendome.
> 
> Me parece perfecto que uses assembler, pero no confundamos profesionalismo en funcion del lenguaje que voy a usar, porque por lo menos para mi eso es un error, no importa el lenguaje que uses, ya sea assembler, C, C++, o basic, si con cualquiera de ellos conseguis el objetivo que te propusiste, todas las opciones son mas que validas.
> 
> De hecho, la manera que tengo de ver a un Ing. es aquel que se encarga de hacer las cosas de la manera mas practica y sin dar vueltas, y obteniendo los mismos resultados.



Si, entiendo y lo comparto, como dije, yo uso ASM si lo que necesite hacer lo pide. La mayoría de las cosas que hago para mi no requieren de una precisión alta, por lo cual uso Basic, si lo que hago merece tener buena precisión (como lo que estoy haciendo ahora de decodificar un tono dtmf) me aplico con ASM. Por otra parte si es para algún trabajo pagado que me pidan, este lo hago en ASM y que por lo general debo hacerlo en ello ya que se trata de mediciones de sensores muy rápidas y salidas de estas también.

A todo esto alguien a usado JAL?? que me pidieron hacer un trabajo en ese lenguaje una vez y querían la documentación, pero como le dije que eso era mas caro (entregando la documentación) me dijeron que lo hiciera en el lenguaje que quisiera, así que ni mire ese lenguaje.


----------



## Eduardo (Jul 5, 2010)

Por las dudas quiero aclarar primero mi posicion: El lenguaje de *programacion general* para microcontroladores *debe ser C*.

Pero C como herramienta general, no como *unica* herramienta. Porque ese parece ser el punto donde gira esta discusion bizantina: *Usar "Un solo libro"*.

Una persona puede programar en C o en Basic si prefiere, pero *debe tener tambien un profundo conocimiento de Assembler*. 

Por que? --> Porque solo conociendo bien Assembler vas a entender bien el hardware que dispones. 
Y necesitas conocer los elementos que estas usando no solo para saber *como* hacer, tambien para cuando no anda saber *que puede ser* y *como* solucionarlo.


------------------------------------------------------

Se habla de velocidad, "precision" y tamaño del codigo generado con los diferentes lenguajes. Hasta donde es cierto? 
Para aclarar en este sentido lo mejor es usar un ejemplo con *PicBasicPro*.


Esto esta sacado de los samples de PBP, es un "Hello world" con un LCD.

```
Pause 500       ' Wait for LCD to startup

loop:
   Lcdout $fe, 1   ' Clear LCD screen
   Lcdout "Hello"  ' Display Hello
   Pause 500       ' Wait .5 second

   Lcdout $fe, 1   ' Clear LCD screen
   Lcdout "World"
   Pause 500       ' Wait .5 second

   Goto loop       ' Do it forever
```
Muy legible y elegante como era de esperar.
Hay que destacar que ahi, *los unicos elementos propios del lenguaje Basic* son la etiqueta "loop:" y el "Goto".


Ahora vamos a ver que genera al compilar.
Primero se genera esto:

```
; PICBASIC PRO(TM) Compiler 2.47, (c) 1998, 2006 microEngineering Labs, Inc. All Rights Reserved.
_USED            EQU    1

    INCLUDE    "C:\ARCHIV~1\MCS\PBP247\16F628.INC"

RAM_START               EQU    00020h
RAM_END                 EQU    0014Fh
RAM_BANKS               EQU    00003h
BANK0_START             EQU    00020h
BANK0_END               EQU    0007Fh
BANK1_START             EQU    000A0h
BANK1_END               EQU    000EFh
BANK2_START             EQU    00120h
BANK2_END               EQU    0014Fh
EEPROM_START            EQU    02100h
EEPROM_END              EQU    0217Fh

R0                      EQU    RAM_START + 000h
R1                      EQU    RAM_START + 002h
R2                      EQU    RAM_START + 004h
R3                      EQU    RAM_START + 006h
R4                      EQU    RAM_START + 008h
R5                      EQU    RAM_START + 00Ah
R6                      EQU    RAM_START + 00Ch
R7                      EQU    RAM_START + 00Eh
R8                      EQU    RAM_START + 010h
FLAGS                   EQU    RAM_START + 012h
GOP                     EQU    RAM_START + 013h
RM1                     EQU    RAM_START + 014h
RM2                     EQU    RAM_START + 015h
RR1                     EQU    RAM_START + 016h
RR2                     EQU    RAM_START + 017h
_PORTL                   EQU     PORTB
_PORTH                   EQU     PORTA
_TRISL                   EQU     TRISB
_TRISH                   EQU     TRISA
    INCLUDE    "LCD.MAC"
    INCLUDE    "C:\ARCHIV~1\MCS\PBP247\PBPPIC14.LIB"

    PAUSE?C    001F4h

    LABEL?L    _loop
    LCDOUT?C    0FEh
    LCDOUT?C    001h
    LCDOUT?C    048h
    LCDOUT?C    065h
    LCDOUT?C    06Ch
    LCDOUT?C    06Ch
    LCDOUT?C    06Fh
    PAUSE?C    001F4h
    LCDOUT?C    0FEh
    LCDOUT?C    001h
    LCDOUT?C    057h
    LCDOUT?C    06Fh
    LCDOUT?C    072h
    LCDOUT?C    06Ch
    LCDOUT?C    064h
    PAUSE?C    001F4h
    GOTO?L    _loop

    END
```
*Ha generado un programa en Assembler* con una serie de directivas y declaraciones antes de nuestro codigo.
Si miramos la parte correspondiente al codigo original, el compilador ha expandido la instruccion Lcdout "Hello" en una serie de macros.
La definicion de estos macros esta en LCD.MAC y su expansion llama a una rutina *escrita en Assembler* que se encuentra en la libreria PBPPIC14.LIB      


Al compilarse este archivo ASM (lo podriamos hacer "a mano" con MPASM), los macros son expandidos y ejecutados generando esto:

```
MOVLW 0x1        ;     PAUSE?C 001F4h
     MOVWF 0x23
     MOVLW 0xf4
     CALL 0x53
                      ;
                      ;     LABEL?L _loop
     MOVLW 0xfe       ;     LCDOUT?C    0FEh
     CALL 0x2
     MOVLW 0x1        ;     LCDOUT?C    001h
     CALL 0x2
     MOVLW 0x48       ;     LCDOUT?C    048h
     CALL 0x2
     MOVLW 0x65       ;     LCDOUT?C    065h
     CALL 0x2
     MOVLW 0x6c       ;     LCDOUT?C    06Ch
     CALL 0x2
     MOVLW 0x6c       ;     LCDOUT?C    06Ch
     CALL 0x2
     MOVLW 0x6f       ;     LCDOUT?C    06Fh
     CALL 0x2
     MOVLW 0x1        ;     PAUSE?C 001F4h
     MOVWF 0x23
     MOVLW 0xf4
     CALL 0x53
     MOVLW 0xfe       ;     LCDOUT?C    0FEh
     CALL 0x2
     MOVLW 0x1        ;     LCDOUT?C    001h
     CALL 0x2
     MOVLW 0x57       ;     LCDOUT?C    057h
     CALL 0x2
     MOVLW 0x6f       ;     LCDOUT?C    06Fh
     CALL 0x2
     MOVLW 0x72       ;     LCDOUT?C    072h
     CALL 0x2
     MOVLW 0x6c       ;     LCDOUT?C    06Ch
     CALL 0x2
     MOVLW 0x64       ;     LCDOUT?C    064h
     CALL 0x2
     MOVLW 0x1        ;     PAUSE?C 001F4h
     MOVWF 0x23
     MOVLW 0xf4
     CALL 0x53
     GOTO 0x7d        ;     GOTO?L  _loop
```
Donde cualquiera que entienda un poco de Assembler se dara cuenta que ese codigo *es inobjetable*, es lo mismo que habria escrito cualquier programador. Con la gran ventaja que PBP se encargo de escribir toda la parte "molesta" por nosotros y *tanto PAUSE (0x53) como LCDOUT (0x2) vienen enlatadas escritas en Assembler* ( son igual de optimas y estan antes en ese listado, pero no las puse para que no se haga tan largo).

De mas esta decir que este es un ejemplo particular. El proceso de generacion de codigo ejecutable *tiene muchas mas opciones*.


Con un ejemplo en C seria bastante "parecido", solamente que en general se van a necesitar mas declaraciones y que en C no se hace una traduccion tan "literal" del codigo que hemos escrito sino que puede sufrir modificaciones de acuerdo al nivel de optimizacion, generando un codigo superior cuando se trata de sentencias complejas. 


*Donde esta el problema con los lenguajes de alto nivel?* Si de *lo que hemos escrito* genera un codigo impecable?
--> Pues el "problema" esta en lo que *no* hemos escrito.

Lo que no hemos escrito son precisamente las *rutinas de libreria*, y esas son las responsables del tamaño del programa y la velocidad (suponiendo que uno no esta usando algoritmos horribles )

En general, estas rutinas* estan muy bien escritas*. Y si dan problemas, es *cuando son demasiado generales *y pierden tiempo+bytes analizando diferentes condiciones cuando tenemos solo una.
Otra causa puede ser la "precision de Thenot", si se necesitan tiempos exactos y la libreria no fue escrita pensando en eso --> No way.


*Ahi es donde uno tiene que "customizar" su entorno de trabajo. Es decir, escribir macros y rutinas propias a gusto y necesidad.*
Pero estos "tuneos" no hay que hacerlos necesariamente en Assembler y mucho menos escribir *el programa entero* (señal de muuucho tiempo libre )

Dependiendo del nivel de la rutina, *el Basic resulta insuficiente* porque los tipos de variable y modos de direccionamiento son limitados (no maneja punteros, no se puede forzar el tipo de variable, no hay puntero a funcion...).
En consecuencia, para una rutina de bajo nivel, Basic casi siempre terminara llamando una rutina escrita originalmente en otro lenguaje (en el caso de PBP es en Assembler) --> *Esto no pasa en C*, salvo por algunas instrucciones muy particulares (Murphy no falla) se puede escribir un sistema operativo completo sin necesidad de Assembler.


En esto ultimo ya entran los gustos personales --> Yo por ejemplo uso C, pero en los puntos donde no me gusta lo generado o se me cantan las b*l*s le inserto un bloque en Assembler.


Conclusion: Cuanto mas alto el nivel del lenguaje mas comodo laburas, pero mas limitado estas ==> Si el tema realmente te interesa *debes manejar bien* tambien Assembler y C.


----------



## lubeck (Jul 5, 2010)

> Conclusion: Cuanto mas alto el nivel del lenguaje mas comodo laburas, pero mas limitado estas ==> Si el tema realmente te interesa debes manejar bien tambien Assembler y C.



Estoy deacuerdo...
Era el punto que faltaba y nunca mencionamos....

Es muy necesario conocer los tres aunque unos mas superficialmente que otros... y desconozco si hay otro mas sencillo en cuanto a micros....

Pongo un codigo de ejemplo de pbp (picbasic pro) en el que se incrusta ASM


```
led     var     PORTB.7
wsave   var     byte $20 system
ssave   var     byte bank0 system
psave   var     byte bank0 system

Goto start              

define  INTHAND myint

' Assembly language interrupt handler
asm

; Save W, STATUS and PCLATH registers, if not done previously
myint   movwf   wsave
        swapf   STATUS, W
        clrf    STATUS
        movwf   ssave
        movf    PCLATH, W
        movwf   psave

; Insert interrupt code here
; Save and restore FSR and any other registers used

        bcf     _led            ; If interrupt, turn off LED
        bcf     INTCON, 1       ; Clear interrupt flag

; Restore saved registers
        movf    psave, W
        movwf   PCLATH
        swapf   ssave, W
        movwf   STATUS
        swapf   wsave, F
        swapf   wsave, W

        retfie                  ; Return from interrupt

endasm

start:  
   TRISB = $7f             ' LED out, rest in
   OPTION_REG = $7f        ' Enable PORTB pullups
   INTCON = $90            ' Enable INTE interrupt
   led = 1                 ' Turn LED on

loop:   
   If led = 1 Then loop    ' Wait here while LED is still on

   Pause   500             ' Wait .5 seconds
   Goto    start           ' Start over (turn LED back on)
```


Saludos...

Pd. Excelente análisis Eduardo según mi punto de vista....


----------



## Tomasito (Jul 5, 2010)

Muy buen post Eduardo!
Estaría bueno adaptarlo a un artículo para la wiki del foro, ¿no? Este tipo de cosas hay que ir poniéndolas, si no, se pierden . Para eso está la wiki a fin de cuentas 



PD: thenot: No sé en qué entorno estarás trabajando, pero con un micro y compilador más o menos decentes, podés decodificar DTMF por software.


----------



## thenot (Jul 6, 2010)

Tomasito dijo:


> PD: thenot: No sé en qué entorno estarás trabajando, pero con un micro y compilador más o menos decentes, podés decodificar DTMF por software.



Sep, eso lo se, pero dado que tendré que poner bastante código ASM incrustado, prefiero hacerlo todo en ASM y así yo me entiendo mejor.


----------



## luis_e (Jul 6, 2010)

Yo he usado los 3 lenguajes por bastante tiempo y estas son mis conclusiones:

ASM:
El asm es especfico de cada familia de microcontroladores, osea que si cambias de familia vas a tener que aprender nuevas instrucciones. La gran ventaja que tiene es que se tiene el control perfecto de lo que hace el microcontrolador. La desvantaja es que hay que escribr una gran cantidad de codigo, que la mayoria de las veces genera un gran problema a la hora de determinar en donde hay un error. La mayoria de las veces no es necesario un supercontrol de lo que hace el pic. Para trabajar bien con este lenguajes es necesario conocer muy bien el micro, ya que se trabaja con los registros de pila y todos los demas especificos de micro. Lo que tiene este lenguaje es que se usa menos memoria.

BASIC:
Lo mejor de este lenguaje es la facilidad con la que se trabaja. Con un par de lineas hace bastante. El problema es que no tenes la minima idea de lo que hace el micro, esto puede ser inportante o no, dependiendo de lo que quieras hacer. No se sabe el tiempo que se demora en ejecutar una instruccion ni nada. Las librerias no son tan bien hechas como se imaginan, son mas ineficientes de lo que creen. Se los digo porque yo mismo me puse a estudiar el asm que genera para manejar una lcd grafica y esta muy lejos de serlo. Ademas genera mucho codigo. Algo que hay que decir que creo que nadie dijo, es que al tener las librerias como las tiene, son inmodificables, osea que si tu aplicacion requiere algo que no esta soportado por la libreria, tenes que hacer todo a pata. Basic es ideal para el que quiere hacer algo no muy complejo, en donde no se requiera utilizar interrupciones y el tiempo no sea un problema. Ademas las instrucciones bloquean el micro (no se como se llama esto realmente), osea, si vos estas esperando datos por el puerto serie, el micro queda clavado ahi. Para usarlo no es muy necesario el conocimiento del funcionamiento interno del micro, por ahi si el de algunos registros especificos. 
Otra cosa, es medio complicado ver el asm que genera. Y se pueden incrustar instrucciones en asm, pero se complica.

C:
Es el lenguaje que uso actualmente, y me parece el mejor de todos. La sintaxis no es muy complicada, las funciones "nativas" del lenguajes son muy buenas, el codigo nenerado es de un nivel medio. Trae muchas librerias, que se pueden modifcar a gusto. Como decian por ahi, a veces hay que hacer todo a pata, otras no. Personalmente, las prefiero hacer yo, para saber exactamente como funcionan.
No se tiene mucho control sobre el micro, pero se puede saber que es lo que hace, porque se puede ver completamente el asm generado.
Es necesario tener un poco bastante de conocimiento del micro, porque se trabaja directamente sobre el. (esto depende del compilador usado).
La velocidad con la que se ejecuta el codigo es bastante alta. Algunos compiladores tiene optimizadores de codigo que lo reducen bastante y aumentan su velocidad, aunque en algunas cosas se ve reducida.
Tambien se puede incrustar instrucciones en asm.

En cualquiera de los 3 lenguajes es necesario saber en mayor o menor medida asm y conocer el micro, porque por mas de ser algunos lenguajes de alto nivel, se esta trabajando en una aplicacion de bajo nivel, y lidiamos constantemente con los registros y el funcionamiento del micro.

Yo uso y recomiendo c, me gusta mas que lo otros, porque es simple y se puede adaptar perfectamente a lo que necesitamos. Te permite un gran control sobre el micro sin sacrificar memoria y sin estar escribieendo un millon de lineas.

El hecho de usar asm hoy en dia, me parece que es querer complicar las cosas. Yo hago cosas medio complicadas en c y no tengo problemas. La unica aplicacion justificable que le encontre al asm, es en la generacion de señal de video, en los juego pictetris y picpong, sobre un pic16f84. en esa aplicacion en especial era requerido asm, para tener un super control de lo que hace el micro. Nunca se hubiera podido hacer en c y ni hablar en basic. 
Salvo que se necesite un super control del micro, no es necesario asm. Yo prefierro centrarme en mejorar la aplicacion en si (trabajando con c), antes que mejorar el codigo en asm. Ojo, a mi me gusta optimizar al maximo la forma de trabajo de un programa, pero lo hago en la forma de trabajo del programa, no en la reduccion de las instrucciones.
Ademas, el programa en asm es demasiado largo, y se dificulta depurarlo. Hice programas en c de 3000 o 4000 lineas, que ocupan mas de 20000 instrucciones en asm, imaginense tener que escribir y depurar todo eso en asm, se complica en c nomas... A la hora de buscar donde hay un error, creanme, se volvoria muyyyyy dificil.

Por ejemplo, para decodificar DTFM, con c se puede hacer muy facil, tanto completamente en software como usando harware. Y no es necesario agregar nada en asm.

*Conclusion final:*
*
Si queres hacer algo sencillo con un pic, de vez en cuando, de forma facil, usa BASIC.
Si queres dedicarte a hacer programas sencilos o complicados, usa C, y aprende asm, porque lo vas a necesitar.
Si queres complicarte, renegar mucho, demorar mucho tiempo, escribir mucho y entender el funcionamiento del pic, usa ASM.*


----------



## Alcocer Garcia Felix Davi (Mar 30, 2015)

Hola saludos a todos tenia una consulta , estoy aprendiendo a programar en asembler , queria saber las ventajas de programar en asembler sobre pbp y pic compiler mikrokc , ya que por algo aun funciona el mplab gracias o estoy haciendo un esfuerzo en vano gracias?


----------



## D@rkbytes (Mar 30, 2015)

Son muchas las ventajas del ensamblador sobre todos los lenguajes, se puede decir que el ensamblador es el padre de todos los lenguajes, pero para que las comprendas necesitas estudiarlo.
A muchos no les gusta simplemente porque no lo entienden o porque se les hace tedioso trabajar con él.
Sin embargo, su comprensión te hará entender muchas cosas que con los lenguajes de alto nivel nunca comprenderás.

MPLAB aún se utiliza porque no solo sirve para escribir programas en ensamblador.
MPLAB es un entorno de desarrollo integrado (IDE) que soporta varios lenguajes de programación.
Ahora se utiliza mucho para escribir programas en lenguaje C, pero también soporta el Basic de algunos compiladores, por ejemplo: PBP.

Y para que sepas las diferencias entre los diferentes entornos, tienes que usarlos y ver sus ventajas y desventajas.
A mi no me gusta opinar sobre cual es mejor porque cada quien tiene preferencias distintas.
Simplemente, cuando algo no me gusta lo dejo de usar.


----------



## COSMICO (Mar 30, 2015)

Muy cierto.


----------



## papirrin (Mar 30, 2015)

> queria saber las ventajas de programar en asembler sobre pbp y pic compiler mikrokc , ya que por algo aun funciona el mplab gracias o estoy haciendo un esfuerzo en vano gracias?



R.- Tambien toma en cuenta que tipo de proyectos vas a realizar, porque tambien depende de eso cual es el que te convendria aprender, porque digamos yo conozco los tres un poco cada uno, y te puedo decir que ensamblador lo uso un  1%, el lenguaje C un 30%, y el restante lo hago en basic por su facilidad y el tipo de proyectos que realizo.

de echo el ensamblador casi siempre lo uso dentro de basic o del C (embebido) cuando requiero de minimizar el tiempo de ejecucion y en muchas ocasiones es suficiente.


----------



## pandacba (Mar 30, 2015)

Es como en todos los sistemas, hay que ver hasta donde quieres llegar y que quieres hacer, para ciertas cosas el asambler es muy tedioso, pero para otras es imprescindible, conocer el assembler te permitira utilzar la capacidad del micro al 100% pero no en todas las ocaciones se necesita eso.
Para hacer un paralelo, por ejemplo el asemblerl de los micro Intel de la gama X86, te imaginas escribir determinados programas isntegramente en assembler? por ejemplo el sistema operativo? ojo no quiere decir que no se use, hay muchas subrutinas embebidas en assembler pero el resto esta escrito en lenguaje C
Es bueno conocer el asembler y alguno lenguaje de alto nivel, podras ser más flexible a la hora de programar, en mi caso que suelo utilzar rutinas de retardo en asembler, porque es algo que se maneja mejor en asembler que por ejemplo en lenguajes basic, no breves retardos, retardos prolongados, tengo unas subrutinas a las cuales le paso el parámetro necesario para obtener el retardo que deseo y resulta simple y muy efectivo, eso por poner algún ejemplo
Imagina en su momento cuando habia varios lenguajes C, par los x86, estaba borland, watcon, microsoft, pero tambien estaba el pascal, que luego fue Delphi y habia que ver cual se adecuaba mas a las necesidades, al comienzo probar uno u otro si se tenia tal posibilidad y adoptar uno
Aqui es exactamente igual, todo requiere tiempo y mucha paciencia, leer mucho devorarse cuanto documento exista sobre el miciro que queremos utilzar interactuar con otros programadores

Imagina que hoy existen otras posibilidades con otros lenguajes para estos micros populares, pero para otros microcontroladoes como el 8051, los micros de motorola, y lo de otros fabricantes solo habia assembler hasta el popular Z80 con el cual muchos se iniciaron no habia otra cosa que assembler para el 6505 de Rockwell no habia otra cosa que assembler, para la serie 05 hata la 011 motorola o por ejemplo los micros de Rubit que son muy buenos e interesantes, los micro de texas, que incluso te proveen una placa de desrrollo a costo reducido y mucha info pero se programan en assembler


----------



## cosmefulanito04 (Mar 31, 2015)

Yo recomiendo C para usarlo en la mayoría del proyecto que se realice y usar assembler en rutinas muy específicas que requieren un tiempo de ejecución crítico.


----------



## Alcocer Garcia Felix Davi (Mar 31, 2015)

Me han convencido con sus respuestas. Uso el Microcode con PICBasic. Es muy sencillo.
Existen mikroBasic Pro y muchos otros compiladores.

Estoy empezando con el ensamblador, además en paralelo empezado con el C, pero quisiera saber por q*ué* existe una gran gama de compiladores en C como C18, C8, C16, HI-TECH y mikroC.

¿Quisiera saber un poco sobre en que casos usar mikroC y PIC C Compiler?

Gracias.


----------



## cosmefulanito04 (Mar 31, 2015)

Un compilador de C, no es más que un traductor assembler y a la vez un traductor en código de máquina.

Tenés distintos compiladores según el hardware asociado, un hardware distinto es muy probable que implique instrucciones en assembler distintas, por lo tanto necesitará un "traductor" específico para ese hardware. 

Por otro lado, podés tener distintos compiladores para un mismo hardware (ej. x86, 8051, etc), pero c/compilador "traduce" de formas distintas, lo que implica que muchas veces un código en C puede tener muchísimas soluciones en assembler, es por eso que en rutinas muy críticas es mejor tomar el control del hardware uno mismo y evitar tiempos de pérdidas por una mala "traducción" o incluso aprovechar ciertos recursos del hardware que al "traductor" se le escapan.

Mí recomendación, de assembler aprendé lo necesario para poder realizar operaciones básicas, trabajar bien con los registros, acceder a la memoria mediante punteros, realizar un loop y trabajar con funciones/rutinas mediante el uso de CALL (o la variante según el hardware).


----------



## papirrin (Mar 31, 2015)

> Estoy empezando con el asembler , ademas en paralelo empezado con el C pero quisiera saber por q existe una gran gama de compiladores en C como C18 C8 C16 HItech microkaC . Quisiera saber un poco sobre en que casos usar MIcrokC y picccompiler gracias .



a mi me gusta el CCS, yo te recomiento que empieces con ese que es muy sencillo, despues cambias a cualquier otro que en si las instrucciones son muuuuy similares.

hay varios compiladores porque son diferentes estructuras de los pic o sea el de 8 bits es diferente al de 16 0 32 bits.

y aclara si lo que buscas es para microcontroladores PICs de microchip porque ya te estan comentando de otros como el x86 8051 z80 etc. que son totalmente diferentes


----------



## Meta (Abr 5, 2015)

Hola:

Para hacer tablas de la verdad igual a un 74HCxx o modificado a tu manera por poner un ejemplo, uso PIC con ASM.

Para proyectos muy pequeños como PIC tipo PIC12F509, PIC12F629 se suele usar ASM.

Proyectos grandes prefiero C, más portabilidad y depaso, te ahorras muchísimo tiempo. El C puedes añadirle bloques asm para mayor rendimiento en ciertas partes del código como los temporizadores y tiempos justo a raja tabla que en C no se puede hacer con los PI, es decir, precisión extrema, por poner ejemplos.

Por lo que veo, el C/C++ de MPLAB X con el C8 para los PIC18F es lo que recomiendo. X32 para los PIC32.

Hi-Tech está obsoleto y solo permite PIC de 18F.

En cuanto a CSS es muy bueno, pero muchas veces se tarda en actualizar algunas funciones de ciertos PIC, sobre todo los nuevos hasta un año y no lo puedes usar, a parte que no usa C estandar. Tienes que recurrir incrustar bloques en ASM dentro de C para modificar ciertos registros que en C no puedes porque todavía CSS no está preparado para ello.

Por eso recomiendo el oficial de Microchip como e lMPLAB X con su compilador de C oficial para los PIC de 8, 16 y 32 bits. Es de lo mejor.

Se ha hablado de programar ARM con el nuevo moderno lenguaje C# y hay proyectos sobre ello.

En C trapicheado de Arduino se usa bastante cada vez más.

En resumen.

C en general, lenguaje de alto nivel, por su mayor tiempo en hacer proyectos, portabilidad, modificacoines o actualizaciones de código rápido y otras muchas ventajas.

Saludos.


----------



## cosmefulanito04 (Abr 5, 2015)

Si no hay dependencia del tiempo, si algo es fácil en assembler, en C todavía es más fácil, salvo excepciones, como instrucciones raras que en C cuestan digerir.

Sobre lenguajes de alto nivel como C#, cero control de lo que pasa. Yo uso Java en un ARM bajo Linux y la verdad ni idea de lo que pasa, lo uso nada mas como interfaz de usuario, pero contra el gcc en procesamiento no le llega ni a los talones.


----------



## Meta (Abr 6, 2015)

Los lenguajes de alto nivel, precisamente es para no preocupar la programador de lo que pasa.

Al hacer una división en asm con un PIC. Tienes que preocuparte de poner hasta el en resto, en una posición de memoria,  ejjejejje.






Saludos.


----------



## cosmefulanito04 (Abr 6, 2015)

En una PC eso está muy bien, en un sistema embebido... mmmm 

Hay que tener un equilibrio, ni exagerar y hacer todo en assembler, ni perder el control absoluto de lo que pasa, salvo que realmente no importe y se necesite implementar algo "bonito" para el usuario.


----------



## Miembro eliminado 356005 (Abr 16, 2015)

pandacba dijo:


> Por ejemplo, el ensamblador de los micro Intel de la gama X86, ¿te imaginas escribir determinados programas íntegramente en ensamblador, por ejemplo el sistema operativo?


Yo no me lo imagino. Existe: *MenuetOS* (resumen en WIkipedia) Precisamente hoy ha salido la última actualización.

 Programación en 32 y 64 Bits en FASM
 GUI con resoluciones de hasta 1280x1024, en 16 millones de colores
 IDE: Editor/Macro Assembler para aplicaciones
 TCP/IP
 Aplicaciones de red incluidos servidores FTP/HTTP/MP3
 Forma libre para las ventanas de aplicaciones
 Reproductor de vídeo
 Reproductor de DVD/MP3
 Cliente HTTP
 Soporte para DVB-T
 Soporte para USB 2.0
 Soporte Multiprocesador, multitarea, multihilo
Y todo esto cabe en un disquete de 1.44 MB 

No es el único. Existe un derivado, llamado *KolibriOS*, que arranca en menos de 5 segundos


----------



## Saint_ (Abr 17, 2015)

Hace tiempo el la facultad en una materia programaros en asm para el x86 manejo de pantalla (modo testo y gráfico), interrupciones del bios y dos...periféricos de entada  como teclados, puertos paralelo, serie y mas...pero un sistema operativo en asm... *Señores me quito el sombrero ante eso.*


----------



## cosmefulanito04 (Abr 25, 2015)

Gracias a que Linux mostró el camino de la independencia de la arquitectura con C, hoy podemos usarlo en muchos desarrollos. 

Hasta tal punto se independizó,  que directamente descartó el uso del scheduler (administrador de tareas) que tienen los x86 por hard, si bien se pierde la ventaja del hard, se gana mucha compatibilidad.


----------



## Dr. Zoidberg (Abr 25, 2015)

Como siempre, lo verdaderamente inteligente no es convertirse en un ayatollah del C o del ASM, ni comenzar a buscar justificaciones esotericas que ocurren una vez cada 10 millones de años para justificar el uso del ASM sobre el C.
Lo inteligente, y por supuesto MUY DIFICIL, es dominar ambos lenguajes y balancear - si resulta necesario - su aplicacion en la solucion de un problema REAL... y en los problemas reales no participa el ego personal de decir "soy mas macho por que programo en ASM y exprimo los recursos del micro" ...y no participa por que hay que considerar las hs-hombre invertidas en el desarrollo en asm y el tiempo de salida al mercado usando uno u otro o la mezcla de ambos lenguajes.
Ahora bien... si algunp cree que tiene la "verdad" opinando desde un punto de vista del aficcionado o del hobbista, yo le recomiendo seriamente que se guarde la opinion hasta que conozca la realidad de los proyectos serios, a gran escala y en entornos muy competitivos.

PD: lo de exprimir al micro se da mediante mediciones en el contexto dr.la aplicacion y no mediante opiniones polarizadas que solo buscan mostrar la realidad que le interesa a cada uno.


----------



## Meta (Abr 25, 2015)

Hola:

¿Alguien exprime en asm su microprocesador de un PC?


Saludos.


----------



## papirrin (Abr 25, 2015)

Busca proyectos con el procesador 8086 o similares,seguramente hay varias decenas., es muy comun que muchos usen tecnologias antiguas para proyectos recientes porque son mas accesibles.

Tu pregunta tiene cientos de interpretaciones, es mejor si eres mas especifico.


----------



## cosmefulanito04 (Abr 25, 2015)

Meta dijo:


> Hola:
> 
> ¿Alguien exprime en asm su microprocesador de un PC?
> 
> ...



En procesamiento de imágenes/video, realmente vale la pena su uso puntual, ya que tenés instrucciones muy preparadas para eso. Yo lo utilicé y realmente se notaba la diferencia, ahora bien, hablo de una rutina, es decir una simple función llamada desde C.

Sin embargo, guste o no, con los uP que van sacando día tras día, muchas veces ni se nota la diferencia, a pesar de que si existen, pero deja de ser práctica su optimización.

Por ej. hablando de los ARM como el último Raspberry, es notable la diferencia del uP entre la versión 1 y la 2.


----------



## Dr. Zoidberg (Abr 25, 2015)

cosmefulanito04 dijo:


> Sin embargo, guste o no, con los uP que van sacando día tras día, muchas veces ni se nota la diferencia, a pesar de que si existen, pero deja de ser práctica su optimización.


Cosme:
El problema es que no existe tal "optimizacion"  !!!!
Absolutamente todos los intentos de optimizacion a los que se hace referencia son "en tamaño" por que son faciles de hacer y verificar, pero nunca veo - en este nivel - optimizacion para velocidad de ejecucion... y el porque es simple: para hacerlas.hay que conocer las mismas tecnicas que conocen los que diseñan compiladores y perfiladores. Asi que si alguien tiene una app real time jugada en tiempo, probablemente intente - al boleo - reescribir codigo en assembler e lugar de analizar las opciones del compilador. Y ni te digo si una optimizacion atenta contra la otra...
La unica solucion es SABER... o mandar fruta en su defecto...


----------



## cosmefulanito04 (Abr 25, 2015)

Dr. Zoidberg dijo:


> Cosme:
> El problema es que no existe tal "optimizacion"  !!!!
> Absolutamente todos los intentos de optimizacion a los que se hace referencia son "en tamaño" por que son faciles de hacer y verificar, pero nunca veo - en este nivel - optimizacion para velocidad de ejecucion... y el porque es simple: para hacerlas.hay que conocer las mismas tecnicas que conocen los que diseñan compiladores y perfiladores. Asi que si alguien tiene una app real time jugada en tiempo, probablemente intente - al boleo - reescribir codigo en assembler e lugar de analizar las opciones del compilador. Y ni te digo si una optimizacion atenta contra la otra...
> La unica solucion es SABER... o mandar fruta en su defecto...



Es cierto que a la hora de compilar en C tenés que saber configurar muy bien los flags, cosa que a veces se me escapa.

Pero también es cierto, que los compiladores, por más bien que los configures y les limites su rango de acción, perfectos no son y eso lo he visto con ARM y sus instrucciones Neon (hablo del querido GCC). En C no tenía forma de hacer un rotador de imagen en tiempo real que requiere hacer interpolación lineal y la única forma de resolverlo fué usando assembler (no es algo que me guste mucho, pero no había otra).

En x86, también he usado las instrucciones SIMD (parecidos al Neon, en realidad es lo contrario, el Neon es un imitación de ese tipo de instrucciones) y los resultados que podés obtener son muy buenos.


----------



## Dr. Zoidberg (Abr 25, 2015)

Pero eso no es una optimizacion, eso es usar un recurso muy particular de una familia de micros para conseguir algo que sin usarlo es dificil o imposible de lograr. De hecho, eso deberia ser parte de una biblioteca de aplicacion especifica, de procesamiento de imagenes en tu caso, pero no tiene nada que ver con una optimizacion, por que el compilador no puede adivinar en que vas a usar las instrucciones especificas del micro.
No se si soy claro...


----------



## cosmefulanito04 (Abr 25, 2015)

Dr. Zoidberg dijo:


> Pero eso no es una optimizacion, eso es usar un recurso muy particular de una familia de micros para conseguir algo que sin usarlo es dificil o imposible de lograr. De hecho, eso deberia ser parte de una biblioteca de aplicacion especifica, de procesamiento de imagenes en tu caso, pero no tiene nada que ver con una optimizacion, por que el compilador no puede adivinar en que vas a usar las instrucciones especificas del micro.
> No se si soy claro...



Para mí si es una optimización, tengo dos formas de llegar y una resulta mucho más rápido que la otra, sin dudas esa última está optimizada, no importa como.

De hecho hay funciones intrínsecas en gcc para suplir esas instrucciones y por lo que averigüe no son del todo útiles, aunque admito que no llegué a probarlas, decidí usarlas directamente en assembler.

No quiero hacer offtopic, pero en este post dejé un ejemplo de eso en una rutina bastante sencilla en C, assembler básico y usando las instrucciones especiales:
 _ https://www.forosdeelectronica.com/posts/1000184/ _

Admito que la "forma" de medir el tiempo deja bastante que desear, lo ideal sería usando un contador de intrucciones en assembler, cosa que de hecho existe, pero lamentablemente no pude utilizarla con éxito.

*Edito:*

Y si, usé un puntero void.


----------



## Dr. Zoidberg (Abr 25, 2015)

cosmefulanito04 dijo:


> Para mí si es una optimización, tengo dos formas de llegar y una resulta mucho más rápido que la otra, sin dudas esa última está optimizada, no importa como.


Y no... por que el *concepto *de optimización es otro, y no es hacer dos cosas 100% diferentes y compararlas diciendo cual es mejor.. por que eso no tiene en cuenta al contexto que usa el compilador para optimizar, y que no se extiende a una sola función.
Y acá que la comparación no es correcta (y si importa el como) por que en el ejemplo en assembler de este _*post*_ vos usás los registros del micro mientras que en C usás variables en RAM al no declarar las variables como _register _(si bien es una sugerencia). El compilador siempre optimiza para usar RAM, ya que los registros son bastantes "escasos" a menos que optimicés para velocidad... y aún así. Esas optimizaciones se hacen con un profiler en tiempo de ejecución y no en tiempo de compilación .



cosmefulanito04 dijo:


> De hecho hay funciones intrínsecas en gcc para suplir esas instrucciones y por lo que averigüe no son del todo útiles, aunque admito que no llegué a probarlas, decidí usarlas directamente en assembler.


Mal hecho!!! Ves que lo que te digo es cierto???? Por que no probaste y perfilaste el comportamiento de esas funciones..???



cosmefulanito04 dijo:


> No quiero hacer offtopic, pero en este post dejé un ejemplo de eso en una rutina bastante sencilla en C, assembler básico y usando las instrucciones especiales:_ https://www.forosdeelectronica.com/posts/1000184/ _Admito que la "forma" de medir el tiempo deja bastante que desear, lo ideal sería usando un contador de intrucciones en assembler, cosa que de hecho existe, pero lamentablemente no pude utilizarla con éxito.


Otra vez comparamos mal!!! Las instrucciones especiales SIMD trabajan en paralelo, mientras que el código que has usado en C es netamente secuencial. Si no hay forma de indicarle al compilador que debe generar código SIMD, la unica solución es hacerlo a pedal en assembler... o usar otro compilador (tené en cuenta que el GCC es un compilador multiplataforma, así que no le importa mucho lo que sea particular de cada micro.. al menos hasta que la comunidad desarrolle algo para explotar - opcionalmente - las características especiales).



cosmefulanito04 dijo:


> *Edito:*
> Y si, usé un puntero void.


   jajajajajaja!!!!


----------



## cosmefulanito04 (Abr 26, 2015)

Dr. Zoidberg dijo:


> Y no... por que el *concepto *de optimización es otro, y no es hacer dos cosas 100% diferentes y compararlas diciendo cual es mejor.. por que eso no tiene en cuenta al contexto que usa el compilador para optimizar, y que no se extiende a una sola función.
> Y acá que la comparación no es correcta (y si importa el como) por que en el ejemplo en assembler de este _*post*_



Para mi es eso. Tengo un "pedazo" de hard que con dos códigos distintos consigo dos resultados distintos, uno mejor que otro, por lo tanto ese utiliza mejor los recursos disponibles.

En otras palabras, el recurso está, en C ese recurso termina siendo ocioso, en cambio en assembler no.



Dr. Zoidberg dijo:


> ...vos usás los registros del micro mientras que en C usás variables en RAM al no declarar las variables como _register _(si bien es una sugerencia). El compilador siempre optimiza para usar RAM, ya que los registros son bastantes "escasos" a menos que optimicés para velocidad... y aún así. Esas optimizaciones se hacen con un profiler en tiempo de ejecución y no en tiempo de compilación .



Eso es cierto, podría haber mejorado la rutina en C, declarando la variable contador para que sea un registro, eso hubiera mejorado bastante el tiempo.



Dr. Zoidberg dijo:


> Mal hecho!!! Ves que lo que te digo es cierto???? Por que no probaste y perfilaste el comportamiento de esas funciones..???



Por esto:

http://hilbert-space.de/?p=22

Además para poder utilizar bien esas funciones, es necesario entender el comportamiento de las instrucciones en assembler, por lo tanto mucho no me hubiera ahorrado y me aseguro de no depender de lo que interprete el gcc.



Dr. Zoidberg dijo:


> Otra vez comparamos mal!!! Las instrucciones especiales SIMD trabajan en paralelo, mientras que el código que has usado en C es netamente secuencial.



Y si, es un recurso que si el compilador no sabe utilizar, se pierde.



Dr. Zoidberg dijo:


> Si no hay forma de indicarle al compilador que debe generar código SIMD, la unica solución es hacerlo a pedal en assembler...



De hecho hay formas diciendole "usá las instrucciones Neon". Las funciones intrínsecas son una forma de ahondar que instrucciones específicas debe usar. Cuando compilé la rutina en C, le dí especifiqué ese flag.

Por otro lado, esas rutinas suelen ser cortas y representan poco código en un proyecto, por eso no veo con malos ojos poner la lupa cuando son críticas, más si no hay otra.

Por ej. el rotador, es mucho más complejo que la rutina en assembler, en realidad dejo preparado todo en C (tablas en ram con cálculos complejos que solo se obtienen una vez), para luego si levantar esos valores en la rutina y usarlos con la imagen actual.



Dr. Zoidberg dijo:


> ...o usar otro compilador (tené en cuenta que el GCC es un compilador multiplataforma, así que no le importa mucho lo que sea particular de cada micro.. al menos hasta que la comunidad desarrolle algo para explotar - opcionalmente - las características especiales).



Ahí vamos, muy probablemente otros compiladores pagos estén más optimizados, yo uso el gcc porque justamente es gratuito.


----------



## Dr. Zoidberg (Abr 26, 2015)

cosmefulanito04 dijo:


> Eso es cierto, podría haber mejorado la rutina en C, declarando la variable contador para que sea un registro, eso hubiera mejorado bastante el tiempo.






cosmefulanito04 dijo:


> Por esto:
> 
> http://hilbert-space.de/?p=22
> 
> ...


Seeee.... pero si terminás de leer lo que dice el link que pasaste, vas a ver que el código que genera es un problema del gcc del *2010*!!
En la web del gcc ya aparece como resuelto (está el link) 




cosmefulanito04 dijo:


> De hecho hay formas diciendole "usá las instrucciones Neon". Las funciones intrínsecas son una forma de ahondar que instrucciones específicas debe usar. Cuando compilé la rutina en C, le dí especifiqué ese flag.
> 
> Por otro lado, esas rutinas suelen ser cortas y representan poco código en un proyecto, por eso no veo con malos ojos poner la lupa cuando son críticas, más si no hay otra.
> 
> Por ej. el rotador, es mucho más complejo que la rutina en assembler, en realidad dejo preparado todo en C (tablas en ram con cálculos complejos que solo se obtienen una vez), para luego si levantar esos valores en la rutina y usarlos con la imagen actual.


Es que vos has hecho las cosas bastaaaante bien, excepto confiarte en la existencia de un problema muuuuy viejo [que parece ya estar resuelto] para decidirte por el assembler sin haber verificado antes la existencia real del error. Pero aún así, el meter código ASM tan específico (aunque acotado) es candidato a generar problemas en el futuro... ni hablar si cambiás de plataforma de desarrollo.
Por otra parte, la capa de abstracción que dá el compilador te permite liberarte de los detalles de implementación de cada micro en particular. Por supuesto que siempre hay que pagar algo, tal vez performance o tamaño de código... o ambas, pero hay que ver cuanto impacta eso en la aplicación final...

Pregunta:
En cuanto tiempo máximo necesitabas ejecutar el algoritmo???


----------



## cosmefulanito04 (Abr 26, 2015)

Dr. Zoidberg dijo:


> Seeee.... pero si terminás de leer lo que dice el link que pasaste, vas a ver que el código que genera es un problema del gcc del *2010*!!
> En la web del gcc ya aparece como resuelto (está el link)



Dr., el código resultante en C y en Assembler es muy similar por el uso de las rutinas, no cambia en nada, salvo que me aseguro saber exactamente que hago.

¿Qué tan enredado le puede resultar al compilador generar el código óptimo?, en la rutina que puse, todavía se le puede optimizar más usando los registro de una forma rebuscada como puse en el post siguiente. 

Hasta ese nivel, si lo quisiera optimizar, el código en C y en Assembler es prácticamente similar debido a que está basado en las instrucciones especial y en como las uso (es decir, debería modificar de la misma forma ambos códigos), por lo tanto, la única diferencia radicará en que tan bien traduce el compilador eso que quiero hacer en Assembler, pero que dejé en forma explícita en C, ¿me explico?, a la larga, no gano nada, en el peor de los casos pierdo, porque el assembler ya lo pensé para poder hacer el código en C.



Dr. Zoidberg dijo:


> Es que vos has hecho las cosas bastaaaante bien, excepto confiarte en la existencia de un problema muuuuy viejo [que parece ya estar resuelto] para decidirte por el assembler sin haber verificado antes la existencia real del error.



Como puse arriba, a la larga el código es muy similar, solo está la traducción en el medio de lo que realmente busco en assembler, es decir no tiene mucho sentido que digamos.



Dr. Zoidberg dijo:


> Pero aún así, el meter código ASM tan específico (aunque acotado) es candidato a generar problemas en el futuro... ni hablar si cambiás de plataforma de desarrollo.



Eso no lo discuto, pero lo mismo sucedería con las funciones en C pensadas para el uso de esa instrucciones especiales. Lamentablemente no queda otra que usar dichas instrucciones, de hecho para algo están.



Dr. Zoidberg dijo:


> Por otra parte, la capa de abstracción que dá el compilador te permite liberarte de los detalles de implementación de cada micro en particular. Por supuesto que siempre hay que pagar algo, tal vez performance o tamaño de código... o ambas, pero hay que ver cuanto impacta eso en la aplicación final...



En mi caso, el impacto era notable.



Dr. Zoidberg dijo:


> Pregunta:
> En cuanto tiempo máximo necesitabas ejecutar el algoritmo???



Idealmente 40mS sin tener en cuenta ninguna rutina en el medio (cosa que no es cierto, ya que en el medio realmente se hacen otras cosas), en C a secas, conseguí algo cercano a los 55mS y en assembler logré reducirlo a 33mS. 

Como resultado, el rotador se acerca bastante a lo ideal, no llega a los 25fps, pero pega en el palo, safa bastante.


----------



## Dr. Zoidberg (Abr 27, 2015)

cosmefulanito04 dijo:


> Dr., el código resultante en C y en Assembler es muy similar por el uso de las rutinas, no cambia en nada, salvo que me aseguro saber exactamente que hago.
> 
> *¿Qué tan enredado le puede resultar al compilador generar el código óptimo?, en la rutina que puse, todavía se le puede optimizar más usando los registro de una forma rebuscada como puse en el post siguiente. *
> 
> Hasta ese nivel, si lo quisiera optimizar, el código en C y en Assembler es prácticamente similar debido a que está basado en las instrucciones especial y en como las uso (es decir, debería modificar de la misma forma ambos códigos), por lo tanto, la única diferencia radicará en que tan bien traduce el compilador eso que quiero hacer en Assembler, pero que dejé en forma explícita en C, ¿me explico?, a la larga, no gano nada, en el peor de los casos pierdo, porque el assembler ya lo pensé para poder hacer el código en C.


  De la forma que escribiste el procesamiento le resulta MUY complicado imaginar lo que estás haciendo, por que tu código son sumas o lo que sea secuenciales en una interación y el compilador tiene que imaginar que las puede ejecutar en paralelo por grupos para poder usar las instrucciones NEON.... hummmmm... ... ni con la bola de cristal
La solución es escribir el código C de otra forma donde quede explícito el procesamiento en grupos de a 8 y esperar que el compìlador sea inteligente como para darse cuenta... pero así es mas probable que lo haga.



cosmefulanito04 dijo:


> Como puse arriba, a la larga el código es muy similar, solo está la traducción en el medio de lo que realmente busco en assembler, es decir no tiene mucho sentido que digamos.





cosmefulanito04 dijo:


> Eso no lo discuto, pero lo mismo  sucedería con las funciones en C pensadas para el uso de esa  instrucciones especiales. Lamentablemente no queda otra que usar dichas  instrucciones, de hecho para algo están.


Claro que es similar, pero oculto en funciones en C, que tienen la capacidad de mutar su estructura u comportamiento sin impactar en la forma del código final. Lo que vos hiciste está bien, pero si alguien tiene que mantener ese bloque de código... deseale suerte.



cosmefulanito04 dijo:


> Idealmente 40mS sin tener en cuenta ninguna rutina en el medio (cosa que no es cierto, ya que en el medio realmente se hacen otras cosas), en C a secas, conseguí algo cercano a los 55mS y en assembler logré reducirlo a 33mS.
> 
> Como resultado, el rotador se acerca bastante a lo ideal, no llega a los 25fps, pero pega en el palo, safa bastante.


Pero no era casi 9 a 1 en la velocidad de ejecución???? Acá lograste solo el 1.6 a 1, que si bien se ajusta (maso) a tu necesidad es casi 6 veces mas lento que la medición...
O usaste assembler sin las NEON???

A ver... el problema no es usar ASM, el problema es hacerlo sin agotar todas las posibilidades del C y su compilador..


----------



## cosmefulanito04 (Abr 27, 2015)

Dr. Zoidberg dijo:


> De la forma que escribiste el procesamiento le resulta MUY complicado imaginar lo que estás haciendo, por que tu código son sumas o lo que sea secuenciales en una interación y el compilador tiene que imaginar que las puede ejecutar en paralelo por grupos para poder usar las instrucciones NEON.... hummmmm... ... ni con la bola de cristal



No se si hablamos del rotador o del ejemplo que puse.

Si hablamos del ejemplo, todas las rutinas básicamente agarran 2 bloques de memoria (2 imágenes) y realizan una AND byte a byte (o en el caso de una imagen blanco y negro de 8bits, pixel a pixel), que permite generar esa máscara final que se vé en la imagen resultante.

Las instrucciones Neon, te permiten trabajar con varios pixel a la vez en una solo instrucción, por lo tanto viendo el primer ej. Neon, lo que idealmente le tomaría a la rutina en assembler básico 16 ciclos para trabajar 16 pixeles y hacer el AND, a la instrucción Neon le lleva solo 1 ciclo.

Ahora bien, los registros *qn* (128 bits), no son más que 2 registros *dn* (64 bits), pero... los registros *dn* a diferencia de los *qn* te permiten agruparlos, por lo tanto en el segundo ej. Neon, en vez de trabajar con 128bits (1 registro *qn*), trabajo con 4 registros *dn* a la vez (256 bits o 32 bytes).

Esa optimización, no hay forma de verlo, salvo que piensen exclusivamente en las instrucciones y en assembler, cosa que después la traducción en C es prácticamente igual.



Dr. Zoidberg dijo:


> La solución es escribir el código C de otra forma donde quede explícito el procesamiento en grupos de a 8 y esperar que el compìlador sea inteligente como para darse cuenta... pero así es mas probable que lo haga.



Pensá que el compilador por más que le pongas el flag del Neon no es muy bueno que digamos, por eso esta ese mix raro de las funciones que simulan esas instrucciones, al igual que el tipo de variables/registros.



Dr. Zoidberg dijo:


> Claro que es similar, pero oculto en funciones en C, que tienen la capacidad de mutar su estructura u comportamiento sin impactar en la forma del código final. Lo que vos hiciste está bien, pero si alguien tiene que mantener ese bloque de código... deseale suerte.



Por eso dejo comentado el código en C reemplazado por la rutina en assembler, si un futuro el hard/compilador lo permite, no creo que sea muy difícil pasarlo.



Dr. Zoidberg dijo:


> Pero no era casi 9 a 1 en la velocidad de ejecución???? Acá lograste solo el 1.6 a 1, que si bien se ajusta (maso) a tu necesidad es casi 6 veces mas lento que la medición...
> O usaste assembler sin las NEON???



No seas malo, fijate en el ejemplo que puse que más o menos se dá esa relación.

Por otro lado, ojala el rotador fuera tan fácil y depender de una sola operación, lamentablemente esto no es así, ya que inevitablemente al trabajar con tablas obtenidas de senos/cosenos (previamente en C), las lecturas de los píxeles no son continuos, debo ir a buscar píxeles (o bytes en memoria) en lugares distantes, eso mata en un principio el proceso. En esa parte, la rutina es similar en C o en assembler y es lo que más tiempo lleva.

Luego que tengo los valores de la imagen ya "rotados", es decir los píxeles en memoria muy cercana, ahí si con las instrucciones Neon hago la interpolación lineal (o como le llaman bilineal) y le paso el trapo al C convencional, esos 20mS de diferencia se ganan ahí.



Dr. Zoidberg dijo:


> A ver... el problema no es usar ASM, el problema es hacerlo sin agotar todas las posibilidades del C y su compilador..



Dr., lamentablemente para usar este tipo de instrucciones en gcc, no hay mejor forma que hacerlo de esta manera.


----------



## Dr. Zoidberg (Abr 28, 2015)

cosmefulanito04 dijo:


> No se si hablamos del rotador o del ejemplo que puse.
> 
> Si hablamos del ejemplo, todas las rutinas básicamente agarran 2 bloques de memoria (2 imágenes) y realizan una AND byte a byte (o en el caso de una imagen blanco y negro de 8bits, pixel a pixel), que permite generar esa máscara final que se vé en la imagen resultante.
> 
> ...





cosmefulanito04 dijo:


> Pensá que el compilador por más que le  pongas el flag del Neon no es muy bueno que digamos, por eso esta ese  mix raro de las funciones que simulan esas instrucciones, al igual que  el tipo de variables/registros.



Yo hablaba de _*este *_ejemplo, que está en las tres formas: C, ASM y ASM+NEON. Y para que pueda optimizar usando el set de instrucciones NEON, la unica posibilidad es que el compilador haga un loop-unrolling de a 8 invocaciones internas, lo que es imposible por que no conoce el valor final del contador del for... *y* - probablemente - habría que transformar a *enmascarar *en un _macro_. La unica posibilidad sería que _tamanio _fuera una constante y multiplo de 8 o 16. Si tuviera eso Y fuera inteligente, el compilador tal vez podría decidirse por generar código NEON para procesamiento paralelo por que estaría bastante claro que es factible utilizarlo. De otra forma no se pueden esperar maravillas.
La optimización sin NEON es mas simple en la medida que ayudés al compilador diciendole que use los registros.. donde pueda.



cosmefulanito04 dijo:


> Por eso dejo comentado el código en C reemplazado por la rutina en assembler, si un futuro el hard/compilador lo permite, no creo que sea muy difícil pasarlo.


Si usás NEON no queda otra que hacer eso. En ASM pelado es mucho mas simple por qur todos los µ tienen las mismas instrucciones basicas.



cosmefulanito04 dijo:


> No seas malo, fijate en el ejemplo que puse que más o menos se dá esa relación.
> 
> Por otro lado, ojala el rotador fuera tan fácil y depender de una sola operación, lamentablemente esto no es así, ya que inevitablemente al trabajar con tablas obtenidas de senos/cosenos (previamente en C), las lecturas de los píxeles no son continuos, debo ir a buscar píxeles (o bytes en memoria) en lugares distantes, eso mata en un principio el proceso. En esa parte, la rutina es similar en C o en assembler y es lo que más tiempo lleva.
> 
> ...


No soy malo , solo que lo que presentaste muestra una cosa que está lejos de ser real... por lo que te dije antes: el *contexto*. El compilador puede hacer optimizaciones sobre todo el código y ajustarlo para que funcionen. Vos solo te limitaste a un fragmento que tiene mucho impacto, y aún así los resultados no fueron como las pruebas los mostraban. Claro.. mientras que cumplan con solucionar el problema es una alternativa válida, pero no es la solución "final"..


----------

