Proj-2013-2014-Python-STM32F4:SRS: Difference between revisions

From air
Jump to navigation Jump to search
Line 87: Line 87:
==2.5 Assumptions and dependencies==
==2.5 Assumptions and dependencies==


The project assume that the users’ input python code observe these limitations listed:
The project assume that the users’ input python code observe these limitations listed[1]:
* 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.
* 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.
* 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.

Revision as of 19:44, 16 February 2014

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: diagram to add

1.3 Definitions, acronyms and abbreviations

1.4 References

1.5 Overview of the remainder of the document

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.2 Product functions

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[1]:

  • 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

3.1 Document External Interfaces

The project’s only external interface to users is the command pythonSTM32 following with the options and the input file. The output of the program is the execution of the program on the board STM32 which is connected to the user’s computer, this program is right compiled from the users’ input python code.


3.2 Function Requirements

3.2.1 support STL, Lib C, libprce

Function: implement the STL, Lib C and libprce in the targeted C++ code

Description: The initial C++ code generated by Shed Skin contains STL, Lib C and libprce functions which are not supported by the compiler arm-none-eabi-g++.

Inputs: The C++ codes generated by Shed Skin

Source: generated by the program Shed Skin compiling the user’s input python code.

Outputs: The Makefile which calls the compiler arm-none-eabi-g++ with the necessary options, and the C++ codes which could be compiled by the compiler arm-none-eabi-g++.

Destination: To generate the executable file for the board STM32 from these C++ codes.

Action: TBC(The function may be resolved by adding correspond libraries or/and compile the correspond part of C++ code.)

Pre-condition: The C++ code generated by Shed Skin is correct.

Post-condition: The output C++ code doesn’t change the intension of the initial code and could be compiled by the compiler arm-none-eabi-g++.


3.2.2 add GC feature

Function: add the GC feature in the targeted C++ code.

Description: The GC is supported in the Python but it is not implemented in the initial C++ code.

Inputs: The C++ codes compilable for the compiler arm-none-eabi-g++

Source: The output of the function 3.1.1.

Outputs: The C++ codes that have implemented the GC.

Destination: To generate the executable file which implement GC for these C++ codes.

Action: TBC(The function may be resolved by adding correspond libraries or/and compile the correspond part of C++ code.)

Pre-condition: The C++ code generated by Shed Skin are right.

Post-condition: The output C++ codes don’t change the intension of the initial code and could be compiled by the compiler arm-none-eabi-g++.

4. Product evolution

5. Appendices

6. Index