project-generator / project_generator Goto Github PK

Need to be able to run scripts before and after compilation and linking

Create a class for IAR, define options available and create a new IAR template files.

The requirement right now it's to have it in tools/project_generator (2 directories deep from the root). This should be optional.

My proposal is to set it in the user_settings, as an example, by default will be as it now, can be change anytime:

PROJECT_ROOT=r'\\..\\..'

I imagine that once something does not go correctly with the project_generator, a user just enables debug messages, to be able tofind out why it fails or behaves incorrectly.

If it's a bug, the report within debug level can be provided in the issue report.

As v0.3 was published, the wiki is outdated - needs update

I hate writing project_generator all the time, too long ... there are couple of options we have

pg
pgen
prg
prgen

pg is a module already in the pypi, shall we aim for another?

Debuggers could be predefined as MCUs are. To show user how to do it, CMSIS-DAP, Jlink and STLink can be firstly implemented.

Project like

common:
  board:
  - frdm-k64f
  include_paths:
  - \gpio_demo_twrk20d72
  - \gpio_demo_twrk20d72\common
  - \gpio_demo_twrk20d72\cpu
  - \gpio_demo_twrk20d72\cpu\headers
  linker_file:
  - \gpio_demo_twrk20d72\k20x256_flash.ld
  source_files:
  - \gpio_demo_twrk20d72\main.c
  - \gpio_demo_twrk20d72\cpu\startup_k20.c
  - \gpio_demo_twrk20d72\cpu\system_k20.c

Should be able to export and compile , as least this one for arm gcc. Or even for uvision, although it does not accept .ld files.

There should be a command that creates a yaml file for the directory. There could also be standard settings ie: debug, no optimizations, etc. so all developers need to do is edit a file, not create and maintain it.

Request to a new feature, build script which would be an extension to current export script. It would allow to build generated project.

Create wiki pages on github.

The wiki page should include:

• Getting started guide
• Description of records
• Script files
• How data are parsed
• Description of all templates (how they differ for example)

Goal : Clear, simple and easy to navigate

This allows to use optimization features such as: http://www.keil.com/support/man/docs/armlink/armlink_pge1362065929730.htm

The name of the project should be used from the projects list file, not needed to be defined again in the project configuration file.

There's one project, one workspace at the moment. We can support one workspace - multiple projects.

This idea came to me yesterday. As I was testing sw previously, I was using various tools which could generate a project, build it and flash a target + run the code to get tests outputs from the console.

We have currently pgen export -b which exports and builds. I would like to investigate what we need to add to support flashing the target.

pgen export -p unit_test_01 --run

This would export, build and run the project (load, reset, run) via some configuration , which we need to design and implement.

Some information for tools:

• uVision : http://www.keil.com/support/man/docs/uv4/uv4_debug_commands.htm
• IAR : http://supp.iar.com/Support/?note=83441&from=note+26068

The default directory stays as it is, but if a user provides the output directory and specific name, it should be able to export it there.

As an example, it should be able to export a project to a structure like this:

examples/blinky
examples/blinky/iar/project.file
examples/blinky/uvision/project.file
examples/blinky/main.cpp

Each method should contain a comment, each "magic" which is in the code base needs a proper documentation, otherwise needs to be rewritten.

This task is to cover all code base.

Hi Martin,

I'm investigating on bringing an exporter for Atmel Studio but unable to find any hint regarding UUID generation. I certainly miss something.
Do you know an easy way to generate UUIDs and insert the patterns in the template?

example (first lines of workspace file):

Microsoft Visual Studio Solution File, Format Version 11.00
# Atmel Studio Solution File, Format Version 11.00
Project("{54F91283-7BC4-4236-8FF9-10F437C3AD48}") = "samv71 - getting started", "samv71 - getting started.cproj", "{6C71DA86-4901-4A3D-A087-581D0232CB87}"

This main project should be always in the root directory. I would like to add this requirement.

What about some additional details? I am thinking about adding there option for settings paths, to override default paths.

projects:
  my_project_1:
     1.yaml
settings:
  uv4:
    path-to-u4-on-my-machine

I think that it would be fairly useful as a long term goal to have some sort of automated testing on the project generator.

0xc0170@f204880

