http://www.ba0sh1.com/stm32cubemx-gcc-makefile/
https://github.com/baoshi/CubeMX2Makefile
You use the cubemx IDE, create your configuration and then generate source code. You must target the TrueStudio IDE. This python utility reads the TrueStudio config files and spews out a makefile for arm-none-eabi-gcc. You just changed to the source directory and type make .. bingo bango .. it compiles. It is useful even if you aren’t planning to use command line make. The best thing it does for you, is to identify all the include directories and define flags needed for a command line compile.. say like what you do in the platform.txt. Also, if you use the Eclipse IDE it can create a new project from a makefile. I used that feature fairly painlessly to import the cubemx files into standard eclipse and compile them.
The only downside for use linux users .. the current version of cubemx fails to create some of the required files needed for the TrueStudio code generation. I had to run to windows cubemx version to generate the files but then I used the python script from linux to do all the conversion.
* more info here *
https://my.st.com/public/STe2ecommuniti … tviews=291
-rick
What is exactly failing on Linux ? Can it be fixed ?
I did a compare between the True Studio ld file and the SW4STM32 I chose to use. There are no differences other than the boilerplate header at the top.
Last I saw in the ST forums, was that there are issues with case sensitivity on the non windows OS platforms. This may not be allowing some paths to be generated.
As I noted in the wall-o-text thread, I find that if I generate all libraries first, then switch to only include libraries, I get some of the missing sections like the gcc startup paths with the small s type that has to be made to a large S for the Arduino build system to find.
I have not tried eclipse or the OpenSTM32 yet. OSTM does not seem to have a lot of traffic, and you have to register to browse. There is an older thread regarding OSX and the installer seems to want to run as windows binary. Eventually I may want to use OSTM for more serious project. For now I can blink LEDs and send serial strings with the ArduinoIDE.
The utility does look interesting. I do miss having a GUI debugger, although I think these are 3rd party plug-ins under eclipse.
the TRUEStudio is creating a zero sized .ld file under OSX.
I option copied the .ld from SW4STM32 and renamed it. From my experiments on windows (I thought I made this on the mac) The files are identical other than boilerplate.
The python script complained about ‘Unknow source file type: Drivers/CMSIS/null’ so I hacked it out with comments. The makefile and ld were generated. Both look reasonable. May attempt an import into my crippled eclipse.
Will see what happens next.
I had to manually check and set the paths in about half a dozen locations by right clicking on the various project files to open various different properties dialogs, which do not always reflect the same values of the properties or preferences dialogs. Similar things will need to be done with OpenOCD and gdb connections.
I am probably confounded in that I am running this under OSX 10.7.5 and chose to point things to the Arduino.cc installed tools rather than download a second set of tools. The Arduino.cc tools still seem to be built with compatibility back to 10.7.5.
(OT) I am trying to stay with 10.7.5 as long as I can as Apple pulled MIDI support from QuickTime (should really be now called Quartz graphic GPUTime) in the newer OS revisions. This breaks being able to play MIDI from the finder by just hitting a space bar. With 10,000+ midi files on my drive, I like being able to browse MIDI from coverflow/Quicklook.(/OT)
This breaks being able to play MIDI from the finder I have just installed the latest STM32CubeMX and generated the test code (OsX Sierra)
Then I tried to generate a Makefile:
./CubeMX2Makefile.py ../test
Below there is the diff. It could be helpful.
--- a/CubeMX2Makefile.py
+++ b/CubeMX2Makefile.py
@@ -138,7 +138,7 @@ def main():
root = tree.getroot()
# MCU
- mcu_node = root.find('.//toolChain/option[@superClass="fr.ac6.managedbuild.option.gnu.cross.mcu"][@name="Mcu"]')
+ mcu_node = root.find('.//tool/option[@name="Microcontroller"]')
try:
mcu_str = mcu_node.attrib.get('value')
except Exception as e:
@@ -166,7 +166,7 @@ def main():
c_defs_subst += ' -D{}'.format(c_def_str)
# Link script
- ld_script_node_list = root.find('.//tool/option[@superClass="fr.ac6.managedbuild.tool.gnu.cross.c.linker.script"]')
+ ld_script_node_list = root.find('.//tool/option[@name="Linker script"]')
try:
ld_script_path = ld_script_node_list.attrib.get('value')
except Exception as e:
https://github.com/sheepdoll/XSTMScrips.git
The script is written in the PostScript language and optimized for running through the Ghostscript interpreter. https://en.wikipedia.org/wiki/Ghostscript for more info https://www.ghostscript.com/ for the community pages.
I use postscript as a general purpose language such as most people would use python for. I prefer postscript for such scripting as it can parse hex and binary files directly. This tool was written for my personal use. For a more general audience I would recommend re-writing it as python.
Some notes on reading the github code. As there is only one file I would recommend reading it from inside the github as cloning it will make the script unreadable or an attempt to launch a CUPS viewer such as preview on the mac. (which for security reasons disables the file system.)
Reading the code in the github file viewer also uses syntax color highlighting, which makes the code more readable.
PostsScript is stack based and RPN syntax so the operands are pushed onto the stack and popped by the operator. The classic example is to add 2 number the syntax would be 2 2 add which would leave 4 on the top of the stack.
Postscript also uses Key value dictionaries like a SQL database. (why I love the language so much.) Dictionaries are pushed onto the stack. These can be created explicitly with a count such as 10 dict. The operand 10 is left over from Version 1 this is how many keys are in the dict.
To make the dictionary the current one the operator ‘begin’ is used to “open” it. Any key in the dictionary can be directly referenced. when the dictionary is open. to close a dictionary the operator end is used. There is a separate dict stack and objects can be found from any open dict. Dicts are similar to c++ objects.
Dicts can also be created with the ‘<<‘ and ‘>>’ I call these french quotes. They are not shifts or stream markers.
Names in postscript are preceded by a slash so /nameExample is a reference these are pointers to object. Pushing nameExample on the stack will load the value from any open dictionary. The operator ‘def’ is used to associate a name with an object. Name keys are not executed until the def is read.
Code objects are nested inside braces ‘{}’ these are executed when the name is loaded.
String objects are contained inside parathisis. ‘()’
Arrays are inside brakets ‘[]’
comments are preceded by a percent ‘%’
The top part of the github code are extensions that are mostly macros used for viewing dictionaries, Hex, binary and floating point data.
The real code starts around line 375 (\033[0;32m) print This is some code that makes the back channel print green text using ANSI escape sequences. Print ‘=’ and ‘==’ operators all write text to the back channel.
I also wrote some more readable file writing extensions that allow me to format the backchannel or re direct it to a printed page or file.
I named these writlin adn writef
Postscript is known as the self un-documenting language So I expect that few here will be interested in this code. I personally find it useful and find Python to be backwards and hard to follow due to the lack of code blocks and the needless use of indentations.
I wanted this code to also be able to create the pin name table code. That will require more work as I need to according to the person I talked to at STM to look inside the cube databases themselves. Ideally this tool would be directly part of the Cube Code generation, Or ST should provide hooks to generate code for any IDE from these setup files. Currently ST seems to think the user will copy the code from the code databases “repository” directory where the examples are stored. Some of this is generated automatically, Which is of minimal use as the peripherals are only partially configured.
I am still working on extending this code to create board.txt and platform.txt. Most likely that will be a separate script added to the Github folder when it is ready.
