Lenguajes de programación de PIC.

El lenguaje nativo de los PIC es ensamblador, pero hay compiladoores que te permiten escribir tus programas en C, Basic, en forma de diagramas de flujo (no se si en Pascal o Java tambien pero imagino que si) que traducen el codigo a ensamblador.

Saludos

"FlyBoy" escribió en el mensaje news: snipped-for-privacy@individual.net...

te Bueno, nativo será binario o exadecimal, pero bien, vale..

flujo

Muy usado es el picbasic, hay una versión shareware ( o free , no recuerdo) limitada y mucha documentación en la red.

Asembler, C, Basic y Pascal, que yo sepa. Recomendable, el C, sin dudarlo.

Siendo puristas, no sería correcto decir que binario o hexadecimal son lenguajes. Son formas de representación de estados discretos. En todo caso, el lenguaje nativo del PIC, sería "código máquina" (sí, se almacena en binario, pero no es lo mismo que decir que el lenguaje es "binario").

--

Saludos de Jose Manuel Garcia snipped-for-privacy@terra.es http://213.97.130.124

"José Manuel" escribió en el mensaje news: snipped-for-privacy@individual.net...

"Lenguaje binario", es una expresión perfectamente válida, y que se empleó con la aparición de los primeros ordenadores, cuando ni siquiera existía todavía el ensamblador.

Dudo que alguien haya escrito alguna vez un programa en hexadecimal, pero en binario muchísimo en su tiempo, y si, había un "lenguaje binario", que además coincidía por lógica, intímamente con la manera de manejar la información el procesador.

Código máquina podría ser otra manera de llamar al lenguaje binario, aunque también contemplaría todos esos experimentos fallidos, por crear sistemas con más de dos estados.

Yo aún conservo un programa escrito íntegramente en lenguaje binario, para un Spectrum, antes de que comercializasen el primer ensamblador.

De acuerdo, José Manuel, no es bueno pecar de puristas jajaja.... Yo he programado el 7090 de IBM ...que era de transistores, no había ni un CI...con un teclado de 32 teclas-bits... Instrución a instrución y luego enter jajaja ¡que tiempos! ojo, no es que sea muy viejo...es que empecé muy joven..jajaja Era en el centro de cálculo de la coplutense de Madrid.. Fortran II y tarjetas perforadas....el compilador y linkador en fichas...¡Como se te cayeran..!! Luego pasó a cintas, eso ya era muy moderno. Saludos JM

"Pepitof" escribió en el mensaje news: snipped-for-privacy@individual.net...

caso,

que

"Cangrejo Moruno" escribió en el mensaje news:Y0w_f.4222$ snipped-for-privacy@news.ono.com...

Po fale, para qué vamos a discutir. Total, al final habrá que acabar diciendo aquello de "llámalo como quieras".

Personalmente me parece incorrecto, y la mayor parte de literatura sobre el tema, lo llama lenguaje máquina. De hecho, si haces una búsqueda en Google, verás que por "machine language" aparecen 1.420.000 entradas, y en cambio, por "binary language" aparecen sólo 48.900, unas 30 veces menos.

La Enciclopedia Británica define "machine language" como: "system of instructions and data directly understandable by a computer's central processing unit". En cambio, "binary language" ni siquiera aparece. Pero en fin, posiblemente se equivoquen, claro.

en

aunque

Ni mucho menos. El lenguaje máquina de una máquina (se llama "máquina" aludiendo a la clásica máquina de estados), es el lenguaje que puede ejecutar esa máquina. Así, el lenguaje máquina de un microprocesador, es el lenguaje que puede ejecutar ese microprocesador. Esto no incluye "experimentos fallidos" ni nada que quieras inventar, más que lo que puede ejecutar ese microprocesador en concreto. Esto es así, por definición, y lo puedes ver en cualquier libro sobre este tema.

Naturalmente, como siempre, tú eres muy libre de llamar a eso lenguaje binario o como te plazca, pero el binario no es más que una forma de representar las instrucciones y los operandos del lenguaje máquina. En última instancia "0" y "1" no son más que representaciones de unos estados físicos, y no es una forma de representación ni más ni menos válida que agujeritos en una tarjeta, o dígitos en hexadecimal, decimal, octal, o cualquier otra. Simplemente, el binario es una forma muy práctica en determinados casos, y por eso se usaba normalmente para escribir en lenguaje máquina.

Ah, y por más que lo dudes, sí se ha escrito, y mucho, lenguaje máquina en hexadecimal. Todavía tengo por ahí algún listado en hexadecimal publicado en Elektor (la entrada de datos de su famoso Junior Computer se hacía en hexadecimal) y en alguna revista más. En el museo de la NASA también había alguno expuesto.

Pues busca en cualquier página nostálgica sobre el Spectrum (o cualquier otro ordenador), y dime si encuentras fácilmente algo llamado "binary language" o por el contrario, "machine language".

--


Saludos de Jose Manuel Garcia
jose.mgg@terra.es
http://213.97.130.124

Cangrejo Moruno escribió en el mensaje de noticias Y0w_f.4222$ snipped-for-privacy@news.ono.com...

