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

[Naba Kumar <naba kumar gmail com>]

Hi Lucas,

On 3/30/11, Lucas van Dijk <info return1 net> wrote:
> I have extended the short description a bit. :)
Great :)

> 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).
Okay. Yes, it would be more usable if the gdb servers can be
started/ended as debugging is started/ended on Anjuta side.

> 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')
I meant precisely that. But I also understand there are many of them.
It was a cool idea, but not necessarily a feasible one. So, a
list/tree view is fine.

> > 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?
Uhm, I guess that depends on what you mean by "keywords". If these are
language keywords that you would want to get highlighted differently
in editor, that's where I mean gtksourceview may not have that
support.

But if you mean keywords as in C API specifically used in AVR
development that you want to be available for symbols
assistance/completion, then yes, it would be akin to putting them in
symbol-db. However, how to put is a matter of investigation. If it's
available as a library, then symbol-db can scan it similar to other
libs. But if it is some kind of "in build" in the compiler, then that
would require something new in symbol-db to be added. This can very
much be part of your initial analysis phase in the project.

> 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.
ARM use is not important for your project, I fully agree. Indeed
having USART comm terminal (I think it may be done with the existing
terminal plugin) and the pins graph would be awesome.

> That's a good idea, I will mention it. :)
Good.

I saw you updated proposal and it's looking good. Let's see how it progresses.

Regards,
-Naba