Retorno de Carro

[julietgolf]

Hola compañeros de TODOPIC, les escribo para consultarles algo que supongo debe ser una pavada, pero ya me tiene los pelos de punta por no poder hacerlo funcionar!
Necesito comandar un modulo R/W de tarjetas SD y se lo realiza a traves del puerto RS232.
El tema es que cada comando hacia el modulo debe finalizar con un <CR> (ascii 0D) y la secuencia que debo mandar es

I<CR> //inicializo el modulo
M FOLDER<CR> //creo un directorio

bueno, q es lo q pasa? Me reconoce el \r que paso junto con el comando I, pero el otro no me lo reconoce... es mas, estuve viendolo en un terminal y el PIC ni siquiera lo envia! Como podran apreciar en el dibujo, el primer 0x0D lo envia, pero despues muere en M FOLDE...



Por si sirve de algo, aca paso el codigo...

Código: CSS

1. #include <16F877A.h>
2.  
3. #FUSES NOWDT                    //No Watch Dog Timer
4. #FUSES HS                       //High speed Osc (> 4mhz)
5. #FUSES NOPUT                    //No Power Up Timer
6. #FUSES NOPROTECT                //Code not protected from reading
7. #FUSES NODEBUG                  //No Debug mode for ICD
8. #FUSES NOBROWNOUT               //No brownout reset
9. #FUSES NOLVP                    //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
10.  
11. #use delay(clock=20000000)
12. #use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8)
13. #include "lcd.c"
14.  
15. void main ()
16. {
17.    delay_ms(100);
18.    printf("I\r");
19.    delay_ms(1000);
20.    printf("M FOLDER\r");
21. }

Que es lo que esta pasando? Me tiene loco ya esto, encima lo necesito para cada comando que le envio!!!  jaja!

Espero haberme explicado lo suficientemente bien y desde ya gracias!

Saludos desde CBA, ARG!

[Nocturno]

¿Será que se te llena algún buffer y ese 0x0D ya no cabe?

[RedPic]

Nocturno tiene razón, porque no es solo el retorno de carro, la R de FOLDER tampoco te llega.

[julietgolf]

Nocturno y RedPic, antes que nada, gracias por prestar atencion a mi post...
Yo tb pense lo mismo q ustedes, probelma de buffer, pero miren lo que hice para cerciorarme que no era eso...

He aqui el nuevo codigo...

Código: CSS

1. #include <16F877A.h>
2.  
3. #FUSES NOWDT                    //No Watch Dog Timer
4. #FUSES HS                       //High speed Osc (> 4mhz)
5. #FUSES NOPUT                    //No Power Up Timer
6. #FUSES NOPROTECT                //Code not protected from reading
7. #FUSES NODEBUG                  //No Debug mode for ICD
8. #FUSES NOBROWNOUT               //No brownout reset
9. #FUSES NOLVP                    //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
10.  
11. #use delay(clock=20000000)
12. #use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8)
13.  
14. void main ()
15. {
16.    delay_ms(100);
17.    printf("I\r");
18.    delay_ms(1000);
19.    printf("NO ES PROBLEMA DE BUFFER");
20.    printf("  EL PROBELMA ES CON EL\r");

y aqui la salida que recibo en mi term:



Como veran, el problema esta en el caracter anterior al <CR> y en el <CR>... sera algun problema del CCS?? Y es muy raro, porque el primer <CR> q mando, para el I, si lo envía!

Probe tb a mandar un

Código: CSS

1. putc(0x0D);

pero tampoco...

Gracias sres...

Saludos!

[RedPic]

Haz dos pruebas.

Primero: Escribe el último printf en la forma printf("  EL PROBELMA ES CON EL\rO NO"); para comprobar si es problema del \r o de los dos últimos caracteres, sean estos cuales sean.

Segundo: Termina el programa C para que no se quede sin saber que hacer. Con While(true){} al final te valdrá.

No hagas las dos pruebas al mismo tiempo, primero una y después la otra, y nos dices los resultados.

[julietgolf]

Uh, sos un groso, Red, mira, probe de ambas formas como me dijiste... los resultados fueron:

1) anduvo el \r pero me recorto los ultimos 2 .. de los 3 q le envio

