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
of course, stepgen would have to be modified so that it could have "step" high every period instead of every other period
some of that got cut off I think
basicly you're saying that 2 functions per base_period (one to set the pulse, one to clear if needed) ?
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 that "1uS per I/O" rule is right.
time to drive to work, bbl
hi from the office
wanted to ask you something.. but I forgot :(
getting old it seems
jepler - you can just run the stepgen function twice per fast thread
err - make_pulses
but it probably is better to have a single "make_pulses" at the start, and a "clear_pulses" at the end of the thread
by having hal_parport know about setting/clearing bits I was perhaps overthinking the efficiency issue
luckily I don't have any hardware that needs a high step rate so it is just daydreaming...
hoo boy have I screwed things up at work this morning
oops - boo!
hint: if you ever type 'find .... | xargs rm' you'll regret it
so just .. don't
like df in fdisk, huh? :)
it's disk free, as an imperative
I think my favorite is still the time I removed '/lib/ld.so' by accident
Tape Used (%) 103.7
I usually like to stop at or below 100%
I agree that would seem like a superior algorithm
unless they mis-count compressed data
no I think it actually sometimes writes a little more than the declared tape size
I just declare it a little low
that helps. what kind of tape?
ok - not one of the "modern" ones with the length stored in a chip in the cart
(and parts of the catalog, sometimes)
I have barcodes on them, that's as fancy as it gets
* alex_joni saw a printer recently..
you can read barcode?
storing a catalog would be pretty neat.
one of those that phones home for new cartriges
the changer reads them
AIT does that - not the ful catalog, but at least the positions of any used segments
it would be nice to be able to reliably (safely) append to a tape
that's kinda necessary, IMO
not just "nice"
not really, you just get used to using one tape per run
software that smartly decides how to fill it (up to 103.7%) is pretty useful then
wonder where it'll stop ;)
can I just do something like this? fscanf(foo, "%d%d%d%d", &var1,&var2, ..)
I'm expecting a fixed number of hex values
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
without the spaces.. that's taken care by my terminal program
"%X %X %X ..."
%X expects only one byte wide?
%x expects something delimited by a space (or other delimiter)
the first non-hex character, probably
I'm receiving them as values
not hex-named characters
the FF is converted from 255 actually
ah, so you're not getting ASCII at all
then scanf won't be much good, I think
I want to strip the first 20 numbers
yeah - that would be a character, but I'm not sure how it'll deal with EOL, EOF, etc.
and only convert the last 5 bytes
SWPadnos: always a fixed number of bytes
ure, but if one of them is 0x04, or 0x1E (end of text, end of file, I think), you may have a problem
I see.. so maybe fgets ?
how do you get the actual bytes?
then atoi ?
using read on /dev/ttyXXX
dev_usart1 on an Atmega128.. similar ;)
read bytes into an array of char (or U8), then printf the last 5 bytes in the array
or something less weighty than printf
gotta run - bbl
yay.. it works ;)
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
-> card number: 10548
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...
I think we all have access to it on shell.sf.net ... somehow
actually I like there to be a summary of the common markup under the edit box