Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
Development / Re: RFC: Backticks
« Last post by ollydbg on Today at 12:09:25 pm »
FYI:

I recently found that msys2 has a nice tool named pkg-config, which is located in msys2_root/mingw64/bin/pkg-config.exe

Now, I see in code::blocks, it can support many libraries. For example, if you want to link opencv library.

You just have to add one line in compiler options in C::B build option

Code
`pkg-config --cflags opencv4`

and in library options in C::B build option

Code
`pkg-config --libs opencv4`

Really nice feature, also, I think it should also work under Linux. :)
2
Embedded development / Re: C::B for Microchip MCUs?
« Last post by stahta01 on Today at 03:35:41 am »
FYI: The SDCC only supports a very small sub-set of Microchip MCUs.

Tim S.
3
Embedded development / Re: C::B for Microchip MCUs?
« Last post by AndrewCot on Today at 01:55:54 am »
A google search on "codeblocks PIC compiler" returned the following pages that should help you out configuring CB with SDCC for use with PIC uControllers:

https://wiki.codeblocks.org/index.php/Using_the_Code::Blocks_IDE_with_SDCC_on_PIC_MCUs
http://www.iearobotics.com/wiki/index.php?title=CodeBlock_IDE_and_PIC_microcontrollers

If you do not know what SDCC is then have a look at the following main SDCC page:
http://sdcc.sourceforge.net/

You can search the CB forums for "SDCC" or the compiler you want to use to see if there are details on configuring it for use with CB.
4
I am really me and I am here ... definitely "slowandsteady"

Give me 18 months, and in return I give you a competent C++ programmer.
5
Embedded development / Re: C::B for Microchip MCUs?
« Last post by oBFusCATed on Yesterday at 03:28:27 pm »
What support do you need?
It should currently be possible to do this if you do these steps:
1. Install the compiler
2. Set it up inside codeblocks
3. Create empty project which uses this compiler
4. Add files
5. Setup build options for your device
6. Add post build commands to do firmware gathering or/and upload in your environment.
7. enjoy

If you need to do these steps often you can write a wizard template script which automates the stuff above and then provide a patch for inclusion in the C::B releases.
6
Embedded development / C::B for Microchip MCUs?
« Last post by knivd on Yesterday at 12:12:31 pm »
I quite like the Code Blocks environment and was wondering, is it not possible to include support for the PIC families in it? I can see a lot of other platforms are already there.
Thanks!
8
Development / Re: RFC: Backticks
« Last post by ollydbg on Yesterday at 05:50:56 am »
You don't need them there. wx-config works fine on linux as it is now.

The good news is that eranif's wx-config-msys2 tool also works well with our C::B's backtick system.

I try to add those lines in the "Other linker options"
Code
`wx-config-msys2 --libs --prefix=$(TARGET_COMPILER_DIR)`

And I got the final result of the linke command:

Code
-LF:\code\msys2-64\mingw64\\lib -pipe -Wl,--subsystem,windows -mwindows -lwx_mswu_xrc-3.1 -lwx_mswu_html-3.1 -lwx_mswu_qa-3.1 -lwx_mswu_core-3.1 -lwx_baseu_xml-3.1 -lwx_baseu_net-3.1 -lwx_baseu-3.1

The only issue is that for C::B, we have $(TARGET_COMPILER_DIR) translated to "F:\code\msys2-64\mingw64\", while, wx-config-msys2 expect there is no ending backslash for the path, so you see double backslashes in the generated command line.
9
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by oBFusCATed on Yesterday at 02:41:00 am »
Currently, the wizard presets the wxWidgets location to "$(#wx)". Perhaps it would be better to firstly check if a variable based on selected wxWidgets version (e.g. "$(#wx30)" for 3.0 and "$(#wx31)" for 3.1) exists and if it does use that. If it does not fall back to "$(#wx)". What do you think about this?
This would be useful for people which switch wx versions often or want to test them easily. I'm not sure this is generally useful. And as far as I know it is possible to change it in the wizard if you're in this kind of situation. So for now I think it is better that we don't add this feature.
10
Contributions to C::B / Re: Updating wxWidgets project wizard
« Last post by PB on June 21, 2021, 07:42:36 pm »
Generally I want to finish this pull request and commit what we have at the moment. Additional changes could be committed later as a second step.

I agree with this with perhaps one suggestion based on the discussion here or in the PR.

Currently, the wizard presets the wxWidgets location to "$(#wx)". Perhaps it would be better to firstly check if a variable based on selected wxWidgets version (e.g. "$(#wx30)" for 3.0 and "$(#wx31)" for 3.1) exists and if it does use that. If it does not fall back to "$(#wx)". What do you think about this?
Pages: [1] 2 3 4 5 6 ... 10