¿Y como escribiste ese programa en bianrio?

La técnica habitual era escribirlo en papel con lo nemonicos del Z80 y luego ensamblar a mano. Eso era escribir en codigo maquina y ser tú el ensamblador/compilador.

Escribir en lenguaje binario sería aprenderse de memoria los codigos binarios de cada instrucción y escribir directamente los DATA para hacer los POKES. En teoria es posible pero no conocí a nadie todavía. Aunque sí era normal hacer pequeñas modificafiones sobre el programa ya hecho directamente sobre los DATA

Hombre de memoria no me los sabía, sería un fenómeno de fería. Tenía una tabla de un libro, que te daba las equivalencias del juego de instrucciones, en binario y hexadecimal.

Digamos, que escribía y ensamblaba manualmente, todo a la vez, para cada instrucción que iba añadiendo. Tampoco era un programa monstruoso. Era una base de tiempos para manejar una caja de ritmos, también autoconstruida, con lo que había en la época.

luego

Esa podia ser la tecnica habitual cuando de copiaba directamente de una revista, para programar la Spectrum en assembler estaba el Zeus, que para el poco espacio que ocupaba era bastante bueno, tambien estaba el paquete ensamblador/debugger Gens-Mons , el Gens ni se le acercaba al Zeus por eso lo normal para desarrollo era usar Zeus-Mons.

r los

=ED era

mente

En esa epoca Motorola vendia kits de desarrollo con microprocesadores

6800, tenia dos sabores, el Exorciser que se programaba por cross-assembler ,era algo hecho como dios manda pero era carito. Habia otro kit barato (500USD) que era el que teniamos que usar los estudiantes, la programacion era ingresando los codigos en hexadecimal, y no podia haber mayor tortura que retocar un par de lineas porque habia que recalcular todos los destinos de los saltos.

Eduardo.

Estoy de acuerdo con que el lenguaje maquina (y mas aun no recuerdo haber escuchado nunca lenguaje binario o hex)es el lenguaje nativo en el sentido estricto, pero digamos que uno normalmente al programar desde su nivel mas basico utiliza el asm. Pero como ha dicho pepitof no armemos un lio que vamos a confundir al autor del mensaje. Por mi parte acepto que al usar la palabra nativo me pase por alto los 0's y 1's que usa al final de cuentas el micro (lenguaje maquina).

Pero tambien todos sabemos por donde va la pregunta, asi que yo repregunto: hay basic o java para micros pic? y otra cosa: que se acostumbra usar normalmente si se desea darle un enfoque de procesamiento en tiempo real a la aplicacion con microcontroladores PIC? hay algun tipo de kernel? este tema es nuevo para mi, algo lei recientemente y me ha pegado la duda.

Saludos

Hay varios compiladores de Basic para PIC, el más famoso, el PIC Basic Pro. En Java, que yo sepa, no hay nada. Lo más usado, es C o directamente ASM. Personalmente, creo que lo más serio es el C de Hitech, combinado con algunos fragmentos en ASM.

Lo del procesamiento en tiempo real, a mí nunca me ha quedado muy claro lo que es. Hay por ahí una cosa llamada RTOS (creo), que dice ser un sistema operativo en tiempo real, pero la verdad es que no lo he mirado siquiera.

En cuanto al tema del kernel, es un concepto que tiene poca aplicación hablando de microcontroladores de gama baja o media. Tener un kernel es práctico en sistemas más abiertos, como el DOS de un PC, en los que, a priori, no sabes qué programas van a correr, y en los que la cantidad de memoria disponible es relativamente grande.

Pero en un sistema tan cerrado como un circuito a microcontrolador, en el que se conoce exactamente lo que éste tiene que hacer, y cómo va a interactuar el microcontrolador con el hadware, no parece lógico tener compiladas y ocupando memoria un montón de funciones que no se van a usar. En su lugar, es más práctico tener librerías de funciones (en el lenguaje que se utilice), de forma que sólo se compilen aquellas que son necesarias en cada caso.

--


Saludos de Jose Manuel Garcia
jose.mgg@terra.es
http://213.97.130.124


"FlyBoy"  escribió en el mensaje
news:4a0mttFpk768U1@individual.net...
>
> Pero tambien todos sabemos por donde va la pregunta, asi que yo
repregunto:
> hay basic o java para micros pic? y otra cosa: que se acostumbra usar
> normalmente si se desea darle un enfoque de procesamiento en tiempo real a
> la aplicacion con microcontroladores PIC? hay algun tipo de kernel? este
> tema es nuevo para mi, algo lei recientemente y me ha pegado la duda.
>

"FlyBoy" escribió :

Buenas, Tienes para microcontroladores de 32bits un kernel de linux:

El primer micro que fue portado a Linux fue el Motorola MC68328, también tienes económico y potente el ARM7. Tal y como definen uCLinux, es una portabilidad para microcontroladores que carecen de Unidad de Gestión de Memoria, tiene mucho éxito: Ahora, la experiencia de amigos que han desarrollado aplicaciones comerciales en este entorno, ha sido según ellos "Muy dura" ya que el gran problema de uClinux es que la comunidad que lo soporta/desarrolla es muy reducidad y no hay mucho código escrito, solo lo básico, además, cada micro necesita su kernel, y hay muchos micros de 32bits por lo que la gente se divide. También me han comentado que es una plataforma muy inestable, y aunque sus desarrolladores están totalmente satisfechos (no es para menos...) el uCLinux está aún verde...

