Code::Blocks Forums

User forums => Embedded development => Topic started by: Lost_Byte on March 25, 2012, 11:55:36 am

Title: Developing for AVR, IDE tuning.
Post by: Lost_Byte on March 25, 2012, 11:55:36 am

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.

Title: Re: Developing for AVR, IDE tuning.
Post by: scarphin on March 25, 2012, 12:12:47 pm

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 (http://forums.codeblocks.org/index.php/topic,13616.0.html)

Title: Re: Developing for AVR, IDE tuning.
Post by: Lost_Byte on March 25, 2012, 12:30:23 pm

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?

Title: Re: Developing for AVR, IDE tuning.
Post by: oBFusCATed on March 25, 2012, 12:53:53 pm

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.

Title: Re: Developing for AVR, IDE tuning.
Post by: scarphin on March 25, 2012, 03:50:29 pm

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.

Title: Re: Developing for AVR, IDE tuning.
Post by: Lost_Byte on March 25, 2012, 04:31:22 pm

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?

Title: Re: Developing for AVR, IDE tuning.
Post by: scarphin on March 26, 2012, 01:01:45 am

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.

Title: Re: Developing for AVR, IDE tuning.
Post by: Lost_Byte on March 26, 2012, 07:29:45 am

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!!!

Quote from: scarphin on March 26, 2012, 01:01:45 am

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.

Title: Re: Developing for AVR, IDE tuning.
Post by: scarphin on March 26, 2012, 12:23:47 pm

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. ;/

Title: Re: Developing for AVR, IDE tuning.
Post by: oBFusCATed on March 26, 2012, 12:49:46 pm

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).

Title: Re: Developing for AVR, IDE tuning.
Post by: Lost_Byte on March 26, 2012, 05:31:44 pm

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...

Title: Re: Developing for AVR, IDE tuning.
Post by: ziss_dm on April 24, 2012, 10:03:09 am

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