UEStudio is installed with a WinAVR application configuration which you can use for your AVR programs. Just use the WinAVR compiler for your project and set the compiler options to your needs. You may need to adapt the compiler configuration template by making a local copy and edit some lines in the compiler configuration.

Debugging could be very difficult if not at all completely impossible from within UEStudio because debugging ATmega controllers is in-circuit debugging and as far as I know there is no stand-alone debugger available for the ATmega series. So for debugging you might need to use AVRStudio.

Programming the ATmega after successful compilation can be done definitely from within UEStudio. How depends on the hardware and tools you use. For example AVRDude installed with WinAVR or installed separately could be executed by UEStudio automatically after a successful build or manually by you to program the code and data into flash and eeprom of the Atmel AVR controller.

Years ago before UEStudio was released the first time I created with UltraEdit a project for coding a program with finally 1500 lines for the Atmel ATmega8515 and AT90S8515 controllers using ICC AVR compiler. After reading the manuals it was no problem for me to setup project tools for compiling the application for both controllers from within UE and and to write the two scripts to program the application into the two controllers using PonyProg from within UE. I did not need debugging. Nowadays I would use UEStudio, WinAVR and AVRDude. But I did not need to write code for ATmega controllers in the last years and therefore have not setup an appropriate configuration in UEStudio.

When you have chosen the WinAVR compiler for your project and the compiler options opened for example via Build - Set Compiler Options are not enough, you next better click on Build - Select Compiler.

In this dialog WinAVR - Application should be already preselected. Click on button Edit Configuration.

What you should first do is pressing button Make Configuration Local (Save in Project Directory) to avoid editing the WinAVR application configuration file in the configs subdirectory of UEStudio which is updated when updating UEStudio.

Alternatively when you will later need that configuration also for other projects, you can create in the configs subdirectory a new directory, for example My_WinAVR, and copy the standard WinAVR application file from subdirectory WinAVR Compiler into directory My_WinAVR.
Also possible is to just copy file Application in directory WinAVR Compiler into the same directory with another name like MyApplication.
Both alternatives make it possible for you to create your own configuration which you can use for all of your projects without be worried about overwriting the configuration on update of UEStudio.


As far as I know there is no better documentation for creating a compiler configuration file than what is found in help of UEStudio. So I write here some additional hints.

At top of the configuration file there are some comment lines which list the standard variables UEStudio offers for being used in the configuration. I think, I don't have to explain them more detailed.

What you see next are various sections [...] with various commands in the format name = value. What the sections are for and which commands are possible is explained in help of UEStudio. Open the help and select the tab Index where at top all the compiler sections are listed. Hint: Read the help pages for the sections in the order you can see the sections in the configuration file and not in alphabetical order as listed on help Index.

Take the time and read the help for the sections with using existing WinAVR or other configurations as reference. Most is quite easy to understand.

Of course you surely need also all the help files of WinAVR. Such a configuration is definitely not created in 2-3 hours because lots of text must be read, understand, used and the created configuration also tested. But the time spent is a good investment when the custom compiler configuration is finally working perfect for your needs and helps you in future working faster than with AVRStudio.

If you need detailed help for a specific configuration command or problem, please ask here in the forum or IDM support by email.

The error message is pretty clear for experts in C and C++ programming. None of the project source files (*.c, *.cpp, ...) contained the function main, i.e. a block like
If you have just one source file in your project, it is possible to compile the code in this source file to an object file without any error as you most likely do on Windows command line. UEStudio has also the command to just compile active file, i.e. compile a C/C++ source file to an object file. But on a project build the locating and linking phase of the configured compiler configuration is also executed. You use the WinAVR application configuration. An application must contain a function main. If no such function can be found during linking the object files to an executable, the linking process fails with this error message.

UEStudio is not an IDE for one or just some specific compilers as nearly all other IDEs. It is an IDE open for any compiler. It is even possible to create a configuration for a tool chain which does not compile a source code file to CPU instructions at all. Nearly all by default installed configurations for various compilers were created by UEStudio users and sent to IDM support. So those configurations are as good as defined by those UEStudio users. The help of UEStudio contains pages on how to create a configuration and how to customize a pre-installed configuration. But it does not contain any information about a specific compiler. Every compiler has a documentation or manual. Once having read the compiler's documentation it is usually not really difficult to create or customize a configuration for this compiler for usage in UEStudio which fit exactly to own requirements. GCC has really lots of options. The WinAVR application configuration contains just the most important once as I could see. So it is possible to extend the WinAVR application configuration.

