Firmware V2: Standard de C, CFLAGS y ciclo de pruebas previo a un pull request

[Carlos Pantelides]

Hola

1) Firmware V2 me está fallando por que hay código c99. ¿La idea sería adaptar el código a ansi C o usar c99?

El documento [1] del 2014 entiendo dice C99.


2) Asumiendo usar c99 y buscando el punto óptimo de inserción de "std=c99", "git grep CFLAGS" con un poco de edición cosmética me trae:

etc/target/lpc11u68.mk:CFLAGS    := -Wall -ggdb3 -mthumb -mcpu=cortex-m0 -fdata-sections -ffunction-sections -fmessage-length=0 -fno-builtin
etc/target/lpc1769.mk:CFLAGS     := -Wall -ggdb3 -mthumb -mcpu=cortex-m3 -fdata-sections -ffunction-sections -c
etc/target/lpc4337_m0.mk:CFLAGS  := -Wall -ggdb3 -mthumb -mcpu=cortex-m0 -fdata-sections -ffunction-sections
etc/target/lpc4337_m4.mk:CFLAGS  := -Wall -ggdb3 -mthumb -mcpu=cortex-m4 -fdata-sections -ffunction-sections -mfpu=fpv4-sp-d16    -mfloat-abi=softfp
etc/target/lpc54102_m0.mk:CFLAGS := -Wall -ggdb3 -mthumb -mcpu=cortex-m0 -fdata-sections -ffunction-sections -fmessage-length=0 -fno-builtin
etc/target/lpc54102_m4.mk:CFLAGS := -Wall -ggdb3 -mthumb -mcpu=cortex-m4 -fdata-sections -ffunction-sections -mfpu=fpv4-sp-d16 -mfloat-abi=softfp


¿Algún motivo por el cual -Wall, -ggdb3, -fdata-sections, -ffunction-sections (según [2] entiendo que es independiente del target) y eventualmente std=c99 no estén en el Makefile?

Entiendo las demás opciones pues podría claramente haber algún target que no sea arm o tenga alguna característica especial.

3) Supongamos que pongo el std=c99 en Makefile o target/xxxx y quiero luego hacer un pull request responsable, siguiendo las instrucciones de [1] que me llevan a [3], debería ejecutar

make mocks

y luego

make tst_...

pero en Firmware_V2 no hay tal cosa, ¿cuál sería el camino?

Saludos y gracias

Charlie


[1] http://www.proyecto-ciaa.com.ar/devwiki/doku.php?do=export_pdf&rev=0&id=desarrollo:firmware:caracteristicas_fw

[2] https://elinux.org/Function_sections

[3] http://proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:firmware:unit_tests

[Eric Pernia]

Buenas noches Charly.

Desde Firmware v2 y luego en el v3 hemos ido adaptando y cambiando muchos requerimientos de los que figuran allí para el v1 por diferentes motivos.
Por un lado no se contnuó con la interfaz Posix y pasamos a la sAPI. Por otro todavía muchas cosas de Fv1 no se han pasado a Firmware v2 como el framework de tests unitario y el de CI, estamos viendo alternativas pero estamos cortos de desarrolladores.

Para saber que opciones tiene Firmware X fijate los targets del Makefile, si lo abrís con Embedded IDE te los muestra como botones.

En Fv1 son:



 

En Fv2:

En Fv3 no solo va a haber C si no que también empezamos a dar soporte a C++. Ambos con las últimas características. Los targets actualemente son:

En Fv2 se trató de empezar con lo mínimo para mejorar muchas cosas y actualizar otras. Mucho antes que se termine lo mínimo indispensable empezó a ser muy usado por la sAPI y los requerimientos de los usuarios van mucho más rápido de lo que damos abasto a desarrollar.

