Back
[00:00:04] <SWPadnos> wow - alex, great job. sleep well :)
[00:07:40] <SWPLinux> jmkasunich: do you have uncommitted changes to the mesa Makefile?
[00:07:57] <SWPLinux> heh - getting it from both sides, I see :)
[00:08:56] <SWPLinux> I'd like to commit the change to the usage awk script
[00:09:14] <jmkasunich> go ahead
[00:09:17] <SWPLinux> ok
[00:09:26] <jmkasunich> if I have any uncommitted stuff, I can merge easily enough
[00:09:56] <SWPLinux> yeah - the change is only one line, plus a comment moting that the script may need revision depending on the Xilinx tools
[00:10:00] <SWPLinux> noting
[00:10:25] <jmkasunich> I just did a diff - the only changes I have in the makefile are ones I did yesterday when we were experimenting with the usage thing
[00:10:33] <jmkasunich> I'll delete and update to get yours
[00:10:52] <SWPLinux> ok
[00:12:28] <SWPLinux> did we decide that things seem pretty much the same here as there, with respect to the Xilinx tools producing output?
[00:13:15] <jmkasunich> I think so
[00:13:47] <SWPLinux> ok. is there a readme anywhere that describes what each make target type should do?
[00:14:08] <jmkasunich> not at the moment
[00:14:24] <jmkasunich> I'm thinking maybe a comment block in the makefile?
[00:14:34] <SWPLinux> ok. what about the stuff we discussed way back when about the workflow? (I know it's still on pastebin.ca - search for FPGA :) )
[00:14:38] <SWPLinux> sure, that would make sense
[00:14:54] <jmkasunich> I have a readme here that has a lot of what we discussed
[00:15:01] <SWPLinux> ok
[00:15:01] <jmkasunich> not sure if I committed it yet
[00:15:19] <jmkasunich> and it has random ramblings from the last few weeks as I've been flailing around
[00:15:21] <SWPLinux> not under the name of "readme" or similar
[00:15:30] <jmkasunich> README, so I guess I didn't commit
[00:15:37] <SWPLinux> no problem. feel free to email or dcc me if you don't want to commit it :)
[00:15:42] <jmkasunich> I can pastebin the current copy if you want it
[00:15:45] <SWPLinux> ok
[00:16:01] <SWPLinux> can you tar up the directory as it is and dcc it?
[00:16:12] <cradek> use a branch use a branch use a branch use a branch
[00:16:18] <SWPLinux> or use a branch, maybe
[00:16:17] <jmkasunich> ;-P
[00:16:40] <cradek> cvs is good for collaborating on development!
[00:16:45] <jmkasunich> you are right
[00:17:01] <SWPLinux> I do plan to make the modules I write work with the .spec file/config tools, so I'll probably be able to spend some time working on the UI as well
[00:17:03] <jmkasunich> * jmkasunich doesn't want to read the fine CVS manual
[00:17:23] <jmkasunich> * jmkasunich looks for the manual
[00:17:31] <SWPLinux> maybe some nice release manager would like to make a branch for you, so you can check stuff into it
[00:17:41] <cradek> cvs tag -b mesa-stepgen; cvs update -r mesa-stepgen; cvs commit
[00:18:02] <cradek> you can branch one directory or the whole shebang
[00:18:05] <SWPLinux> mesa-configtools
[00:18:12] <jmkasunich> ok, I can probably parse what you just wrote
[00:18:22] <jmkasunich> one dir?
[00:18:27] <jmkasunich> hmm
[00:18:34] <SWPLinux> do it in the mesa_5i2x dir
[00:18:36] <jmkasunich> currently I've been working in my main checkout
[00:18:51] <SWPLinux> that dir will remain in the branch, I think
[00:18:55] <jmkasunich> you are saying that I can branch just mesa_5i2x and its subdirs?
[00:19:00] <cradek> yes
[00:19:20] <cradek> the other folks who want to use it will have to update -r thebranch in that same directory
[00:19:54] <jmkasunich> if they do that in the dir once, what will be the effect of future cvs up -dP at the top level?
[00:19:59] <SWPLinux> this has the (side) effect of hiding the branch from others, but also hiding the trunk from you, I think
[00:20:02] <jmkasunich> will it continue to keep the dir on the branch
[00:20:08] <cradek> yes
[00:20:24] <cradek> it will do the right thing (give you changes in the rest of the tree from trunk, and changes in your directory from the branch)
[00:20:34] <jmkasunich> then at some point once its merged they can do a -A (I think) in that dir to clear the stickys?
[00:20:43] <cradek> yes
[00:20:51] <SWPLinux> now isn't that useful?
[00:20:53] <jmkasunich> ok, I'm convinced
[00:23:13] <SWPLinux> let me know when you're done :)
[00:23:23] <SWPLinux> ok, looks like it
[00:23:30] <jmkasunich> about to add the readme
[00:23:49] <jmkasunich> but you should be able to checkout the branch now
[00:24:03] <SWPLinux> ah - just the firmware dir, so only one commit message
[00:24:25] <jmkasunich> I did the tag and the commit in the mesa-5i2x dir
[00:24:30] <jmkasunich> but there were no modified files there
[00:24:43] <SWPLinux> ok
[00:25:58] <jmkasunich> the bad news is that right now I can't even do "make size.usage"
[00:26:07] <SWPLinux> hmmm
[00:26:08] <jmkasunich> because it invokes my (broken) python tool
[00:26:44] <jmkasunich> gotta figure that out - I didn't think it would as long as the vhdl (which that tool will eventually generate) is newer than the specs that the tool reads
[00:26:51] <jmkasunich> I touched the vhdl, and it still did it
[00:27:22] <SWPLinux> ok - what's the toolchain supposed to be? can we look at the pastebin and put target suffizes on the various stages (where they don't exist yet)
[00:27:48] <jmkasunich> stand by a sec
[00:28:29] <jmkasunich> grr
[00:28:36] <SWPLinux> http://pastebin.ca/499631
[00:28:37] <jmkasunich> ok, I was trying something that didn't work
[00:28:40] <SWPLinux> ok
[00:29:02] <jmkasunich> do an update on the branch - I committed the readme
[00:29:06] <SWPLinux> I think that was the last pastebin when we discussed it before
[00:29:09] <jmkasunich> cia doesn't report new files I think
[00:29:27] <jmkasunich> the readme has pretty much the same thing, but more current
[00:29:36] <jmkasunich> perhaps I should say "less out of date"
[00:29:35] <SWPLinux> ok
[00:29:37] <SWPLinux> heh
[00:29:41] <SWPLinux> same thing to me
[00:35:40] <jmkasunich> cradek: interesting cvs behavior:
[00:36:00] <jmkasunich> Checking in README;
[00:36:00] <jmkasunich> new revision: 1.1.2.2; previous revision: 1.1.2.1
[00:36:00] <jmkasunich> done
[00:36:00] <jmkasunich> rlog: /cvs/emc2/src/hal/drivers/mesa_5i2x/firmware/README,v: No such file or directory
[00:36:00] <jmkasunich> rlog: /cvs/emc2/src/hal/drivers/mesa_5i2x/firmware/README,v: No such file or directory
[00:36:02] <jmkasunich> jmkasunich@mahan:~/emcdev/emc2head/src/hal/drivers/mesa_5i2x/firmware$
[00:36:10] <jmkasunich> (I made some changes to README and committed)
[00:36:32] <jmkasunich> the log message on the commit list doesn't include a diff
[00:36:44] <jmkasunich> might that be because the file exists only in the branch?
[00:37:39] <cradek> yes exactly
[00:37:39] <jmkasunich> hmm, got the same thing for the initial checkin of readme
[00:37:47] <cradek> I've seen that and never bothered to fix it, just ignore it
[00:37:53] <jmkasunich> ok
[00:37:56] <cradek> the checkin is right, the email generation is wrong
[00:38:43] <jmkasunich> SWPLinux: update again to get the latest readme
[00:39:03] <SWPLinux> just got it, thanks
[00:40:02] <SWPLinux> I don't see any description of what the .size target is supposed to do
[00:40:17] <SWPLinux> I guess I could switch to the editor with the Makefile open :)
[00:40:32] <jmkasunich> there isn't a .size target
[00:40:35] <SWPLinux> hmmm. maybe - right
[00:40:37] <SWPLinux> usage
[00:40:50] <jmkasunich> oh
[00:41:02] <SWPLinux> that's not there either
[00:41:22] <jmkasunich> readme takes a high level view, it doesn't describe each step in the xilinx flow
[00:41:29] <jmkasunich> (it probably should, but it doesn't at the moment)
[00:41:39] <jmkasunich> lemme look around, I think I have a file with my notes on that)
[00:41:42] <SWPLinux> no problem
[00:42:36] <SWPLinux> o - if you have info that you think I can decipher, please check that in. I think I know enough about how the toolchain is supposed to work that I only need pointers to what names the various parts have
[00:43:32] <SWPLinux> also, if you'd like to discuss UI stuff, we can do that. I may prefer to work on that on the plane so I can use a non-RT boot (so my lap doesn't get as hot :) )
[00:47:34] <jmkasunich> pretty much all of this toolchain stuff can be done on a sim box
[00:48:46] <jepler> you can also test that the rt stuff compiles, if you don't mind me stating the obvious
[00:48:51] <jepler> that's likely all you can do on a laptop anyway
[00:49:13] <jmkasunich> right - kinda hard to plug the 5i20 into the laptop
[00:50:47] <SWPLinux> well, the 7i43 however ...
[00:50:52] <SWPLinux> not that I have one
[00:52:27] <SWPLinux> actually, on this laptop, I won't be able to test that RT stuff compiles unless I boot RT, because I don't have time to set up VMWare player
[00:52:38] <SWPLinux> unless there's another way
[00:52:47] <jmkasunich> I think there is configure foo to tell it to build RT while running non-RT
[00:52:59] <SWPLinux> ah. I don't want to deal with that at the moment
[00:53:23] <SWPLinux> yeah - I guess you should be able to do something like --with-rtai=
[00:54:25] <cradek> --with-realtime= iirc
[00:54:31] <SWPLinux> yep - just looked :)
[00:55:44] <SWPLinux> I suppose I should get all the computer hardware off the dining room table before my wife gets home
[01:00:16] <SWPLinux> interesting. when you have multiple keyboards plugged in, caps-, scroll- and num-lock track each other
[01:00:29] <SWPLinux> ie, the num-lock light comes on on all the keyboards
[01:01:33] <SWPLinux> I guess you need to set things up to not send core events to stop that (shift, alt, and ctrl also are "shared" - it's like one big keyboard with 3 of each key :)
[01:02:00] <jepler> SWPLinux: yes if you take control of a specific keyboard with the input device layer, its lock lights and so on become fully independent
[01:03:13] <jepler> e.g., hal_input with "+" at the beginning of the device specifier
[01:05:53] <SWPLinux> right
[01:06:16] <SWPLinux> it was surprising to be able to press shift on one keyboard and get capital letters on another though
[01:07:05] <jepler> X only anticipated a single modifier set
[01:08:40] <SWPLinux> since they're core events, it should look like one keyboard to any higher layer
[01:08:54] <SWPLinux> which makes sense - it was just kind of funny to see 3 lights toggling
[01:11:24] <cradek> wow, we have a lot of new stuff in trunk. we sure need to release it.
[01:12:18] <SWPLinux> if it's at all possible, I'd like to release 2.2 on a later Ubuntu than dapper
[01:12:33] <cradek> is there a new LTS?
[01:12:42] <SWPLinux> no, and there won't be for almost 2 years
[01:12:49] <SWPLinux> and that's way too long
[01:13:24] <cradek> that means we lose every 6 months - yuck.
[01:13:29] <SWPLinux> actually, I could be wrong about that. they may be releasing another as either 7.10 or 8.04
[01:13:43] <cradek> 7.10 would be very nice
[01:13:47] <SWPLinux> they will probably have two LTS releases active at a time
[01:14:20] <SWPLinux> yeah. I think there are enough additions - even simple stuff like having widescreen modes on the liveCD - that 7.10 would be good even if it isn't an LTS
[01:14:29] <jmkasunich> if 7.10 is going to be a lts, I suggest that we wait for it for 2.2
[01:14:41] <cradek> I'm still making 2.1 breezy releases - we'll just have to continue to make two - dapper and something else
[01:14:56] <SWPLinux> 8.04 will be the next
[01:15:10] <cradek> maybe we can use dapper until then.
[01:15:23] <cradek> then we'll do releases for dapper & 8.04
[01:15:30] <cradek> (no need to wait)
[01:15:40] <SWPLinux> right
[01:16:25] <cradek> maybe the next one could be SMP too, and screw the folks without LAPICs - they can get new machines or continue to run dapper
[01:16:48] <jmkasunich> what generation of machines would that be?
[01:16:54] <jmkasunich> P3's have LAPICS?
[01:16:58] <jmkasunich> P2s?
[01:17:00] <SWPLinux> I'm running your SMP kernel on a sempron UP laptoip at the moment
[01:17:06] <cradek> even genuine PII have them I think
[01:17:20] <cradek> I think it's the oddball machines that don't work
[01:17:56] <cradek> I don't know the details - I know skunkworks has one like that
[01:18:12] <SWPLinux> what's the latest kernel on "regular" Dapper?
[01:18:18] <SWPLinux> isn't it still 2.6.15-ish?
[01:18:21] <cradek> yes
[01:18:31] <cradek> I think they never change kernel versions
[01:18:38] <SWPLinux> they do, but not often
[01:18:56] <SWPLinux> I had much better latencies with the SMP 2.6.20 kernel than with 2.6.15
[01:19:07] <SWPLinux> like 2 us with SMP, 5-6 with UP
[01:19:11] <cradek> probably a rtai difference, not kernel
[01:19:16] <SWPLinux> could be
[01:19:28] <SWPLinux> this was on a single core celeron
[01:19:28] <cradek> oh SMP vs UP too, apples/oranges
[01:19:30] <SWPLinux> yep
[01:19:46] <SWPLinux> the SMP kernel may be better due to preemption issues
[01:19:56] <cradek> * cradek waves his hands
[01:20:40] <SWPLinux> I guess I'm saying that if itdoesn't hurt too much, the SMP kernel / a later kernel would be great, and it works on SMP or UP as well
[01:20:51] <cradek> well only some UP (those with LAPICs)
[01:21:03] <SWPLinux> ok - newer machines
[01:21:13] <cradek> we currently have a kernel that will run on virtually anything
[01:21:24] <cradek> I'd be sorry to give that up, but I'd really like SMP too
[01:21:23] <SWPLinux> sure, but not as well
[01:21:26] <SWPLinux> yeah
[01:21:55] <SWPLinux> I thought the liveCD boot had some way of picking the right kernel for the hardware
[01:22:01] <SWPLinux> like SMP/UP, etc
[01:22:06] <cradek> we should use the same kernel forever on dapper - and support it throughout 2.2
[01:22:25] <SWPLinux> that is probably the smartest thing to do :)
[01:22:49] <cradek> but, we can package for "something else" too, even start that later in 2.2
[01:24:19] <cradek> these are all issues for the new board to decide.
[01:24:38] <SWPadnos> yep
[01:28:15] <cradek> bbl
[01:28:23] <SWPadnos> see you later
[01:34:48] <jmkasunich> SWPLinux: just committed an annotated makefile
[01:36:10] <SWPadnos> ok. thanks
[01:36:24] <SWPadnos> do you have time to discuss UI stuff as well?
[01:37:42] <jmkasunich> sure
[01:37:58] <jmkasunich> what particular UI are we talking about?
[01:38:01] <SWPadnos> ok. give me a minute and I'll talk it out with you
[01:38:11] <SWPadnos> the stuff you've had trouble with :)
[01:38:21] <jmkasunich> oh
[01:38:26] <SWPadnos> mesa toolchain
[01:38:51] <SWPadnos> feel free to ramble a bit - I need to move some stuff around, but I can read faster than you can type :)
[01:39:04] <jmkasunich> oh I get it
[01:39:31] <jmkasunich> when you said "do you have time to discuss" I thought you wanted to discuss something in particular
[01:39:36] <SWPadnos> heh - right - I'd like to help move the mesa toolchain along
[01:39:49] <SWPadnos> ah - no, just get sort of a to-do / trouble list together
[01:39:53] <jmkasunich> ok
[01:40:21] <jmkasunich> you can read faster than I can type, but I can cheat
[01:40:28] <SWPadnos> damned paste
[01:40:29] <jmkasunich> I can tell you to read README
[01:40:28] <SWPadnos> :)
[01:40:32] <SWPadnos> heh
[01:40:46] <SWPadnos> ok. brb - gotta move stuff around a bit
[01:40:59] <jmkasunich> take your time, I'm doing something along the same lines
[01:41:34] <SWPLinux> ok. I'll have to go pick up my wife at around 10:00
[01:41:45] <SWPLinux> err - 11:00
[01:41:56] <jmkasunich> ok
[01:42:09] <jmkasunich> I was gonna say "10? then lets not get started"
[01:42:24] <SWPLinux> yeah - I noticed the clock and almost had a heart attack
[01:47:42] <jmkasunich> I've got something really squirrely going on in the makefile
[01:47:52] <jmkasunich> but I probably shouldn't let it distract me
[01:50:46] <jmkasunich> ok, I'm ready to talk when you are
[02:08:10] <SWPLinux> ok - ready
[02:08:36] <jmkasunich> the thing thats been driving me nuts is handling I/O pins
[02:08:40] <SWPLinux> I read through the last section of the README - figuring that the upper stuff is close enough to what we came up with before
[02:08:40] <SWPLinux> ok
[02:09:02] <jmkasunich> the last few days I think I might be getting back on track though
[02:09:29] <jmkasunich> a big improvement is when I started writing a detailed description of what each class does in the file before the class def
[02:09:36] <SWPLinux> heh
[02:09:41] <SWPLinux> top-down design, in more ways than one :)
[02:09:47] <jmkasunich> I'm working on spec2vhdl right now - fpgaedit is on the back burner
[02:10:22] <jmkasunich> (we were messing with fpgaedit at the workshop - I'm pretty sure that it won't be quite as nasty once spec2vhdl is right)
[02:11:18] <SWPLinux> ok - spec2vhdl is the "I have modules, and I want to create an FPGA config with those modules"
[02:11:30] <jmkasunich> I just committed my latest spec2vhdl so we can talk about it
[02:11:34] <jmkasunich> right
[02:11:38] <SWPLinux> ie, 6 stepgens and 10 PWMgens ...
[02:11:42] <SWPLinux> ok
[02:12:02] <jmkasunich> right - and the 6 stepgen 10 pwmgen part isn't the main issue
[02:12:33] <jmkasunich> the issue is how I tell it that pin 23 can be stepgen.0.phaseA or pwmgen.2.up or gpio.23, etc
[02:13:03] <jmkasunich> I think I've figured out that I need a pindriver class, which is what I've just been working on
[02:13:15] <jmkasunich> comment block at line 347
[02:13:17] <SWPLinux> ok - do you want to be able to assign any pin to a particular module I/O ?
[02:13:40] <jmkasunich> at the spec level, yes
[02:13:56] <SWPLinux> right - so there's a sane drop-down of possible functions at the fpgaedit level
[02:14:07] <SWPLinux> (for each pin)
[02:14:11] <jmkasunich> suppose the fpga spec says you have an SPI module, and the module spec for spi says it has clock and data pins
[02:14:49] <jmkasunich> in the fpga spec I need to say "spi.0.clock goes on pin 23"
[02:15:04] <jmkasunich> there might be something else that also goes on pin 23
[02:15:29] <jmkasunich> after place-n-route, I need to save an enum variable for pin 23 that has "spi.0.clock" and "something-else" as its choices
[02:15:46] <jmkasunich> I also need to emit VHDL for a mux that chooses between those two things
[02:15:54] <jmkasunich> (I'm gonna support more than 2, probably 8)
[02:16:07] <SWPLinux> damn thos emoticons
[02:16:11] <SWPLinux> +e
[02:16:25] <jmkasunich> text my friend, text!
[02:16:28] <SWPLinux> heh
[02:16:53] <SWPLinux> so, do you have a clear idea of what to do, or some particular block on getting it done?
[02:17:00] <SWPLinux> I can tell you waht I think should work
[02:17:03] <jmkasunich> well, its gotten clearer lately
[02:17:13] <SWPLinux> good
[02:17:16] <SWPLinux> deal
[02:17:20] <jmkasunich> I have a chip-select class that is well described and well implemented I thnk
[02:17:38] <jmkasunich> the module instance class needs revised heavily
[02:17:43] <jmkasunich> the pindriver class is new, and comes first I think
[02:17:53] <jmkasunich> the flow I'm leaning towards is:
[02:18:11] <jmkasunich> 1) read general stuff from spec, such as which board I'm targeting, etc
[02:18:36] <jmkasunich> 2) create the relevant number of pindriver objects, which will start out with no sources connected to them
[02:19:13] <jmkasunich> 3) create gpio module instance(s), which will register themselves as sources for each pin
[02:19:40] <jmkasunich> 4) read the spec and create other module instances, which will register themselves as sources for certain pins
[02:19:55] <jmkasunich> 5) generate chip select objects as needed for each instance
[02:20:14] <jmkasunich> 6) iterate thru instance and pin lists, generating the vhdl and other output files
[02:20:50] <SWPLinux> ok
[02:21:34] <jmkasunich> I have to resist the urge to optimize, and trust the tools
[02:21:53] <jmkasunich> if you look above the comment block that describes the pindriver class, you'll see some vhdl generation code
[02:21:56] <SWPLinux> at this stage, do we already have a count of stepgens, for instance, or is the user deciding how many to put int?
[02:22:05] <jmkasunich> the user is deciding
[02:22:16] <jmkasunich> that is in the fpga spec file, input to this program
[02:22:38] <jmkasunich> he decides how many and what pins they hook to
[02:23:25] <SWPLinux> ok, so the input spec has a list of what's allowed - the program doesn't have to go find out what modules could go in the config
[02:23:45] <jmkasunich> the input fpga spec has a list of what he wants
[02:23:56] <jmkasunich> there are also module specs
[02:24:09] <jmkasunich> the module specs tell it what the possibilities are
[02:24:14] <SWPLinux> sure - those have the interface specs and pin names and such
[02:24:21] <jmkasunich> right
[02:24:52] <jmkasunich> fpga spec is a source file, module specs are headers, and the individual module vhdl files are libraries (C analogy)
[02:24:53] <SWPLinux> it sems that you could treat the pindriver and gpio as one entity in this program
[02:25:14] <SWPLinux> err - no, maybe not. nevermind
[02:25:17] <jmkasunich> I've gone back and forth on that
[02:25:31] <SWPLinux> because the GPIO is a function that you allow for a pin
[02:25:49] <jmkasunich> my latest thinking is that pindriver is the mux and driver stuff, and gpio is the module that the driver accesses which handles many pins
[02:26:01] <SWPLinux> but there may be cases where you don't want to allow GPIO on a pin
[02:26:29] <jmkasunich> I assumed that it would always be an option - disable whatever special function it has, and you can use it as I/O
[02:27:01] <SWPLinux> you get into protection issues if you allow a user to possibly change a pin to output that should really be left as input - a capability which I/O implies
[02:27:22] <SWPLinux> but that's a separate issue, I think
[02:27:27] <jmkasunich> which level of user ;-)
[02:27:33] <SWPLinux> heh
[02:27:39] <jmkasunich> the fpgaedit tool will let you specify the mode of the pin
[02:28:05] <jmkasunich> once the fpga and hal driver are loaded, the directions are fixed
[02:28:15] <SWPLinux> so, it seems that it would be easy enough to create 48 / 72 / 96 pindriver and GPIO entities, and by default connect GPIOs to all pindrivers
[02:28:24] <jmkasunich> yes, that was the plan
[02:28:41] <jmkasunich> step 3 in the flow I wrote a little while ago
[02:28:58] <jmkasunich> 2) make pindrivers 3) make gpios 4) make other modules per the spec
[02:29:11] <SWPLinux> since the purpose of this program is to connect modules to pins, it makes sense to not have pins or GPIO modules treated as generic objects
[02:29:17] <SWPLinux> they are the subject of the program
[02:29:28] <SWPLinux> right
[02:29:37] <jmkasunich> pins certainly - and trying to make them generic objects was one of the ways I went astray
[02:29:42] <jmkasunich> the pindriver class is the answer to that
[02:29:59] <jmkasunich> I'm less sure about gpio as generic vs specific
[02:30:12] <SWPLinux> you may need different types of pin object though, since Spartan II and Spartan III have different options (which may have no relevance, but could)
[02:30:29] <SWPLinux> I think GPIO should be generic, but just a default created module
[02:30:40] <jmkasunich> right, thats what I was thinking too
[02:31:04] <SWPLinux> and the mux can be a specific "well-known" block of VHDL that's emitted for any pin that has more than one module in its list of connections
[02:31:27] <jmkasunich> see the stuff starting at line 302?
[02:31:27] <SWPLinux> you can optimize it away if there's only one module connected - that's easy ehough
[02:31:39] <jmkasunich> those are 8 different mux implementations, for 1 thru 8 sources
[02:32:07] <jmkasunich> probably premature optimization, I could emit the same logic for all cases and let Xilinx optimize it away
[02:32:16] <jmkasunich> but I trust myself more than I trust xilinx
[02:33:02] <SWPLinux> I'd just write a mux vhdl block, and pipe it through the same text substitution code that other modules will go through (with different substitutions, of course)
[02:33:06] <jmkasunich> the '${o}' etc is for text substitution - actual signal names will go in the emitted vhdl
[02:33:11] <SWPLinux> ok
[02:34:14] <jmkasunich> anyway, I'm not sure the line 302 stuff is the correct approach, its just one approach to that part
[02:34:22] <SWPLinux> sure
[02:34:42] <jmkasunich> I need to figure out an overall way to tackle this thing
[02:34:54] <jmkasunich> its tempting to try to complete one class, then move on
[02:34:57] <jmkasunich> but I think thats wrong
[02:35:01] <SWPLinux> it doesn't really matter if you have an array of VHDL blocks for the mux, it's only marginally harder to use them
[02:35:32] <SWPLinux> if you want to do that, use the GPIO as the complete class
[02:35:50] <SWPLinux> it's pretty well defined, and has only one pin :)
[02:36:02] <jmkasunich> actually gpio has lots of pins
[02:36:15] <jmkasunich> because gpio is the module that the driver interacts with
[02:36:25] <jmkasunich> so it has word wide registers that control multiple pins
[02:36:44] <SWPLinux> hmmm. are you going to allow the user to decide where in the overall GPIO memory space to put each pin?
[02:36:53] <jmkasunich> I haven't decided whether there will be 3 (for the 5i20) GPIOs, each controlling 24 pins, or one GPIO that controls all 72
[02:37:07] <jmkasunich> memory space as in PCI bus addresses?
[02:37:18] <SWPLinux> I'd say separate. there are mesa boards with 2, 3, and 4 connectors
[02:37:48] <SWPLinux> yes - ie, where in the word the CPU reads the bit goes
[02:38:07] <jmkasunich> PCI addresses will be invisible to the user
[02:38:21] <SWPLinux> GPIO1 connects to header 2, pin 5, and is read as bit 19 of the GPIO data word
[02:38:21] <jmkasunich> each module's entry in the 1K ram includes a base address
[02:38:46] <SWPLinux> or do you expect the bit positions to be fixed?
[02:39:01] <jmkasunich> they will be fixed relative to the base address
[02:39:32] <jmkasunich> the base addresses will be assigned by the chip select generation step, which is already in pretty good shape
[02:39:42] <SWPLinux> ok, for a single connector, there may be inputs and outputs, and that (or those) register will be at some address - that's not what I'm talking about
[02:40:04] <SWPLinux> I'm talking about which bit position in that register each GPIO actually represents
[02:40:09] <jmkasunich> after ALL module instances are defined, the select generation code packs them into the address space based on the size of the address block each instance needs
[02:40:46] <jmkasunich> bits will be packed into registers in a logical fashion, which the gpio portion of the HAL driver understands
[02:41:07] <jmkasunich> if I do 24 pins per gpio module, then pins 0 thru 23 will be bits 0-23
[02:41:18] <SWPLinux> ok - so it's not going to be a user-selectable item in this program
[02:41:26] <jmkasunich> no reason for that
[02:42:03] <SWPLinux> this gets back to the parport pin numbering question. if you have 12 inputs, are they XXX.in-0 through xxx.in-11, or are they sparse, depending on which pins are actually assigned?
[02:42:03] <jmkasunich> pin 2 on port A will have the HAL name gpio.A02.in, gpio.A02.out, etc, and the internals don't matter
[02:43:00] <jmkasunich> the hal pin numbers will always match up up to the physical
[02:43:04] <SWPLinux> ok
[02:43:14] <SWPLinux> that's a discussion for another time :)
[02:43:29] <jmkasunich> if you have a 7i31 LED board, io A05 will always light LED 05 on the board attached to cable A
[02:44:13] <jmkasunich> if A05 is configured as stepgen or gpio, and stepgen was selected at the fpgaedit stage, then there won't be a gpio.A05 hal pin
[02:44:21] <SWPLinux> ok, and you'll get a HAL error if someone changes the function in the config, which is fine
[02:44:38] <SWPLinux> (if you've got something connected to A05)
[02:44:41] <jmkasunich> right
[02:45:24] <jmkasunich> regarding 1 or 2/3/4 GPIO modules.... to an extent thats also premature optimization on my part, but...
[02:45:41] <jmkasunich> assume 24 pins per GPIO module for a moment
[02:45:47] <jmkasunich> I have quite a few registers in that GPIO
[02:45:56] <jmkasunich> one read reg - input state
[02:46:25] <SWPLinux> read, write, pull-up enable, tristate, ...
[02:46:37] <jmkasunich> write regs: output state (if gpio), enable (if gpio and tristate), mode select (2 bits, selects in, out, tristate, oc), and source (3 bits)
[02:47:02] <SWPLinux> right - how do you pack them? ...
[02:47:05] <jmkasunich> as written right now, there are 7 regsiters, 24 bits each
[02:47:21] <jmkasunich> out, ena, mode0, mode1, src0, src1, src2
[02:47:26] <SWPLinux> it's ideal to have all the read registers next to each other, as well as all the write registers
[02:47:28] <SWPLinux> ok
[02:47:36] <jmkasunich> only out and ena are accessed after startup
[02:47:51] <SWPLinux> I think you need to have the concept of register "groups"
[02:47:56] <jmkasunich> the thing is - lots of 24 bit registers means lots of load on the low data lines, and nothing on the high lines
[02:48:24] <SWPLinux> is that a problem you need to deal with?
[02:48:27] <jmkasunich> if I had only one GPIO for all pins, I would have fewer regsiters total cause I'd pack 32 pins per reg
[02:48:58] <jmkasunich> well, worst timing is almost always the data bus when reading
[02:49:20] <SWPLinux> it's only one more load than perfect packing (per register)
[02:49:29] <jmkasunich> address -> decode -> enable data to bus -> propagate internally -> pindrivers -> external bus
[02:49:36] <SWPLinux> but aren't the internal registers tristated when not selected?
[02:49:53] <jmkasunich> they're coded in VHDL as tristate
[02:50:11] <jmkasunich> but it appears that xilinx doesn't like internal tristate buses, they convert it to logic
[02:50:19] <SWPLinux> hmmm
[02:50:40] <SWPLinux> ok, let me restate the question - is this a problem that needs to be dealt with in this tool?
[02:50:43] <jmkasunich> if there are 25 things that can drive a bus line, they have 25 and gates, with the "tri-state enable" as one input, and the register as the other
[02:50:50] <jmkasunich> then all 25 are ored together
[02:51:07] <jmkasunich> re: the restate....
[02:51:11] <jmkasunich> maybe ;-/
[02:51:14] <SWPLinux> heh
[02:51:37] <jmkasunich> it depends on how I implement GPIO, whether the tool reads a template or actually emits the vhdl directly
[02:51:51] <jmkasunich> regardless, the decision needs to be made before anything can be tested
[02:52:05] <SWPLinux> I don't think it should be. there's no reason to think that we'll be able to make a tool that will be able to do better at deciding what will work in an FPGA than the vendor of the FPGA
[02:52:15] <SWPLinux> I think it should use an external template
[02:52:23] <jmkasunich> and both the C source for the gpio driver and the VHDL source for the gpio module need to match
[02:52:38] <SWPLinux> GPIO is a module, like PWMGen or Stepgen - it just gets automatically created for you
[02:52:42] <jmkasunich> sorry, there is a misunderstanding here
[02:52:56] <jmkasunich> I'm not at all proposing that I make the tristate vs bunch-o-gates descision
[02:53:07] <jmkasunich> only the 24 per register vs 32 per register decision
[02:53:25] <jmkasunich> and no mater how you slice it or what device you use, 32 per register is more efficient
[02:53:40] <jmkasunich> the only quesion is how much more and does it matter
[02:53:50] <SWPLinux> I think if one extra register (or 50, for that matter) causes the thing to not work, then we'll need to revisit it, but until then I'd keep it clean - one GPIO per connector
[02:54:10] <jmkasunich> fwiw, the C driver is written that way already
[02:54:20] <SWPLinux> ok - that's good :)
[02:54:44] <SWPLinux> it's the same number of registers anyway, until you get to the 4-connector board
[02:54:52] <jmkasunich> yeah
[02:54:59] <jmkasunich> 24+24+24 = 32+32+8
[02:55:27] <SWPLinux> yep. another premature optimization eliminated! :)
[02:56:18] <jmkasunich> ;-)
[02:56:56] <jmkasunich> right now I need to figure out the order in which to code things in spec2vhdl.py
[02:57:23] <SWPLinux> your step 4 may be misworded, or I don't understand the input to this program
[02:57:57] <jmkasunich> instead of thinking in terms of "finish class A (say pindriver), then do class B (module instance), I should probably try to list the methods of all the clases, and then implement them only as needed
[02:57:57] <SWPLinux> does the module spec or the input spec tell us which pindrivers could possibly be connected to the module pins?
[02:58:30] <SWPLinux> or are we making those decisions here (in this program)?
[02:58:34] <jmkasunich> the module spec says "a stepgen has two pins called step/up/phA, and dir/down/phB
[02:58:48] <jmkasunich> the input spec says "for stepgen 1, connect step/up/phA to pin 23
[02:59:44] <jmkasunich> any module pin (like step/up/phA) can only connect to one fpga pin
[03:00:02] <SWPLinux> ok. I thought we were discussing the program which allows a user to make those connection decisions
[03:00:33] <jmkasunich> IRC fails me
[03:00:35] <SWPLinux> heh
[03:00:37] <jmkasunich> lets try
[03:01:12] <jmkasunich> you can have a pwm, a stepgen, gpio, and an encoder all connected (at the spec2vhdl stage) to pin 23
[03:01:23] <SWPLinux> wait
[03:01:40] <SWPLinux> are those connected to pin 23 in the input to spec2vhdl, or as the output of spec2vhdl?
[03:01:50] <jmkasunich> both
[03:02:04] <jmkasunich> lemme type an example
[03:02:20] <SWPLinux> so the decision of which things could possibly be activated on pin 23 is part of the input to spec2vhdl
[03:02:28] <jmkasunich> this is the fpga spec - assume the module spec for stepgen says there is a pin called step, and the module spec for an pwm has a pin called pwm
[03:02:35] <jmkasunich> yes
[03:02:38] <jmkasunich> fpga spec:
[03:02:44] <jmkasunich> [ stepgen.0 ]
[03:02:49] <jmkasunich> pin step 23
[03:02:58] <jmkasunich> <more stepgen stuff>
[03:03:06] <jmkasunich> [ pwmgen.4 ]
[03:03:11] <jmkasunich> pin pwm 23
[03:04:00] <jmkasunich> later at the fpgaedit stage, pin 23 has a dialog listing three possible sources: stepgen.0.step, pwmgen.4.pwm, and gpio.A23.out
[03:04:01] <SWPLinux> ah - ok. there are two stages for the type 3 user
[03:04:48] <jmkasunich> yeah, one wires the inputs to the mux, the other sets the mux to a specific input
[03:05:21] <SWPLinux> ok. I think I had thought that a level 2 user would be able to set the mux options
[03:05:36] <SWPLinux> leaving it out of the level 3 realm
[03:05:54] <jmkasunich> you can't wire the inputs to the mux without the toolchain
[03:06:11] <jmkasunich> you _can_ change the mux setting without the toolchain
[03:06:19] <jmkasunich> the former is level 3,. the latter is level 2
[03:06:24] <SWPLinux> the select inputs can come from registers, so they can be modified in level 2
[03:06:26] <SWPLinux> right
[03:06:59] <SWPLinux> this is the second stage of level 3 - that's why I was confused about it
[03:07:12] <jmkasunich> I don't think of it as a 2nd stage of level 3
[03:07:21] <SWPLinux> I hadn't separated the two stages in my mind, and that's aprt of the README that I only skimmed over
[03:07:25] <jmkasunich> every level 3 user is also a level 2 user and a level 1 user
[03:07:28] <SWPLinux> sure
[03:07:34] <SWPLinux> it's listed in the README as level 3 stage 2 :)
[03:08:02] <SWPLinux> lines 90-105
[03:08:07] <jmkasunich> oh, I was looking at the level descriptions at the top
[03:08:12] <SWPLinux> heh
[03:08:22] <jmkasunich> "stage 2" is transparent to the actual user
[03:08:41] <jmkasunich> stage 1 - the user makes decisions and writes the spec
[03:08:51] <jmkasunich> stage 2 - make reads the specs and does stuff
[03:09:13] <SWPLinux> ah, so there's really no UI here :)
[03:09:26] <jmkasunich> no GUI
[03:09:28] <SWPLinux> right
[03:09:29] <jmkasunich> just a format for the spec file
[03:09:43] <jmkasunich> level 2 is where the GUI 'fpgaedit' comes in
[03:09:46] <SWPLinux> I'm gonna have to run now, and I probably won't be back on tonight, nor tomorrow outside normal work hours
[03:09:48] <SWPLinux> right
[03:09:57] <jmkasunich> ok
[03:10:24] <SWPLinux> is there some particular thing I can do on the road that will help out?
[03:10:27] <jmkasunich> we managed to make some decisions, and I can make progress on building the classes I need
[03:10:53] <jmkasunich> I'm not sure
[03:11:01] <SWPLinux> I think at this stage, you don't need heavy class-ification
[03:11:13] <SWPLinux> you're pretty much doing text substitutions on a lot of different things
[03:11:31] <jmkasunich> PinDriver, ModuleInstance, ChipSelect are the classes I have in mind so far
[03:11:53] <jmkasunich> each one will have methods that create and adjust them
[03:11:56] <jmkasunich> and methods that generate output
[03:12:24] <SWPLinux> so conceptually, you have some class with lists of places to get templates, things to put in those templates, and a map between the substitution placeholder names ($i0) and substitution text (gpio.0.pin.3.output)
[03:12:47] <jmkasunich> yeah
[03:13:05] <SWPLinux> there shouldn't be a lot more than that here - even the optimized mux is just a decision about which array element to use as the template
[03:13:06] <jmkasunich> at least, the ModuleInstance class is like that
[03:13:11] <SWPLinux> sure
[03:13:43] <jmkasunich> the ChipSelect class is more complex and doesn't use templates
[03:13:53] <SWPLinux> ok - gotta run. see you later. I'll read back when I get home, so if you have any thoughts, type 'em in
[03:13:59] <jmkasunich> ok
[03:13:59] <jmkasunich> goodnight
[03:14:06] <SWPLinux> righto - same for you
[03:14:22] <SWPLinux> (I'll be back on my regular PC)
[14:06:24] <jepler> cradek: do you intend to fix this error installing the latest truetype-tracer package on an ubuntu system?
[14:06:29] <jepler> The following packages have unmet dependencies:
[14:06:31] <jepler> truetype-tracer: Depends: libfreetype6 (>= 2.1.10-1) but 2.1.7-2.4ubuntu1.3 is to be installed
[14:06:34] <jepler> E: Broken packages
[14:06:35] <jepler> er, on a breezy system
[14:16:54] <cradek> yeah let me see if I can figure it out
[14:18:29] <jepler> I finally found where to get breezy packages:
http://old-releases.ubuntu.com/releases/
[14:18:45] <jepler> should we note somewhere that emc2.2 will not be released for breezy?
[14:18:53] <cradek> yes
[14:19:05] <jepler> where?
[14:20:10] <cradek> good question
[14:20:45] <jepler> I can add a note on the wiki ..
[14:20:53] <jepler> under "news"
[14:20:53] <jepler> === End-of-life for Ubuntu Breezy ===
[14:20:53] <jepler> Ubuntu has ended support for "Breezy". Starting with EMC 2.2.0, packages for Breezy will not be built. You can upgrade a Breezy system to Dapper if you follow [[Breezy_Upgrading|these instructions]].
[14:21:43] <cradek> great
[14:22:31] <alex_joni> should I add a news item to www.linuxcnc.org ?
[14:22:50] <SWPadnos> make an updated package that just shows the message :)
[14:22:57] <SWPadnos> updates ECM2 package, taht is
[14:23:12] <alex_joni> we could also add a notice to the latest emc2 release
[14:23:14] <SWPadnos> argh. must drink the coffee
[14:25:16] <jepler> since users will probably have to do something manually to switch to 2.2 it may not matter so much
[14:25:22] <jepler> I dunno
[14:26:36] <cradek> jepler: tracer fixed
[14:28:18] <jepler> cradek: great, thanks
[14:32:06] <alex_joni> later all
[14:32:13] <jepler> bye alex_joni
[14:37:25] <cradek> can someone explain the CANON_POSITION struct to me? (canon.hh)
[14:37:46] <cradek> those are constructors right? should it be class, not struct, or does that matter?
[14:39:37] <SWPadnos> struct and class are identical except for default accessibility
[14:39:44] <SWPadnos> (public/private)
[14:40:14] <cradek> ok, so those x,y,z,etc are public since this is a struct? (they must be in this case, for it to be useful)
[14:40:38] <SWPadnos> yes, that may be why it's a struct. it saves one word "public:"
[14:40:53] <cradek> ok
[14:41:00] <cradek> now moving on to the hard questions...
[14:41:05] <SWPadnos> oh shit
[14:41:11] <jepler> the constructor allows you to write: CANON_POSITION p = CANON_POSITION(1.0, 2.0, 3.0, ..., 9.0);
[14:41:14] <cradek> I know I can assign one of these to another with = (you can even do that in C)
[14:41:22] <cradek> can I compare them with != ?
[14:41:30] <SWPadnos> good question
[14:41:37] <SWPadnos> have you tried compiling something that does that?
[14:41:37] <jepler> no, you would have to write 'operator !='
[14:42:13] <cradek> ok, I figured so, let me see if I can figure out how to spell that
[14:42:14] <SWPadnos> ok - for a struct, those operators may not be created automatically. I thought for structs you got trivial = / ~= operators (that would compare elements)
[14:42:25] <SWPadnos> err - for classes, not for structs
[14:42:41] <jepler> I think it's something like this:
[14:42:42] <jepler> operator!=(const CANON_POSITION &o) const {
[14:42:42] <jepler> if(x != o.x) return 1; if(y != o.y) return 1; if(z != o.z) return 1;
[14:42:42] <jepler> if(a != o.a) return 1; if(b != o.b) return 1; if(c != o.c) return 1;
[14:42:42] <jepler> if(u != o.u) return 1; if(v != o.v) return 1; if(w != o.w) return 1;
[14:42:45] <jepler> return 0;
[14:42:47] <jepler> }
[14:42:50] <SWPadnos> eek
[14:43:11] <jepler> (inside the 'struct' declaration)
[14:43:28] <SWPadnos> you don't want to return 1, you want to return true/false
[14:43:28] <cradek> are all the consts needed? (what are they?)
[14:44:04] <jepler> yes. The first "const" means that the right-hand side argument is not modified, and the second "const" means that the left-hand side argument is not modified
[14:46:42] <SWPadnos> well crap
[14:47:02] <jepler> oh, I forgot the return type "bool" and yes I should have spelled "true" and "false" correctly
[14:47:34] <SWPadnos> sometimes I wonder what the hell chatzilla does with the long things I type
[14:47:52] <SWPadnos> couldn't something like return x==o.x && y==o.y ... work just as well?
[14:48:03] <cradek> bool operator!=(const CANON_POSITION &o) const {
[14:48:03] <cradek> return(x != o.x || y != o.y || z != o.z ||
[14:48:03] <cradek> a != o.a || b != o.b || c != o.c ||
[14:48:03] <cradek> u != o.u || v != o.v || w != o.v);
[14:48:03] <cradek> }
[14:48:05] <SWPadnos> it seems that it should be more efficient, and could hardly be less
[14:48:11] <SWPadnos> right
[14:48:16] <cradek> this is what I wrote, I think it's the same
[14:48:45] <SWPadnos> or do operator== and then != does something like return !(this==o)
[14:48:48] <jepler> the if(..) return; if(..) return; return 0; structure is needed for operator< etc, but not for operator== and operator!=
[14:48:50] <SWPadnos> I'm not sure that works though
[14:49:34] <SWPadnos> this is pretty silly. the std::vector library would be so useful here
[14:50:00] <SWPadnos> not that all of us combined have the time to port canon to that
[14:56:04] <SWPadnos> hmmm. do you get a 'this' pointer in operators?
[15:00:55] <jepler> SWPadnos: yes, they're just like any other member function
[15:01:08] <SWPadnos> ok. I thought so, but didn't remember the details
[15:01:17] <SWPadnos> like "duh, they're functions" :)
[16:53:39] <cradek> hmm, sai and testsuite need some help with UVW
[16:54:00] <cradek> but that's so unrewarding...
[16:54:41] <SWPadnos> he
[16:54:43] <SWPadnos> h
[17:19:50] <SWPadnos> now that's an interesting tracker submission
[17:34:39] <skunkworks> yes.
[17:37:10] <skunkworks> it cannot work good... :)
[17:55:44] <alex_joni> lol
[17:57:02] <SWPadnos> right, because PID doesn't "work good" in the other 127,563,809 places it's used :)
[17:57:40] <alex_joni> * alex_joni needs to read that again
[17:58:08] <SWPadnos> of course, you need a stacked P loop around a PI loop or nothing will work, ever!
[17:58:35] <alex_joni> so using a P around PI is better than using PID around PID
[18:00:16] <SWPadnos> of course. it's not like you could set I or Dgains to 0 or anything
[18:00:40] <alex_joni> well.. then you get a crippled PID which is worse
[18:03:18] <cradek> um, am I missing something? can't a user easily set up these dual loops if he wants?
[18:04:09] <alex_joni> cradek: jmk closed it long ago
[18:04:12] <alex_joni> we were just fooling around
[18:04:39] <alex_joni> bbl
[18:10:08] <jepler> go jmk
[18:11:20] <cradek> I have no doubt dual loops might help - but I don't know how you could get good velocity feedback for the inner loop into hal
[18:15:24] <jepler> speaking of which .. I can't find the thread now, but some user was talking about the velocity report from m5i20 being weird for one servo cycle when position is reset by an index pulse. If the right velocity can't be calculated, I wonder if the next best thing is to hold the velocity estimate steady during a cycle where index-enable went from true -> false
[18:16:43] <cradek> I don't remember seeing that
[18:16:47] <jepler> cradek: it's up to the position feedback system (e.g., encoder) to provide a good velocity estimate. like jmk did in the software 'encoder' module, it involves a high-resolution timestamp along with the last encoder count
[18:17:13] <jepler> you don't remember it, and I can't find it now -- I wonder if it was just a vivid dream then
[18:25:59] <SWPadnos> it's a valid dream though. holding velocity output or calculating it with the latched position+delta from index is a good idea
[19:17:29] <cradek> I don't like those stepgen limits.
[19:17:37] <cradek> I don't see any need for them anymore.
[19:18:14] <skunkworks> you would just do 1.5*axis limits? or such?
[19:18:49] <cradek> well, I don't think they are needed at all, except for the occasional testing
[19:19:03] <cradek> maybe they have some purpose I don't understand, I'm not a stepgen expert
[19:19:16] <cradek> I don't like that the user has to dink with them all the time
[19:19:41] <skunkworks> you think they could be somehow removed from stepgen?
[19:20:02] <cradek> or at least default to inf, and the user could set them lower if he wants
[19:26:15] <jepler> cradek: only by setting stepgen.maxvel does it become possible to give the user the 'unattainable step rate' message
[19:26:37] <jepler> I think that if you don't explicitly set the stepgen.maxvel you do get "the highest possible"
[19:26:50] <jepler> (though with the changes in 2.1 it might give the 'unattainable' message)
[19:26:53] <cradek> hmm
[19:27:42] <cradek> so what happens to a misconfigured machine then? does it not follow the programmed path since some joints may lag behind?
[19:28:09] <jepler> yeah, until you get an ferror
[19:28:35] <cradek> hm.
[23:04:17] <steve_stallings> steve_stallings is now known as steves_logging
[23:26:12] <jmkasunich> Mr. "PID cannot work good" actually had the nerve to resubmit that bug report - completely unchanged, no additional info or anything