Back
[07:26:52] <micges_work> alex_joni: around?
[07:32:15] <alex_joni> yup, but not very long
[07:35:26] <micges_work> in realtime can we manage any interrupts?
[07:35:39] <micges_work> (I think not but just make sure)
[07:42:52] <micges_work> or dma?
[11:40:49] <alex_joni> micges_work: I think you can set up dma
[11:46:20] <JT-Dev> Pushing to ssh://jthornton@git.linuxcnc.org/git/emc2.git
[11:46:22] <JT-Dev> To ssh://jthornton@git.linuxcnc.org/git/emc2.git
[11:46:23] <JT-Dev> ! [rejected] master -> master (non-fast forward)
[11:46:25] <JT-Dev> error: failed to push some refs to 'ssh://jthornton@git.linuxcnc.org/git/emc2.git'
[11:46:32] <JT-Dev> * JT-Dev wonders what happened
[11:52:54] <micges_work> alex_joni: have you done this?
[11:54:48] <alex_joni> nope
[11:55:07] <alex_joni> but I think seb contemplated on doing it for the 5i20 driver
[11:56:41] <micges_work> I see
[12:07:25] <jepler> 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
[12:08:21] <jepler> but how that's done at the rtai layer, I don't have any idea
[12:08:55] <jepler> you also have to contemplate priority of period threads vs interrupt threads
[12:08:58] <jepler> periodic
[12:09:34] <jepler> 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
[12:10:10] <alex_joni> I think there was some emc1 code that ran in interrupt driven mode
[12:10:28] <alex_joni> e.g. set up the timer to cause an interrupt too, to handle the periodic thing
[12:10:33] <jepler> 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
[12:10:57] <SWPadnos> 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
[12:12:28] <jepler> the old emc1 history is here among other places:
http://git.unpy.net/view?p=emc.git;a=shortlog;h=refs/heads/Interrupt_driven
[12:13:10] <jepler> (what a useless diff that top commit gives!)
[12:13:56] <SWPadnos> heh - it looks like mostly comment spacing changes
[12:14:32] <SWPadnos> oh, and code spacing too, can't forget that
[12:19:55] <jepler> it's true; if you have a git clone of that, "git show -w origin/Interrupt_driven" trims the diffstat from 9745 to 2317
[12:20:28] <SWPadnos> -w ignores whitespace?
[12:20:37] <jepler> yes
[12:20:48] <SWPadnos> very cool
[12:21:19] <jepler> it's still a useless mess imo
[15:24:09] <CIA-2> EMC: 03seb 07master * r2fa0df4ddf37 10/src/hal/drivers/mesa-hostmot2/ (hostmot2.h pwmgen.c): fix pwmgen memory leaks, & simplify pwmgen a bit
[21:29:43] <alex_joni> odd machine.. 3 step pins (x,y,z) but only one common dir pin
[21:30:51] <jepler> I recall seeing some cheapo driver like that. I recommend simply throwing it out..
[21:32:01] <cradek> maybe can be fixed with an x-acto knife and wire-wrap wire?
[21:33:07] <jepler> 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)
[21:33:54] <cradek> that's genius
[21:35:55] <jepler> I have to admit there was a flash at the moment I imagined that scheme
[21:36:26] <cradek> if it needs much setup time, you might only be able to do half that
[21:36:33] <jepler> yes
[21:38:06] <cradek> arg, the temptation to put lucid on my primary laptop is almost overwhelming
[21:38:23] <jepler> what do you have now?
[21:38:31] <cradek> the one that works perfectly and suspends right and unsuspends right and did I say works perfectly?
[21:38:34] <jepler> if you have 9.10 you should run the upgrade and let me know if it ruins everything
[21:39:33] <cradek> it is apparently 9.04
[21:39:47] <cradek> Jerkish Jingle-horse
[21:40:20] <jepler> at least the gui upgrade won't let you do 9.04->10.04 as a single step upgrade
[21:40:52] <cradek> nope, it says 9.10
[21:41:13] <cradek> I'd probably install fresh and restore my home directory anyway
[21:41:30] <jepler> I think the odds are good that suspend will still work right
[21:41:43] <jepler> I haven't done many suspend/resume cycles yet since installing 10.04 but so far it's been fine
[21:42:00] <cradek> well I doubt it would have regressed (hahahahaha)
[21:52:48] <SWPadnos> 10.04 seems to work very well on my little laptop
[21:53:06] <SWPadnos> including suspend/hibernate, wifi, ethernet, audio, video ...
[21:53:39] <micges> SWPadnos: seems that drivers part of ubuntu was improoved
[21:53:44] <SWPadnos> I haven't bothered trying the camera yet (VGA resolution, what's the point), and this laptop doesn't have bluetooth
[21:54:08] <SWPadnos> the suspend thing they got right a year or so ago, but the atheros wifi is more recent
[22:02:45] <cradek> trying only briefly, I couldn't get emc2-sim to build, because of tk/tcl/tkinter version problems
[22:03:00] <cradek> I even tried specifying --with-tcl-whatever /something/tclConfig.sh etc
[22:03:20] <cradek> I'll know more later... I'm going to reinstall this machine.
[22:04:16] <SWPadnos> hmmm, yeah. I haven't really tried to do any compiling, and haven't even downloaded EMC2 sources on that laptop yet
[22:09:32] <jepler> huh, emc2 sim builds just fine on my 10.04.
[22:10:50] <jepler> (weird -- vim-gnome requires tcl8.4?)
[22:12:40] <jepler> checking for tcl... /usr/lib/tcl8.5/tclConfig.sh found
[22:12:40] <jepler> checking for tk... /usr/lib/tk8.5/tkConfig.sh found
[22:12:40] <jepler> checking for BWidget using /usr/bin/tclsh8.5... found
[22:12:47] <jepler> checking match between tk and Tkinter versions... 8.5
[23:26:19] <cradek> jepler: ok, I must've done something wrong.
[23:26:30] <cradek> I installed gitk first, which pulled in some 8.4 stuff. maybe that was it.
[23:30:21] <andypugh> To save me finding out where I need to look, does kfree work on a hal_malloc-ed ting?
[23:32:59] <cradek> very doubtful
[23:33:35] <andypugh> Hmm, Seb uses it in his patch of today, I think.
[23:34:49] <cradek> I don't think there is a hal_free
[23:35:13] <andypugh> yes, "kfree(pwmgen.instance)" after "hm2->pwmgen.instance = (hm2_pwmgen_instance_t *)hal_malloc(hm2->pwmgen.num_instances "
[23:35:46] <cradek> he's smarter than me, so maybe it's right - but I am suspicious.
[23:35:59] <andypugh> I guess I could try hal_free and see if it compiles? Or is that too brutal?
[23:36:10] <cradek> there's no hal_free
[23:37:33] <andypugh> Perhaps hal has a garbage collector?
[23:37:43] <cradek> nope
[23:38:47] <jepler> NAME
[23:38:47] <jepler> hal_malloc - Allocate space in the HAL shared memory area
[23:38:52] <jepler> The allocator is very simple, and there is no `free'. The entire HAL
[23:38:55] <jepler> shared memory area is freed when the last component calls hal_exit.
[23:39:07] <jepler> so it sounds like seb's change is wrong
[23:39:35] <andypugh> It's 12 bytes leaked if you fail to load pwmgen then. It might be bearable?
[23:39:38] <cradek> good catch andypugh
[23:40:07] <andypugh> I am guessing that kfree can't even access the hal shared memory?
[23:40:59] <andypugh> I will query it in that thread on the mailing list.
[23:41:42] <cradek> there are kfrees all over in hostmot2
[23:42:32] <cradek> oh that's because it calls kmalloc fors tuff.
[23:43:11] <jepler> they may not all be wrong
[23:43:21] <cradek> right
[23:43:39] <cradek> a spot check shows some matching kmallocs
[23:43:57] <andypugh> 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.
[23:45:41] <jepler> because realtime stuff is running in kernel space. there's no malloc there.
[23:49:30] <andypugh> 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.
[23:50:42] <andypugh> 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
[23:51:56] <andypugh> 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.