Get best of the week

¿Cuál es el nuevo nRF Connect SDK para Nordic? ¿Evolución, revolución o alternativa?

La semana pasada, Nordic Semiconductor agregó soporte de la serie nRF52 al nRF Connect SDK.



La pregunta principal que la mayoría de las personas tiene es qué es y por qué es importante. Esta pregunta es especialmente relevante para aquellos que tienen experiencia con el SDK nRF5, y hay muchos de ellos.

Noto de inmediato que el artículo está escrito principalmente para aquellos que usan enfoques tradicionales en el desarrollo del nivel Cortex-M o dispositivos cercanos. Por lo tanto, algunas definiciones y analogías pueden no parecer completamente correctas desde el punto de vista de aquellos que trabajan en un alto nivel (mira lo que está sucediendo en el lado de Linux), pero será más fácil de entender para aquellos que recién comienzan de esta manera.

Comentarios y aclaraciones son siempre bienvenidos.

Un poco sobre quién es nórdico y cómo les está yendo bien ahora
Nordic . , , Bluetooth Low Energy, 90% . : Starline, Pandora, Scher-Khan . Redmond, Ready4Sky. . 2 .

Nordic Semiconductor 40%, 2.5 , (TI). , . , Samsung Xiaomi Nordic , , .

, Nordic, , . nRF5x STM ( ).

:

  • ( )
  • SDK
  • ( )
  • Altium

, Nordic Semiconductor .

Aquí surge la pregunta principal, ¿por qué se lanzó el nuevo SDK y en qué se diferencia del actual? Si es así, todo está bien con la solución actual.

El SDK nRF5 actual funciona sobre la base de una cola simple, y en la mayoría de los casos esto es suficiente para implementar casi cualquier tarea (aunque algunas empresas todavía usan sus propios SDK, pero estas son excepciones a las reglas). El nuevo nRF Connect SDK utiliza un enfoque radicalmente diferente basado en Zephyr RTOS. Considere las diferencias con más detalle.
RTOS (RTOS) conlleva ciertas ventajas y desventajas conocidas. Estos últimos incluyen:

  • gastos generales adicionales para mantener el SO
  • Gran complejidad de desarrollo en proyectos simples.
  • mayor complejidad de construcción

El resto de los RTOS son:

  • mayor confiabilidad debido al control de flujos individuales

Dentro de Nordic, esto se ha vuelto interesante y relevante desde la introducción del nuevo sistema en paquete (SIP) con LTE Cat-M / NB-IoT / GPS, la serie nRF91. Este SIP tiene un mayor rendimiento debido al nuevo núcleo Cortex-M33 y otros requisitos para el componente de red, que apareció debido a la transición de BLE a redes celulares. Otra innovación aquí fue el módem SDR, que funciona en un núcleo separado y con el que era necesario organizar la interacción internuclear. Por primera vez, el SDK basado en RTOS apareció aquí, y para aquellos que encontraron por primera vez un nuevo enfoque, planteó una serie de preguntas, comenzando desde la etapa de preparación. También se lanzó un asistente especial para el ensamblaje correcto del entorno de desarrollo: Asistente de inicio. Él le dice qué componentes necesita instalar (hay muchos de ellos, ver más abajo) y verifica que todo esté instalado correctamente.

imagen

Desde este punto de vista, podemos comparar la transición a Zephyr con la aparición del primer ARM Cortex-M en masa y la transición a 32 bits. Ahora la mayoría usa MK de 32 bits como los principales, sobre los cuales hay un artículo sobre Habré. También habla sobre la transición, que inicialmente parecía innecesariamente complicada. Pero con el tiempo, casi todos llegaron a la conclusión de que esto se ha convertido en el estándar.

Vale la pena señalar que Zephyr OS no es el único RTOS que se ejecuta en chips nórdicos. Ejemplos de proyectos con FreeRTOSDisponible en SDK v.11 a partir de 2016, e incluso antes en SDK v.9 había soporte Keil RTX para la familia nRF51 (2015). Sin embargo, antes eran funciones más experimentales y los fabricantes de RTOS proporcionaron mayor apoyo. Lo cual, en principio, es cierto ahora.

El soporte no oficial de Zephyr para las familias nRF5x apareció en 2016 .

Zephyr Nordic decidió crear un SDK completamente nuevo en RTOS solo ahora.

Hay una serie de requisitos previos para esto:

  • Una serie de tecnologías se heredan de Linux:

    • trabajar con flujos, colas en tiempo real (especialmente importante para protocolos dependientes del tiempo como BLE)
    • bibliotecas para redes y seguridad
    • modelo de descripción de hardware flexible con optimización energética
    • bibliotecas para trabajar con periféricos (sensores, etc.)

  • :




    • , Nordic,

  • ( )
  • ( ) . , , .