However, it looks like you are already near to a working build with WinAVR configuration. You only don't have any source file in your WinAVR project containing function main.

If you need more help after adding the main function to one of your source files, please let me know with posting also version of UEStudio used by you and which user interface mode you are using, i.e. ribbon mode, toolbar/menu mode with contemporary menus or toolbar/menu mode with traditional menus, which makes it easier for me to guide you.

I suggest to first create a WinAVR project with just one source file like test.c containing only:
This simple project with no really useful code in function main should compile without any error or warning.

Dibor, you are using at the moment UEStudio 19 in toolbar/menu mode with traditional menus as I could see on the video.

Let me first describe section [General] and what .CPP = .C means and why I think it was not good to add this line to this section.

The help contains on tab Index the list item [General] Compiler Section. Double clicking on this index list item opens the associated help page. It contains at bottom the line:

The remaining optional keys are for example .CPP=.C and are explained in the [.EXT] section.

The link at end opens the help page [.EXT] Compiler Section which explains the section [.C] in WinAVR application configuration. This EXECUTIVE section contains the instructions what to do with a single file according to its file extension on Compile, Build or Rebuild all.

The WinAVR application configuration contains:

[.C]
Out = $In.o
ReleaseFlag = $(Optimization)
DebugFlag = -g -O0
Cmd0 = $(Compiler) $R $(COPT) -c -o $O $I

IncFiles = 1
CaseSensitive = 1
IncDirs = .;$(INCLUDE);
IncKeyWords = #include;
Comments = /*.*/.//.eol.

Out means an output file should be created and the name of the output file is defined with $In.o. $In is a variable reference and its meaning can be read in comment block at top containing $In- input name. So for a file like 13cm.cpp the variable $In expands to 13cm and appended is the file extension .o (object file).

The compilation from source file to object file is done with the flags for a release build or for a debug build.

For a release build the optimization flag as referenced with $(Optimization) is defined by opening from menu Project the Project settings... dialog and clicking on tab Settings on button Compiler options and double clicking in section C/C++ COMPILER OPTIONS on last item Optimization to select the optimization level resulting in using -O0 or -O1 or -O2 or -O3 or -Os. The Compiler Options can be also opened by clicking in menu Build on Compiler options. The manual of gcc/g++ contains the description of the optimization flag -O. The WinAVR application configuration contains in the sections [Settings], [SettingsInfo] and [SettingsReps] a line starting with Optimization = which defines this compiler specific option for easy configuration by the user via the Compiler Options dialog.

For a debug build the optimization flags are defined fixed with -g -O0 which means generate debug information and do not optimize the code which is standard for C/C++ compilers for a debug build.

Release or Debug build is defined in Project Settings dialog on tab Settings in group Build mode or with the selector on toolbar Build. The directory into which the files are created during build process can be customized by clicking on button Compiler options and define both at bottom of the the dialog window. The debug and release path the user enters here is interpreted as relative path to project directory as defined for the project as written in dialog window at bottom.

The last line with Cmd0 defines the command line written into the project.mak file generated by UEStudio for a Build or Rebuild all respectively is the command line executed by UEStudio on using Compile to compile just the active source file to an object file.

$(Compiler) references the compiler option with name Compiler. The user of the WinAVR application configuration can define in the Compiler Options dialog in section COMPILER OPTIONS which compiler executable to use: avr-gcc as used usually for C files or avr-g++ as used usually for C++ files. See also What is the difference between g++ and gcc?

Well, most projects consist of only C source files or of only C++ source files. A mixed usage of C and C++ source files in a project is rare. So it is usually okay that all files of WinAVR project are compiled according to section [.C] with the compiler set once by the user in the Compiler Options dialog. However, I would have written into the WinAVR application configuration:

[.C]
Out = $In.o
ReleaseFlag = $(Optimization)
DebugFlag = -g -O0
Cmd0 = avr-gcc $R $(COPT) -c -o $O $I
IncFiles = 1
CaseSensitive = 1
IncDirs = .;$(INCLUDE);
IncKeyWords = #include;
Comments = /*.*/.//.eol.

[.CPP]
Out = $In.o
ReleaseFlag = $(Optimization)
DebugFlag = -g -O0
Cmd0 = avr-g++ $R $(CPPOPT) -c -o $O $I
IncFiles = 1
CaseSensitive = 1
IncDirs = .;$(INCLUDE);
IncKeyWords = #include;
Comments = /*.*/.//.eol.

