21 respuestas en este tema

[alecuba16]

Buenas a todos,

Estoy haciendo un microcontrolador para el turbo de geometria variable y ahora estoy metido con el tema de configuración y menús, asi como mensajes por pantalla.

Mas o menos esto es lo que pretendo conseguir y tengo el 50% hecho, pero antes de terminar y luego tener que cambiar desde la base, me ayudaria que me hicierais sugerencias aun sea a nivel de "usuario" para asi sea lo mejor y mas facilmente entendible.

El microcontrolador tiene como entradas:
Sensor de presión (MAP) en mBars.
Sensor de pedal en %.
Sensor de Tºde la turbina del turbo en ºC.
Cable para saber si está en posición del motor encendido, a presión de aceite o algo asi (para no dejar entrar en el menu de instalación mientras motor encendido).
Botones menu,modo,mas y menos.

Tiene como salidas un control a la geometria y un display

El display que dispongo ahora mismo es de 16caracteres x 2 lineas.

Es decir caben palabras de 16 letras y hay disponibles dos lineas, para que os hagais la idea es esto lo que cabe:

ABCDEFGHIJKLMNOP
1234567890ABCDEF

Bien pues cuando el sistema está funcionando se dispone de un boton de modo, el cual conmuta entre el modo de ir saliendo los parametros en orden y cambian cada X's tiempo que es configurable desdel menú, o se queda en uno fijo.

Ejemplo cuando va rotando pueden salir mensajes como:

Presion (mBar):
0.7

Acelerador (%):
20

Temp. Turbo©:
780

Geometria (%):
68

Entonces se van rotando u se queda fijo en alguno de ellos, el tiempo minimo de actualizacion tanto en rotaje de mensajes como en actualizar uno fijado es de 0.5segundos


Si se presiona una vez el botón de menú, sale el menu y si se vuelve a presionar esté donde esté sale del menu sin guardar cambios al principal, para editar una vez en un parametro se presiona modo o para entrar en un submenu , se entra con el boton modo, entonces cuando el parametro se esté editando parpadeara y cuando se guarde presionando otra vez modo se quedará fijo.

Entonces en el menu habia pensado poner:
Config. Valores->va a otro submenu (en cualquier momento se puede entrar)
Instalacion ->va a otro submenu (solo se puede entrar con el motor apagado)
Config. Visual->va a otro submenu (en cualquier momento se puede entrar).