yo lo solucione haciendome un ensamblador en basic :-)

El mejor para mi es el Picsc:

Es broma, es que lo hice yo, pero tiene algunos errores y no hay documentación. Lo hice porque se me hacía muy duro programar en ensamblador despues de muchos años de lenguajes de alto nivel, es una mezcla de asm y c, y me ha permitido programar un PIC con la efectividad del asm y la facilidad del C ;-)

Como curiosidad me encontr=E9 pyastra que es un compilador de python para Pic. No lo recomiendo, parece m=E1s una prueba de concepto (o "mental paja") que otra cosa (ojo, dale tiempo para que madure).

Tambi=E9n tienes sdcc que yo lo uso, pero todav=EDa no me fio mucho y siempre acabo mirando el ensamblador que genera (el sdcc pasa de .c a .asm, despu=E9s tienes que compilar el asm con gputils o el compilador de microchip).

El basicstamp lo usa mucha gente, =E9chale un vistazo.

Y no s=E9, a veces tardas menos en programar el pic si lo haces dir=E9ctamente en ensamblador (si el programa es peque=F1o y se deja). Sobretodo cuando tienes que contar el tiempo que tarda en ejecutarse tu c=F3digo para tener un timer cutre y esas cosas.

Hala, hasta pronto!

Creo que un sistema en tiempo real es aquel en el que un programa se ejecuta de forma predecible, por ejemplo ni windows ni linux lo son, porque la cpu se reparte entre varios procesos y nunca sabes cuando (ni cuanto) un programa se va a parar a mitad de su ejecucion.

El PIC ejecutando un solo programa es claramente tiempo real, porque llega al extremo que puedes medir el tiempo contando los ciclos de instrucciones.

luego

Esa podia ser la tecnica habitual cuando de copiaba directamente de una revista, para programar la Spectrum en assembler estaba el Zeus, que para el poco espacio que ocupaba era bastante bueno, tambien estaba el paquete ensamblador/debugger Gens-Mons , el Gens ni se le acercaba al Zeus por eso lo normal para desarrollo era usar Zeus-Mons.

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

Antes de conseguir el Gens algo había que hacer y no solo copiar ensamblador.

EL Zeus no lo llegue a conocer. Miraré a ver si lo encuentro. Todavía sigo haciendo algunas cosas para el Spectrum

................................................

los

directamente

En esa epoca Motorola vendia kits de desarrollo con microprocesadores

6800, tenia dos sabores, el Exorciser que se programaba por cross-assembler ,era algo hecho como dios manda pero era carito. Habia otro kit barato (500USD) que era el que teniamos que usar los estudiantes, la programacion era ingresando los codigos en hexadecimal, y no podia haber mayor tortura que retocar un par de lineas porque habia que recalcular todos los destinos de los saltos.

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

Cierto, yo ultizaba un truco . las instrucciones destinos de saltos las rodeaba arriba y abajo con algunos nops. Así tenía confianza en que un fallo no podía ser que me había colado en calcular el salto relativo en +-2.

Eso es, la parte de los RTOS para PIC es lo que me causa duda. En algunas ocasiones encuentro en la red que hablan de un RTOS pero lo he dejado pasar y ahora si me da curiosidad.

Para la PC normal recuerdo haber usado un soft "RTOS" , basicamente lo que hace es una gestion de las tareas o procesos que ejecuta la PC de acuerdo a un criterio de prioridad y tiempo de ocurrencia. Por poner un ejemplo tenemos tareas que se ejecutan de forma periodica: cada 20 ms actualizamos la hora en el monitor, cada 100 ms leemos dato del puerto paralelo, o cada 2 horas activamos un foco por ejemplo. Tambien estan las tareas asincronas como lectura de teclado a las cuales tambien se les asigna un nivel de prioridad de modo que si dos o mas tareas se deben ejecutar al mismo tiempo, se vayan ejecutando de acuerdo a la prioridad de cada una.

En la PC el periodo basico es aquel que fija el timer 8254 (el que genera los famosos ticks cada 18 ms) de este modo las tareas periodicas se programan en funcion del numero de ticks , por ejemplo en forma de pseudo instruccion: set_period_task(act_hora, 2, 5) donde los parametros serian: funcion a declarar como periodica, tiempo en que se repite el proceso en ticks de reloj y al ultimo la prioridad. Esto ultimo determina si dos tareas se ejecutaran al mismo tiempo se ejecuta primero aquella que tenga prioridad mas alta. Logico que todo esto se puede programar en un microcontrolador pero hacer la gestion de tareas se vuelve un lio y creo que ahi es donde entra el RTOS con un conjunto de instrucciones que me imagino harian algo de lo descrito lineas arriba.

Regresando a la PC que esta el QNX para aplicaciones de tiempo real pero no he mirado

Saludos