yup, but not very long
in realtime can we manage any interrupts?
(I think not but just make sure)
micges_work: I think you can set up dma
Pushing to ssh://firstname.lastname@example.org/git/emc2.git
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'ssh://email@example.com/git/emc2.git'
* JT-Dev wonders what happened
alex_joni: have you done this?
but I think seb contemplated on doing it for the 5i20 driver
there's no provision in rtapi for interrupt-driven code; everything's designed to be time driven. Conceptually I'm tempted to imagine interrupt "threads" that differ from time threads simply in the external event that rtapi_task_wait waits for
but how that's done at the rtai layer, I don't have any idea
you also have to contemplate priority of period threads vs interrupt threads
and if motion is running periodic and communication with the motors is free-running via interrupts, will emc cope with the variable phase shift between them
I think there was some emc1 code that ran in interrupt driven mode
e.g. set up the timer to cause an interrupt too, to handle the periodic thing
there was an emc1 branch. I have no idea if it ever worked. but yes, it might be a good example for how to use the rtai apis
there is also the problem that HAL communications (pins/signals) aren't truly atomic, since in some cases you need more than one pin for communications between components
the old emc1 history is here among other places: http://git.unpy.net/view?p=emc.git;a=shortlog;h=refs/heads/Interrupt_driven
(what a useless diff that top commit gives!)
heh - it looks like mostly comment spacing changes
oh, and code spacing too, can't forget that
it's true; if you have a git clone of that, "git show -w origin/Interrupt_driven" trims the diffstat from 9745 to 2317
-w ignores whitespace?
it's still a useless mess imo
EMC: 03seb 07master * r2fa0df4ddf37 10/src/hal/drivers/mesa-hostmot2/ (hostmot2.h pwmgen.c): fix pwmgen memory leaks, & simplify pwmgen a bit
odd machine.. 3 step pins (x,y,z) but only one common dir pin
I recall seeing some cheapo driver like that. I recommend simply throwing it out..
maybe can be fixed with an x-acto knife and wire-wrap wire?
if you were a total masochist you could probably get it to work. toggle dir every cycle, and assert the step pins for the axes that need to step. you can still achieve one step per 2 periods, just like with sane step generators (and no doublestep)
I have to admit there was a flash at the moment I imagined that scheme
if it needs much setup time, you might only be able to do half that
arg, the temptation to put lucid on my primary laptop is almost overwhelming
what do you have now?
the one that works perfectly and suspends right and unsuspends right and did I say works perfectly?
if you have 9.10 you should run the upgrade and let me know if it ruins everything
it is apparently 9.04
at least the gui upgrade won't let you do 9.04->10.04 as a single step upgrade
nope, it says 9.10
I'd probably install fresh and restore my home directory anyway
I think the odds are good that suspend will still work right
I haven't done many suspend/resume cycles yet since installing 10.04 but so far it's been fine
well I doubt it would have regressed (hahahahaha)
10.04 seems to work very well on my little laptop
including suspend/hibernate, wifi, ethernet, audio, video ...
SWPadnos: seems that drivers part of ubuntu was improoved
I haven't bothered trying the camera yet (VGA resolution, what's the point), and this laptop doesn't have bluetooth
the suspend thing they got right a year or so ago, but the atheros wifi is more recent
trying only briefly, I couldn't get emc2-sim to build, because of tk/tcl/tkinter version problems
I even tried specifying --with-tcl-whatever /something/tclConfig.sh etc
I'll know more later... I'm going to reinstall this machine.
hmmm, yeah. I haven't really tried to do any compiling, and haven't even downloaded EMC2 sources on that laptop yet
huh, emc2 sim builds just fine on my 10.04.
(weird -- vim-gnome requires tcl8.4?)
checking for tcl... /usr/lib/tcl8.5/tclConfig.sh found
checking for tk... /usr/lib/tk8.5/tkConfig.sh found
checking for BWidget using /usr/bin/tclsh8.5... found
checking match between tk and Tkinter versions... 8.5
jepler: ok, I must've done something wrong.
I installed gitk first, which pulled in some 8.4 stuff. maybe that was it.
To save me finding out where I need to look, does kfree work on a hal_malloc-ed ting?
Hmm, Seb uses it in his patch of today, I think.
I don't think there is a hal_free
yes, "kfree(pwmgen.instance)" after "hm2->pwmgen.instance = (hm2_pwmgen_instance_t *)hal_malloc(hm2->pwmgen.num_instances "
he's smarter than me, so maybe it's right - but I am suspicious.
I guess I could try hal_free and see if it compiles? Or is that too brutal?
there's no hal_free
Perhaps hal has a garbage collector?
hal_malloc - Allocate space in the HAL shared memory area
The allocator is very simple, and there is no `free'. The entire HAL
shared memory area is freed when the last component calls hal_exit.
so it sounds like seb's change is wrong
It's 12 bytes leaked if you fail to load pwmgen then. It might be bearable?
good catch andypugh
I am guessing that kfree can't even access the hal shared memory?
I will query it in that thread on the mailing list.
there are kfrees all over in hostmot2
oh that's because it calls kmalloc fors tuff.
they may not all be wrong
a spot check shows some matching kmallocs
No, the kfrees seem to match kmallocs. I am not sure why they are kmalloc and not vanilla malloc, but I wouldn't _expect_ to know that.
because realtime stuff is running in kernel space. there's no malloc there.
Supplementary question. Is it OK for a tp_pwmgen_write function to read a value as a side-effect? There is a bidirectional register. I need to read the fault bit so that I can write it back unchanged. It seems daft not to deal with it then, but to pretend I hadn't read it and leave it to a redundant tp_pwmgen_read function.
I can't just "or" it, as only the one bit is readable, the other 31 bits are write-only and always read as FFFFFFFF
Ah, no.. Wait. Why is it you only realise you are saying something stupid after you have said it? That bit is read-only, I don't have to worry about it at all.