thecore-embedded / thecore Goto Github PK

There are few issues exists:

• ambiguous configuration name for stm32f4xx platform: CONFIG_CONSOLE_DEVICE_NUM
• conversion algorithms are hard-coded in console streams (see istream.hpp) and cannot be reused within debug assertions.
• bypass driver lacks puts()-like routines

More likely exist. These should be fixed.

The CS43L22 is a highly integrated, low power stereo DAC with headphone and Class D speaker amplifiers. The CS43L22 offers many features suitable for low power, portable system applications.

It is also placed on stm32f4 discovery.

References:
CS43L22 datasheet

Current behavior is abort build if CppUTest library is missing. A warning should be raised instead.

When FreeRTOS is selected, configuration file is required. In most cases of simple embedded applications a default config provided by The Core is sufficient.

Pinconfig wrappers should cover following demands:

• compile-time check of repeated reconfiguration of the same pin
• batch pin configuration, when few pins within same port can be initialized together
• strong checks against garbage pin parameters usage, such as using values dedicated for pin speed when configuring pin direction
• etc.

Task is about modifying nix expressions shipped with The Core so they can be used on MacOS

Another platform must be added.

Refs:
Eval tools

We need to implement i2s support for stm32f4xx platform.
It can be done within SPI bus implementation (same controller is used for I2S in stm32f4xx).

ILI9341 is a TFT LCD Single Chip Driver with 240RGBx320 Resolution and 262K color.
It can be brought along with TFT display on the same PCB.

Refs:
Specification

Current implementation of the usart_bus platform module:

    // Configure UART
    // TODO: make configuration values be chosen at compile time
    init_struct.USART_BaudRate             = 115200;
    init_struct.USART_WordLength           = USART_WordLength_8b;
    init_struct.USART_StopBits             = USART_StopBits_1;
    init_struct.USART_Parity               = USART_Parity_No;
    init_struct.USART_Mode                 = USART_Mode_Rx | USART_Mode_Tx;
    init_struct.USART_HardwareFlowControl  = USART_HardwareFlowControl_None;

It contains hard-coded init values. The issue is about creating compile-time configuration of the particular usart bus.

See default, common and freertos semaphroe

When building The Core in one of release modes asserts stays there. It is not expected.

A lot of options like required RTOS, platforms or build mode must be tested during single travis run.

suspend() and resume() routines are convenient aliases for wfe and sev instructions respectively. This is required for implementing single-threaded semaphore in case no OS is present. Thus, spinlocks will be avoided.

Bus is inside SPI bus and related code. reinterpret_cast cannot be used in constant expressions.

Configuration class of the SPI bus uses constexpr std::uintptr_t to store DMA streams.

This must be avoided. Possible way is to deal with configuration parameters using template specialization, same as USART driver do. Difference though is that SPI DMA stream will be stored in static const variable instead of constexpr

HC-05 module is an easy to use Bluetooth SPP (Serial Port Protocol) module, designed for transparent wireless serial connection setup.

No support of BTLE in this module

Refs:
ITEAD wiki
AT command set

Currently, semaphore for FreeRTOS is just a wrapper for SemaphoreHandle_t
It can be used with restrictions of queue size which is limits how many events sempahore can accumulate.

Additional implementation required to let semaphore handle as much events as possible.

See: https://github.com/Microsoft/GSL
Simply, it will improve quality of C++ code and will help track subtle bugs.

The MFRC522 is a highly integrated reader/writer IC for contactless communication at 13.56 MHz. It can be found in a cheap RFID reader/writer modules like this.

UART is preferable as communication mode between MCU and MFRC522.
Unit tests required.

Additional implementation inside existing code is also required:

• #34 Configurable USART modes are required to support different baud rates.
• #35 EXTI driver will supply the Core with interrupts from MFRC522
• #36 FIFO read/write can be triggered while servicing EXTI IRQ. This will decrease response latency significantly.

Refs:
Datasheet.

When testing TheCore it is viable to have some reports about how good is coverage.
Here is some reference about how to do it with gcc and cmake/ctest

