ries_ is now known as ries
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-09-20.txt
SWPadnos_ is now known as SWPadnos
JT-Work_ is now known as JT-Work
* alex_joni drops a needle
ting tinkle tinkle
I am looking at writing the Hostmot2 driver for the Mesa 8i20 card (2.2kW 3-phase servo drive)
I am trying to work out the best "pinout"
The config modparam declares how many "smart serial" channels are to be enabled on the host FPGA card, and those can connect to (currently) 3 different accessory cards.
My original idea was to simply expose the status/data registers of the sserial components and then drive those with external modules, chosen to suit the attached device.
ie hm2_5i23.sserial.global.status and hm2_5i23.sserial.0.register0 etc.
However, I am beginning to have a bit of a rethink, as the sserial peripherals report back a cookie, so could be configured at load-time, so we would end up with hm2_5i23.8i20.0.angle, hm2_5i23.8i20.0.current etc.
This seems a lot neater, as it saves having easily-forgotten links between the hm2_5i23 driver and an external module.
A typical setup would have 2x global and axes x 3 data registers.
do all the SPI-interface daughtercards have "cookies"?
I believe so.
It isn't SPI as such, as far as I know.
I think it is Mesa's own serial protocol.
oh, I see now that the 8i20 is RS-422 @ 2.5Mbps
I agree: if you can autodetect the devices, there's no reason to force the user to enter information about them
i think it makes sense for the hostmot2 driver to export a serial port at the kernel level, not at the hal level, and have a separate 8i20 driver load and attach to the serial port in the kernel, and export its own hal pins
Do you think it is reasonable for the hm2 driver to poll the daughtercards at startup and create pins to suit/
I just read the answer you wrote before I asked the question :-)
It definitely avoids exporting HAL pins with non-human-comprehensible data on them.
Which seems "right"
and avoids trying to stuff stream-like communications (such as a serial port) into a shared-memory scalar-like communication provider (like hal)
Yes, I was wondering how that would work out, it would need buffers and state-machines and other complications.
better off making some new abstraction outside of hal
OK, all that remains now is to actually do it :-)
This looks a bit more complicated than the LED driver.
I wonder what to call the modules in the modparam?
num_sserial? num_sslbp? num_rs422?
if they're rs422 i think you should call them that
if there's some funny extension or incompatibility, then dont use rs422
The 8i20 docs call is SSLBP
I guess I can ask Pete. It isn't a hard thing to change anyway, the 3-phase-pwm components changed name twice.
andypugh, the status register will tell you the external device so an appropriate name would be good
(the RS-422 part is not visible to the driver, only parallel registers for parameters and data)
I was going to use 8i20 for the pins themselves, so you would have hm2_5i23.0.8i20.0.phase-angle (or similar)
see that your 6th sense is still working ;)
My only question was what to call the generic smart-serial interface in the config line (where currently we state num_encoders=3, num_stepgens=2)
NOte that the SSLBP will also support the 7I64 and a couple of new cards we dont have a names for yet
You do realise that your nam-space only allows for 1000 products?
So, num_sslbp=8 would suit as a parameter?
Yes its sort of a mess now as the low level firmware ID only knows its a sserial not that it has a SSLBP ROM (Ill retire when I get to 1000)
Right, so sslbp is a sub-set of sserial?
The driver can probe the Firmware type (SSLBP MODBUS etc)
In that case I will use num_sserial
What does SSLBP stand for?
slow serial low baud protocol
SS for smart serial and LBP for our LittleBinaryProtocol
We have a minor change in the status regs to make heterogeneous remote devices easier to deal with, Ill send you the updated firmware and manual
So, fairly proprietery then :-)
Well its open and documented in the manual
Perhaps "proprietary" (even spelled correctly) was not quite the right word.
Thats better (we use it a lot even for our USB stuff)
basically maps 64K range register access onto a simple serial stream
Looks like we can run the 8I20 at close to 10 KHz update rate (servo thread rate) with SSLBP (though 4 KHz would be more comfortable)
I guess that means I have to keep the driver fast then?
I though computers were fast now...
Yes, but I can make them slow