Re: XBoot Group

[Alex Forencich]

Brad-

That should be fixed now. I overlooked a couple of things when I set up
the group settings earlier.

A GUI sounds like a really good idea. The only trick with it, though,
is it has to be cross-platform since a lot of AVR users run windows.
And it also wouldn't be too much of a stretch to let the GUI communicate
with XBoot as well so you can have an all-in-one bootloader building and
downloading program. That could be pretty sweet. A lot of the other
bootloaders out there have GUIs, but only for downloading code, not to
mention they're usually closed source on the bootloader side as well.

What format do you think you will use for the configuration file?
Binary? XML? The standard sectioned config file format? It might be
nice if the config file is human editable as well, so command line guys
like ourselves can skip the GUI and just use a text editor, but still
get the benefits of a separate config file.

I say, go for it, but definitely do a little planning before you start
coding like mad.

Alex Forencich

On 05/14/2010 11:30 AM, Brad Nelson wrote:
> Hey Alex,
>
> I can't start a discussion on the XBoot development group - it says it's
> announcement only. Let me know if that was your intention, otherwise I've got
> an idea or two I'd like to talk about.
>
> Here's the one that I was just wanting to bring up with you. So, everytime I
> update the code to the most recent firmware version, I either have to backup my
> Makefile and xboot.h or I have to reconfigure everything from scratch.
>
> For an internship at CMU this summer, I need to brush up on my GUI programming
> skills (been embedded too long...). I was thinking of doing a GTK project to
> help out with that. So I was thinking, it would be pretty cool (and spare us
> a billion noob questions) to have a GUI that could set all the options. The
> configuration file could be saved separately from XBoot, and therefore not be
> disturbed by updating to the latest version.
>
> Just wondering what you think. I realize it's really an unnecessary luxury,
> but since I need a GUI project anyway, it's little skin off my back. And it
> would make XBoot really stand out ;)
>
> Brad
>

[Bradley Nelson]

Awesome, bro. I like the expansion to include GUI communications.
Cross-platform with GTK was what I was thinking - GiMP does it, along
with many other programs. But you're right, I will need to look into
it since I haven't done that before (open to hints). Here's my half-
baked plan, let me know what you think. Feature list first,
implementation second.

Features:
* Cross-platform GUI written in GTK.
* Uses AVRDude in the background to do the programming
* Uses SVN to update XBoot to the latest version.
* Uses "make" to compile things, so either a WinAVR or AVR-GCC
Makefile can be used
* Configures all available XBoot options
* Configures some available AVRDude settings
* Communicates with bootloader (e.g., can send all available AVR109
bootloader commands)

Implementation
* xboot.h stays as it is, with the only possible changes being
standardizing the line numbers where certain features are located
* A separate "feature config" file (possibly XML, maybe just CSV) lets
the GUI program know what line numbers certain features are at. This
way, a new feature doesn't require adding code to the GUI.
* The GUI lists the available features as parsed from the "feature
config" file, letting the user select from dropdown box/check/uncheck
available bootloader features.
* The GUI can save the setup to an alternate file. Features will be
saved by unique IDs, which will allow for future compatibility.
* The GUI has a list of AVRDude options that will go into the
makefile. Should probably parse directly from AVRDude available
programmer output.
* The GUI has a few buttons:
* Save setup to file (as described above)
* Update bootloader to latest version (via SVN/tarball)
* Export xboot.h
* Compile bootloader
* Program Bootloader to Chip (with alternate filename)
* Program Fuse Bits (probably with just hex values, but later maybe
we could add a list of chip specific fuse bit options like
AVRStudio ... I'm sure that data already exists somewhere...)
* Program Application to Chip (with associated filename box and
browse button)
* Several buttons to play with the bootloader (erase flash, erase
EEPROM, read buffer, write buffer, etc.)

I'm hoping this kind of architecture will keep program maintenance to
a minimum. I've drawn a lofty picture, but I plan on starting with a
bare bones set of features and adding features incrementally. I
should have a GUI drawn up in a few days. Where should I add the GUI
folder into the repository?

I'm a little concerned because I haven't done any Windows programming
since VB6 ... MinGW should work for a Windows compile environment,
right? I think I'll start with getting it working in Linux first,
then port it over to Windows.

Brad

--
You received this message because you are subscribed to the Google Groups "avr-xboot" group.
To post to this group, send email to avr-...@googlegroups.com.
To unsubscribe from this group, send email to avr-xboot+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/avr-xboot?hl=en.

[Alex Forencich]

Well, XBoot uses a modified version of AVRDude to access the signature
rows, so you won't be able to access everything with avrdude. However,
if you use avrdude, it might also be possible to program XBoot itself
from the GUI. I can post a feature request on the AVRDude bug tracker
to add support for XBoot since the necessary modifications are very
simple.

As for xboot.h standardization, don't rely on line numbers. What we
should do is create an xboot.xml file that defines all the parameters as
well as the overall structure of xboot.h so that the entire file can be
generated from the xml file. That way, we don't go replacing the wrong
thing if something is commented out. The other advantage to this is
that the GUI just needs to implement general types of features and it
uses xboot.xml to fill in all the blanks. That way, it adapts to the
version of xboot used (doesn't have to be latest) and you don't need to
update the GUI for every version of xboot. Also, it should be usable
from the command line so it can be called from a makefile. That way it
can be called from either xboot's makefile or someone else's makefile to
build xboot with a specific feature set.

And as for windows, I have done a bit of .net development, but very
little cross-platform stuff. It will definitely be a learning experience.

Alex Forenich