There are a lot of options for UB checks in GCC, described in instrumentation options document.

Some of the options must be included in the Core builds.

Currently there is no way to start new bus transfer while servicing an interrupt. This is the significant limitation which prevents designing of event-driven systems based on the Core.

Refs:
Bus xfer() method.

See sys.cpp file:

// TODO: move this to toolchain-dependent module
#if UINT32_MAX == UINTPTR_MAX
#define STACK_CHK_GUARD 0xe2dee396
#else
#define STACK_CHK_GUARD 0x595e9fbd94fda766
#endif

// TODO: move this to toolchain-dependent module
__attribute__((used))
uintptr_t __stack_chk_guard = STACK_CHK_GUARD;

// TODO: move this to toolchain-dependent module
extern "C" __attribute__((noreturn)) __attribute__((used))
void __stack_chk_fail(void)
{
    ecl::cout << "Fail!!!" << ecl::endl;
    for(;;);
}

These should be moved somewhere to better place.

See also: https://github.com/blog/1184-contributing-guidelines

Platform code cannot use ecl::cout object due to following reasons:

• Stream could not be constructed and inited when platform code executes
• Stream uses locks, which are prohibited in IRQ context
• Stream depends on a console driver, which is a part of a platform. It is a cyclic dependency and must be omitted.

So additional implementation should be made.

For now i2c bus implementation does not support error handling. Actually device can hang in case of en error or glitch on a bus.
For polling we can use timeouts for operations.
For irq - there is a separate handler for errors.

This task is about implementing a driver for http://www.instructables.com/id/BH1750-Digital-Light-Sensor/

SMBUS, The System Management Bus is a single-ended simple two-wire bus for the purpose of lightweight communication.

While SMBus is derived from I²C, there are several major differences between the specifications of the two busses in the areas of electricals, timing, protocols and operating modes.

SMBus mode is supported by I2C periphery in stm32f4xx platform. TheCore's I2C driver can be extended with new mode and separate aliases can be provided for I2C and SMBus.

Another way to implement it is to use configuration structure that define mode that will be used.

The MLX90614 is an Infra Red thermometer for non contact temperature measurements. Both the IR sensitive thermopile detector chip and the signal conditioning ASSP are integrated in the same TO-39 can.

Chip uses SMBus to communicate with host.

Blockers:

• #90 SMBus driver is required.

Following components should be included:

• fonts
• basic primitives (line, circle etc.)
• UI elements (textbox, areas etc.)
• much, much more

GNU ARM Eclipse QEMU claims to support STM32F4Discovery, so it may be worth trying it for test purposes (maybe even on Travis).

Definitions from common platform modules that used only in configure files or/and platform must be moved to platform.

Other should be placed in common modules.

TM4C12x is a cortex-m4 processor. It can be used as a part of Tiva C Launchpad.

Something that nice to have in theCore.

Subtasks:

• #163 - EXTI driver
• #164 - Console subsystem support for TM4C

Platform.cpp and irq manager provides similar functionality and must be merged.

A special driver must be crafted that will dispatch incoming interrupts from GPIO lines. It must be taken into account that 16 lines of GPIO EXTI are mapped only to 7 EXTI IRQs.
See stm32f4xx EXTI tutorial for some details.

It would be good to complete metadata and submit cpputest nix-expression upstream to nixpkgs.

These functions are implemented for FreeRTOS, but it missing in the common thread library

Such routines must be implemented.

For now i2c supports only polling and irq mode.
DMA support should be added to achieve high performance data flow

It is possible to trigger TheCore build using host compiler and get some strange errors:

