Author Topic: C Compiler features worth copying from other IDEs  (Read 5404 times)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6484
    • My Best Post
C Compiler features worth copying from other IDEs
« on: March 10, 2014, 03:14:04 pm »
I was just reading "Assembler tools for CB" http://forums.codeblocks.org/index.php/topic,19028.0.html

And, I decided adding the Assembler tools was too soon.

I think adding the $device from Em::Blocks (EMB) to the C Compiler would be a useful feature to the C Compiler that would help the Assembler when added.

Any other simple features that would improve CB C Compiler for embedded support?

I prefer features from open source IDEs or at least semi open source like the EMB project.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11643
    • Travis build status
Re: C Compiler features worth copying from other IDEs
« Reply #1 on: March 10, 2014, 10:22:47 pm »
I think adding the $device from Em::Blocks (EMB) to the C Compiler would be a useful feature to the C Compiler that would help the Assembler when added.
What should $device do?
I'm not interested in digging in Em::Blocks...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6484
    • My Best Post
Re: C Compiler features worth copying from other IDEs
« Reply #2 on: March 10, 2014, 10:32:21 pm »
I think adding the $device from Em::Blocks (EMB) to the C Compiler would be a useful feature to the C Compiler that would help the Assembler when added.
What should $device do?
I'm not interested in digging in Em::Blocks...


Nearly if NOT all Embedded C Compilers and Assemblers require a device or MCU type to compile or assemble code.
The  EMB uses $device as the tag in the C Compiler and/or  Assembler.
CB uses C Compiler flags like -mcu=MCUTYPECODE where  MCUTYPECODE is replaced with what EMB has as a $device field.

In some ways, the CB way is just as good; but, in many ways I think it would be cleaner to just choose the MCUTYPECODE portion without the compiler option prefix of  -mcu.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11643
    • Travis build status
Re: C Compiler features worth copying from other IDEs
« Reply #3 on: March 10, 2014, 10:57:55 pm »
In some ways, the CB way is just as good; but, in many ways I think it would be cleaner to just choose the MCUTYPECODE portion without the compiler option prefix of  -mcu.
Hopefully when we start to fully utilize the wxpropgrid component in the flags we will be able to just have a combobox with the list of devices or architectures supported by the compiler.
I don't think we need another tab for this.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: C Compiler features worth copying from other IDEs
« Reply #4 on: March 11, 2014, 04:32:24 am »
In some ways, the CB way is just as good; but, in many ways I think it would be cleaner to just choose the MCUTYPECODE portion without the compiler option prefix of  -mcu.
Hopefully when we start to fully utilize the wxpropgrid component in the flags we will be able to just have a combobox with the list of devices or architectures supported by the compiler.
I don't think we need another tab for this.
I agree, a dedicated tab for the device would clutter the interface imo and won't apply to all the supported compilers. In the end the device (and the valid devices list) should be specific to the compiler/assembler and it is not needed for a desktop compiler.
Afaik current implementation lets the user to choose the device from a list in the project wizard related to the architecture (avr and mcs51 versions at least). I think this is the way it should be as choosing the device from somewhere else can interfere with the wizard script and worse result in a device mismatch.
But Tim has an important point here. The device should be defined somehow for an embedded compiler to perform any operation. The only place I can think of that a device won't be defined initially is an 'empty project' with an embedded compiler where the user is left to configure project settings manually. New project wizards for supported compilers might overcome this problem though.