CubeMX ioc files - add a 'collecting them' thread or section?

Development of new Cores using the STMCubeMX and HAL
Post Reply
zmemw16
Posts: 1413
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

CubeMX ioc files - add a 'collecting them' thread or section?

Post by zmemw16 » Fri Jul 28, 2017 9:51 am

the ioc file is essentially a switch matrix defining the pin usage/mapping for the cpu, think afio and in the event of the developer naming SPI3 pins on the schematic as SPI1 etc etc provides a mechanism to generate or re-generate the core code interface.

query - would it be useful to provide a collection topic or section for them ?

stephen

ms34me
Posts: 4
Joined: Thu Dec 10, 2015 5:27 pm

Re: CubeMX ioc files - add a 'collecting them' thread or section?

Post by ms34me » Thu Oct 05, 2017 2:20 am

I think this is a good idea.. i've already done it for this waveshare xnucleo board I have, i use it as a base for my projects.

zmemw16
Posts: 1413
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: CubeMX ioc files - add a 'collecting them' thread or section?

Post by zmemw16 » Thu Oct 05, 2017 2:07 pm

only took 10 weeks :D

which xnucleo ?
using it with which OS win/linux/mac
which core, chris, daniel, STM

my latest cz_Mini_stm32fve is attached :)
just lose the .txt when you save it
GPL2 & standard disclaimers apply.

stephen
Attachments
cz_VET_Blue3.ioc.txt
(3.17 KiB) Downloaded 4 times

User avatar
sheepdoll
Posts: 236
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: CubeMX ioc files - add a 'collecting them' thread or section?

Post by sheepdoll » Thu Oct 05, 2017 6:33 pm

Some time ago I wrote a simple parser in postscript for *.ioc files. My collection of STM32 boards is quite eclectic, So I have a number of different files.

To truly get the full picture that CubeMX presents, the static XML files are also useful. Fortunately STM came up with a python script that works similar to my postscript.

I also find it useful to place the *.ioc inside the git. That way if one changed stuff in cube, there can be different branches with different configurations.

zmemw16
Posts: 1413
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: CubeMX ioc files - add a 'collecting them' thread or section?

Post by zmemw16 » Thu Oct 05, 2017 7:51 pm

sheepdoll wrote:
Thu Oct 05, 2017 6:33 pm
To truly get the full picture that CubeMX presents, the static XML files are also useful. Fortunately STM came up with a python script that works similar to my postscript.
what did they call it?
sheepdoll wrote:
Thu Oct 05, 2017 6:33 pm
I also find it useful to place the *.ioc inside the git. That way if one changed stuff in cube, there can be different branches with different configurations.
not sure i follow that
istr a warning about renaming and then saving a CubeMX project.
i've done it moving a 411 to a 407, lots and lots of replacing 411 with 407, actually wasn't too hard :D

stephen

User avatar
sheepdoll
Posts: 236
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: CubeMX ioc files - add a 'collecting them' thread or section?

Post by sheepdoll » Fri Oct 06, 2017 2:27 am

zmemw16 wrote:
Thu Oct 05, 2017 7:51 pm

what did they call it?
Not exactly sure, this was in one of the STM postings. As I do not use python, I sort of noted it then went onto other things. I'd have to search the forums, which I do not have time to do at the moment.
zmemw16 wrote:
Thu Oct 05, 2017 7:51 pm
not sure i follow that
istr a warning about renaming and then saving a CubeMX project.
i've done it moving a 411 to a 407, lots and lots of replacing 411 with 407, actually wasn't too hard :D

stephen
The git branches are more useful within the processor type. So you have a branch for 407 with say SPI active, and another with I2C. The branches never get merged, they simply exist at peers to the parent project.

Not sure there is really a way to automate going from one variant to another. There is too much dependency on the peripheral architecture of a given variant.

Post Reply