User forums > Embedded development

C Compiler features worth copying from other IDEs

(1/1)

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

oBFusCATed:

--- Quote from: stahta01 on March 10, 2014, 03:14:04 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.

--- End quote ---
What should $device do?
I'm not interested in digging in Em::Blocks...

stahta01:

--- Quote from: oBFusCATed on March 10, 2014, 10:22:47 pm ---
--- Quote from: stahta01 on March 10, 2014, 03:14:04 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.

--- End quote ---
What should $device do?
I'm not interested in digging in Em::Blocks...


--- End quote ---

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.

oBFusCATed:

--- Quote from: stahta01 on March 10, 2014, 10:32:21 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.

--- End quote ---
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.

scarphin:

--- Quote from: oBFusCATed on March 10, 2014, 10:57:55 pm ---
--- Quote from: stahta01 on March 10, 2014, 10:32:21 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.

--- End quote ---
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.

--- End quote ---
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.

Navigation

[0] Message Index