decodificador / escanner aldl gm para ecu 1227747 - Página 3

RVP · 30-04-2008, 16:13:37

Cita:

Empezado por AndR3Z

9 bits por byte?

sip... mas o menos....

estoy escribiendo de memoria, asi que puedo tener algun error, en los links que envie esta la descripcion completa

la trama se compone de un "byte" de sincronismo, con el valor 0x1ff, luego de eso vienen 20 "bytes" de la forma 0x0PP donde PP es lo que normalmente se ocupa para sacar los datos.

en todo caso es una forma de verlo, alguien podria decir tambien que viene un bit en 1, luego 0xff y eso es el sincronismo. luego 20 veces la combinacion bit en 0 y dato de 8 bits

pero lo que importa, es que son (1 + 20) * (1 + 8) bits lo que componen un frame, y eso, a 160 baudios es como 1 frame por segundo.

primer 1 : byte de sincronismo
20 siguientes datos

de cada grupo de 9 bits:
el primero indica nuevamente sincronismo si esta en 1
los 8 bits siguientes son datos

AndR3Z · 30-04-2008, 19:56:37

Cita:

Empezado por RVP

sip... mas o menos....

estoy escribiendo de memoria, asi que puedo tener algun error, en los links que envie esta la descripcion completa

la trama se compone de un "byte" de sincronismo, con el valor 0x1ff, luego de eso vienen 20 "bytes" de la forma 0x0PP donde PP es lo que normalmente se ocupa para sacar los datos.

en todo caso es una forma de verlo, alguien podria decir tambien que viene un bit en 1, luego 0xff y eso es el sincronismo. luego 20 veces la combinacion bit en 0 y dato de 8 bits

pero lo que importa, es que son (1 + 20) * (1 + 8) bits lo que componen un frame, y eso, a 160 baudios es como 1 frame por segundo.

primer 1 : byte de sincronismo
20 siguientes datos

de cada grupo de 9 bits:
el primero indica nuevamente sincronismo si esta en 1
los 8 bits siguientes son datos

q choro.. hace años q no analizaba métrica de transmision de datos (bueno, tecnicamente ayer q estaba escribiendo un driver rsr485), pero hacia años q no veia eso.

y tiene un buffer de entrada ese PIC como para usar los ciclos mientras se llena la memoria con el dibujado de la pantalla y cualquier calculo q haya q hacer?

RVP · 30-04-2008, 23:58:24

la lectura es via una interrupcion, donde se detecta la transicion de 1 -> 0 en la pata que viene de la ecu, esto indica el comienzo de un bit. es decir, no estoy usando la usart del pic para leer la trama de la ecu, sino una interrupcion directa. el tiempo de refresco de la pantalla y la lectura del mini-teclado son despreciables a esa velocidad, asi que no hay (por el momento) necesidad de un buffer adicional, si se quisiera, se implementa una cola con un semaforo para sus operaciones, pero eso lo implementa uno, no es parte del hardware. cuando lees datos seriales normales, rs232 ahi usas la usart, que tiene su propia circuiteria y un mini-buffer de 2 bytes (!) pero tambien genera interrupciones en la lectura asi que se puede ampliar a todo lo que quieras. el pic esta corriendo a 1mhz real (cristal de 4), pero podria ir 5 veces mas rapido si se necesitara.

norske · 19-05-2008, 19:56:55

INTERESANTE PROYECTO como a ido avanzando la cosa?

saludos y suerte.

RVP · 21-05-2008, 03:01:34

Cita:

Empezado por norske

INTERESANTE PROYECTO como a ido avanzando la cosa?

saludos y suerte.

velocidad = 0 km/h

alguien sabe donde comprar mas horas para el dia?

hablando en serio, cero tiempo para dedicarle estas ultimas semanas, metido en cursos y cachos de la pega :( ya continuara, los avances van por aca de todas maneras.

saludos.

RC5 · 10-08-2010, 17:12:27

estaba tan interesante que me atrevi a revivir el post , el carburador del k5 me tiene loco ....

RVP · 10-08-2010, 17:21:23

Cita:

Empezado por RC5

estaba tan interesante que me atrevi a revivir el post , el carburador del k5 me tiene loco ....

jejeje, pase por algo parecido!!

aunque no lo creas, el proyecto ha seguido avanzando, lo que si, tome una decision radical, lo simplifique, por lo menos la version "movil", sigue siendo un escanner pero "mostrador", te va mostrando los parametros, errores, etc en tiempo real, sin memoria ni revision. por que?, porque es mucho mas chico y puedes andarlo trayendo, para detectar un error solucionable en viaje basta y sobra. en todo caso, la capacidad de memoria la soporta el diseño, solo se recorto electronicamente.

30-04-2008, 23:58:24	#23
RVP Senior Member Top 1000 Fecha de Ingreso: Apr 2003 Ubicación: Santiago, Chile Mensajes: 3.124	Re: decodificador / escanner aldl gm para ecu 1227747 la lectura es via una interrupcion, donde se detecta la transicion de 1 -> 0 en la pata que viene de la ecu, esto indica el comienzo de un bit. es decir, no estoy usando la usart del pic para leer la trama de la ecu, sino una interrupcion directa. el tiempo de refresco de la pantalla y la lectura del mini-teclado son despreciables a esa velocidad, asi que no hay (por el momento) necesidad de un buffer adicional, si se quisiera, se implementa una cola con un semaforo para sus operaciones, pero eso lo implementa uno, no es parte del hardware. cuando lees datos seriales normales, rs232 ahi usas la usart, que tiene su propia circuiteria y un mini-buffer de 2 bytes (!) pero tambien genera interrupciones en la lectura asi que se puede ampliar a todo lo que quieras. el pic esta corriendo a 1mhz real (cristal de 4), pero podria ir 5 veces mas rapido si se necesitara.

19-05-2008, 19:56:55	#24
norske Member Top 500 Fecha de Ingreso: Sep 2006 Ubicación: Los Angeles Edad: 50 Mensajes: 869	Re: decodificador / escanner aldl gm para ecu 1227747 INTERESANTE PROYECTO como a ido avanzando la cosa? saludos y suerte.

10-08-2010, 17:12:27	#26
RC5 Member Top 500 Fecha de Ingreso: Jan 2007 Ubicación: Puerto Natales - XII Region - Republica Independiente de Magallanes Edad: 49 Mensajes: 545	Re: decodificador / escanner aldl gm para ecu 1227747 estaba tan interesante que me atrevi a revivir el post , el carburador del k5 me tiene loco ....