Supporting ubicom SX28/48/52 under Gideon

[Kuba Ober]

Hi,

I already have some code written for it as standalone stuff, and I wonder
 what would be the overall direction to integrating support for Ubicom
 SX28/48/52 under gideon.

Relevant links:
http://www.ubicom.com/products/sx/sx.html
http://www.parallaxinc.com/html_files/sxtech/sxtech_home.htm

I have a standalone commandline assembler more or less ready. It has bugs
 that I know of, yet as soon as I go to non-lazy state I'll fix them ;-))

I have assembly highlighting code for old KWrite (I'm in the process of
porting it to kate).

I have a loose skeleton for commandline gdb-UI-emulating in-system debugger
using Parallax SX-KEY (it's a cute dongle that you connect to the serial port
and to the target system that allows in-system programming and debugging).

I have a commandline programmer for SX-KEY.

Now the questions are:

1. I presume that assembler would better stay commandline just as it is.
Parallax syntax it is a rather simple assembly syntax, so it's parsing is
very fast. Thus the assembler does everything in a single program (i.e. it
doesn't need or provide an external linker -- all the needed sources are
included and it provides final .hex and .lst files). 2k lines assembly takes
about 0.2 seconds on a PIII/450.

2. As far as the debugger is concerned, should I:
- keep it as commandline-only and write some kind of gideon plugin for it, or
- separate the guts as a library and provide commandline-ui and gideon-plugin
ui's that depend on that lib?

3. The debugger is obviously architecture-specific, so for gideon UI things
like register/memory windows etc. need to be made from scratch. What is the
place they should go to in the source tree (more or less)?

4. Programmer: programming belongs more or less to the same category as run
and debug does, because you need assembled files to do it. Does gideon
provide enough menu flexibility to add actions to the menus (like to debug
menu, whatever).

5. Does gideon support multiple targets in the same project? My reasoning is
that I usually have some simple embedded things plus a simple qt or kde gui
for them -- it would make sense to have them in the same project.

Cheers, Kuba Ober