Colección de drivers para perifericos del PIC24 con FreeRTOS

[jgpeiro06]

Estoy pensando en desarrollar una colección de drivers para los periféricos del PIC24 de Microchip con FreeRTOS, pero no se exactamente que debe hacer un driver.

Hasta el momento sé que una vez implementado el driver las tareas tienen a su disposición unas funciones generales para manejar el periférico típicas como: init, reset, open, close, read, write.

Estoy seguro que hay una manera "estandar" de escribir un driver y que debe haber documentación, pero no se donde...

También sé que un driver debe permitir a las distintas tareas de una aplicación manejar el periferico sin producir errores, pero no se si deben de cumplir algún requisito más.
 

Saludos

[jgpeiro06]

Bueno, aquí dejo una versión NO FUNCIONAL del driver de la UART. Con vuestros comentarios espero poder hacerlo funcionar correctamente, así que espero que os animéis!!

Cumple los tres conceptos basicos que creo que debe cumplir un driver:
   Impide que más de una tarea maneje la UART al mismo tiempo.
   Libera a las tareas del control de las interrupciones.
   Libera al usuario de la configuracion a bajo nivel.

Se divide en 2 archivos: uart_driver.h y uart_driver.c, y se apoya en las funciones del archivo uart.h que proporciona Microchip.
El archivo uart_driver.h declara las siguientes funciones:

int InitUART1_driver(void);
Inicializa los recursos que comunicarán la uart con la aplicacion (2 queues y un mutex).

void OpenUART1_driver(unsigned int config1,unsigned int config2, unsigned int ubrg);
Configura y arranca la uart.

void CloseUART1_driver(void);
Para la uart.

unsigned int ReadUART1_driver(void);
Lee un dato de la cola de recepción de la uart. Este dato habrá sido introducido en la cola en la función  _ISR __attribute__((interrupt)) _U1RXInterrupt.

void WriteUART1_driver(unsigned int data);
Escribe un dato en cola de transmisión de la uart. Este dato será extraído de la cola en la funcion  _ISR __attribute__((interrupt)) _U1TXInterrupt.

Código: C

1. // UART_DRIVER.H
2.  
3. #ifndef UART_DRIVER_H
4. #define UART_DRIVER_H
5.  
6. #include "UART.H"
7. #include "FreeRTOS.h"
8. #include "queue.h"
9. #include "semphr.h"
10.  
11. int InitUART1_driver(void);
12. void OpenUART1_driver(unsigned int config1,unsigned int config2, unsigned int ubrg);
13. void CloseUART1_driver(void);
14. unsigned int ReadUART1_driver(void);
15. void WriteUART1_driver(unsigned int data);
16. //void _ISR _U2TXInterrupt(void);
17. //void _ISR _U2RXInterrupt(void);
18.  
19. #endif  // #ifndef UART_DRIVER_H

Código: C

