ASM, basic , C y otros

ezavalla dijo:
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.....
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!!
 
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......
 
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.
 
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 :LOL:... por que yo no le entiendo ni una palabra de lo que habla solo se que si es Español :LOL: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 :apreton:
 
Última edición:
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?
 
Última edición:
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.
 
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.

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.
 
Última edición:
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.
 
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.
 
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.
 
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.
Código:
   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:
Código:
; 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:
Código:
     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.
 
Última edición:
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

Código:
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....
 
Última edición:
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.
 
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.
 
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?
 
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.
 
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.
 
Atrás
Arriba