Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Am finishing an STM32 wizard and need some tips...

(1/4) > >>

Aerodesic:
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.

My wizard and other changes have been tracking the currently nightlies without incident so I don't expect much integration fuzz to get this installed.  Unfortunately, as my plugin requires the extra wizard api exposure, I can't just release this as an 'addon' (though I do believe my additions should make some more complex wizards possible at a later date, and for me the Squirrel approach seems saner than writing a bunch of C code that needs to be validated under a bunch of other platforms I don't / can't run.

And I can make my patches (against the current nightly build) if someone else wants to see what I've been doing.  I don't have a document yet describing what I've done (with the APIs that have been added) but that should be coming soon.

My current issue is a desire to establish some project-defined openocd configuration to enable debugging after the wizard has completed.  I know from past conversations with a few folks here the GDB functionality may be in a state of 'flux' so didn't want to start tipping the cart with my own mods before asking about any 'road map.'  Does anyone have suggestions as to what best course to take for this mechanism.

Thanks for listening,

-Gary

oBFusCATed:
Please post patches about the wizard.

About debugging: Can you describe the problem with more details?

Aerodesic:
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...
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.

-Gary

oBFusCATed:

--- Quote from: Aerodeisc on April 18, 2016, 07:54:13 pm ---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...
Does the C::B project have a 'best practice' on this issue? 

--- End quote ---
I can apply git patches. Don't remember how it is done with svn, probably the internet knows.


--- Quote from: Aerodeisc on April 18, 2016, 07:54:13 pm ---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.

--- End quote ---
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.
If you give me a link to a previous discussion I might remember:)

Aerodesic:
I'm looking through google et al for tips - found references to using git to import svn to generate a git patch (which does know about binary bits) but of course that fails with an error: 'tempfile' can't be called as a method at /usr/local/share/perl/5.12.4/Git.pm line 1042.

I am now digging through the scriptmanager stuff (been through this a bunch lately) and don't remember anything specific for debug setup, but if it's there I will find it :-)

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.

I'll be back as soon as I fix the diff issue - do I post the patches here or do you want a link to my owncloud storage?

Thanks!
-Gary

Navigation

[0] Message Index

[#] Next page