[Task] - Create script to cleanup PeripheralPins.c

Create a document to gather all specifications of the behavior of the robot. Each component of it must be tested at its maximum in order to have the worst situation for investigation day. Values has to be clear.

Related epic/story: #36

Subtasks

[Task] - Script to compare pin definition in xlxs to STM32CubeMX file

Description

Develop a simple script to make sure that the design doc containing all the pins and their functions is correctly implemented in STM32CubeMX.

Related epic/story: #26

Subtasks

generate .csv file with CubeMX
parse design doc and cubemx_pintout.csv
check that all the needed pins are present
check that the definition/function/label are correct
find extraneous pins not present in the design doc

[Task] - Remove uneeded include of mbed.h

Description

A lot of headers and source files are including mbed.h.

A lot of them don't really need mbed.h but only PinNames.h for example.

Check all source files and decide if it's really needed.

Related epic/story: n/a

[Story] - Test Applications

Description

Before implementing a new functionality into the main firmware, it's usually good practice to make a small test application demonstrating the use case, how it works and open discussion to implementation before opening a PR.

This story gathers all the test apps and related discussion.

This main post will be updated with new test apps to include.

Related epic/story: n/a

Test Applications

crash reporting - mbed/crash_reporting.md - @ladislas
watch dogs - #17 - @ladislas
play video - @YannLocatelli
mcu serial number forum - @ladislas

[Epic] - Bootloader, DFU & Linker Script

A deeper understanding of the bootloader and linker script inner functioning is needed to work firmware update OTA.

Here are some interesting resources:

[Task] - Rename spike to spikes

Description

Follow the plural rule.

Related epic/story: #7

[Task] - Change CI to use Linux instead of macOS

Description

macOS costs too many minutes of free github action time... Move to linux!

Related epic/story: #7

[Task] - Rework headers include

Description

Follow the rules in:

Related epic/story/task: #78

[Task] - Implement LEKA_V1.0_DEV target

Description

The LEKA_V1.0_DEV target is based on the DISCO_F769 with minor configuration.

As the mainboard evolve, continue to customise the LEKA_V1.0_DEV target to suit our need.

Related epic/story: #26

Subtasks

[Epic] - QSPI, OpenOCD, Linker & External flash

Description

Documentation related to QSPI Flash, OpenOCD & Linker configuration.

The goal is to have OpenOCD flash both the main mcu and the factory QSPI flash during manufacturing.

Docs

QSPI

OpenOCD

Linker

[Task] - Implement custom targets

Description

For development and later for production phases, we need to implement custom targets to make the process easier

Related epic/story: #26

Subtasks

~~Leka_v1_DEV~~ DISCO_ORIGINAL - using the 32F769IDISCOVERY while we wait for the mainboard
DISCO_MODIFIED - based on DISCO_ORIGINAL but with removed features
DISCO_IOC - generated from .ioc file with the same features removed than DISCO_MODIFIED
~~Leka_v1_PROD~~ LEKA_V1.0_DEV - for our development mainboard
~~[ ] Leka_v1_DEV_BLE - using the P-NUCLEO-WB55~~

[Task] - Test watchdogs

[Task] - Generate Leka defined pins directly into PinNames.h

Description

For the moment we define Leka pins inside LekaPinNames.h but that prevent us from using those pins in mbed_app.json.

Improve the generator script to add them directly into PinNames.h

Related epic/story: #74 #75 #6 #7

Setup EditorConfig & ClangFormat

related to #7

[Task] - Separate drivers from libs

Description

Separate drivers (directly talking to hardware) from libs (higher level functions)

Related epic/story: #7

Subtasks

rename lib to libs
create drivers directory

[Story] - LekaOS BLE v1.0.0

Introduction

BLE communication with the iPad is one of the most important feature of LekaOS. Without it the robot is useless and its presence allow us to:

control the robot
debug/log what's going on
tests new functionalities (FOTA, scheduling, etc.)

Roadmap

Setup a basic working example using mbed
Test the integration with timed tasks and scheduling
Implement Leka Communication Specifications

1. Setup a basic working example using mbed

This first step is really easy: use the examples from mbed-os to create a simple working example of BLE for Leka to pave the way for future developments

This must include:

read, write and notifications services/characteristics
the use of predefined services (battery) and proprietary services (temperature, firmware version, basic command)

2. Test integration with timed tasks and scheduling

Through out our development we will need to start tasks and stop them. Gaining a deeper understanding about how this will work between BLE and mbed os is paramount as all future development will rely on that.

More information in #1 - #1 (comment)

