Proj-2013-2014-Python-STM32F4:SRS

This document describes the software requirements specification of the project Proj-2013-2014-Python-STM32F4

Document History

	Version	Date	Authors	Description	Validator	Validation Date
	0.1.0	10 févr. 2014	TAO Xinxiu, XIA ye	SRS	TBC	TBC

1. Introduction

1.1 Purpose of the requirements document

The purpose of this requirements document is to present the requirements and specifications of the project Proj-2013-2014-Python-STM32F4. The document explains the purpose and functional features of the system, the interfaces details of the system, what the system will do, the constraints under which it must operate.

The intended audiences of this document is the users, the developers and the tutor of the project.

1.2 Scope of the product

The project aim to compile Python programs to run them on the board STM32F4. This project will use the project Shedskin which is a python-to-C++ compiler. The main function of the project is to compile the C++ code which is generated by the compiler Shed Skin to executable code which can be run on the board STM32F4. Instead of modifying the project Shed Skin, we will just compile the C++ code files and the Makefile file to make it executable on the board.

// TODO: chart to added

2. General description

2.1 Product perspective

• System intefaces

//TODO diagram to add

1. With the help of the project Shed Skin, firstly we compile the users’ input python source code(.py) to C++ code(.cpp, .hpp, Makefile).

2. The core part of this project is to modify the Makefile, to add necessary initialisation to the C++ code generated by Shed Skin and to add other needed files (linder.ld, etc) and libraries to make it compilable by the compiler arm-none-eabi-g++.

3. With the help of the GNU/ARM toolchain (command arm-none-eabi-g++), compile the program and obtain the executable file *.bin.

4. To use the tool ST-LINK which is an in-circuit debugger and programmer for the STM8 and STM32 microcontroller families to write the executable file .bin to the board.

• User interfaces

The command line style will be used as the user interface of this programme. And the specific error messages will be returned to the user when error occurs.

• Hardware interfaces

The programme should be run on Linux System. The STM32F407 is used as the targed board.

• Software interfaces

Shed Skin GNU/ARM toolchain ST-LINK

2.3 User characteristics

The project is intended for the users who want to run their python programs on the board STM32. The users need to know the exact errors when it is caused by the python code they wrote. The users may or may not know exactly how to download and run the program on the board, but they are expected to know the basic steps and to do the operations as suggested in the document of this project.

2.4 General constraints

• Hardware limitations

The board STM32F407, USB cable type A and mini-B.

• Software limitations

Operating System: Linux

The program required the following software products to be pre-installed:

* Shed Skin
* ST-LINK
* GNU/ARM toolchain

2.5 Assumptions and dependencies

The project assume that the users’ input python code observe these limitations listed:

• Only builtin scalar and container types (int, float, complex, bool, str, list, tuple, dict, set) as well as None and instances of user-defined classes can be passed/returned. So for instance, anonymous functions and iterators are currently not supported.
• Builtin objects are completely converted for each call/return from Shed Skin to CPython types and back, including their contents. This means you cannot change CPython builtin objects from the Shed Skin side and vice versa, and conversion may be slow. Instances of user-defined classes can be passed/returned without any conversion, and changed from either side.
• Global variables are converted once, at initialization time, from Shed Skin to CPython. This means that the value of the CPython version and Shed Skin version can change independently. This problem can be avoided by only using constant globals, or by adding getter/setter functions.
• Multiple (interacting) extension modules are not supported at the moment. Also, importing and using the Python version of a module and the compiled version at the same time may not work.

3.Specific requirements, covering functional, non-functional and interface requirements

• document external interfaces,
• describe system functionality and performance
• specify logical database requirements,
• design constraints,
• emergent system properties and quality characteristics.

3.1 Requirement X.Y.Z (in Structured Natural Language)

Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:

• Natural language sentences (with MUST, MAY, SHALL)
• Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
• Mathematical Notations
• Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects: