WinAVR a few Improvements

[Keyla]

Hi there I requested the WinAVR integration months ago. Because of trouble in my RL I have just now the time to work with CB.
The good news is yes it is working but I have some further requests/questions which IMHO might improve the use of CB for AVR family qC coders. But there are still a few lacks which qould be nice to fix. As I noticed in the sticked thread working on some things is allready going on and the embedded device maintainer is just out of time...

A few improvements are:
No WinAVR autodetection
There is no WinAVR autodetection of paths and the compiler itself. That would be easy to realise, the path is stored in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\WinAVR. Oh and in the environment variable %PATH% of course.

no unnessesary options e.g. .EXE output, Resources,...
IMHO because of the currently hardcoded integration CB isn't able to hide useles options. The default output extension is .ELF not .EXE. And there are no OS platforms or so on...

real integration (as platform, build/upload process, Wizzard,..)
As said before a own tab for 'Embedded devices' in the template Wizzard would be very nice. And therefor a specific platform and or further buildoptions (CPU frequency and so on) and maybe the import of existing makefiles?
Another very important thing is the connection to the uploadtool called avrdude and its options. ATM I integrated as as 'tool' but that's just a workaround.

profiler
Currently the profiler isn't working. You get the following message:

ld.exe:: cannot find -lgmon

I think it will very usefull in combination with the profiler plugin because size/speed matters in embedded devices.

debugger
There are multiple posibillities to debug the microprocessor.
In a completely virtual box using simulavr or in the real hardware using JTAG managed by avarice. Both must be invoked and are avaidable via a GDB interface. Both have custom options (GDB options, JTAG options, behaviour...) but should be integrated without problems. As I read there are allready some experiments...

avrlibc doc integration
If someone would develop a general documentation component the integration of the AVRLibC PDF to the context based help would be a great help.

[Keyla]

No comments? 

[BrianSidebotham]

The developers of c::b are not embedded developers, they are profficient c++ programmers with good knowledge of windows/unix and mac OS software. Therefore, if you use winavr and need improvements to it's support, you've got to try and get your hands dirty.

I have posted an AVR project wizard in the development forum. Please feel free to upgrade to a new nightly build when it's in and post your comments about it in that post.

I have not dealt with auto-detection, but I will. It's easy enough to do.

The default outputs from the wizard are .elf files. You can also opt to generate .hex .srec or .bin files from the .elf output too.

Profiling is going to be next to impossible. To be able to profile, you must link in the profiling lib which keeps track of the processors performance graphs. As far as I know, this is not supported by the avr-gcc toolchain.

Generally, I tend to do 'profiling' by toggling pins when entering and leaving interrupts, etc. This gives a good indication of how much time the processor spends in various portions of the code. It's a little tedious, but does the job, and is done with very minimal impact on the overall system performance.

With regards to the avrlibc documentation, the man pages viewer is currently being worked on, and winavr currently comes with man pages for avr-libc. This seems to work fine, although I think the man pages viewer is still in its early stages.

I'll have a look at gdb, but if you're on windows, AVR Studio from Atmel does a brilliant job. You can add it as a tool in c::b so it's only one click away. Debugging optimised code is a PITA with Avr Studio, but it is still very capable.

[Keyla]

Thanks for your answer and your improvements.

I thinking of profiling,testing to do a more professional development on embedded devices. Yes currently I do similar tricks but I think they are dirty. I only thought that avr-gcc creates profiling infos by default because read somthing in the GCC doc.... of course under this conditions it isn't possible.

You are right, currently Im working with AVRstudio for debug session. But it isn't nice if you have to switch. and it would be to cool to run all in a single IDE By the way AVRstudio has a lot of bugs, too.

[BrianSidebotham]

Well, debugging in c::b seems to work fine with gdb and simulavr. For your information, I have the following debugger settings:

Debugger initialization commands

Code

target remote localhost:1212
load
break main
continue

You must also select/check the "Do *not* run the debugee" option

Simulavr must already be running in gdbserver mode. i.e. open a dos box and run

Code

simulavr -d atmega128 -g

before debugging.

I haven't fully tested it by any means, but I can debug avr code that has multiple libraries linked in, so quite a complex hello world example for the debugger. Debugger options are application-wide, not project-wide, so you'll only have to do those settings once.

[Keyla]

Wow this sounds realy good! I will test it when I will have more sparetime...

[Barricade]

Hello Brian,

I'm very interested in using c::b together with winavr/avr-gcc + debugging for c++ projects.
My current configuration use for that AvrStudio, but the c++ objects debugging is not
working very well. Can you check you configuration works for that please ?!

Thank you
Barry

[Keyla]

By the way, which Atmel do you use? I allways thought that C++ has a to big footprint for microcontrollers?

[Barricade]

I use ATMEGA128 and of course you should be carefull because the 4K RAM only.
But the bigger AVR's are coming now.

[Valentin66]

А мHello Brian,

I'm very interested in using c::b together with winavr/avr-gcc + debugging for c++ projects.
My current configuration use for that AvrStudio, but the c++ objects debugging is not
working very well. Can you check you configuration works for that please ?!

Thank you
Barry

And I can't use this configuration for AvrStudio, I don't know what could be the cause of my problem. I have no way to test this combination. I would be very grateful if you could share your experience in using c :: b.