Development Blog 2.2
From AVR-Eclipse
Here you can find some progress reports for the AVR Eclipse Plugin Version 2.2
Version 2.2 was released on June 18th, 2008.
Contents |
[2008-04-19] AVRDude properties
It has been some time since the last blog entry, so I would like to show you what has happened since end of March. Please note that this is still a preview, and while most things work just fine there is still a lot of little things to program, like usable error messages, warnings etc. My current estimate for a beta release is in early May, but as this is a spare time project I will not promise anything.
Most changes since the last preview have been with the AVRDude support.
Here are some screenshots to show you how it will (probably) look. They are all from the project properties dialog, and all settings can be either for the whole project or for a single build configuration (for the power users amongst you)
Selecting the AVRDude item in the project properties will give you four new tabs with properties. The first one is to associate a programmer with the project and set some MCU specific options:
Notice the AVRDude command line preview at the bottom? Here you can see how the avrdude command line will look like in realtime. All changes to any property are immediately shown.
The next screenshot is from the Flash & EEPROM tab:
On this tab you can set if you want to upload an Flash or EEPROM image file. The filename is either taker from the project (from build) or can be selected directly. For example this could be used to have a single EEPROM image file for multiple build configurations.
In this example the Flash file name is taken from the current build configuration, while the name of the EEPROM file is set directly. I have used some variables in the name for the EEPROM file, which have no other purpose than to show how this could be used.
Next we have the Fuses tab. This I am still working on, so it might look different in the upcoming release.
I will probably remove the from fuses file part temporarily, because currently there are no fuses files and adding them to the plugin will take some more time and I would like to get the 2.2 release out of the door as soon as possible. So initially only direct entry of fuse byte entries will be possible. A fusebyte editor is in the works, but I rather spend my time on getting the avrdude support ready.
The last tab has some settings that you probably never need, but are there just in case:
What is still missing are the Lockbits. I will add them as soon as the fuses section is finished and they will be in the 2.2 release, but again without an editor.
Now you know how to set the avrdude properties. But how is avrdude executed? I have planned for two ways. The first one, already working, is to execute avrdude every time a build is performed.
As uploading does take its time, you probably don't want to call avrdude for every build. In this case deselect the avrdude tool and manually start the avrdude upload via an (not yet existing) menu entry.
Well I hope you got a good impression of whats coming up with the AVR Eclipse Plugin. Again, your feedback would be welcome.
What I could need at the moment (except for more spare time) are some nice icons for the tabs. I could do them myself, but that would take another day I rather spend coding. So, if you are somewhat of an artist, please contact me.
- Innot Apr 19, 2008 10:40 am
[2008-03-23] Project Properties for Build Configurations
There were some requests to make the target hardware properties (MCU type and FCPU frequency) again changeable per build configuration (like it was in 2.0).
The problem is, that the internal data structures of a CDT build configuration are not flexible and very limited in adding additional properties. While the two target hardware properties could still be managed as Configuration options, adding all the properties required for AVRDude would have been not impossible but rather ugly. Therefore I removed the AVR specific properties from the Build Configuration and handled them separately. (If you are curious: They are stored in the ".settings" folder of your projects)
To handle those properties for each Build Configuration requires quite a bit of code. Especially because not everyone needs the properties for each build configuration, so project wide settings was an absolute requirement.
But I have been working on this lately and have made some progress. Here are two screenshots on how this is handled now:
This is the main AVR project properties page. On this page you can select if you want to have separate properties for each build configuration. The default is off, which means that all settings are applied to all build configurations.
The next screenshot shows the Target Hardware properties page:
Here the "individual settings for each Build Configuration" option has been set (otherwise the top part would have been disabled). The top part, where the build configuration is selected / managed, is the same as for the other C/C++ Build pages (they are even synchronized). So in this example the Debug configuration would use an ATmega16 with 1MHz as a target hardware. The "Release" configuration or any other custom configurations could have different MCUs and/or Clock values.
BTW the ugly little gap between the MCU Type and the MCU Clock Frequency is intentional. A warning is displayed in it when a MCU Type is selected, that is not supported by avrdude.
As the framework for this is finished and seems to run well, adding more property pages (for AVRDude) will be much simpler and should not take more than a few days.
- Innot Mar 23, 2008 6:29 am
[2008-03-10] AVRDude support
I have been thinking a lot on how to get the best integration of avrdude in the plugin. The goal is to make usage of avrdude as simple as possible for AVR novices (like me) and still have all options available for you powerusers who have a dozens of different Programmers and hundreds of AVR processors you like to program.
For now I have decided to split the avrdude configuration in two parts:
- Everything that is releated to the Programmer device(s) is set up in the Eclipse preferences.
- Everything that is related to the actual processor will be in the Project properties.
I have started with the global preferences and have them basically finished (see screenshots below) Next I will start with the project specific properties. One of the project settings for avrdude will be the programmer configuration, so each project or even each build configuration can use its own programmer (or all use the same programmer if you only have one)
The AVRDude Preference Page
On this Page you can enter the path to a custom avrdude config file (the -C option) and manage the list of all your programmer configurations.
If you add a new configuration or edit an existing configuration the following dialog will let you edit the details of a programmer configuration.
The AVRDude Programmer Configuration Dialog
Here all relevant options (I hope) for a programmer can be edited. If you think that something is missing please drop me note.
(Yes, I do know that these settings do not make sense, they are just an example to show what the dialog can do. I thought about adding a few more validity checks, but I think they are not worth the effort)
- Innot Mar 10, 2008 4:13 pm
[2008-03-10] The MCU List View
This started as a tool for debugging. I needed a tool to get a quick overview if avrdude and some other modules used in the Plugin were returning good values. However I thought that this would be quite usable for everyone starting a new project, so it has become a full feature of the upcoming 2.2 release. This View shows a list of all known AVR Processors and whether they are supported by a tool.
BTW, clicking on a MCU Name (those which are shown as links) will download and open the datasheet for the MCU.
This last feature did cost me a few days of development time, because Eclipse/SWT tables cannot display anything other than images and texts (which I didn't know when I started this), so a lot of trickery was necessary to get clickable links in the table. But I think was worth the effort (I like looking at datasheets :-))
I have yet to test it with Linux (or other non-Windows platforms), but I am optimistic that it should work everywhere.
The signatures are derived directly from the Atmel Partdefinitionfiles if you have them installed. Otherwise a default list is used.
- Innot Mar 10, 2008 4:13 pm