This must include:

starting a long running thread
stoping a long running thread anytime
starting again from the beginning
starting again where we left off (if possible)

3. Implement Leka Communication Specifications

We'll review, update and implement the Leka Communication Specifications in parallel with the iOS app.

The main goal is to have the two perfectly synchronised.

This must include:

implement all the services/characteristics
implement the command analyser
a lot of testing

4. Mandatory commands

implement reset command and test in case of infinite loop

[Task] - Fix openocd flash command

Description

Try using -c 'reset run' -c 'exit'

Related epic/story: #24

[Task] - Screen - Exploration to use JPEG

Ecran - valider le jpeg

Description

Display a JPEG image on the screen connected on Leka board.

Etat initial

Journée d’investigation:

LekaScreen avec la structure pour la journée d’investigation qui appelle LekaLCD
LekaLCD, code de Modar avec l’animation du cube

Tasks

Create directory structure

related to #7

[Story] - Organization, Rules, Tools & Toolchain

Introduction

LekaOS is a great project and a big project that will grow in size considerably over the next few months. It's important for the sanity of all the developers involved that good defaults and standards are setup and chosen at the beginning to reduce friction and bikeshedding.

Different topics will be covered:

folder organization
naming conventions
coding style
testing
CI & automation
toolchains

Folder/Directory organization

LekaOS will follow the monorepo philosophy, which means that all the dependencies will be located inside this repository. No external dependencies, no submodules, everything must compile after git clone.

⚠️ One exception might be large binary files (e.g. images, sounds, etc.). Extra care must be taken and each case must be discussed.

Root folders will be:

.azure-ci or .github - CI related tasks
docs - documentation
lib - library folder
src - sources of the main application
test - tests --> unit, functional, integration
script - scripts used by different processes

Naming conventions

⚠️ to do

Coding style

Coding style is taken care of by EditorConfig and ClangFormat.

Testing

⚠️ to do

CI & Automation

⚠️ in progress

use https://github.com/codespell-project/codespell to check for spelling errors in code
use clang-format-lint to check style - https://github.com/marketplace/actions/clang-format-lint

Toolchains

LekaOS will be compiled using GCC ARM None Eabi.

Some tests must be run to see wether we use mbed-cli, Make of CMake.

[Epic] - Size Estimation for Memory Specs

LekaOS needs to store and access a lot of information/content while working.

For example:

images
animations
sounds
misc data

Estimation on the size required to stock all this content must be done.

[Epic] - LekaOS Coordination

This epic will discuss how we should organize the inner working of LekaOS.

[Story] - Firmware Update

Description

This story gathers all the information and ideas about the firmware update process: strategy, support, security, tests, etc.

Related epic/story: n/a

`.hex` or `.bin`?

The question asked is should we send the update as a .bin file or .hex.

The question was asked to the community here:

ARM Mbed OS Forum - Firmware Update w/ FlashIAP - .bin or .hex?

The answers provide useful information:

.bin is smaller than .hex
.hex incorporate a checksum for each lines
.bin allows for custom binary framing to provide additional information
.bin allows for custom frame length to send more information each time

With those information, the .bin approach seems to be better in many points.

QSPI Flash or SD Card

Following the ".hex or .bin?" question, we must investigate and decide if we want to use SD Memory Card or QSPI Flash.

Pros of the SD Card:

we can use a FileSystem to store the .bin
we can write frames by frames, we don't have to worry about sector/page size, etc.
we have a lot of available memory so we can store a lot of versions if roll back is necessary
we can store config files as well

Cons of the SD Card:

we need the FileSystem in the bootloader which can add some memory consumption

Pros of the QSPI Flash:

we just need QSPI Flash
memory is safe and strong

Cons of QSPI Flash:

we must deal with sector/page size when writing to the external memory
we can store only one previous version
we need to use KVStore to store external info (old/new version number, checksum, size, etc.)

With those information, QSPI Flash seems to be a good candidate for simple systems with low resources and low memory available.

On the other hand, the SD Card approach gives us a higher level view of the subject and allow us to use concepts closer to those of a regular computer. The SD Card can also be flashed before and more testing can be done.

In conclusion:

we can keep one QSPI Flash for factory firmware (we need to understand how to flash it)
the update process can use the SD Card with a dedicated directory

Update workflow

⚠️ to do

Security

For firmware update through untrusted channels (BLE, Wifi, etc.), security is paramount! We can distinguish two types of security:

signing
encrypting

Signing means that the content of the file is signed, a hash is generated and it can be checked to make sure it comes from Leka and not from someone else. With just signing, the content of the firmware update is visible to the external world.