1. // UART_DRIVER.C
2.  
3. #ifndef UART_DRIVER_C
4. #define UART_DRIVER_C
5.  
6. #include "UART_DRIVER.H"
7.  
8. static xSemaphoreHandle xMutexUartDriver;
9. static xQueueHandle xQueueUartDriverTx;
10. static xQueueHandle xQueueUartDriverRx;
11.  
12.  
13. int InitUART1_driver(void){
14.  
15.     if( NULL == ( xMutexUartDriver = xSemaphoreCreateMutex() ) )
16.         return -1;
17.        
18.         if( NULL == ( xQueueUartDriverTx = xQueueCreate( 4, sizeof( unsigned int ) ) ) )
19.                 return -1;
20.        
21.         if( NULL == ( xQueueUartDriverRx = xQueueCreate( 4, sizeof( unsigned int ) ) ) )
22.                 return -1;
23.        
24.         vQueueAddToRegistry( xMutexUartDriver, ( signed portCHAR * ) "xMutexUartDriver" );
25.         vQueueAddToRegistry( xQueueUartDriverTx, ( signed portCHAR * ) "xQueueUartDriverTx" );
26.         vQueueAddToRegistry( xQueueUartDriverRx, ( signed portCHAR * ) "xQueueUartDriverRx" );
27.         return 0;
28. }
29.  
30. void OpenUART1_driver(unsigned int config1,unsigned int config2, unsigned int ubrg){
31.  
32.         if( pdTRUE == xSemaphoreTake( xMutexUartDriver, portMAX_DELAY ) ){
33.                 OpenUART1( config1, config2, ubrg );
34.                 ConfigIntUART1( UART_RX_INT_EN & UART_RX_INT_PR7 & UART_TX_INT_EN & UART_TX_INT_PR7 ); // Como trabajar correctamente con los defines de uart.h?
35.         }
36.        
37.         return;
38. }
39.  
40.  
41. void CloseUART1_driver(void){
42.         CloseUART1();
43.         ConfigIntUART1( UART_RX_INT_DIS & UART_TX_INT_DIS );// Como trabajar correctamente con los defines de uart.h?
44.         xSemaphoreGive( xMutexUartDriver );
45.         return;
46. }
47.  
48.  
49. unsigned int ReadUART1_driver(void){
50.         unsigned int data;
51.         xQueueReceive( xQueueUartDriverRx, &data,  portMAX_DELAY );
52.         return data;
53. }
54.  
55.  
56. void WriteUART1_driver(unsigned int data){
57.        
58.         xQueueSend( xQueueUartDriverTx, ( void * ) &data, portMAX_DELAY );
59.        
60.         if( uxQueueMessagesWaiting( xQueueUartDriverTx ) )              // ¿¿??
61.                 IFS0bits.U1TXIF = 1;                                                            // ¿¿??
62.        
63.         return;
64. }
65.  
66. void _ISR __attribute__((interrupt)) _U1RXInterrupt( void ){
67. //void __attribute__((__interrupt__, auto_psv)) _U1RXInterrupt( void ){
68.        
69.         unsigned int data;
70.         IFS0bits.U1RXIF = 0;    // Clear flag
71.         portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;
72.        
73.         data = ReadUART1();
74.        
75.        
76.         xQueueSendFromISR( xQueueUartDriverRx, &data, &xHigherPriorityTaskWoken );
77.        
78.         return;
79. }
80.  
81. void _ISR __attribute__((interrupt)) _U1TXInterrupt( void ){
82. //void __attribute__((__interrupt__, auto_psv)) _U1TXInterrupt( void ){
83.  
84.         unsigned int data;
85.         IFS0bits.U1TXIF = 0;    // Clear flag
86.         portBASE_TYPE xTaskWokenByReceive = pdFALSE;
87.    
88.     xQueueReceiveFromISR( xQueueUartDriverTx, ( void * ) &data, &xTaskWokenByReceive );
89.     WriteUART1( data );
90.                
91.     return;
92. }
93.  
94.  
95. #endif  // #ifndef UART_DRIVER_C

y aquí un ejemplo de su uso con FreeRTOS

Código: C