Submenu config.Valores:
-Presión objetivo(mbar):0 a 5000mbar.
-Modo pedal:Suave, medio , Intenso (suave -> turbo responde poco al pedal tienes que dar mas de medio pedal para que de al tope, medio...,intenso -> poco pedal turbo responde mas, con menos de medio pedal la geometria se va al tope para dar todo cuanto se pueda, turbo se calienta mas en crucero), aqui utilizaré tres funciones para aproximar , una exponencial en suave, medio es lineal, y una logaritmica para la de intenso.
-Temp. crucero turbo: la temperatura objetivo que se pretende cuando se va a crucero (pedal no varia en mas de un x's porciento en un determinado tiempo, esta temperatura seria el objetivo mas que obtener la presión objetivo)

Submenu de instalacion
Config. MAP->otro submenu
Config. TPS->otro submenu
Config. TempTurbo->otro submenu
Config. Geometria->otro submenu

Submenu MAP
Rango : 0-5v o 0-12v
Presión máxima: 0->5000mbar (a partir de la presión máxima puedo obtener el numero de saltos con el voltaje)
Sensibilidad: en milivolts (aun tengo que averiguar mas).

Submenu TPS
Rango : 0-5v o 0-12v
Calibracion -> te lleva a un procedimiento el cual te obliga a poner el pedal sin pisar y luego pisandolo para medir los milivolts y saber el 0% y el 100% relativo al pedal.
Sensibilidad: en milivolts (se calcula en el proceso de calibracion).

Submenu TempTurbo
Rango: 0-5v o 0-12v
Temperatura máxima(5/12v):
Temperatura min. (0v):
Temperatura MaxTurbo©:

Submenu Geometria
Tipo: PWM, Voltaje..(aqui tengo que buscar mas opciones), por el momento PWM
Min:(en % si es PWM , en volts si es voltaje)
Max:(en % si es PWM , en volts si es voltaje)
Tasa PWM:(si se configura PWM sale este, en hz):
Voltaje PWM(si se configura PWM sale este, en volts):
-----------------------------------------------------------------------------------------------

Submenu Config. Visual:
Tiempo Actualizacion (seg):0,5..2seg.
Tiempo Retorno Auto (seg): 5..20seg


Aún quedan muchas cosas por detallar pero de entrada esto es bastante cosa.


Otra idea es hacer un teclado númerico para que sea mas facil la interacción pero queda muy aparatoso y para integrar en el cuadro del coche o algun lado quedará muy grande, mi idea era intentar.

Otra variacion es cambiar el display de 2 lineas por uno de 4 o 6 y mostrar todos los parametros a la vez, pero ya no se podría colocar en lugares pequeños.

Gracias a todos

Editado por alecuba16, 08 julio 2012 - 12:53:12.

[alecuba16]

Bueno tengo terminado el controlador con los requerimientos que tenia al principio actualmente me queda pasarlo a una placa, pero en circuiteria y emulacion va perfecto, le he hecho varios ajustes y menus y que se puedan guardar y tal.

El algoritmo de calculo se construyo en una tabla que partio de dos funciones que relacionaban el pedal, la presion con la geometria que es el resultado, etc.


aunque mañana entrego el documento del proyecto de final de carrera , lo seguire mejorando y desarollando mas cosas.

Aunque no se le pueda pedir peras al olmo actualmente esta implementado en un pic18f corriendo a 16mhz (suficiente) el codigo lo he optimizado bastante y solo funciona con interrupciones, no hay bucles ni esperas (sleeps).

Si podeis darme consejos y sugerencias aun estoy a tiempo. hasta el día 27 de este mes.

Editado por alecuba16, 18 septiembre 2012 - 23:22:54.

[MerLiNz]

Acabo de leer esto ahora , por este foro la gente no suele leer las cosas de electronica jaja.

Yo lo habria hecho con una GLCD en vez de con un display lcd, asi le puedes poner un menu mas amplio, lo unico es que como me dijiste estabas en ASM y es un rollo hacerte una libreria en asm para glcd
Este es el menu que elabore yo:

Aparte con letras grandes para que se vean bien las presiones, rpm y eso...

Sobre el control del servo de geometria variable no tengo mucha idea, yo el de presion por wastegate lo quiero hacer de la siguiente forma:
Si por ejemplo lo pones a 1bar de 4000-5000rpm (configurable los rangos) pues segun la deteccion ADC actua automaticamente regulando la presion para mantenerla asi, todo esto con ciertos limites (imagina que un manguito esta picado, se pondria el duty a 100% para mantener 1bar). Seria asi: lee adc, calcula duty, modifica el duty del pwm y asi sucesivamente. Por ejemplo, cuando el turbo este cargando se mantendria la waste cerrada hasta que esta llegase a determinada presion (por ejemplo 0.9bar) y una vez llega a esa presion activa el duty al 70% (normalmente es lo que las solenoides de control admiten como maximo), una vez vaya llegando a la presion destinada (1bar) entonces se va reduciendo el duty para mantenerla, si la presion disminuye pues se aumentaria el duty de nuevo (todo basado en calculos a mucha frecuencia).

El pic que estoy usando es el dspic33ep256mu806 a 40mips vamos, de sobra para que la respuesta sea veloz y evitar los picos de presion.

Una cosa que modificaria de tu proyecto es la posicion de los botones, los pondria debajo del lcd, ya que encima cuando estes toketeando pondras la mano delante y no se vera bien.

Editado por MerLiNz, 19 septiembre 2012 - 01:32:36.

[Redbullet]

Muy interesante, qué pena no entender nada, pero me hago una idea de lo preparados que estamos en el foro....

[alecuba16]

Lo sé pero hay peña como tu que sabe y sabia que me ibas a echar un cabo

Vaya no sabia del GLGD !!! me has convencido, cuantos bits necesito (pines)??

Además me falta añadir (que no para el proyecto este para entregar) sino el que seguiré , que lea las rpm's.

Que algoritmo utilizas para medirlo lo mas generico posible y de donde sacaste la info???

Es que he visto conversones universales pero no he visto el algoritmo que siguen, si numero de pulso por segundo , si Variable en voltios, si PWM....

Además estoy intentando investigar el control de la geometria hella que tengo que tiene como una retroalimentación en can para decir el ángulo, sería investigar como hacerme una libreria para leer can y implementarlo en el actual, para mejorar aun mas el algoritmo de la geometria en el tema de los angulos donde está.


Sobre ensambler, al final me he pasado al CCS con el hitech c18. migré el codigo en ensamblador. Me estaba siendo tedioso estoy acostumbrado a trabajar a alto nivel y objetos.

Quizas migre el código a un compilador que compila C++ (http://www.phaedsys....iarewpic18.html) para pic, tiene muy buena pinta y para mi programar en objetos lo llevo muy bien, puedo hacer mi diagrama uml y optimizar los objetos.

Me lo miraré para luego de la presentacion del proyecto cuando lo siga desarrollando porque estaba hasta los coj* de trabajar solo con 16 columnas y 2 lineas!!

Tiene muy buena pinta el display ese tuyo, que estaba midiendo ahi?.

Tienes razón ya me he topado que en el código voy "sobrado" pero en el display me he quedado corto, con solo 4MIPS puedo ejecutar todo sin llevar la cpu del mcu a mas del 70% . el adc tengo un periodo de 55us en obtener las 3 señales. Mi onda PWM va desde 2800hz a 140hz.

Luego las interrupciones son de menos de de 18 lineas, asume que en cada una hay 2 instrucciones las cuales tengan algunas otras 20 lineas = 18*2*20=720instrucciones redondea 1000., el micro en teoria hace 4000000 por seg -> 250us en ejecutar una la interrución el algoritmo gordo tiene unas cuantas pero no mas de 40, asi que asume 500us (estoy vago en calcularlo jeje), en total puede tener 750us a 1ms en ejecutar una vuelta entera al programa a 4mips.

En 1ms tampoco creo que vaya a haber mucho pico, ¿cierto? el duty cycle de la geometría se precalcula y luego se guarda en un valor en memoria que utiliza el generado de pwm, por lo que el retraso minimo que tendra para cambiarla es el periodo que usa el controlador que es de 140hz -> 7ms, así que el sistema mio puede dar como 5 vueltas al programa entero antes de que se pueda cambiar la geometria a un valor nuevo, por lo que tampoco me interesa que sea muy rapido, por eso lo uso a 4mips, porque a 16mips me es imposible hacer un periodo de 140hz de pwm sin perder presición de bastante, hablamos de 138hz o 144hz, mientras que ahora tengo 140,01hz y eso que lo estoy haciendo por software.

Le he dado una resolución de aprox 1% de duty, aunque por ahora trabajo con una tabla estática para calcular presion y temperatura del turbo vs geometria.

La estructura del main general que he seguido es:
-Rutina de interrupción alto nivel: Señal PWM, Modulo ADC
PWM: //Tiene que cumplir un duty total de 140hz
			 Señal pwm se genera mediante programar un timer que se pone a TIEMPO A 1;//Tiempo completo
			 Cuando salta el timer de duty total - tiempo a 1 se coloca la pata a cero DUTYTOTAL - TIEMPO A 1; //Resto del tiempo
ADC://Cada vez que hay una interrupcion de una conversion completa
		 Si margen entre valor actual y valor antiguo > tiempo_de margen //Se guarda el valor anterior y el actual con una distancia de 10ms para calculos del algoritmo., además calcular geometria y actualizar valor del % del duty cicle que usará el generador de pwm.
					 valor antiguo=actual
		 fin si
		 valor actual=captacion modulo adc
		
-Rutina de interrupcion bajo nivel: Timer de actualizacion del lcd y Pulsadores (Mediante interrupciones del puerto <img src='http://clubhondaspirit.com/foro/public/style_emoticons/<#EMO_DIR#>/cool.png' class='bbc_emoticon' alt='B)' />.
	 Si Timer LCD:Si ha hecho X's overflows //han pasado 4 segundos con 31 overflows por ejemplo
		 entonces flag actualiza lcd a cierto
si pulsado boton
		 mirar cual se ha pulsado
			 si modo menu hacer unas cosas(ajustes del menu , guardar configuracion eeprom etc..)
		 si modo normal hacer otras (mostrar sensor anterior o siguiente, ir a menu, dejar en el sensor actual, rotacion de sensores automatica)
while(1)
{
if(guardar configuracion)
{write al eeprom (configuracion);
guarda config = falso
}
if(actualiza LCD){
			 if(modomenu){
				 //cosas a mostrar en modo configuracion
				 }else{
				 //Muestra datos actuales senores y se van rotando
			 }
actualiza_LCD=falso;
}
Actualiza_LCD lo controla un flag del timer de refresco del lcd

Como puedes ver no he usado un solo sleep (es tiempo de cpu inutil) ni apenas bucles, porque también es una espera inutil, todo con interrupciones.

El unico bucle es el general.

Lo que me falta ahora es como ver como meter el micro en sleep y cuando haya una interrupcion despierte porque esto quita ruido en la conversion ADC, y además reduce el consumo de unos mA o uA a nA -

Esto me interesa explotarlo porque tengo que hacer un timer para aviones de vuelo libre y tienen que ir con una pilita de unos mA y comandar un microservo.

Redbullet.

Estamos en eso aprendiendo

Editado por alecuba16, 19 septiembre 2012 - 14:59:20.

[MerLiNz]

El GLCD utiliza 8bits en paralelo + algunos otros pines para enable, intensidad de la pantalla, iluminacion... Aun asi no te compliques para tu proyecto de fin de carrera porque puede que no te de tiempo a implementar todo.

Yo de compilador usaba el C18 con el MPLABX (el nuevo que saco microchip, bastante bueno, aunque algo lento. Hace poco que salio del beta y aun le quedan por mejorar), ahora para el dspic utilizo el C30, aunque microchip saco el XC8 (para pics 8bits como el tuyo) XC16, XC32... Pero vamos con una copia de los anteriores C18, C30, C32...
Yo no te recomiendo pasarte a C++, aunque trabajes muy comodo con los objetos y tal es muy pesado para el pic, piensa que tienen poca ROM, RAM y velocidad de proceso... Con el C normal sobra.

Las RPM en mi nissan son unicamente un PWM de 0-9V, no recuerdo a que frecuencia iba pero recuerdo que era baja frecuencia. En honda supongo que sera parecido. Para su lectura utilizo el input caputure del dspic (un chollo facil y sencillo, con lectura por hardware).

El CAN yo he hecho varios proyectos (solo para pruebas) de comunicaciones y eso y todo bien, también lo quiero implementar en mi controladora, digamos que tenemos 2 unidades (glcd y controlador) estos 2 se comunican por CAN, el controlador le envia los datos (rpm, presion, velocidad, marcha....) a la GLCD y esta lo interpreta graficamente, utilizo la comunicacion CAN porque el coche tiene muchas fuentes de ruido y es el que mejor se adapta, ademas si en un futuro quiero conectarle otro controlador para otra cosa seria cuestion de unirlos por CAN y ya esta , existen pics de 8bits (utilizados para cosas simples) con CAN, como el 18f46k80 con CAN integrado.

Sobre en 1ms si no va a haber pico pues no creo, yo creo que la mayoria de controladoras funcionan con una respuesta mas lenta, ademas si te fijas en el datasheet de los sensores de presion veras que estos también tienen un tiempo determinado de lag que creo que andaba por los milisegundos, es decir, aunque la presion subiese de 0,9b a 1bar en 1ms (cosa dificil) el sensor hasta 'x'ms despues no marcaria como que tiene 1bar de presion. No se si me he explicado bien.

Otra cosa interesante para tu proyecto seria deteccion de errores (con un led rojo para alertar al "conductor), por ejemplo sobrepresiones incontroladas (si sube de X presion y el controlador no es capaz de controlarlo (imaginate que se queda la wastegate atrancada, o el servo se queda bloqueado por un fallo) entonces se enciende el led y aparte baja el PWM al minimo o bien desconecta por seguridad. también deteccion de cortocircuito/circuito abierto en la solenoide/servo de la waste mediante una resistencia shunt (le metes el ADC a la resistencia y calculas la intensidad que circula, si varia de los parametros predefinidos luz roja!
Y también algo que detectase algun fallo en el sensor de presion, esto ya habria que mirarlo bien para ver errores que puede dar, por ejemplo que el conector este desenchufado, o que se haya cortocircuitado y de los 5V constantes..

[alecuba16]

El GLCD utiliza 8bits en paralelo + algunos otros pines para enable, intensidad de la pantalla, iluminacion... Aun asi no te compliques para tu proyecto de fin de carrera porque puede que no te de tiempo a implementar todo.

Bueno tampoco creo que sea tanto trabajo,no?, mas me costo un bug que le encontre al pic con el tema del LATCH del puerto B desgraciadamente tengo que leer el puerto dos veces para que se baje.

Tarde como 2 dias!!!!!!!!!!!!!! no queria hacer ninguna chapuzilla para evitarlo y queria que funcionase pero buscando por el forum de microchip , era un bug del pic.

No el proyecto ya entregue lo que hay hasta ahora, esto será un branch (no se si has trabajado alguna vez con control de versiones y subversion) pues eso un fork con display glcd 8 bits aun tengo patas de sobra , es mas quizas lo minimize a un pic16f886 o este le añada todo el tema de leer rpm's y convertirlas segun coche y añadir para leer un contador de rpm's por si el turbo tiene también lector de rpm's, el tema del can, pero para hacer eso lo haria funcionar a 16mips.

Yo de compilador usaba el C18 con el MPLABX (el nuevo que saco microchip, bastante bueno, aunque algo lento. Hace poco que salio del beta y aun le quedan por mejorar), ahora para el dspic utilizo el C30, aunque microchip saco el XC8 (para pics 8bits como el tuyo) XC16, XC32... Pero vamos con una copia de los anteriores C18, C30, C32..

El hitech c18 es el mas optimizado que hay por ahora y el que mas optimiza eso vi antes de usarlo por eso no use el c18 a secas.

Yo no te recomiendo pasarte a C++, aunque trabajes muy comodo con los objetos y tal es muy pesado para el pic, piensa que tienen poca ROM, RAM y velocidad de proceso... Con el C normal sobra.

IAR.Embedded.Workbench.for.Microchip.PIC.v2.21A.FULL-YgH.iso, aunque sea solo para pic16, hechale un vistazo generas todo primero desde un uml de cambio de estados y entidades con sus relaciones, te genera el esquema y luego tu has de implementarlo, es muy feo y seco pero promete.

Incluye simulador de cambio de estados y tal, para que veas que todo funciona bien y no lleva a lados que no quieras, que esto para un soft de lo que sea con muchas funciones va que te cagas.

No se si has usado alguna vez bouml, de unos diagramas pasas a codigo en pocos pasos y no hay nada mas optimizado que hacerlo de esta manera es lo que caracteriza la ingenieria del software de una simple implementacion como he hecho yo en este caso.

Las RPM en mi nissan son unicamente un PWM de 0-9V, no recuerdo a que frecuencia iba pero recuerdo que era baja frecuencia. En honda supongo que sera parecido. Para su lectura utilizo el input caputure del dspic (un chollo facil y sencillo, con lectura por hardware).

Si en el pic es lo mismo con el ADC

Pero si es PWM entonces tiene un voltaje fijo y varia el periodo no?, porque sino no es pwm es variacion de voltaje.

A mi me interesa de base a un futuro y estandarizarlo mas poder usa varios tipos de sensores,abarcar el maximo mercado posible, ya que lo hago hacerlo aprobechando bien el hard.

El CAN yo he hecho varios proyectos (solo para pruebas) de comunicaciones y eso y todo bien, también lo quiero implementar en mi controladora, digamos que tenemos 2 unidades (glcd y controlador) estos 2 se comunican por CAN, el controlador le envia los datos (rpm, presion, velocidad, marcha....) a la GLCD y esta lo interpreta graficamente, utilizo la comunicacion CAN porque el coche tiene muchas fuentes de ruido y es el que mejor se adapta, ademas si en un futuro quiero conectarle otro controlador para otra cosa seria cuestion de unirlos por CAN y ya esta , existen pics de 8bits (utilizados para cosas simples) con CAN, como el 18f46k80 con CAN integrado.

Nah no hace falta, yo lo leo por soft como he hecho con la onda pwm, que como la frecuencia que usa este servo es muy baja el modulo pwm no daba y tenia que ponerlo a 1mips... , asi que lo hice por soft y ya esta, el can lo mismo me hago una libreria toda maja y tirando.
En vez de por hard.

Sobre en 1ms si no va a haber pico pues no creo, yo creo que la mayoria de controladoras funcionan con una respuesta mas lenta, ademas si te fijas en el datasheet de los sensores de presion veras que estos también tienen un tiempo determinado de lag que creo que andaba por los milisegundos, es decir, aunque la presion subiese de 0,9b a 1bar en 1ms (cosa dificil) el sensor hasta 'x'ms despues no marcaria como que tiene 1bar de presion. No se si me he explicado bien.

Si te he entendido , miraré documentacion de sensores a ver que tasa de actualizacion tienen, yo tengo para empezar un GM de 2.5 asi que tengo hasta 1.5bar + suficiente para el turbo que tengo de pathfinder que tengo por aqui.

Otra cosa interesante para tu proyecto seria deteccion de errores (con un led rojo para alertar al "conductor), por ejemplo sobrepresiones incontroladas (si sube de X presion y el controlador no es capaz de controlarlo (imaginate que se queda la wastegate atrancada, o el servo se queda bloqueado por un fallo) entonces se enciende el led y aparte baja el PWM al minimo o bien desconecta por seguridad. también deteccion de cortocircuito/circuito abierto en la solenoide/servo de la waste mediante una resistencia shunt (le metes el ADC a la resistencia y calculas la intensidad que circula, si varia de los parametros predefinidos luz roja!

Ya lo tengo implementado, una vez se supera la presion o temperatura maxima del tubo la geometria pasa a 0 y aparce un mensaje y un altavocillo con un condensador para hacerlo vibrar a una frecuencia (porque me queda 1 timer de los 3 que tiene el pic) y lo quiero reservar para cosas mas serias.

Y también algo que detectase algun fallo en el sensor de presion, esto ya habria que mirarlo bien para ver errores que puede dar, por ejemplo que el conector este desenchufado, o que se haya cortocircuitado y de los 5V constantes..

Eso también lo tengo implementado, si mi adc lee de 0 a 1023 (valor en bytes), el sensor segun algunos datasheets nunca dan 0v ni 5v, tengo una resolucion de 0.004v, asi que le he puesto cuando el voltaje es menor a 0.05v y mayor a 4.99v alarma.

Solo lo tengo al comprobarlo al inicializar eso si, quizas deba ponerlo también mientras esta funcionando normal.

Como te dije anteriormente , lo malo que ya lo tienes, pero yo me pensaria muchisimo empezar a crear el programa una vez ya tienes idea en uml, con sus casos de uso y diagramas y tal, luego pasar por cualquier herramienta de modelacion desde uml, te genera tus archivos source con sus funciones por rellenar y parametros, luego es solo meter el codigo.

Yo pensaba como tu cuando empece a hacer la asignatura donde me enseñaron esto, ingenieria del software, que asco cuanta documentacion y dibujitos, pero cuando vi lo potente que es hacerlo asi las herramientas y que bien quedo estructurado el codigo con sus relaciones y lo facil que era de editar luego y añadir funciones, y encima el tema de objetos.

Que diseñes por objetos no significa que el codigo crezca, es una forma de ordenar el código al programar que luego al compilador puede ser que salga un codigo mas refinado y pequeño que el micro tenga que "paginar" menos po lo tanto menos retardo moviendo instrucciones y en uso de memoria, porque el hecho de la gracia de los objetos es esto, en cambio el metodo tradicional lo ocupas "por si acaso" , mientras que por objetos el micro tiene las instrucciones para crear el objeto cuando lo necesita lo crea, solo el objeto necesario no todo el "por si acaso".

Gracias por los consejos.

Editado por alecuba16, 19 septiembre 2012 - 22:22:11.

[MerLiNz]

El GLCD trabaja por pixels 128x64 (es el glcd mas tipico), yo hice una libreria la cual utiliza la ram del pic para la "creacion" del dibujo/letras o lo que sea, entonces cada X tiempo actualiza el GLCD, es el metodo mas rapido, ya que el metodo normal tienes que leer el dato desde la glcd, modificarlo y volverlo a enviar. En el youtube que puse puedes ver que al cambiar de pagina parpadea un poco, sin embargo despues de la modificacion de utilizacion de ram carga bastante mas rapido y eso que al usar una protoboard no se puede poner a la frecuencia maxima (ruidos), pero ni falta le hace .

El hitech es también de microchip, vale para pics 18 y menores, luego esta el C18 que solo vale para pic18. Las optimizaciones seran similares, cierto es que en modo "free" te genera muchisimo codigo basura, sin embargo hay "cracks" para no tener problema de esto

Las RPM ya te digo, es PWM de 0-9V (en vez de 0-5V de toda la vida) lo que varia es el periodo, segun eso se calcula las RPM, por ejemplo creo que 60Hz eran 1000RPM o algo asi, ahora no me acuerdo bien pero algo asi era.

El caso es que para la gestion de objetos (creacion, destruccion) se necesita una gestion, los pics de por si no lo tienen (por lo menos los normales) esa gestion seguramente ocupara rom y ram, y eso conlleva a la relentizacion del codigo, en realidad para un pic lo mejor es ASM, es la mejor optimizacion, sin embargo te tiras 3h para hacer una simple funcion por lo cual es muy lento. Luego viene el C a secas que es lo mas cercano a ASM.
Y con el MPLABX (el mplab normal también se podia) puedes ver la traduccion del codigo C en ASM en una ventana, con el CCS supongo que también se podra, por ejemplo:


while(NVMCONbits.WR);
00092E E24729 CP0.B 0x729
000930 35FFFE BRA LT, 0x92E
68: NVMADR+=0x0100;
000932 201000 MOV #0x100, W0
000934 B4272A ADD NVMADR
000936 B00808 ADD #0x80, W8
69: }

Lo que te refieres a la creacion "por si acaso" también lo hace los compiladores de microchip, si tu pones un codigo que no se usa, automaticamente al compilarlo no te lo crea, o si por ejemplo pones un bucle que nunca se cumplira (por ejemplo while(0) i=i+1; (en este caso ignora completamente ese codigo y ni lo pone).
Luego estan otros codigos como los inline, estos lo que hacen es generar un codigo cada vez que se llama la funcion, asi se ahorra el call y return ademas de las variables en caso de que haya algunas variables, el problema es que esto utiliza mucha rom, si el codigo tiene 5 lineas, y llamas 20 veces distinta a la funcion se genera 5x20 veces.
Resumiendo, hay muchas formas de optimizar, lo unico es que hay que leerse bien el manual ya que hay muchos tipo de variables, datos, funciones...

[alecuba16]

El GLCD trabaja por pixels 128x64 (es el glcd mas tipico), yo hice una libreria la cual utiliza la ram del pic para la "creacion" del dibujo/letras o lo que sea, entonces cada X tiempo actualiza el GLCD, es el metodo mas rapido, ya que el metodo normal tienes que leer el dato desde la glcd, modificarlo y volverlo a enviar. En el youtube que puse puedes ver que al cambiar de pagina parpadea un poco, sin embargo despues de la modificacion de utilizacion de ram carga bastante mas rapido y eso que al usar una protoboard no se puede poner a la frecuencia maxima (ruidos), pero ni falta le hace .

Vaya, desde luego si lo implemento no lo haria asi me quedaria sin memoria en un 2x3 o consumiria demasiado recursos ya pensaría algun tipo de algoritmo para no tener que dibujar todo.

O eso o si sigo tu idea si lo montase en el mio creo que tendria que montar un pic10 o algo así encagado de "tarjeta gráfica" y comunicados por usart.

La ventaja que tengo actualmente de que en menos de 1ms he podido calcular todo quizas dos veces, lo perderia claramente :/.

Hablando de eso me he puesto a buscar y he encontrado una cosa que me servira de mucho, los pic18 incorporan una alu por hard para multiplicar!! jajajaja esto va a mejorar en 100us el tiempo del programa fijo fijo !!

El hitech es también de microchip, vale para pics 18 y menores, luego esta el C18 que solo vale para pic18. Las optimizaciones seran similares, cierto es que en modo "free" te genera muchisimo codigo basura, sin embargo hay "cracks" para no tener problema de esto

Eso mismo, el compilador esta "curado" o semi curado

Las RPM ya te digo, es PWM de 0-9V (en vez de 0-5V de toda la vida) lo que varia es el periodo, segun eso se calcula las RPM, por ejemplo creo que 60Hz eran 1000RPM o algo asi, ahora no me acuerdo bien pero algo asi era.

Diras que para indicar 0 utiliza un voltaje de 0 a 9/2 y luego para indicar 1 utiliza un voltaje de 9/2 -> 9??? cierto??, es decir el voltaje es constate pero tiene un nivel bajo y un nivel alto, no que vaya de 0 a9v analogicamente entiendo.

El caso es que para la gestion de objetos (creacion, destruccion) se necesita una gestion, los pics de por si no lo tienen (por lo menos los normales) esa gestion seguramente ocupara rom y ram, y eso conlleva a la relentizacion del codigo, en realidad para un pic lo mejor es ASM, es la mejor optimizacion, sin embargo te tiras 3h para hacer una simple funcion por lo cual es muy lento. Luego viene el C a secas que es lo mas cercano a ASM.

No necesariamente todo compilador tiene varios pasos y el último siempre es Binario o ASM.

Una cosa es la memoria ram y otra la memoria de instrucciones , las instrucciones de construir un objeto no se guardan en la ram se guardan en la de instrucciones y solo se manejan apuntadores a estas , a ram no se lleva nada de eso que piensas .

Si te das cuenta la memoria de instrucciones es normalmente muy grande en los pics comparado a la ram.

Y con el MPLABX (el mplab normal también se podia) puedes ver la traduccion del codigo C en ASM en una ventana, con el CCS supongo que también se podra, por ejemplo:


while(NVMCONbits.WR);
00092E E24729 CP0.B 0x729
000930 35FFFE BRA LT, 0x92E
68: NVMADR+=0x0100;
000932 201000 MOV #0x100, W0
000934 B4272A ADD NVMADR
000936 B00808 ADD #0x80, W8
69: }

Si en el vsm studio que utilizo lo puedo ver también, me genera el fichero hex(binario) y el asm

Lo que te refieres a la creacion "por si acaso" también lo hace los compiladores de microchip, si tu pones un codigo que no se usa, automaticamente al compilarlo no te lo crea, o si por ejemplo pones un bucle que nunca se cumplira (por ejemplo while(0) i=i+1; (en este caso ignora completamente ese codigo y ni lo pone).
Luego estan otros codigos como los inline, estos lo que hacen es generar un codigo cada vez que se llama la funcion, asi se ahorra el call y return ademas de las variables en caso de que haya algunas variables, el problema es que esto utiliza mucha rom, si el codigo tiene 5 lineas, y llamas 20 veces distinta a la funcion se genera 5x20 veces.
Resumiendo, hay muchas formas de optimizar, lo unico es que hay que leerse bien el manual ya que hay muchos tipo de variables, datos, funciones...

No me refiero a eso, sino que tu cuando creas una estructura o variables reservas un espacio, ya solo declarandola si o si, en cambio crear un objeto , si este no es llamado no consume espacio son apuntadores a funciones que lo crean cuando esta en asm, al menos eso entendi en la documentacion que lo explica de c++ para sistemas embebidos y es la tendencia que hay ahora y de futuro uml + C++ para sistemas embebidos.

Si atmel y Avr ,ti que llevan la batuta en sistemas embebidos lo usan y microchip no , no es que no sirva, al reves tecnologicamente microchip esta menos avanzado, pero es como las cucarachas de microchip hay mucha informacion asequible y de atmel y avr no.


Atmel llevan tiempo en C++.

Es como ubuntu y gentoo o slackware .

El uml en x86 se lleva aplicando desde unos añitos como 20 y segun veo po ahi si no sabes uml no te quieren almenos como proyectista.


Saludos

Editado por alecuba16, 19 septiembre 2012 - 23:53:37.

[Ivan82]

[MerLiNz]

Lo de las RPM no acabo de explicarme bien, o no me entiendes bien

Es un PWM que 0v indica el 0 logico y 9V indica el 1 logico, es decir, en vez de los 0-5V que estamos acostumbrados a ver en la electronica digital, son de 0V a 9V, lo unico que varia es su periodo el cual indica las RPM, x ejemp: 60Hz = 1000RPM; 120Hz=2000RPM y asi...

[alecuba16]

Lo de las RPM no acabo de explicarme bien, o no me entiendes bien

Es un PWM que 0v indica el 0 logico y 9V indica el 1 logico, es decir, en vez de los 0-5V que estamos acostumbrados a ver en la electronica digital, son de 0V a 9V, lo unico que varia es su periodo el cual indica las RPM, x ejemp: 60Hz = 1000RPM; 120Hz=2000RPM y asi...

Ya te entendi en el post anterior, pero bueno eso no habria problema le enchufo algun tipo de selector y con una salida lo conmuto para lecturas de 5v o 9v-12v, en la de 9v le pongo una resistencia para disminuir el voltaje y tirando.

O eso o colocar un transistor el cual la base lo maneje la señal de 9v y colector vaya a 5v y el emisor a mi entrada de 5v,lo que tengo que ver que sea suficientemente rapido en el cambio , es decir si contamos que 60hz son 1000rpm 15000rpm son 900hz, redondeamos a 1khz, es decir un periodo de 1/1000= 0,001 seg, 1ms.

Sabrias de algún lado donde se indicase de cada marca o cualquier info sobre los diferentes sensores??

Me gustaría muchisimo incorporarlo a mi controlador, pero necesito estandarizarlo lo mas posible.

A ver si me echas un cabo

Por cierto me puse a mirar en ensamblador el código que me generaba el compilador y no suele utiliza el multiplicador 8x8 por hard!!!! solo en un caso en concreto, encontre una libreria que lo utiliza:http://www.ccsinfo.com/forum/viewtopic.php?t=37227 para multiplicar dividir y exponenciar.

Igual en el tuyo tienes muchas operaciones como el mio y usando el multiplicador por hard (fijate si primero te genera el codigo en assembler) la diferencia es sustancial en tiempo, lo voy a probar.

Editado por alecuba16, 20 septiembre 2012 - 12:05:49.

[MerLiNz]

Si, para el voltaje lo mejor es un transistor y se acabo, asi le puedes meter hasta 20V sin que el pic se cosque. Es dificil buscarlo, yo estuve buscando el de nissan y no lo he encontrado, se que lo busque en google pero no me acuerdo ni que puse para buscarlo, el caso es que la mayoria de fabricantes funcionan asi, existen tacometros aftermarket universales que los enchufas a cualquier coche y van bien, supongo que la unica diferencia quizas sea la frecuencia que nissan funcione de X a Y y honda de Z a J, si tienes un osciloscopio ya estas tardando en meterselo a tu coche para hacerlo universal puedes poner Sensor RPM->Fabricante->Honda; Nissan; ... Es mas, ahora que me estoy acordando, la apexi AVCR para la seleccion de RPM te pide que le indiques el numero de cilindros que tiene el vehiculo y el sensor de velocidad también es medio universal ya que solo viene para 4 tipos.

La mayoria de compiladores usan sus propias multiplicaciones/divisiones, esto es porque siguen un ISO-**** o noseque historia, en el dspic a mi si me multiplica por hard, pero me divide por software, en este pic la multiplicacion solo toma una instruccion de reloj, y la division 16 instrucciones creo (ambos de 16bits y 32/16bits=16bits). De todas formas no me preocupa mucho a 40MIPS no tengo problemas, y si veo que va muy lento lo puedo poner hasta 70MIPS , yo para usar la division por hard tengo que usar la funcion __builtin_divud(x,y); pero tengo que tener cuidado con las divisiones por 0 ya que te lleva a una interrupcion de error div by zero y no vuelve a dividir bien hasta que le reseteo el registro de error.

Lo escribi aqui para no olvidarme: http://www.todopic.c...p?topic=37934.0

[alecuba16]

Si, para el voltaje lo mejor es un transistor y se acabo, asi le puedes meter hasta 20V sin que el pic se cosque. Es dificil buscarlo, yo estuve buscando el de nissan y no lo he encontrado, se que lo busque en google pero no me acuerdo ni que puse para buscarlo, el caso es que la mayoria de fabricantes funcionan asi, existen tacometros aftermarket universales que los enchufas a cualquier coche y van bien, supongo que la unica diferencia quizas sea la frecuencia que nissan funcione de X a Y y honda de Z a J, si tienes un osciloscopio ya estas tardando en meterselo a tu coche para hacerlo universal puedes poner Sensor RPM->Fabricante->Honda; Nissan; ... Es mas, ahora que me estoy acordando, la apexi AVCR para la seleccion de RPM te pide que le indiques el numero de cilindros que tiene el vehiculo y el sensor de velocidad también es medio universal ya que solo viene para 4 tipos.

La mayoria de compiladores usan sus propias multiplicaciones/divisiones, esto es porque siguen un ISO-**** o noseque historia, en el dspic a mi si me multiplica por hard, pero me divide por software, en este pic la multiplicacion solo toma una instruccion de reloj, y la division 16 instrucciones creo (ambos de 16bits y 32/16bits=16bits). De todas formas no me preocupa mucho a 40MIPS no tengo problemas, y si veo que va muy lento lo puedo poner hasta 70MIPS , yo para usar la division por hard tengo que usar la funcion __builtin_divud(x,y); pero tengo que tener cuidado con las divisiones por 0 ya que te lleva a una interrupcion de error div by zero y no vuelve a dividir bien hasta que le reseteo el registro de error.

Lo escribi aqui para no olvidarme: http://www.todopic.c...p?topic=37934.0

Pues eso eso necesito, pasame toda la info que tengas sobre los fabricantes de sensor de rpm y también el tema de sensor de velocidad .

Si los dspic son una respuesta a los Atmel bastante buena. Miralo que sobrado que eres el matias el humilde los MIPS???

Yo es que me gusta ser muy "smart" y "optimizado" en esto de la informatica y por eso le saco el jugo a los 8bit.

Sino tengo por ahi un AMD 64 3200+ que no lo uso ese tiene unos cuantos GMIPS y con el puerto paralelo que aún tiene usarlo de I/O y ya puedo "reshularte" con mis mips

Resumiendo:

-Sensores de RPM:
Configurar numero de cilindros.
Ejemplo 4:
Preconfigurar el puerto para lectura, contar 4 cambios-interrupciones y calcular su periodo = frecuencia = rpm, cierto?


-Sensor de velocidad:
Por voltaje??? 0-12??¿

Editado por alecuba16, 20 septiembre 2012 - 21:31:31.

[MerLiNz]

Info tengo ninguna , a veces leo las cosas y no las guardo por eso luego no recuerdo donde lo vi el caso es que creo que guarde la imagen del osciloscopio que postearon donde ponia la info, pero ya ni me acuerdo, lo que puedes hacer para saberlo: osciloscopio y miras la señal de tu carro, o bien también con un polimetro que tenga frecuenciometro te podria servir, en base a eso te haces tu propio calculo:
60Hz ----- 1000RPM
xHz ------- xRPM

Yo prefiero un pic bueno porque asi nunca se te queda chico , tiene muchos perifericos (pwm, oc, ic, can, timers a patadas de 16bits, un monton de spis, USB, uart, memoria de sobra...) lo que hace muy sencilla y rapida la programacion, 16bits son 16bits...

por ejemplo, ponle esto a tu pic a ver cuanta memoria te sobra

struct _mapa {
unsigned int mMAP[21][21];
unsigned int mRPM[21], mLOAD[21];
};

struct _coil {
unsigned int RPM[21];
unsigned int DWELL[21];
};

en mi dspic ocupa un 1%

El sensor RPM simplemente lees el periodo y sacas la frequencia, esa frecuencia la divides (o multiplicas) por una constante predefinida (por ejemplo y digo ejemplo porque no se el dato real: nissan *32, honda *16, toyota...) y sacaras las RPM.

El sensor de velocidad también va por PWM, lo primero es que sale del generador inductivo (en la caja de cambios) en forma alterna, llega a la ecu y alli lo pasa a continua y señal cuadrada (digital), luego lo saca por el velocimetro en forma de PWM también, sobre este sensor poco te puedo decir porque nunca he mirado, pero seguramente sera de la misma forma que las RPM.

Otra forma facil que se me ha ocurrido para sacar las RPM y no complicarte es pillar la señal del inyector 1 por ejemplo, como un motor da 1 inyeccion por cada media vuelta entonces daria 2 inyecciones por cada vuelta, si tienes una Freq de 10Hz seria lo equivalente a 5 vueltas por segundo, multiplicas por 60 y ya tienes las RPM.

[alecuba16]

Info tengo ninguna , a veces leo las cosas y no las guardo por eso luego no recuerdo donde lo vi el caso es que creo que guarde la imagen del osciloscopio que postearon donde ponia la info, pero ya ni me acuerdo, lo que puedes hacer para saberlo: osciloscopio y miras la señal de tu carro, o bien también con un polimetro que tenga frecuenciometro te podria servir, en base a eso te haces tu propio calculo:
60Hz ----- 1000RPM
xHz ------- xRPM

Yo prefiero un pic bueno porque asi nunca se te queda chico , tiene muchos perifericos (pwm, oc, ic, can, timers a patadas de 16bits, un monton de spis, USB, uart, memoria de sobra...) lo que hace muy sencilla y rapida la programacion, 16bits son 16bits...

por ejemplo, ponle esto a tu pic a ver cuanta memoria te sobra

struct _mapa {
unsigned int mMAP[21][21];
unsigned int mRPM[21], mLOAD[21];
};

struct _coil {
unsigned int RPM[21];
unsigned int DWELL[21];
};

en mi dspic ocupa un 1%

El sensor RPM simplemente lees el periodo y sacas la frequencia, esa frecuencia la divides (o multiplicas) por una constante predefinida (por ejemplo y digo ejemplo porque no se el dato real: nissan *32, honda *16, toyota...) y sacaras las RPM.

El sensor de velocidad también va por PWM, lo primero es que sale del generador inductivo (en la caja de cambios) en forma alterna, llega a la ecu y alli lo pasa a continua y señal cuadrada (digital), luego lo saca por el velocimetro en forma de PWM también, sobre este sensor poco te puedo decir porque nunca he mirado, pero seguramente sera de la misma forma que las RPM.

Otra forma facil que se me ha ocurrido para sacar las RPM y no complicarte es pillar la señal del inyector 1 por ejemplo, como un motor da 1 inyeccion por cada media vuelta entonces daria 2 inyecciones por cada vuelta, si tienes una Freq de 10Hz seria lo equivalente a 5 vueltas por segundo, multiplicas por 60 y ya tienes las RPM.

Ok, pues buscaré , si tengo un multimetro con fecuencimetro, osciloscopio al final no me lo han prestado.

Eso..... haciendo calculos de cabeza tengo 3936bytes, asi que haciendo cuentas (21*21+ 21+21) *2 =966 bytes la primera y la segunda -(21+21)*2 = 84 bytes, asi que 1050 bytes que es 26,7% de ram ocupada. .

De todas formas el algoritmo que utlizo para calcular la geometria no tiene demasiados filas ni columnas unas 20 y todas indican un numero de porciento de acelerador y presion, que se multiplica con el que se conoce. solo almaceno % asi que uso un byte para representarlo.

Mi idea es luego hacerlo con una función que lo calcule al vuelo y tenga tantos microsteps como quiera pero aú tengo que pensar como relacionar el acelerador con el map.

De momento no lo he llenado del todo, si me veo apurado estoy a 4mips, lo subo a 12mips y uso mas la cpu

Se te ve que te gusta el tema este y llevas trasteando un tiempo, yo empiezo en esto y parece interesante voy a ir viendo como es el mundillo.

Editado por alecuba16, 20 septiembre 2012 - 22:51:39.

[MerLiNz]

Pues si, yo sabia programar desde los 14 años, pero no sabia que programas hacer, algun troyano o algo asi en aquellos tiempos del win98 y poca cosa mas, pero desde que descubri los pics pues ya me diras tu, puedo hacer "lo que me salga" es mas, tengo tantos proyectos en mente que no se cual hacer, tengo 2 o 3 proyectos empezados y ninguno terminado jaja

Yo de osciloscopio me pille este hace unos años:
http://www.ebay.es/i...0#ht_5175wt_907

junto con un portatil, para estas cosillas es perfecto, para cosas de precision y demas necesitaria otro, pero vamos, para lo que yo lo uso (coches) me sobra, también me pille un analizador logico que me costo 20€ creo, esta bastante bien, lo he probado poco, pero hablan bien de el.

Editado por MerLiNz, 20 septiembre 2012 - 22:58:33.

[alecuba16]

Con razón..... jajaj. Lo mismo me pasa ahora a mi tengo tantas cosas en paralelo que no las tengo acabadas, ejemplo ahora estoy muy puesto con kernels y compilaciones cruzadas desde mi pc para routers con mips, añadir torrents con samba, ftp ,etc y soporte discuso duros usb , en plan un NAS, ya que está enchufado las 24h que amortice descagando solo, como voy sobrado de MIPS en ese caso si te gano tengo 320mhz (320/4=80 mips) y 64MB de ram, me sobran los mips!!!!!!!!!!

Que opinas de este osciloscopio DIY:

http://yveslebrac.bl...-in-galaxy.html

Tiene buena pinta, almenos asi tirando por teoricamente por encima su modulo adc debe hacer una conversion entera en unos 18-20us. 1/(20/1000000)=50000 samples /sec o sea 50Ms/s, no esta nada mal ,no?.

Te paso por privado mi mail y el whatsapp asi te tengo de libro de consulta, te importa?

Editado por alecuba16, 21 septiembre 2012 - 08:42:51.

[MerLiNz]

Hombre, por 5€ no puedes pedir mas

[alecuba16]

Ahora estoy mirando otra cosa que me es muy util , no se si lo has probado, se trata de "self programming" es decir crear un "bootloader" que en caso que no haya ninguna peticion por el puerto de serie sigua y arranque el programa "normal" y en otro caso descague el hex del puerto de serie y se programe a si mismo.

Tienes alguna experiencia con esto???

Aunque tengo un programador para hacer ICSP, me interesa el tema.