Recibir unsigned long por Rs232, protocolo SDI

[Burno]

Hola gente, estamos realizando una comunicación entre dos pics por rs232 y lo hemos logrado mediante el protocolo SDI, el problema se nos da en que en un momento el esclavo envía datos de la siguiente forma:

  adc_value = read_adc();  // guarda valor medido de la señal analogica del sensor
               
               putc(ADDRESS); //delay_us(WAITLESS);
               putc('+');      //delay_us(WAITLESS);
               printf("%Lu\r\n", adc_value);

Es decir envia por printf el valor "adc_value" que es el valor del conversor analógico digital (adc_value está definido como unsigned long ).

El problema que en todo el protocolo, el maestro lee con getc(); y así compara y recibe datos. Cuando recibe estos datos unsigned long  tenemos que mostrarlos en un lcd como números, lo que hicimos fue recibirlos como char y los pasamos con atoi pero el valor que muestra no corresponde y encima con un dígito más.

Cual sería la forma correcta de obtenerlos y que sea lo que está en la variable adc_value?  Adc_value tiene que ser un entero entre 0 y 1024? (Es un conversor de 10 bits.)

Gracias por su tiempo

[MerLiNz]

putc(adc_value>>;
putc(adc_value);

y para la recepcion:
adc_value=getc()<<8;
adc_value|=getc();

[RALF2]

Que tal Amigos!
Burno podrias modificar el encabezado de tu pregunta donde dice SDI deberias colocar SPI para no crear confucion. 

Saludos

[Burno]

MerLiNz, gracias por tu respuesta, pero tengo entendido que la función putc no se usa para enviar variables, y si en este caso sirviera, no entendí lo que le agregás  de >>8 y <<8.

Ralf el bus usado es spi, pero usamos el protocolo SDI-12 http://en.wikipedia.org/wiki/SDI-12


Saludos!

[MerLiNz]

el putc si no me equivoco es para enviar char, osea 8bits, el >>8 lo que hace es desplazar los 8 bits altos de los 16bits, es decir si adc_value=0x019A entonces en el primer putc se envia 0x01 y en el segundo putc 0x9A.

La recepcion lo mismo, obtiene los 8bits altos, como primero se manda 0x01 pues esos son los bits altos, y luego se le hace un or a los bits bajos para añadirle el 0x9A

[Burno]

No he podido, el código del sensor emisor no lo puedo cambiar por lo tanto no puedo enviar los datos con putc, tengo que adaptarme a que se envia el dato como printf y la variable es unsigned long, debo recibirlo en mi pic y probé lo de getch()>> y getch()<< sin suerte.
Alguna otra alternativa?

Gracias

[AngelGris]

  Sigo un poco mareado con el tema... en el encabezado indica que usas protocolo SDI y en el cuerpo del mensaje dices que usas RS232. Con SDI ¿Quieres decir Serial Data Interface? Si es así, creo que es mejor indicarlo UART.

  Por lo general, para UART se suele utilizar una transmisión 8,n,1; eso indica que son 8 bits de datos, ninguno de paridad y 1 de stop.

  Más allá que quieras transmitir un dato de 16, 24 o 32 bits, siempre se enviarán 8 bits a la vez.

  Puede ser que haya algún problema de velocidad entre receptor y transmisor... una forma de "debuggear" el programa sería, hacer la rutina del esclavo en un PIC y observarlo con un terminal para ver como llegan los datos.

  Utilizando, por ejemplo Proteus, podrías hacer un programa en un pic que lea el ADC y envíe los datos al terminal de proteus. Mirando el terminal podrías interpretar como llegan los datos, y la forma necesaria para darle un formato y luego poder mostrarlo en un LCD.

  Me parece que al utilizar printf, ya le estás dando formato de cadena y por lo tanto no sería necesario utilizar "atoi" en el maestro. Creo también que al transmitir el caracter "\n" deberían incluir un getc() para que lea dicho dato.

[RALF2]

Asi es AngelGris!
Yo opino que la duda que tiene Burno no es con respecto al protocolo SDI sino con respecto al USART y el ADC, no obstante ya que me encontraba ladillado    le resolvi el problema a Burno (eso creo  )

Saludos

[Burno]

No tendría que haber puesto lo de protocolo SDI jaja, era innecesario en realidad, SDI es un protocolo para aplicar a la comunicación RS232. Perdon por confundir con eso, no tiene nada que ver en mi  problema.

No encuentro solución, en proteus hice el circuito y un emisor envia con printf por rs232 un unsigned long conocido, y en el receptor lo recibe y lo muestra en la LCD, pero no entiendo que es lo que pasa:

Envío un unsigned long con valor 512 (se supone que unsigned long tiene 16 bits, no?) y en el receptor lo recibo con dos getch (porque tengo en claro que con getch se reciben 8 bits)... imprimo cada getch como hexa para ver los datos que llegan en binario y llega:

00110101   y   10110001  osea 0x35 y 0xB1

espero haberles aclarado mi problema! gracias

[AngelGris]

  Usa sólo el PIC que envía los datos y conectalo al "virtual terminal".

  Yo creo que la función "printf" ya formatea el número. Entonces, en lugar de enviarte 2 datos de 8 bits (que sería el unsigned long), te envía 3 datos de 8 bits... el primer dato es el "5", luego el "1" y por último el "2". Y si, además estás enviando "\n", también te manda los 8 bits correspondientes a ese signo (retorno de carro, que en decimal corresponde al 13).

[MerLiNz]

el unsigned long dependiendo del compilador puede variar, en los de microchip un unsigned long tiene 32bits, unsigned int =16bits y unsigned char 8bits

tu problema es el siguiente:
No puedes enviar una trama con formato string (printf) y luego querer sacar los numeros con getch, cuando tu envias una trama en formato string estas enviando el codigo ascii de los numeros/letras, por ejemplo, si pones una 'a' recibirias 0x61, ademas sin contar que el \r\n sobraria ya que esto se añade para hacer el efecto de "Intro", por ejemplo si lo sacas en un terminal veras los numeros en lineas distintas.

Tienes 2 opciones, o bien lo envias y recibes como string y haces una conversion atoi (para integer) atol(para long), o lo envias todo como te escribi en el primer post y lo recibes con los getch.

[RALF2]

Que tal amigos!
Burno yo realice el programa en CCS y envio 16bits utilizando el printf, que creo era lo que querias y con getc los capturo y luego los retransmito como codigo ascii solo coloque el .c te coloco el codigo con los .cof para que los simules en proteus y veras que funciona 
Ahora bien si utilizas otro tipo de compilador distinto al ccs la cosa cambiaria un poco.

y nos cuentas si te sirve