TODOPIC
Otros Microcontroladores / Dispositivos programables => ** PROYECTOS ** => Mensaje iniciado por: misterweb en 07 de Enero de 2019, 12:50:37
-
Este es un proyecto que llevo pensando hace mucho tiempo, y aunque he realizado algunos programas que ya realizan esta funcion, me gustaria hacerlo de forma mas completa.
En fin me explicare mejor. La idea es la siguiente:
1) Un microcontrolador 18F que es es que estoy trabajando actualmente aunque puede ser cualquier otro.
2) Se crean multiples subrutinas dentro de la memoria Flash de programa del Pic tales, como , configuraciones puertos, pwm, envio datos a puerto, convertidor A/D y muchas mas, cada una de estas subrutinas las llamaremos, comando1, comando2, comando3, ..... etc.
3) Reservaremos una parte de la memoria Ram del Pic por ejemplo entre la posicion 100 a 1FF, el programa principal empezara leyendo la posicion 100 y hay por ejemplo se encuentra el valor "1" que en su interpretacion de ordenes significa que tiene que ejecutar el comando1, y esto significa por ejemplo que tiene que configurar el puertoA con un determinado valor.
Una vez echo esto pasara a la siguiente posicion de memoria 101 de Ram y ejecutara otro comando y asi sucesivamente.
4) Evidentemente se necesitan datos adjuntos a estos comando, si queremos por ejemplo en el comando1 configurar el puerto PORTA con sus entradas y salidas, evidentemente debe haber un sitio donde le diga con que valor se debe configurar el ese puerto, bueno pues esos valores necesarios para el buen funcionamiento de los comandos pueden almacenarse entre las posiciones 200 a 2FF
5) Va a ser necesario otro bloque de memoria para los datos que se puedan generar u otras cosas mas, que por ejemplo puede estar en el bloque de RAM que va de posicion 300-3FF .
Bueno a esta altura de la pelicula si alguien se ha leido esto estara pensando para que coño querra este
tio hacer esto....JEJEJE.
La idea es convertir el microncontrolador en una especie de microprocesador, se que hay un microcontrolador de la
familia 18 que puede correr parte de codigo en SRAM, pero yo quiero ir mas alla y poder correr funciones
mas complejas, es como si yo creara los comandos que se van a ejecutar en este microprocesador.
Que ventajas tiene esto:
Es inmediato, yo creo un programa se lo meto en memoria RAM atraves del puerto serie, lo ejecuto y miro como
se comporta, y lo modifico y lo vuelvo ejecutar miles de veces, las veces que yo quiero.
Creo multiples combinaciones exteriormente.
Lo unico que tengo que hacer es cargar los bloques de Memoria y dar la orden de ejecucion.
Desventajas:
Se pierde en velocidad y se complican las creaciones de programas, pero mas tarde se puede crear un interpretador de ordenes.
Bueno yo me manejo en Linux, para mi crear programas en C que cargen los bloques de memoria del Pic y lo almacenen
en memoria RAM del Pic no me supone problema, pero entiendo que por lo general la gente se maneja en windows.
En fin me gustaria saber que le parece a la gente esta idea.
Muy feliz año y prospero año nuevo para toda la gente de este foro.
-
Me parece que vas a perder el tiempo y sin sentido.
Lo que vayas a cargar en la RAM tiene que estar en algun lado, Y es la FLASH, en resumen, Directamente crear una tabla que ejecute esos "comandos" y listo, te ahorras la RAM.
Si vas a enviar las cosas por una PC para que luego lo ejecute, entonces puede que si... Pero no le llamaria "correr programa DESDE la RAM" sino que en la RAM exista una tabla que redireccione al micro para un lado u otro.
Queres ejecutar cosas de la RAM? Buscate otro micro que lo haga. Por el mismo precio tenes algunos ARM que lo hacen. Hay solo un par de casos que vale la pena ejecutar de la RAM. Hablo de tener instrucciones en la RAM y ejecutarlas. Como si fuera la FLASH.
-
Bueno lo que busco mas o menos es tener un microprocesador pero con las ventajas de un microcontrolador, esto es los microprocesadores no tienen pwm, convertidores analogicos digitales, comparadores etc...
Si efectivamente no es correr en RAM sino como tu dices un redireccionamiento a una tabla de subrutinas.
Yo creo en el PC un archivo de texto con las ordenes y los datos y se los cargo atraves un programa por el puerto serie en los bloques de memoria RAM del Pic y luego le doy la orden de ejecutar.
Me parece muy util, por ejemplo imaginarque estoy intentando saber como puedo configurar por ejemplo un LCD y que saque un mensaje. Escribo en el archivo del PC, los datos secuencialmente para que salga por un puerto del PIC, le cargo este archivo al PIC y pruebo hasta que doy con las configuracion que haga que funcione correctamente el LCD.
Quien dice un LCD, puede ser eprom, cualquier dispositico con entrada I2C, o cualquier otro dispositivo.
Simplente tengo que modificar el archivo de texto y volver a enchufarle los datos al PIC de nuevo, hasta que de con la configuracion correcta.
Luego una vez hallado puedo ya crear el programa de programacion normal para el PIC.
Me ahorro tener que estar programando y reprogramando el PIC unicamente tengo que varior los datos en un archivo de texto.
En fin es solo una idea.
Saludos.
-
Creo que lo que estás buscando es un bootloader.
Busca info sobre ellos a ver si te solucionan el problema.
-
También por lo que cuentas puede que te interese el lenguaje FORTH
-
Bueno lo que busco mas o menos es tener un microprocesador pero con las ventajas de un microcontrolador, esto es los microprocesadores no tienen pwm, convertidores analógicos digitales, comparadores etc...
Te estas equivocando... Eso lo tienen, el problema es que un microprocesador no estas hablando de algo pequeño como para lo que pretendes.
Me parece muy util, por ejemplo imaginarque estoy intentando saber como puedo configurar por ejemplo un LCD y que saque un mensaje. Escribo en el archivo del PC, los datos secuencialmente para que salga por un puerto del PIC, le cargo este archivo al PIC y pruebo hasta que doy con las configuracion que haga que funcione correctamente el LCD.
Parece genial pero no contas con todo lo demás que tenes que tener en cuenta. La preparación de las funciones que pretendes. El desarrollo de lo que pretendes, el debug, etc. La poca memoria RAM que tenes. Luego querer implementar otra cosa ya que va a ser MUY especifica tu implementacion. TODO ese tiempo va a ser mejor destinado a programar correctamente. Hay miles de formas de programar y de "probar" el programa sin siquiera subirlo a un microcontrolador o un simulador. Para que luego no estes grabando miles de veces el microcontrolador.
Disculpa que no comparta tu idea y que sea alguien que te de la contra, solo quiero que no pierdas el tiempo. Si lo queres hacer como un desafio, adelante. Yo lo estoy viendo del punto de vista practico, ademas, apenas pierda energía no tendría mas el programa.
Tampoco es un bootloader. Tampoco es un microprocesador, el microprocesador no ejecuta de la RAM. Si quisiera lo que el quiere hacer me busco un ARM con una RAM externa, copio todo a la RAM externa y voy ejectuando desde la RAM, como debe ser, dejando un programa como "supervisor"... Y ahi SI cargo el programa como debe ser, con las instrucciones correctas que irian en el microcontrolador y estaria ejecutando esas funciones (un poco mas lento obviamente). Distinto es lo que el intenta.
Por esto
-
Buenas KILLERJC, Picuino gracias por las contestaciones, perdon un poco por el pequeño retraso, pero estoy trabajando y hasta que no llego a casa y no me desenvuelvo de algunas cosas no puedo contestar.
Parece que la idea no esta causando sensacion ...... JEJEJE.
Bueno no importa era eso solo una idea, yo solo lo hago por cacharrear la verdad es que ni voy a obtener ningun dinero de ello ni voy aprobar ninguna asignatura...... vamos de los bichos raros que disfruta el tiempo programando en ensamblador y en C sin obtener ningun beneficio a cambio...... ya podia tener otras aficiones mas productivas como jugar en bolsa...jejeje.
Y en parte tambien por que ya me esta funcionando, la idea es si merece la pena llevarlo mas alla, pero la verdad es que me estais convenciendo de que no.
Demasiado trabajo, pienso que puede ser util en algunos casos en concreto para chequear un circuito, crear un pulso determinado, etc..
pero de ahi a crearse todo un sistema, es verdad que no merece la pena.
Bueno KILLERJC y Picuino muchas gracias por vuestras contestaciones...
Un saludo.
-
Demasiado trabajo, pienso que puede ser util en algunos casos en concreto para chequear un circuito, crear un pulso determinado, etc..
pero de ahi a crearse todo un sistema, es verdad que no merece la pena.
El trabajo que planteas es muy parecido a como funcionan estos "robots" para los estudiantes que recién aprenden electrónica, el cual uno puede decirles que avancen x vueltas, o tantos grados. Hay una persona que pregunto por eso. Y la aplicacion en software es muy parecida a la que planteas. Obviamente que puede tener utilidad. Por eso te dije que si queres hacerlo, como un hobby etc, lo hagas. Pero no lo pienses en que va a ser una revolucion o por los motivos que me diste antes (unirlo al mundo de los microprocesadores, etc)
Es decir.. tenes una serie de funciones especificas a la aplicación, y vos cambias el "orden" y "cantidad" de ejecucion. Aun asi estas pueden trabajar con EEPROM mas que RAM... Pero el principio es identico. Nuevamente, si me decias que era para esto lo tomaba de otra forma xD
-
Todo lo que hago es por hobby, en fin la idea tampoco es que la tenga muy clara, pero bueno la idea que yo tenia pensado seria:
En el microcontrolador hay un monton de subrutinas que ya estan probadas y funcionando, subrutinas como control Pwm, convertidor a/d, comparadores y un largo etc...
Por otro lado tenemos un programa que controla la carga de datos del puerto serie en la RAM, y segun esos datos en RAM lo que hace interpretar las ordenes y los datos para ir ejecutando esas subrutinas con los datos adecuados que tambien estan en la RAM.
En estas funciones deberia estar tambien implementadas la funciones propias de pic como goto, call, return etc... para poder hacer ciclos y demas cosas.
Creo que va mas haya del programa de "robots" que dices, ya que en si se crearian programas, que se podrian modificar constantemente escribiendo simplemente en este archivo de texto, y modificandolo, cada archivo de texto podrian ser programas totalmente distintos.
Se cargan se prueban y listo.
No esta estaria pensado tanto en hacer un proyecto definitivo en que se quedaria funcionando asi, sino que estaria pensado para probar creacion de programas y ver si funcionan, sobre todo en la rapidez de modificacion, carga y ejecucion.
Y una vez comprobado su funcionamiento, llevarlo a un programa de microcontrolador definitivo normal y al uso.
Pero en fin el desarrollo de este interpretador de ordenes y datos en RAM seria lo que llevaria un trabajito de mucho cuidado.. estoy convenciendome de que no merece la pena.
Como tu dices yo solo lo hago por hobby, No creo que para nada de lo que haga vaya a crear un revolucion...jejeje.... tampoco es mi interes, todo lo que hago es por divertirme.
Ademas no estoy inventando nada nuevo los micocontroladores , pic etc.. solo entienden de unos y ceros, el lenguaje ensamblador ya tiene un interpretador, el lenguace C ya es a un nivel superior y asi hasta los distintos lenguajes.
Saludos.
-
Estás intentando crear un lenguaje intérprete, algo totalmente ineficiente, aparte de que es bastante complejo de desarrollar.
Yo no perdería el tiempo en esas cosas, en todo caso haces tu programa en C, lo compilas y te creas un archivo de texto en tarjeta SD para parametrizar el funcionamiento, pero no para escribir ahí el programa.
Si te empeñas en el lenguaje intérprete, es algo que ya está inventado, te puedes bajar el MiniBasic, es un intérprete Basic desarrollado en C, que puedes portar a cualquier plataforma. Ahora, el rendimiento del microcontrolador se va a caer en picado. https://sourceforge.net/projects/minibasic/
Otro tema es rodar programas en Ram, no se si se puede hacer con los PIC. Con algunos ARM si que puedes compilar para que el programa se cargue y ejecute en Ram. Yo lo estoy haciendo con los RT1020, pero con memorias Ram de 256Mbit.
-
Saludos paneta9999
Menudo animalico el RT1020 creo que me llevaria toda una vida comprenderlo.
Hay por ahi un pic que no me acuerdo cual es que corre codigo en RAM una parte SRAM y tambien en memoria externa.
Pero poniendo mis pensamientos en alto en este post me doy cuenta de que la idea seria como un "debbuger" cargo,, un programa lo chequeo , y lo modifico las veces necesarias. Esto ya existe en los PICs con los ICD2 , ICD3, etc... pero a diferencia que la rutinas ya estarian grabadas en el PIC y grabadas de antemano y funcionando.
En fin no hay mejor cosa que publicar tus pensamientos....para que contesten de lo descabelladas y locas que son tus ideas y para mas remate..... tengan razon......jejejeje.
Saludos.
-
Menudo animalico el RT1020 creo que me llevaria toda una vida comprenderlo.
Que va, es muy sencillo, igual que programar cualquier otro microcontrolador en C. Además, usando el IDE MCUXpresso, tienes las Config Tools que te permiten configurar todos los periféricos y el reloj de manera gráfica, sin tener que escribir una solo linea de código, más fácil imposible, yo estoy encantado con el entorno de trabajo de NXP, es genial.
Lo que ya tiene más miga es el DMA, a mi al menos es un tema que me está costando bastante, pero a base de probar y probar, va saliendo, sobre todo usando los ejemplos que trae el SDK para los micros de NXP.
Acaban de sacar una nueva versión del IDE, la 10.3 y el SDK 2.5 que ya incluye las Peripheral Tools para la serie RT y los Kinetis, con este asistente configurar cualquier periférico es cosa de niños. Quiero mirarlo bien para ver si por fin puedo configurar el DMA sin tener que sufrir leyendo tochos de manuales que no hay quien los entienda, por ahora me he ido salvando a base de trabajar con los programas de ejemplo que trae el SDK, que son muchos.
-
También por lo que cuentas puede que te interese el lenguaje FORTH
y otra vez más, siendo que programe en ese lenguaje, porque no lees de que se trata, es lo más parecido a lo que planteas....
(y existe para pic tambien....)
-
Reitero lo del FORTH, al menos para que conozcas su filosofía. Te ayudará.
Otro tema semejante es el de las máquinas virtuales de bytecode, como la de java.
Yo estoy haciendo algo semejante, pero para secuenciar luces y servomotores.
Si que tiene muchas aplicaciones, pero en los pic deberías combinarlo con un bootloader para la flash y aprender la teoría que te propongo para que te dé ideas nuevas.
Saludos.
-
https://es.wikipedia.org/wiki/Forth
Esto es lo que tu quieres y es una de las implementaciones del FORTH:
https://es.wikipedia.org/wiki/C%C3%B3digo_enhebrado
Algo de máquinas virtuales, la de java es la más conocida:
https://es.wikipedia.org/wiki/M%C3%A1quina_virtual_Java
Tendrás que decidir si haces una máquina orientada a pila o bien orientada a registro:
https://es.wikipedia.org/wiki/M%C3%A1quina_de_registro
https://es.wikipedia.org/wiki/M%C3%A1quina_de_pila
Un saludo.
-
Estás intentando crear un lenguaje intérprete, algo totalmente ineficiente, aparte de que es bastante complejo de desarrollar.
Debes tener en cuenta que en muchos entornos el 80% del código de un programa contiene lógica que apenas consume un pequeño porcentaje del tiempo de ejecución pero que consume muchas horas de programación y pruebas.
Un lenguaje interpretado puede ser mucho más eficiente que uno compilado a la hora de desarrollar y probar un programa. No estás teniendo en cuenta el tiempo de desarrollo que en muchos casos supone el mayor coste del proyecto. Hoy en día te puedes comprar una CPU el doble de rápida por pocos euros más. Ya no estamos en los tiempos en los que había que exprimir hasta el útimo bit.
¿Realmente merece la pena dedicar 8 horas más de desarrollo para ahorrar dos euros en cada micro? Dependerá del número de micros que se vendan y como valores el tiempo de trabajo.
Un intérprete no es complejo de desarrollar. Hay multitud de lenguajes interpretados disponibles y hacer un lenguaje a medida de tipo enhebrado (cada número es una llamada a una subrutina) no lleva mucho tiempo, es tan simple como hacer una tabla y buscar valores.
Es posible que en ciertos entornos la mayor parte del código sea para hacer cálculos intensivos y en ese caso es normal que te decantes por el C o el código máquina. Pero siempre hay cierta lógica de programa que lleva poco tiempo de ejecución pero mucho de desarrollo y es muy tedioso tener que hacer un pequeño cambio, compilar, cargar el programa y volver a probar. En estos casos un lenguaje interpretado te da una velocidad de pruebas y una flexibilidad que no te puede dar el C de ninguna manera.
El FORTH es el lenguaje interpretado más ligero (puede caber en solo 2kb para empezar) y potente. Se ha usado en entornos profesionales realmente grandes. Aquí algunos ejemplos de la NASA: https://web.archive.org/web/20101024223709/http://forth.gsfc.nasa.gov/
El problema de este lenguaje es que hay que tener una buena disciplina de programación Bottom-Up para que el programa no se convierta en un verdadero lío. No es una opción para programadores con poca disciplina.
Lua pertenece ya a otro nivel. Ya hay varios micros que lo utilizan, por ejemplo el circuito ESP8266. Se puede combinar con facilidad con rutinas C para dejar a cada lenguaje la parte en la que es más eficiente.
Hay muchas más opciones, lo importante es echarles un vistazo y valorar sin prejuicios su posible utilidad.
Un saludo.
-
Muy buenas.. lamento no tener una contestacion rapida pero entre el trabajo y demas cosa no puedo contestar antes.
Saludos paneta9999 estuve viendo todos los productos de NXP , todos los perifericosa anexos la verdad es que esta muy interesante, tuve experiencias con algun freescale, atmegas, STm,. Pic.,.... pero la verdad es que ya la cabeza ya no me da pa mas.....jejeje :(
Quiza mas adelante... tambien es verdad que todo lo que hago yo es a nivel de aficionado y como hobby.
Muy buenas Picuino, estuve mirando lo que mandastes, bueno la verdad es que la maquina en la que estaria yo ahora mismo es una maquina de registro y casi no llegaria ni maquina contadora.
Bueno esta muy bien lo del FORTH, yo he trabajado con ensamblador, C y lenguajes interpretados, pero todavia no he llegado a este punto,eso seria quiza un poquito mas adelante.
Me explico y esto si es muy **** IMPORTANTE***** para lo que queria desarrollar.
1) Los entornos de desarrollo como describe paneta9999 con los NXP , Arduinos, Mplab para PIc, Workbench para STM, y a si un largo etc... son magnificos, aunque tuviera 50 vidas no creo que pudiera desarrollar ni el 1% de cualquiera de ellos, pero ademas es que eso tampoco es mi interes.
2) Muchisimas veces en uno de estos entornos de desarrollo pongamos un ejemplo el control de un dispositivo GPS, lo controla hasta donde lo controla y si quieres averiguar mas para hacer un control mas exaustivo, el meterte en ver como lo hacen, se hace complicado cuando por lo general esta oculto. Aun asi son magnificos yo no les quito su grandisima utilidad.
De todo esto es lo que surge la necesidad y siguiendo con el ejemplo del dispositivo GPS, pues dices bueno voy hacer un rutina de puerto Serial que controlo este dispositivo y le vaya metiendo datos al dispositivo haber como reacciona.
Bueno empiezas a darte cuenta que tienes que modificando el programa mil veces y volviendolo a quemar otras tantas y al final te surje la idea bueno si pudiera cargar datos en memoria del microcontrolador y que los fuera sacando para atacar al gps, sin tener que estar modificando y quemando, y al final lo consigues y fenomenal. Cargo un archivo en la memoria del Pic, el PIc lee estos datos y los saca al dispositivo GPS.
Bueno hasta ahi fenomenal, pero tienes que probar otro tipo de dispositvo o simplemente por ejemplo crear una serie de pulsos o lo que sea y entonces ya no necesitas de una subrutina si no de varias. ( Decir que estas subrutinas ya estan funcionando perfectamente dentro del programa Flash del PIc y probadas) .
Y entondes te pones a diseñar otro programita que interprete los datos que se han almacenado en la memoria RAM para que y haga actuar a las subrutinas adecuadas y le meta los datos adecuados.
Entonces es cuando te empiezas a dar cuenta de que si cada vez que quieres probar un circuito o hacer cualquier cosa es un coñazo hacer un programita por cada proyecto y cuando te empiezas a plantear una especie de interpretador de ordenes que haga todas estas funciones y cuando vea los datos en RAM sea el el que escoga que subrutinas tienen que funcionar y los datos que tiene que utilizar.
Pero claro como se a llegado a lo conclusion en este Post , es que la verdad es que esto es un trabajito de muchisimo cuidado.
Yo ya lo empence a hacer. empezando por ordenes muy basicas, pero todavia no lo he probado...... en fin bonito el proyecto .... pero muy trabajoso.
Saludos a todos.
-
Un lenguaje sencillo (user friendly, mucho más que el FORTH) pequeño en memoria y muy usado es el TCL.
https://en.m.wikipedia.org/wiki/Tcl
No conozco ninguna implementación para Pic, pero debe haber alguna o se podrá adaptar una de otro micro.
-
Otro lenguaje de script y una razón más para pasarse al Arduino: http://www.juniper-lang.org/ Lo borro porque no parece que sea interpretado.
Esta es una implementación (PICOL) realmente muy pequeña de TCL:
https://chiselapp.com/user/dbohdan/repository/picol/index
Ocupa 4000 líneas de código y está más orientado al aprendizaje "Note that Picol is not intended for production use", pero creo que es un buen punto de partida para implementar TCL.
Se puede extender con nuevos comandos que llamen a rutinas en C propias.
Saludos.
-
Flash Forth para pic y avr
http://flashforth.com/
Se me olvidaba comentar que el FORTH es, además de un intérprete, un compilador que compila a código máquina desde el propio microcontrolador.
Precisamente por esa capacidad es por lo que se ha utilizado a la hora de comenzar a programar nuevos sistemas hardware y sistemas BIOS.
Saludos.
-
Saludos Picuino n y toda la gente.
Estuve pensando como podria ser el conjunto de diagrama de flujo de todo el conjunto y para mi podria ser de la siguiente forma.
- Tienes que ingresar para ver archivos adjuntos -
Lo que hace la occiosidad ....si estuviera a pico y pala seguro que no estaria pensando en estas cosas......jejeje.
Bueno en principio el interpretador de ordenes dentro del PIC es muy sencillo en el sentido de las pocas ordenes que tiene que utilizar, basicamente lo que tiene que hacer es llevar datos de un lado a otro y al final llamar a la subrutina o subrutinas.
Ordenes unicamente en ensamblador como movlw, movff, movwf POSTINC0, call, return y poco mas, por eso yo pienso en ensamblador.
Los datos que recibe de RAM vienen de un archivo por ejemplo dato.dat que lo que contiene son numeros, tales como 12, 23, 45, 145, etc..
Que significa 12 pues por ejemplo carga los registros de retardo con los valores siguientes que son 23,45 y 45
luego por ejemplo encuentra el numero 123 -- que puede significar inicializa subrutina I2C y asi indefinidamente.
Y al final ejecuta todo.
Si no quisieramos hacer nada mas lo unico que tendriamos que hacer es crear un archivo dato.dat cada vez que quisieramos hacer un programa con numeros, pero tendriamos que tener memorizado que siginifica esos numeros, lo cual es un poco coñazo.
Sino creariamos un lenguaje de programacion basico, que mediante un compilador nos creara el archivo.dat, esto es si por ejemplo el compilador encuentra la palabra "inicializa_I2C" pues sabe que tiene que meter el numero por ejemplo "123" dentro del archivo.dat.
Bueno ahi es donde creo que entran los lenguajes de programacion FORTH, tcl-tk, lenguaje C, java o lo que se desee.
cl
Yo en este sentido para hacer los trabajos duros me encuentro muy acostrumbado al C, tengo experiencia con tcl-tk y otros lenguajes tambien interpretados.
Muchas veces el pensar en alto ayuda a clarificar ideas.
Muchas gracias por tus ideas Picuino.
-
Aquí hay un artículo muy interesante de un programador que comenzó haciendo una versión TinyBasic para el 8080 y realizó interpretes para portar código del Apple original (con un 68000) al Apple con Power PC.
http://www.drdobbs.com/web-development/the-return-of-tiny-basic/184406381
Desarrolla varias ideas muy interesantes:
Tipos de lenguajes:
1º Lenguaje interpretado (el más largo e ineficiente, el más sencillo de leer)
2º Lenguaje Bytecode o lenguaje intermedio, que es la traslación del lenguaje texto a otro más cercano a la máquina. No es lenguaje máquina es de mayor nivel. Puede consistir en números que corresponden a la rutina a llamar y a los argumentos.
3º Lenguaje máquina del microprocesador donde se ejecuta.
Los compiladores pasan del 1º al 3º.
Los intérpretes pasan del 1º al 2º y luego ejecutan el bytecode. Hay diferentes tipos de bytecode, los del basic son lentos y añaden unas 10 instrucciones de código máquina por bytecode. Los del FORTH son más rápidos y apenas añaden 2 o 3 instrucciones de código máquina por bytecode.
Los intérpretes JIT (just in time) pasan del 1º al 2º y justo antes de ejecutar el programa pasan del 2º al 3º con lo que al final ejecutan código máquina y son casi tan rápidos como un compilador.
Velocidad de ejecución:
Es curioso que en muchas ocasiones, en los modernos microprocesadores, la velocidad de un lenguaje interpretado puede ser mayor que la de un lenguaje compilado !!!
Esto se debe a los fallos de página de la caché. Los lenguajes interpretados con máquina virtual (bytecode) son muy eficientes en espacio y esto hace que ocupen poca memoria. Si todo el programa cabe en la caché, no se dan fallos de página. Un programa equivalente compilado que tenga fallos de página puede ralentizarse mucho más.
Tiny Basic:
Es un lenguaje muy antiguo y relativamente lento, pero tiene muchas ventajas, porque estaba diseñado para microcontroladores que apenas llegaban a los 4k de memoria, equivalente a un pequeño microcontrolador de hoy.
He encontrado varias páginas con el dódigo fuente, pero no he tenido tiempo de evaluarlas.
https://gist.github.com/pmachapman/661f0fff9814231fde48
https://github.com/BleuLlama/TinyBasicPlus
http://www.nicholson.com/rhn/basic/basic.info.html
Wikipedia: https://es.wikipedia.org/wiki/Tiny_BASIC
-
Saludos Picuino n y toda la gente.
Estuve pensando como podria ser el conjunto de diagrama de flujo de todo el conjunto y para mi podria ser de la siguiente forma.
1º Yo no lo haría con ensamblador. Es más eficiente en velocidad, pero hoy en día por pocos céntimos consigues un PIC más potente. En c será más portable y rápido de escribir (podrás aprovechar programas que ya existen).
2º Yo metería el intérprete dentro del microcontrolador. Que al micro le lleguen las líneas de código en formato texto y que las transforme en su propio lenguaje interpretado (IL). Algo parecido al Bytecode.
El intérprete no tiene por qué ocupar más de 4k de programa.
En el PC puedes hacer el programa que envíe el texto por la UART, con control XON XOFF u otro equivalente.
OTRA SOLUCIÓN COMPLETAMENTE DISTINTA:
También tienes que considerar otra solución que te puede interesar.
Puedes programar un bootloader muy grande, con sistema de entrada, salida, control de periféricos y todas las funciones que te interesen. Algo parecido a la BIOS de los PC.
Luego puedes compilar un pequeño programa que haga llamadas a las funciones de la BIOS y lo envías para que el bootloader lo grabe en memoria.
De esa manera el tiempo de grabación es pequeño y puedes hacer debug gracias al bootloader, interactuando con él por medio del puerto serie.
Todo el control y el envío de programa se hace por puerto serie, sin el programador.
MicroChip te da alguna solución parecida, aunque no la conozco bien.
El problema de esta solución es que no tienes posibilidad de programar el micro sin un compilador, mientras que con el código interpretado si que puedes.
Un saludo.
-
Muy buenas noches Picuino y demas gente.
Estamos pensando en proyectos distintos, la verdad es yo deseo hacer algo tan complicado como dije en post anteriores, en realidad es para probar dispositivos o probar trozos de codigo muy pequeños, de unas pocas lineas 20, 30 a lo maximo 200 lineas que es lo que ocuparia un bloque de memoria RAM.
En ningun momento se escribe codigo en la memoria flash, las subrutinas ya as escritas y probadas, el programa en RAM lo unico que hace es seleccionar las rutinas adecuadas y meterle los datos para que funcionen y correrlas-
1º Yo no lo haría con ensamblador. Es más eficiente en velocidad, pero hoy en día por pocos céntimos consigues un PIC más potente. En c será más portable y rápido de escribir (podrás aprovechar programas que ya existen).
Todo esto es cierto, a mi no me importa utilizar en este sentido una cosa o la otra.
2º Yo metería el intérprete dentro del microcontrolador. Que al micro le lleguen las líneas de código en formato texto y que las transforme en su propio lenguaje interpretado (IL). Algo parecido al Bytecode.
El intérprete no tiene por qué ocupar más de 4k de programa.
Buff a mi esto me parece muy complidado, creo que todos los entornos de desarrollo que hay por ahi al final lo que hacen es meter codigo en ensamblador dentro del microcontrolador.
La unica justificacion que existiria para meter un interprete de lineas de codigo en formato texto, seria que quisieras montar un miniordenador, algo parecido al Spectrump, o algo asi y que fuera necesario una compilacion en linea desde teclado o desde un archivo de texto en el propio sistema sino pienso que es mucho mas sencillo desde fuera.
Esa el la idea que tengo aunque puede que sea util para alguna otra aplicacion, que en este momento se me escapa.
Este es otro proyecto muy interesante que alguna vez tambien he estado tentado de empezarlo.
El problema de esta solución es que no tienes posibilidad de programar el micro sin un compilador, mientras que con el código interpretado si que puedes.
El proyecto que yo estoy trabajando cuando hablo de compilacion no es compilacion para crear memoria en flash, sino para crear programa en RAM, en ningun momento se graba ningun momento se graba una sola linea de codigo en Flash.
Aun asi este post esta abierto a todo y yo siempre estoy abierto a todo tipo de proyectos....
Un saludo Picuino.
-
Yo creo que los proyectos no son tan distintos. Solo tienen diferentes opciones.
Yo también estoy ahora pensando en cómo desarrollar el secuenciador de luces y la opción era un lenguaje a medida almacenado en RAM o en FLASH.
Por concretar.
1º Hay que elegir un lenguaje de alto nivel.
Es el que escribe la persona en formato de archivo de texto.
Se puede escoger un lenguaje estandar como TinyBasic o FORTH, con la ventaja de que son estándar y ya hay mucho trabajo hecho y muchas personas que lo pueden entender.
También se puede escoger un lenguaje más sencillo. En otra implementación que hice, inventé un lenguaje sencillo basado en orden y argumentos para la comunicación entre 2 procesadores. En este caso también estaba pensando en hacer un pequeño lenguaje a medida con solo 5 instrucciones, sin condiciones y sin bucles. Para secuenciar luces no hace falta mucho más.
El problema del lenguaje a medida es que es más complejo de desarrollar o si se hace simple, queda demasiado limitado.
2º Escoger el Lenguaje Intermedio
En este caso hay que definir un lenguaje objeto o lenguaje máquina, independiente del dispositivo. Este es el lenguaje al que se va a traducir el primero por parte del intérprete. Los compiladores también hacen este paso antes de convertir el lenguaje intermedio a código máquina.
En este caso hay que decidir qué tipo de lenguaje utilizar. Los lenguajes basados en pila y llamadas, de tipo Forth, son muy eficientes. Pueden ser muy eficientes en velocidad o muy eficientes en tamaño, dependiendo de la implementación.
Otra aproximación es utilizar registros fijos en memoria. El problema de esta aproximación es que no es reentrante y se da de tortas con los programas cooperativos. La ventaja es que evitas muchos pasos de argumentos entre funciones y es más rápido.
También se puede hacer un lenguaje basado en paso de argumentos. Primero la instrucción y luego los argumentos.
También hay que escoger si las instrucciones tienen tamaño fijo o tamaño variable. Cada una tiene sus ventajas e inconvenientes.
3º Escoger dónde colocar cada uno
En tu caso el intérprete de alto nivel quieres que esté en el ordenador, pero en ocasiones puede ser más interesante que esté en el micro. Por ejemplo en mi caso me estaba planteando que el secuenciador se pueda programar con un mando a distancia. Esto significa que las órdenes deben ser pocas y el intérprete completo debe estar dentro del micro.
El lugar donde colocarlo es lo de menos, pero yo te aconsejo que lo programes todo en C y así puedes moverlo donde quieras sin mucho esfuerzo. El C vale para cualquier sitio.
Por ahora ya hay tarea suficiente.
-
En mi caso tengo un micro con 4kwords, de las que 1kword está ocupado por rutinas básicas de manejo de PWM y similares.
La velocidad del micro no es problema, trabajando a 32MHz tengo potencia de sobra para encender y apagar luces con un intérprete.
Tengo que hacer por lo tanto un intérprete en unos 2kword del PIC. En principio no necesito ni variables, ni condicionales. Puede que necesite bucles, pero muy sencillos.
Lo que si necesito obligatoriamente es hacer tareas cooperativas. Las secuencias deben ejecutarse a la vez en tiempo real y de forma independiente. Aunque tengo que añadir algún mecanismo para sincronizarlas en alguna ocasión.
Lo que había pensado es hacer task independientes y que las órdenes de espera (wait) permitan pasar al intérprete de un task a otro.
Por último necesito almacenar varios programas en la memoria. Cada uno con varias task.
Esto me obliga a hacer cierta recolección de basura. Si borro un programa, el hueco debe rellenarse moviendo los demás datos.
Mi memoria RAM libre es de unos 300bytes. Es poco, pero lo veo suficiente para hacer un programa de forma interactiva. Una vez que el programa funcione bien, lo puedo almacenar en memoria FLASH.
En principio había pensado en 3 instrucciones:
SETPWM numero_de_led, valor_pwm
WAIT milisegundos
RAMPA numero_de_led, valor_pwm_final, milisegundos
Además quería añadir las palabras TASK, PROGRAM y END, para definir una tarea o un programa compuesto de varias tareas, con la palabra END para finalizar la definición.
Lo que no me gusta del TinyBasic es la utilización de números de línea. Pero no hay otra manera sencilla de editar un programa de varias líneas de forma interactiva.
-
Un artículo interesante sobre el lenguaje Partcl:
https://zserge.com/blog/tcl-interpreter.html
-
Muy buenos dias Picuino:
Haber vamos por partes y lo primero es saber que exactamente lo que deseas que quiere hacer tu proyecto.
Segun citas anteriores:
Yo estoy haciendo algo semejante, pero para secuenciar luces y servomotores.
Otra cita
Por concretar.
1º Hay que elegir un lenguaje de alto nivel.
Es el que escribe la persona en formato de archivo de texto.
Bueno por lo que adivino, lo que estas buscando es hacer un programa en que tienes que enceder unos Leds o Luces lo que sea y en un determinado secuencia de tiempo.
Quieres que este programa haga una presentacion para la persona que maneja el equipo y que esta persona pueda elegir que luces se van activar y cuales no, y el tiempo o retardo entre intervalos de salidas.
Me supongo que logicamente dispondra por tanto de un teclado y de un display LCD o pantalla TFT, o no si por ejemplo los datos los carga atraves de un ordenador por puerto serie o por USB.
Si estas afirmaciones son correctas para que complicarse la vida por que no crear un menu:
El usuario va eligiendo como como quiere que se activen las luces y el intervalo de tiempo entre unas y otras.
Cuando acaba presiona en el teclado si hay teclado la orden quit, y esto automaticamente graba en una EEprom externa o en la misma EEProm del microcontrolador por ejemplo de la siguiente forma:
dato_salida1, tiempo1
dato_salida2, tiempo2
etc...
Cuando se da la orden ejecutar el programa no tiene mas que ir leyendo secuencialmente la memoria EEProm y ir sacando lo datos.
Seguramente me estoy equivocando de cabo a rabo, pero tendria que saber mas exactamente que quiere hacer tu proyecto.
Primero es definir perfectamente cuales son la funciones de nuestro proyecto.
Por que podemos complicarlo todo lo que queramos, pero en principio para que tomarse tanto trabajico.
Un saludo Picuino
-
Se me olvidaba ... que microcontrolador tienes pensado usar?
Saludos.
-
Estoy usando para las pruebas un PIC16F15325, pero tengo la intención de que quepa en un PIC16F15324.
La idea es usar una comunicación con un PC por puerto serie (con un conversor USB a UART externo).
Las secuencias pueden ser sencillas, pero hay que describirlas de alguna manera. Eso que dices es un lenguaje de programación.
Imagina un ejemplo de dos luces que se encienden y se apagan alternativamente cada segundo:
TASK 1
WAIT 500
LED 1, 250
WAIT 500
LED 1, 0
END
TASK 2
LED 2, 250
WAIT 500
LED 2, 0
WAIT 500
END
PROGRAM 1
TASK 1
TASK 2
END
Los tiempos pueden ser muy distintos e independientes.
Imagina ahora que quieres programar un led RGB tililando como el fuego, cambiando rápidamente entre tonos amarillos y naranjas.
Mientras otro led va aumentando y disminuyendo la luz progresivamente de manera lenta, imitando el amanecer.
Por otro lado tres led (rojo, verde y ambar) imitan la secuencia de un semáforo con los parpadeos de la luz ambar.
Además quiero cambiar los tiempos de cada uno de forma independiente.
Eso hay que hacerlo con algún lenguaje de programación.
Un saludo.
-
Eso es por la parte de las luces, porque también quiero incluir un control de servomotor para hacer una o dos secuencias de movimientos.
-
Hola buenas Picuino:
Voy intentando entender tu proyecto:
La idea es usar una comunicación con un PC por puerto serie (con un conversor USB a UART externo).
Presupongo que es por el puerto serie por donde quieres meter los datos para que las luces vayan variando.
Las secuencias pueden ser sencillas, pero hay que describirlas de alguna manera. Eso que dices es un lenguaje de programación.
Pueden ser simplemente datos o bytes registrados en la memoria RAM, luego el programa que tienes dentro del Pic se encargue de interpretarlos y ejecutarlos .
TASK 1
WAIT 500
LED 1, 250
WAIT 500
LED 1, 0
END
El valor 250 puedo ser como una especie de ciclo de PWM?
Segun lo que te dije antes atraves del puerto serie almacenas en las posiciones :
posicion contenido
RAM
100 - valor 10 significa que llame a subrutina fijar los valores del retardo
101 - valor 0
102 - valor 50
103 - valor 10 estos tres ultimos valores hacen que al final sea el retardo de 500
104 - valor 30 esto hace que corra la subrutina que tienes arriba de encender el LED1
105 -valor 31 hace que corra la subrutina de LED2
106 -valor 'q' quit fin de programa.
Asi es como funcionaria mi programa, las subrutinas ya estarian escritas y funcionando en la flash, no se si esto te podria valer a ti.
El programa se puede complicar todo lo que quieras...
Para probar los efectos de luz lo unico que tendrias que es variar el archivo de carga RAM volver a cargarlo y correrlo puedes tardar a lo mejor 10 segundos en hacerlo.
Saludos.
-
Presupongo que es por el puerto serie por donde quieres meter los datos para que las luces vayan variando.
Por el puerto serie meto el programa en formato de texto. Luego las luces varían dependiendo del programa, sin necesidad de conexión con el PC.
El puerto serie es en realidad un conversor USB-UART
El valor 250 puedo ser como una especie de ciclo de PWM?
Si, el pwm va desde 0 (apagado) hasta 250 (brillo máximo)
Segun lo que te dije antes atraves del puerto serie almacenas en las posiciones :
posicion contenido
RAM
100 - valor 10 significa que llame a subrutina fijar los valores del retardo
101 - valor 0
102 - valor 50
103 - valor 10 estos tres ultimos valores hacen que al final sea el retardo de 500
104 - valor 30 esto hace que corra la subrutina que tienes arriba de encender el LED1
105 -valor 31 hace que corra la subrutina de LED2
106 -valor 'q' quit fin de programa.
La ram sería igual en los dos proyectos (el tuyo y el mío), pero en el mío el microcontrolador recibe los datos en formato texto y los convierte en lenguaje intermedio almacenado en la RAM. Posteriormente, una rutina se encarga de ejecutar los códigos de la RAM.
En mi caso el intérprete está en el micro y en tu caso el intérprete está en el PC.
En los dos casos, los intérpretes utilizan un lenguaje intermedio que se almacena en RAM.
En los dos casos una máquina virtual se encarga de interpretar ese lenguaje intermedio llamando a las subrutinas.
Pero en el mío
-
La traducción correcta para mi código sería algo así:
(He cambiado algo las órdenes porque aún estoy definiendo el lenguaje)
Progama en formato texto:
TASK 1
WAIT 500
LED 1, 250
WAIT 500
LED 1, 0
REPEAT
END
Programa en lenguaje intermedio o bytecode:
0x01 // orden WAIT
0xF4
0x01 // numero 500 en formato de 16bits little-endian (podría también utilizarse big-endian)
0x11 // orden cambiar luminosidad del led 1 (0x12 sería cambiar la luminosidad del led 2)
0xFA // Valor 250 en formato de 8 bits sin signo
0x01 // orden WAIT
0xF4
0x01 // numero 500 en formato de 16bits little-endian (podría también utilizarse big-endian)
0x11 // orden cambiar luminosidad del led 1 (0x12 sería cambiar la luminosidad del led 2)
0xFA // Valor 250 en formato de 8 bits sin signo
0x02 // REPEAT. Se comienza otra vez desde el principio
0x00 // END. Fin de la tarea.
Con esto estaría almacenada la rutina en RAM.
A continuación un programa sería una tarea especial que sirve para lanzar a un conjunto de tareas todas juntas. Se almacena en memoria así:
TASK 3
RUN 1 // Ejecuta la tarea 1
RUN 2 // Ejecuta la tarea 2
END
0x02 // orden init TASK
0x01 // Tarea número 1 (la primera tarea almacenada en la tablas de tareas
0x02 // orden init TASK
0x02 // Tarea número 2 (la segunda tarea almacenada en la tablas de tareas
0x00 // END. Fin de la tarea. El programa termina y no se repite más.
Por último, la posición en RAM de cada una de las tareas se almacenan en una tabla.
Con la orden RUN 1 se ejecuta la tarea almacenada en la tabla en la primera posición.
Con la orden RUN 2 se ejecuta la tarea almacenada en la tabla en la Segunda posición.
Ahora las dos tareas se ejecutan a la vez, pero han comenzado en tiempos distintos y no están sincronizadas.
Si lo paro todo y mato las tareas (STOP) puedo iniciar las dos a la vez de forma sincronizada llamando a la tarea 3. RUN 3
-
Para sincronizar todas las tareas hago lo siguiente:
1. El sistema tiene un contador de milisegundos que se va actualizando por interrupciones.
Por ejemplo podría estar en 15300 milisegundos
2. Cada tarea tiene un contador de tiempo, que se copia del contador de milisegundos del sistema con la orden RUN.
En este caso se copiaría 15300
3. En cada orden WAIT, se incrementa el contador de tiempo de la tarea
Por ejemplo un WAIT 500, aumentaría el contador de la tarea hasta 15800 milisegundos
Hasta que el contador del sistema no llege al valor del contador de la tarea, el programa no sigue adelante.
Esto asegura que no se pierden milisegundos al ejecutar otras instrucciones y así la cuenta de milisegundos de todas las tareas siempre estarán sincronizadas.
Esto evita tener que añadir instrucciones de sincronización y asegura que los tiempos de los programas siempre son consistentes.
Un saludo.
-
https://wiki.tcl-lang.org/page/Small+Tcl
Do you want a particularly small version of Tcl to embed in a hardware-constrained device? You're not the first. There are a few possibilities listed in the Implementations section of this page.
-
Muy buena Picuino
Veo que tienes la idea de meter el compilador de texto dentro del microcontrolador, no se cuanto lo tendras avanzado, pero lo veo un buen trabajito ademas de ver la forma como implentar cualquiera de los lenguajes que propones como tcl,... etc..
Aparte de espacio que ocupara esto el PIC.
Estoy usando para las pruebas un PIC16F15325, pero tengo la intención de que quepa en un PIC16F15324
No se te quedaran un poco pequeños estos pics.
Yo este proyecto es igual a mi idea que tuve hace mucho tiempo, tengo varios 8085, todos los integrados anexos a esta serie, control teclado, expansor puerto, etc..
Con la idea de montarme un miniordenador parecido al Spectrump, bueno pues la idea a la hora de montar el compilador en aquella epoca se usaban las memoria UVprom, estas eran la memorias que venian con ventanita de cristal y que se borraban con una lampara de ultravioleta, se programaban con un programador de Vprom.
El compilador que usaba el Basic de aquella epoca, bueno pues pensando como implementarselo lo que se me ocurrio en aquel momento fuera con una de esas memoria UVprom, aunque hoy existiendo las memorias EEprom esto es mucho mas sencillo.
Al caso, la forma de implentarselo que se me ocurrio en esa epoca, era grabar en la memoria sucesivamente el texto de la orden y seguido el codigo en hexadecima de esa orden, de la forma siguiente .. como ejemplo
orden codigo hex
LET 05h
PRINT 0Ah
GOTO 3Ch
QUIT 3Ah
---------
---------
ETC...
El que manejaba el Spectrump en aquella epoca, se acordara de que se metia la orden comando por teclado y se apretaba ENTER, si no era correcto te daba un mensaje error, y si lo era daba mensaje creo OK. y esperaba el siguiente comando asi sucesivamente.
El caso es que interiormente me supongo que lo que haria es comparar la cadena de texto con una de las almacenadas en la memoria UVprom y encontraba la coincidencia pues le asociaba el valor en hexadecimal de la orden.
Bueno todo este rollo es para mostrarte otro punto de vista, que podria ser el grabar una memoria EEprom externa o la misma memoria interna del microcontrolador las cadenas de texto con las ordenes y seguido el codigo hexadecimal asociado, lo unico que te tienes construir una subruitina que compare la cadena en EEprom con la que tu has metido por el puerto serie, y te de codigo HEX correspondiente.
El construir una subrutina que haga eso no me parece nada complicado y en principio me parece menos complicado que intentar implementar un tcl dentro del Pic.
Tampoco estoy por quitarte la idea, cada uno debe tener sus ideas propias para su proyecto, simplemente te doy un punto de vista diferente.
Un abrazo.
-
Buenas ..
Precisamente rebuscando entre componentes que habia comprado hace tiempo em encontre con 5 - PIC24HJ128GP506, no me arcordaba ni que los tenia,
Y ahora me recorde que los tenia precisamente para un proyecto como este que era correr programas en la memoria RAM externa.
http://ww1.microchip.com/downloads/en/DeviceDoc/70175H.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/70175H.pdf)
Saludos
-
Hola misterweb. Implementar el TCL en un pic es casi imposible. Es un lenguaje muy flexible y dinámico en tiempo de ejecución y necesita mucha memoria RAM.
El TCL estaría al nivel del Lua, ambos para microprocesadores de 32 bits ocupando unos 100kb de memoria Flash.
Lo bueno del TCL es su filosofía muy simple y flexible. Puede inspirar para hacer otros lenguajes. Además la versión Picol ocupa solo 800 líneas de código, por lo que es suficientemente sencillo como para estudiarlo.
Por otro lado el Forth para Arduino ocupa unos 8kb. Es demasiado grande, aunque no necesito el compilador solo intérprete. Pero no voy a intentar simplificarlo porque no me gusta mucho la notación RPN.
He probado a compilar el uBasic y ha ocupado unos 3900Words, casi toda la memoria, pero ya se va acercando a lo que quiero.
Si al final veo muchos problemas de memoria, haré lo que tu pensabas, colocar el compilador en el PC. Por ahora tengo todas las rutinas de PWM y de comunicación UART por interrupciones en 1430 words (35% de memoria ocupada).
La idea final creo que será implementar una especie de lenguaje máquina interpretado. Como tú dices es bastante sencillo implementar el compilador. Simplemente se busca la palabra en un diccionario y se traduce a un código en memoria.
Luego un intérprete se limita a llamar a las diferentes funciones según el código que se encuentre en la memoria (una orden switch case)
Por ahora estoy liado con las estructuras de datos. Tengo que ponerlo todo en RAM, con la opción de guardar programas en FLASH para recuperarlos más adelante.
Un saludo.
-
Muy buenas Picuino y demas gente:
Si al final veo muchos problemas de memoria, haré lo que tu pensabas, colocar el compilador en el PC.
En principio sino no son muchos comandos inclusive en la flash del microcontrolador, en C podria ser algo
parecido a esto.
char COMANDO [ ] = "WAIT";
if (strcmp(DATO_EN_RAM, COMANDO) == 0) { graba_codigo_hex_de_wait_en_RAM(); }
char COMANDO [ ] = "LED1";
if (strcmp(DATO_EN_RAM, COMANDO) == 0) { graba_codigo_hex_de_wait_en_RAM(); }
Si ya empiezan a ser muchos comandos se podria almacenar los textos en la eeprom o de pic o exterior y entonces
y crear una rutina que vaya buscando los datos en la eeprom comparandola con la variable DATO_EN_RAM
y cuando encuentre coincidencia grabe dato contiguo en la eeprom, que es el codigo hex del comando en la RAM.
Para ello a lo mejor habra que dar un tamaño de grabacion del texto del comando en la eeprom, esto es dar un
ancho por ejemplo de 8 caracteres estandar, si el comando tiene menos caracteres rellenarlos con espacios en blanco,
y lo mismo los datos del comando que vienen por el puerto serie y se almacenan en RAM.
De esta forma asegura la comparacion y la sincronizacion de los datos.
y de comunicación UART por interrupciones en 1430 words
Gracias a la interrupcion del puerto serie por que si no los datos se acaban perdiendo por falta de sincronizacion
entre PC y PIC.
Luego un intérprete se limita a llamar a las diferentes funciones según el código que se encuentre en la memoria
(una orden switch case)
A lo mejor si lo vas a grabar en la flash, entonces correrlo ya directamente en la flash.
Puede que en algunos casos si grabas flash de esta forma tengas que recolocar todo el programa flash del pic o parte.
Aunque seguramente antes de grabarlo en flash lo que querras probar en memoria.
En mi caso en ensamblador el este codigo seria algo parecido a esto:
;**********************************************************************
; SUBRUTINA EJECUCION PROGRAMA RAM EN BLOQUE 100 - 1FF
; LOS CODIOGOS DE COMANDOS YA ESTAN ALMACENADOS EN EN ESTE BLOQUE
; JUNTO CONLOS DATOS ANEXOS.
;**********************************************************************
RUNPROG
movlw 0x01 ; Inicializacion contador de program
movwf FSR0H ;
movlw 0x00
movwf FSR0L
movlw 0ffh
movwf COUNTER
LAZO
movf POSTINC0,W ; Mueve el dato de memoria a work y incrementa a la posicion
addwf PCL,1 ; Sumaselo a PCL para saltar al comando adecuado
bra COMANDO1 ; CARGA COMANDO 1 ENVIAR UN DATO POR EL PUERTO A
bra COMANDO2 ; CARGA COMANDO 2 ENVIAR UN DATO POR EL PUERTO B
bra COMANDO3 ; CARGA COMANDO 3 ENVIAR UN DATO POR EL PUERTO C
bra COMANDO4 ; CARGA COMANDO 4 PARA CONFIGURAR LAS VARIABLES DEL RETARDO
bra COMANDO5 ; CARGA COMANDO 5 HACER UN SALTO INCODICIONAL A UNA DIRECCION DE PROGRAMA.
bra COMANDO6 ; CARGA COMANDO 6 HACER UN SALTO CODICIONAL A UNA DIRECCION DE PROGRAMA.
bra COMANDO7 ; CARGA COMANDO 7 PARA EJERCUTAR LA FUNCION RETURN RETORNO LLAMADA CALL.
bra COMANDO8 ; CARGA COMANDO 8 ENVIO DE UN DATO BLOQUE 300-3FF A UNA POSICION DETERMINADA 200-2FF.
bra COMANDO9 ; CARGA COMANDO 9 CONFIGURACION ENVION DATOS COMANDO ANTERIOR -- COMANDO8.
bra COMANDO10 ; CARGA COMANDO 10 PARA CONFIGURACION PUERTO A TRISA
bra COMANDO11 ; CARGA COMANDO 11 PARA CONFIGURACION PUERTO B TRISB
bra COMANDO12 ; CARGA COMANDO 12 PARA CONFIGURACION PUERTO C TRISC
bra COMANDO13 ; CARGA COMANDO 13 CONFIGURA PUERTO I2C VIRTUAL.
bra COMANDO14 ; CARGA COMANDO 14 SACA DATO POR EL PUERTO I2C VIRTUAL.
bra COMANDO15 ; CARGA COMANDO 15 FIJA CONDICION DE START.
bra COMANDO16 ; CARGA COMANDO 16 INICIA CIRCUITO I2C
ETC...
salida
decfsz COUNTER
goto LAZO
return
COMANDO1 ; EJEMPLO
ETC..
ETC..
bra salida
COMANDO2
ETC..
COMANDO3
ETC..
Por ahora estoy liado con las estructuras de datos. Tengo que ponerlo todo en RAM, con la opción de guardar
programas en FLASH para recuperarlos más adelante.
¿Puede ser po los tamaños de los textos de los comandos como comente anteriormente? cual es el problema.
Que bonito, en definito es lo mismo que hace un ordenador o el Spectrump, que es compilar y descompilar o lo que
es lo mismo ensamblar y desensamblar.
Bueno si lo grabas en una eeprom, lo mismo que cuando compilas buscas la cadena y cuando lo encuentras salvas el
codigo del comando, cuando descompiles puedes hacer lo inverso, que es buscar el codigo de del comando y extraer
de la misma eeprom la cadena correspondiente.
La verdad es que todo esto es un buen trabajito.....jejeje, pero a mi me parece muy interesante.
Ademas Picuino cuando alguien crea un compilador, nadie lo crea todo a la vez, pasito a pasito, pienso que
nada es trabajo perdido, puede que en algun momento tengas que modificar muchas cosas pero aunque parezca
que no todo lo anterior vale.
Para mi que hago todas estas cosas por puro hobby el placer esta justo en el momento que estoy creando el codigo.
acabado esto queda satisfacion pero pasado el tiempo casi el olvido.
Un saludo.
-
El problema que tengo consiste en que cada rutina necesita memoria ram para los punteros de ejecucion, el estado run o idle, el contador de tiempo de espera, etc.
Para que sea pequeño y reubicable utilizo punteros relativos de 1byte.
La idea es rescatar una rutina de la flash y colocarla en ram para ejecutarla.
También quiero poder guardar una rutina desde la ram hasta la flash.
Como dices, la parte de compilación es sencilla porque solo hay 5 comandos sencillos.
A mi también me gusta la idea de emular un pequeño micro como el spectrum, aunque mi proyecto sea mucho más sencillo.
Un saludo.
-
Si la idea es probar secuencias de comandos para controlar algún dispositivo como LCDs o módulos SPI, I2C usando puerto serial, creo que la mejor alternativa sería implementar algo similar a lo que hicieron los de Sparkfun en el BusPirate:
(http://dangerousprototypes.com/docs/images/7/7f/Bp-action-2ii.jpg)
(https://cdn.sparkfun.com/assets/learn_tutorials/4/0/4/12942-04.jpg)
https://learn.sparkfun.com/tutorials/bus-pirate-v36a-hookup-guide
HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)
I2C>[0x3a 0x0f [0x3b r]
I2C START BIT
WRITE: 0x3A ACK
WRITE: 0x0F ACK
I2C START BIT
WRITE: 0x3B ACK
READ: 0x41
NACK
I2C STOP BIT
I2C>
-
Muy buenas Picuino:
El problema que tengo consiste en que cada rutina necesita memoria ram para los punteros de ejecucion, el estado run o idle, el contador de tiempo de espera, etc.
No entiendo muy bien esto que dices, la idea que tengo del programa que quieres hacer se me ocurre de la siguiente forma.
Seria crear un array en RAM muy grande, dependeria del numero de rutinas con las que se fueran a grabar provenientes del puertos serie.
array[255]
Pero si por ejemplo a tamaño del comando le damos 7 caracteres ascii que como te dije en anterior post si no se compleratara se deberia completar con caracteres vacios.
Bueno creamos una variable PUNTERO, esta variable va saltando de 7 en 7:
0 a 6 - inculida primera rutina
7 a 13 - incluida 2 rutina
16 a 20 - etc..
cuando vaya a leer la primera posicion de rutina en RAM, leera las posicions 0,1,2,3,4,5,6 y las puede meter en un array por ejemplo
comando[6]
El puntero saltara 0, 7,14,21, etc..
Bueno por otro lado tenemos el lado de la memoria flash o eeprom, buen cuando se lee la flash o se graba en flash existe el puntero ptro o TBLPTR, bueno este puntero se incrementa cada vez que se lee un dato o se escribe.
El caso es que es un unico puntero. Se puede reservar un espacio para el texto de la instruccion igual de 7 caracteres y en este caso el 8 byte se puede meter el codigo hexadecimal de ese comando.
De tal forma en la tablas e guardaria.
0 a 6 texto instrucion 7 codigo hex
8 a 14 texto instrucion 15 codigo hex
16 a 22 texto instrucion 23 codigo hex
Habra que hacer una subrutina que grabe o lea texto de la flash o eeprom con una variable PUNTERO2 que vaya
pegando saltos 0, 8, 16, 24 , etc...
Bueno esta subrutina cuando marque PUNTERO2 una posicion por ejemplo la 0 tendra que menter los datos contenidos en las posicones 0,1,2,3,4,5,6 dentro del array
comando2[7]
Bueno tanto los transistos de busqueda de codigo de instruccion, grabar datos de RAM a flash, como pasar datos de Flash a RAM, los transistos se harian entre los arrays comando[7] y comando2[7].
Los punteros en principio yo solo veo dos PUNTERO Y PUNTERO2 una para memoria RAM y otro para la flash y ambos se modificarian igual de forma incremental uno de 7 en 7 y otro de 8 en 8.
Yo en principio no veria mucho mas , aunque puede que me este equivocando.
Saludos.
-
Muy Buenas JamesTaggart
Interesante el Bus Pirate, sobre todo puede trabajar con tensiones de 3,3 y 5 V.
Bueno para averiguar con que address esta trabajando un dispositivo I2C existe una programita de Arduino que es muy util y te lo averigua.
Pero lo mas interesante de todo seria que este circuito hiciera funciones de sniffer esto es que si estas analizando la comunicacion I2C entre dos dispositivos te grabara y te sacara las tramas entre los 2 dispositivos.
Yo esto lo he intentado con un microcontrolador a nivel de capturar las tramas y luego traducirlo a un protocolo, pero al final me ha vuelto loco y no he conseguido sacar nada coherente, en fin es un proyecto que tengo ahi y que intentare algun dia resolver.
Bueno el proyecto que yo quiero hacer es esto de probar dispositivo, pero tambien muchas cosas mas , crear un trama, atacar distintos dispositivos logicos, etc.. etc..
Saludos.
-
En mi caso, los comandos tienen que ser interactivos y también correr solos, en forma de tareas (task).
En memoria puede haber varias tareas, no solo una, y todas pueden correr de forma independiente (multitarea) incluso mientras el micro responde a órdenes interactivas. También puede haber tareas en marcha y otras paradas.
Las tareas se almacenan en un array de memoria de 250 bytes:
char memprog[250]
Las órdenes se almacenan con códigos, no en forma de texto. Una especie de código máquina o bytecode.
Cada tarea tienen una cabecera de datos con su estado (RUN, STOP, IDLE) su número identificador del 0 al 32, los milisegundos de espera y un puntero a la posición de RUN.
Cada tarea apunta a la siguiente, en forma de lista encadenada, la última tarea tiene un puntero NULL para indicar el final de la lista.
Cuando se ejecuta una tarea, se copia el tiempo del sistema (millis) en la variable de milisegundos de la tarea. Cuando llega una orden WAIT, los milisegundos de la tarea se incrementan y el estado pasa a IDLE. En ese estado lo único que hace la tarea es esperar hasta que el tiempo del sistema valgan lo mismo que los milisegundos almacenados en la tarea y entonces vuelve al estado RUN.
De forma que tengo varios retos de almacenamiento de datos y de ejecución en paralelo.
Un saludo.
-
Buenas Picuino.
Madre mia me supera, como dicen en mi pueblo demasiado pienso para tan poco pollo.....jejeje.
Similar al sistema operativo de un ordenador multitarea, en fin como todo, poco a poco, supongo que tendras que tener un programa supervisor de todo esto y que vaya asignando ejecuciones y prioridades, y jugar con el Timer del microcontrolador.
Hay una cosa que tambien se puede hacer y es en una placa montar varios microcontroladores, sincronizados por un master, atraves de un puerto I2C por ejempo. Hoy al precio que estan los microcontroladores esto no supone un desembolso muy importante.
Saludos.
-
Al final no es tan difícil.
Voy leyendo la lista de tareas.
Si la tarea está en run, leo siguiente instrucción y la envío al intérprete.
Si la tarea esta en idle (en espera por un wait), espero hasta que pase el tiempo.
Al final de la lista, vuelvo a comenzar.
Luego las demás tareas se hacen por interrupciones. Cada cierto tiempo fijo el pwm , leo y escribo la uart o actualizo el contador de tiempos.
Una vez que sabes como hacerlo, es sencillo. El problema es aclararse porque es la primera vez que combino en un programa todas estas ideas distintas.
Un saludo.
-
Muy buenas Picuino.
Este fin de semana estuve en el pueblo, estuve liado y por eso no conteste.
Bueno si dificil no es dificil, pero si muy muy laborioso.
Yo en este momento estoy en proceso de como colocar adecuadamente los datos en los bloques de memoria RAM del Pic y como manejarlos, tengo echo el programa de correrlo en RAM aunque no probado, con lo cual todavia queda mucho trabajo ahi, y luego mas tarde crear un interpretador de ordenes y compilador en el PC para crear un lenguaje mas humano.
Bastante trabajito, aunque supongo que menos que el tuyo que ademas tienes que grabar programa en flash del PIc, interpretar lenguaje de texto en RAM, hacer procesos multitarea, etc...
En fin en menudo lios nos metemos...jejeje.
Saludos.
-
Si. A veces pienso que para qué lo complico tanto, pero cuando por fin lo veo terminado, merece la pena.
Estos dias he estado liado con otras cosas, pero voy a retomarlo ahora.
He decidido ir por pasos. Lo primero es hacer un interprete de códigos. Los codigos los meteré yo a mano en el programa. Luego vendrá la multitarea (esto es sencillo al ser código interpretado y no necesitar velocidad)
Luego el compilador de códigos, que no sé si lo colocaré dentro o fuera del PIC.
Lo que me está dando más problemas hasta ahora es el control PWM de los led, lo que creía que sería más sencillo. Pero es que me gusta complicarlo todo. Si tengo tiempo contaré los detalles en otro post. He conseguido controlar 6 led con un solo módulo PWM y con una resolución de 20000 pasos.
Respecto a lo tuyo, los bloques de Ram dan mucho trabajo. Es mejor olvidarse de ellos. Los nuevos PIC tienen un puntero que trata toda la memoria de forma lineal. Mira el datasheet a ver si te sirve.
-
Muy Buena Picuino
Si. A veces pienso que para qué lo complico tanto, pero cuando por fin lo veo terminado, merece la pena.
Bueno la verdad es que en mi caso es por hobby disfrutar el momento en que lo vas haciendo, y luego como dices la satisfacion de que te ha quedado que una cosa que funciona y que te puede ser utlil para otras muchas cosas.
De momento voy haciendo lo que puedo por que tambien trabajando queda mucho tiempo para algo, y ademas absorbe mucha energia y despues de una jornada laboral no se suele tener la cabeza con mucha energia.
En fin si lo mas seguro sera cambiar de PIC, mira que soy tonto que ya tenia comprados los PICs que funcionaban con la posibilidad de correr programas en RAM externa y al final se me olvido que los tenia, en fin....poco a poco.
Yo me lo voy a tomar un poco mas tranquilo y ademas tengo otro proyecto en mente que me resulta mas rentable personalmente y quiero llevar adelante.
Saludos.
-
Cuando tenga el mío hecho lo subiré, por si le sirve a alguien. La mitad de lo que hago también es hobby porque realmente no necesito algo tan complicado.
De todas formas ahora estoy terminando otro proyecto para poner en marcha una web estática generada con Python y quiero dejarlo enfilado antes de seguir con este.
Saludos.
-
Muy buenas Picuino:
Hay tambien una idea muy interesante en tu proyecto con respecto a meter el "compilador de texto - codigo" dentro del Pic, y que he estado pensando en ello.
Esto es por ejemplo hay multitud de circuitos que responden a comandos AT , modulos GSM, modulos GPS, modulos de lectura BUS CAN como el elm327, etc..
Bueno esto es bastante interesante a lo mejor implemetarlo en cualquier proyecto, con lo cual podria ser podria implementar la idea que tu tenias de meter el compilador de texto dentro del Pic, de esta forma no tendria que haber ningun programa previo dentro del PC, para hacer que mediante envio de comandos por el puerto Serie, hiciese que funcionara el microcontrolador correspondiente.
Saludos.
-
Exacto. Eso es lo que quiero hacer. Una especie de compilador de comandos Hayes (comandos AT).
Te da mucha flexibilidad para manejar el circuito y para el usuario final es muy sencillo manejarlo, sin necesidad de programas especiales ni nada, solo un terminal serie.
Pero mis comandos quiero que permitan definir secuencias que se ejecuten en bucle. Es algo más que un simple comando de configuración.
Un saludo.
-
El programa no es tan difícil ni lleva demasiado tiempo, pero el otro proyecto de montar la web me está llevando más de lo que pensaba. Cualquier proyecto que se quiera dejar bien perfilado termina teniendo un montón de detalles que trabajar.