Fv3 se está haciendo con la idea de que se puedan generar proyectos directamente según la placa elegida, dejando solamente lo que le concierne a esa placa en el proyecto del usuario para que no sea la cosa gigantezca que es FV1. De paso si tocas alguna biblio apra un uso particular no la rompes para todos los otros proyectos. Si es un cambio grande yqueres que aplique a todos lo agregas como una nueva versión de la biblioteca.
 
La idea es armar un Wizzard de proyectos y manejar las dependencias de bibliotecas con versiones. Habría un repo por arquitectura y otro con bibliotecas independientes del hardware, el Wizzard tomaría de ellos o de una copia local para generarte un proyecto.

Aunque está verde por falta de gente.

Lo más actual de eso lo estamos usando para la especialización de la UBA y en la amteria que doy en UNQ y lo tengo acá:

http://github.com/epernia/cese-edu-ciaa-template/

Nos falta alguien que se encargue de mantener el tema de testing y CI, hay cosas que se pueden testear sin hardware, como si compila o no y otras que se requiere si o si hardware conectado para hacer CI.

No se abandona nada del trabajo previo pero necesitamos avanzar con pequeños pasos más firmes hasta que contemos con más gente para paralelizar tareas.

Mi trabajo actualmente se centra en actualizar la sAPI de la v 0.x.y a 1.x.y y que esa sAPI esté disponible para las 4 placas que se venden actualmente y sea igual programar con cada una de ellas, Martín está colaborando en el diseño de la sAPI 1.x.y. También entre ambos estamos viendo la infraestructura de FV3 y eso es lo que tenemos hasta ahora.

Con el wizzard de proyectos y la sAPI afilados es mas fácil que se crezca en bibliotecas de periféricos externos y en usuarios ya que va a haber un escalón mucho más chico para el ingreso de usuarios nuevos. Luego de eso nos podemos preocupar por el usuario especializado que usa testing y CI y en esas herramientas, que en general ya tiene las propias.

Abrazo.
Eric.

--
Has recibido este mensaje porque estás suscrito al grupo "CIAA-Firmware" 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 ciaa-firmware+unsubscribe@googlegroups.com.
Visita este grupo en https://groups.google.com/group/ciaa-firmware.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Eric Pernia]

Para poner las cosas en perspectiva es importante ver también la lista de ejemplos y bibliotecas.

Ejemplos Fv1:

• adc_dac
• baremetal
• blinking
• blinking_echo
• blinking_lwip
• blinking_modbus_master
• blinking_modbus_slave
• blinking_multicore
• rtcs_example
• rtos_example
• SimonSays
• sleeping_example

Bibliotecas Fv1:

• base
• ciaak
• drivers
• GPIO
• ADC / DAC
• Ethernet
• Flash
• UART  
• libs
• modbus
• multicore
• plc
• posix
• rtcs
• rtos (FreeOSEK)
• systests
• update

Ejemplos en Fv2:

Bare-metal with sAPI library examples

• GPIO:
  • gpio_01_switches_leds: each switch drives the upper led.
  • gpio_02_blinky: the simply led blinky with a blocking delay.
  • gpio_03_blinky_switch: led blinky with a with a non-blocking delay, to allow you to respond to a switch at the same time.
  • gpio_04_led_sequences: led sequences by using a non-blocking delay.
  • keypad_7segment_01: Drives a keypad and 7 segment display.
  • lcd_01: Drives an LCD display.
• UART:
  • uart_01_echo: UART echo, it respond the same that you send from PC.
  • uart_02_receive_string_blocking: Waits until receive a certain pattern String in a UART or timeout expire (blocking code).
  • uart_03_receive_string: Waits until receive a certain pattern String in a UART or timeout expire (non-blocking code).
• Printf
  • stdio_01_printf_sprintf: printf() and other similar standard C libray functions.
• ADC, DAC:
  • adc_dac_01: ADC and DAC example.
