I have been working on a driver for the Hostmot2 Buffered SPI
function. The initial aim is to support the 7i65 Octuple Servo
Interface.

The aim is to make a general-purpose interface for the SPI modules, so
that the 7i65-specific code will be in a separate comp module. This
makes it easy to write drivers for any other cards using SPI, or for
home-built hardware.
Later iterations will probably support Decoded Buffered SPI and Simple
SPI functions.

I have been following the guidelines here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?SPI_Sub-Driver_For_Hostmot2
But have hit a snag.
In principle it all seems easy enough, but in practice the information
that the driver needs isn't available when it needs it.
The first problem is that the channel descriptors should really be set
up at load-time, and shouldn't really be pins. I assume that they are
pins in that spec so that external modules can set them (I believe
that there is no way for a module to set a parameter of another
module, but correct me if I am wrong). The problem is that the pins
have no value until both module are loaded and the pins are netted
together. That netting clearly can not happen until both modules are
loaded and have created the pins to net.
This issue is, in principle, manageable by writing the channel
descriptors into FPGA memory as soon as the driver starts, and before
sending/reading any SPI data,

A more difficult problem to overcome is related to the TRAM registration.
The way that BSPI works is that each channel descriptor creates on
what might be seen as a virtual port, in practice a specific memory
address/register on the FPGA. So a 24-bit signal might need to be sent
to 0x5400 and a 16-bit one to 0x5404. For TRAM registration each
internal HAL-driver representation of each data frame needs to be
registered to the correct FPGA channel at module load time.
Unfortunately there is no way to know what FPGA channel each frame
needs to go to until a value is read from what is called
hm2_7i43.0.SPI.0.FRAME.0.CD_INDEX in that Wiki Spec. And that can only
happen really rather too late.

One way round this would be to pass all the requisite information to
the Hm2 driver in the loadrt modparam. However this would lead to a
very long string (and, commas are not allowed inside a specific
sub-string) and relies on the putative 7i65 user to know the exact
spec required, and get it right.

To illustrate, we would need something like (2 bspi functions, 10
channels, 13 frames each):
loadrt hm2_pci config="firmware=hm2/sv8_8.bit
bspi_chans=0x1000055F.0x90010057.0x90020057.0x1003034F.0x1004034B.0x90050041.0x90060041.0x100705C7.0x900705C7.0xD00705C7
bspi_frames=0.0.1.2.3.4.4.5.6.7.7.8.9
bspi_chans=0x1000055F.0x90010057.0x90020057.0x1003034F.0x1004034B.0x90050041.0x90060041.0x100705C7.0x900705C7.0xD00705C7
bspi_frames=0.0.1.2.3.4.4.5.6.7.7.8.9"

This is workable, but relies on the integrator to know the required
incantations. (I guess that the 7i65 comp module could spit the
required config string out into dmesg)

I have been considering an alternative scheme:
loadrt hm2_pci config="firmware=hm2/sv8_8.bit bspi_conf=7i65.0.ini
bspi_conf=7i65.1.ini"

In this latter case the 7i65.0.ini string is the filename of a
configuration file. My intention is that these files would be created
by the 7i65 (or other) comp module in the config directory, or could
be hand-coded by the integrator to suit their own hardware.
The files would be human-readable.

What do folks think? It is rather a break with the way things have
been done up to this point. What file format would make sense? I am
thinking that it could use the same format as the existing INI files,
and I assume there are functions available to grab data from those.
The drawback is that as far as I am aware that format isn't ideal for
open-ended lists. Alternatively perhaps XML would work better?

To be honest, and thinking as I type, I am now thinking that the
extra-long config string is probably workable. Is there a built-in
function to split a dot-separated string of hex numbers into a u32
array? Is it possible to allow commas in Hm2 config strings? I am not
sure if it would break anything. It appears that hostmot2 used to use
strsep() but now uses argv_split(). I confess to being a little
confused, as that uses isspace() which should not break at commas, but
my experience is that it does. I need to investigate in more detail.

-- 
atp
"Torque wrenches are for the obedience of fools and the guidance of wise men"

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to