Developing for AVR, IDE tuning.

[Lost_Byte]

Hello!
My last project for AVR been completed few years ago. And these years have been spent on embedded linux developing...
In order to develop for embedded linux C::B is the best (IMHO), and I'd like to use C::B in every kind of projects.
Some days ago I decided to return to some my old AVR projects,and implement some fresh ideas.
And I realized ... how inconvenient to write code in AVR Studio.

I have converted my AVR projects to C::B IDE.
And I would like to perform the development process without leaving the IDE: code-writing>flash-filling>debugging and so on.

I've tried to set this strings:
On "project/target options">"Debugger" tab> "Remote debugging support" > "Additional shell commands" > "Before connection" put these lines:
avrdude -p x128a1 -c jtagmkII -e -P usb -U flash:w:$(TARGET_OUTPUT_FILE).hex
avarice -x -2 -j usb -R :4243
All of them sucessfully operate in console. But entering to debug under C::B failed with "programm is not been run" message.

A questions to AVR developers:
- is any tunes to simplfy developing for AVR?
- how to start AVR-tools such as avarice or avrdude?

P.S. C::B version is 10.05.

[scarphin]

First of all it's better to switch to a debuggers nightly. Unfortunately 'Additional shell commands' cannot work the way needed. Say u want to launch 'avarice' by scripting it in 'Before connection', the debugger won't launch till 'avarice' has stopped. So not much of use. I solved this problem by using the tools menu. I made entries in the tools for the programmer and debugger and I launch them when I need them. Have a look at this topic:
http://forums.codeblocks.org/index.php/topic,13616.0.html

[Lost_Byte]

Thanks a lot! How could I have guessed? flashing tool...

Ok! But why step-by-step programm running is so slow? About 10 seconds to step!!!
Whose blame? avarice? C::B debugee?

[oBFusCATed]

If you have many watches or running disassembly or having windows like call stack/running threads/examine memory all the time it will be slow, because there is too much output produced by gdb.

[scarphin]

It's mostly the gdb and gdbserver (avarice). Also the hardware debugger (AVR Dragon for me) doesn't run so fast. Even if u disable many of the register view, disassembler and other things, u won't get much speed unfortunately.

[Lost_Byte]

None of the above reasons...
Debugger: JTAG-ICE mkII
No any debugging windows.

And now quite strange things... Trace-cursor does not appears, "Programm is not being run" in debugger window, "Failed to synchronise with the JTAG ICE (is it connected and powered?)" on C::B log....
Are these tools efficient, in general? Or it's just experimental? I mean avrdude+avarice...

Does anyone uses these seriously? ...Under C::B IDE?

[scarphin]

Believe it or not there is no faster way to debug with hardware whether it's 'jtag-ice' or 'dragon'. It's not related to CB, it's not even much related to 'gdb' and 'avarice', that's how things are. You can also try AVR Studio's simulator.

[Lost_Byte]

Simulator???
There are:
- SD-card with FAT FS on SPI;
- 2x C328R Cameras on UARTS;
- mma7455 accelerometer (SPI);
- M2M modem connection (UART with hardware flow)...
- Dallas ds1338 RTC (I2C).
in my project...

Years ago I've tried to implement  C328R driver under both simulavr and IAR-sym, only for sport. It is awful!!!

Believe it or not there is no faster way to debug with hardware whether it's 'jtag-ice' or 'dragon'. It's not related to CB, it's not even much related to 'gdb' and 'avarice', that's how things are. You can also try AVR Studio's simulator.

Sorry, I do not believe. Hardware debugging under AVR Studio is so fast as fast you can press F5 button, whatever debug views you have opened...
It is unfortunate that this is not a open source project.

[scarphin]

By 'faster' I mean 'same speeds as PC debugging'. AVR Studio has its own protocol for PC side for debugging but it uses the same hardware in the end. I've also tried it but there is no considerable speed difference imo, you can't still catch the 'zero-crossing' of the mains voltage (which I needed at the time) and run the corresponding portion of the program till the next 'zero-crossing'. Afaik Obfuscated is working on a MI interface for the gdb which I think will speed up things, I don't know how much increase in speed it will attain though. Maybe Obfuscated can give some ideas. ;/

[oBFusCATed]

The new gdb/mi plugin is faster only if gdb produces lots of output, because the protocol is asynchronous and so multiple commands can be sent to gdb at once.
If you don't see lots of lines in the Debug log pane, when full logging is enabled the problem is not in C::B's integration. It is somewhere inside gdb (probably).

[Lost_Byte]

Yee... I see a lot of lines... And they are scrolling a long time... too long...

OK... I hope gdb\mi plugin will be more more advantage...

[ziss_dm]

Hi Lost_Byte,

I'm not sure is it still relevant, but I have used slightly different approach (which is working for me)

1) Set type of project "Dynamic Library" - output <project_name>.elf
2) Set avrdude as a host application. Good idea to tick "Run host in terminal". This way "Run" means - upload
3) For debugger:
  - remote connection
  - Additional GDB commands
     - before connect

Code

file <project_name>.elf               -> to fix attempt to load avrdude as application
shell cmd /c start_gdb_server         -> to auto start gdb server (avarice in your case)

   
     - after connect

Code

tbreak main  

   

regards,
ziss_dm