jmkasunich: have you started on the 5i20 firmware yet?
(for step generation)
that would be "no"
I'm still working on getting the machine working with software step/dir
(mounting and wiring stuff, etc)
why do you ask?
just making conversation
* jmkasunich guesses that jepler has it half done already ;-)
I'm still trying to think of something "original" to do with the 5i20
that sound like a fun conversation
I don't have any good ideas yet
requirements I assume are minimal external hardware?
logic analyzer isn't that original.... and you'd need some ram
100MHz is pretty far from state of the art too... but probably usefull for some projects
I can't remember what it's called -- fenn would -- but there's already a powerful logic analyzer out there to be built from parts
gpl'd firmwares and board designs
ok, not original enough
ah, this thing: http://minila.sourceforge.net/
32 channels, 100MHz, 128 kb/channel
put a/d's on it and make a storage scope?
also not all that original, you can buy that for a few hundred $
yeah -- and memory's a problem again
line in jacks to A/D, D/A to line out
and implement some DSP'ish stuff inside
a lot of ideas seem to call for RAM -- maybe I should look at doing a RAM daughterboard that would take one 25-pin header
use PC100 era DIMMs - cheap and huge
since they're DRAM, I bet the address bus is row/col
so you can don't eat up so many bits
I wonder if ~24 I/Os is enough
in fact, you might be able to mux row/col/data on one set of 16 lines
leaving 8 for control
then a 64MB dimm would give you 64MB, as 32M x 16
64MB x 64 dimm if you only used 16 bits would give you 16M as 8M x 16
data and address are separate on the 144-pin SODIM pinout
I figured - you'd have to use a couple '245s on the board to join them
its a speed/pins tradeoff
easiest to design it for two connectors
that doesn't leave much I/O
no it doesn't
how about a resolver to digital converter?
(I even have some resolvers you could have)
is a 298 a single H bridge. or a dual?
dual H bridge -- one 298 runs 2 servos or one stepper
trying to think of things the might be fun to control, and require bandwidth greater than you'll get from RT code in a PC
hm, needs RAM again, but a video encoding accelerator, specifically for the "motion estimation" step
though PCs are well above real-time at video encoding, so it doesn't matter much
also requires memory: a frame grabber
but again, most webcams manage to do that all by themselves
in terms of computing power, the PC has the fpga beat, unless you are doing something that doesn't tolerate latency
or something that parallelizes really well
motion estimation is very parallel
pc video encoding is a disk -> encoder -> disk thing, right?
so latency doesn't matter
what about camera -> encoder -> disk ?
probably not too different, as long as there's a big enough buffer somewhere
between camera and encoder
and interfacing to the camera won't be fun
if the hypothetical operation to be performed can be done in one PCI write and one PCI read, it would take at least 60ns (and that's optimistic). In that time, a 2GHz CPU has about 120 cycles.
yeah you're probably right that I won't find anything that can be done faster on a PCI-attached FPGA
so if you're just using it as a coprocessor, it needs to be something that takes a long time to process a little bit of data
or you'll be IO bound
_and_ something that the fpga is inherently faster at (parallelism, since the clock is actually slower)
its gotta be something that interacts with the real world
unfortunately most of the real world is analog
damned real world
its a shame laser pointers have short coherent lengths
interferometry on the cheap would be fun
doing a wall-projected reproduction of classic vector games was on my list a while back
but it looked like it was expensive to get closed-loop galvos
laser pointer, bouncing off of mirrors on the arms of two dead disk drives
oops, no feedback
I suspect you need feedback to do "asteroids"
it does matter where each thing is drawn
I'm trying to think of a way to do feedback
the resolvers you offered me earlier, of course
not enough bandwidth
they usually use 2500 or 5000 Hz excitation
I doubt the update rate can significantly exceed that
we're looking for pid loops with update rates in the 10s of khz
I think that the older, slower vector games would cross the 1024-position screen in as little as 1ms (1MHz clock) and the later games were faster
disks have average seek times of 5mS or so
dunno how average is computed
298 can drive the coils
feedback is the key
I figured you'd want to drive it in the analog domain
hopefully its inductance would be a good pwm filter
force = current, not voltage, so stepping the voltage would let you change the torque quickly
but without the servo tracks on the disk surface, feedbacks is the challenge
the other challenge would be computing the paths
because of inertia, you can't draw a sharp corner
you'd probably want loops on corners
not a problem for CRT vector displays
though I suppose those electrons must have some mass
their mass isn't the limiting factor
its the deflection plate capacitance
don't worry I wasn't being serious
I wonder how many 8x8 multipliers fit on the fpga
for video encoding?
to do a 1D convolution filter
any particular application?
image processing -- many interesting 2D convolutions are separable
1 sample in, 1 sample out, many multiply-accumulate operations
bet the PC is faster
FPU can do a mult-acc in a couple clocks
or are you thinking of massive parallelism?
a 64x1 or 128x1 kernel
operate on 128 scan lines at once?
no, operate on a history of 128 pixels
out = in1 * weight1 + in2 * weight2 + ... + in128 * weight128
FIR filter IOW
then shift all "in"s right 1, get new "in1", compute again
thats an FIR
OK -- I've just heard it called a convolution, and the weights are the "kernel"
filtering is probably the term when the signal is X vs time
for pixels, its X vs space
so maybe different terminology
isnt the "kernel" rather small but 2D?
like 5x5 pixels, or 10x10?
that's why I led off by saying many of them are "separable": you can turn a separable NxN kernel into a 1xN kernel for rows, and then a Nx1 kernel for the columns
but if N is small (compared to 128) you don't get the parallism
how much memory is in each of the internal blocks in the FGPA?
enough to store one scan line of pixels?
I forget if it's around 40,000 bits or 40,000 bytes
lets assume bits
I think it's the area of all the multipliers that would kill this idea
you need 8 bits in and 8 bits out, right?
(discard 8 low bits of product)
yes, though 16 would be nice
I don't think dozens of 16-bit multipliers will fit, though
16 in and out, or 8x8->16 ?
16 bit input pixel values
where do you get that many bits? digital camera?
I thought they were about 12 bits at best
hm -- by traversing the image cleverly (according to the hilbert space-filling curve) you only need to load N pixels for each output pixel, and you only have to store N^2 pixels, not N rows of pixels
because they run on PCs, the processing programs generally jump from 8 to 16 bit internal precision.
you're right that digital camera RAW formats typically have at most 12 bits
what kind of N values are you aiming for? 5x5? 10x10? 50x50? ;-)
it will turn out video cards are better for this task anyway
this would be for the 10x10 to 25x25 territory
probably right about the video cards
think real world interaction I say....
all you do is 25x25*2 textured triangles and read the result out of the framebuffer
I liked the projection asteroids idea
but pulling it off would be tough
60 frames/sec, times 50-100 lines in a frame
6000 lines per second
gonna be _real_ hard to move mirrors that fast
even a 1/4" diameter thin one on a hard disk arm
others seem to be trying this too: http://www.linux-laser.org/
the electronics is about 4 orders of magnitude faster than the mechanics
they're using commercial projectors and just doing the interface
yeah but what are the chances I could come up with something better than a commercial projector from spare parts?
I was thinking more of "what are the chances you could come up with something that sorta works for 1/100th the price of a commercial projector
I have no clue what they cost, but I bet its >$1000
[03:08:42] <jmkasunich> http://home.att.net/~JEKasunich/vannorman/VN_Home.htm
[03:09:07] <jmkasunich> http://elm-chan.org/works/vlp/report_e.html
"You can get point output rates up to 130,000 pts/sec. Such fast rates are necessary for photorealistic TV-like raster frames."
he describes a feedback sensor that could be adapted to the hard disk servo
I'm reading that part but none of it has sunk in yet
he does the actual servo loop in analog
which makes sense, but doesn't use the fpga
looks like he can deflect 8 degrees and settle in 200uS or so
using peak coil currents of about 5A
too much analog electronics
gotta run, but could you reflect a dot off the mirror onto a linear ccd (?) like from a scanner? Tell what the deflection is?
I was thinking about that actually ;-)
but the readout time from the CCD is too slow
(about 1mS for the ones I looked at)
oh well. Grocery store barcode scanner? 'night, before I get killed.
cradek: I dunno if you want to pursue this, but here's a hacked up diff to get rid of the need for latex2html to build the deb: http://emergent.unpy.net/index.cgi-files/sandbox/nol2h.patch.1
there are other changes in my local tree, maybe I removed some by mistake. here's the diff before I hacked it: http://emergent.unpy.net/index.cgi-files/sandbox/nol2h.patch
I'm off to bed now
this is beginning to look like a problem that "needs solved" thoug
I could just dump that into our repository like I did the few other things that aren't in base
how big is it?
"it" is latex2html, right?
yeah I think that's the only thing not in the base repositories, but I'm not sure
I thought it was only needed to build the docs?
I'll have to look at it tomorrow - I haven't been feeling too great so should get to bed on time
yeah but docs are in the base package so build-dep gives you doc tools.
this only affects developers and others who do builds, not ordinary users then
yeah this is just about building
get some sleep
I'm trying, but all I'm accomplishing is missing work
which isn't all bad I guess...
Does anybody know if there's a nice tool to extract and handle I18N strings in python (like e.g. linguist for QT)?
fjungclaus: in emc2 we use xgettext to extract messages from python, tcl, and C files. in python we use the 'gettext' module to find translations from the message catalog at runtime.
I like the stuff done with sim (mini). The comp, ddt, hypot are all fascinating.
it is great for debugging the trajectory planner or graphing its performance with halscope
I confess. I can hardly keep up with developments.
[14:30:59] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=254681#post254681
Wah! That sounds very good.
seems like a guy that can be worked with :)
we need to pick a channel and stick with it ;)
here is probably the best place.
Thanks - it is the least I can do. Emc2 is a wonderful program.
JohnR said he would get ahold of Bryan today and talk it through.
Sounds like he wants to get a system going so he can keep up with emc2 and all his stuff.
That will be a good addition.
Hey skunkworks. Perhaps you should correct John's thought that I made the changes to the email stuff.
who is bryan?
could be the software guy that Vigilant sent boards to - it may not be Paul at all
I think it's one of Vigilant's guys who will be in charge of the emc2 stuff
from their side I mean
alex_joni: did you make the email changes to linuxcnc.org? Do you want me to post a correction to the thread on cnczone? Do you care ;)
skunkworks: not really
do we still support any platforms that use a gcc 2.x or egcs?
do we still support "BDI-TNG"?
is there any system where it is useful to specify --with-kbuild, or is the automatic detection good enough?
might there be custom systems where detection wouldn't work?
like RH, Gentoo, custom embedded builds ...
jepler: was that a retorical set of questions?
I don't think that any 2.x or egcs still work
and a newer 2.6 won't build on anything older than 3.0
so my personal call would be ditch them
out with the old, eh?
I notice that rtai makes no attempt at all (I think) to support older kernels
even older versions of 2.6
jepler: thanks from a guy from germany, he's successfully using jdi.py
alex_joni: is that better than our existing pumakins?
(based on fred's work I see)
jmkasunich__: honestly.. I have nfc
alex_joni: I would like to clean out some cruft during 2.2.
jepler: how much cleaning do you have in mind?
dropping non-kbuild (non-2.6) kernels maybe?
jmkasunich__: dropping pre-3.0 compilers and old-bdi-specific hacks is what I've done so far
I plan on some more NML cleanups
did a bit for 2.1, but there's plenty more
dropping non-kbuild kernels will simplify the build system a lot won't it?
no, sim basically follows the non-kbuild method
the non-kbuild method still built kernel modules tho, sim doesn't do that
or is the diff between kernel and user less than the diff between kbuild and non-kbuild?
in sim, each component is built into a .so by the same makefile rules that build a kernel .o for non-build systems -- they just have a different $(MODULE_EXT)
different libs and headers though I would expect (user headers vs. kernel headers)?
or do they still use kernel headers?
yes -- all the compiler flags are different
Hey, Jeff. Connection to irc is very instable today ...
sorry to hear that
mine has been fine all day
Any suggestion for I18N tool to be used together with python?
did you see my answer about I18N and python?
07:05:03 <jepler> fjungclaus: in emc2 we use xgettext to extract messages from python, tcl, and C files. in python we use the 'gettext' module to find translations from the
message catalog at runtime.
No, probably the answer was lost ...
Ok, I'll try that ...
in fact there is a (partial) translation of AXIS to german already.
I think Florian Hahn has done a lot of this work ...