Do you see the differences?

The compiler executable to use is defined fixed for C source code files as well as for C++ source code files. So the three lines starting with Optimization = in the sections [Settings], [SettingsInfo] and [SettingsReps] would be no longer needed and the user would not need anymore to select in compiler options which compiler to use for the project. And for C++ source code files the general C++ options as defined by variable CPPOPT in section [Variables] would be used instead of the general C options as defined by variable COPT in same section. I think, whoever wrote this WinAVR application configuration used it only for C and not for C++.

$R references the flags as defined by ReleaseFlag or by DebugFlag in the EXECUTIVE section according to build mode.

-c is a gcc/g++ option which means compile input file to an object file.

-o is a gcc/g++ option to define name of output file of which name is specified next with $O referencing output file name as defined with Out in same section and being created in current directory which is either the configured debug or release directory and which is set by UEStudio on executing mymake.exe in program files directory of UEStudio with the project.mak file generated by UEStudio.

$I references the full qualified file name of the source code file to compile.

The other settings are explained in help and usually don't need to be modified for any C/C++ compiler.

But for reasons which I have never understood there are programmers which invent file extensions for their source files different to the standard *.c for C source files and *.cpp for C++ source files. For that reason the section [General] contains a mapping list of file extension to EXECUTIVE section.

Therefore the lines
mean that all files with a file extension as written left to the equal sign should be processed with EXECUTIVE section [.C] as defined in the WinAVR configuration.

It can be seen here that this list was created based on Visual Studio configuration because I am quite sure that no C/C++ programmer for AVR controllers gives ever the C/C++ source files the file extension .ADB or .JAVA or .FOR (FORTRAN) although gcc supports also JAVA and FORTRAN compilation.

I think once again that the UEStudio user creating the WinAVR configuration has never really thought about C++ WinAVR projects or a WinAVR project with mixed C and C++ source files as otherwise the configuration would be really written as I wrote above with file extensions .C++, .CC, .CP assigned to EXECUTIVE section [.CPP] and variable CPPOPT would be defined as set for C++ COMPILER OPTIONS which make really sense and work for AVR controller compiled with avr-g++.

---

