project-generator / project_generator_definitions Goto Github PK

Is there plan to add support for Cortex-M33

As we changed pdef remote (from my repo to this one), we haven't updated remote. Therefore we should a check that remote origin is set to this repository in the default location, if not, set it there.

I am currently keeping my fork up to the date 😆

cc @sg-

Their recent plans made it unavailable for open source projects like this one to run some free jobs. The credit system is one time thing that needs to be requested and takes some time to be granted. Not ideal, so I'll look at how to migrate it elsewhere where we can run our simple checks.

Already fixed in project_generator, same fix needed here, line 28 in the definitions script file

I'll send a fix within a day

The current pgen version (v0.6) uses legacy devices (as named in uvision 5). Which is fine as it will work after downloading legacy support to uVision 5 (http://www2.keil.com/mdk5/legacy/).

We might find soon enough a device which is only supported via device packs. I'll find out what it needs to be compatible with device packs, for us to switch to use a new device packs.

At least basic description what this module does, so it's not empty on pypi

Let's move to py3 by default.

I tried quickly today to scrape definitions with uvisions and there are some easy to fix python errors like

project_generator_definitions\tools.py", line 67, in get_mcu_definition
    uvproj_dic = xmltodict.parse(file(project_file), dict_constructor=dict)
NameError: name 'file' is not defined

I'm using:
IAR EWARM 7.40.7
mbed-os-5.1.0-rc4
project-generator (0.9.8)
project-generator-definitions (0.2.27)

Exporting to the following targets and trying to build in IAR IDE results in an error that the device doesn't have VFP registers. The project files need to have the FPU option set to VFPv4 single precision.
NUCLEO_F411RE
NUCLEO_F401RE
DISCO_F429ZI
FRDM-K64F
FRDM-K22F

Most of progen targets assume that there is some default debugger set up. We can say it's cmsis-dap debugger. This is not correct and expected, as any module using those targets might change the default one (cmsis-dap is not even documented anywhere that that's default one).

File reference: https://github.com/project-generator/project_generator_definitions/blob/master/project_generator_definitions/target/targets.py

Hi,

I'm working to package this up for Arch Linux and am curious if you can create tags to the releases so I can build the packages based on tags.

Thanks!

When progendef create to be used on uvision4_nucleo_f746zg.uvproj.tmpl, this is the traceback

progendef create -f uvision4_nucleo_f746zg.uvproj.tmpl -m
 -t uvision5
Traceback (most recent call last):
  File "C:\Python27\Scripts\progendef-script.py", line 9, in <module>
    load_entry_point('project-generator-definitions', 'console_scripts', 'progendef')()
  File "c:\code\git_repo\github\project_generator_definitions\project_generator_definitions\main.py", line 54, in main
    return args.func(args)
  File "c:\code\git_repo\github\project_generator_definitions\project_generator_definitions\create_command.py", line 23
 in run
    if ProGenDef(args.tool).mcu_create(args.mcu, args.file) == False:
  File "c:\code\git_repo\github\project_generator_definitions\project_generator_definitions\definitions.py", line 152,
n mcu_create
    data = self.definitions.get_mcu_definition(template_file)
  File "c:\code\git_repo\github\project_generator_definitions\project_generator_definitions\tools.py", line 74, in get_
cu_definition
    'DeviceId' : [int(uvproj_dic['Project']['Targets']['Target']['TargetOption']['TargetCommonOption']['DeviceId'])],
TypeError: int() argument must be a string or a number, not 'NoneType'

with uvision4, it fails as well but with INFO.

We should add simple CI tests to at least verify syntax in the yaml files.

Core should be valid, target should have mcu, and mcu should be valid and present. All tool specific should be there. For example this can be normal mistake for user adding a new target:

    iar:
    OGChipSelectEditMenu:
      state:
      - STM32F401xE ST STM32F401xE
    OGCoreOrChip:
      state:
      - 1

The tests would be run by Travis, so each PR would be tested before it gets landed

We provide API to get target definition, but not mcu.

Target is useful for a user writing own yaml files, but for other frameworks, mcu might be better option. For instance, there's a framework which calls its target freedom-k64f, this one has an mcu on it. It could use frdm-k64f progen target, or rather mcu MK64Fxxxxx and get mcu definition right away.

We should get ROM/RAM details which are known by uvision. They are under <OnChipMemories>

They are not active if you use scatter file.

We should align definitions to the release process set in the progen.

We should distinguish between legacy mcu and the new mcu. For instance, mcu k64f could define uvision (as it is now) for uvision4 - legacy, uvision5 would be using the new packs mcu (there should be new fields in the mcu).

This should be non-breaking change.

Related to some latest cleaning for v0.6, we should define uvision syntax better. TargetOption is not exactly what's inside xml file.

