#emc-devel | Logs for 2007-08-26

[00:39:42] <jepler> SWPadnos: I love when I can tell someone flat out he's wrong, and everyone is happy about it
[00:39:57] <jepler> it doesn't happen often
[00:40:03] <SWPadnos> heh
[00:40:23] <SWPadnos> the trick is to not be wrong when you do it
[00:40:26] <SWPadnos> s/the/one/
[00:40:45] <SWPadnos> wrongly telling people they're wrong often fails miserably
[00:47:05] <SWPadnos> out of curiosity, does emc2-dev require a specific version of gcc, or is it >= some rev?
[00:52:20] <SWPadnos> ok - it looks to me that it just depends on g++. I wonder if it would casuse a problem if g++ were updated between installing emc2 and emc2-dev, since the compiler would be different for new .comps
[00:52:57] <cradek> vermagic: 2.6.15-28-386 preempt 486 gcc-4.0
[00:53:10] <cradek> yes the compiler version has to match for modules to insert
[00:56:17] <SWPadnos> ok - that version number isn't too descriptive though, so a bugfix update might not change that signature
[00:58:37] <cradek> that's right, it probably wouldn't
[00:59:00] <cradek> I wasn't sure what you were asking.
[00:59:34] <SWPadnos> ah - just related to whether it will continue to be safe to install emc2-dev to develop new comps
[00:59:49] <cradek> yes I bet so.
[01:08:35] <jepler> [25290.862926] hal_parport: Unknown symbol __divdi3
[01:08:42] <jepler> huh here's a new one on me
[01:08:49] <jepler> apparently you can't do division of long longs in a module
[01:09:39] <SWPadnos> I bet you can on x64 ;)
[01:09:50] <jepler> grngrng
[01:10:38] <jepler> Computing
[01:10:38] <jepler> deltat = (end_clocks - start_clocks) * 1000000 / cpu_khz:
[01:10:38] <jepler> gives the duration measured in nanoseconds
[01:10:48] <jepler> ^^ this advice in the rtapi_get_clocks manpage is wrong
[01:10:50] <jepler> (I wrote it)
[01:11:13] <jepler> since the division doesn't work
[01:12:10] <SWPadnos> are both deltat and cpu_khz long long?
[01:12:45] <jepler> if the difference is not a long long then the multiplication is wrong (done as int or long and overflows)
[01:13:02] <jepler> if the difference is a long long the multiplication is ok but the division by cpu_khz doesn't work (gives insmod error)
[01:13:15] <SWPadnos> I'd think the clocks vars would be long long though
[01:13:45] <jepler> in my code I was actually doing something slightly different than what is shown there
[01:13:50] <SWPadnos> ok
[01:16:27] <SWPadnos> what range of times are you trying to measure?
[01:16:52] <SWPadnos> (ie, do the *_clocks vars need to be 64-bit?)
[01:19:47] <SWPadnos> if the max time interval is <4 seconds (2^32), you can use a precomputed scale factor to get nanoseconds (with some reasonable precision)
[01:21:19] <jepler> I am trying to busy-wait a length of time given in ns: deadline = tsc_from_earlier + ns2clocks(delay); while(rtapi_get_clocks() < deadline) {}
[01:21:58] <SWPadnos> ok - this method would only require a multiplication and shift (or a union)
[01:22:21] <jepler> delay is a u32 and sensical values of it will typically be small (smaller than a BASE_PERIOD)
[01:22:34] <SWPadnos> you basically use a 32-bit factor as the fraction of a nanosecond per clock. multiply delta by that and the high 32-bit word is the answer in annoseconds
[01:22:52] <SWPadnos> nanoseconds, not yearly seconds ;)
[01:23:26] <SWPadnos> actually, the scale factor would have to be a long long to account for sub-GHz clocks
[01:24:04] <SWPadnos> scale_factor = (unsigned long long)(1e9 * 2^32 / cpu_hz)
[01:25:03] <SWPadnos> deltat = (unsigned int) (((end_time-start_time)*scale_factor) >> 32)
[01:26:16] <SWPadnos> it's the DDS step generation algorithm all over again :)
[01:27:16] <jepler> * jepler double checks that the first line of his hal file is "loadusr -w sync"
[01:27:35] <jepler> I already hard locked twice
[01:27:41] <jepler> busy waits are so hard to write
[01:27:42] <SWPadnos> heh
[01:28:02] <SWPadnos> you should put an escape counter in there, at least for testing
[01:30:38] <jepler> ... 3 times
[01:33:24] <jepler> /home/jepler/emc2.cvs/src/hal/drivers/hal_parport.c:228: warning: left shift count >= width of type
[01:33:29] <jepler> perhaps if I'd read the warnings
[01:33:32] <jepler> it might tell me something
[01:34:07] <SWPadnos> hmmm
[01:34:44] <SWPadnos> deltat = (unsigned int) ((unsigned long long)(((end_time-start_time)*scale_factor) >> 32)) ?
[01:34:59] <jepler> (1ll << 32) instead of (1 << 32)
[01:35:02] <SWPadnos> deltat = (unsigned int) ((unsigned long long)(((end_time-start_time)*scale_factor)) >> 32)
[01:35:04] <SWPadnos> heh
[01:35:06] <SWPadnos> oh, that
[01:35:24] <SWPadnos> I should read the pasted warnings better - left shift != right shift
[01:56:56] <jepler> oh duh
[01:57:11] <SWPadnos> ?
[01:57:11] <jepler> I had the math right long ago, but I was using rtapi_get_clocks() in one place and rtapi_get_time() in another
[01:57:49] <SWPadnos> err - oops
[02:13:26] <jepler> whee
[02:13:38] <jepler> * jepler is stepping at 20kHz with BASE_PERIOD 50000
[02:13:48] <SWPadnos> kewl
[02:13:58] <jepler> with guaranteed 4us step pulse length, in this case
[02:16:22] <SWPadnos> are you doing a possible step output at the beginning of the thread then a reset at the end, with other functions running in between?
[02:16:36] <jepler> this is just a simple .hal test setup
[02:16:43] <jepler> but in reality that is the ideal way to do it
[02:16:54] <SWPadnos> that's why I asked ;)
[02:16:55] <jepler> then you burn fewer cycles to be sure you got the step length you needed
[02:17:33] <SWPadnos> I'm sure most CPUs can do all or most of the fast thread processing in a few microseconds
[02:17:54] <SWPadnos> it's the separation of step generation and output that gets you
[02:19:22] <jepler> I don't follow you..
[02:20:20] <jepler> if you mean that each hardware driver has to support a "reset" function to permit this kind of step rate doubling, yes that's true
[02:20:44] <SWPadnos> the fact that this component has to be written specifically for e.g. the parport - you can't necessarily split the decision making from the I/O operations via HAL
[02:20:45] <jepler> but in reality there is approximately 1 type of output device for software generated step waveforms
[02:20:49] <SWPadnos> right - you need to add functions
[02:21:04] <SWPadnos> 8255 cards are different
[02:21:44] <jepler> here's my hal file: http://emergent.unpy.net/index.cgi-files/sandbox/testreset.hal
[02:21:48] <SWPadnos> the Mesa could be used (though that won't be desirable soon)
[02:21:47] <jepler> as you can see, stepgen and parport remain separate
[02:22:28] <SWPadnos> right - you've added the reset function
[02:23:20] <SWPadnos> so write captures the clocks value, then reset waits until it's safe to turn it off?
[02:23:28] <jepler> yes
[02:24:21] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/double-step-rate.patch
[02:24:32] <SWPadnos> does the reset mask cover the other I/Os on the port, or just the data pins?
[02:24:46] <jepler> right now, just pins 2..8
[02:25:09] <SWPadnos> that's a very reasonable first step. well done
[02:25:56] <cradek> nice. I remember you talking about this but didn't know you were serious about doing it.
[02:26:09] <jepler> turns out it's not much code
[02:26:35] <cradek> now you don't pluto-step for your router?
[02:27:17] <jepler> don't .. need ? want ?
[02:27:55] <cradek> umm
[02:27:59] <cradek> whatever
[02:28:22] <jepler> the top step rate I need might be between 35kHz and 40kHz if I want to use 8x microstepping
[02:28:28] <jepler> pluto is one solution for that, this would be too
[02:28:35] <jepler> (and using 4x or 2x stepping would be a third)
[02:28:37] <jepler> I like having options
[02:29:55] <jepler> as I was telling you privately earlier, the xylotex seems to require an input high voltage that is outside the pluto's output voltage spec (2.9V) so I am looking for other options
[02:30:43] <jepler> using pluto-step still would be what I'd like best
[03:27:04] <fenn> i just read all that like 5 times, and while i think i understand what's going on, i dont see why it wasn't already written like that
[03:49:56] <fenn> and why if(port->reset_time > period/4) port->reset_time = period/4; (why not just set it every time)
[03:53:43] <fenn> ...and couldnt you get 4x the update rate if you had a "hard-wired" write function instead of waiting for parport to get around to it?
[03:55:19] <fenn> in addition to the "hard wired" reset function
[03:55:59] <SWPadnos> I think period/4 is a guess at something that would be reasonably unlikely to screw things up if you have high latency
[03:56:22] <fenn> i mean you could busy-wait/flip the port bits 10 times in a row, then do other stuff
[03:56:47] <fenn> if the cpu was fast enough it should be able to do everything in the sliver of time that's left
[03:58:04] <SWPadnos> but the spacing betwen bursts would still suck
[03:58:48] <fenn> is timing at high speeds really that important?
[03:58:57] <fenn> i mean say you have a 10x microstepping drive
[03:59:02] <fenn> and you ouput 10 steps in a burst
[03:59:19] <SWPadnos> yes, it should be that important
[03:59:25] <fenn> why?
[04:00:01] <SWPadnos> if you output 10 steps at 5 uS each (total of 50 uS), then wait 50 uS to do it again, you would get weird behavior I think
[04:01:10] <fenn> i think it would just act like a full stepping drive
[04:01:39] <SWPadnos> I'm not sure that's true
[04:02:16] <SWPadnos> and how do you slow it down by 50%? do you do 10 pulses every second thread run, or half as many pulses every run?
[04:02:50] <fenn> half as many pulses every run
[04:03:14] <fenn> but what i meant originally was 10 steps at 5us each, then wait 5us, then do it again
[04:03:34] <SWPadnos> it's the "wait 5 uS" that's hard, if you want anything else in the system to run
[04:03:35] <fenn> i'm sure there's something obviously wrong with that :)
[04:04:03] <SWPadnos> this does a busy-wait, so *nothing* else will run while this thing is waiting to reset the parport
[04:04:12] <fenn> this pseudo-fullstep stuff is kinda interesting though
[04:04:44] <fenn> i was thinking earlier about what would happen if you switched the drive between full/half/microstep depending on how fast it's going
[04:06:06] <SWPadnos> that seems like a reasonable thing to do, if you have feedback. without it, you'd have to be really sure of the synchronization between the PC and the drive (knowing what the scale it at any given moment0
[04:06:31] <fenn> yeah the pc would be the one doing the switching
[04:07:08] <fenn> maybe you'd lose a microstep here and there
[04:07:35] <fenn> well, not if it was done right i guess
[04:09:06] <fenn> uh, so why does this newfangled patch have to be for only one driver? can't you copy the function pointer for the write function of whatever stepgen is linked to and use that directly?
[04:10:04] <fenn> or is there not always a "write" function to begin with
[04:11:36] <fenn> aww no manpage for hal parport?
[04:12:42] <SWPadnos> stepgen doesn't have a write function, it only outputs bits fora driver to grab and output
[04:12:50] <SWPadnos> the real magic here is that there
[04:13:07] <SWPadnos> the real magic here is that there's a parport write and a parport reset in the same thread. reset is what turns the step pulses off
[04:13:09] <fenn> i'm talking about the new patch - it uses the write function directly
[04:13:40] <fenn> er... crap
[04:13:45] <fenn> nevermind
[04:14:17] <fenn> this doesnt make any sense to me now
[04:14:20] <SWPadnos> heh
[04:14:34] <fenn> dont you have to wait for the parport to come along and look at the new bits?
[04:14:49] <fenn> after you "reset" them
[04:15:20] <SWPadnos> no, that's the thing. stepgen only outputs the 1 in this mode. it lets parport.reset output the 0 a little later
[04:15:35] <SWPadnos> then next thread run, it can do it again
[04:23:36] <fenn> xylotex has 200ns setup & hold times.. that's not too much busy waiting
[04:25:02] <SWPadnos> not for one pulse per thread run
[04:25:21] <SWPadnos> since you can do other work in the interim
[04:25:49] <fenn> gecko needs 5us or so, not so good
[04:26:26] <SWPadnos> it's 5 uS total I think - 200 KHz step rate
[04:26:30] <fenn> not so good for the 'toss out 10 microsteps at once" idea
[04:26:47] <fenn> yeah, 4.5us "on" 0.5us off
[04:27:01] <fenn> so you'd want your reset to send a 1 to the drive and only busy-wait 0.5us
[04:27:54] <SWPadnos> depends on which edge actually causes the step
[04:28:05] <fenn> does it matter?
[04:28:21] <fenn> says step on falling edge
[04:29:22] <SWPadnos> I guess it doesn't matter, since you'd still issue exactly one of each edge per thread run
[04:29:54] <SWPadnos> but the step space and length parameters would swap places, so the BASE_PERIOD becomes the steplen, and the wait time is stepspace
[04:30:29] <SWPadnos> well, BASE_PERIOD - latency - stepspace = minimum step length this would output
[04:32:30] <fenn> oh btw g203V is different (step on rising edge, 2us "off" time 1us "on")
[04:32:45] <SWPadnos> nighty night. bedtime for me
[04:32:53] <fenn> me too