Menu
▾
▴
avr-eclipse-user — General discussions and support for the AVR Eclipse plugin
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
(5) |
Mar
(17) |
Apr
(8) |
May
(6) |
Jun
(5) |
Jul
(23) |
Aug
(22) |
Sep
(7) |
Oct
(8) |
Nov
(14) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(15) |
Feb
(4) |
Mar
(8) |
Apr
(13) |
May
(12) |
Jun
|
Jul
(5) |
Aug
(3) |
Sep
(2) |
Oct
(15) |
Nov
(2) |
Dec
(3) |
| 2010 |
Jan
(12) |
Feb
(13) |
Mar
(8) |
Apr
(1) |
May
|
Jun
(8) |
Jul
(11) |
Aug
(12) |
Sep
(4) |
Oct
(7) |
Nov
(3) |
Dec
(4) |
| 2011 |
Jan
(2) |
Feb
(5) |
Mar
(6) |
Apr
|
May
|
Jun
(1) |
Jul
(4) |
Aug
|
Sep
|
Oct
(2) |
Nov
(3) |
Dec
(8) |
| 2012 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thomas H. <th...@in...> - 2008-08-14 19:47:49
|
Hi Niels, as you said something about make and makefiles I assume that your sample project uses a makefile (if not you may skip the rest of my reply and I would need more information to track your problem down) With Eclipse / CDT / AVR plugin you don't need a makefile, as Eclipse will generate one for you automatically. What you could do is go through the included tutorial (Help -> AVR Eclipse Plugin -> Getting Started) to create a new project. If you can build this new project you are in good shape and you can try to copy all *.c and *.h files from your non-working blinking LED project to the new project. As I assume that your blinkenlight program is rather simple it should build right away. brgds, Thomas Niels Wolf wrote: > Hey. > > I am nearly so new to microcontrolers, C and AVR-Eclipse that you > would think my skin is really soft and pink and i look like a little > naked rat. > > I know basics of electronics and arduino and managed to program a > attiny with avr-studio. I also managed to upload *.hex with avrdude on > the commandline. I managed to get my c project build but not uploaded > in kontrollelab, that would not see my mk2. I installed avr-plugin, > the toolchain on linux and created a new c-avr project. so far so > good.. i watched this: http://www.vimeo.com/1213811 but thats not > really telling anything. i also looked at screenshots and the wiki.. > > But I cant get my simple blinking led project build in eclipse.. i get > some no target error, i created one with right mouseclick on the > project as stated in the help, problem remains. also all my includes > go red, though the header files are in the include folder (if that > means anything)... I know eclipse pretty well from developing java, > web stuff etc. but thats different. i know ant but not so much of > make. I know c from the arduino platform, though thats a bit > different, too. i know some c++ from the openframeworks platform, even > more different. > > so here comes my big HELP.. can anybody point me out to a avr-eclipse > 'my first project' tutorial or anything similar like my first most > simple c project in in eclipse. with sections like "what can go wrong > and why and how to fix it". anything else that would get me up to > speed and understanding is also very welcome.. i do this after work, > so i only have around 2 hours a day, which is why i am here. > > thanks so much.. > > Niels > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > avr-eclipse-user mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-eclipse-user > > |
|
From: SourceForge.net <no...@so...> - 2008-08-14 19:30:32
|
Bugs item #2050945, was opened at 2008-08-14 09:03 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2050945&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Group: None Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Thomas Holland (innot) Summary: Read Back of "Enable Individual Settings ..." Initial Comment: In the Project Properties the flag: avrtarget/perConfig is not shown correct after checking out a project with Subversion. It seems that this property is set correct only after closing and re-opening the project. I checked it several times, in the file: de.innot.avreclips.core.prefs in the .settings folder in the project folder the following line appears: avrtarget/perConfig=true after checking out and opening the project-properties the flag is not shown as active/true! This leads to errors in the build! Regards, Soenke soe...@zo... ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2008-08-14 21:30 Message: Logged In: YES user_id=1542541 Originator: NO Hi Snke, the problem is that the properties get cached a little bit to aggressive - basically once they have been read from the file the plugin never reloads the properties file again in the session. Hopefully with a few sync() calls at the right places this bug can be fixed without to much change. brgds Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2050945&group_id=189165 |
|
From: Niels W. <kz...@gm...> - 2008-08-14 07:58:01
|
Hey. I am nearly so new to microcontrolers, C and AVR-Eclipse that you would think my skin is really soft and pink and i look like a little naked rat. I know basics of electronics and arduino and managed to program a attiny with avr-studio. I also managed to upload *.hex with avrdude on the commandline. I managed to get my c project build but not uploaded in kontrollelab, that would not see my mk2. I installed avr-plugin, the toolchain on linux and created a new c-avr project. so far so good.. i watched this: http://www.vimeo.com/1213811 but thats not really telling anything. i also looked at screenshots and the wiki.. But I cant get my simple blinking led project build in eclipse.. i get some no target error, i created one with right mouseclick on the project as stated in the help, problem remains. also all my includes go red, though the header files are in the include folder (if that means anything)... I know eclipse pretty well from developing java, web stuff etc. but thats different. i know ant but not so much of make. I know c from the arduino platform, though thats a bit different, too. i know some c++ from the openframeworks platform, even more different. so here comes my big HELP.. can anybody point me out to a avr-eclipse 'my first project' tutorial or anything similar like my first most simple c project in in eclipse. with sections like "what can go wrong and why and how to fix it". anything else that would get me up to speed and understanding is also very welcome.. i do this after work, so i only have around 2 hours a day, which is why i am here. thanks so much.. Niels |
|
From: SourceForge.net <no...@so...> - 2008-08-14 07:03:43
|
Bugs item #2050945, was opened at 2008-08-14 07:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2050945&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Matthew McDougal (mmdoogie) Summary: Read Back of "Enable Individual Settings ..." Initial Comment: In the Project Properties the flag: avrtarget/perConfig is not shown correct after checking out a project with Subversion. It seems that this property is set correct only after closing and re-opening the project. I checked it several times, in the file: de.innot.avreclips.core.prefs in the .settings folder in the project folder the following line appears: avrtarget/perConfig=true after checking out and opening the project-properties the flag is not shown as active/true! This leads to errors in the build! Regards, Soenke soe...@zo... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2050945&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-08-02 23:36:52
|
Bugs item #2033031, was opened at 2008-07-30 13:25 Message generated for change (Comment added) made by ratmandu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2033031&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Group: unspecified version >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Justin Richards (ratmandu) Assigned to: Thomas Holland (innot) Summary: Linux FUSE and Lockbit preview in svn version Initial Comment: Sections in previews are too small, non-resizable, and thus, unreadable. See attachments. Using latest svn version (as of 07/30/08 1:23 PM CDT) on eclipse europa on Gentoo Linux in gnome. ---------------------------------------------------------------------- >Comment By: Justin Richards (ratmandu) Date: 2008-08-02 18:37 Message: Logged In: YES user_id=2163405 Originator: YES Looks great! Thanks. tested with svn rev 577. ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-30 17:23 Message: Logged In: YES user_id=1542541 Originator: NO I changed the layout of the preview control. While not finalized I think this will solve the bug. If you have time I would appreciate it if you could give it a try (SVN Rev. 571). (Att.: SourceForge SVN servers will be offline for 12hrs starting 17:00pst) ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-30 15:55 Message: Logged In: YES user_id=1542541 Originator: NO Hello Justin, thanks for the heads up on this. I only test the plugin against Linux sporadically, so I haven't noticed this yet. Seems like the implementation of SWT has some subtle differences between Windows and Linux. The difference seems to be in the TreeColumn.pack() method, which is called whenever the Preview has changed. >From your Screenshots I would say that on Linux pack() will only size the columns according to the size of the root elements (the fuse bytes), while on Windows it will also take the content of the child elements (the bitfields) into account when determining the minimum column size. I changed the PreviewControl to also show the column headers and thus made the columns resizable (SVN Rev 570). But I doubt that this will solve the problem as the columns are re-packed for every change. I could make the size of the column static and only changeable by the user, but I kind of liked the dynamic sizing I was getting on Windows. I will have to think about this and see if I can find a good solution. Or maybe there is a trick on how to get the same behaviour from both Linux and Windows. brgds, Thomas ---------------------------------------------------------------------- Comment By: Justin Richards (ratmandu) Date: 2008-07-30 13:26 Message: Logged In: YES user_id=2163405 Originator: YES File Added: screenshot4.png ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2033031&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-30 22:23:39
|
Bugs item #2024369, was opened at 2008-07-22 10:14 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.2 >Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Thomas Holland (innot) Summary: project not linked after library changes Initial Comment: Consider a workspace with: - an AVR static library - an AVR application using the static library The application has a "Project Reference" to the library, so the library is built if it does not exist when building the application (which is good and as it should be) Now for the erroneous behaviour: If you change sources of the static library and then rebuild the application: - the static library gets rebuilt (as expected) - but the application gets not rebuilt! It seems that the eclipse-internal dependencies via the "Project Reference" is used to rebuild the library. But the necessary dependency in the makefile between the application and the library is missing. I guess it is as simple as adding a dependency like: application: library in the generated makefile to make it work as expected. ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2008-07-31 00:23 Message: Logged In: YES user_id=1542541 Originator: NO OK! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-07-29 13:58 Message: Logged In: NO Thank you very much for your quick reply! Both of your solutions work, but the second one, which suggests to set > your application project -> Properties -> C/C++ General -> Paths and symbols -> References properly, is of course much cleaner. And that one even allows to select the configuration of library to depend upon. ... Once you make it right - it just works!-) ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-22 16:35 Message: Logged In: YES user_id=1542541 Originator: NO disregard the workaround from my last message. Here is the correct way: your application project -> Properties -> C/C++ General -> Paths and symbols -> References and add a reference to your static library project. Now the dependency you want is added to the makefile. Note that you still need the reference to your static library project in the "Properties -> Project References", so actually there are two references to the library project, one for CDT subsystem to include the dependencies and one for the Eclipse to do the builds. Thomas ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-22 16:14 Message: Logged In: YES user_id=1542541 Originator: NO I can reproduce the problem. However this is a shortcoming of CDT and out-of-scope for the AVR plugin. The creation of the makefile is buried deep within the bowels of CDT and short of rewriting large parts of CDT there is nothing my plugin can do. A report similar to your complaint is already in the Eclipse/CDT bug tracker: https://bugs.eclipse.org/bugs/show_bug.cgi?id=210248 As a workaround you could add the static library to the "Other Objects" list of the Linker "... -> AVR C Linker -> Objects -> Other Objects (*.o)". Even though it says "*.o", the linker will accept an *.a file as well and link it correctly (as far as I can see after 5 minutes of testing). Unlike user libraries, user Objects are included in the dependencies calculation. brgds Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-30 22:22:52
|
Bugs item #2033031, was opened at 2008-07-30 20:25 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2033031&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Group: unspecified version Status: Open Resolution: None Priority: 5 Private: No Submitted By: Justin Richards (ratmandu) Assigned to: Thomas Holland (innot) Summary: Linux FUSE and Lockbit preview in svn version Initial Comment: Sections in previews are too small, non-resizable, and thus, unreadable. See attachments. Using latest svn version (as of 07/30/08 1:23 PM CDT) on eclipse europa on Gentoo Linux in gnome. ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2008-07-31 00:23 Message: Logged In: YES user_id=1542541 Originator: NO I changed the layout of the preview control. While not finalized I think this will solve the bug. If you have time I would appreciate it if you could give it a try (SVN Rev. 571). (Att.: SourceForge SVN servers will be offline for 12hrs starting 17:00pst) ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-30 22:55 Message: Logged In: YES user_id=1542541 Originator: NO Hello Justin, thanks for the heads up on this. I only test the plugin against Linux sporadically, so I haven't noticed this yet. Seems like the implementation of SWT has some subtle differences between Windows and Linux. The difference seems to be in the TreeColumn.pack() method, which is called whenever the Preview has changed. >From your Screenshots I would say that on Linux pack() will only size the columns according to the size of the root elements (the fuse bytes), while on Windows it will also take the content of the child elements (the bitfields) into account when determining the minimum column size. I changed the PreviewControl to also show the column headers and thus made the columns resizable (SVN Rev 570). But I doubt that this will solve the problem as the columns are re-packed for every change. I could make the size of the column static and only changeable by the user, but I kind of liked the dynamic sizing I was getting on Windows. I will have to think about this and see if I can find a good solution. Or maybe there is a trick on how to get the same behaviour from both Linux and Windows. brgds, Thomas ---------------------------------------------------------------------- Comment By: Justin Richards (ratmandu) Date: 2008-07-30 20:26 Message: Logged In: YES user_id=2163405 Originator: YES File Added: screenshot4.png ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2033031&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-30 20:55:22
|
Bugs item #2033031, was opened at 2008-07-30 20:25 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2033031&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Group: unspecified version Status: Open Resolution: None Priority: 5 Private: No Submitted By: Justin Richards (ratmandu) >Assigned to: Thomas Holland (innot) Summary: Linux FUSE and Lockbit preview in svn version Initial Comment: Sections in previews are too small, non-resizable, and thus, unreadable. See attachments. Using latest svn version (as of 07/30/08 1:23 PM CDT) on eclipse europa on Gentoo Linux in gnome. ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2008-07-30 22:55 Message: Logged In: YES user_id=1542541 Originator: NO Hello Justin, thanks for the heads up on this. I only test the plugin against Linux sporadically, so I haven't noticed this yet. Seems like the implementation of SWT has some subtle differences between Windows and Linux. The difference seems to be in the TreeColumn.pack() method, which is called whenever the Preview has changed. >From your Screenshots I would say that on Linux pack() will only size the columns according to the size of the root elements (the fuse bytes), while on Windows it will also take the content of the child elements (the bitfields) into account when determining the minimum column size. I changed the PreviewControl to also show the column headers and thus made the columns resizable (SVN Rev 570). But I doubt that this will solve the problem as the columns are re-packed for every change. I could make the size of the column static and only changeable by the user, but I kind of liked the dynamic sizing I was getting on Windows. I will have to think about this and see if I can find a good solution. Or maybe there is a trick on how to get the same behaviour from both Linux and Windows. brgds, Thomas ---------------------------------------------------------------------- Comment By: Justin Richards (ratmandu) Date: 2008-07-30 20:26 Message: Logged In: YES user_id=2163405 Originator: YES File Added: screenshot4.png ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2033031&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-30 18:26:05
|
Bugs item #2033031, was opened at 2008-07-30 13:25 Message generated for change (Comment added) made by ratmandu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2033031&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Group: unspecified version Status: Open Resolution: None Priority: 5 Private: No Submitted By: Justin Richards (ratmandu) Assigned to: Matthew McDougal (mmdoogie) Summary: Linux FUSE and Lockbit preview in svn version Initial Comment: Sections in previews are too small, non-resizable, and thus, unreadable. See attachments. Using latest svn version (as of 07/30/08 1:23 PM CDT) on eclipse europa on Gentoo Linux in gnome. ---------------------------------------------------------------------- >Comment By: Justin Richards (ratmandu) Date: 2008-07-30 13:26 Message: Logged In: YES user_id=2163405 Originator: YES File Added: screenshot4.png ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2033031&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-30 18:25:22
|
Bugs item #2033031, was opened at 2008-07-30 13:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2033031&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Group: unspecified version Status: Open Resolution: None Priority: 5 Private: No Submitted By: Justin Richards (ratmandu) Assigned to: Matthew McDougal (mmdoogie) Summary: Linux FUSE and Lockbit preview in svn version Initial Comment: Sections in previews are too small, non-resizable, and thus, unreadable. See attachments. Using latest svn version (as of 07/30/08 1:23 PM CDT) on eclipse europa on Gentoo Linux in gnome. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2033031&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-29 11:58:22
|
Bugs item #2024369, was opened at 2008-07-22 08:14 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.2 Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Thomas Holland (innot) Summary: project not linked after library changes Initial Comment: Consider a workspace with: - an AVR static library - an AVR application using the static library The application has a "Project Reference" to the library, so the library is built if it does not exist when building the application (which is good and as it should be) Now for the erroneous behaviour: If you change sources of the static library and then rebuild the application: - the static library gets rebuilt (as expected) - but the application gets not rebuilt! It seems that the eclipse-internal dependencies via the "Project Reference" is used to rebuild the library. But the necessary dependency in the makefile between the application and the library is missing. I guess it is as simple as adding a dependency like: application: library in the generated makefile to make it work as expected. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-07-29 11:58 Message: Logged In: NO Thank you very much for your quick reply! Both of your solutions work, but the second one, which suggests to set > your application project -> Properties -> C/C++ General -> Paths and symbols -> References properly, is of course much cleaner. And that one even allows to select the configuration of library to depend upon. ... Once you make it right - it just works!-) ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-22 14:35 Message: Logged In: YES user_id=1542541 Originator: NO disregard the workaround from my last message. Here is the correct way: your application project -> Properties -> C/C++ General -> Paths and symbols -> References and add a reference to your static library project. Now the dependency you want is added to the makefile. Note that you still need the reference to your static library project in the "Properties -> Project References", so actually there are two references to the library project, one for CDT subsystem to include the dependencies and one for the Eclipse to do the builds. Thomas ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-22 14:14 Message: Logged In: YES user_id=1542541 Originator: NO I can reproduce the problem. However this is a shortcoming of CDT and out-of-scope for the AVR plugin. The creation of the makefile is buried deep within the bowels of CDT and short of rewriting large parts of CDT there is nothing my plugin can do. A report similar to your complaint is already in the Eclipse/CDT bug tracker: https://bugs.eclipse.org/bugs/show_bug.cgi?id=210248 As a workaround you could add the static library to the "Other Objects" list of the Linker "... -> AVR C Linker -> Objects -> Other Objects (*.o)". Even though it says "*.o", the linker will accept an *.a file as well and link it correctly (as far as I can see after 5 minutes of testing). Unlike user libraries, user Objects are included in the dependencies calculation. brgds Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-22 14:36:03
|
Bugs item #2024369, was opened at 2008-07-22 10:14 Message generated for change (Settings changed) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.2 >Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Thomas Holland (innot) Summary: project not linked after library changes Initial Comment: Consider a workspace with: - an AVR static library - an AVR application using the static library The application has a "Project Reference" to the library, so the library is built if it does not exist when building the application (which is good and as it should be) Now for the erroneous behaviour: If you change sources of the static library and then rebuild the application: - the static library gets rebuilt (as expected) - but the application gets not rebuilt! It seems that the eclipse-internal dependencies via the "Project Reference" is used to rebuild the library. But the necessary dependency in the makefile between the application and the library is missing. I guess it is as simple as adding a dependency like: application: library in the generated makefile to make it work as expected. ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-22 16:35 Message: Logged In: YES user_id=1542541 Originator: NO disregard the workaround from my last message. Here is the correct way: your application project -> Properties -> C/C++ General -> Paths and symbols -> References and add a reference to your static library project. Now the dependency you want is added to the makefile. Note that you still need the reference to your static library project in the "Properties -> Project References", so actually there are two references to the library project, one for CDT subsystem to include the dependencies and one for the Eclipse to do the builds. Thomas ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-22 16:14 Message: Logged In: YES user_id=1542541 Originator: NO I can reproduce the problem. However this is a shortcoming of CDT and out-of-scope for the AVR plugin. The creation of the makefile is buried deep within the bowels of CDT and short of rewriting large parts of CDT there is nothing my plugin can do. A report similar to your complaint is already in the Eclipse/CDT bug tracker: https://bugs.eclipse.org/bugs/show_bug.cgi?id=210248 As a workaround you could add the static library to the "Other Objects" list of the Linker "... -> AVR C Linker -> Objects -> Other Objects (*.o)". Even though it says "*.o", the linker will accept an *.a file as well and link it correctly (as far as I can see after 5 minutes of testing). Unlike user libraries, user Objects are included in the dependencies calculation. brgds Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-22 14:35:35
|
Bugs item #2024369, was opened at 2008-07-22 10:14 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.2 >Status: Open Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Thomas Holland (innot) Summary: project not linked after library changes Initial Comment: Consider a workspace with: - an AVR static library - an AVR application using the static library The application has a "Project Reference" to the library, so the library is built if it does not exist when building the application (which is good and as it should be) Now for the erroneous behaviour: If you change sources of the static library and then rebuild the application: - the static library gets rebuilt (as expected) - but the application gets not rebuilt! It seems that the eclipse-internal dependencies via the "Project Reference" is used to rebuild the library. But the necessary dependency in the makefile between the application and the library is missing. I guess it is as simple as adding a dependency like: application: library in the generated makefile to make it work as expected. ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2008-07-22 16:35 Message: Logged In: YES user_id=1542541 Originator: NO disregard the workaround from my last message. Here is the correct way: your application project -> Properties -> C/C++ General -> Paths and symbols -> References and add a reference to your static library project. Now the dependency you want is added to the makefile. Note that you still need the reference to your static library project in the "Properties -> Project References", so actually there are two references to the library project, one for CDT subsystem to include the dependencies and one for the Eclipse to do the builds. Thomas ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-22 16:14 Message: Logged In: YES user_id=1542541 Originator: NO I can reproduce the problem. However this is a shortcoming of CDT and out-of-scope for the AVR plugin. The creation of the makefile is buried deep within the bowels of CDT and short of rewriting large parts of CDT there is nothing my plugin can do. A report similar to your complaint is already in the Eclipse/CDT bug tracker: https://bugs.eclipse.org/bugs/show_bug.cgi?id=210248 As a workaround you could add the static library to the "Other Objects" list of the Linker "... -> AVR C Linker -> Objects -> Other Objects (*.o)". Even though it says "*.o", the linker will accept an *.a file as well and link it correctly (as far as I can see after 5 minutes of testing). Unlike user libraries, user Objects are included in the dependencies calculation. brgds Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-22 14:14:29
|
Bugs item #2024369, was opened at 2008-07-22 10:14 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.2 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Thomas Holland (innot) Summary: project not linked after library changes Initial Comment: Consider a workspace with: - an AVR static library - an AVR application using the static library The application has a "Project Reference" to the library, so the library is built if it does not exist when building the application (which is good and as it should be) Now for the erroneous behaviour: If you change sources of the static library and then rebuild the application: - the static library gets rebuilt (as expected) - but the application gets not rebuilt! It seems that the eclipse-internal dependencies via the "Project Reference" is used to rebuild the library. But the necessary dependency in the makefile between the application and the library is missing. I guess it is as simple as adding a dependency like: application: library in the generated makefile to make it work as expected. ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2008-07-22 16:14 Message: Logged In: YES user_id=1542541 Originator: NO I can reproduce the problem. However this is a shortcoming of CDT and out-of-scope for the AVR plugin. The creation of the makefile is buried deep within the bowels of CDT and short of rewriting large parts of CDT there is nothing my plugin can do. A report similar to your complaint is already in the Eclipse/CDT bug tracker: https://bugs.eclipse.org/bugs/show_bug.cgi?id=210248 As a workaround you could add the static library to the "Other Objects" list of the Linker "... -> AVR C Linker -> Objects -> Other Objects (*.o)". Even though it says "*.o", the linker will accept an *.a file as well and link it correctly (as far as I can see after 5 minutes of testing). Unlike user libraries, user Objects are included in the dependencies calculation. brgds Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-22 08:14:07
|
Bugs item #2024369, was opened at 2008-07-22 08:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Matthew McDougal (mmdoogie) Summary: project not linked after library changes Initial Comment: Consider a workspace with: - an AVR static library - an AVR application using the static library The application has a "Project Reference" to the library, so the library is built if it does not exist when building the application (which is good and as it should be) Now for the erroneous behaviour: If you change sources of the static library and then rebuild the application: - the static library gets rebuilt (as expected) - but the application gets not rebuilt! It seems that the eclipse-internal dependencies via the "Project Reference" is used to rebuild the library. But the necessary dependency in the makefile between the application and the library is missing. I guess it is as simple as adding a dependency like: application: library in the generated makefile to make it work as expected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2024369&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-17 17:20:56
|
Bugs item #2020689, was opened at 2008-07-17 17:01 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2020689&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Group: v2.2 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Thomas Holland (innot) Assigned to: Thomas Holland (innot) Summary: avrdude option -D (Disable auto erase for flash) Initial Comment: The plugin is missing a way to set the -D option for avrdude. While I thought that I covered all avrdude options in the user interface I have missed the -D option. The plugin should support *all* avrdude options so support for -D will be added as well as a free text field for options of future avrdude releases. Thomas ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2008-07-17 19:21 Message: Logged In: YES user_id=1542541 Originator: YES Fix is in the SVN repository (Rev 556) and will be in the next release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2020689&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-17 15:14:41
|
Bugs item #2020702, was opened at 2008-07-17 17:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2020702&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Holland (innot) Assigned to: Thomas Holland (innot) Summary: Update Site not working with Ganymede Initial Comment: The plugin update site fails for some users who are using Eclipse 3.4 (Ganymede). Eclipse 3.4 uses a completely new update system (P2), but which still has a compatibility mode for Eclipse 3.3 update sites like the update site for this plugin. This compatibility mode works for me (I can use the update site with Eclipse 3.4 just fine), but other users are reporting error messages like: "Cannot complete the request. See the details." And the details are: "An error occurred while collecting items to be installed. No repository found containing: com.ibm.etools.emf.event/osgi.bundle/3.0.0.v20060918_M' Both positive and negative experiences with the update site were on Windows XP systems, so it seems to be not operating system related. A workaround is to download the plugin directly from sourceforge instead of using the update site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2020702&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-17 15:01:29
|
Bugs item #2020689, was opened at 2008-07-17 17:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2020689&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Group: v2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Holland (innot) Assigned to: Thomas Holland (innot) Summary: avrdude option -D (Disable auto erase for flash) Initial Comment: The plugin is missing a way to set the -D option for avrdude. While I thought that I covered all avrdude options in the user interface I have missed the -D option. The plugin should support *all* avrdude options so support for -D will be added as well as a free text field for options of future avrdude releases. Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2020689&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-16 13:08:18
|
Bugs item #1962594, was opened at 2008-05-12 21:28 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=1962594&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.1 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Thomas Holland (innot) Assigned to: Thomas Holland (innot) Summary: Searching for System Paths slow on Linux. Initial Comment: While the searching for System Paths happens in the background, this may still significantly slow down systems with slow Harddrives. The Plugin should be modified to persist the found Paths and only start a search when a persisted system path is not valid anymore. ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2008-07-16 15:08 Message: Logged In: YES user_id=1542541 Originator: YES Hi Michael, thanks for your input on this. I only test the plugin with a plain vanilla Ubuntu distro (in a virtual machine), so I never noticed how slow the search can be. In the SVN repository there is already a fix for this bug scheduled for the next release. With this fix the plugin will memorize a path once it is found and only rescan if the path becomes invalid. Haven't tested this fix yet but I will do so as soon as possible. I am not sure about your idea to make the search paths and their order (currently: "/usr/local/", "/usr/", "/opt/", "~/", "/home/" - in this order) a preference item. It might not be worth the effort because power users like yourself will probably use custom path settings anyway and for beginners the option to change the search paths will be just confusing and an additional error source. What I will look into is to stop the scans if all paths are custom anyway. This is not as trivial as it sounds because this requires some modifications of the user interface to get it consistent. Also I think I will write a little "How To Build the Plugin from Source" in the project Wiki so anyone interested can fiddle with the plugin. brgds Thomas ---------------------------------------------------------------------- Comment By: Michal Schulz (michalsc) Date: 2008-07-15 21:26 Message: Logged In: YES user_id=436426 Originator: NO I may confirm that searching for system paths is awfully slow on linux. I have recently installed avr plugin for eclipse and found out, that the searching performed by avr takes around 15 (fifteen!!!!) minutes on my laptop. The reason is, avr plugin scans not only the whole /opt (which is huge on my machine) and /usr (which is even bigger). AVR plugin scans also *both* the ~/ and /home directories recursively. Please note that my home directory contains around 150'000 files in 15GB. It will be slow no matter what harddrive I will use. Now, after every start of eclipse (or alternatively after every change of workspace) I have to kill several "find" processes :/... I was also going to modify the plugin but I don't know how to rebuild it in eclipse itself. The AVR plugin contains a very nice path setting, where I have put all the toolchain paths manually. In my opinion, setting them all to "Custom" should stop the background system path scan completely. Unfortunately it does not. Moreover, the paths which are searched after the toolchain should be somehow editable. Please, fix it or tell me how can I do it by myself. I do really like the avrplugin but this system path scan is killing me (and fills filesystem caches with absolutely irrelevant stuff ;)). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=1962594&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-15 19:26:21
|
Bugs item #1962594, was opened at 2008-05-12 21:28 Message generated for change (Comment added) made by michalsc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=1962594&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Holland (innot) Assigned to: Thomas Holland (innot) Summary: Searching for System Paths slow on Linux. Initial Comment: While the searching for System Paths happens in the background, this may still significantly slow down systems with slow Harddrives. The Plugin should be modified to persist the found Paths and only start a search when a persisted system path is not valid anymore. ---------------------------------------------------------------------- Comment By: Michal Schulz (michalsc) Date: 2008-07-15 21:26 Message: Logged In: YES user_id=436426 Originator: NO I may confirm that searching for system paths is awfully slow on linux. I have recently installed avr plugin for eclipse and found out, that the searching performed by avr takes around 15 (fifteen!!!!) minutes on my laptop. The reason is, avr plugin scans not only the whole /opt (which is huge on my machine) and /usr (which is even bigger). AVR plugin scans also *both* the ~/ and /home directories recursively. Please note that my home directory contains around 150'000 files in 15GB. It will be slow no matter what harddrive I will use. Now, after every start of eclipse (or alternatively after every change of workspace) I have to kill several "find" processes :/... I was also going to modify the plugin but I don't know how to rebuild it in eclipse itself. The AVR plugin contains a very nice path setting, where I have put all the toolchain paths manually. In my opinion, setting them all to "Custom" should stop the background system path scan completely. Unfortunately it does not. Moreover, the paths which are searched after the toolchain should be somehow editable. Please, fix it or tell me how can I do it by myself. I do really like the avrplugin but this system path scan is killing me (and fills filesystem caches with absolutely irrelevant stuff ;)). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=1962594&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-07 20:04:40
|
Bugs item #2011424, was opened at 2008-07-05 23:35 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2011424&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.2 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Thomas Holland (innot) Summary: avrdude executable can not be found Initial Comment: After installing and setting up the latest version of your plugin I get the following error message when I try to use it. --- Cannot run AVRDude executable. Please check the AVR path preferences. Cannot run program "C:\WinAVR\bin\avrdude" (in directory ""): CreateProcess error=267, Der Verzeichnisname ist ungltig --- See screenshot. Commandline capture: Launching C:\WinAVR\bin\avrdude -pm169 -cstk500v2 -PCOM1 "-Uflash:w:E:\PROJEKTE\Intruder_Detection\Intruder Detection\binary\main.hex:a" Output: The plugin version 2.1.1 works just fine with avrdude. ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2008-07-07 22:04 Message: Logged In: YES user_id=1542541 Originator: NO The reason for the error message was an invalid "Build directory" (Project -> Properties -> C/C++ Build). Added a descriptive error message to the plugin when the build directory is not valid. This is already in SVN (revision 548) and will be included in the next release. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-07-07 19:00 Message: Logged In: NO Your requested informations: * avrdude path is verified and correct * Eclipse Platform Version: 3.3.2 Build id: M20080221-1800 * Tried all possible methods to start the upload to target. Error occurs with all start methods. * A new project in the same workspace produces the same error. * I tried the commandline from Eclipse console inside the XP command shell and it works just fine. ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-07 10:23 Message: Logged In: YES user_id=1542541 Originator: NO Hi, I assume that you checked that "C:\WinAVR\bin\avrdude" is the correct path to the avrdude executable. In this case the problem seems to be that the working directory is not set correctly by the plugin. That's the "(in directory "")" in your output which should be something like "(in directory "[your workspace]\[your project]\[config name e.g. Debug]")". I cannot reproduce this bug, so I need some more information to trace this down: * What Eclipse version are you using? 3.3 (Europa) or 3.4 (Ganymede)? * How did you start the upload: with the toolbar button, from the AVR main menu, from the project context menu or with the keyboard shortcut? * If you create a new project, do you get the same error? Also the following might be helpful to reproduce the bug: * the .project and .cproject files of the project you are trying to upload. * the Eclipse error log (Help -> About Eclipse Platform -> Configuration Details -> View Error Log) You can either attach these files to this bug report or send them to me directly (th...@in... - german OK). brgds Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2011424&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-07 19:41:03
|
Bugs item #2008171, was opened at 2008-07-01 19:29 Message generated for change (Comment added) made by maxlem You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2008171&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.2 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Max (maxlem) Assigned to: Thomas Holland (innot) Summary: Build System ignores .c files in C++ project (Ganymede) Initial Comment: Scenario : New C++ Project New file > main.c Build : Nothing to build for target Workaround : rename as main.cpp ---------------------------------------------------------------------- >Comment By: Max (maxlem) Date: 2008-07-07 19:41 Message: Logged In: YES user_id=1970826 Originator: YES thank you very much, I can wait for the next release. BTW, This plugin rocks! Atmel should finance you/contribute... AVR studio is a very poor IDE compared to eclipse, and now with all the benefits of CDT 5.0, coding for AVRs is ridiculously pleasing! ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-07 17:20 Message: Logged In: YES user_id=1542541 Originator: NO Disregard my last entry. This is a bug of the plugin. I have commited the fix (svn revision 547) and it will be in the next release. Contact me if you need the fix right away and then I will build a special release for you with just this fix. brgds Thomas ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-01 23:05 Message: Logged In: YES user_id=1542541 Originator: NO Yes, that behaviour is already in the CDT GCC plugin on which the AVR Plugin is based. I will look into this in the next few days to see if it can be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2008171&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-07 17:19:54
|
Bugs item #2008171, was opened at 2008-07-01 21:29 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2008171&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.2 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Max (maxlem) Assigned to: Thomas Holland (innot) Summary: Build System ignores .c files in C++ project (Ganymede) Initial Comment: Scenario : New C++ Project New file > main.c Build : Nothing to build for target Workaround : rename as main.cpp ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2008-07-07 19:20 Message: Logged In: YES user_id=1542541 Originator: NO Disregard my last entry. This is a bug of the plugin. I have commited the fix (svn revision 547) and it will be in the next release. Contact me if you need the fix right away and then I will build a special release for you with just this fix. brgds Thomas ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-02 01:05 Message: Logged In: YES user_id=1542541 Originator: NO Yes, that behaviour is already in the CDT GCC plugin on which the AVR Plugin is based. I will look into this in the next few days to see if it can be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2008171&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-07 17:00:27
|
Bugs item #2011424, was opened at 2008-07-05 21:35 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2011424&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.2 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Thomas Holland (innot) Summary: avrdude executable can not be found Initial Comment: After installing and setting up the latest version of your plugin I get the following error message when I try to use it. --- Cannot run AVRDude executable. Please check the AVR path preferences. Cannot run program "C:\WinAVR\bin\avrdude" (in directory ""): CreateProcess error=267, Der Verzeichnisname ist ungltig --- See screenshot. Commandline capture: Launching C:\WinAVR\bin\avrdude -pm169 -cstk500v2 -PCOM1 "-Uflash:w:E:\PROJEKTE\Intruder_Detection\Intruder Detection\binary\main.hex:a" Output: The plugin version 2.1.1 works just fine with avrdude. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-07-07 17:00 Message: Logged In: NO Your requested informations: * avrdude path is verified and correct * Eclipse Platform Version: 3.3.2 Build id: M20080221-1800 * Tried all possible methods to start the upload to target. Error occurs with all start methods. * A new project in the same workspace produces the same error. * I tried the commandline from Eclipse console inside the XP command shell and it works just fine. ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2008-07-07 08:23 Message: Logged In: YES user_id=1542541 Originator: NO Hi, I assume that you checked that "C:\WinAVR\bin\avrdude" is the correct path to the avrdude executable. In this case the problem seems to be that the working directory is not set correctly by the plugin. That's the "(in directory "")" in your output which should be something like "(in directory "[your workspace]\[your project]\[config name e.g. Debug]")". I cannot reproduce this bug, so I need some more information to trace this down: * What Eclipse version are you using? 3.3 (Europa) or 3.4 (Ganymede)? * How did you start the upload: with the toolbar button, from the AVR main menu, from the project context menu or with the keyboard shortcut? * If you create a new project, do you get the same error? Also the following might be helpful to reproduce the bug: * the .project and .cproject files of the project you are trying to upload. * the Eclipse error log (Help -> About Eclipse Platform -> Configuration Details -> View Error Log) You can either attach these files to this bug report or send them to me directly (th...@in... - german OK). brgds Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2011424&group_id=189165 |
|
From: SourceForge.net <no...@so...> - 2008-07-07 08:23:24
|
Bugs item #2011424, was opened at 2008-07-05 23:35 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2011424&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Behavior Group: v2.2 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Thomas Holland (innot) Summary: avrdude executable can not be found Initial Comment: After installing and setting up the latest version of your plugin I get the following error message when I try to use it. --- Cannot run AVRDude executable. Please check the AVR path preferences. Cannot run program "C:\WinAVR\bin\avrdude" (in directory ""): CreateProcess error=267, Der Verzeichnisname ist ungltig --- See screenshot. Commandline capture: Launching C:\WinAVR\bin\avrdude -pm169 -cstk500v2 -PCOM1 "-Uflash:w:E:\PROJEKTE\Intruder_Detection\Intruder Detection\binary\main.hex:a" Output: The plugin version 2.1.1 works just fine with avrdude. ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2008-07-07 10:23 Message: Logged In: YES user_id=1542541 Originator: NO Hi, I assume that you checked that "C:\WinAVR\bin\avrdude" is the correct path to the avrdude executable. In this case the problem seems to be that the working directory is not set correctly by the plugin. That's the "(in directory "")" in your output which should be something like "(in directory "[your workspace]\[your project]\[config name e.g. Debug]")". I cannot reproduce this bug, so I need some more information to trace this down: * What Eclipse version are you using? 3.3 (Europa) or 3.4 (Ganymede)? * How did you start the upload: with the toolbar button, from the AVR main menu, from the project context menu or with the keyboard shortcut? * If you create a new project, do you get the same error? Also the following might be helpful to reproduce the bug: * the .project and .cproject files of the project you are trying to upload. * the Eclipse error log (Help -> About Eclipse Platform -> Configuration Details -> View Error Log) You can either attach these files to this bug report or send them to me directly (th...@in... - german OK). brgds Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2011424&group_id=189165 |