For example for flash driver dll - Targets-Target-targetOption-TargetCommonOption-Device

  <Targets>
    <Target>
      <TargetName>{{name}}</TargetName>
      <ToolsetNumber>0x4</ToolsetNumber>
      <ToolsetName>ARM-ADS</ToolsetName>
      <TargetOption>
        <TargetCommonOption>
        <Device>{{uvision_settings['Device']}}</Device>
          <Vendor>{{uvision_settings['Vendor']}}</Vendor>
          <Cpu>{{uvision_settings['Cpu']}}</Cpu>
          <FlashUtilSpec></FlashUtilSpec>
          <StartupFile></StartupFile>
          <FlashDriverDll></FlashDriverDll>

We should provide the same as for uvision, for only core (no device). This currently results in the traceback.

Our cores have support only for uvision, thus we have not seen the error.

Why? http://pybuilder.github.io/documentation/external_plugins.html#.V5m-hfmANBc

Hi,
I want to add a new board, stm32f373cc as an HIC. When I try to generate the make file using progen, I get the following error:
RuntimeError: Target: stm32f373cc not found, Please add the target to https://github.com/project-generator/project_generator_definitions
Any suggestions on what can be done? How do we add a new mcu yaml file to project generator definition?

Each target needs a separate yaml file where is just a path to mcu yaml file. This could be simplified with a dictionary (or a class if there is any API there):

PROGENDEF_TARGETS = {
    'frdm-k64f': 'mcu/freescale/mk64f.yaml',
    'my-new-platofrm': 'mcu/freescale/mk64f.yaml',
    'mbed-lpc1768': 'mcu/nxp/lpc1768.yaml',
}

We should state what versions we use and our parsers supports. For instance the latest master contains fixes for IAR >7.40.2 that introduced FPU2 settings for MCU.

We currently don't do any validity check. If I have uv4 project, and use uv5 parser, it parsers it without any errors, just the mcu definition might not be correct.

We should add additional checks for uv4 not to try to parse uv5 project file (with software packs).

Followup for #18. I am preparing definitions v0.0.1 for ProGen v0.8.x, which is going to be python module. I already got branch for this devel: https://github.com/project-generator/project_generator_definitions/tree/dev_v1. I am going to publish v0.0.1 this weekend, so we can start testing this how it works. I'll send PR to progen v0.8 branch to start using this python module.

The module will contain yaml files, ProGenDef class providing API for definitions. We should write tests - each yaml definition is tested to contain valid syntax, all data which are required. I ported so far simple test case just to get travis working and structure for tests.

Any ideas for this upcoming version, speak now!

Add MCU Cortex-Mxx support for uvision5

Currently supports only uvision (should be compatible), but fails if -t uvision5 is used

I created already an issue for pgen, to have a parser there, the data should be implemented here. For reference https://github.com/0xc0170/project_generator/issues/92

We can add debuggers definitions for various tools, so user can select which one to use for projects.

I could not find Cortex-M0+ definition here:
https://github.com/project-generator/project_generator_definitions/tree/master/project_generator_definitions/mcu/arm

Is there any particular reason not to have this?

This would be better to follow semver, as we might have some breaking changes in syntax , mcu definitions or newer versions of ides, etc..

Currently project generator tracks master. For the upcoming v0.8, I am thinking about turning this into python module, and use semver. If we do this, I might go back to older versions and create a patch for v0.5-v0.7, which would start using python module.

Create a new mcu definition should be implemented here. It's not progen responsibility as all logic is implemented here.

projgendef create (some arguments, will be filled later)

Hi
When I export MBED test for a NUCLEO_STM32 targets and IAR,
I always need to change project option within the IDE to use flash loader in the Debugger/Download options.

Maybe it can be automatic by changing yaml files ?

Thx

The MCU settings in many IDE has own FPU settings which should be defined by a target.

I'll have to look at those settings, how we can capture them in definitions and use in the progen.

Do you want it?
Would you be okay with a beefed up version of the mbed-os template?
I can get it done in about a day, so I'll be working on it tomorrow, let me know if It's not what you want.

Hello,
When I export a project for NUCLEO_F746ZG it does not contain the correct information for flash
mbed export -i uvision5 -m NUCLEO_F746ZG --source=mbed-os/TESTS/mbed_drivers/c_strings
The correct value seems to be in the .uvoptx file

          <Number>0</Number>
          <Key>UL2CM3</Key>
          <Name>UL2CM3(-S0 -C0 -P0 -FD20010000 -FC1000 -FN1 -FF0STM32F7x_1024 -FS08000000 -FL0100000 -FP0($$Device:STM32F746ZG$CMSIS\Flash\STM32F7x_1024.FLM))</Name>

Could you fix it, please ?
Cheers

Every uvision and uvision5 option block should contain the following otions:

    uvision(5):
        TargetOption:
            Device:
            - xx
            DeviceId:
            - xx
            Vendor:
            - xx
            Cpu:
            - xx
            FlashDriverDll:
            - xx
            SFDFile:
            - xx
            RegisterFile:
            - xx

This is optional:

            PackID:
            - xx

The PR project-generator/project_generator#381 extended the options.

This might happen with the progen v0.8 release (will take some time , good as a transition period). v0.7.x was patched, so they already use definitions from pypi.