What are the key steps to getting AVRStudio 4.11 to show C source file debugging info (rather than an assembly listing of the flash memory)?
I've been trying different things for hours and nothing seems to work.
I have an ATmega8535.
Is there any documentation that focuses on the 20% of things that 80% of users would like to do (I'm assuming this to be something like the following):
Development Environment: Native Windows (2k or XP) - (not Linux, Unix or Cygwin).
Development Language: C
Deep knowledge of compiler, object, linker internals, etc.: Zero.
Number of Files in project: More than one, and more functions than main() alone.
I've been searching avrfreaks, but it's no help - a lot of the links are now broken, and anyway, the elf2coff thing, I already have - but it doesn't seem to work with the latest gcc ("can't create elf dbase").
I did load ImageCraft's ICCAVR with a view to porting the existing project to this environment, but I got put off by two things:
The keyword that you use to indicate Program Memory (flash), is 'const'. I got to that while porting and thought it seemed suspect. I.e. I didn't imagine that it would always do what I was wanting.
When I was trying to convert an old gcc 'set bit' instruction, your documentation said, "see the Atmel datasheet". I'm afraid that was the deciding factor for me - to stick with GCC for a bit longer to see if I could get it to work.
When one pays for a product, one does not want to be sent running around looking for answers - if a runaround IS necessary, at least and explanation of why and a hint of where in the datasheet to look would be helpful.
(This was not a deciding factor, but it's a negative factor with your product) Whenever I open your html help, I keep getting asked if I want to allow such and such a thing to be installed (I don't, so this is very annoying) - what does this give me that I can't do without it- I seem to be able to browse your help even if it does not load.
What are your comments on these points?
I'm in no way a commited gcc person and would willingly pay to make my life easier when it comes to developing this code, so there is still time to convert me to ICCAVR.
Note, this was an inherited project that was developed with the AT90S8535 (but it has to be moved over to the ATmega8535) - hence the change to the latest gcc (the gcc it was originally developed with didn't seem to support the mega version, nor did version 3 of AVRStudio). The migration is complete except for the c-level debugging info.
I would embrace you and give you a guy-to-guy hug if I could but reach out.
That's done it!
The exact thing (out of all the permutations that I had, unsuccessfully, tried last night was):
As you said, use: -gdwarf-2 (elf-dwarf2 wasn't recognised by the compiler)
This is it, in its full context (the local make file - not including the avrfreaks/avr_make additions that get added to the compiler flags when it is included.
#compiler flags - optimise for space CPFLAGS = -gdwarf-2 -Os -Wall -w -Wstrict-prototypes -Wa,-ahlms=$(
In the avrfreaks/avr_make file, I had to change block 8 because avr-objcopy does not seem to support the avrobj format anymore.
also modified the following in block 9 (this is on a Win2k system - don't know if it's still valid for Linux): %.cof: %.elf $(ELFCOF) $< $(OUT) $@ $*.sym $(CP) $(OUT)/$@ . $(CP) $(OUT)/*.sym . $(CP) $(OUT)/*.cof . # $(CP) $(OUT)/* . # $(CP) $(OUT)\\*sym . # $(CP) $(OUT)\\*S .
I'm still getting elfcoff saying that it was, "Unable to create Elf dbase", but everything else seems okay now.
While somewhat unusual, I don't think it breaks ANSI C's definition per se, except for people who use "const char *" to a function's argument to mean the function will not change the content, but I can be wrong. In anyway, AVR is a Harvard architecture so this issue needs to be handled one way or another...
I *may* add a separate keyword at some future release, but it will have to be done slowly to support backward compatibility :-(
Eh? One problem here is that the old GCC does not generate set bit instruction so now you have unnecessary extensions to the language in your program. I am pretty sure the new GCC fixes it, but a set bit is simply:
unsigned char c; #define bit(x) (1 When one pays for a product, one does not want to be sent running around
Unless I am wrong, you are only experiencing this because your program happens to use a non-standard C extensions. This is the prime reason we avoid extensions as much as possible....
Not sure what you mean here. We switched to use HTML Webwork help on V7, so there may be requirements that I don't know of, but so far, I have not gotten any such complaints from other people. You need either Javascript or Java and the Webworks suppose to detect that, but I am not aware that it needs anything else to be installed.
Well, hope this helps. If you wish, you can email me privately if you have more questions etc.
I had given up on gcc by the time I read your first post and set about porting to ICCAVR again - this was fairly easy after all (with a few macros defined in a new header). After the first file compiled without warning, I found Carsten's suggestion on the gcc fix (which worked) - so halted the port - it's not so important now (given that I recall the demo version of ICCAVR has a 4k code limit - did I recall that correctly) and I know that the gcc code so far is 6k (this may become a factor in the abandonment of gcc).
Anyway, this is what pops up every time I open ICCAVR's help file: Do you want to install and run: file://C:\iccv7avr\Help\ICCAVR\wwhelp3.cab (Quadralay Corporation). As I say, I'd be interested in what this gives me, since the help seems to work fine when I say "No, I don't want to install this".
There is a bad downside, actually. When I have the ICCAVR help open, I get errors when I open my normal IE browser (to google's home page or any new website):
"A runtime error has occurred. Do you wish to debug? Line: 0 Error: object doesn't support this property or method" - where I have to click no.
(I am using a fairly old popup killer - proxomitron - maybe this is a factor) - anyway, not nice. IE5.5 SP2, Win2k.
A couple of other things that are putting me off the product:
It is not possible to put two source windows side by side in the IDE (to view one while typing into another).
There is no pre-configured option to use MS Dev Studio's editor as an alternative (maybe it can't be used? maybe I'm missing the point - but it is a good editor that has never caused me any problems.).
It's too fussy using the current menu setup to compile a single file: (especially when one is in an edit and compile cycle to try and figure something awkward). MS Dev Studio gets it right when it puts build and compile under the same 'build' menu (Alt, B, B or Alt, B, C).
Closing a window is too fussy as well - It's a shame you didn't do an MDI application but chose the tabs (which are good - but you really need the other things associated with MDI apps to turn them into an asset rather than simply a replacement).
These are only my personal opinions, and as I've metioned, I've not ruled out a switch to ICCAVR yet - it will become a necessity if the final code won't fit (but then, I'll be considering IAR Workbench under this scenario).
It's fully functional for 45 days, and then 4K limited "forever" for non commercial sue.
Hmm... no idea. What OS are you using, and what is your default browswer (and version). Do you have Javascript or Java enabled? Do you get to see any of the Help at all?
I guess this is the problem using a (well known 3 rd party) product. I have no idea... I will take your info and send it to Qudralay. I do again stress that no one else has the problems (so far) so it's probably something about your particular setup.
Not currently. Sorry.
Yes, you can use any external editor. See Tools->Environments and set the editor to external.
Generally we don't recommend people to compile a single file. Just build the whole project. This is one of those ease of use thing. For 99% of people, they are happy with just clicking on the build icon. If we make "compile to single file" easy to use, for some reasons, then lots of people start to use it and wonder why they can't build executables etc. By moving it away, we solve a lot of support issues w/o hurting most users. Just right now, we have a customer wondering why the "linker file" blinks and disappears when he clicks on it. It took me many emails to fish it out of him that he builds and project, compile each file to object, then click on the linkw.exe icon (and expect what?...) Since ilinkw is a command line program, of course it just blinks and disappears. Some people have very clear idea on what they are doing. Unfortunately, they could be wrong at times :-) Our philosophy is to make our tools as simple to use as possible for the 80-90% of the users, and give the rest some of the hooks.
We use to have MDI on V5, but again, a whole different set of support problems cropped up. Since most people have their own favorite editor anyway, we just make our editor usable and spend the energy on the compiler and the application builder. BTW, ^W closes an editor window.
FWIW, I have no problems with the ICC AVR help being open in Opera and then launching another tab on, say, Google.
Although I almost never use IE, pasting the path to the ICC AVR help file works OK with MSIE, although I do get an IE warning about "Internet Explorer has restricted this file from showing active content that could access your computer."
I guess that MS has so many security holes that when they decide to block an active control in IE, they need to be all showy about it to Demonstrate That They Are Taking Security Seriously and are Doing Something About It.
No problems, tho, with firing up other IE sessions.
Mmm..... and now it takes 6 seconds on my 2.4GHz machine to show the first help page, as opposed to less than 1 second in V6.... But apart from that: a great compiler and IDE! :-)
Don't you know we get kickback from Microsoft and Intel!! :-)
Unfortunately, old WinHelp is not "recommended" by Microsoft anymore, that plus other reasons (we can now maintain more or less single source Help source amongst all the products that we support with some "conditional" text) so we have to switch. Framemaker/Webwork combo is not ideal, but it does solve some problems. Sorry for the slow down though.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.