Basic HM2 SPI driver

So lots of this is what the guys on #emc have been saying from the beginning. I now see the light and see why you would not want to support lots of devices right in the HM2 driver. So I think that all that the only information that the hm2 driver needs is what SPI channels you plan to use and how many "frames" to put on each SPI port. This is what SWPadnos suggested for something similar:

SPI=4,-1,5,-1

Meaning 4 frames on port 0, port 1 OFF, 5 frames on port 2, and port 3 OFF. This would create a set of HAL pins for each frame. They are as follows:

CD (U32) This is the channel descriptor for the frame
SEND (U32) This is pin for the bits to send, the length in bits is specified in the channel descriptor.
RECEIVE(U32) This is a pin for the resulting bits from the frame
READ(BIT) This is a bit that specifies if the frame should be sent during the hm2 read or write functions. If the bit is set, then the frame is sent during the read function.
ENABLE(BIT) Enable or disable the frame.

A driver could then be made for each device. There isn't really anything to difficult to do here. I believe that a simple realtime component could be written for any new device. Then the HAL pins connected and the interface should be very flexible. The device drivers should even be able to send internalization data to devices without any special features from the HM2 driver.


Let me know if I've got something wrong here. Of course I haven't address anything about how HM2 will actually do any of this, but it appears that a conclusion about this stuff needs to come first.

Possilbe HM2 SPI Hierarchy

Do you think this would work? Ignore the fact that it is XML. All the attributes, shown in read are HAL pins. Use config parameters to set how many of everything. Input a bit, float, int, scaling and length transform this into the proper bits to send to the SPI buffer. I know lots of details are missing.

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.