[ 31%] Building C object core/platform/stm32f4xx/SPL/CMakeFiles/spl.dir/src/stm32f4xx_cryp_tdes.c.o
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c: In function ‘CRYP_TDES_ECB’:
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c:108:25: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   uint32_t keyaddr    = (uint32_t)Key;
                         ^
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c:109:25: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   uint32_t inputaddr  = (uint32_t)Input;
                         ^
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c:110:25: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   uint32_t outputaddr = (uint32_t)Output;
                         ^
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c:131:53: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
   TDES_CRYP_KeyInitStructure.CRYP_Key1Left = __REV(*(uint32_t*)(keyaddr));
                                                     ^
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c:133:53: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
   TDES_CRYP_KeyInitStructure.CRYP_Key1Right= __REV(*(uint32_t*)(keyaddr));
                                                     ^
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c:135:53: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
   TDES_CRYP_KeyInitStructure.CRYP_Key2Left = __REV(*(uint32_t*)(keyaddr));
                                                     ^
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c:137:53: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
   TDES_CRYP_KeyInitStructure.CRYP_Key2Right= __REV(*(uint32_t*)(keyaddr));
                                                     ^
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c:139:53: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
   TDES_CRYP_KeyInitStructure.CRYP_Key3Left = __REV(*(uint32_t*)(keyaddr));
                                                     ^
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c:141:53: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
   TDES_CRYP_KeyInitStructure.CRYP_Key3Right= __REV(*(uint32_t*)(keyaddr));
                                                     ^
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c:159:18: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
     CRYP_DataIn(*(uint32_t*)(inputaddr));
                  ^
/home/executor/projects/thecore/demo-example/core/platform/stm32f4xx/SPL/src/stm32f4xx_cryp_tdes.c:161:18: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
     CRYP_DataIn(*(uint32_t*)(inputaddr));
                  ^

Reason is that cross-compiler wasn't set. It is hard to notice though.

Currently we have few sensor drivers implemented. They should be covered with unit tests

And upload some examples into the test repo

The LIS3DSH sensor is popular accelerometer sensor: http://www.st.com/content/ccc/resource/technical/document/datasheet/23/c3/ea/bf/8f/d9/41/df/DM00040962.pdf/files/DM00040962.pdf/jcr:content/translations/en.DM00040962.pdf

The STM32F4Discovery has lis3dsh on board and it is easy to evaluate it.

Sensor supports I2C and SPI interfaces, has FIFO and able to trigger EXTI interrups. It is pretty good instance to provide "live" testing of many components of TheCore.

NRF24xxx is a single chip 2.4GHz transceiver with an embedded baseband protocol engine (Enhanced ShockBurst™), suitable for ultra low power wireless applications. The nRF24L01+ is designed for operation in the world wide ISM frequency band at 2.400 - 2.4835GHz.

It can be found as a part of low-cost RF modules, like this.

Official page states:

This product is not recommended for new designs. Nordic recommends its drop-in compatible
nRF24L01+ or for a System-on-Chip solution the Nordic nRF24LE1 or nRF24LU1+.

Issue must be changed if it is better to implement nRF24LE1 or nRF24LU1+ instead of NRF24L01.

Refs:
Official page
ElecFreaks WiKi
NRF24 product specification

STOR:

1. Remove attribute at memcpy (memcpy.c file) definition:

   //__attribute__((used))
   void * LIBC_FUNCTION(memcpy) (void *dst, const void *src, size_t cnt)
   {
   

2. Build advaced_demo release or minsize configuration:

   VERBOSE=1 make advanced_demo_release -j5
   

3. Observe results at the end of a build:

   <artificial>:(.text+0x108): undefined reference to `memcpy'
   <artificial>:(.text+0x45a): undefined reference to `memcpy'
   <artificial>:(.text+0x464): undefined reference to `memcpy'
   <artificial>:(.text+0x47c): undefined reference to `memcpy'
   

Workaround is to keep the used attribute.

Current clang support is old and unusable. A toolchain file must be provided, so derived projects can be built with that toolchain.

Currently there are no timers in the Core. This should be changed.

The SSD1306 is popular OLED display which can work over I2C, SPI and 6800 / 8080 parallel interfaces

The goal is to keep buildable and runable examples in sync with main repo. Multiple examples can be aggregated using ExternalProject utility from cmake. A list of demos is subject of discussion.

Including source-formatting script based on astyle.
Naming convention of the classes, functions, file names etc. must be included