Coincido con eso, es un poco un desperdicio de hard pero al final lo que importa es el costo y espacio como decis, y cada uno de esos PIC se puede programar en BASIC que es facil de dominar y hace bien una tarea a la vez. El tema es que definitivamente eso elimina a los Arduino del panorama, porque saldria caro y seria poco conveniente andar poniendo varias placas, aunque teniendo en cuenta la aplicacion, me parece que espacio fisico sobra.
Manejar interrupciones con Arduino es muy muy simple, ya tiene las funciones para hacerlo. Es solo declarar que se van a utilizar interrupciones y la subrutina que se hace cargo. Por eso sostengo que es mas sencillo utilizar un arduino para esta aplicación por parte de principiante, que solo se tiene que enfrentar con la programación sin preocuparse en el harware.
En realidad no entiendo como puede ser mas sencillo utilizar varios pics. Como hacen la integración ? por bus I2C?
Para este caso particular no es mas facil ni con varios PIC ni con varios Arduino, pero es simplemente porque si bien la programacion se simplifica mucho, lo que se complica despues es coordinar la informacion para enviarla a la PC, ya que tendria que haber un PIC o Arduino dedicado a hablar con la PC y requerir la informacion a cada microcontrolador.
Pero en general a veces es mas practico por lo que vale dejar un PIC o ATMega dedicado a funciones muy especificas para simplificar el diseño y la programacion, en particular porque ningun programa suele andar a la primera, y es mas facil calibrar y depurar cada algoritmo por separado.
Que se pueda declarar de forma mas simple las interrupciones no significa que sea mas facil hacer un programa con interrupciones.
Igual a lo que yo me referia era a que no tiene sentido querer resolver todo en software si uno no se quiere interiorizar tanto en programacion, pero si lo que se quiere hacer es complejo porque hay que coordinar varias entradas distintas va a ser complejo lo hagas como lo hagas, pero es mas facil cortarlo y probarlo de a partes que entiendas lo que hacen. Si todas las distitnas partes estan en un solo programa tenes que ir probando parte por parte, ir haciendo programas de prueba que solo hacen una cosa y cuando ya verificaste esa parte le agregas otra seccion, pero teniendo cuidado de no romper lo anterior. Yo lo haria asi, pero entiendo que el que no esta tan ducho en el desarrollo de programas puede enloquecer con esto.
Y para unir todas las entradas te fijas algun proyecto que tenga varias entradas seriales por ejemplo, o meter 10 cables USB serial en una PC, soluciones asi que no son practicas para produccion en masa pero que te ahorran tiempo de programacion.
Saludos
MARCOS
Marcos, no quiero generar polémica, pero la idea que de separar diversas señales y colocar una interfaces para cada una es mucho mas compleja de realizar a cabo, solo estas trasladando el problema al lado de la PC y ni hablar de la fiabilidad del sistema. No es practico siquiera a nivel principiante. Lo poco practico viene en enfrentar a un principiante, con escaso conocimiento de electrónica, a un PIC, te imaginas enfrentándose a 10.
Pregunta:
Por qué no contratan a mi primo (Hugo Duca) como preparador. Tiene el record en Mar de Ajó con un fiat de la categoría "Amigos": 218 km/h !!!
Él tiene el dinamómetro en el oído...
Yo les presto la bolita para las pruebas entonces jaja.
Lindo proyecto, complejo eso si, por qrue realmente desde cierto punto de vista no sabes si "funciona bien" o no, digo, simular todo me parece medio complejo no ?
10 años atrás
lun jul 21 2014, 22:07
Para un principiante puede tener sentido dividir las cosas en partes, por supuesto como dice Marcos, el proyecto en si es complejo y eso no se puede evitar se haga lo que se haga. Hay que asumir que la placa que uno diseñe no necesariamente va a ser la final, cuando se trata de hacer mediciones es mejor hacer cada una por separado, se haga todo en placas distintas, o se implemente todo en una sola pero activando cada parte del codigo por separado. Asi uno sabe que cada medicion se hace correctamente y que no estorba el resto del codigo, y una vez que se logra medir todos los sensores, queda el desafio de integrar todo en una sola placa (si se hicieron varias) o habilitar todas las rutinas para que trabajen juntas (si se hizo todo con una sola placa).
Si uno pretende hacer todo de una sola vez ya en la placa final, no queda otra que diseñar todo teoricamente antes de ponerse a programar, la velocidad a la que se comunica con la PC, la secuencia que se va a usar para leer sensores, el formato de los datos que se envian. Asi se diseñaria una rutina de interrupcion unica que se llamaria periodicamente, digamos 500 veces por segundo o algo asi, se llevaria un contador que se incrementaria en cada interrupcion, y ese contador le daria el turno a las distintas funciones a ejecutar. Digamos que tenemos 5 sensores en los conversores A/D, en el turno 0 activamos la captura del AD0, leemos la del AD4 y salimos de la interrupcion, en el turno 1 leemos la captura del AD0 (que para entonces ya estara lista), disparamos la del AD1 y salimos de la interrupcion, y asi, cuando llegamos al turno 4, leemos la captura del AD3 y disparamos la del AD4 (que se va a leer en el turno 0 despues).
Es una idea general, pero mas o menos asi se trabaja con interrupciones de una manera mas ordenada y simple, seria similar a como en Visual Basic se disparan eventos cada vez que se activa un Timer, se compara el valor del Timer y se hace la funcion que corresponda a ese tiempo. Hay formas mas complejas de trabajar con interrupciones pero no creo que sea necesario en este caso particular.
Cada vez que se llama a la interrupcion, y antes de salir, se chequearia si el PIC recibio algun caracter del puerto serie, y se acumularia en un buffer, si hay mas de un caracter en el buffer, se llamaria a una rutina que reconozca si la PC envio algun comando, y si se reconoce uno, se ejecuta lo que haga falta.
Este proyecto no necesita tener una comunicacion tan compleja porque como dije es mas practico que la PC pida los datos y el microcontrolador envie todos juntos, asi que la PC podria enviar solo un byte de un valor determinado y cuando recibe eso el microcontrolador envia todo. Pero supongamos que es mas complejo y hay varios comandos, por ejemplo un comando Sx, que pide la medicion de un sensor, y x representa el numero de sensor, ahi el micro recibe la S y la guarda en el buffer, como tiene mas de un caracter en el buffer, chequea si hay un comando valido, como falta el numero no hay nada valido, entonces sale de la interrupcion. En la proxima puede recibir el numero, lo agrega al buffer y vuelve a chequear, esta vez sera un comando valido, lo procesa para saber que medicion tiene que enviar, y luego envia los dos bytes de la medicion por RS232 antes de salir de la interrupcion.
Si se planifica bien no es tan complicado, es mas bien complejo por la cantidad de cosas que hay que coordinar, pero cada paso es bastante simple, lo complejo esta en la planificacion, si funciona bien en papel deberia ser bastante directa la programacion despues.
Pastbytes no difiero en ningún sentido en la parte técnica, difiero en las herramientas a usar. Solo sostengo que a un principiante tenes que darle herramientas de principiantes. Pedirle que resuelva con pics un problema complejo o diez problemas simples, es una receta al fracaso. Las placas de desarrollo tipo Arduino, Pcduino, Raspaberry PI, están para eso . El problema planteado no tiene ninguna complejidad con estas placas, es precisamente el utilizar PICs lo que lo hace inaccesible a un principiante. Basta poner en google Arduino + el sensor que desees y conseguís el código necesario depurado. Es mas, si alguien en el trabajo me trae un problema similar, que se puede resolver fácilmente con PICs...... le pongo un PLC. Es menos dolor de cabeza para mi y el cliente y puedo calcular exactamente el tiempo que me llevaría hacerlo.
No recomiendo un PLC a un principiante por el costo y que el Ladder puede resultar exotérico al principio, pero seria sin duda mas simple de enfrentar que un desarrollo con PICs.
Saludos