Back
[01:08:57] <jmkasunich> SWPadnos: around?
[01:16:22] <jmkasunich> somebody else might have an opinion anyway...
[01:17:08] <jmkasunich> I'm looking for a cheap (<$50) microcontroller board (already built) with a Free compiler, etc for linux
[01:17:39] <jmkasunich> need to count a couple encoders, read some analog signals, generate a bit of pwm or maybe just some dig outs, etc
[01:18:37] <jmkasunich> so far this one is looking good:
http://www.futurlec.com/ET-AVR_Stamp.shtml
[01:18:47] <jmkasunich> but I wondered if anybody here has favorites?
[01:24:11] <jepler> jmkasunich: I recently played with mbmgecvt/mbmgecvt.c: ASCII Pascal program text
[01:24:14] <jepler> er
[01:24:19] <jepler> http://arduino.cc/
[01:24:57] <jepler> atmega128 is a much bigger chip but no faster than the one on arduino boards
[01:25:34] <jepler> gnu gcc for avr is pretty good
[01:26:33] <jmkasunich> I was looking at the arduino
[01:26:42] <jmkasunich> seems to use some strangish language
[01:26:59] <jepler> you can program it in "C" if you like
[01:27:10] <jmkasunich> ah, ok
[01:27:36] <jepler> but yeah part of the arduino gimmick is this little IDE that is easy to install on windows
[01:27:54] <jepler> how fast do you need to read quadrature -- motors, or mpgs?
[01:27:58] <jmkasunich> the prices I saw for arduino were in the $33 range
[01:28:05] <jmkasunich> wheels on a floor
[01:28:21] <jmkasunich> I haven't done all the math yet, but I think its 10's of KHz max
[01:28:27] <jmkasunich> maybe single digit khz
[01:28:43] <jmkasunich> engineering week project
[01:29:36] <skunkworks> a compitition?
[01:30:37] <jmkasunich> yeah
[01:30:50] <jmkasunich> mousetrap powered vehicle with a twist
[01:30:55] <skunkworks> cool - I would not want to be going against you :)
[01:31:02] <jmkasunich> it has to do stuff, not just go
[01:31:28] <jmkasunich> pop two balloons, pick up three washers from the floor, and stop inside a 24" square 50' from the start line
[01:31:47] <jmkasunich> the balloons and washers are NOT on a straight line from the start area to the target square
[01:31:56] <jmkasunich> all forward motion must be powered by the trap
[01:32:06] <jepler> jmkasunich: sounds fun
[01:32:06] <jmkasunich> but you can steer, etc, with other stuff
[01:32:24] <jmkasunich> should be
[01:32:35] <skunkworks> so the trap doesn't have to power the uP - thats good ;)
[01:32:38] <jmkasunich> although it will probably result in late nights and frustration as time runs out
[01:32:48] <jmkasunich> skunkworks: yeah, that would suck
[01:33:06] <jmkasunich> I'm thinking two encoders made of mouse guts, on two unpowered wheels
[01:33:23] <jmkasunich> trap powered front wheel (tricycle), with steering, maybe an RC servo
[01:34:08] <jmkasunich> dead reckoning using the encoders, plus some line following - the course is outlined by black electrical tape, and the balloons are on the border - the washers are in the middle though, so that has to be dead reckoning
[01:34:32] <skunkworks> the washers are known locations I assume?
[01:34:37] <jmkasunich> yes
[01:34:46] <jmkasunich> the course is 8 feet wide
[01:34:54] <jmkasunich> both balloons are along the right edge
[01:35:26] <jmkasunich> the washers are at 3, 4, and 5 feet from that edge, and 25, 30, and 35 feet from the start
[01:35:58] <jmkasunich> the ballons are at IIRC 15 and 45 feet from the start, or something like that
[01:36:19] <skunkworks> it doesn't have to be kinetic does it? you can power the wheels with some sort of gear increaser (string to a gear box of some kind) ?
[01:36:25] <jmkasunich> so you go right, pop a balloon, then head for the middle for washers, then right again for the other balloon, and back to the middle for the end target
[01:36:31] <jmkasunich> yes
[01:36:49] <jmkasunich> speed is worth points, but not lots of points
[01:36:50] <jepler> jmkasunich: the analog isn't particularly fast, but you can start a conversion and continue running code, polling it or trigger an interrupt conversion complete
[01:37:12] <jmkasunich> I'm thinking of using the analog for line sensing
[01:37:28] <jepler> "up to 76.9ksps" at reduced resolution. there's also a penalty for switching channels
[01:37:36] <jepler> maybe that's still plenty fast
[01:37:54] <jmkasunich> yeah, if I can sample each of 3 or 4 sensors at 1KHz that will be plenty
[01:38:12] <jmkasunich> I suspect that even if we go for "blazing speed" the thing will be doing 3-4 feet per second
[01:38:31] <jmkasunich> so thats only 1/20th of an inch per millisecond
[01:38:48] <jepler> (that's atmega168, the chip on arduino; atmega128 may be different but I suspect it's pretty similar)
[01:39:08] <skunkworks> I hope this gets videotaped..
[01:39:39] <jmkasunich> it probably will, but probably won't be posted on a public website
[01:39:51] <jmkasunich> if its posted internally and not huge, I'll try to snag a copy
[01:40:04] <jepler> the atmega128 is same conversion rate. looks like it has differential inputs with 10x and 100x gain, though
[01:40:04] <SWPadnos> I'm back
[01:40:22] <SWPadnos> does the 128 have those, or is that the 1280?
[01:40:44] <jepler> this document says atmega128
[01:41:03] <jmkasunich> the gain is no big deal - I can do op-amps if needed
[01:41:19] <jmkasunich> I'm more interested in your thoughts on tools (compiler, etc) and ease of use
[01:41:25] <SWPadnos> hmmm - I've never noticed that in the '128 manual
[01:41:32] <SWPadnos> gcc for AVR
[01:41:56] <jmkasunich> in the past I've used a laptop running linux+rtapi+hal, but I think that would be too heavy, and also I/O limited
[01:42:30] <jmkasunich> nice dev environment tho - halscope and everything
[01:42:35] <SWPadnos> heh
[01:42:36] <jepler> jmkasunich: sometimes the flash programming can be fiddly
[01:42:57] <jepler> you have an opportunity to brick each chip when you program the fuses to set clock source
[01:43:33] <jmkasunich> hmm
[01:43:44] <jmkasunich> is that an "every time you change everything" kind of thing?
[01:43:46] <SWPadnos> the avr tools package (which I can't remember the name of at the moment) uses the $36 Atmel programmer, which should work reasonably well
[01:43:49] <jmkasunich> change anything I mean
[01:43:50] <jepler> no, only once
[01:44:02] <SWPadnos> if you have a board with a crystal on it, then it's a lot easier to not-brick chips
[01:44:03] <jepler> you can re-flash without setting the fuses again
[01:44:25] <SWPadnos> (and even "bricked" ones can be re-flashed if you apply a clock to the clock pins (except for the AT90S1200A I think)
[01:44:26] <jmkasunich> SWPadnos:
http://www.futurlec.com/ET-AVR_Stamp.shtml - there is a programmer at the bottom of the poage
[01:44:34] <jmkasunich> it has a crystal
[01:44:49] <SWPadnos> there's no clock connection on the standard ISP header though
[01:45:06] <SWPadnos> there's an SPI clock, but not an oscillator connection (that goes to XTAL1 and XTAL2)
[01:45:25] <SWPadnos> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=ATAVRISP2-ND
[01:45:37] <jmkasunich> given that the board has a crystal, and I'm not interested in slow clock power saving modes, I'm not too worried
[01:45:59] <SWPadnos> righto
[01:46:10] <jmkasunich> is that CD linux friendly?
[01:46:46] <SWPadnos> nope
[01:46:55] <SWPadnos> but there's a package if you turn on universe
[01:46:57] <jmkasunich> bzzzzt
[01:46:58] <SWPadnos> search for AVR
[01:47:16] <jmkasunich> I saw lots of AVR stuff in synaptic
[01:47:39] <jmkasunich> I'm liking the $5 programmer that goes with the futurlec stamp
[01:47:42] <SWPadnos> heh
[01:47:46] <jepler> avrispv2 is supported by avrdude, the common avr programming software
[01:47:57] <SWPadnos> right - avrdude, that's the one :)
[01:48:05] <jmkasunich> those prices seem too good to be true - 4.90 for the programmer board, including the cable?
[01:48:12] <jepler> so is "pony prog stk200"
[01:48:35] <jepler> jmkasunich: the programmer is just 2 digital I/O from PC, 1 to PC
[01:48:42] <SWPadnos> jmkasunich, I wouldn't use the futurlec one - it depends on parallel port timings, and as such may (will) change characteristics when you change PCs
[01:48:43] <jepler> jmkasunich: the board is signal conditioning
[01:48:53] <SWPadnos> that's been by experience with dumb programmers anyway
[01:49:06] <jmkasunich> still, a board, a ttl chip, a few resistors, leds, and caps, and a cable, for $5 is cheap
[01:49:12] <jepler> besides the arduino bootloader I've only used dumb programmers .. they're a bit finicky, maybe it's why i brick all my AVRs
[01:49:16] <SWPadnos> the AVRISP has a microcontroller (two, actually), which takes caer of all timing
[01:49:28] <Roguish> jepler: hello. i'm hooking up a 2nd 5i20 and more motors to simulate a 5 axis machine. just like the one in your utube video. could i borrow the gcode that runs in that simulation?
[01:49:55] <SWPadnos> the second micro is the "bootloader" for the one that does programming - it takes over and programs the main chip if you start it up in update mode
[01:50:49] <jepler> Roguish: I believe it's "cone.ngc" from the w_tool_length branch on CVS
[01:50:57] <SWPadnos> jmkasunich, how big (small) does the board need to be?
[01:51:27] <jmkasunich> no real size limits, other than if its as big and heavy as a laptop, I'll use the laptop
[01:51:35] <jmkasunich> smaller is good of course, but not critical
[01:51:40] <SWPadnos> ok
[01:51:51] <SWPadnos> the AVR butterfly is pretty cool - has an LCD even
[01:51:54] <SWPadnos> $21.28
[01:52:14] <SWPadnos> I think that's the one anyway
[01:52:25] <SWPadnos> yep
[01:52:30] <SWPadnos> when do you need this?
[01:52:33] <jmkasunich> I saw that in passing, but it seems to have much more limited I/O - things are dedicated to the sensors on the butterfly instead of availalbe
[01:52:52] <jmkasunich> I probably want to decide what I'm getting in time to order this week, so I have it next week
[01:53:07] <SWPadnos> that's partly true, but the pads around the board can have headers put in there, and they give access to something like 30 or 40 I/Os
[01:53:08] <jmkasunich> the contest is feb 22, but it takes time to come up to speed, and to build the rest of the hardware
[01:53:11] <jepler> you'll have a lot of I/O on the et-avr, less on the arduino
[01:53:29] <SWPadnos> I can bring you a butterfly if you want it
[01:53:36] <Roguish> thank you. found it.
[01:54:01] <jmkasunich> SWPadnos: offer appreciated, but it will be too late - our wicheta weekend is the last weekend before the contest
[01:54:13] <SWPadnos> ah, ok :)
[01:54:37] <jmkasunich> a $20 or $30 board isn't gonna bust my budget anyway
[01:54:39] <SWPadnos> the trouble with AVRs is no quadrature input
[01:54:43] <SWPadnos> nope
[01:54:58] <jmkasunich> yeah, I figure I'll have to count in software, like hal-encoder
[01:55:13] <jmkasunich> can these things handle a 10-20KHz interrupt routine?
[01:55:17] <SWPadnos> yep, but you'll probably want interrupts for that, with tight filtering / counting code
[01:55:28] <SWPadnos> yes, but it really depends on the interrupt code
[01:55:47] <jmkasunich> its supposed to be 16ish mips, so that would be 800 instructions per 20KHz interrupt
[01:56:04] <jmkasunich> assume 30% for the ISR and the rest for the main program
[01:56:08] <jmkasunich> thats 240 instructions
[01:56:10] <jepler> that's 800 to 1600 cycles from interrupt to interrupt .. not an absurdly large budget
[01:56:32] <SWPadnos> yeah, you may need to do that in assembly, and tell the compiler to leave some registers alone
[01:56:43] <jmkasunich> a lut based encoder counter can be done in a few dozen clocks
[01:56:45] <jepler> the interrupt prologue that gcc writes is pretty big, because it stores and restores the whole register file
[01:57:10] <SWPadnos> the AVR is really good for multibyte simple math, unless you have to fetch/store to SRAM
[01:57:20] <jmkasunich> I just remembered that GCC assembly language is this really screwy strange dialect
[01:57:44] <jepler> you mean inline asm? you can also write it in separate ".S" files .. then it's just the operand order that is surprising to DOS refugees
[01:58:05] <jmkasunich> ah, thats good to know
[01:58:19] <jepler> (and I think that with modern gas you can specify intel order if you prefer it)
[01:58:19] <SWPadnos> it'for register operands, it's one cycle per byte of precision for addition and subtraction (in some cases, only one cycle for two bytes), but when you have to load/store, you add two cycles per byte per access, so 8 extra cycles for a 2-byte load then store
[01:58:27] <jmkasunich> its been long enough ago since I did x86 assy that operand order won't matter much
[01:58:42] <SWPadnos> 50-50 shot there ;)
[01:59:34] <jmkasunich> encoder counting is "get current bits, mask in old bits, use as index to lookup a code, and based on that code, either inc, dec, or do nothing with the count
[01:59:49] <jmkasunich> if the code is +1, 0, or -1, the inc/dec/nothing is just a (wide) add
[02:00:17] <SWPadnos> you can be more efficient by using bits to decide whether to increment or decrement
[02:00:29] <SWPadnos> there is a single-cycle add/subtract to /from word instruction
[02:00:29] <jmkasunich> no branch penalties eh?
[02:00:33] <SWPadnos> one cycle
[02:00:49] <SWPadnos> there are also skip instructions though
[02:00:49] <jmkasunich> I've been doing CISC too long I see - I tend to avoid branches
[02:01:06] <SWPadnos> so skip if ... / addw / skip if not blah / sub takes 4 clocks
[02:01:11] <jmkasunich> cool
[02:01:26] <jmkasunich> are bit tests fast, or do you have to mask and such?
[02:01:32] <SWPadnos> I should look up those adiw / sbiw commands - they may be two clocks
[02:01:35] <jepler> bit tests and moves are pretty fast, shifts aren't
[02:01:38] <SWPadnos> sbis r0,7
[02:01:46] <jmkasunich> cool
[02:01:55] <SWPadnos> err - sbrs
[02:01:57] <jepler> one bit shifter, not barrel
[02:02:01] <jmkasunich> definintely want to use assembly, C would make you do ugly things
[02:02:02] <SWPadnos> * SWPadnos whistles in ignorance
[02:02:13] <jmkasunich> if using assy, no shifts would be needed at all
[02:02:21] <SWPadnos> you can do 4-bit "shifts" with the swap instruction, which swaps nibbles
[02:02:49] <jepler> there's also the "t" status bit, for moving bits around
[02:02:53] <SWPadnos> yep
[02:02:55] <jmkasunich> the address for the lut (16 bytes) would be <oldA><oldB><newA><newB>
[02:03:21] <jmkasunich> and the value in the table at that addr would be <newA><newB><inc><dec>
[02:03:29] <jmkasunich> so I just store that looked up value
[02:03:46] <SWPadnos> I bet once you get the table done, and you've pushed/popped pointer registers, and loaded base pointers, and then done the logic, you'd be just as well off with a mask / eor approach
[02:03:47] <jmkasunich> next time, I replace <inc> and <dec> with <newerA> and <newerB>
[02:04:56] <SWPadnos> the Z register (the only one usable to point into flash, which you need for a table lookup) will require two pushes and two pops, plus two immediate loads
[02:05:09] <SWPadnos> that's 4+2+4 cycles for the push/load/pop
[02:05:24] <jmkasunich> is pointing to ram easier/faster?
[02:05:36] <jepler> if you're really cycle counting, you'll want to move the LUT into RAM during startup .. a bit faster to access than program memory
[02:05:42] <jmkasunich> exactly
[02:05:56] <jmkasunich> its got 4K, and I need 16 bytes
[02:05:56] <SWPadnos> you can optimize that by aligning the table on a 256-byte boundary (note that that's a 128-word boundary), and load the low byte with the table offset
[02:06:07] <SWPadnos> no, program rom and SRAM have the same 2-cycle hit
[02:06:12] <SWPadnos> I think
[02:06:17] <SWPadnos> maybe ROM is 3
[02:06:29] <jmkasunich> but there are more registers that can point to sram, right?
[02:06:43] <SWPadnos> ok, it is 3
[02:06:56] <fenn> SWPadnos: what's the difference between RAM and SRAM?
[02:07:06] <SWPadnos> yes, there are 3 that can point to RAM, but there are no two-pointer addressing modes
[02:07:14] <jepler> jmkasunich: yes I think you can index with any of X Y or Z to (S)RAM, while only Z can index for program memory
[02:07:16] <SWPadnos> you can do one pointer + a constant (compile-time constant) offset
[02:07:28] <SWPadnos> fenn, in this case, I'm using them interchangeably
[02:07:34] <SWPadnos> the RAM in an AVR is SRAM
[02:07:52] <SWPadnos> but you can't do Z+Y
[02:08:07] <jepler> yeah .. but just page align the t
[02:08:10] <jepler> able
[02:08:16] <jmkasunich> are X, Y, and Z addressable as bytes?
[02:08:18] <jepler> so that the computed part is the low byte and the constant part is a high byte
[02:08:19] <SWPadnos> so the pointer math is identical, but you do save the cycle because load from ROM is 3 instead of 2 for load from RAM
[02:08:29] <SWPadnos> yes, that's what I said before :)
[02:08:31] <jepler> jmkasunich: yes, X is shorthand for r27:r26
[02:08:38] <SWPadnos> jmkasunich, yes, Z is R30 and R31
[02:08:50] <fenn> * fenn doubts any of this matters for a mouse bot
[02:09:09] <SWPadnos> there's also a W (R24+R25), which can be used for some word functions, but isn't a pointer
[02:09:14] <jmkasunich> I'd put the LUT on a 16 byte boundary, load the high byte of the pointer with a constant, load the low byte with <prev_cycle_lut_value>, stuff in the low two bits with I/O pin values, do the lookup, and store the new value away
[02:09:20] <SWPadnos> such as add immediate to word
[02:10:08] <jmkasunich> since the algorithm only uses the low 4 bits of the LUT value, the high 4 bits can be bits 4-7 of the address
[02:10:13] <SWPadnos> but again, once you do all that, then actually act on the two important bits (do I add, do I subtract), then add the overhead of a possibly extra set of register saves, the advantage of a LUT may be lost
[02:10:34] <SWPadnos> you'd want to zero those, and use a 256-byte boundary
[02:10:39] <jmkasunich> why?
[02:10:54] <SWPadnos> no masking
[02:10:55] <jmkasunich> (using 256 boundary seems unneccessary)
[02:11:07] <jmkasunich> if there are bit writes, I don't need masking
[02:11:14] <SWPadnos> uh
[02:11:37] <SWPadnos> you have two bits (old), which hopefully would be stored with other bits as zero
[02:11:43] <SWPadnos> you or in the two new bits
[02:11:47] <SWPadnos> this is the low byte
[02:12:01] <SWPadnos> with a 16-byte boundary, you also have to or in the high nibble
[02:12:07] <jmkasunich> nope ;-)
[02:12:13] <jmkasunich> not with a clever table
[02:12:48] <SWPadnos> that's probably a lot more clever than necessary, since there's no penalty to using a 256-byte boundary :)
[02:13:04] <SWPadnos> (yes, table values have the high nibble of the table address ...)
[02:13:08] <jmkasunich> perhaps, but clever doesn't cost cycles
[02:13:27] <SWPadnos> it may cost readability. consider the C / ASM code to put that nibble there ;)
[02:13:31] <jmkasunich> and with only 4K of ram, I'd rather not force any large chunks to be wasted
[02:13:39] <SWPadnos> you don't waste anything
[02:13:54] <SWPadnos> unless you need 3.75k+1 byte, and there's nowhere to put the table
[02:14:09] <SWPadnos> it still uses only 16 bytes, it's just got to go somewhere on a boundary
[02:14:29] <jmkasunich> as long as the compiler is smart enough I guess thats true
[02:14:35] <SWPadnos> but I shouldn't say that, as I don't know the linker controls with gcc
[02:14:56] <jmkasunich> I'm thinking back to masm days, when you issue an align directive, it skips ahead to the next address that meets the alignment restrictions
[02:15:21] <SWPadnos> actually, what I do is specifically start the data segment somewhere
[02:15:36] <SWPadnos> and put some things where I want them using .org statemenrs
[02:15:42] <SWPadnos> directives
[02:16:16] <SWPadnos> but I've even seen the (IAR) linker put short code blocks inside the interrupt table, when I didn't use all the vectors
[02:16:35] <jmkasunich> ok - clever tools replace clever programmer
[02:16:36] <SWPadnos> an 8-byte function would get stuck between interrupts 5 numbers apart (so 10 words)
[02:16:38] <SWPadnos> heh
[02:16:53] <SWPadnos> I don't know if there is an align directive - there should be
[02:17:51] <fenn> jmkasunich: i hear the futurlec programmer doesn't work with standard pinouts - you need a patch or something (it might be included in avrdude now though)
[02:18:24] <jmkasunich> fenn: it sounds like I might want to get a better programmer
[02:18:49] <SWPadnos> you'd have to build a crossover cable to get that board to work with the "standard" programming pinout though
[02:19:01] <SWPadnos> that board being the ET-AVR
[02:19:12] <fenn> oh, a proprietary header, even better
[02:19:23] <SWPadnos> well, the header matches the programmer, no doubt
[02:19:44] <SWPadnos> that could be standard, but with the parallel port pin conections changed
[02:19:56] <jmkasunich> you are talking about the programming header on the ET-AVR, right?
[02:20:00] <SWPadnos> yes
[02:20:13] <jmkasunich> the cable from there to parport will probably be handwired anyway, so that doesn't really matter
[02:20:25] <jmkasunich> I'm more concerned about timing sensitivity
[02:20:31] <SWPadnos> if fenn is correct that people have to change things to get the futurlec programmer to work, then that means that there are two places where the screwup can be
[02:20:47] <jmkasunich> * jmkasunich fires up synaptic and installs everything with AVR in the description
[02:20:49] <SWPadnos> one is the parport to programmer connection, the other is the programmer to target connection
[02:21:24] <SWPadnos> I've had tons of bad luck with PIC and AVR programmers that used the parport, and almost none with serial and USB programmers
[02:21:30] <SWPadnos> so it may not be luck ;)
[02:22:36] <jmkasunich> maybe I want a better programmer - but I kinda like the futurlec stamp
[02:23:26] <SWPadnos> did you notice their development board for that?
[02:23:32] <SWPadnos> http://www.futurlec.com/ET-AVR_Stamp_Board.shtml
[02:24:25] <jmkasunich> I saw it - I've never been fond of solderless breadboards, so I kind of skipped over it
[02:24:43] <SWPadnos> heh - it's got other stuff, like lights and buttons, that could be useful
[02:25:04] <jmkasunich> I can do lights and buttons
[02:25:11] <SWPadnos> one thing I don't like is that I haven't been able to find the datasheet for the ET-AVR, so it's not possible to check pinouts
[02:25:12] <jepler> there's also a solder-able set of holes under the solderless breadboard
[02:25:21] <jmkasunich> I figure I'll be doing a perfboard anyway, with signal conditioning and drive electronics
[02:26:02] <fenn> oh btw futurlec takes months to deliver sometimes
[02:26:11] <jepler> http://www.ett.co.th/download/03AVR/03A12-00279/ET-AVR%20START%20KIT%20V1.0%20%20EXP_Schemetic.pdf
[02:26:34] <SWPadnos> of course - no docs from futurlec, but from the manufacturer
[02:26:40] <SWPadnos> deja vu again
[02:27:05] <jmkasunich> fenn: well, that would be the nail in the coffin
[02:27:20] <SWPadnos> hmmm
[02:27:57] <fenn> futurlec has great prices but that part is certainly a project killer
[02:28:23] <fenn> they have to ship from thailand to australia to us
[02:28:36] <jmkasunich> jepler: the schematic you posted is the breadboard, not the stamp itself
[02:28:41] <jepler> jmkasunich: oh oops
[02:28:49] <jepler> I didn't look too close at what I found :(
[02:28:52] <jmkasunich> still handy
[02:28:53] <SWPadnos> yeah - I'm looking for the stamp now :)
[02:29:09] <SWPadnos> but I only saw the jtag connector, not the normal SPI programming connector
[02:29:39] <jepler> if you want a "big" AVR, sparkfun has
http://www.sparkfun.com/commerce/product_info.php?products_id=35
[02:30:41] <SWPadnos> jmkasunich, I missed your actual I/O needs - what are they again?
[02:31:37] <fenn> hah you didnt expect specifications did you
[02:31:54] <jmkasunich> 2 encoders, a few analogs (photocells or such for detecting black tape on the floor), and a few digital outs (either RC servo waveform, or PWM, for a steering servo or motor), plus a couple more digital outs for misc, like maybe a solenoid to make the thing stop
[02:31:56] <SWPadnos> well, no, not really ;)
[02:32:13] <SWPadnos> hmmm. ok
[02:32:36] <SWPadnos> I have a couple of boards I've designed that could do that, but I'm not sure I put chips with A/D on them
[02:32:54] <jmkasunich> I see that futurlec is based in AU, and has no phone number so I can't call and say "I want this only if its in stock in the USA"
[02:33:02] <jmkasunich> so they suddenly are very un-interesting
[02:33:17] <SWPadnos> they've got things like transistor outputs (for solenoids), terminal strips for wiring, switching supplies for wide-range DC supply etc
[02:33:40] <jmkasunich> SWPadnos: I'd rather have something cheap and off-the-shelf replaceable
[02:33:51] <jmkasunich> especially if it turns out to be a fun toy, I might want more later
[02:33:54] <SWPadnos> well, you can't beat the price, if I send you one or two fro free ;)
[02:33:59] <SWPadnos> get you hooked ;)
[02:34:22] <SWPadnos> oh, and a serial port on one of them :)
[02:35:28] <jmkasunich> what is AT90CAN128?
[02:35:41] <SWPadnos> hmmm. that's an interesting point - do you need comms with a PC so you can tell it how far to go or whatever?
[02:35:48] <SWPadnos> it's got a CAN controller in it?
[02:36:11] <jmkasunich> I need to be able to do some kind of debug and development, so a PC would be handy
[02:36:39] <SWPadnos> yep - it's more or less a 128 + CAN controller
[02:37:05] <SWPadnos> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=ATSTK500-ND
[02:37:35] <SWPadnos> it's $83, but it has all I/Os available, buttons and lights, connectors for all ports, and the programmer is built in (as well as a DC supply)
[02:37:52] <SWPadnos> I think it comes with 2 processors as well, maybe megas, maybe not
[02:38:04] <SWPadnos> damn. those were $300 when I bought my first one
[02:38:12] <jmkasunich> sockets for dips...
[02:38:31] <jmkasunich> I'd rather have something stampish
[02:38:49] <jmkasunich> buttons are a waste of space - I will need to wire MY stuff, not their stuff, to the I/Os
[02:39:07] <SWPadnos> all I/Os are connected via 10-pin headers that have 8 bits + power and ground
[02:39:19] <SWPadnos> you need to cable to the buttons and lights, else they're just on headers
[02:39:41] <jmkasunich> so I need cables to go to my perfboard(s) instead of just plugging it onto my perfboard
[02:40:17] <SWPadnos> yes, or you can plug the perfboard into the expansion headers - those have all the I/Os on them
[02:40:30] <SWPadnos> but the perfboard would need to be bigger
[02:42:06] <jmkasunich> that sparkfun board jepler found looks nice
[02:42:17] <SWPadnos> ethernut ;)
[02:42:26] <SWPadnos> then you can fiddle with RTNet too
[02:42:37] <jmkasunich> $37.95, 1.85" square, all I/Os accessible, crystal oscillator onboard
[02:43:42] <jmkasunich> ethernut looks interesting - haven't found prices yet
[02:43:46] <SWPadnos> it looks like they use the 6-pin programming header
[02:44:25] <SWPadnos> I wonder how long it would take to get an Arduino
[02:45:39] <SWPadnos> hmmm. the arduino may not have enough I/Os
[02:46:53] <jmkasunich> looks like a 28 pin dip instead of the plcc or whetever that other package is
[02:47:44] <SWPadnos> yes - 23 I/Os max
[02:47:54] <SWPadnos> including analog comparator and A/D channels, and USB/serial
[02:48:57] <SWPadnos> bummer. I used the ATMEGA162 on both of these boards, so no A/D
[02:49:02] <SWPadnos> just a single comparator
[02:49:20] <jmkasunich> the sparkfun board is nice and simple - they have schematics and such - it uses the Atmel in circuit programmer pinout
[02:49:23] <jepler> I think there are 20 usable I/O on the arduino
[02:53:43] <jmkasunich> jepler: where did you get your arduino?
[02:53:48] <jepler> jmkasunich: sparkfun
[02:53:56] <jmkasunich> sparkfun has them listed at 34.95, but out of stock at the moment
[02:54:03] <jepler> jmkasunich: heck
[02:54:57] <jmkasunich> to be honest, for $3 more the mega128 board seems nicer
[02:55:13] <jepler> there's also the "stamp" version of it, a few bucks more, smaller, no USB ..
http://www.sparkfun.com/commerce/product_info.php?products_id=8164#
[02:55:14] <jmkasunich> no USB or anything though
[02:55:18] <jmkasunich> saw that
[02:55:30] <jmkasunich> still low I/O count
[02:55:50] <jepler> yeah
[02:55:53] <jmkasunich> oh, it says it uses the mega168, IIRC swp said that has no A/D
[02:56:11] <jepler> no that was 162 .. there are too many models of avr
[02:56:17] <jepler> 168 has 6 A/D
[02:56:26] <jmkasunich> oh, ok
[02:58:00] <SWPadnos> right -0 sorry for the extra part number in there
[02:58:43] <SWPadnos> http://www.sparkfun.com/commerce/product_info.php?products_id=31
[02:59:16] <SWPadnos> just add chip ;)
[02:59:34] <jmkasunich> http://www.sparkfun.com/commerce/product_info.php?products_id=35
[02:59:40] <jmkasunich> chip included and twice as fast
[02:59:56] <jmkasunich> twice as much money too....
[03:00:09] <SWPadnos> oh - I have dozens of those (or something almost identical to that)
[03:00:19] <SWPadnos> 12.288MHz crystal though, I think
[03:00:28] <fenn> atmega32 is the same speed as 128, just less ram and program space
[03:00:37] <fenn> (and it comes in DIP)
[03:00:46] <SWPadnos> wow - bummer. those would be much much less expensive for that product
[03:01:09] <fenn> i think almost all avr's are 20 mips now
[03:01:22] <SWPadnos> megas and newer tinys are, I think
[03:02:04] <jmkasunich> the actual chips are pretty cheap - $4.93 for a mega168
[03:02:13] <SWPadnos> hmmm. nope - there are a bunch, but nowhere near all of them
[03:02:24] <fenn> well, the new ones
[03:02:51] <SWPadnos> hmmm. nothing with more than 64KBytes of flash can go to 20 MHz
[03:02:56] <jmkasunich> if a 28 pinner would be big enough, this is hard to beat:
http://www.sparkfun.com/commerce/product_info.php?products_id=29
[03:03:05] <jmkasunich> plus a $5 chip
[03:03:22] <SWPadnos> that's the same as the one I linked to, except for a smaller chip
[03:03:39] <jmkasunich> ah
[03:03:50] <SWPadnos> same price even
[03:04:12] <jmkasunich> the chip for that is $8.80
[03:04:17] <fenn> newer chips have more flexibility with interrupts too
[03:05:01] <jmkasunich> I wonder why those boards have 8MHz oscillators? the chips can do 16
[03:05:20] <fenn> there is a clock multiplier
[03:05:25] <SWPadnos> all chips can use the 8 MHz osc, even the low voltage ones ??
[03:05:40] <SWPadnos> uh - I don't think so. there is a divider in some of the chips
[03:05:44] <fenn> all chips are low voltage, just the ones marked low voltage have been tested to function correctly at low voltage
[03:06:02] <SWPadnos> and the LV ones aren't specced to run at the higher frequencies
[03:06:25] <fenn> when operating at low voltage
[03:06:36] <fenn> uh, i might be wrong about the multiplier
[03:07:13] <SWPadnos> well, the specs for a given chip are generally either low voltage and low freq, or high voltage and high freq
[03:07:34] <SWPadnos> but they're probably the same chips, so you could likely run the LV chips on HV at HF :)
[03:07:54] <fenn> right
[03:08:08] <jmkasunich> all that matters is that I'd find myself looking for a source of 16MHz crystals if I bought one of those boards
[03:08:22] <fenn> jmkasunich: you dont need the crystal actually
[03:08:29] <SWPadnos> you do for 16 MHz
[03:08:33] <fenn> hmm.. ok
[03:08:34] <SWPadnos> the internal osc is either 1 MHz or 8 MHz
[03:09:13] <fenn> woah did the datasheets always have hyperlinks in them?
[03:09:38] <SWPadnos> heh - yes, for internal links. not as much for web links
[03:09:57] <SWPadnos> (but I started with the AVR slightly before it hit the general market, so they may have been there "forever")
[03:10:39] <jmkasunich> gonna want a few of these:
http://www.sparkfun.com/commerce/product_info.php?products_id=8181
[03:10:51] <jmkasunich> I think whatever I get I'll get it from sparkfun so I only need to place one order
[03:13:19] <SWPadnos> I still think the butterfly for $21.28 is a good deal. there's already a phototransistor on it, and all the I/O is available if you want it
[03:13:44] <jmkasunich> I need at least 3 phototransistors, and I need to mount them on the vehicle, not on the board
[03:14:11] <jmkasunich> but I should take a closer look at the butterfly anyway
[03:15:08] <SWPadnos> there are 3 10-pin headers, which I'm sure are 3 I/O ports
[03:15:13] <SWPadnos> one is probably the one with A/Ds on it
[03:15:25] <SWPadnos> (they're not labeled on the baord, and I don't have the pdf open at the moment)
[03:16:52] <fenn> why is it the RC oscillator can do 8MHz but not 16MHz
[03:17:02] <jmkasunich> tolerances probably
[03:17:04] <SWPadnos> dunno
[03:17:11] <SWPadnos> it may also be a low voltage thing
[03:20:08] <jmkasunich> damn - he doesn't have the "I tinker, therefore I am" tee-shirts anymore
[03:20:17] <SWPadnos> heh
[03:20:19] <jmkasunich> does have this one tho:
http://www.docsmachine.com/tees/teegraphics/tee16.jpg
[03:20:24] <SWPadnos> I like the way a friend of mine put it:
[03:20:33] <SWPadnos> "I'm thinking about it, therefore I might be"
[03:51:59] <CIA-15> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: fix the extents sometimes not updating right away when the origin changes
[03:54:08] <CIA-15> EMC: 03cradek 07v2_2_branch * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: fix the extents sometimes not updating right away when the origin changes
[04:00:28] <jmkasunich> sparkfun order placed - got the 128 board, some sensors, and a parport programming cable
[06:18:10] <CIA-15> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/ (m7i43_hm2.comp m7i43_hm2.h):
[06:18:10] <CIA-15> EMC: This adds very basic support for steppers.
[06:18:10] <CIA-15> EMC: Also: improved docs and misc bug squishes
[06:19:58] <seb_kuzminsky> steppers are weird
[06:28:08] <SWPadnos> heh. what leads you to that conclusion?
[06:29:02] <seb_kuzminsky> i'd never really used steppers before this week... It's wierd to have a P controller in the device driver.
[06:29:21] <seb_kuzminsky> also it's wierd how they get all hot just sitting there not moving
[06:29:30] <SWPadnos> hmmm. what kind of driver?
[06:29:44] <SWPadnos> motor drive that is, not the softwae/FPGA with P in it
[06:30:21] <seb_kuzminsky> It's a Lin Engineering stepper with integrated driver
[06:30:31] <seb_kuzminsky> surplus special...
[06:30:41] <SWPadnos> oh, interesting
[06:30:54] <SWPadnos> I think I've seen some like that advertised
[06:31:09] <seb_kuzminsky> http://www.linengineering.com//site/products/silverpakD.html
[06:33:35] <SWPadnos> do you have current reduction turned on?
[06:34:08] <SWPadnos> it's only 33% (reduction, though they could mean down to 33%)
[06:36:22] <seb_kuzminsky> ehm, i think so but i'm not sure...
[06:38:19] <seb_kuzminsky> i think the driver uses reduced holding current by default, unless you special order a motor without it
[06:38:27] <seb_kuzminsky> I'm not sure how these motors are configured...
[06:39:06] <seb_kuzminsky> do velocity-mode steppers generally get hooked up to an external PID controller?
[06:39:22] <SWPadnos> it says "Selectable Current Reduction of 33%"
[06:39:31] <SWPadnos> well, that's an interesting question :)
[06:39:42] <SWPadnos> that's how Jon Elson's USC works
[06:40:12] <SWPadnos> the problem is that steppers have the wrong torque response (compared to servos)
[06:40:24] <SWPadnos> if a servo lags, you tell it to try harder
[06:40:45] <seb_kuzminsky> steppers have high torque at low speed, and torque falls off as rpm increases, right?
[06:40:46] <SWPadnos> if a stepper lags, you need to slow it down (and you have to detect the lag before a stall occurs or it's over anyway)
[06:40:50] <SWPadnos> yes
[06:41:01] <seb_kuzminsky> while servos have constant torque up to their nominal speed?
[06:41:10] <SWPadnos> yes, and even more for brief periods
[06:41:20] <seb_kuzminsky> how do you detect stepper lagging? with an encoder?
[06:41:20] <SWPadnos> usually the peak torque is 4-6x the continuous
[06:41:29] <SWPadnos> with a special driver and an encoder
[06:41:46] <SWPadnos> Mariss (of Geckodrive) is working on just such a beast
[06:42:52] <seb_kuzminsky> how do you get a servo to give up that extra 4-6x of torque? say the motor bogs down, speed falls, the controller detects the lag and increases pwm, which increases current to the motor and it gives more torque?
[06:43:08] <SWPadnos> yep, that's how it would work
[06:43:21] <SWPadnos> it's a little different if you're using step-to-servo drives such as geckos though
[06:43:26] <seb_kuzminsky> right
[06:43:32] <seb_kuzminsky> then the pid happens on the gecko
[06:44:00] <SWPadnos> you need to set the current limits correctly for servos, they'll destroy themselves if you ask them to and the drives aren't limited
[06:44:10] <SWPadnos> yes, though they have a fixed I term
[06:44:40] <SWPadnos> you can only adjust P and D (and I'm not sure they're quite P and D - they're called proportional and damping)
[06:45:06] <seb_kuzminsky> brushed dc motors have resistance in the windings, doesnt that limit the current for you?
[06:45:29] <SWPadnos> not enough
[06:45:32] <seb_kuzminsky> if the ps and the motor are matched, shouldnt it "just work"
[06:45:46] <SWPadnos> most DC motors have 1 ohm or so of resistance, less for smaller motors
[06:45:52] <SWPadnos> no
[06:46:18] <SWPadnos> if all the power went into winding resistance (and out as heat), there would be none left to output fromthe shaft as mechanical energy
[06:46:42] <seb_kuzminsky> that's a "stall", right?
[06:47:26] <SWPadnos> err - no, for a DC motor, a stall is when the amount of current (torque) on the motor can't overcome the load, so it stops
[06:47:45] <seb_kuzminsky> one of the little servos i'm testing with has a "stall current" of 2.5 A (19V, 7.5 Ohm winding resistance)
[06:48:03] <SWPadnos> oh, maybe that is it then
[06:48:34] <seb_kuzminsky> if you're givign it full current and its not moving, the only place the energy can go is into resistive heat i think
[06:48:38] <SWPadnos> 7.5 ohms is very high. is that a really small and really high speed motor?
[06:48:45] <SWPadnos> yes, that's true
[06:49:27] <seb_kuzminsky> yeah, 7800 rpm, about 1" dia & 2" long
[06:49:39] <SWPadnos> ok, so it has no torque :)
[06:49:45] <seb_kuzminsky> it's similar to the servos cradek has on his sherline lathe
[06:49:48] <SWPadnos> 7800 no load?
[06:50:08] <seb_kuzminsky> right, no load
[06:50:20] <seb_kuzminsky> 1.6 oz*in cont torque, 7.some peak :-)
[06:50:43] <seb_kuzminsky> needs like a 100:1 belt drive :-)
[06:50:57] <SWPadnos> hmmm
[06:51:23] <SWPadnos> 19/7.5 ~= 2.5, but if all the power is going into heat, then the rotor shouldn't spin
[06:51:55] <SWPadnos> also, the back emf gets subtracted from the supply voltage before calculating resistive losses
[06:52:05] <SWPadnos> so that makes no sense to me
[06:52:14] <SWPadnos> (but then again, I'm not a motor expert :) )
[06:52:15] <seb_kuzminsky> you only get back emf if the motor's spinning i think
[06:53:06] <seb_kuzminsky> the back emf rating of a brushed dc motor is measured in V/rpm
[06:53:16] <SWPadnos> but at no load, 7800RPM certainly would qualify as spinning, no?
[06:53:34] <SWPadnos> sure, or more commonly V/kRPM
[06:53:39] <seb_kuzminsky> at no load, the motor is spinning at 7800 rpm, big back emf, low current
[06:53:46] <SWPadnos> (or volts/rad/sec)
[06:54:03] <seb_kuzminsky> now fight the motor, rpm drops, back emf drops, current goes up, torque goes up
[06:54:06] <SWPadnos> ok, but you said 2.5A, 7.5ohm, 19V stall
[06:54:39] <SWPadnos> 2.5*7.5 is 18.5V in resistive losses, plus 1/2V for back EMF, which isn't computing in my brain
[06:54:45] <SWPadnos> though it's late, so it could be me
[06:54:56] <seb_kuzminsky> yes, 2.5A at stall, which is 0 rpm, so no back emf
[06:55:09] <SWPadnos> ok, so those were separate specs ;)
[06:55:24] <seb_kuzminsky> no
[06:55:37] <seb_kuzminsky> 7.5 Ohm is the winding resistance, no matter the shaft speed
[06:55:44] <seb_kuzminsky> 19.1 V is the motor's rated voltage
[06:55:50] <seb_kuzminsky> 7800 rpm is the no-load speed
[06:55:59] <seb_kuzminsky> 2.5 A is the stall current
[06:56:15] <seb_kuzminsky> the 7800 rpm and 2.5 A are mutually exclusive, but the voltage and resistance dont change
[06:56:18] <SWPadnos> righto
[06:56:20] <SWPadnos> sure
[06:56:44] <seb_kuzminsky> at no load, there's very nearly 19 V of back emf, and the motor is just sipping current
[06:57:09] <SWPadnos> right - that's why I said they're spearate specs
[06:57:34] <SWPadnos> I guess I'd need to (a) look it up or (b) go to sleep to know what the definition of stall is for a DC motor :)
[06:57:34] <seb_kuzminsky> ok i think we mean the same thing now :-)
[06:57:44] <SWPadnos> yep
[06:58:19] <seb_kuzminsky> oh yeah, this conversation started when you said you need current limiting on servos
[06:58:29] <SWPadnos> yep
[06:58:39] <seb_kuzminsky> my little toy servo doesnt need it, because 2.5 A is well within the range of my power supply
[06:58:44] <seb_kuzminsky> but big servos...
[06:59:06] <seb_kuzminsky> have much lower resistance, around 1 Ohm you said, which would pop my ps and/or my amp...
[06:59:07] <seb_kuzminsky> I see
[06:59:24] <SWPadnos> sure, and you can't overcurrent yours (unless stall is peak, and you're only supposed to use ~0.6A continuous)
[06:59:37] <seb_kuzminsky> i think that's the case
[06:59:42] <SWPadnos> well, that is if you use a 19V supply
[07:00:00] <seb_kuzminsky> 24V, but what's 25% overvoltage between friends?
[07:00:21] <SWPadnos> hmmm. about 50% more heat? :)
[07:00:59] <seb_kuzminsky> ok off to bed for me
[07:01:29] <seb_kuzminsky> later
[07:01:34] <SWPadnos> night night. cool stuff with the 7i43
[07:01:43] <seb_kuzminsky> :-)
[14:53:37] <skunkworks605> skunkworks605 is now known as skunkworks_
[15:01:57] <jepler> I'm going to e-mail the developers list as well, but is anybody still actively working on an outstanding bug for 2.2.3? if not, I might try to get a release out this weekend.
[15:03:01] <cradek> I got all of mine done
[15:03:25] <cradek> (except O-repeat not working)
[16:52:09] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[21:33:46] <SWPadnos> interesting. I have two (probably unrelated) problems trying to boot the liveCD (version 2.2.2-1 I believe)
[21:33:58] <SWPadnos> first, it doesn't boot - some PCI resource allocation problem. I
[21:34:17] <SWPadnos> I can fiddle with BIOS / boot options to fix that
[21:34:59] <SWPadnos> second is that just before the boot menu, there's an error message saying (something like) "error: unrecognized keyword in config file"
[21:36:03] <cradek> bad download? bad cd?
[21:36:05] <SWPadnos> this is only visible for a half second or so, so it's entirely possible that I'm seeing it only because this is an LCD display and mobile graphics card, so there may be no re-sync going on (like with a CRT when you change graphics modes)
[21:36:24] <SWPadnos> no, I don't think so. I've burned from this image and booted successfully several times
[21:36:28] <SWPadnos> I'm running a CD check right now
[21:36:59] <SWPadnos> well, no I'm not, because it needs to boot to do that
[21:37:10] <SWPadnos> I did verify with k3b when I burned it though
[21:37:46] <skunkworks_> I have not seen that.. I have booted the live cd on quite a bit of hardware. A lot of the newer hardware I have to set up the video manually
[21:37:47] <jepler> some systems have broken PCI devices when CONFIG_PNPACPI is turned off -- for example, on one of my laptops this kills the network interfaces
[21:38:14] <jepler> all ACPI is turned off in our kernel, because some ACPI is power-management-related or latency killer..
[21:38:21] <SWPadnos> right
[21:38:45] <SWPadnos> I've tried booting in safe graphics mode, and separately with noacpi and nolapic boot params, neither worked
[21:39:37] <jepler> If you remove 'quiet' from the boot line do you get any additional information?
[21:39:42] <SWPadnos> no
[21:39:50] <SWPadnos> oh, maybe - one sec
[21:40:01] <SWPadnos> I was thinking of the change to nosplash :)
[21:40:24] <jepler> I'm not 100% sure what option I mean
[21:40:31] <jepler> I think in grub it's to remove 'quiet'
[21:40:39] <jepler> I think it would be the same for the live CD though
[21:41:05] <SWPadnos> yes, there are two options, I had confused the one you asked about with the one I had actually changed
[21:42:14] <SWPadnos> oh, there's a suggestion to ty the option "pci=biosirq" in the extra messages
[21:43:22] <jepler> what finally fails -- can't mount the cdrom?
[21:43:41] <jepler> btw, have you booted regular dapper livecd on there?
[21:43:59] <SWPadnos> the system fails to boot, at a text screen
[21:44:35] <SWPadnos> I'm not sure I have booted normal dapper, I have certainly booted 7.10 (that's what's installed on the HD)
[21:45:34] <SWPadnos> without quiet, it happens to stop after the list of registered schedulers, but I think those aren't the problem
[21:46:48] <jepler> not that it helps, but here are my dmesg lines after that:
http://pastebin.ca/872629 (previous line was 'io scheduler cfq registered")
[21:46:51] <jepler> s/"/'
[21:47:35] <jepler> (that's not a magma kernel though, it's ubuntu generic)
[21:49:02] <SWPadnos> dunno - I'd assume that the liveCD wouldn't write to the hard disk, and I can't get to a prompt since the liveCD boot never finishes
[21:49:31] <SWPadnos> I'll try "single" to see if it's a graphics thing
[21:50:15] <SWPadnos> nope
[21:50:44] <cradek> the live cd will use swap it finds
[21:51:05] <SWPadnos> trying the stock CD now
[21:52:30] <SWPadnos> damn - that's one unbalanced CD
[21:52:39] <SWPadnos> sounds like a milling machine
[21:52:47] <SWPadnos> but it boots
[21:57:37] <jepler> hmph
[21:57:44] <jepler> oh well, I guess you won't be running emc on that machine anytime soon
[21:58:13] <SWPadnos> heh - it's my new laptop - I just wanted to demo stuff
[21:58:37] <cradek> you don't need realtime for that
[21:58:44] <SWPadnos> true
[21:59:18] <SWPadnos> it seemed like the easiest way, since I don't have any EMC stuff on this machine yet
[22:01:19] <jepler> ooh 4pm
[22:01:23] <jepler> time to gtfooo
[22:01:51] <SWPadnos> hmmm. this is the laptop I plan to bring to Wichita - any suggestions on the best way to get it "emc2-able"?
[22:02:06] <SWPadnos> considering that it's a 7.10 SMP 64-bit install at the moment ;)
[22:02:52] <jepler> sim builds on 7.10 .. debian/configure sim then look at debian/control and see what packages are listed there
[22:02:54] <cradek> doesn't sim just work?
[22:03:02] <jepler> ignore the doc ones (e.g., latex, lyx) and install the rest
[22:03:12] <SWPadnos> sim probably does work - I admit I haven't ttried it yet
[22:03:16] <jepler> if it doesn't work, I want to hear about it
[22:03:20] <SWPadnos> will do
[22:03:38] <SWPadnos> I generally prefer to work on non-sim for developpment though, because I usually work on the lower-level stuff :)
[22:03:47] <jepler> bah whatever you say
[22:03:57] <SWPadnos> heh
[22:03:58] <jepler> you can't plug a mesa card into it
[22:04:06] <SWPadnos> USB 7i43 :P
[22:04:07] <alex_joni> actually you can
[22:04:18] <alex_joni> but it's expensive as hell
[22:04:21] <SWPadnos> it has expresscard though, no pcmcia
[22:04:33] <alex_joni> ah, so only pci-x then
[22:04:44] <alex_joni> pci-x <-> pci bridge?
[22:04:44] <cradek> seems that's a grossly wrong machine to use then... :-/
[22:04:52] <jepler> you can develop non-driver comps, though...
[22:04:56] <jepler> that's my point
[22:05:08] <jepler> anyway .. leaving now
[22:05:19] <alex_joni> see you
[22:05:33] <SWPadnos> heh
[22:05:50] <SWPadnos> yes, I know it's not great for RT or driver development
[22:05:51] <alex_joni> hmm, working tomorrow.. for a change
[22:05:55] <jepler> btw seb_k e-mailed me and says he wants to put the 7i43 driver into 2.2.3 so that may lengthen the timeline a bit
[22:05:57] <SWPadnos> though I should be able to do modbus
[22:06:10] <alex_joni> SWPadnos: maybe installing it, and then pulling in the kernel will make it work
[22:06:24] <skunkworks_> heh - We have a note pad with
http://www.emcins.com/ on it.
[22:06:31] <alex_joni> there's still a chance the live-cd works differently than an installed system
[22:08:07] <SWPadnos> well, it certainly doesn't boot
[22:08:53] <alex_joni> oh, ok then :)
[22:09:15] <alex_joni> * alex_joni hates 6MB changelogs
[22:09:22] <alex_joni> how are you supposed to read them?
[22:09:32] <SWPadnos> dunno
[22:09:39] <SWPadnos> look for stuff you're interested in?
[22:10:04] <alex_joni> err.. what if I don't know what I'm looking for?
[22:12:21] <SWPadnos> then you have to read the whole thing!
[22:12:41] <SWPadnos> time for dinner - bbl
