Back
[11:37:23] <jepler> I have a terrible, hackish idea to double the step rate at a given base_period. The parport would get a new function, which sets or clears some configurable bits (data = data & ~CLEAR | SET). You'd arrange the base_thread functions so that enough time elapses from the .write to the .clear that the drive latches the step pulse. 1uS is long enough for l297, xylotex, gecko, so in most cases you could just run the functions back-to-back if t
[11:37:54] <jepler> of course, stepgen would have to be modified so that it could have "step" high every period instead of every other period
[11:41:27] <alex_joni> some of that got cut off I think
[11:42:44] <alex_joni> basicly you're saying that 2 functions per base_period (one to set the pulse, one to clear if needed) ?
[11:44:01] <jepler> yes
[11:44:08] <jepler> You'd arrange the base_thread functions so that enough time elapses from the .write to the .clear that the drive latches the step pulse.
[11:44:19] <jepler> 1uS is long enough for l297, xylotex, gecko, so in most cases you could just run the functions back-to-back if that "1uS per I/O" rule is right.
[11:44:26] <jepler> time to drive to work, bbl
[11:44:44] <alex_joni> ok
[12:03:50] <jepler> hi from the office
[12:04:14] <alex_joni> hey :)
[12:04:22] <alex_joni> wanted to ask you something.. but I forgot :(
[12:04:27] <alex_joni> getting old it seems
[12:06:42] <jepler> oh well
[12:29:32] <SWPadnos> jepler - you can just run the stepgen function twice per fast thread
[12:29:41] <SWPadnos> err - make_pulses
[12:30:37] <SWPadnos> but it probably is better to have a single "make_pulses" at the start, and a "clear_pulses" at the end of the thread
[12:36:47] <jepler> by having hal_parport know about setting/clearing bits I was perhaps overthinking the efficiency issue
[12:37:07] <jepler> luckily I don't have any hardware that needs a high step rate so it is just daydreaming...
[12:38:08] <jepler> hoo boy have I screwed things up at work this morning
[12:38:15] <SWPadnos> yay!
[12:38:18] <SWPadnos> oops - boo!
[12:38:20] <jepler> hint: if you ever type 'find .... | xargs rm' you'll regret it
[12:38:32] <jepler> so just .. don't
[12:38:32] <SWPadnos> heh
[12:38:41] <SWPadnos> like df in fdisk, huh? :)
[12:38:45] <jepler> could be
[12:39:05] <SWPadnos> it's disk free, as an imperative
[12:39:21] <jepler> I think my favorite is still the time I removed '/lib/ld.so' by accident
[12:39:30] <SWPadnos> urk
[13:01:45] <alex_joni> oopsy
[13:01:46] <alex_joni> :)
[13:44:19] <cradek> hi all
[13:44:24] <SWPadnos> hiya
[13:45:23] <cradek> Tape Used (%) 103.7
[13:45:41] <SWPadnos> I usually like to stop at or below 100%
[13:45:58] <cradek> I agree that would seem like a superior algorithm
[13:46:10] <SWPadnos> unless they mis-count compressed data
[13:46:37] <cradek> no I think it actually sometimes writes a little more than the declared tape size
[13:46:50] <cradek> I just declare it a little low
[13:47:06] <SWPadnos> that helps. what kind of tape?
[13:47:18] <cradek> just DLT
[13:48:24] <SWPadnos> ok - not one of the "modern" ones with the length stored in a chip in the cart
[13:48:36] <SWPadnos> (and parts of the catalog, sometimes)
[13:48:45] <cradek> nope
[13:48:56] <cradek> I have barcodes on them, that's as fancy as it gets
[13:49:01] <alex_joni> heh..
[13:49:08] <alex_joni> * alex_joni saw a printer recently..
[13:49:11] <SWPadnos> you can read barcode?
[13:49:12] <cradek> storing a catalog would be pretty neat.
[13:49:21] <alex_joni> one of those that phones home for new cartriges
[13:49:25] <cradek> the changer reads them
[13:49:33] <SWPadnos> AIT does that - not the ful catalog, but at least the positions of any used segments
[13:49:38] <SWPadnos> full
[13:51:42] <cradek> it would be nice to be able to reliably (safely) append to a tape
[13:52:04] <SWPadnos> that's kinda necessary, IMO
[13:52:11] <SWPadnos> not just "nice"
[13:54:26] <cradek> not really, you just get used to using one tape per run
[13:54:58] <cradek> software that smartly decides how to fill it (up to 103.7%) is pretty useful then
[13:55:23] <alex_joni> wonder where it'll stop ;)
[15:09:19] <alex_joni> can I just do something like this? fscanf(foo, "%d%d%d%d", &var1,&var2, ..)
[15:09:40] <cradek> yes
[15:09:51] <alex_joni> I'm expecting a fixed number of hex values
[15:10:01] <cradek> %x?
[15:10:14] <alex_joni> FF FF FF 55 02 FF 02 FF 00 0E 29 1A 00 00 00 00 00 00 00 00 00 15 94 34 30
[15:10:30] <alex_joni> without the spaces.. that's taken care by my terminal program
[15:10:31] <cradek> "%X %X %X ..."
[15:10:44] <alex_joni> %X expects only one byte wide?
[15:10:52] <cradek> brb
[15:11:37] <SWPadnos> %x expects something delimited by a space (or other delimiter)
[15:11:47] <SWPadnos> the first non-hex character, probably
[15:11:57] <alex_joni> I'm receiving them as values
[15:12:03] <alex_joni> not hex-named characters
[15:12:13] <alex_joni> the FF is converted from 255 actually
[15:12:18] <SWPadnos> ah, so you're not getting ASCII at all
[15:12:22] <alex_joni> no
[15:12:29] <SWPadnos> then scanf won't be much good, I think
[15:12:30] <alex_joni> %c ?
[15:12:42] <alex_joni> I want to strip the first 20 numbers
[15:12:45] <SWPadnos> yeah - that would be a character, but I'm not sure how it'll deal with EOL, EOF, etc.
[15:13:03] <alex_joni> and only convert the last 5 bytes
[15:13:09] <alex_joni> SWPadnos: always a fixed number of bytes
[15:13:39] <SWPadnos> ure, but if one of them is 0x04, or 0x1E (end of text, end of file, I think), you may have a problem
[15:13:44] <SWPadnos> s/ure/sure/
[15:13:56] <alex_joni> I see.. so maybe fgets ?
[15:13:57] <SWPadnos> how do you get the actual bytes?
[15:14:01] <alex_joni> then atoi ?
[15:14:04] <alex_joni> serial
[15:14:15] <SWPadnos> using read on /dev/ttyXXX
[15:14:29] <alex_joni> dev_usart1 on an Atmega128.. similar ;)
[15:14:56] <SWPadnos> read bytes into an array of char (or U8), then printf the last 5 bytes in the array
[15:15:14] <SWPadnos> or something less weighty than printf
[15:16:17] <SWPadnos> gotta run - bbl
[16:00:26] <alex_joni> yay.. it works ;)
[16:00:51] <alex_joni> DEBUG: got new data: ffff ffff ffff 55 2 ffff 2 ffff 0 e 29 1a 0 0 0 0 0 0 0 0 0 15 ff94 20 1c
[16:00:55] <alex_joni> -> card number: 10548
[16:52:41] <jepler> cradek: at some point didn't you fix some things on the wiki? Would it be possible to add a link to
http://www.usemod.com/cgi-bin/wiki.pl?TextFormattingRules from the "edit" page? I always have to remember that the link to that page is on BasicSteps...
[16:53:55] <cradek> I think we all have access to it on shell.sf.net ... somehow
[16:54:54] <cradek> actually I like there to be a summary of the common markup under the edit box