SPI serial interface for MESA Anything I/O Cards

Ok, so I have been spending some time working on developing some hardware, and software for running serious RepRap machine using EMC2. I have to admit that I see lots of advantages of using EMC over the Arduino or Sanguino core controllers. I have been using a MESA 7i43 (www.mesanet.com) FPGA card running Hostmot2 firmware to control a three axis gantry mill. I'm working on adding RepRap capabilities to this machine.
The electronics are great, and I can use servo motors with encoders or stepper motors and still have tons of I/O available to do what I want. However, there is one hold up. I would like EMC to be in complete control of the RepRap machine including the extruder. The only problem with the MESA cards is that they have no analog inputs built into them. I have been talking with the EMC developers trying to determine if it is reasonable to add the SPI serial interface onto the MESA cards to read A/D converters, or a SPI thermocouple interface to measure the temperature. EMC already has PID controller with full feed forward control loops built in. Anyway, this post is geared toward the EMC developers.

Well now that is all done, we have been talking about the SPI driver for the Hostmot2, it has been determined that the hardware portion of the interface is very doable. The hard part seems to be creating a way to describe how to talk to the devices on a BSPI channel, and how to interpret the resulting data. As I have described, I'm not terribly knowledgeable in the way of all the EMC internals. I have been doing lots of reading in the last couple of weeks, but I still have a ton to learn.
Currently the way that the Hostmot2 driver is customized to a specific set of modules (encoders, PWM, stepgen, ect...) is with "config" mod parameter (please forgive me on the terminology) that are basically command line parameters. This is apparently quite difficult to program, but looks like the best way to setup the driver. Today on the IRC I asked if an XML file describing the configuration would be any easier to use. Because of the realtime nature of the driver, this would require lots of "messy" code working directly with the kernel. So not good.

I just kept thinking that we could easily describe how to talk to a device and interpret the results using a XML file. So, here is another one of my crazy stabs at this whole SPI driver mess:

• Create an XML file that gives the hierarchy of the SPI channel and describes how each device talk. It would be nice to have a GUI, but not really necessary.
  
• Develop a script that parses the XML file for errors and conflicts, and then generates the source code for a new SPI driver for the attached devices.
  
• Compile the driver prior to EMC runtime, do all the stuff that I don't know how to do to make the driver work.
• And somehow make it work with the current Hostmot2 dirver...um...I don't know how to do that.
  

Naturally what I'm suggesting is crazy, after all I'm the one saying it. However, I hope that this may spark some ideas of how this might work. Here is a view of a possible XML tree for an BSPI channel:
And here is the raw XML:

There are lots of different SPI devices, but of most interest in this application is A/D converters, D/A converters, and GPIO deceives. The script I talked about would have to know how to handle different types of devices. For A/D, we would need a type that takes the right N bits and creates a scaled, or unscaled, number out of them. The opposite for D/A. For GPIO, the data would need to be mapped to and from the bits.

Anyhow, I'm done going crazy now. let me know what you all think. I'm almost certain to hear that this idea is not the best because hey, Hal drivers are suppose to be static. This of course is just the opposite of standardized components.