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

[Naba Kumar <naba kumar gmail com>]

Hi Lucas,

On 3/29/11, Lucas van Dijk <info return1 net> wrote:
> Here's my draft of my application, I think I'll submit it tommorow, as the
> GNOME GSoC admins also give feedback. :)
>
> http://pastebin.com/pxmhStW6
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.).

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

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?

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.

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.

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.

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

The last thing. Do I need to register anywhere to be a mentor? Forgive
me if I have not been following the google mentors mailing list
lately, but if anyone knows, please tell me :).

Thanks.

Regards,
-Naba