I would but ran into a small snag (am researching but haven't found the solution yet): How do I post a patch with a .png (binary) file in it? I'm so used to git I forgot about this issue with svn...I can apply git patches. Don't remember how it is done with svn, probably the internet knows.
Does the C::B project have a 'best practice' on this issue?
The 'debug' problem is only that I would like to pre-populate the project's 'debugger' configuration with the GDB parameters for connecting to opencdb (target remote etc.) openocd uses a different port than other gdb debug shims, so anything in the top-leve processor-specific debugger configuration wouldn't apply.I think, I've fixed this no long ago. It should be possible to set the settings of the debugger using scripting. But I might be wrong.
As soon as that part is resolved, I'll post the diffs. They are rather largish (13k + lines) with mostly in the wizard and support 'include' scripts - I broke the script into four pieces because maintiaining one LARGE script seems tedious - four smaller 'modules' made more sense and I might break it down further. As I stated, this is a complex script and includes (among other things) serialization of configuration to the user's .config/codeblocks/ area to save state so I don't have to grok through the STM32_CUBE modules over an over. (The serialization is a simple 'write config' / 'read config' that allows storing arbitrary data into an isolated 'jail' in the codeblocks configuration folder - not the project folder. I wrote a Squirrel data-structure dumper so I can serial Squirrel objects and then reload them later. Makes the loading configuration about 1000x faster than re-reading the files in the STM32 CUBE folders.
erested in patches to the scripting bindings of C::B only.
If the script is as complex as you describe it, I'll prefer if it stays as a separate project and not part of C::B.
The reason is that there will be very few people using it and none of the core developers will maintain it properly.
As a separate project it can have faster iterations and better support.
I'm eager to help with improvements to C::B to facilitate easier integration, installation and setup.
Hopefully this sounds reasonable to you.
p.s. I'm maintaining the arduino wizards in a similar fashion (no matter that a different version has been added to the main install). https://github.com/obfuscated/cb_arduino_template
p.p.s. You can use my git repo to post patches against. It is relatively up-to-date.
I am about ready to make available a plugin 'wizard' for the STM32 family of ARM devices. This plugin knows about the structure of the STM32 "Cube" libraries which expose the various API's supported by the manufacturer, plus some third-party 'middleware' for extra functionality. The plugin will allow you to (for example) 1) select additional libraries in the cube; 2) enable HAL (hardware abstraction) functionality as needed and perform *some* of the initialization required; 3) enable FreeRTOS and hook up timers etc; 4) build a project containing all of the needed components copied from the CUBE into the user's project directory. It's well enough along I'm currently using it in a limited production basis for build test applications for some new hardware.
This is funny :)
I have recently (like, during the last couple of weeks) coded a script for importing a Cube project file (*.gpdsc) to C::B.
In doing so, I also added support for XML parsing (rudimentary, what wxXML provides) in scripts.
I also had to add a "Custom command" (besides serial/network) entry in remote debugger connection settings that allows you to open a pipe to openocd from inside gdb.
All above changes live locally on my disk, not committed yet.
Is what you implemented anywhere accessible so I can have a look?
@mandrav: https://sourceforge.net/p/codeblocks/tickets/341/
Also please don't make changes to the scripting at the moment, because there is a sqplus to scrat migration changes that ought to be applied soon.
error: E:\Dev\C-CPP\CodeBlocks\share\codeblocks/templates/wizard/codeblocks_stm32_wizard/wizard.script line = (1500) column = (48) : error expected 'IDENTIFIER'