next steps: stepgen overshoots with high maxaccel velocity_cmd should be renamed to velocity_fb probably cleanup look at pluto_step include .PIN files as docs JMK suggested auto-generating man pages from the PIN files... better sample configs, maybe move my test scripts there, document better on driver unload, it should stop all the motors and "safe" the gpios.... The watchdog already sort of does this. document this behavior add support for the 5i22 next It's starting to feel like it's ready for some kind of module abstraction... To standardize the semantics and make it easier to think about. Pull out the common code. pins are special module drivers are expected to export the following functions: parse_md(): deal with the MD & modparam config info, make HAL representation, allocate memory for registers, request TRAM entries write(): check if FPGA registers need to be written with new information from HAL (or from within the driver), and if so write them force_write(): write the FPGA registers with current values process_initial_tram_read(): TRAM registers have first value, any data-dependent driver initialization should happen now prepare_initial_tram_write(): set TRAM register values to initialize the FPGA prepare_tram_write(): set TRAM registers as appropriate process_tram_read(): handle new values in TRAM registers debug_print(): show internal state clean the tree: Is the driver stable enough for this now? The one remaining invasive change I might want to do is the anyio layer between the firmware drivers like hostmot2 and the llio drivers (see Wishlist at bottom). Here's what's in our trees currently: 2.2: driver: hal_m5i20 boards supported: 5i20 firmware source: eeprom or userspace utility run before driver load firmware notes: old hostmot, various flavors other notes: widely used driver: hal_5i2x boards supported: 5i20; 5i22 support planned? firmware source: eeprom or userspace firmware notes: not sure, a fork off the old hostmot code? other notes: development stalled? driver: hostmot2 boards supported: 5i20, 7i43 firmware source: request_firmware()/udev firmware notes: hostmot2, various flavors, supported by Mesa other notes: actively developed, all AnyIO boards will be supported by end of summer driver: m7i43_hm2 DEPRECATED! boards supported: 7i43 firmware source: compiled into driver, sent to board at insmod time firmware notes: hostmot2, various flavors, supported by Mesa other notes: in maintenance mode, new development continued in hostmot2 in TRUNK (see below) TRUNK: driver: hal_m5i20 boards supported: 5i20 firmware source: eeprom or userspace utility run before driver load firmware notes: old hostmot, various flavors other notes: widely used driver: hal_5i2x boards supported: 5i20; 5i22 support planned? firmware source: eeprom or userspace firmware notes: not sure, a fork off the old hostmot code? other notes: development stalled? driver: hostmot2 boards supported: 5i20, 7i43 firmware source: request_firmware()/udev firmware notes: hostmot2, various flavors, supported by Mesa other notes: actively developed, all AnyIO boards will be supported by end of summer driver: mesa7i43-gpio DEPRECATED! boards supported: 7i43 firmware source: compiled into driver, sent to board at insmod time firmware notes: 48 gpio other notes: development ended driver: m7i43_hm2 DEPRECATED! boards supported: 7i43 firmware source: compiled into driver, sent to board at insmod time firmware notes: hostmot2, various flavors, supported by Mesa other notes: in maintenance mode, new development continued in hostmot2 in TRUNK (see below) translation ram (tram): just do it then do dma need to deal with the "strobe" bit currently the driver takes advantage of the fact that the module instances are contiguous in hm2 register space. Things'll have to change to support non-contiguous access. Could make a smart "allocate a register buffer" function smart: have it allocate space for each request contiguously in a larger buffer and set the TRAM encoders: use shielded encoder wires! performance: my motor shaft is spinning at 8K rpm, which is 133.33333 revs per second The encoder has 256 lines, so 1024 transitions per revolution, so 136533 transitions per second sampling at twice that would mean ~300 Ksamples/sec with the "quad filter" set to 3 clocks, the low-level input needs about 1 Msample/sec. with the "quad filter" set to 15 clocks, the low-level input needs about 5 Msample/sec. it's actually running at 50 MHz, so that shouldnt be a problem... The firmware is storing the quadrature count in a 16-bit register, which I'm reading about every ms (1 KHz) at 140K transitions/second, that should be max 140 counts per reading, which is *fine* How is encoder.XX.velocity computed? missing stuff: expose filter rate to HAL (cooked prolly) fancy velocity computation index mask support pins: velocity optional: a, b, index (available in the control register, which is getting read via fake-TRAM each cycle) parameters: max-index-vel (optional) velocity-resolution (optional) functions: CDI just has a read() pwmgen: feature complete! no known bugs! ioport: stepgen: setting .scale to 1600 (1600 steps/rev) and then commanding position to 1600 revs causes chaos, it runs in the wrong direction, some overflow bug not handled there... if a stepgen is stepping, and you set its .enable to 0 it stops instantly (which is good). But if you then set its .enable to 1, it resumes at its previous velocity (which is bad). test different steps-pre-rev on different stepgen instances support other stepping modes support velocity control? support smaller stepgens - most dont need 6 pins... config="stepgen="off,on:width=2" watchdog: 7i43: can't get it to work with the pci card parport... test with the 400K board again needs to support multiple boards 5i20: turn hm2_5i20 driver into a generic PCI driver: hm2_anyio_pci how to configure the firmware? Currently the llios take a "config" modparam (one for each board), which they pass to hm2_register(). hm2_register() does a bunch of gross string parsing... issues with the 2006-02-06 firmware: svst4_4: don't know what to do with this MD (LEDs?): m7i43_hm2: Module Descriptor 6 at 0x0488: m7i43_hm2: General Function Tag: 128 ((unknown-gtag-128)) m7i43_hm2: Version: 0 m7i43_hm2: Clock Tag: 1 m7i43_hm2: Instances: 1 m7i43_hm2: Base Address: 0x0200 m7i43_hm2: -- Num Registers: 1 m7i43_hm2: Register Stride: 0x00000100 m7i43_hm2: -- Instance Stride: 0x00000004 m7i43_hm2: -- Multiple Registers: 0x00000000 planned milestones: 1.0 add support for all other PCI cards IOPort connector names for the still-unsupported cards: 4I68: P1,P2,P4 5I22: P2,P3,P4,P5 5I23: P2,P3,P4 add optional tram support add DMA support for PCI cards with TRAM & the 7i43 llios should support multiple boards each complete support for encoder complete support for pwmgen complete support for stepgen complete support for gpios complete support for watchdog wishlist: add an anyio layer in the kernel similar to the parport layer 1. load anyio_manager 2. load low-level board drivers: anyio_{7i43,5i20|pci,etc} 3. llios find their boards & registers with the anyio layer 4. anyio layer fetches firmware & programs the board 6. load high-level firmware driver 7. it connects to anyio_manager and allocates the boards it wants 8. hostmot2 makes HAL objects for each board 9. hostmot calls hal_ready multiple HLs is a non-issue if each HL can recognize "this is my firmware, I'll use this board" vs. "oops, I dunno what this is, skip it" abstract the EPP code into a proper EMC2 (or RTAI) parport driver abstract the stepgen code into an EMC2 library