todo

来自「CNC 的开放码,EMC2 V2.2.8版」· 代码 · 共 422 行

next steps:


    pins & params use "-" vs "_" inconsistently


    write a little userspace helper, a "hostmot2 config wizard":

        tell it what anyio board(s) you have, and what daughter boards on what connectors

        it'll pick the firmware, and poop out a little hal file with well-named nets that make the daughter board work


    when reading IO Cookie & Config Name, if it fails read it many times
    to get some more data


    > Note: Double quotes in hm2_7i43 command took me some time to figure out,
    > as the config modparam single quotes were getting stripped by Bash. This
    > might be something to add to "man hostmot2".


    include .PIN files as docs

        JMK suggested auto-generating man pages from the PIN files...


    better sample configs

        ask cradek to commit his


    on driver unload, it should stop all the motors and "safe" the
    gpios....  The watchdog already sort of does this.  document this
    behavior


    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
            Remove in Jan 2009

            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
            Remove in Jan 2009




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




encoder:

    rawcounts is s32 - is that ok?  It might overflow on very long,
    very high-resolution axes, or on things like spindle encoders.


    there's at least one bug hiding:

        [ 5440.031253] hm2_5i20.0: initialized AnyIO board at 0000:01:04.0
        [ 5442.863016] hm2/hm2_5i20.0: encoder.01 dT <= 0, how can this be?
        [ 5442.863023] hm2/hm2_5i20.0: hm2->encoder.tsc_rollover_flag=1, e->tsc_num_rollovers=0
        [ 5442.863026] hm2/hm2_5i20.0:     cur = ( 1537, 1017 )
        [ 5442.863028] hm2/hm2_5i20.0:    prev = ( 1536, 64791 )
        [ 5442.864041] hm2/hm2_5i20.0: encoder.01 dT <= 0, how can this be?
        [ 5442.864047] hm2/hm2_5i20.0: hm2->encoder.tsc_rollover_flag=0, e->tsc_num_rollovers=0
        [ 5442.864050] hm2/hm2_5i20.0:     cur = ( 1537, 2035 )
        [ 5442.864051] hm2/hm2_5i20.0:    prev = ( 1536, 64791 )
        [ 5442.865042] hm2/hm2_5i20.0: encoder.01 dT <= 0, how can this be?
        [ 5442.865048] hm2/hm2_5i20.0: hm2->encoder.tsc_rollover_flag=0, e->tsc_num_rollovers=0
        [ 5442.865050] hm2/hm2_5i20.0:     cur = ( 1537, 3041 )
        [ 5442.865052] hm2/hm2_5i20.0:    prev = ( 1536, 64791 )
        [ 5442.866042] hm2/hm2_5i20.0: encoder.01 dT <= 0, how can this be?
        [ 5442.866049] hm2/hm2_5i20.0: hm2->encoder.tsc_rollover_flag=0, e->tsc_num_rollovers=0
        [ 5442.866051] hm2/hm2_5i20.0:     cur = ( 1537, 4047 )
        [ 5442.866052] hm2/hm2_5i20.0:    prev = ( 1536, 64791 )
        [ 5442.867043] hm2/hm2_5i20.0: encoder.01 dT <= 0, how can this be?
        [ 5442.867049] hm2/hm2_5i20.0: hm2->encoder.tsc_rollover_flag=0, e->tsc_num_rollovers=0
        [ 5442.867051] hm2/hm2_5i20.0:     cur = ( 1537, 5055 )
        [ 5442.867053] hm2/hm2_5i20.0:    prev = ( 1536, 64791 )
        [ 5442.868047] hm2/hm2_5i20.0: encoder.01 dT <= 0, how can this be?
        [ 5442.868055] hm2/hm2_5i20.0: hm2->encoder.tsc_rollover_flag=0, e->tsc_num_rollovers=0
        [ 5442.868057] hm2/hm2_5i20.0:     cur = ( 1535, 5697 )
        [ 5442.868059] hm2/hm2_5i20.0:    prev = ( 1536, 64791 )


    performance:

        my motor shaft tops out at 8K rpm, which is 133.33333 revs
        per second

        my highest-resolution encoder has 512 lines, so 2048
        transitions per revolution, so 275K transitions per second,
        or 1 transition every 3 or 4 us

        sampling at twice that would mean ~600 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 275K transitions/second, that should be max 275 counts
        per reading, which is *fine*




pwmgen:

    no known issues




ioport:

    no known issues




stepgen:

    stepgen overshoots with high maxaccel, but most of the time
    maxaccel is 0, isn't it?  so the trajectory planner gets to control
    acceleration?

    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 table output mode

    support velocity control?

    support smaller stepgens - most dont need 6 pins...

        config="stepgen="off,on:width=2"




watchdog:

    currently it's like this: if a watchdog exists, it will be
    initialized, but if pet_watchdog doesnt run, it'll bite and we wont
    know about it

    on watchdog bite, keep doing all reads (encoders, gpios, raw)?
    
        reading those things should still work, but what's the use?

        wd bites happen for three reasons i think: 
        
            epp cable unplugged,

            linux shutdown or crashed,

            user loadrt'ing hm2_pci by hand and not getting to addf & start within 1 second

        In no case does it help to keep reading the FPGA


    to keep halcmd-experimentation from tripping the watchdog right
    away, have the timeout default to 0, meaning no wd

    let the user set wd.timeout if they want

    dont start watchdog at insmod, start it at the first pet_watchdog
    (warn if it's 0 and suggest maybe 5x the servo thread period)




7i43:

    can't get it to work with the pci card parport...  NetMos 9805
    problem, try a card with another chipset

    test with the 400K board again

    needs to support multiple boards (i think this works)


5i20, 5i23, 4i65, 4i68:

    no known issues


5i22:

    test with the 1.5M version




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...

    HAL doesnt let you add or remove HAL objects after hal_ready().
    So the driver's set of HAL objects is determined at module load time,
    before anything shows up in HAL...  Bummer.  Chris Radek suggested
    that this might be possible to fix.

    The config of an hm2 board is a structured object:

        typedef struct {

            struct {
                bool enabled;
                bool index_enabled;
                bool index_mask_enabled;
            } hm2_encoder_config[];

            struct {
                bool enabled;
            } hm2_pwmgen_config[];

            struct {
                bool enabled;
                uint width;
            } hm2_stepgen_config[];

            char *firmware;

            bool enable_raw;

        } hm2_config_t;




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 optional tram support

        complete support for stepgen




wishlist:

    add DMA support for PLX9054


    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