Que Modulos necesitamos

BSP
API
OS
Compiler Linker and Types (HW Specific)
Bootloader

y definir que necesita cada capa de la capa inferior

-Wall -Werror no deja compilar algunos archivos de unity. Porvisoriamente saque -Wall -Werror pero hay que volver a agregarlo haciendo reglas distintas de compilacion para los archivos de untiy donde no nos importan los warnings y los archivos de la ciaa donde SI NOS importan los warnings.

Este ticket esta para resolver el problema y volver a agregar -Wall -Werror en el makefile en la parte de unit testing.

el proyecto va a necestiar algún tipo de documentación además de doxygen. Docbook o latex.

Importante sería que se pueda generar pdf (para quein lo quiere bajar e imprimir) y html para quein lo quiera ver online y además poder mostrar la guia de referencia en la página.

Port ciaa to LPC4337

agregar ARCH/CPUTYPE/CPU al make info

implementar ciaaSerialDevices

Como corremos el código creado en Ladder. Este va a ser un tema importante, necesitamos expertos en el tema.

Hay un standard abierto, pero no recuerdo el nombre, Pablo me lo comento ayer. Quienes son los expertos en el tema?

Que funcionalidades necesitaria un Interpreter de Ladder de las capas inferiores?

implementar ciaaPOSIX_stdlib

allow following options:

/* Copyright 2014, ACSE & CADIEEL

con Ezequiel definimos la version inicial del Firmware

implementar ciaaDevices

Los archivos generados de OSEK dependen del oil.

Se debe agregar en Makefile la dependencia entre .oil y los archivos generados para que la generación sea automática si es necesario y así no es más necesario el comando

make generate

some tests are not compiling.
the variable of the test makefiles:
_TST_MOD
shall be evaluated and those mocks shall be compiled/linked with the test.

I guess in posix this depends on the arch size, in 64 bits shall be uint64.

This has to be clarified and if needed the interfaces shall be improved.

CUNIT? Un Unit propio? Un TestSuite?

CUnit solo corre en la pc, por lo que recomendaria crear un unit similar que no sirva para correr los tests en la pc y en el firmware.

De ejemplo propongo mirar:
https://sourceforge.net/p/opensek/code/HEAD/tree/trunk/FreeOSEK/TestSuite

Esta testsuite va guardando los resultados de los test en una variable, luego con el debugger se puede leer la variable y en la pc saber como salieron los tests..

Lo que dice el título, por ejemplo se podrian documentar en:

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=coding_guidelines

Por ejemplo:
CIAAFirmware/examples
CIAAFirmware/examples/example1
CIAAFirmware/examples/example2
CIAAFirmware/out
CIAAFirmware/out/bin
CIAAFirmware/out/lib
CIAAFirmware/out/doc --> eg. for Doxygen
CIAAFirmware/modules
CIAAFirmware/modules/bsp
CIAAFirmware/modules/os
CIAAFirmware/modules/...
CIAAFirmware/externals/ --> eg. FreeRTOS FreeOSEK, otras cosas?
CIAAFirmware/make

There may be some issues with the port to posix regarding the hw timers

This commit shall be re checked.

Para el proyecto deberiamos ir pensando en un Continuous Integration al menos a mediano plazo.

Yo conozco Jenkins pero no es algo wow, hace lo que tiene. Otras opciones?

En google lo primero que encontre de servers: http://www.cloudbees.com/ pero no lo conozco.

Para el tema de los slaves deberian estar en la CIAA, CADIEEL o ACSE, no se si existe esa posibilidad?

implementar ciaaPOSIX_stdlib

Implementar printf

Lenguaje debria ser basado en IEC61131-3

La tarea tiene que ser en comun acuerdo con ciaa Software.

basado en https://gist.github.com/wjrogers/1016065

por ejemplo:
modules/platform/Types.h <- los genericos
modules/platform/cortexM4/Types_Arch.h
modules/platform/x86/Types_Arch.h
modules/platform/x86_64/Types_Arch.h

y types.h deberian incluir Types_Arch.h y con las makefiles deberiamos incluir el correcto, les parece?

Deberian crear los siguientes tipos

uint8
uint16
uint32
uint64
sint8
sint16
sint32
sint64

uint8f
uint16f
uint32f
uint64f
sint8f
sint16f
sint32f
sint64f

o algo similar.

Types.h podria definir algunos macros como ser:

TRUE
FALSE

E_OK
E_NOT_OK

rename sem_* functions to ciaaPOSIX_sem_*

Que tipo de make es el más adecuado, quien sería el responsable del tema?

implement make info_ext_

as for info_platforms provide a info_ext_platforms.

assert. colocarlo para detectar tempranamente errores en debug

add support of OpenOCD to makefile

maths
circular buffer
etc

Podemos basarnos en: http://libmodbus.org/download/? Implementarlo de cero?

Y no al lado de los .c
Como no pude resolver el probelma y no queria invertir más tiempo es que los .o se compilan el el mismo directorio a los .c.
Si pude compilar en out/obj/.o lo que no pude es hacer entender a make la dependencia entre un archivo .c en un subdirectorio y el mismo nombre de archivo.o en out/obj, por ende deje que los .o y los .c esten en el mismo directorio.

No muy lindo pero funciona, debe ser mejorado en el futuro.

add to all header files after the includes but before and after anything else:

#ifdef __cplusplus
extern "C" {
#endif

/* content */

#ifdef __cplusplus
}
#endif

/* TODO comment to allow the module tests to compile ... #29 */
// typedef signed long long int64_t;

implement string library

change the license
adapt the generator
remove memmaps, and use ciaaPOSIX_stdint.h as types and not the internal type system.
etc.

rename mtest to utest (unit test)
and use mtest for module tests (a type of unit test but of multiple files)

implement first module test for stdio

3 spaces shall be used instead of tabs

conditional definition of NULL in osek to allow compilation with other modules

Necesitamos ver como manejar el tema de configuration y variation management... :(

• For example ciaaPOSIX_stdio.c calls PreCallService, this shall only be done if OSEK is present... :(

In general: we need a solution for variant management, like OIL or a header file for configuration. Ideas?

Como configuramos todos los drivers (los macros por ejemplo), como sabe el ciaak_start que drivers debe inicializar?

Como hacemos con las dependencias de un modulo a otro?

Primera versión en:
https://github.com/ciaa/Firmware/blob/master/modules/template/

Para el make que armemos va a haber que preparar un paquete para los usuarios que utilicen windows (la mayoria supongo). Conoczo 2 opciones:

mingw (mas sencillo de instalar)
cygwin (más potente)

yo no uso windows, alguien que utilice windows se deberia ocupar de esto 👍

Utilizar makedepend para recompilar los archivos que sea necesario cunado un header file es modificado.

que contenga las dependencias, macros y funciones necesarias para portar ciaa firmware.

Definir finalmente el tema de la licencia:

LGPL
GPL+LinkingException
BSD
MIT

En los mails corrio mucho pero seria bueno documentar la resolución final en un ticket y cerrar el tema, cuando se cierre el tema debe ser completado en los templates: #4