Somewhere around this commit we used to have a minimal set of options for the yaml files. Then things changed and there are specific options for specific tools and I dont think this is the right approach. I think we should define what the yaml files are capable of and then let the scripts figure out the best setting when generating a project file rather than having the yaml creater also be intimately familar with the toolset. Otherwise I fear a feature like https://github.com/0xc0170/project_generator/issues/51 will never be possible.

In the #52, it was proposed by @aethaniel , to have board definitions outside of the project_generator. Or at least to be able to pass the yaml record with board definitions for a project, then use that information internally to get the right information.

    board_def = {
        # Freescale FRDM boards
        'frdm-k20d50m': {
            'uvision': 'MK20DX128xxx5',
            'gcc' : 'cortex-m4',
        },
        'frdm-kl25z' : {
            'iar' : 'MKL25Z128xxx4',
            'gcc' : 'cortex-m0+',
        },
        'frdm-k64f' : {
            'uvision' : 'MK64FN1M0xxx12',
            'gcc' : 'cortex-m4f',
        },

        # mbed boards
        'mbed-lpc1768' : {
            'uvision' : 'LPC1768',
            'iar' : 'LPC1768',
            'coide' : 'LPC1768',
            'gcc' : 'cortex-m3',
        },

        # ST Disco boards
        'disco_f407vg' : {
            'coide' : 'STM32F407VG',
            'gcc' : 'cortex-m4',
        },
    }

This can be expressed in the yaml file, provided externally, and the pg just gets the board. This ticket is to start a discussion how it can be implemented so it scales. The initial idea was to have a common place, but probably would be better to have a repo with all these definitions, which can be easily pulled and used.

Comment all tool options available for records.

Move the tool specific settings dictionary out from the tool class.

Generic makefile with GCC ARM class.

Provide a syntax for records for all options for compiler, linker (parser).

New version of Simplicity studio was announced v3, http://www.silabs.com/products/mcu/Pages/simplicity-studio.aspx

Lets look at the output, and share here what it takes to support it.

The last time I used it, was a project based on makefile, so might be similar to makefile eclipse generator which is already supported.

As we are getting to a package, it would be beneficial to get version

project_generator --version

This one is a bit tricky, the default dir is generated_project, which can include any variable names inside, or default one. Then the project can be exported anywhere within a project root. Thus gives some flexibility, but harder to get it right when clean :-)

project_generator init --help:

  --all ALL             All generated projects.
  -f FILE, --file FILE  YAML projects file.
  -p PROJECT, --project PROJECT
                        Specify which project to be removed
  -t TOOL, --tool TOOL  Create project files for provided tool (uvision by
                        default).

Assembly files need symbols too

IAR template should be generic (only one template). There will be needed mcu definitions (special attributes per MCU) to be defined.
Plus all available options should be supported by parser and the template.

Currently for v0.5, we are using subprocess for pulling the latest mcu definitions. As it does not provide much options, going through pipes and all the other magic to get errors, we should consider module sh or any other available options.

It should rebase to the latest master silently (or might be faster to compare local HEAD and remote HEAD). The master should be available to change.. We support currently to redirect it to the local directory. Might consider also pull from a fork (but that's proably for later, I consder local directory to be a personal fork).

It should be fairly easy to add Sublime Text project support, using Makefile as a build tool: see here https://www.sublimetext.com/docs/2/projects.html

Support configuration for target. Currently everything is set to bin.. We should be able to create a project for a library.

This is a task to add another template and class for exporting. I can't find any information about command line builder for CoIDE, so that one needs to be investigated.

The Makefile should be generic, and adjusted to GCC toolchain (GCC ARM, CodeSourcery, etc).

It does build, but no object file is generated. If it is build via builder or in the IDE.

It might be problem with the IAR template file.

I corrected paths and created the user settings path. I thought there is a trick which would staged the file and then just ignore it, but looks like that trick works only locally.

The only solution which I see, it's to have default settings file and then import users settings. Like in CMSIS-DAP is it and other repositories.
Or force a user to run git update-index --assume-unchanged user_settings.py to ignore that file.

Comments?

There were few changes, wiki should reflect them.

This should work for simple projects like one project for a repository, one linker file with source/header files, libraries.

For projects, where are many various projects within a repository, it would create a record of all files for given directory.

Look at EmBlocks and create an exporter for this tool. They support various toolchains.

The list of features is impressive : http://www.emblocks.org/web/features

Debuggers could be predefined for CoIDE as MCUs are.

To show user how to do it, CMSIS-DAP, Jlink and STLink can be firstly defined.

There is not target currently defined. Should records define debug/release configuration?

The board which would translate to MCU and CPU core and other details if required by tools.

This can be defined in the yaml file.

board:
    frdm-k64f

Or via an argument. There are already used arguments (b - build, p - project, -t tool). So what can be defined for board?)

