Tengo un PIC18F4680 y quiero interactuar con un módulo Ecan y UART al mismo tiempo. Estoy enviando el mensaje UART correctamente y leyendo el bus CAN correctamente, pero al intentar hacer ambas cosas al mismo tiempo, el microcontrolador deja de funcionar. ¿El PIC18F4680 puede administrar ambas comunicaciones sin fallar?
Si no es posible trabajar con ambas comunicaciones a la vez, ¿qué microcontrolador debo utilizar? El código de programación está hecho para MicroC, por lo que preferiría un microcontrolador compatible con MicroC.
He intentado simplificar la arquitectura del firmware, pero sigue sin funcionar. Aquí está el código:
Msg_Rcvd = CANRead(&CAN_RxID, data_rx, &rx_DLC, CAN_Rcv_Flags);
id = CAN_RxID;
dato = data_rx;
UART1_Write('$');
UART1_Write(dato[0]);
UART1_Write(dato[1]);
UART1_Write(dato[2]);
UART1_Write(dato[3]);
UART1_Write(dato[4]);
UART1_Write(dato[5]);
UART1_Write(dato[6]);
UART1_Write(dato[7]);
He guardado los valores leídos del bus CAN en diferentes variables para evitar usar ambas comunicaciones a la vez, pero no funciona. No estoy familiarizado con las interrupciones y no sé exactamente cómo usarlas. ¿Alguien ha hecho algo similar con las interrupciones?
El PIC 18F4680 es capaz de ejecutar su módulo UART y CAN al mismo tiempo. Si estos funcionan por separado, pero no juntos cuando ambos se usan mucho, es probable que algo se esté sobrepasando.
Su arquitectura de firmware importa mucho aquí. Probablemente tenga una rutina de interrupción congestionada. He realizado CAN y UART I/O juntos en varios PIC, incluidos algunos de la serie 18F. Utilizo un sistema multitarea cooperativo mínimo para tales cosas. Simplifica mucho la arquitectura del firmware para dedicar una tarea a recibir desde cada puerto de comunicaciones. En el caso de UART, la rutina de interrupción mete los bytes recibidos en un FIFO, que luego la tarea de lectura de UART drena a medida que se acerca. Para CAN, no uso interrupciones en absoluto, solo hago que la encuesta de tarea de recepción de CAN esté disponible para el próximo marco CAN, lo procese, luego regrese y hágalo de nuevo. Tenga en cuenta que el sondeo de un evento en el sistema multitarea es un bucle que incluye una llamada a TASK_YIELD en cada iteración. Eso permite que otras tareas utilicen el procesador.
Lo primero que debe hacer es verificar que está ejecutando el PIC a su velocidad de reloj máxima. Después de eso, no hagas tonterías en el firmware. Este es un caso en el que una arquitectura de firmware bien pensada realmente importa. Examine particularmente su estrategia de interrupción. Haga lo menos posible en la interrupción para reducir la latencia del servicio de hardware, luego maneje la mayoría de las cosas en el código de primer plano. Escribir la rutina de interrupción en ensamblador puede ser una buena idea. He visto a los compiladores agregar mucha hinchazón para interrumpir las rutinas.
Si aún no puede reducir sus 20 libras de código a un tamaño razonable de 10 libras, obtenga un PIC de 30 libras. Hay series 33EP, por ejemplo, que también tienen módulos UART y CAN. La tasa de ejecución de instrucciones más rápida permite más descuido antes de que el sistema se rompa. Sin embargo, una vez más, una buena arquitectura de código es la solución real.
Eugenio Sh.
olin lathrop
usuario28910