Most desired upgrades and enhancements for MikroE compilers

[steve42lawson]

Hi mikroe Team, something very important is missing in that list. A tool to generate defs files for new MCU. This has been requested many times. Then we don't have to wait 2 years or more to use new devices...

I third that! Would be VERY useful!!

[Soumitrab]

Hi ME Team

I would like to see the following upgrades in the compiler :
a) Support for pre-initialized variables passed as method parameters. Eg: function DoThis(x: Byte = 0);
b) All declared numerical variables should be automatically set to 0 if not explicitly initialized.
c) Support for set type enumeration
d) Library method overloading
e) Class based object structure

Editor:
a) Option for placing and going to bookmarks via right-click menu/gutter bookmark click
b) please please put the animation of panels as an option. If unchecked , do not perform silly translation animation
c) Panels to be preferably drag-drop dockable
d) Does not accept and open dropped *.pas files even though drop target setup is present

Thanks

[steve42lawson]

• Ability to set fuses via compiler directives rather than Edit Project
• Support for inline functions.
• Improved/corrected documentation

And one not on the list -- one that is a bane for me every time I "create a new Project version":

When a Project is "Save As"ed to a new name [such as to create a new version of the Project], the Search Path(s) are not preserved! So, I have to go in and reconnect these path(s), which is a pain! This, and the fact that one CAN'T set fuse directives, in the code, are the two biggest problems I have with your product. It makes it difficult to preserve the integrity of a project that might need to be moved/copied to a different station [e.g. collaboration], or even, ported to a different platform! The fact that the fuse directives are missing from the code, means the code integrity is vulnerable. One means for improving said integrity, might be including the intended fuse settings in a comment, but what a royal pain that is!

The lack of the ability to inline functions is a close second. The way I work around that, currently, is to define a macro version [below the function definition] of a function that needs to be inlined. Another total pain!!

The function definition form, preserves the full intent of the function's structure, which can be made arcane by a conversion to MACRO form -- plus, I think better in the function definition format, and find a function easier to debug, and edit, than is a MACRO. Thus the reason for having, and preserving, a function definition form [that is echoed by the MACRO form]. Also, a MACRO lacks features of the function, like type checking.

[kvlada]

Can we please, PLEASE for once, get fuse configs as compiler directives?

I'm simply tired of having to setup all the fuses manually each time I have to compile software for a different chip. And of course you make a mistake, after 348th manual setting of 999 combo-boxes (plus frequency), you make a mistake and then spend 30 minutes debugging the code, while the problem is in one single wrongly set fuse.

Please ME, is this too much to ask?

Maybe the solution is for compiler division to switch to "yearly upgrade" sales model?

I know many people wouldn't mind paying 50 - 100€ every year to be happy with their compiler.

[adamto99]

• Ability to set fuses via compiler directives rather than Edit Project
• Support for inline functions.
• Improved/corrected documentation

audacity temp mail origin
And one not on the list -- one that is a bane for me every time I "create a new Project version":

When a Project is "Save As"ed to a new name [such as to create a new version of the Project], the Search Path(s) are not preserved! So, I have to go in and reconnect these path(s), which is a pain! This, and the fact that one CAN'T set fuse directives, in the code, are the two biggest problems I have with your product. It makes it difficult to preserve the integrity of a project that might need to be moved/copied to a different station [e.g. collaboration], or even, ported to a different platform! The fact that the fuse directives are missing from the code, means the code integrity is vulnerable. One means for improving said integrity, might be including the intended fuse settings in a comment, but what a royal pain that is!

The lack of the ability to inline functions is a close second. The way I work around that, currently, is to define a macro version [below the function definition] of a function that needs to be inlined. Another total pain!!

The function definition form, preserves the full intent of the function's structure, which can be made arcane by a conversion to MACRO form -- plus, I think better in the function definition format, and find a function easier to debug, and edit, than is a MACRO. Thus the reason for having, and preserving, a function definition form [that is echoed by the MACRO form]. Also, a MACRO lacks features of the function, like type checking.

Fixing the code editor is absent in IDE improvement proposals .