Re: [anjuta-devel] GSoC: Anjuta as an AVR development environment

[Lucas van Dijk <info return1 net>]

Hi Naba,

Thanks for your feedback, will update my proposal.
 

> That's a good write up. I have some suggestions to take into account.

In the description, you say "Create a great AVR development
environment ..., and a lot more avr tools into Anjuta.". The last
part, I think, can be made more precise - like what other tools (e.g.
the launch tool, PIN view, registers view etc.).

I have extended the short description a bit. :)

In the para referring to avr-gcc, I would suggest to describe more in
terms of adapting the entire project build structure to avr
environment, not just the compiler, because that's what it would be.
And also emphasize on using automake/autoconf (I don't think any other
backend works besides that). It would use the autotools project
structure to accomplish avr specific configure/build/install. this is
what the project template would put in place. .... Unless, you have
something else in mind?

I will indeed use the automake/conf backend, and I will explain it a bit better in the proposal.

I did not see you anticipate writing a new plugin for debugger based
off avr-gdb, you think avr-gdb is fully compatible with gdb in terms
of machine interface (MI2 or something, which is what Anjuta uses)? It
would be ideal to use existing one, of course. I am raising the
concern because I thought Seb hinted towards possible new debugger
plugin in one past email. Using simulavr might require fixing a few
things - without really going reading up simulavr, I would assume it's
a local gdb server connected in some way hopefuly not only through
local IP address (to allow easy detection). 

Instead of "configuring" the path and IP addresses of the gdb servers,
the ideal way is to configure the path through project template
(possibly tricky) and determine running instance of either simulavr or
avarice automatically.

Well, I thought it was necessary to write a new plugin as Sebastien mentioned it, but avr-gdb is as far as I know fully compatible with the normal gdb. simulavr is indeed a local gdb server, the default port is 1212, but it would be nice to start simulavr automatically when the user wants to start debugging, preferably with configurable hostname and port (per project)? And start avarice instead of simulavr when the 'on chip debugging' option is checked in project creation wizard (but it would be very handy if this could be changed when the project already exists).
 

Then, in the details section you mentioned chip data views casually,
but in my opinion, that's the part going to require writing new
plugins. So I would elaborate a bit on that. About the PIN details, do
you intend to use an actual diagram (that would be cool) or just list
of data (boring, but will do) - or perhaps both?

What do you exactly mean with a diagram? A sort of top down sketch of the selected chip, and show the pin status? That would be cool indeed, but there are a lot of AVR's with a lot of different pinouts, so it's a lot of work to support them all.

My initial idea was a treeview like in AVR studio:
http://nahians-avr.webs.com/AVRStudioInit.gif (window 'I/O View')
 

If the register view is done through gdb, isn't it already available
in Anjuta debugger? Same goes for memory/EEPROM viewing/editing. If
they are done through gdb, the memory view is usable, hopefully. If
they are accessed differently, of course, they would require new
plugins. If so, perhaps elaborating a bit on how the communication is
happening through makes sense.

I looked a bit more into avr-gdb, and it seems like you can view and edit registers and eeprom with avr-gdb.
 

The editor keywords extending part I think requires some
investigation. Last I remember gtksourceview didn't have that feature.
It may be possible now, though.

I can add an extra symbol DB right?
 

In the last para, you mentioned possible extension of this project for
arm development. Note that there are already couple of arm related
plugins available. Perhaps, you can look into them for possible
merge/ideas/what-next etc.

Well, I'm not planning to do a lot on ARM's, as I have almost no experience with them yet. But it seems a lot of the functionality I was planning to create, already exists in Anjuta (just needs to be tested if it works with avr-gdb too), I could make some nice tools which makes development easier, like an USART terminal for serial communication testing, or a graph which plots the status of specific pins against the time. 

One more thing I would emphasis, if I were you, is the idea of
complete avr development 'package'. You know, something like someone
installing/downloading it in one go and having his system fully ready
for avr development - he just needs to plug in the JTAG etc. It means
that all your plugins/templates etc. go in a single and independent
install for the user to extend Anjuta for total avr development. It
might give some higher selection chance to your proposal :).

That's a good idea, I will mention it. :)
 
Thanks Again,
Lucas