2) puse el while(true) y anduvo todo ok, envio el <CR> y tb los 2 .. ultimos

He aqui el codigo del caso 2 y su screenshot...

Código: CSS

1. #include <16F877A.h>
2.  
3. #FUSES NOWDT                    //No Watch Dog Timer
4. #FUSES HS                       //High speed Osc (> 4mhz)
5. #FUSES NOPUT                    //No Power Up Timer
6. #FUSES NOPROTECT                //Code not protected from reading
7. #FUSES NODEBUG                  //No Debug mode for ICD
8. #FUSES NOBROWNOUT               //No brownout reset
9. #FUSES NOLVP                    //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
10.  
11. #use delay(clock=20000000)
12. #use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8)
13.  
14. void main ()
15. {
16.    while(true)
17.    {
18.       delay_ms(100);
19.       printf("I\r");
20.       delay_ms(1000);
21.       printf("NO ES PROBLEMA DE BUFFER");
22.       printf("  EL PROBELMA ES CON EL\rO NO...");
23.    }
24. }

Red, si tenes tiempo y sabes, me dirias porque pasa eso, lo de no haber puesto el while(true)?

Ahora me tengo q ir volando para la Universidad, pero despues me fijo si puedo hacer andar mi modulito...

MUCHAS GRACIAS!!! 

[RedPic]

¡¡¡ Yeah !!! 

Déjalo como te muestro mas abajo y te funcionará una sola vez pero bien, o sea enviará todo completo una vez:

Código: CSS

1. void main ()
2. {
3.    delay_ms(100);
4.    printf("I\r");
5.    delay_ms(1000);
6.    printf("NO ES PROBLEMA DE BUFFER");
7.    printf("  EL PROBELMA ES CON EL\rO NO...");
8.    while(true)
9.    {
10.    }
11. }

La explicación es que si no colocas ese bucle infinito el programa al ser compilado termina con la instrucción SLEEP que se ejecuta inmediatamente detrás del último printf. Y como printf hace uso de la USART para transmitir y ésta es independiente del contador de programa y razonablemente lenta, el PIC entra en SLEEP antes de terminar de transmitir.

Imagino que si pusieses la USART a mayor velocidad lograrías recibir mas caracteres o incluso completo antes de entrar en modo SLEEP y que si, por el contrario, colocases la USART a una velocidad menor perderías mas caracteres aún.

Al poner un bucle infinito al final, o repetir infinitas veces el envío como tu has hecho, la USART no se detiene porque la instrucción SLEEP no se ejecuta y completa su ciclo perfectamente.

Dale un vistazo al fichero .LST que genera el CCS y mira cuál es la última instrucción del programa y comprueba cómo al poner el bucle esa última instrucción nunca llega a ejecutarse mientra que en la primera versión sin bucle se ejecuta siempre. 

[guille1984]

RedPic, realmente sos un Groso total.

Nos has salvado la vida varias veces ya.

Te vamos a hacer un monumento en mi facultad.

[RedPic]

Te vamos a hacer un monumento en mi facultad.

Pero que en el monumento salga favorecido. Ja, ja, ja 

[josezumino]

Sos un RE-GROSO......!!!!! RedPic....... Gracias a tus respuestas he logrado aprender mucho de programación en C de CCS para PIC's.
Soy un eterno agradecido. Espero poder mostrarte pronto mis logros.

[RedPic]

Sos un RE-GROSO......!!!!! RedPic....... Gracias a tus respuestas he logrado aprender mucho de programación en C de CCS para PIC's.
Soy un eterno agradecido. Espero poder mostrarte pronto mis logros.

Gracias josezumino,

Solo soy un aficionado que lleva mucho años en esto.

Dicen que todos los días se aprende una cosa nueva, yo, como soy muy burro solo aprendo una a la semana, pero son muchas semanas ya y voy acumulando conocimientos, trucos, técnicas y tal. O sea que no tengo mérito alguno mas allá de que no lo abandono y sigo acumulando cosas en la cabeza.  

Un saludo y muchas gracias de nuevo.