The issue with wrong relative paths of the warnings output by avr-gcc or avr-g++ (can't see which compiler you have configured in compiler options) is not easy to reproduce by me with having WinAVR compiler not installed at all and not having your WinAVR configuration and project file.

Please pack into a 7-Zip, RAR or ZIP file archive file:

1. WinAVR application configuration file as used by you now,
2. the UEStudio project file trx_control.prj,
3. the UEStudio project user interface file trx_control*.pui and
4. the makefile trx_control.mak generated by UEStudio in subdirectory Debug of your project.

For the makefile click in menu View in submenu Views/lists in submenu Toolbars on menu item Build to make this toolbar visible. Then click on last item of toolbar Build with tooltip Commands to open a pop-up menu and click on last item Show makefile to get this file opened in UEStudio. I am really wondering why the Build toolbar was not yet enabled by you as this is the most important predefined toolbar in my opinion on working with an UEStudio project with a compiler configuration in toolbar/menu mode.

Your (later deleted) video does not show any of the lines on which avr-gcc/avr-g++ output a warning. So I can't really recommend you an alternate code line to avoid these warnings.

So I looked on your project and the WinAVR application configuration and improved both after installing also currently latest WinAVR version 20100110. The work on WinAVR application configuration is not yet finished as I want to add even more options. But it is good enough to give it to you.

The relative path issue is easy to explain. UEStudio creates the *.mak file as much as possible with all files referenced with a relative path to the directory on build which is either subdirectory Debug or Release in project directory. avr-gcc.exe and avr_g++.exe output warnings and errors with the file names as specified on command line which means with the relative paths. But UEStudio interprets relative paths in output window by default always relative to project directory and not to a subdirectory of active project. For that reason there is one ..\ too much in the warnings in output window.

There are three possible solutions:

1. Right clicking into output window to open context menu, left clicking on context menu item Set default path for relative paths... and selecting subdirectory Debug or Release of the project directory.
2. Changing value of configuration setting UseFullPaths in section [General] in WinAVR configuration from 0 to 1. Then UEStudio creates the *.mak file with all files referenced with absolute (full) path. This setting affects only the *.mak file, not the project file of UEStudio which still uses relative paths and so the project can be easily moved to any other directory or drive.
3. The directory for Debug and Release is modified in Compiler Options dialog window to be the directory of the project. But this is only handy on having source and header files in a different directory and the project is build always with just one of the two predefined configurations.

I used the second option which is the best one in my opinion for your project.

I have never seen before a project on which a source file is included within a source file using #include directive. This is possible, but it should be really avoided for several reasons (symbol parser, locating warnings and errors, debugging). For that reason I modified your source files to avoid including the other two *.cpp files into main *.cpp file by creating appropriate header files for the two other *.cpp files. I created two groups in project settings, one for the three source files and another one for the three header files which looks better on tab Project of Workspace Manager view. Do you know the IntelliTip command .source -> .header which is the first command on IntelliTip toolbar? It can be used to open the appropriate *.cpp file on *.h file is currently active as well as the appropriate *.h file on *.cpp file currently active.

The warnings could be easily avoided by changing in the functions printf and sprintf the type of parameter format to const char *.

I added some compiler options to the WinAVR configuration which I will send finally also to IDM as a replacement of current WinAVR configuration to make it possible for WinAVR developers like you to customize the build process without editing the configuration.

The most important option added by me is WinAVR Version set by default to 20100110 and which can be modified by the user of this configuration to any other version string. It is unfortunately necessary that the user of the WinAVR sets the WinAVR version once in Compiler Options for the project because of the not very good design on how WinAVR installer stores in Windows registry where (latest installed) WinAVR is installed on the Windows PC. I will report details on what is not good done here later and how the installer corrupts (yes, really) the Windows environment on using default options to add bin and utils\bin to system PATH environment variable at the beginning. Well, it is at least documented in manual how the installer corrupts Windows environment so that at least the WinAVR compilation works from command line. Some other compilers and every other batch file using for example find do not work anymore as before installing WinAVR, but it looks like the WinAVR developers take that into account.

There is now among Compiler also C Compiler and C++ Compiler in Compiler Options for projects using mixed C and C++ source files. WinAVR is installed with some executables existing multiple times. The reason is well known for me. On Linux it is standard to use multiple file names for same file for unknown (perhaps historical) reasons and use symbolic links to have the executable file only once in file system. Those symbolic links are replaced by copies of the linked executable file on creating a package for Windows instead of ignoring the symbol links not really needed at all.

I added the compiler options Debug Options and Debug Optimization to WinAVR configuration and set them suitable for your project.

I fixed spelling mistake in compiler option Bitfileds by renaming this option to Bitfields. This modification in name of a compiler option will cause an incompatibility on WinAVR projects having used this option. But I think, it is nevertheless better to fix the spelling of this option. I fixed this option also in your project file containing now only Bitfields.

I added additional values on option Language Standard, added compiler option C++ Compiler Option to give the user a place to define any set of C++ specific compiler options in addition to Compiler Options used for C and C++, and added lots of warning options with information copied from documentation. The warning option -Wall is enabled already for your project.

The WinAVR configuration updated by me is now part of your project. The project does no longer use the WinAVR configuration in configs\WinAVR Compiler\ in program files folder of UEStudio because of your project depends on the modifications. The standard WinAVR configuration in configs\WinAVR Compiler\ in program files folder of UEStudio is overwritten on updating UEStudio in future. For that reason a standard configuration of UEStudio should be never modified, only a project specific configuration. Well, I hope my enhanced WinAVR configuration will become in future the standard WinAVR configuration.

I do not understand what is the problem. The Rebuild all was successful with 0 errors and 0 warnings. So updated project with updated configuration works also on your Windows PC perfect.

Double clicking on a line in output window makes only sense for those lines starting with a file name without or with a relative or absolute path, having next a line number and and then an error message or a warning. Then UEStudio parses this line in output window for file name without or with relative or absolute path and for the line number, opens this file and sets caret to beginning of the line according to line number in output window. Double clicking on pure information line not containing any error or warning message is therefore absolutely nonsense.

What do you expect from UEStudio to do with a line containing just an information like the summary information after a successful build?

What do you mean with run project?

UEStudio is for compiling the source files and nothing else. There is no built-in interface in UEStudio like in AVRStudio to work with hardware connected to a USB device configured first by the user and which connects the AVR controller on a board with the PC for programming and perhaps even for debugging.

Installed with WinAVR is also old version 5.10 of Avrdude. The currently latest version of this tool to program AVR controllers using a USB programmer is version 6.3. When you have an USB programmer for AVR controllers and have installed the drivers for this USB device, then you can add in section [Build] more command lines to create the Intel HEX files automatically after a successful build and run Avrdude to program the new code using the Intel HEX files into the controller.

The author of WinAVR configuration has added four commands for manual execution at any time by clicking on Build toolbar on last item Commands which are for your project: Make project.HEX, Make project.BIN, Make project.SREC and Make HEX/BIN/SREC. More commands for manual execution can be added by adding them to project specific WinAVR configuration. But those commands could be also executed automatically on build process as additional commands in section [Build] with Cmd2, Cmd3.

It is up to you what is done on a build by UEStudio and what is executed by you manually. You can also configure project tools which I prefer over commands stored in a compiler configuration because of those commands have usually nothing to do with the build (compilation) process and are very often really project dependent. Project tools can be executed by key and can be added to toolbar for easy execution by mouse with one click.

As I coded many years ago for an AVR controller as UEStudio was not available using UltraEdit with compilation of the project using a project tool calling a batch file for compilation, I wrote one more batch file which executed PonyProg (Avrdude was not available) to program the code and data into the AVR controller and next started a terminal program which connected the serial COM of the PC with the serial COM of the board with the AVR controller. My code output messages via serial interface and also executed commands which I entered in terminal program which sent it via serial interface to the AVR controller. I did not need a debugging interface. The source code files had just a few thousand lines and so in-circuit debugging was not needed by me.

Dibor, do you know the commands Next message and Previous Message with their default key assignments Ctrl+Shift+Down Arrow and Ctrl+Shift+Up Arrow as displayed in context menu of output window after clicking with right mouse button into the output window?

These are the commands which are best for fixing code resulting in a warning or an error on compilation as seen in output window. On pressing Ctrl+Shift+Down Arrow with output window containing warnings and error messages of previous build and with input focus set on window of any opened file, UEStudio searches in output window for next line with a file name and a line number, opens this file or make it active on being already opened, and set the caret to beginning of the line of which line number is shown in output window. So using this feature makes it possible to fix the code producing warnings or errors without moving the hands from the keyboard.

UEStudio tries always its best on parsing a line double clicked by the user and informs the user about the result. UEStudio does of course not understand the text of the double clicked output line. So UES cannot determine if a line contains just pure information for the user or a warning or error message with a file name and a line number. But if the user explicitly double clicks on a line, UEStudio assumes this line contains a file reference and tries to find out based on rules (code) what could be the file name and where the file could be stored and finally informs the user about success or failure on locating and opening the file. The commands Next message and Previous message ignore all lines on which UEStudio fails to determine the name of a file and its storage location. But an explicitly double clicked line results always either in opening the file and setting caret to the line as parsed by UEStudio or in an error message if no file could be found according to the line in output window. The error message is useful as it has proven before in case of a source file is referenced with a relative path and UEStudio fails to find the file with this relative path because of assuming a different directory as base path for the relative path. So the error message shown on double clicking an output line with real file name helps users to find out what is going wrong on relative path interpretation.

Please note that it never makes sense to double click on an error line containing a linker error message referencing an object file. A programmer cannot fix the binary object file. He has to fix the code which results in an object file which could not be successfully linked together with other object files to a library or application. The only information a programmer can use from referenced object file in a linker error message is the file name without file extension as the source code file producing this object file has most likely the same file name. This is one of the reasons why source code files should not be included in another source code file. It is easier to find out what is wrong in a source code file causing a linker error if each source code file is compiled first to an object file of which name is identical to the source code file name.

---

I had the same issue as you on making more edits on project specific WinAVR configuration using Select Compiler window. I think, there is a string length limit of 32768 bytes or something similar for the multiline rich text edit field in the dialog. Everything is displayed, but editing behavior is indeed strange. I will report this issue to IDM support by email once I have finished the WinAVR configuration. If this limitation is not caused by the used Microsoft library, then I hope the UEStudio developers fix that issue in a future version of UEStudio.

In the meantime simply open the configuration file directly in UEStudio like any other file. It is a pure text file and so edits on configuration can be done also like on any other text file without using Select Compiler dialog window. There is no syntax highlighting on opening the file as text file in UEStudio by default, but you can apply any suitable syntax highlighting. I use the syntax highlighting for setting files (*.ini, *.inf) for editing the configuration file.