Problemas con el spi en una raspberry pi

175 views
Skip to first unread message

Jorge

unread,
Apr 21, 2021, 4:23:50 PM4/21/21
to Embebidos32

Hola a todos como estan ?

 

Estoy trabajando en un proyecto con una raspberry y cada 5 ms tengo que enviar datos por el spi y en las primeras pruebas use como clock del spi 700 khz, pero me di cuenta de que muchas veces en el bus del spi no tenía datos y tampoco clock. Conforme fui bajando la frecuencia empecé a dejar de perder datos en el bus spi.

 

Tambien me pasa algo parecido con el gpio si  quiero subir y bajar muy rápido un pin con una raspberry pi de forma repetitiva algunos de los ciclos los pierdo. 

 

Estoy programando en c, para el gpio estoy usando la librería gpiod y con el spi me base en el ejemplo spidev_test.c.


Saludos a todos y gracias a todos por leer.


Pablo A. Llanos

unread,
Apr 22, 2021, 1:39:57 AM4/22/21
to embeb...@googlegroups.com
Hola Jorge,

Para explicarlo en términos simples, Linux no es un sistema operativo de tiempo real y no puedes saber cuánto tiempo demora la ejecución de un fragmento de código. Tu aplicación está siendo interrumpida por otras tareas de mayor prioridad y por eso no puedes obtener los timmings deseados.

Hay forma de resolver ésto parcialmente pero no es simple: Lo primero que debes hacer es implementar un driver porque ahora tu aplicación se encuentra en el user space y tiene menor prioridad que el Kernel space (kernel core y los drivers). Dentro de tu driver puedes usar timers de alta resolución para poder lograr tiempos del orden de milisegundos. Si eso no es suficiente, lo siguiente que puedes hacer es usar un Kernel RT o aplicar a tu Kernel el parche PREEMPT-RT, este parche trae algunas herramientas adicionales para decirle al context switcher del core que no interrumpa alguna sección crítica de tu código pero desde ya te aclaro que tiene sus desventajas y nunca podrás lograr HARD REAL TIME. Incluso con este parche sólo podrás lograr SOFT REAL TIME.


Si nunca desarrollaste un driver, ésta es la biblia, un libro que explica desde cero los distintos subsistemas del Kernel y cómo crear un driver básico: https://lwn.net/Kernel/LDD3/

Si necesitas HARD REAL TIME debes pensar en usar un sistema heterogéneo, por ejemplo, la RPi corriendo Linux para las operaciones de alto nivel (display, touch, conectividad) y un microcontrolador Cortex M corriendo un RTOS o baremetal code que procesa las operaciones de tiempo real (enviar los datos cada 5ms y setear un GPIO. La comunicación entre ambos la puedes hacer mediante UART, SPI, I2C, USB, etc.

Espero que te sirva la info.

Saludos cordiales,

Pablo Llanos Clariá
Embedded Linux Expert
UNITED CODERS


--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/b5c1245a-bba8-4fe6-8d67-d4ed0e9a2241n%40googlegroups.com.

Jorge

unread,
Apr 22, 2021, 3:05:10 PM4/22/21
to Embebidos32
Pablo muchas gracias por tu respuesta. Voy a estar investigando lo que me pasaste.

Saludos

Carlos Pantelides

unread,
Apr 22, 2021, 6:45:50 PM4/22/21
to Embebidos32
hace mucho había preguntado si alguien sabía si se podía usar uno de los cores con freertos (por ejemplo) y los restantes linux, no recuerdo que me habían contestado ni mucho como buscarlo ni si ha cambiado algo

saludos

Pablo A. Llanos

unread,
Apr 23, 2021, 2:05:59 AM4/23/21
to embeb...@googlegroups.com
Sí Carlos, es posible. 

Hay dos formas para hacerlo:

1. La más simple es utilizar un Hypervisor. Un Hypervisor es como una máquina virtual, la ventaja de esto es que es fácil implementarlo (comparado con la otra opción) pero, obviamente, tiene la desventaja que hay un consumo de recursos adicional.

2. La vía difícil (pero la más eficiente desde el punto de vista del uso de recursos), puedes modificar el bootloader (u-boot) y hacer una asignación estática de los cores, memoria, IRQs, etc. Esto requiere un gran conocimiento de la plataforma y bastante experiencia portando BSP. Por ejemplo, adjunto a este mail, hay un paper de EVIDENCE donde explica como instalar Linux y Erika Enterprise RTOS en un procesador iMX6 Dual-Core de NXP.

Otra alternativa es utilizar una pastilla que contenga un application processor y un RTU (todo en la misma pastilla). Por ejemplo, el iMX8QM (enlace) tiene 2x Cortex A72, 4x Cortex A53, 2x Cortex M4F, 1 DSP y 2x GPUs Vivante GC7000. En este procesador puedes usar Linux y RTOS en forma nativa sin un Hypervisor. El RTOS corre en los dos cores Cortex M4F y el resto de los recursos los utiliza Linux. Tiene un gran números de ventajas, el propio fabricante provee el bootloader y todas las herramientas nativas para implementar un sistema heterogéneo sin usar un Hypervisor. Hay varios mecanismos para transferir información entre los OS, no necesitas utilizar un puerto externo (como SPI, I2C, etc) evitando así todos los problemas de cualquier comunicación (sincronización, ruido, ACK, etc).

Les comparto una foto del KIT de desarrollo del iMX8 Quad Max, precisamente lo compré para probar lo que estamos discutiendo en este hilo y ha sido una muy grata experiencia. Hace aproximadamente un mes hubo un Webinar,si alguien le interesa aquí está la presentación y la grabación del Webinar. En la página 34 de la presentación hay una breve introducción sobre el uso del RTOS en los Cores M4F.

IMG_20210423_084141.jpg

Saludos cordiales,

Pablo Llanos Clariá
Embedded Linux Expert
UNITED CODERS

automotive_multicore_solution.pdf

Carlos Pantelides

unread,
Apr 23, 2021, 7:35:12 AM4/23/21
to Embebidos32
Me mataste Pablo, me mostraste el caldero al final del arco iris.

Jorge, cuando termines de hacer funcionar el camino de usar un core para un RTOS, por contraste tu proyecto original te va a parecer irrelevante, jaja

Supongo que sabés buscar por vos mismo, pero por las dudas me he tomado el atrevimiento de buscar yo también aunque no tengo el tiempo y fundamentalmente la capacidad aunque sí el deseo de tomar uno de esos caminos, me imagino que el de Xen es más fácil.


Y esta parecía prometedora pero no está más y no está en cache:
Xen Hypervisor is used as a virtual machine monitor with default credit and new ... Linux running as domain 0 using four Cortex-A7 cores,. • FreeRTOS running as ... tick interrupt in FreeRTOS operating system (a part of ARM. Generic Timer ...

Se mudó a


Perdón por lo metiche, saludos

Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/UT5rtJ-Ul1E/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/CAFvB5gM%3DPSJj5252kQRR9fn7QMMdM7xPxN1gtswFdtDgQxFDmg%40mail.gmail.com.


--
Reply all
Reply to author
Forward
0 new messages