• TIMER, RTC:
  • cycles_counter_01: clock cycles counter functions, only work in debug mode. Allows execution time trazability.
  • tick_01_tickHook: Periodic tick function (interrupt-based) with periodic callback.
  • rtc_01: RTC peripheral to have date and time clock.
  • pwm_01: PWM applied to LEDs.
  • pwm_02_rgb_controller_uart: RGB LED example.
  • servo_01: Servomotor PWM control example.
• External peripherals:
  • I2C Magnetometers. In Chinese GY-273 module you can have one of this magnetometers, that have the same pinout but different register map. To difference them see the chip, ignore the board serigraphy:
    • i2c_01_hmc5883l: HMC5883L magnetometer.
    • i2c_02_qmc5883l: QMC5883L magnetometer.
  • dht11_01: Humidity an Temperature sensor.
  • ultrasonicSensor_HCSR04_01: HC-SR04 utrasonic distance sensor.
  • spi_01_sdCard_fatFileSystem: ADC logging in a SD/MicroSD Card (SPI connected) by using a FAT File System (ChanFS).
  • WiFi ESP01 (ESP8266) module:
    • 01_uart_bridge: Use this to send AT commands directly to ESP01 module.
    • 02_http_server: Embedded web Server to see sensor values.
    • 03_thingspeak: Send data to thingspeak dashboards.

Embedded Operating Systems with sAPI library examples

• Cooperative O.S. (see M.J. Pont's book at https://www.safetty.net/publications/pttes )
  • scheduler_01_seos: Cooperative O.S. introduction.
  • scheduler_02_seos_background_foreground: Cooperative O.S., foreground-background.
  • seos_Pont2014_01: SEOS Cooperative O.S. from M.J. Pont (2014).
  • seos_pont_02_microwave: SEOS Cooperative O.S. from M.J. Pont (2014), microwave example.
• FreeOSEK
  • freeOSEK_01_blinky: Blinky led with freeOSEK RTOS.
• FreeRTOS
  • freeRTOS_01_blinky: Blinky led with freeRTOS RTOS and sAPI.
  • freeRTOS_02_Queue: Queue management with freeRTOS and sAPI.
  • freeRTOS_03_ChanFatFS_SPI_SdCard_ADC_log: ADC logging in a SD/MicroSD Card (SPI connected) by using a FAT File System (ChanFS), freeRTOS and sAPI.
  • freeRTOS_book: Richard Barry's book examples with FreeRTOS and sAPI:
    • EXAMPLE001: Creating tasks
    • EXAMPLE002: Using the task parameter
    • EXAMPLE003: Experimenting with priorities
    • EXAMPLE004: Using the Blocked state to create delay
    • EXAMPLE005: Converting the example tasks to use vTaskDelayUntil()
    • EXAMPLE006: Combining blocking and non-blocking tasks
    • EXAMPLE007: Defining an idle task hook function
    • EXAMPLE008: Changing task priorities
    • EXAMPLE009: Deleting tasks
    • EXAMPLE010: Blocking when receiving from a queue
    • EXAMPLE011: Blocking when sending to a queue or sending structures on a queue
    • EXAMPLE012: Using a queue set
    • EXAMPLE013: Creating one-shot and auto-reload timers
    • EXAMPLE014: Using the callback function parameter and the software timer ID
    • EXAMPLE015: Resetting a software timer
    • EXAMPLE016: Using a binary semaphore to synchronize a task with an interrupt
    • EXAMPLE017: Using a counting semaphore to synchronize a task with an interrupt
    • EXAMPLE018: Centralized deferred interrupt processing
    • EXAMPLE019: Sending and receiving on a queue from within an interrupt
    • EXAMPLE020: Re-writing vPrintString() to use a semaphore
    • EXAMPLE021: Re-writing vPrintString() to use a gatekeeper task
    • EXAMPLE022: Experimenting with event groups
    • EXAMPLE023: Synchronizing tasks
    • EXAMPLE024: Using a task notification in place of a semaphore, method 1
    • EXAMPLE025: Using a task notification in place of a semaphore, method 2

Statecharts with sAPI library examples

LPC Open examples

• LPC4337 LPC Open:
  • adc_fir_dac
  • asm
  • blinky
  • blinky_ram
  • blinky_rit
  • blinky_input
  • boot: LPCBootloader example
  • mpu
  • start_m0
  • trilat
  • i2c
  • pwm
  • sd_spi
  • usb_cdc
  • usb_msc_host
  • usb_rom_cdc
  • statechart
  • tcpecho
• LPC4337 LPC Open and RTOS:
  • freertos_blinky
  • blinky_osek
  • multicore

Bibliotecas Fv2:

• base
• board
• chip
• ciaa
• dsp
• fatfs (esta y la de abajo deberían mergearse en una sola)
  
• fatfs_ssp
• freertos
• lpcusblib
• lwip
• osek (FreeOSEK)
• sapi

Asi que si bien se han sacado herramientas y algunas bibliotecas (la que más se extraña es la de Modbus, que dependia de Posix) se han agregado muchas más bibliotecas y ejemplos para hacer más accesible el proyecto a la comunidad. En Fv2 además de FreeOSEK ofrecemos FreeRTOS que ahora también dispone de una versión estática.

Saludos.

Eric.

[Eric Pernia]

Voy apegar todo esto en otro mail con un asunto relvamiento de estado de Firmware o algoa asi asi queda el resumen bien en el grupo.

[Carlos Pantelides]

Gracias Eric por la excelente respuesta y por la cadena aparte.

Entonces por completitud:

1) Firmware V2 me está fallando por que hay código c99. ¿La idea sería adaptar el código a ansi C o usar c99?