project_generator -p blinky -br frdm-k64f -t make_gcc_arm

uVision generator should have one generic template which can be reused for any target.

There are limited options available to a user. At least what can be added:

• linker options
• assembly options
• prescript/postscript run

Debuggers could be predefined for IAR as MCUs are.

To show user how to do it, CMSIS-DAP, Jlink and STLink can be firstly implemented.

Remove source dir paths, they are used for makefile only. They can be easily obtain from source files.

    source_paths:
        - mbed/libraries/mbed/targets/cmsis
        - mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F407VG

project_generator export options:

  -f FILE, --file FILE  YAML projects file.
  -p PROJECT, --project PROJECT
                        Project to be generated.
  -t TOOL, --tool TOOL  Create project files for provided tool (uvision by
                        default).
  -l, --list            List projects defined in the project file.
  -e, --execute         Build defined projects.

Npt sure about execute, it was build, but that can be easily mistaken with b as board... shall we use full names?

Searching for project-generator>=0.5
Reading https://pypi.python.org/simple/project_generator/
Best match: project-generator 0.5
Downloading https://pypi.python.org/packages/source/p/project_generator/project_generator-0.5.zip#md5=5834faed5887dab70718e8d8f4b20415
Processing project_generator-0.5.zip
Writing c:\users\deskto1\appdata\local\temp\easy_install-dxynxf\project_generator-0.5\setup.cfg
Running project_generator-0.5\setup.py -q bdist_egg --dist-dir c:\users\deskto1\appdata\local\temp\easy_install-dxynxf\project_generator-0.5\egg-dist-tmp-stmisq
Traceback (most recent call last):
File "setup.py", line 13, in
url = "",
File "C:\Python27\lib\distutils\core.py", line 151, in setup
dist.run_commands()
File "C:\Python27\lib\distutils\dist.py", line 953, in run_commands
self.run_command(cmd)
File "C:\Python27\lib\distutils\dist.py", line 972, in run_command
cmd_obj.run()
File "build\bdist.win-amd64\egg\setuptools\command\install.py", line 67, in run
File "build\bdist.win-amd64\egg\setuptools\command\install.py", line 117, in do_egg_install
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", line 370, in run
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", line 594, in easy_install
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", line 645, in install_item
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", line 693, in process_distribution
File "build\bdist.win-amd64\egg\pkg_resources.py", line 618, in resolve
File "build\bdist.win-amd64\egg\pkg_resources.py", line 870, in best_match
File "build\bdist.win-amd64\egg\pkg_resources.py", line 882, in obtain
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", line 613, in easy_install
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", line 643, in install_item
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", line 833, in install_eggs
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", line 1055, in build_and_install
File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", line 1040, in run_setup
File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 68, in run_setup
File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 114, in run
File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 67, in runner
File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 43, in _execfile
File "c:\users\deskto~1\appdata\local\temp\easy_install-dxynxf\project_generator-0.5\setup.py", line 21, in

File "C:\Python27\lib\site-packages\pip\req.py", line 1546, in parse_requirements
session=session,
File "C:\Python27\lib\site-packages\pip\download.py", line 278, in get_file_content
raise InstallationError('Could not open requirements file: %s' % str(e))
pip.exceptions.InstallationError: Could not open requirements file: [Errno 2] No such file or directory: 'requirements.txt'

Create Eclipse exporter class , to be able to export project files. Because eclipse xml is not that easy compare to IAR, uvision, I would start with makefile based project and gcc arm plugin. The goal is : makefile for project configuration, eclipse for toolchain and files.

I created a branch https://github.com/0xc0170/project_generator/tree/dev_eclipse_makefile , where I am slowly progressing.

We can potentially make all of the core in this repository into a proper Python module with a proper setup script etc. this will probably help with testing as currently I have to add the root directory of this repo to Python path in order to import the various classes etc.