Para comprender cómo se han producido cambios dramáticos, el diagrama estructural de la documentación oficial es muy adecuado. El gris indica los componentes que forman parte de Zephyr.

imagen

En la práctica, al implementar este enfoque, surgen una serie de problemas cognitivos. Los desarrolladores acostumbrados al producto y las soluciones experimentan disonancia con una gran cantidad de cambios.

Considere la versión de desarrollo en Windows, ya que causará más preguntas con respecto a aquellos que están acostumbrados a desarrollar en Linux.

Se requieren los siguientes paquetes:

  • Chocolatey (administrador de paquetes)
  • Git (sistema de control de versiones)
  • Ninja (sistema de construcción orientado a la velocidad)
  • CMake (sistema de construcción de alto nivel)
  • DTC-MSYS2 ( (device tree))
  • GPerf ( )
  • west ( )
  • pip ( Python)
  • Python3
  • GNU Arm Embedded Toolchain (GCC, GDB ARM)

Para alguien que se enfrenta a un conjunto similar de utilidades por primera vez, puede parecer que todo es innecesariamente complicado y podría usarse el viejo paradigma, que los enfoques existentes para el desarrollo son bastante efectivos. Sin embargo, si miras más profundo, entonces todo se vuelve mucho más interesante.

Por ejemplo, Chocolatey y pip le permiten instalar todos los paquetes necesarios a través de la consola para OS y Python, respectivamente. Y Python, como la mayoría del software en cuestión, se coloca en un comando:

hoco install python xxx

También se actualiza con un comando:

choco upgrade all

El enfoque es un poco inusual para los usuarios de Windows, para aquellos que están familiarizados con los administradores de paquetes de consola en Linux (apt, zypper, etc.), nada nuevo. A menudo he notado la situación de que los desarrolladores de software para MK actualizan el software solo cuando reinstalan el sistema operativo en una PC. Sobre por qué es malo no hablaremos, solo noto que aquí este problema se resuelve automáticamente.

Las innovaciones en el campo de la configuración y montaje de proyectos son mucho más interesantes.

Ninja fue diseñado y posicionado como un reemplazo para la marca y se centró en la velocidad de construcción. Es especialmente bueno en aplicaciones cuando es necesario reconstruir proyectos con un montón de archivos pequeños, donde no hubo cambios. El efecto puede ser un orden de magnitud, o incluso dos, ver pruebas .

Cmakea su vez, permite generar archivos de configuración para Ninja en un lenguaje de alto nivel (scripting) para la plataforma en la que se realizará el ensamblaje. Acerca de Cmake se puede leer en Habré, por ejemplo, aquí , aquí y aquí ,
GPerf genera una tabla de punteros, lo que ahorra memoria, consulte el paso 3 del ensamblaje a continuación.

También debemos prestar atención a un nuevo enfoque para la descripción del hierro. Apareció Devicetree , describiendo la estructura de hardware del dispositivo. Este es un resultado directo del soporte de Zephyr por parte de la Fundación Linux.

Las ventajas son que la descripción del hardware ahora está en un archivo .dts separado, que tiene una estructura simple, es fácil de modificar y, como resultado, transferir el código entre diferentes familias de chips.
Como ejemplo, por lo que puedo ilustrar todo, daré el dtsi básico en nRF52840 , que a su vez se utiliza en la descripción de la placa nRF52840-DK nrf52840dk_nrf52840.dts
. El número de placas base compatibles con Zephyr ya supera los 200 .

Como se dijo anteriormente, Nordic lanzó por primera vez Zephyr en la serie nRF91, luego en el nRF53, y ahora finalmente ha alcanzado el nRF52 más masivo.

Cambiar a RTOS permite a su vez resolver el problema de adaptar el código para el nuevo hardware. Incluso entre los chips de una familia, la transición requería ciertos recursos del lado del desarrollo, si iba acompañada de una transición a otro dispositivo flexible (la biblioteca BLE precompilada). Sin mencionar la transición, por ejemplo, de las series 51 o 91 a 52, cuando la plataforma de hardware en sí misma cambia significativamente. Ahora esta tarea se resolverá mucho más fácil y más rápido.

El hierro en Nordic se mejora constantemente, pero esto debe escribirse por separado. En el marco de este artículo, solo podemos notar que el enfoque está en la integración con RTOS, seguridad, eficiencia energética y mejora del canal de radio (BLE 5.2). Gracias puede decir que el doble núcleo Cortex-M33, ARM y ARM Cryptocell TrustZone.