Encrypting means that from the original content we generate a cyphered version of the update that has to be decrypted once on the device. If someone steals the update, they won't be able to read it's content.

Both signing and encrypting must be done on the firmware sent for the update.

Useful links:

Frame structure

The .bin approach lets us use a custom binary frame for the data we send.

Source: Specs-FOTA-Frame.gsheet

Item	Size	Type	Content	Comment
Start bytes	4 bytes	`array[4] {uint8_t}`	`[2A 2B 2C 2D]`	Start sequence to recognize a frame
Header
Size	1 byte	`uint8_t`		The size of the data contained in the current frame (`1..256`)
Data type	1 byte	`uint8_t`	- `00` - Firmware version - `01` - Firmware size - `02` - Number of frames to receive - `03` - Global CRC	The type of data received
CRC	1 byte	`uint8_t`		CRC Checksum of the current frame's data (⚠️ to be investigated)
Data				The data contained in the current frame. It can only be of one type
Firmware version	3 bytes	`array[3] {uint8_t}`	`major minor patch`
Firmware size	4 bytes	`uint32_t`		Total size of the firmware to be sent
Number of frames to receive	4 bytes	`uint32_t`		Number of frames to be sent for the update
Global CRC	4 bytes	`uint32_t`		CRC Checksum of the firmware
Stop bytes	4 bytes	`array[4] {uint8_t}`	`[2D 2C 2B 2A]`	Stop sequence at the end of a frame

Proofs of concept

1. First Leka Bootloader

understand how the bootloader works with mbed-config
create a simple bootloader running in a loop
send an application and write it to MCU Flash (w/ FlashIAP)
send an application and write it to QSPI Flash first, then to MCU Flash (w/ FlashIAP)

♻️ Steps

Step 1.1

Hello, I'm the bootloader!
I'm waiting for 5 seconds before starting the application...

1... 2... 3... 4... 5...

Starting application now!

Hello, I'm application!
I'm running in a loop.
1
2
3
// [...]

Step 1.2

Hello, I'm the bootloader!
I'm waiting for an application to be sent to me...

1... 2... 3... 4... 5... // [...]

An application is available! I'm writing the application to MCU Flash!

// [...]

Application written to MCU Flash!

Starting the application now!

Hello, I'm application!
I'm running in a loop.
1
2
3
// [...]

Step 1.3

Hello, I'm the bootloader!
I'm waiting for an application to be sent to me...

1... 2... 3... 4... 5...

An application is available! I'm writing the application to QSPI flash!

// [...]

Application written to QSPI!

I'm writing the application to MCU Flash!

// [...]

Application written to MCU Flash!

Starting the application now!

Hello, I'm application!
I'm running in a loop.
1
2
3
// [...]

2. In application update

start the application and have the application wait for a new version
store the new version to QSPI Flash
reboot and write the application to MCU Flash

♻️ Steps

Step 2.1

Hello, I'm the bootloader!

Checking if a new application is available...
No application available.

Starting current application now!

Hello, I'm application!
I'm running in a loop waiting for an new application to be sent to me...
1
2
3
// [...]

An application is available! I'm writing the application to QSPI flash!

Application written to QSPI!
Rebooting...

Hello, I'm the bootloader!
Checking if a new application is available...
New application available!

Now I'm written the application to the MCU...
Application written to MCU.

Starting new application now!

Step 2.2

to do

[Task] - Watchdog - Compare between thread and ticker

Description

The current version of the watchdog uses a thread.

@YannLocatelli proposed an alternative solution using a ticker which might be more light weight here: #17 (comment)

#include "mbed.h"

Ticker kicker;

void watchdogKick()
{
    Watchdog::get_instance().kick();
}

int main()
{
    printf("\n\nDemonstration of watchdog in case of error (happens in 10s).\n");

    const uint32_t TIMEOUT_MS = 5000;
    Watchdog &watchdog = Watchdog::get_instance();
    watchdog.start(TIMEOUT_MS);

    kicker.attach_us(watchdogKick, 1000);
    
    ThisThread::sleep_for(10s);
    error("This is a reason why watchdog exists. Restarting in 5000ms...\n");
    
    return 0;
}

Related epic/story: #19

Subtasks

create two examples, one with a thread and the other with a timer
test them with fatal errors and while loops
compare size or executable

[Task] - Test toolchains

related to #7

[Story] - Leka Mbed Target

Description

Leka is based on the DISCO_F769NI target.

A custom target must be created. This includes:

create a dummy target with the DISCO_F769NI
creating the target structure
adding config files: CubeMX .ioc, CSV with pins
creating and adding scripts: CSV to .ioc and .ioc to source code
adding the PinNames.h and PeripheralPins.c files
copying the files from mbed repository
add linker scripts
~~find a way to incorporate the target in mbed-os if needed~~ no need

[Task] - Flex - Test Process

From Pierre:

brancher le flex sur le shield de type ARDUINO pour la DISCOVERY ou directement sur la carte mère ( nom : CML01 : carte mère LEKA01 ?)
visualiser/ mesurer le courant sur le 5V et le 3.3V ( via ADC sur CML01)
faire clignoter en séquentiel les 2 LEDs de tête avec 1 seule couleur puisla 2 ème, puis la 3 ème, puis les 3 couleurs, cycle 0.5s
faire clignoter en séquentiel les 20 LEDs de ceinture avec 1 seule couleur puis les 3, cycle 0.5s
allumer toutes les LEDS
mesurer le courant 5V en conséquence
allumer le détecteur de proximité 1 et la LED, en couleur bleue la plus proche, approcher la main. Ceci doit afficher la LED de proximité en rouge. Selon la distance de détection, modifier le règlage. Idem pour les 5 autres.
faire un balayage séquentiel des 6 détecteurs : vérifier la bonne détection de la zone concernée
activer le lecteur RFID, via une commande RS232 : allumer les 2 LEDs de tête en bleu
approcher un tag RFID de petite taille : si détecté, noter la distance de détection et allumer les 2 LEDs de tête en rouge pendant 2 secondes
approcher un tag RFID de grande taille ( carte bancaire) : si détecté, noter la distance de détection et allumer pendant 5 secondes les 2 LEDs de tête en rouge pendant 2 secondes

[Task] - Move mbed-os and external libs to extern directory

Description

Currently mbed-os is located inside the lib/_vendor directory.

Even with the _vendor directory, it's not that clear that this library is not supposed to be modified.

We should move it to the extern or external repository at the root of the project.

Related epic/story: #7

Update default branch to develop

[Story] - Leka / LekaOS - QA, Norms, Certifications & Tests

Description

This story gathers all the tasks related to:

quality analysis
norms & certifications
tests & investigation days

Related epic/story: n/a

Step 1 - Journée d'investigation

Répartition des composants pour la journée d’investigation

2020_09_08-Specs-Investigation_day.gdoc

@ladislas:

Moteurs et contrôleur moteur
LEDs
BLE
Lecteur RFID
Capteurs en I2C : Accéléromètre, Gyroscope, Magnétomètre, Température

@YannLocatelli:

Vibreur haptique et amplificateur
Capteurs de toucher
WIFI
Bluetooth
Ecran et SDRAM
Mémoire SD
Mémoire flash externe (QSPI)

Autres:

Module de réception de la recharge par induction
Capteurs en ADC : luminosité, microphone
Watchdog

[Task] - Script to edit .ioc CubeMX file

Description

When #27 is completed and everything is good to go, modify the .ioc file with the correct labels.

Related epic/story: #26 #27

Subtasks

parce design doc .csv
parce .ioc file
add corresponding:
- P{xx}.GPIOParameters=GPIO_Label
- P{xx}.GPIO_Label={label}

[Story] - External Drivers Study

Description

The goal of this story is

Related epic/story:

leka / lekaos Goto Github PK

lekaos's People

Contributors

Stargazers

Watchers

Forkers

lekaos's Issues

Description

Description

Description

Description

Documentation list

Description

Description

Description

Subtasks

Description

Description

Resources

Description

Description

Description

Subtasks

Description

Subtasks

Description

Subtasks

Description

Description

Test Applications

Description

Description

Description

Description

Subtasks

Description

Docs

QSPI

OpenOCD

Linker

Description

Subtasks

Description

Description

Subtasks

Introduction

Roadmap

1. Setup a basic working example using mbed

2. Test integration with timed tasks and scheduling

3. Implement Leka Communication Specifications

4. Mandatory commands

Description

Ecran - valider le jpeg

Description

Etat initial

Tasks

Introduction

Folder/Directory organization

Naming conventions

Coding style

Testing

CI & Automation

Toolchains

Description

.hex or .bin?

QSPI Flash or SD Card

Update workflow

Security

Frame structure

Proofs of concept

1. First Leka Bootloader

Step 1.1

Step 1.2

Step 1.3

2. In application update

Step 2.1

Step 2.2

Description

Subtasks

Description

`.hex` or `.bin`?