entiendo c99

 

 2) Asumiendo usar c99 y buscando el punto óptimo de inserción de "std=c99", "git grep CFLAGS" con un poco de edición cosmética me trae:

por ahora va en cada target


3)  [si] quiero luego hacer un pull request responsable [que tests debería hacer] ¿cuál sería el camino?

No test provistos aun

[Eric Pernia]

Respondo entre líneas.

El lun., 23 de abr. de 2018 07:50, Carlos Pantelides <carlos.p...@gmail.com> escribió:

Gracias Eric por la excelente respuesta y por la cadena aparte.

Entonces por completitud:

1) Firmware V2 me está fallando por que hay código c99. ¿La idea sería adaptar el código a ansi C o usar c99?

entiendo c99

Aquí podríamos incluso usar c 11 todos los compiladores de las placas que tenemos lo soportan.

 

 2) Asumiendo usar c99 y buscando el punto óptimo de inserción de "std=c99", "git grep CFLAGS" con un poco de edición cosmética me trae:

por ahora va en cada target


3)  [si] quiero luego hacer un pull request responsable [que tests debería hacer] ¿cuál sería el camino?

No test provistos aun

Sería testear manualmente con placa en mano los cambios que hagas. Por ejemplo si tocas el driver de uart probarlo con varios programas que usen cada función. 

De hecho cada release de fv2 implica probar todos los ejemplos de las cosas que cambiaron frente a la release anterior con cada placa y periférico.

Con la fv1 ha pasado que teniendo tests y todo y compilando los programas no andaban por un error de incializacion de click y cosas similares, asi que es laborioso pero hasta no tener todo un hardware super confiable para interactuar con las placas y que analice los resultados es la mejor manera probar que anden los ejemplos.

Donde si servirían los tests unitarios son en las funciones de alto nivel que no le pegan al hardware. Por ejemplo buffers o cosas similares que se pueden testear incluso compilando c para la PC. Ahí si se podría automatizar sin intervención de hardware externo.

Saludos.

Eric.

--
Has recibido este mensaje porque estás suscrito al grupo "CIAA-Firmware" 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 ciaa-firmwar...@googlegroups.com.