Back
[02:36:22] <cradek> I miss the cvs-xemacs integration. but do I miss it enough to go looking for some git-xemacs thing? does it even make sense?
[02:41:54] <SWPadnos> hardly
[02:42:01] <SWPadnos> err. I meant totally
[06:30:55] <alex_joni> jepler: tried that patch, but it still failed
[06:31:23] <alex_joni> it seems that f[0] isn't an int, so the array v[f[0]-1] doesn't work
[06:31:36] <alex_joni> I used f[0][0] and that worked
[06:33:46] <alex_joni> but now I'm getting another error:
[07:19:53] <alex_joni> http://pastebin.ca/1510828
[07:47:43] <alex_joni> hmm.. it seems to work, but I still get that error
[07:47:49] <alex_joni> * alex_joni is happy :D
[11:53:14] <jepler> alex_joni: well, don't commit it..
[11:53:28] <jepler> it probably breaks files that do specify surface normals,t oo
[12:03:01] <jepler> hm, I looked at my patch again and it makes no sense
[12:09:53] <jepler> it has to loop over 'f'
[12:09:54] <jepler> http://emergent.unpy.net/index.cgi-files/01157053957/vismach-alex2.patch
[12:09:57] <jepler> again, without testing ..
[13:19:28] <alex_joni> jepler: I managed to convert my obj to one with normals
[13:19:41] <alex_joni> it looks like: f 1//1 2//2 3//2
[13:19:43] <alex_joni> etc..
[13:20:01] <alex_joni> but it gets loaded by vismach (in the original version)
[13:20:18] <alex_joni> the only thing is that error I get with
http://pastebin.ca/1510828
[14:02:27] <jepler> you get that with the old version and the new?
[14:32:29] <cradek> wow, I don't think many people will use that 1710 card at a cost of $1461.00
[14:38:19] <SWPadnos> the encoders are probably close to that cost each as well
[14:41:29] <cradek> don't be ridiculous - you can get an entire working machine for about that :-)
[14:43:20] <cradek> I guess you can get a good deal on stuff like servos and encoders if they're bolted to tons and tons of cast iron
[15:01:07] <SWPadnos> yes indeed
[15:04:10] <skunkworks_> cradek: figured out all the relays yet? ;)
[15:04:28] <cradek> nope, not one bit
[15:04:46] <cradek> the mesa stuff will be here tomorrow - I can't decide what to do first
[15:05:02] <cradek> I might try to get the spindle to run
[15:06:41] <skunkworks_> cool
[15:07:59] <skunkworks_> you said there was a resolver on the spindle motor? is there resolvers for axis feedback also?
[15:08:23] <cradek> no, axis feedback is tach + diff encoder
[15:08:38] <skunkworks_> nice
[16:16:41] <alex_joni> jepler: actually I only tried the old version
[16:16:46] <alex_joni> since I managed to convert my file
[17:43:23] <pcw_home> Sebastian: around?
[17:43:33] <seb_kuzminsky> hi peter
[17:44:12] <pcw_home> Hi!
[17:45:49] <pcw_home> I was thinking about the SPI interface and wondered if it might be best to punt
[17:45:51] <pcw_home> and do the chip/daughterboard specific code in a comp, just exposing enough of the bare SPI
[17:45:53] <pcw_home> hardware to make the comp clean
[17:46:59] <seb_kuzminsky> i think that's pretty much the design i'm planning on
[17:47:34] <pcw_home> Building in really specific chip interfaces in the driver seems wrong
[17:47:42] <seb_kuzminsky> the hostmot2 driver would have an spi subdriver within it, much like it currently has encoder & stepgen subdrivers
[17:48:14] <seb_kuzminsky> the spi driver would export a number of spi interfaces, probably to the kernel, not to HAL
[17:48:41] <seb_kuzminsky> then chip-specific drivers would be loaded, and the load-time arguments would say which spi interface to attach themselves to
[17:49:02] <seb_kuzminsky> so you'd loadrt hostmot2, then hm2_pci (say), and you'd have some encoders & pwmgens & spis
[17:49:25] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[17:50:03] <seb_kuzminsky> then you'd "loadrt hm2_ad5754 spi=0" and "loadrt "hm2_ad7329 spi=1" or something like that
[17:50:45] <seb_kuzminsky> those drivers would use the hm2 spi api provided by the hostmot2 driver to set up their frames, and they'd get data back (in callbacks from hm2_read) and update hal pins
[17:51:23] <seb_kuzminsky> at least that's what i think, but i havent actually tried writing any of it yet! and my untested designs usually dont work :-/
[17:51:49] <SWPadnos> heh
[17:52:31] <pcw_home> Similar to what I was thinking, but I was going to put all the chip specific code in a comp
[17:52:33] <pcw_home> I was thinking the advantage would be that it would make it easier for users to write
[17:52:35] <pcw_home> their own specialized chip/daughtercard interfaces
[17:53:10] <seb_kuzminsky> do you mean that there would be one comp that would have drivers for all spi chips?
[17:53:23] <pcw_home> In other words there would be a 7I65 comp, A 7I64 Comp etc
[17:53:39] <seb_kuzminsky> i see, a comp per daughterboard, not a comp per spi slave
[17:54:52] <seb_kuzminsky> i suppose we could do it that way, the upside is it's easier to load the right drivers for daughter boards, the downside is that it's harder to reuse the drivers for individual spi slaves
[17:55:07] <pcw_home> The sharing of the SPI interface on cards like the 7I65 makes creating a 7I65 driver out of individual chip
[17:55:09] <pcw_home> interfaces painful
[17:55:45] <seb_kuzminsky> i see, that makse sense i think... i'll have to look at that in more detail
[17:56:01] <seb_kuzminsky> but right now my friends just arrived for lunch so i'll bbl
[17:56:04] <ehj666> Seb_kuzminsky: Is there an error in the hm2-stepper sample configuration for the 5i20 in 2.3.3? Loading the sample configuration with a 5i20 board installed, I am getting hm2-stepper.hal:43 parameter or pin 'hm2_5i20.0.watchdog.timeout_ns' not found.
[17:56:36] <ehj666> rats, too late.
[17:56:38] <seb_kuzminsky> ehj666: that probably means the hm2_pci driver didnt load - look in dmesg and lspci and see if something broke
[17:56:41] <seb_kuzminsky> bbl
[17:56:58] <pcw_home> Bye Seb
[17:58:37] <SWPadnos> re: SPI, if you want to use external modules to interpret and format data, I'd make a SPI option on the loadrt line that specifies the number of words to transmit per transmit strobe
[17:58:55] <SWPadnos> that would tell the HM2 SPI code how many data I/O pins to make
[17:59:27] <SWPadnos> so if you tell it you need 4 words, you get hm2_pci.0.spi.0.data-{in,out}.[0-N]
[17:59:36] <SWPadnos> err, with N=3, for the 4-word case
[17:59:55] <SWPadnos> even if you send 4 16-bit words, there are 4 unsigned 32-bit HAL pins
[18:00:13] <SWPadnos> the word size, CPOL/CPHA, and bit rate can all be HAL pins/params
[18:00:15] <pcw_home> But you may have a mix of data widths...
[18:00:33] <SWPadnos> can the buffered SPI do that in a single "burst"?
[18:01:13] <pcw_home> Yes, its can do a mix of lengths, speeds, etc
[18:01:16] <SWPadnos> if so, then you export N word-size pins as well
[18:01:29] <SWPadnos> on a per-channel basis?
[18:01:39] <pcw_home> Yes
[18:01:48] <SWPadnos> I don't see multiple speeds being too useful - if a device can handle a high speed, just use that :)
[18:04:50] <pcw_home> Cards like the 7I65 that are isolated and share the isolation for cost reasons may have different SPI device
[18:04:52] <pcw_home> speeds, also readback is slower so DAC outputs can run at 16 or 24 Mbps but ADc readback only 8
[18:04:54] <pcw_home> This will improve after I add readskew adjust reads will always run slower
[18:05:10] <pcw_home> (but reads)
[18:06:35] <pcw_home> This has to do with channel-channel skew in the isolator being really small, but propagation delay large
[18:06:36] <pcw_home> and somewhat unpredictable
[18:16:10] <SWPadnos> wouldn't you use separate clocks for read and write then?
[18:16:21] <SWPadnos> or just write at the slower speed
[18:16:58] <SWPadnos> or use separate SPI channels for the inputs and outputs
[18:23:57] <CIA-2> EMC: 03cradek 07master * r948621e9c242 10/configs/demo_sim_cl/ (demo_sim_cl.hal demo_sim_cl.vcp): make this run again - not as good a demo without the external buttons, though
[18:34:45] <pcw_home> But think like the ADCs have DIN and DOUT and if I have a shared interface I don't want to slow DACS down to the ADC rate
[18:34:46] <pcw_home> for a high performance systen I would either not use isolation or have one interface per chip
[18:35:53] <pcw_home> (but for motion control, high performance costs money and gains nothing)
[18:39:13] <SWPadnos> oh, so you have a separate clock rate for each CS line in a given SPI module
[18:39:16] <SWPadnos> (more or less)
[18:39:21] <pcw_home> Even for a single chip (like the quad 16 bit DACS we use on the 7I65)
[18:39:22] <pcw_home> If I am only sending data I can use the maximum data rate, but if I am reading status
[18:39:24] <pcw_home> (like overcurrent shutdown or some such) I need to run the SPI interface at a lower speed
[18:39:56] <pcw_home> Yes for each of the 16 channel descriptors for a given BSPI channel
[18:41:40] <SWPadnos> I'd say the "generic SPI interface" probably doesn't need to expose all that at first
[18:41:45] <pcw_home> The BSPI really only makes sense for interfacing with chips that have multiple channels (like the 7I65 uses)
[18:41:47] <pcw_home> for something simple like the 7I64 the SSPI (non buffered) interface makes more sense.
[18:42:10] <SWPadnos> the only thing I can see people using is multiple word transfers
[18:42:37] <SWPadnos> like the 6-channel ADC I have, I'd like to be able to tell the SPI driver to do 3x 32-bit transfers
[18:42:51] <pcw_home> No it just needs to be a step up from raw-read and raw-write :-)
[18:42:51] <SWPadnos> (which is one of the formats you can read the 6x 16bit values with)
[18:42:55] <SWPadnos> yeah :)
[18:43:26] <pcw_home> I would presume that all done in the comp
[18:43:33] <pcw_home> (thats)
[18:43:47] <SWPadnos> even single-transfer mode would be great as a start, but I started thinking about common configurations (like having several chips in series), so multi-word seems lke a good thing to plan for from the start
[18:43:54] <SWPadnos> yes, decoding the data would be done in the comp
[18:44:20] <SWPadnos> but I think it would be better if it weren't necessary for every external SPI comp to have to queue things maually
[18:44:41] <SWPadnos> so the ability for the HM2 side to send/receive a few words at a time is a boon
[18:44:44] <pcw_home> The SPI interfaces support multi word (Easier with BSPI) via the DontClearFrame bit
[18:45:32] <SWPadnos> sure
[18:45:37] <pcw_home> Had to use that for interfacing with a serial EEPROM (40 bit command/address)
[18:45:53] <seb_kuzminsky> i dont think the spi drivers will show up in hal at all
[18:45:56] <SWPadnos> you'd need both modes (send several words, with a CS strobe between, and send several words like a single long word)
[18:46:19] <seb_kuzminsky> the per-chip drivers will talk to the spi drivers via direct function call, and the *per-chip* drivers will expose their stuff to hal
[18:46:44] <SWPadnos> my proposal is that the HM2 portion presents a few control pins (CPOL, CPHA, bt rate, word length, maybe other mode settings like DontClearFrame)
[18:47:04] <seb_kuzminsky> SWPadnos: i think that stuff belongs in the per-chip driver
[18:47:10] <SWPadnos> and then, based on the loadrt parameters, also presents N data-in.xx and data-out.xx u32 pins to HAL
[18:47:19] <seb_kuzminsky> they're arguments to hm2_spi_allocate_port() (or whatever it'll be called)
[18:47:26] <pcw_home> You dont think the per chip (or daughtercard) part can be done in a comp?
[18:47:37] <seb_kuzminsky> pcw_home: yes i do
[18:47:41] <SWPadnos> (where N is the number of words to reansfer per read/write strobe, which is specified on the loadrt line)
[18:47:57] <SWPadnos> and then you have an external comp which takes the data and makes sense of it
[18:48:06] <SWPadnos> in addition to fiddling with the strobe pin(s)
[18:49:36] <seb_kuzminsky> i think the per-chip/per-daughterboard drivers will know what their chip(s) need in terms of polarity and phase and word size, and they'll tell those things to the spi interface driver when they register
[18:50:13] <seb_kuzminsky> the spi interface driver (in the hostmot2 comp) will do the reads/writes, and call the per-chip driver's "handle data" callback when a complete frame is received
[18:50:15] <SWPadnos> oh. I was thinking of components that don't specifically have to register with HM2
[18:50:21] <SWPadnos> they could be userspace even
[18:50:30] <SWPadnos> (but not for readback, probably)
[18:50:31] <seb_kuzminsky> SWPadnos: you'd hook them up via hal nets?
[18:50:34] <SWPadnos> yep
[18:50:48] <SWPadnos> they become data converters, for hte most part
[18:51:06] <SWPadnos> on one side they have a very few pins to talk to SPI (the actual data, plus a strobe pin)
[18:51:17] <SWPadnos> on the other side they have data that makes sense for whatever is attached
[18:51:38] <seb_kuzminsky> yeah i see what you mean
[18:51:40] <SWPadnos> your deisgn is better though, regarding initialization
[18:52:03] <SWPadnos> there isn't a really good way to do one-off inits or other mode changes with the separate component design
[18:52:16] <seb_kuzminsky> a nice feature of your design is that you can halsample/halscope the spi frames
[18:52:24] <SWPadnos> (unless the number of words to transfer and the bit length are pins, which get attached to the external component)
[18:52:25] <seb_kuzminsky> fwiw
[18:52:27] <SWPadnos> yes
[18:52:38] <SWPadnos> and you can use a different SPI interface, if one becomes available
[18:52:57] <SWPadnos> so someone could write a bit-banging SPI driver for the parport, and then connect the same external hardware to it
[18:53:03] <seb_kuzminsky> with my design you'd have to unload and reload the per-chip driver to change spi interface
[18:53:11] <seb_kuzminsky> oh i see what you mean
[18:53:24] <seb_kuzminsky> well the bit-banger should just implement my api ;-)
[18:53:40] <SWPadnos> oh, and the same internal HAL component to massage the data :)
[18:53:42] <SWPadnos> heh
[18:53:51] <SWPadnos> my parport/hm2/eek driver
[18:53:53] <seb_kuzminsky> have an spi service in the kernel, like the parport service in linux - you register ports and users
[18:54:17] <SWPadnos> theoretically, a userspace API is possible, and there are hardware SPI chips that are supported by the kernel
[18:54:27] <SWPadnos> again, it's all HAL pins, so it
[18:54:37] <SWPadnos> it's configurable however you need
[18:55:00] <SWPadnos> it would have to be done as an HM2 module to support all the advanced features of the BSPI though
[18:59:49] <ehj666> seb: Got a minute?
[18:59:53] <seb_kuzminsky> ehj666: sure
[19:00:47] <ehj666> I did not see an error in dmesg other than a termination message.
[19:02:16] <ehj666> I created a hal file based on hm2-stepper.hal which did the 1st four commands, i.e loadrt trivkins; loadrt motmod...;loadrt hostmot2; loadrt hm2_pci...
[19:02:38] <ehj666> Then used halcmd -f test.hal to load it, which worked fine.
[19:03:09] <seb_kuzminsky> after loading that test.hal file, what does "show pins" show?
[19:03:31] <ehj666> Doing halcmd show pin, shows expected pins, except no pins starting hm2_5i20...
[19:04:08] <ehj666> So no hm2_5i20.0.watchdog.timeout_ns, etc.
[19:04:46] <ehj666> Pins starting axis. and motion. are all that appear.
[19:05:05] <cradek> that may be a param
[19:05:08] <seb_kuzminsky> that's a problem
[19:05:47] <ehj666> k, is there something I can do about it?
[19:05:57] <seb_kuzminsky> does lspci show the 5i20?
[19:08:01] <ehj666> Hmm, don't see it. Missing 5i20 board used to give a very different error though. I will shut down and reseat the board.
[19:08:10] <seb_kuzminsky> gulp
[19:08:14] <seb_kuzminsky> ;-)
[19:15:00] <ehj666> seb: Ok, that seems to have got it. I thought a missing board would generate an error on the loadrt hm_pci... line.
[19:15:23] <seb_kuzminsky> no, though it would be nice if it did
[19:15:38] <seb_kuzminsky> and alex suggested a way to make that happen, i just havent implemented it yet :-(
[19:15:45] <seb_kuzminsky> too busy making chips :-)
[19:16:47] <ehj666> k, I thought I remembered getting a different error for that. Thanks.
[19:17:07] <SWPadnos> hal_m5i20 probably did print some sort of error
[19:17:29] <ehj666> k
[19:17:29] <SWPadnos> it was probably easier, since it was only looking for one type of card
[19:17:53] <SWPadnos> (it's not strictly an error to find zero 5i20's, it's only an error if no cards of any type are found)
[19:18:41] <seb_kuzminsky> it'll be pretty easy i think to report an error if the hm2_pci "config" argument doesnt exactly match the hm2 boards found
[19:20:13] <SWPadnos> can you specify the actual board (via PCI bus:num or similar)?
[19:22:23] <seb_kuzminsky> it could be changed to do that (i think) but currently it uses hotplug to enumerate all the anyio pci boards it can find
[19:25:20] <Lerman_______> Lerman_______ is now known as Lerman
[19:27:54] <SWPadnos> is it a crap-shoot as to which is first when you have more than one?
[19:28:26] <seb_kuzminsky> sort of, yes :-(
[19:28:38] <seb_kuzminsky> the order is the same from boot to boot, but i dont know how to predict it beforehand
[19:29:28] <SWPadnos> and it could change from kernel to kernel, most likely
[19:29:45] <SWPadnos> there's probably a way of telling udev / hotplug to do it one way, but I don't know how either
[19:30:04] <seb_kuzminsky> i think detection order wont change from kernel to kernel, but i dont know for sure
[19:31:17] <SWPadnos> I wouldn't count on it, these things have changed before :)
[19:33:28] <seb_kuzminsky> it'd be nice if you could specify the bus:dev in the hm2_pci config modparam
[19:34:39] <seb_kuzminsky> config is an array of string, which is internally parsed to split out the different "key[=value]" bits
[19:35:14] <seb_kuzminsky> i could add a key named "address" or "pcidev" or something, with a value of "bus:dev", and that config array entry would apply to that device only
[19:47:44] <SWPadnos> do they have serial numbers in the PLX chip (or EEPROM)?
[19:48:03] <seb_kuzminsky> i dont know
[19:48:05] <seb_kuzminsky> pcw_home: do you know?
[19:53:48] <PCW> Sebastian: Theres no serial number ATM but theres probably someplace
[19:53:50] <PCW> in the EEPROM where you could stick one, I think there may even be a standard place
[19:54:11] <seb_kuzminsky> if it's not already in all the in-use cards, it probably makes more sense to use the PCI bus address
[20:00:18] <PCW> There is a standard place = VPD or Vital Product Data we've just not used it
[20:00:20] <PCW> Its part of the PCI r2.2 Spec
[20:05:12] <PCW> It also gives a standardized EEPROM access method (no bit banging)
[20:05:14] <PCW> Seem to me I had to use it with the 3X20 since its bridge has no GPIO access to the EEPROM
[20:14:43] <alex_joni> 3x20 + 7i68 is cool
[20:15:32] <PCW> Its pretty dense I/O if you just use the 3X20 or several
[20:16:05] <alex_joni> what's the price range?
[20:16:13] <PCW> We've had it working with 7 meter cable
[20:16:14] <alex_joni> I notice it's not in the price list.. or I can't find it :)
[20:16:37] <PCW> ~300 for module, ~100 for 7I68
[20:17:40] <alex_joni> so a bit more than a 5i22 then ;)
[20:18:11] <alex_joni> although that's "only" 96 IO
[20:20:12] <PCW> We should have cheaper equivalents when Spartan6 is available
[20:23:22] <jepler> due to the integrated PCI express interface? or other factors?
[20:26:17] <PCW> Yes Spartan6 has one one lane PCIE interface
[20:27:00] <PCW> But its more troublesome in that it has to self configure at power up
[20:30:15] <PCW> Spartan6 design needs a fail-safe "bootstrap" configuration
[20:33:42] <PCW> 3X20 bridge chip is expensive, its really a PCIE-->PCI bridge (PEX8111) + a PCI --> LocalBus bridge (PCI9056) in one package
[20:35:55] <SWPadnos> huh. I'd love to be able to put a half dozen USB2 hosts in one of those, plus a few timing blocks of various types.
[20:36:30] <jepler> * jepler can hear the wheels turning in SWPadnos's head
[20:36:39] <SWPadnos> clickity-clack
[20:36:58] <PCW> Alex: it has a larger FPGA also though its something of a nuisance
[20:37:00] <PCW> The 2M chip is a lot cheaper than the 1.5M and a little cheaper than the 1M one
[20:37:01] <PCW> but the 2M Spartan3 is not supported by WebPack
[20:37:39] <SWPadnos> figures
[20:38:14] <SWPadnos> a little birdie told me that you can copy the (mumble) chip description files into the correct directory, and the webpack will then support those chips
[20:38:37] <SWPadnos> assuming you can get the mumble file, of course
[20:38:44] <PCW> How interesting...
[20:39:10] <alex_joni> jepler: I only heard a hollow *clong*
[20:39:17] <jepler> SWPadnos: how much bandwidth back to the host do you need, though? you only get 250MB/s on that one lane
[20:39:18] <alex_joni> bet he has something stuck between those wheels
[20:40:14] <SWPadnos> that's enough for me. I don't need the full bandwidth to all the devices, just pretty fast transfer
[20:40:18] <PCW> The bridge wont even do that, maybe 180 MB/sec
[20:40:29] <SWPadnos> yeah, and the description says ">150MB
[20:40:30] <SWPadnos> "
[20:40:37] <PCW> SPartan 6 should do 250 MB/sec full duplex
[20:40:53] <SWPadnos> cool
[20:41:27] <SWPadnos> oh hey pcw, can you email me a diagram with the hole and 50-pin connector positions of the 5i23?
[20:41:33] <SWPadnos> thoth at sover dot net
[20:41:51] <PCW> I guess Spartan6 wont support Gen2
[20:41:52] <PCW> OK Will mail...
[20:41:54] <jepler> what's "integrated hard memory" mean, in this list of spartan6 bullet points?
http://www.xilinx.com/products/spartan6/index.htm
[20:41:57] <SWPadnos> I think I'll need to make a daughtercard that plugs straight into the headers
[20:42:46] <PCW> It has a DDR2/3 memory controller hardwired into certain pins
[20:44:33] <seb_kuzminsky> this still calls the development version of EMC the "CVS" version:
http://www.linuxcnc.org/docs/
[20:45:45] <SWPadnos> we should s/CVS/developement/g more or less
[20:46:06] <PCW> SWPadnos: I'll have to make the drawing (Ger2DXF) an dimension it, be a few mins
[20:46:14] <SWPadnos> ok, thanks
[20:52:34] <jepler> SWPadnos: fixed, thanks
[20:52:48] <SWPadnos> erre.
[20:52:50] <SWPadnos> ok
[20:53:03] <SWPadnos> saw me looking for your beagle info?
[20:53:28] <jepler> yeah
[20:53:29] <SWPadnos> oh - CVS
[21:01:34] <SWPadnos> pcw, you wouldn't happen to know if you have about a dozen 5i23 in stock, would you?
[21:02:26] <PCW> We should have at least 40 or 50
[21:02:59] <SWPadnos> ok, cool I think Lily said a smalle rnumber when I odered 1 last week, but she wasn't sure if there was another production run in the works
[21:03:17] <PCW> Yes we just did a new 50 batch