1. void vTaskUARTTEST( void * pvParameters ){
2.        
3.         unsigned int value1=0, value2=0, value3=0, value4=0;
4.                
5.         AD1PCFG = 0xFFFF;                                                       // Configura los pines del puerto A como digitales. Solo para el PIC24.
6.  
7.         asm volatile ( "MOV #OSCCON, w1 \n" "MOV #0x46, w2 \n" "MOV #0x57, w3 \n" "MOV.b w2, [w1] \n" "MOV.b w3, [w1] \n" "BCLR OSCCON,#6");
8.         RPOR7bits.RP15R = 3;    // RP15 is UART1TX
9.         RPINR18bits.U1RXR = 14; // UART1RX is RP14
10.         asm volatile ( "MOV #OSCCON, w1 \n" "MOV #0x46, w2 \n" "MOV #0x57, w3 \n" "MOV.b w2, [w1] \n" "MOV.b w3, [w1] \n" "BSET OSCCON, #6" );
11.        
12.         while(1){
13.  
14.         OpenUART1_driver( 0x8000, 0x0400, 12 );
15.        
16.                 unsigned int data = 100;
17.                 do{    
18.                
19.                         WriteUART1_driver( data );
20.                         data = ReadUART1_driver();
21.        
22.                 }while( data != 100 );
23.        
24.                 CloseUART1_driver();
25.         }
26. }
27.  
28. int main(){
29.         if( InitUART1_driver() )
30.                 return -1;
31.        
32.         if( pdPASS != ( xTaskCreate( vTaskUARTTEST, ( signed portCHAR * ) "UARTTEST,", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY+1, &xHandleADC ) ) )
33.                 return -1;
34.  
35.         vTaskStartScheduler();

[RICHI777]

Hola, te comento mi opinion. Con respecto a como escribir un driver, dudo que exista algún documento formal de como hacerlo, lo que hago yo normalmente es ver como lo hacen sistemas comerciales y con prestigio, sobre todo en el convenio de nombres, tipos de datos y organización arquitectonica, etc, etc. Con respecto a lo que posteaste dos sugerencias tengo y una obeservación.
La observación es que en este esquema no es para cualquier micro, porque no es lo mismo implementar colas o buffers circulares que implementar mutex y colas de un RTOS que son computacionalmente mas pesadas en recursos, overhead y footprint, pero es claro que lo estas orientado a un micro de 16 bits con la potencia necesaria.

Las dos sugerencias son estas:

• Utilizar tipos de datos, ejemplo byte,word, dword o UINT8,UINT16,UINT32 para mi es más facil leer código asi y tambien ayuda a la portabilidad
• Podrias incluir el manejo de lo que es plataforma dependiente dentro de una capa de bajo nivel, de esa manera tendrias todo el manejo del hardware dentro de una capa y te permitiria que tu implementación sea facilmente portable a otra plataforma u otro micro sin grandes esfuerzos.
  

Igual es muy piola lo que estas haciendo !

Saludos !

[RICHI777]

Hola, otras funciones que deberias implementar por lo menos en el driver de UART serian estas :

• Poner la interface en modo on line u off line
• Soporte para protocolos ( hardware y software )
• Retornar cuantos caracteres existen en las colas
• Retornar el estado de la misma, desde la optica del dispositivo conectado

Saludos !

[jgpeiro06]

Con respecto a como escribir un driver, dudo que exista algún documento formal de como hacerlo

No se, la verdad es que no he visto. Pero tiene que existir libros sobre SO que traten este tema en algún apartado.

Utilizar tipos de datos, ejemplo byte,word, dword o UINT8,UINT16,UINT32

De momento primero quiero aprender a realizar el driver correctamente. La portabilidad es algo secundario.

Podrias incluir el manejo de lo que es plataforma dependiente dentro de una capa de bajo nive

El archivo uart_driver.c, se apoya en una capa de mas bajo nivel que es el archivo uart.h y sus correspondientes .c, y estos se ocupan de escribir los datos en los registros de la uart. ¿Es esa la manera adecuada de dividir el driver en capas?

Igual es muy piola lo que estas haciendo

¿Que quiere decir "piola"?

Poner la interface en modo on line u off line

Hasta ahora con la función Open se configura la uart en varios modos y se pone en marcha. Con la función Close se para la uart.

Soporte para protocolos ( hardware y software )

¿a que te refieres?

Retornar cuantos caracteres existen en las colas

Si, esta puede ser util, la implementare. ¿Que nombre puedo darle?.o ¿no debería la función Read cumplir ya esta función?

Retornar el estado de la misma, desde la optica del dispositivo conectado

¿a que te refieres?

[Suky]

Hola! Hoy me encuentro en las mismas, he retomado el tema de aprender a trabajar con FreeRTOS tras una pequeña introducción que realizo Reinier el año pasado. La idea es aprender a crear Drivers como para desarrollar algunos proyectos, pero no he encontrado mucha información. Alguien tiene algo de información al respecto? Tengo la presentación de Marcelo Lorenzati, pero no es más que eso, una presentación. Seria interesante algún libro o articulo se explaye más sobre el tema 

Por ahora vengo estudiando los códigos de driver que he encontrado, con la complejidad que ello conlleva, intentando formar una estructura de trabajo.

Saludos!

[LABmouse]

Hola, yo tampoco encuentro manual o información de como y cuales funciones mínimas debe tener un driver que cumpla con un standard...

[RICHI777]

Hola, por lo que tengo entendido solo para SO establecidos ( Windows, Unix, Linux, BSD, iOS ) hay formas especificas y establecidas de escribir drivers: La misma se basa en la comunicación del kernel y los dispositivos, por lo tanto como FreeRTOS no es SO establecido ( tampoco según mi punto de vista es realmente un SO ) la idea de desarrollar drivers quedan a criterio de los desarrolladores, eso si, la forma correcta de escribirlos es siguiendo el paradigma que ofrece el entorno, es recomendable que sea usando el conjunto de servicios que brinda FreeRTOS ( colas, scheduler, semaforos, etc ). Sería lo mismo que cuando hago un script en Python se haga siguiendo el paradigma de Python y no escribirlo como si fuera C, las dos formas seguramente funcionen pero la idea es usar el paradigma correcto. Aunque para ciertas aplicaciones es mandatorio el uso de un RTOS, no se puede usar a diestra y siniestra, pensar que estas implementaciones ocupan mas memoria y pueden llevar a los tipicos problemas de los RTOS.

Saludos !

PD. Revsiando este post me di cuenta que nunca le conteste a jgpeiro

[Suky]

Muchas gracias por los comentarios RICHI! Al volver del "descanso" voy a seguir trasteando con esto  


Saludos a ambos!