Para construir devicetree usadosDevice Tree Compiler , que forma parte de MSYS2 (sistema de compilación mejorado basado en Cygwin y MinGW-64).

La segunda parte de la configuración del proyecto está en KConfig (Kernel config), que también se heredó de Linux. Le permite seleccionar los bloques necesarios a través de una interfaz gráfica y establecer parámetros para el ensamblaje para una tarea específica, lo cual es especialmente importante en las condiciones de recursos limitados de los sistemas en un chip.

Puede usar utilidades tradicionales como menuconfig, o en el marco de Segger Embedded Studio (el IDE oficial recomendado) hay una interfaz integrada que se puede iniciar a través del elemento de menú correspondiente: Proyecto> Configurar proyecto SDK nRF Connect



A continuación se presenta un ejemplo de configuración de proyecto con SSL / TLS basado en nRF9160. Como puede ver en él, puede configurar tanto las características de hardware del proyecto (plataforma, número de subprocesos, módulos de kernel enchufables) como software (claves, direcciones, etc.).





Considere las etapas del montaje del proyecto: hay cinco en total:

  • Configuración : procesamiento preliminar de todas las configuraciones (devicetree, KConfig), en la salida obtenemos archivos de encabezado que describen el hardware y la configuración para Ninja
  • Premontaje (I) : procesamiento de estructuras a alto nivel, compilación de archivos y compensaciones del sistema (desplazamiento), creación de tablas de llamadas
  • Ensamblaje inicial (II) : compilación de los códigos fuente principales y empaquetado en archivos, vinculando
  • (III) — (GPerf),
  • - (IV) — hex, bin

Puede leer más sobre el sistema de ensamblaje Zephyr con imágenes en la documentación oficial . Hay bastante texto e imágenes, por lo que no consideraremos los detalles en este artículo.
Es importante comprender que las herramientas utilizadas aquí no son un sustituto del preprocesador C (cpp) y el enlazador C (ld). Ambos se utilizan en todas las etapas, excepto el procesamiento posterior. Sin embargo, el resultado de su trabajo está sujeto a mejoras adicionales, que permiten reducir significativamente el tiempo de montaje y los requisitos de memoria.

No puede comparar directamente los resultados de los programas creados en dos SDK. Dado que las bibliotecas y los enfoques son muy diferentes y aún no existen tales pruebas. Definitivamente, se puede decir que la solución se siente bien en chips medios y de gama alta en la línea (nRF52832 y superior), y queda una gran reserva de recursos. Sin embargo, no se puede decir que el nuevo SDK no sea aplicable en chips más jóvenes como nRF52810. Es necesario considerar el problema con más detalle.

Volviendo a la pregunta en el título del artículo, podemos decir que este paradigma es definitivamente una nueva realidad. Lo que a primera vista trae mejoras significativas. Al menos 2 nuevas familias de chips del mayor fabricante de BLE del mundo trabajan con precisión y solo con esta tecnología y no se espera ningún retorno. En mi opinión, esta es una revolución que se preparó de antemano.

Actualización : El 14 de mayo, Nordic celebró un seminario web sobre el nuevo SDK en el que anunció que todas las versiones de BLE anteriores a la 5.0 solo estarán disponibles en el SDK nRF Connect. En consecuencia, Directino Finding, también conocido como AoA / AoD (BLE 5.1) y LE Audio (BLE 5.2), que muchos están esperando, traerá consigo nuevas herramientas este año y los cambios en el desarrollo llegarán antes de lo previsto.

Recomendaciones:

  • Los cambios son radicales, el código que funciona con el SDK nRF5 actual no es compatible con el nuevo (SDK nRF Connect)
  • Cambiar a RTOS con Devicetree y KConfig le permite obtener un nivel adicional de abstracción para el hardware, lo que a su vez acelera significativamente el desarrollo y la transferencia del proyecto a una nueva plataforma.
  • Cambiar a Zephyr brinda soporte para una gran cantidad de protocolos y bibliotecas listas para usar; para los dispositivos IoT, los más interesantes son las funciones de red y seguridad, donde Linux es tradicionalmente fuerte
  • Zephyr OS utiliza una serie de herramientas durante el ensamblaje, que pueden reducir significativamente el tiempo de ensamblaje y los requisitos de memoria, lo cual es especialmente importante para las aplicaciones integradas
  • El nuevo SDK permite el uso de desarrolladores de alto nivel, que están mucho más en el mercado que los de bajo nivel. Esto resuelve el problema del personal y el aumento de la cuota de mercado.

More articles:


All Articles