Back
[00:03:59] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[01:15:40] <skunkworks> dad is in the hospital - heart attack
[01:15:58] <SWPadnos> ouch. I hope he's OK
[01:16:13] <SWPadnos> or gets that way soon :)
[01:16:21] <skunkworks> they did the baloon thing.. But they can't put a stint in because he is alergic to nickle
[01:16:27] <skunkworks> but so far so good
[01:16:43] <SWPadnos> allergic to Nickel - how strange
[01:16:55] <SWPadnos> thank goodness for balloons :)
[01:17:03] <skunkworks> found out when he broke his ankle and pinned it.
[01:17:15] <SWPadnos> ouch^2
[01:17:24] <cradek> that's gotta be a bad way to find out
[01:17:39] <cradek> he must have never worn white gold
[01:18:56] <skunkworks> yes - it wouldn't heal
[01:22:33] <jmkasunich> skunkworks: sorry to hear about your dad - hope he recovers soon
[01:22:39] <skunkworks> Thanks
[01:23:22] <skunkworks> looks like linuxcnc.org got fixed :)
[01:23:42] <SWPadnos> yeah, the data is back but we're not sure the hold is plugged
[01:23:44] <SWPadnos> hole
[01:26:06] <cradek> I wish I was cool enough to vandalize the websites of people who volunteer to write free software
[01:26:20] <SWPadnos> you need to be uber-cool to do that
[01:26:32] <SWPadnos> (actually, it's even cooler if you have the umlaut on the U)
[01:26:58] <skunkworks> bbl
[01:30:13] <cradek> what did it say anyway?
[01:31:40] <jmkasunich> "this site was defaced by an asshole who didn't have anything productive to do with his time"
[01:31:48] <SWPadnos> it said
[01:32:00] <SWPadnos> "HackedHackedHacked ..."
[01:32:12] <cradek> hahaha
[01:32:20] <cradek> jmk's is much better
[01:32:43] <cradek> wow, that's pretty creative
[01:32:53] <cradek> even spray-paint vandals do better than that
[01:50:48] <jmkasunich> wow, I have some very old mice
[01:52:35] <jmkasunich> no ICs at all - just four discrete transistors
[01:53:51] <cradek> how do you generate mouse protocol with four transistors?
[01:55:14] <cradek> or is it pre-pc?
[01:55:14] <SWPadnos> you connect them to a mouse adapter card which does the counting
[01:55:24] <SWPadnos> remember those add-in cards?
[01:55:39] <cradek> not in the pc world...?
[01:55:42] <skunkworks> no
[01:55:44] <SWPadnos> sure
[01:55:52] <skunkworks> way before my time
[01:55:58] <SWPadnos> Logitech, Microsoft, and others had them
[01:56:15] <cradek> I think my first mouse was a mousesystems and it plugged into a serial port
[01:56:24] <SWPadnos> yep, those were later :)
[01:56:37] <cradek> wish I still had it - it was cool
[01:56:48] <cradek> very low resolution for today though, I bet
[01:57:03] <cradek> I'm not sure if it had more than one "count" per stripe on the pad or not
[01:57:14] <SWPadnos> heh - yeah, one inch of travel would be more than even an EGA screen :)
[01:57:40] <cradek> I *do* have my EGA monitor (I repaired it a couple years ago)
[01:57:57] <SWPadnos> do you have anything that can drive it?
[01:58:16] <SWPadnos> I guess you could whip up a pong game on a PIC or AVR pretty easily :)
[01:58:20] <jmkasunich> these are logitec
[01:58:25] <jmkasunich> h
[01:59:18] <fenn> make a clock out of it!
[01:59:25] <cradek> sure, the EGA card in the AT
[02:00:16] <SWPadnos> ah, right - the bus mouse :)
[02:00:34] <SWPadnos> http://en.wikipedia.org/wiki/Bus_mouse
[02:03:02] <SWPadnos> http://cgi.ebay.com/Logitech-MouseMan-Deluxe-Bus-Model-PK32-Mouse-Kit_W0QQitemZ130197640219QQihZ003QQcategoryZ116300QQcmdZViewItem
[02:04:41] <jmkasunich> is there nothing that people won't stick on ebay?
[02:05:18] <SWPadnos> nope
[02:07:34] <cradek> I have a 3 button mouseman on my emc machine. With scrollwheel emulation on the middle button they're quite usable again
[02:09:08] <SWPadnos> hmmm - hold middle button and move to emulate a scrollwheel??
[02:10:01] <jmkasunich> I'm examining these with an eye to radical (bandsaw) surgery to use them as encoders
[02:10:41] <cradek> SWPadnos: yes
[02:30:24] <jmkasunich> damn - here I am wanting 5-40 screws again
[02:30:41] <jmkasunich> oh, I mean a 5-40 tap, I have the screws
[02:31:16] <SWPadnos> use 6-32 and twist harder ;)
[02:36:28] <jmkasunich> snap
[02:36:34] <jmkasunich> you owe me a 6-32 tap
[02:36:49] <SWPadnos> no, 6-32 screws :)
[02:37:18] <cradek> jmkasunich: I have a bunch of 5-40 LH, but not RH
[02:37:22] <jmkasunich> they don't fit thru the center of a bearing with a 1/8 bore
[02:37:26] <jmkasunich> cradek: thats funny
[02:37:34] <cradek> I have a shitload of 5-44 RH if you want some
[02:37:38] <cradek> and 6-40
[02:37:49] <jmkasunich> I have 6-36
[02:53:42] <dmwaters> {global notice} Good day all, I apologize for the netsplits, we had some maintenence due on a couple servers but it's over now. thank you for your patience, and thank you for using freenode!
[06:49:03] <skunkworks> dad is doing fine. A bit of a scare after they took the needle out of his leg.. his blood pressure dropped - but about 10 doctors showed up and fixed it :)
[06:50:03] <skunkworks> we will be running back up tomorrow. He is actually in rochester mn.. probably the best place to be when having medical problems :)
[06:50:14] <skunkworks> Going to bed.
[06:50:18] <skunkworks> night all
[08:18:00] <alex_joni> skunkworks: glad to hear he's ok
[14:21:10] <CIA-41> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/scope_disp.c: fix the time displayed when mousing over a trace
[14:24:41] <CIA-41> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: fix the time displayed when mousing over a trace
[14:24:41] <CIA-41> EMC: 03jepler 07v2_2_branch * 10emc2/src/hal/utils/scope_disp.c: fix the time displayed when mousing over a trace
[19:31:52] <maddash> CIA-41: hi
[19:32:06] <alex_joni> * alex_joni eats CIA-41
[19:32:07] <CIA-41> * CIA-41 tastes crunchy
[19:54:10] <fenn> 404
http://linuxcnc.org/Boardofdirectors/trackers.html (from sf feature request page)
[21:09:37] <SWPadnos> at least, we might get technical
[21:09:53] <seb_kuzminsky> right
[21:10:08] <SWPadnos> first, the hardware - the driver is supposed to support configs for any of the Mesa PCI boards
[21:10:16] <SWPadnos> assuming you use a compatible config
[21:10:42] <SWPadnos> in the model we have there are 4 kinds of users
[21:11:11] <SWPadnos> first, developers. these are the people who define new FPGA functions and write the HAL drivers for them
[21:11:27] <SWPadnos> hmmm - let me find one of the docs we came up with - one sec
[21:12:27] <SWPadnos> http://pastebin.ca/499631
[21:12:38] <seb_kuzminsky> thx
[21:12:44] <SWPadnos> sure
[21:13:13] <SWPadnos> the idea is that there may be generic functions you could incorporate into an FPGA (written by level 4 users in that doc)
[21:13:29] <SWPadnos> a level 3 user would choose the functions to put into an FPGA and where those functions might connect
[21:13:49] <SWPadnos> there's still more work to do for a given configuration - you have to decide which functions to enable/disable
[21:14:10] <SWPadnos> the number of possibilities is too large to allow for module load parameters - the load line would be too unweildy to write or read
[21:14:30] <SWPadnos> so there needs to be a way of having the FPGA tell the driver what functions are enabled
[21:14:35] <SWPadnos> that
[21:14:58] <SWPadnos> so a level 2 user (the machine integrator) can choose which functions to turn on
[21:15:35] <SWPadnos> the driver then reads the config (both what functions are available and which ones are enabled), and at load time it creates the appropriate HAL pins
[21:15:50] <SWPadnos> then of course a level 2 or level 1 user can change HAL connections, etc.
[21:16:05] <seb_kuzminsky> when you say "function" you mean a particular unit of functionality on the fpga, such as a pwmgen or encoder counter?
[21:16:09] <SWPadnos> yes
[21:16:36] <seb_kuzminsky> the basic functions seem to be stepgen, pwmgen, encoder, and digital I/O, is that right?
[21:16:37] <SWPadnos> so for example I might stick a stepgen and a PWMgen on the same I/O pins, assuming that I'll use those two pins for a motor, but not knowing which kind at FGPA compile time
[21:16:41] <SWPadnos> so far
[21:16:52] <seb_kuzminsky> oh and dac
[21:16:57] <seb_kuzminsky> which is basically pwm, right?
[21:17:09] <SWPadnos> I have plans for an absolute encoder reader, I also have an analog I/O card that could be used with this scheme
[21:17:20] <SWPadnos> there's also serial and SPI
[21:17:26] <seb_kuzminsky> right
[21:17:35] <SWPadnos> and 32-bit digital I/O cards (the ones peteW is designing)
[21:17:45] <seb_kuzminsky> have you looked at Mesa's HostMot firmware? this sounds similar
[21:17:48] <SWPadnos> yes
[21:18:03] <SWPadnos> you'll still have the problem of deciding which things to enable
[21:18:06] <SWPadnos> at driver load time
[21:18:09] <seb_kuzminsky> peteW is Peter C Wallace at mesa?
[21:18:11] <SWPadnos> yes
[21:18:23] <seb_kuzminsky> i've worked with his 7i43 with hostmot2 firmware
[21:18:44] <SWPadnos> yep. I have several 5i20 and 5i22 cards, and have seen (nad modified) hostmot2
[21:18:50] <SWPadnos> s/nad/and/
[21:19:02] <seb_kuzminsky> there's a blob at the beginning of the firmware's address space that enumerates the functions available in the fpga and the pins available
[21:19:33] <SWPadnos> consider this: I/O is always available, even if there's some other function that could use those pins
[21:19:43] <seb_kuzminsky> in my 7i43 driver i have modparams to disable function instances at module load time, sort of like your 'v' and 'w' blocks maybe
[21:19:56] <SWPadnos> the driver only has one opportunity to create HAL pins, so which do you create: I/O or PWM (for example)?
[21:20:29] <seb_kuzminsky> at module load time the user may disable function instances; pins belonging to a disabled function instance become gpios
[21:20:34] <seb_kuzminsky> (is how i did it)
[21:20:51] <SWPadnos> that's OK with a small set of functions, but gets difficult with (a) larger pin-count FPGAs and (b) configs that may have several possible functions on a single physical pin
[21:21:13] <SWPadnos> can you enable PWMs 1,2 and 6 only?
[21:21:19] <SWPadnos> ot just "3PWM"?
[21:21:27] <seb_kuzminsky> i agree that scheme wont work if there are multiple functions available for a particular pin
[21:21:28] <SWPadnos> s/ot/or/
[21:21:31] <SWPadnos> right
[21:21:38] <seb_kuzminsky> my scheme enables the first N instances of the function
[21:21:55] <SWPadnos> right - bad when you want 3 PWM and 3 stepgen on your 6 "motor output" pairs :)
[21:22:06] <seb_kuzminsky> yes, i see
[21:22:24] <SWPadnos> this kind of stalled because bot h JMK and I dropped it for whatever reason
[21:22:31] <seb_kuzminsky> the hm2 firmware allows each pin to be gpio or *one* other function
[21:22:46] <seb_kuzminsky> there's no way for the firmware to express that a pin can be pwm or stepgen or gpio
[21:22:48] <SWPadnos> yes, there's a mux assumed for the 5i2x firmware(s)
[21:22:54] <seb_kuzminsky> it's "gpio and what other function"
[21:23:06] <SWPadnos> you can with the framework set out here
[21:23:11] <seb_kuzminsky> right
[21:23:38] <SWPadnos> it may be possible to have a single driver work with both the PCI and parallel-port connected units
[21:23:41] <seb_kuzminsky> maybe a bitmap of what function instances to enable would be better...
[21:23:51] <SWPadnos> that would take some thought, but I think it's possible
[21:24:02] <SWPadnos> yes, but bitmaps on the command line aren't pretty
[21:24:21] <seb_kuzminsky> hehe, maybe a list of integers?
[21:24:38] <seb_kuzminsky> loadrt hal_driver pwmgens=1,2,6 stepgens=0,3,4,5
[21:25:03] <SWPadnos> loadrt m5i2x pwmgens=0x3A stepgens=0x05 encoders=0x22 .......
[21:25:08] <SWPadnos> ok, that could work
[21:25:09] <seb_kuzminsky> yep
[21:25:16] <SWPadnos> more like stepgens=0,1,1,1,0,0,0,1
[21:25:27] <seb_kuzminsky> sure
[21:25:34] <SWPadnos> but you have to be sure that you don't select things that are overlaid together
[21:25:46] <seb_kuzminsky> yes, that should cause the load to fail
[21:25:50] <SWPadnos> and reporting that kind of error could be a very confusing experience ;)
[21:26:06] <SWPadnos> there are also some philosophical questions
[21:26:11] <seb_kuzminsky> error: pwmgen 0 and stepgen 0 trying to use the same I/O pin!
[21:26:50] <SWPadnos> if I have a 5i22 and I assign alternate functions to all the pins on the first two headers, do I get digital I/Os 0-47 or 48-95?
[21:26:57] <SWPadnos> sure
[21:27:10] <SWPadnos> (on the second two headers)
[21:27:21] <seb_kuzminsky> i chose to give the gpio pins in hal number that correspond to the I/O header pin numbers in the manual
[21:27:33] <seb_kuzminsky> s/number/numbers/
[21:27:42] <seb_kuzminsky> seems least confusing
[21:27:46] <SWPadnos> yeah, those should probably be m5i2x.0.dio.P2.41
[21:27:58] <seb_kuzminsky> ah with the port number in the name, nice
[21:28:41] <jepler> we've seen repeatedly that users either don't find or can't interpret the listings shown in the documentation for 5i20 or pluto that purport to explain the relationship between HAL items and physical pins
[21:29:00] <seb_kuzminsky> <rolls eyes>
[21:29:29] <SWPadnos> phone
[21:29:38] <seb_kuzminsky> in my driver, when it loads successfully, it prints out a pinout table, saying what pin has what function
[21:29:48] <jepler> prints -- in dmesg?
[21:29:56] <seb_kuzminsky> yes
[21:34:12] <seb_kuzminsky> i've been thinking of how to share code between the 7i43 driver and possible 5i2x drivers...
[21:34:48] <seb_kuzminsky> i think a low-level i/o driver to handle epp or the different pci interfaces, then a generic firmware driver that talks to the firmware via the low-level I/o drivers
[21:35:06] <seb_kuzminsky> then another system to manage firmware images...
[21:35:23] <seb_kuzminsky> so first you'd load the low-level i/o drivers for the card(s) you have
[21:35:32] <seb_kuzminsky> then you'd load the firmware images you wanted to use
[21:36:06] <seb_kuzminsky> then you'd load a generic driver that would map firmwares to boards, cause the low-level drivers to send the specified firmware to their boards, and export the resulting stuff to hal
[21:36:43] <seb_kuzminsky> seems kind of big and messy, but reusing the code that talks to the firmware would probably make it worth it
[21:37:22] <seb_kuzminsky> it's a bit tricky, because the pci cards can be detected without sending them firmware, but the epp board can not
[21:37:46] <seb_kuzminsky> best we can do is find the epp port, and talk to the cpld that handles pre-firmware epp communication on the 7i43
[21:52:12] <SWPadnos> I'm not too worried about having multiple drivers for the various buses, but I think I'd like to reduce source-code duplication as much as possible
[21:52:29] <SWPadnos> so you'd load one driver for the 7i43 and maybe another for the PCI cards
[21:52:44] <SWPadnos> (or even have one driver that includes both bus access methods, if it's reasonable to do so)
[21:53:09] <fenn> * fenn votes for one driver per physical device type
[21:53:43] <fenn> where physical device is a thing you plug in
[21:53:44] <seb_kuzminsky> i see, and have the epp driver and the pci driver both "statically link" the code that talks to the firmware into a single module
[21:54:44] <seb_kuzminsky> fenn: one driver per device type is appealing...
[21:55:45] <seb_kuzminsky> but these things have very flexible firmware, and you might want to drive two different physical devices of the same type (eg two 5i20's) but with different firmware on each
[21:56:29] <seb_kuzminsky> so the choices are to link all firmwares into the one main driver, or to put each firmware in a separate module to be loaded before the main driver
[21:56:43] <seb_kuzminsky> and use modparams to pick firmwares for each physical device
[21:57:15] <seb_kuzminsky> it's further complicated because at least the 7i43 comes in two versions, identical except for different size FPGAs (200K gate & 400K gate)
[21:57:40] <seb_kuzminsky> so each firmware comes in a 400K version and a 200K version, and the driver has to pick the right one once it's probed the 7i43s
[21:58:00] <fenn> i think the driver should be smart enough to pick different firmwares for the same device type
[21:58:14] <seb_kuzminsky> currently I'm linking both flavors into the main driver, but it feels kind of hokey to link in all possible firmwares, wasteful
[21:58:46] <fenn> what do you mean 'link in'?
[21:59:51] <seb_kuzminsky> the firmware .bit file is turned into a C file with a big char array holding the firmware, this c file is compiled into the driver
[22:00:35] <seb_kuzminsky> oops, i meant the firmware goes in a char array in a header file, which is #included in the driver .c file (.comp, really)
[22:01:06] <fenn> i see
[22:01:07] <seb_kuzminsky> so if there are three different firmwares, times two fpga flavors, that's a lot of junk to link in, in precious non-swappable kernel memory
[22:01:30] <fenn> well there are lots of ways to deal with that
[22:01:33] <seb_kuzminsky> maybe not a big deal? i dont know, i just know it feels wasteful
[22:02:05] <seb_kuzminsky> the first thing that comes to mind is to put each firmware in its own module, and just load the firmware modules you're planning to use
[22:02:30] <seb_kuzminsky> it's a bit tricky because i think there needs to be some infrastructure to register firmware blobs, so the actual driver knows where to find them later
[22:03:00] <seb_kuzminsky> so now you're loading a firmware infrastructure module, then one or more firmware modules, then the driver module
[22:03:38] <seb_kuzminsky> a modparam to the main driver module tells it what firmware blobs to get (via the firmare management infrastructure) and send to which physical devices
[22:03:59] <seb_kuzminsky> seems big and hairy, but everything else i've thought of seems worse
[22:04:54] <seb_kuzminsky> maybe compile all the firmware into the main driver until the users complain that they're running out of ram :-)
[22:10:19] <SWPadnos> the idea with the new driver architecture is that you could drive multiple cards with different configurations "automagically"
[22:10:40] <SWPadnos> there is specifically a separate FPGA load step though (before the driver is loaded)
[22:10:50] <seb_kuzminsky> i see, yes that would take care of it
[22:10:51] <SWPadnos> the FPGA bitfile is not intended to be part of the driver
[22:11:25] <seb_kuzminsky> that's nice, so the firmware is *never* in kernel memory
[22:11:35] <SWPadnos> you always know where the firmware blobs are with the PCI cards, because you can use the pci_find_device function
[22:11:37] <SWPadnos> right
[22:12:05] <SWPadnos> there would need to be something different for a parport device, but that amount of command-line config is pretty easy
[22:12:07] <seb_kuzminsky> that would work... and it's probably cleaner than all that kernel code i've been contemplating
[22:12:22] <SWPadnos> something like loadrt m5i2x parport=378,278 pci=1
[22:12:33] <SWPadnos> or pci=0 if you don't want to use PCI cards ...
[22:12:49] <seb_kuzminsky> the pci modparam shouldnt be needed, since the driver can find them automatically
[22:13:10] <seb_kuzminsky> unless you wanted to disable a card on your pci bus, but that seems rare
[22:13:13] <SWPadnos> it would just allow you to use or not use PCI cards, if you choose (but it probably is unnecessary)
[22:13:16] <SWPadnos> yep
[22:13:37] <seb_kuzminsky> food for thought, thanks :-)
[22:13:52] <SWPadnos> the way the I/O is supposed to work is with "standard" structs for each device type
[22:14:07] <SWPadnos> so an encoder input has a few registers that are well-defined
[22:14:33] <SWPadnos> if you have 10 encoder inputs, that would essentially be an array of those structs in the PCI memory space
[22:14:48] <seb_kuzminsky> right, that's very similar to hm2
[22:15:19] <SWPadnos> the parport driver can load the data into a similar memory map, but the data pointer to the encoder "interpreter" function would just point to a memory struct instead of a PCI struct
[22:15:43] <SWPadnos> (that should probably be done with the PCI cards as well anyway - using a DMA burst to read and write the data)
[22:16:03] <SWPadnos> so the driver internals just work with memory pointers and the bus drivers move the data around
[22:16:25] <seb_kuzminsky> currently the 7i43 driver loads the MD table into ram, then parses it and turns it into things it can export to HAL
[22:16:41] <SWPadnos> yep, makes sense (much like what we did with the USC driver)
[22:16:55] <SWPadnos> copy registers to RAM, using a map / region list of addresses to transfer
[22:17:17] <seb_kuzminsky> the EPP i/o is slow and a bit funny though...
[22:17:42] <SWPadnos> yes, but the USC hardware helps out - it increments the address register automatically on each read/write
[22:17:51] <SWPadnos> so you set up the addr then do a bunch of reads
[22:17:53] <seb_kuzminsky> the 7i43 hm2 firmware has a 16-bit address space, with 32-bit registers
[22:18:01] <SWPadnos> should be similar with the 7i43
[22:18:03] <seb_kuzminsky> yes, the 7i43 does address autoincrement too
[22:18:43] <SWPadnos> so it ends up that any time you want to transfer from two regions that are closer than 3 bytes from each other, you might as well just read a contiguous block with the extra data
[22:18:53] <seb_kuzminsky> so there that wont work so well if the user disables every other instance of the function!
[22:18:53] <SWPadnos> instead of doing an extra addr setup
[22:19:09] <SWPadnos> true, it does represent some extra overhead
[22:19:15] <seb_kuzminsky> s/so there//
[22:19:17] <SWPadnos> more noticeable on the parport ;)
[22:19:30] <SWPadnos> (though that depends a lot on the PCI chipset)
[22:19:52] <seb_kuzminsky> the 7i43 does something called "address translation", where you can map physical addresses to logical addresses like a page table sort of
[22:20:13] <SWPadnos> cool
[22:20:15] <seb_kuzminsky> once the user has set up the functions they want enabled, you could map all their registers to be contiguous, then do a single block read
[22:20:26] <SWPadnos> yep, that would be a good thing
[22:20:36] <seb_kuzminsky> pcw says he's planning something similar for the pci cards, to help with dma
[22:21:45] <seb_kuzminsky> i was thinking of having a unified in-kernel representation of the desired device state, and handing that to the low-level driver to send out in whatever way is more efficient/appropriate
[22:22:02] <seb_kuzminsky> without worrying too much yet about optimizing the in-kernel state layout
[22:22:31] <SWPadnos> yep
[22:22:53] <SWPadnos> incidentally, a fair amount of work has been completed on this new driver scheme
[22:23:04] <seb_kuzminsky> you and jmkasunich have been working on the mesa pci fpga cards?
[22:23:08] <SWPadnos> yes
[22:23:16] <seb_kuzminsky> it's in src/hal/drivers/mesa_5i2x?
[22:23:16] <SWPadnos> well, working may be too strong a word recently ;)
[22:23:19] <SWPadnos> yes
[22:23:34] <seb_kuzminsky> the m5i20 stuff is being obsoleted by the mesa_5i2x work?
[22:23:41] <SWPadnos> once it's done, yes
[22:23:55] <seb_kuzminsky> hmmm....
[22:23:58] <SWPadnos> the loader is confirmed to work with 5i20 and 5i22 boards
[22:24:18] <SWPadnos> I think the library or utility to move bitfile segments around is done
[22:24:23] <SWPadnos> some of the FPGA functions are done
[22:24:44] <SWPadnos> I'd have to look (fora while ;) ) to really know what still needs doing though
[22:24:48] <seb_kuzminsky> what's the difference between your firmware and hm2?
[22:25:06] <seb_kuzminsky> there's the config block where the type 3 user can disable function instances
[22:25:28] <SWPadnos> the stepgens are different I think, the config block idea, muxes on the GPIOs
[22:25:36] <SWPadnos> some others I don't remember
[22:25:50] <SWPadnos> I think Pete W added some features to the hostmot code as a result of us talking about them here :)
[22:26:07] <seb_kuzminsky> hehe, the joy of open source
[22:26:11] <SWPadnos> (like the ability to drive a direction pin with a function output)
[22:26:13] <SWPadnos> yep
[22:27:29] <seb_kuzminsky> hm2 has 1-of-2 pin muxes, which probably makes sense for the ratio of fpga gates to io pins on the 7i43
[22:27:36] <seb_kuzminsky> maybe it's different on the 5i2x boards
[22:28:09] <SWPadnos> the 5i22 has a 1.5Mgate chip
[22:28:13] <seb_kuzminsky> hehe
[22:28:18] <SWPadnos> or a 1.0M I think
[22:28:20] <seb_kuzminsky> so you could put another linux system on it :-)
[22:28:23] <SWPadnos> just about
[22:28:42] <SWPadnos> it has 33% more pins and 650% more gates than a 5i20 :)
[22:28:50] <seb_kuzminsky> yum
[22:28:55] <SWPadnos> indeed
[22:29:11] <SWPadnos> it's also a faster chip - the same family as the 7i43
[22:29:16] <SWPadnos> spartan 3
[22:29:17] <seb_kuzminsky> spartan 3
[22:29:18] <seb_kuzminsky> right
[22:29:27] <SWPadnos> vs. spartan 2 on the 5i20
[22:30:06] <seb_kuzminsky> the 5i22 also has a different & better pci interface, right? the 5i20 isnt dma capable iirc
[22:33:11] <seb_kuzminsky> i gotta go get the kids from preschool, thanks for your input and for cluing me in to your work with the 5i2x boards!
[22:33:26] <SWPadnos> ok, time for me to run too
[23:22:35] <skunkworks> Dad is doing well. Good spirits
[23:22:49] <skunkworks> be going home saturday
[23:26:33] <alex_joni> skunkworks: glad to hear that
[23:26:38] <alex_joni> send him all my best wishes
[23:27:44] <skunkworks> Thanks - I will :)
[23:28:05] <alex_joni> ok, I'm off to bed
[23:38:45] <jmkasunich> reading back - don't have time to get into a big conversation, but one thing set off alarm bells
[23:38:59] <jmkasunich> the "use the same code for EPP and PCI" goal
[23:39:06] <jmkasunich> I don't like it at all
[23:39:26] <jmkasunich> PCI is a pipe, and EPP is a teeny tiny drinking straw with a kink in it
[23:39:41] <jmkasunich> the difference is so huge that it drives different coding styles
[23:40:19] <jmkasunich> I have absolutely no interest in EPP connected devices whatsoever, and won't be happy with anything that limits bandwidth in attempt to retain EPP compatability
[23:55:25] <jmkasunich> on the other hand, my work on 5i2x drivers stalled badly in May/June, and I haven't restarted yet, so anything is better than nothing
[23:56:02] <jmkasunich> I have some personal projects in mind that will involve custom VHDL, not just a mix of mesa supplied functions, and I was trying to build a framework for that
[23:56:11] <jmkasunich> two things made me stall:
[23:56:44] <jmkasunich> 1) I think my attempt to service everybody from Aunt Tillie (easy config) to me (fully custom VHDL) was blowing brain fuses
[23:56:59] <jmkasunich> 2) My divorce started about then :-(
[23:57:33] <jmkasunich> item 2 is finished now, and life is coming back up to speed
[23:57:41] <jmkasunich> but I have months of other projects on my plate
[23:58:33] <jmkasunich> item 1 is still blowing brain fuses, and at some point a may just say screw Aunt Tillie - I'll do what I want, and not inflict it on other EMC people - let it live outside the project