#emc-devel | Logs for 2011-05-31

Back
[00:04:06] -!- theorbtwo has quit [Ping timeout: 255 seconds]
[00:04:12] theorb is now known as theorbtwo
[00:13:37] -!- geo01005 has quit [Ping timeout: 252 seconds]
[00:16:54] -!- Aero-Tec has quit [Quit: ChatZilla 0.9.86.1 [Firefox 4.0.1/20110413222027]]
[00:21:09] -!- crazy_imp has quit [Read error: Operation timed out]
[00:56:00] -!- SWPadnos_ [SWPadnos_!~Me@74-92-8-214-NewEngland.hfc.comcastbusiness.net] has joined #emc-devel
[00:58:50] -!- SWPadnos has quit [Ping timeout: 248 seconds]
[00:58:53] SWPadnos_ is now known as SWPadnos
[01:01:30] -!- czervika has quit [Quit: Peace out money]
[01:40:11] -!- The_Ball has quit [Ping timeout: 240 seconds]
[01:43:53] -!- maddogma has quit [Remote host closed the connection]
[02:14:59] -!- schwege has quit [Ping timeout: 252 seconds]
[02:26:19] -!- ries has quit [Quit: ries]
[02:27:23] -!- factor has quit [Read error: Connection reset by peer]
[02:49:39] -!- Tom_shop has quit []
[02:50:11] -!- geo01005 has quit [Ping timeout: 252 seconds]
[02:58:49] -!- kljsdfhklj has quit [Quit: kljsdfhklj]
[03:32:11] -!- geo01005 has quit [Ping timeout: 240 seconds]
[03:38:59] -!- ries has quit [Quit: ries]
[03:44:27] -!- ve7it has quit [Read error: Connection reset by peer]
[03:49:41] -!- Roguish has quit [Ping timeout: 276 seconds]
[03:51:21] -!- schwege has quit [Ping timeout: 240 seconds]
[04:18:14] -!- willburrrr2003 has quit [Quit: Relax, its only ONES and ZEROS!]
[05:07:22] -!- geo01005 has quit [Ping timeout: 248 seconds]
[05:10:50] -!- rooks has quit [Quit: So long, and thanks for all the fish.]
[05:16:39] -!- awallin [awallin!~quassel@2001:708:110:1020:224:7eff:feda:7c7d] has joined #emc-devel
[05:26:37] -!- vladimirek [vladimirek!~vladimire@bband-dyn166.178-41-220.t-com.sk] has joined #emc-devel
[06:15:04] -!- FinboySlick has quit [Quit: Leaving.]
[06:23:01] -!- The_Ball has quit [Ping timeout: 258 seconds]
[06:29:27] -!- aggrav8d has quit [Ping timeout: 252 seconds]
[06:31:54] -!- scanf has quit [Quit: Leaving]
[07:17:14] -!- capricorn_one has quit [Remote host closed the connection]
[07:31:54] -!- scanf has quit [Ping timeout: 248 seconds]
[07:32:20] -!- scanf- has quit [Client Quit]
[07:57:49] -!- factor has quit [Ping timeout: 252 seconds]
[07:58:10] -!- schwege has quit [Ping timeout: 260 seconds]
[08:17:19] -!- monode has quit [Quit: Page closed]
[08:35:35] -!- anonimasu has quit [Read error: Connection reset by peer]
[08:46:26] -!- acemi has quit [Quit: WeeChat 0.3.2]
[09:06:55] -!- Paragon-WS has quit [Ping timeout: 246 seconds]
[09:07:14] -!- monode has quit [Ping timeout: 252 seconds]
[09:19:41] -!- KimK has quit [Ping timeout: 240 seconds]
[09:20:33] -!- maximilian_h [maximilian_h!~bonsai@ulmg-5d84dd10.pool.mediaWays.net] has joined #emc-devel
[09:40:27] -!- factor has quit [Quit: Leaving]
[10:00:55] -!- DaViruz has quit [Ping timeout: 240 seconds]
[10:03:05] -!- maximilian_h has quit [Ping timeout: 250 seconds]
[10:48:48] -!- vladimirek has quit [Remote host closed the connection]
[10:52:43] -!- schwege has quit [Read error: Operation timed out]
[10:54:46] -!- rooks has quit [Client Quit]
[11:05:25] -!- pjm has quit [Ping timeout: 260 seconds]
[11:34:00] -!- acemi has quit [Ping timeout: 260 seconds]
[11:49:14] -!- nicko has quit [Ping timeout: 250 seconds]
[12:21:35] -!- geo01005 has quit [Quit: ChatZilla 0.9.86.1 [Firefox 4.0.1/20110413222027]]
[12:41:41] -!- Poincare has quit [Read error: Operation timed out]
[12:51:21] -!- Poincare has quit [Quit: changing servers]
[12:59:49] -!- wagnerf_ has quit [Remote host closed the connection]
[13:03:25] -!- kljsdfhklj has quit [Read error: Connection reset by peer]
[13:11:22] -!- kljsdfhklj has quit [Quit: kljsdfhklj]
[13:23:32] -!- Birdman3131 has quit [Ping timeout: 240 seconds]
[13:27:21] -!- OoBIGeye has quit [Ping timeout: 255 seconds]
[13:33:35] Tech_Talk is now known as Birdman3131
[13:33:39] -!- JT-Work [JT-Work!~chatzilla@216-41-154-151.semo.net] has joined #emc-devel
[13:34:14] -!- kb8wmc [kb8wmc!~chatzilla@64.25.194.25] has joined #emc-devel
[13:45:21] -!- Paragon-WS has quit [Ping timeout: 255 seconds]
[14:02:46] -!- KimK [KimK!~Kim__@ip174-71-95-176.om.om.cox.net] has joined #emc-devel
[14:03:58] -!- factor has quit [Read error: Connection reset by peer]
[14:19:23] -!- vladimirek [vladimirek!~vladimire@bband-dyn166.178-41-220.t-com.sk] has joined #emc-devel
[14:22:02] -!- awallin has quit [Remote host closed the connection]
[14:29:06] -!- JT-Work has quit [Read error: Connection reset by peer]
[14:29:49] -!- JT-Work [JT-Work!~chatzilla@216-41-154-151.semo.net] has joined #emc-devel
[14:36:35] -!- JT-Work has quit [Quit: ChatZilla 0.9.86.1 [Firefox 4.0.1/20110413222027]]
[14:44:59] -!- Valen has quit [Quit: Leaving.]
[15:06:28] -!- Connor [Connor!~Connor@75.76.30.113] has parted #emc-devel
[15:08:09] -!- Connor [Connor!~Connor@75.76.30.113] has joined #emc-devel
[15:26:58] -!- schwege has quit [Read error: Operation timed out]
[15:43:57] -!- nullie has quit [Quit: Ex-Chat]
[15:50:47] -!- psha [psha!~psha@195.135.237.18] has joined #emc-devel
[15:55:51] -!- cncbasher_ [cncbasher_!~quassel@cpc8-hart9-2-0-cust686.11-3.cable.virginmedia.com] has joined #emc-devel
[16:01:11] -!- kljsdfhklj has quit [Ping timeout: 240 seconds]
[16:01:31] kljsdfhklj_ is now known as kljsdfhklj
[16:02:51] -!- ve7it [ve7it!~LawrenceG@S0106009027972e37.pk.shawcable.net] has joined #emc-devel
[16:06:29] -!- kljsdfhklj has quit [Quit: kljsdfhklj]
[16:34:00] -!- JT-Shop has quit [Read error: Connection reset by peer]
[16:34:31] -!- JT-Shop [JT-Shop!~chatzilla@216-41-156-49.semo.net] has joined #emc-devel
[17:00:05] -!- rooks has quit [Read error: Operation timed out]
[17:11:13] <cncbasher_> has zenomai been looked at for emc2 ? , feasable or not ?
[17:20:41] -!- kljsdfhklj has quit [Read error: Connection reset by peer]
[17:41:15] -!- Calyp has quit [Remote host closed the connection]
[18:00:03] -!- syyl has quit [Ping timeout: 255 seconds]
[18:03:13] -!- nullie has quit [Quit: Ex-Chat]
[18:04:29] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100423140709]]
[18:04:32] <KimK> The only mention of Xenomai I could find on the wiki was at http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?FPGA where this was all I found: http://conferences.fnal.gov/cgi-bin/rt2007/download.pl?paper_id=PS1B004&wanted_file=PS1B004.PDF Hope that helps.
[18:09:59] <KimK> There is also Wikipedia, where there is a section marked "Xenomai vs. RTAI" here: http://en.wikipedia.org/wiki/Xenomai which has a couple of interesting comments.
[18:10:58] <cradek> people have talked/asked about this for years but nobody has offered to do the work, or made an argument about the possible benefits, that I've seen
[18:13:36] <KimK> The Wikipedia article says RTAI's project goals are lowest latency, which I'm sure would be paramount to EMC2 users. The Xenomai project goals I'm less familiar with, sorry.
[18:29:47] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[18:34:24] -!- scanf- has quit [Quit: Leaving]
[18:45:47] -!- isssy has quit [Quit: Visitor from www.linuxcnc.org]
[18:51:48] <cncbasher_> ok thanks , i'll try and dig deeper
[18:56:14] <cradek> what's your goal precisely?
[18:58:14] <cncbasher_> usb i hope , as xenomai , has usb
[18:58:39] <cncbasher_> but theirs a lot more to it than that
[18:59:07] <cncbasher_> so may be an option to improve
[19:00:27] -!- cncbasher [cncbasher!~quassel@cpc8-hart9-2-0-cust686.11-3.cable.virginmedia.com] has joined #emc-devel
[19:04:14] -!- vladimirek has quit [Ping timeout: 276 seconds]
[19:04:17] <archivist> cncbasher, before you put too much effort in, see if they use the synchronous mode from usb2, and can stop random plugging in any usb device because latency from the device poll can be a killer
[19:06:43] <cncbasher> thanks for that
[19:12:40] -!- Loetmichel has quit [Ping timeout: 240 seconds]
[19:12:42] <archivist> I did have an hour or few reading the usb spec
[19:13:00] <cncbasher> did you get anywhere ?
[19:14:31] <cncbasher> supports usb3 also
[19:14:51] <cncbasher> as you say reading time for a while i think
[19:15:12] <archivist> I got side tracked, I believe the synchronous mode should be usable BUT the polling will probably be a killer if its allowed to
[19:16:21] <cncbasher> i have a few using usb on windows , and it's a pain when they drop
[19:18:05] <cncbasher> been thinking of looking at it for a while , and came across xenobi on a google search
[19:18:36] -!- vladimirek [vladimirek!~vladimire@bband-dyn166.178-41-220.t-com.sk] has joined #emc-devel
[19:18:44] <cncbasher> as it also either emulates or whathave you with RTAI
[19:22:35] <archivist> I dont know how the chips cover the poll and whether synchronous overrides the poll on a channel
[19:25:02] <archivist> does the os also poll all channels(ports) or what, even usb3 does that still poll at usb1/1.1 slowness
[19:30:04] <cncbasher> as far as i know they all drop to usb1 speed , but can be overridden , against spec rules etc
[19:33:41] -!- awallin_ [awallin_!~quassel@cs27057046.pp.htv.fi] has joined #emc-devel
[19:38:32] -!- jcizek has quit [Quit: Leaving.]
[19:50:27] <archivist> so dropping to do a poll mid synchronous transfer would be a disaster
[19:54:10] -!- micges [micges!~ddd@abgr54.neoplus.adsl.tpnet.pl] has joined #emc-devel
[19:55:14] -!- micges has quit [Client Quit]
[19:56:46] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust1037.basl.cable.virginmedia.com] has joined #emc-devel
[20:06:17] <JT-Shop> andypugh: you still need someone to commit something?
[20:07:38] <andypugh> I think so. DO i need to produce a patch, or can somebody else just add #include </linux/slab.h> to mesa_8i20.c and mesa_7i65.c ?
[20:07:40] -!- martinst_ has quit [Read error: Connection reset by peer]
[20:08:11] <JT-Shop> in master?
[20:08:58] <andypugh> Yes. I can't see it doing any harm, and looks to be required in other linux dielects.
[20:14:44] <JT-Shop> let me go down to the beer cave
[20:16:18] <andypugh> jtektool is about 13 I assume? The 14 year olds I have met online are more mature.
[20:17:36] <jthornton> LOL
[20:20:27] -!- robh__ [robh__!~robert@5ace7020.bb.sky.com] has joined #emc-devel
[20:20:43] <jthornton> andypugh: where does mesa_8i20.c reside?
[20:21:15] <andypugh> src/hal/drivers/mesa-hostmot2/
[20:21:54] <andypugh> Probably needs to go in 2.5
[20:22:02] <jthornton> I swear I looked there :/
[20:22:04] <jthornton> ok
[20:22:20] <andypugh> Actually, let me do a test compile first.
[20:22:34] <jthornton> please do :)
[20:37:26] -!- psha has quit [Quit: Lost terminal]
[20:45:17] -!- syyl has quit [Quit: Leaving]
[20:47:04] <jthornton> andypugh: I just grepped for </linux/slab.h> and don't see it used anywhere in EMC's code
[20:47:26] <andypugh> Skip the first /
[20:47:42] <jthornton> ok
[20:48:40] <jthornton> now it shows up
[20:56:05] -!- motioncontrol has quit [Quit: Sto andando via]
[20:56:05] <andypugh> Added to mesa_8i20.c and mesa_7i64.c it still compiles.
[21:00:22] -!- jtektool has quit [Quit: Visitor from www.linuxcnc.org]
[21:00:44] <jthornton> where did you add it?
[21:04:44] <jthornton> I guess if it is not a patch you don't get proper credit/blame
[21:05:17] <andypugh> I can make a patch, if it is easier.
[21:08:01] -!- rooks has quit [Read error: Operation timed out]
[21:22:05] <JT-Shop> yea, that would be best I think
[21:22:38] <JT-Shop> I still don't understand why you don't have commit access...
[21:22:53] -!- isssy has quit [Quit: Visitor from www.linuxcnc.org]
[21:24:08] <andypugh> Because i am not to be trusted :-)
[21:27:15] -!- kljsdfhklj_ has quit [Read error: Connection reset by peer]
[21:30:39] <JT-Shop> dang foreigners...
[21:30:53] <andypugh> (More seriously, I am still finding my way with Linux/C and I think it is a good idea for my stuff to be filtered by somebody with more clue.)
[21:31:36] <andypugh> I just wish it was easier toget a dialog going about commits.
[21:39:02] -!- kljsdfhklj has quit [Quit: kljsdfhklj]
[21:39:35] -!- FinboySlick has quit [Quit: Leaving.]
[21:41:11] -!- cncbasher_ [cncbasher_!~quassel@cpc8-hart9-2-0-cust686.11-3.cable.virginmedia.com] has parted #emc-devel
[21:41:20] -!- cncbasher has quit [Remote host closed the connection]
[21:50:22] <KimK> Hi Andy. I would normally be delighted to dialog about commits with you, or push something for you, or most anything else. Unfortunately, I'm trying to finish my edit of the Integrator Manual, last one of the bunch. I'm over 90% done, I think, maybe more. Done editing, looking for build errors now. And hoping one of the gurus figures out the "lack of cross-references" problem.
[21:53:03] <JT-Shop> KimK: is the Guru now on Docs :)
[21:53:26] -!- Fox_Muldr has quit [Ping timeout: 276 seconds]
[21:54:05] -!- cjdavis has quit [Ping timeout: 240 seconds]
[21:58:50] <KimK> JT-Shop: Ha! I'm only the guru of fooling AsciiDoc with workarounds. How "build docs" does all of the automagically scripted things that it does remains a mystery. We'll see how much damage everybody says I did after I push, lol!
[22:03:52] <JT-Shop> well at least you have the most experience with asciidoc besides psha
[22:05:51] <KimK> But all my experience is in the "driver's seat". I've only opened the hood and looked in once. I said, "Yikes!" and closed it.
[22:08:20] <andypugh> I am messing about with docs myself, moving the exported bspi functions from man9 to man3
[22:09:00] <KimK> I feel like the Wizard in that scene near the end where the the balloon gets away, and Dorothy shouts upward, "Come back! Come back!", and the Wizard says, "I can't, I don't know how it works!"
[22:11:13] <KimK> I made a list of the man3 functions and added it near the others for convenience. Not sure if yours made it in on that throw, but we can surely add it.
[22:12:37] -!- acemi has quit [Quit: WeeChat 0.3.2]
[22:21:44] -!- tom3p [tom3p!~tomp@r74-192-62-131.vctrcmta01.vctatx.tl.dh.suddenlink.net] has joined #emc-devel
[22:22:36] <CIA-9> EMC: 03seb 07v2.5_branch * r271269ac2edf 10/src/hal/drivers/mesa-hostmot2/ (mesa_7i64.c mesa_8i20.c): Add missing library.
[22:24:27] <KimK> Well, how about that! Is that it, Andy? Thanks, Seb! (Wherever you are.)
[22:25:26] <andypugh> I submitted that via Sourceforge bugs.
[22:25:44] <andypugh> The thing I want to discuss is the SPI driver architecture...
[22:30:01] -!- SWPadnos has quit [Changing host]
[22:30:01] -!- SWPadnos [SWPadnos!~Me@emc/developer/SWPadnos] has joined #emc-devel
[22:33:57] <KimK> Ah, yes, I'd like that too. Unfortunately, I have to run an errand that will take maybe 2 hrs and by that time it will be late there. I'll check with you as soon as I get back. If I don't make it back in time, then tomorrow, maybe?
[22:36:35] <KimK> Back in 5-10 minutes first.
[22:44:49] -!- isssy has quit [Client Quit]
[22:46:48] <KimK> OK, back, any parting comments?
[22:47:41] <JT-Shop> 2 more pieces of OSB done 6 left to go
[22:48:49] <KimK> Excellent. Back in a couple hours, maybe.
[22:57:16] -!- seb_kuzminsky [seb_kuzminsky!~seb@c-98-245-83-250.hsd1.co.comcast.net] has joined #emc-devel
[22:57:21] <seb_kuzminsky> hi folks
[22:58:19] <seb_kuzminsky> looks like our git history is confused - i'm trying to merge 2.5 into master, and there's a bunch of surprising conflicts
[22:59:41] <seb_kuzminsky> maybe related to cmorley's funny-looking merge of 2.5 and axis back in mid-april? I'm not sure
[23:00:37] -!- pjm__ has quit [Read error: Connection reset by peer]
[23:02:34] <andypugh> Hi Seb, thanks for the push.
[23:02:43] <seb_kuzminsky> sure, thanks for the patch :-)
[23:02:54] <seb_kuzminsky> now if only i could merge it into master...
[23:03:38] <andypugh> Any thoughts on whether a comp-based SPI sub-driver should export functions? (Did you see that email from Jeff a while back?)
[23:03:40] -!- tris has quit [Ping timeout: 248 seconds]
[23:03:59] <seb_kuzminsky> meh
[23:04:34] <seb_kuzminsky> i talked this over with jeff a while back, before you started working on it, and i remember we were in agreement on the way forward back then - a binary interface between the hostmot2 driver and the spi subdriver, in the kernel, outside of hal
[23:04:47] <seb_kuzminsky> i think i told you about this once
[23:04:58] <seb_kuzminsky> unless he or i have changed our minds since then, we still agree ;-)
[23:05:41] <andypugh> Actually, a bigger question. How do you feel about an extra TRAM phase? I am wondering about registering a set of writes to be run before the read, to clock-out SPI data.
[23:06:03] <SWPadnos> setup / read / write might make sense
[23:06:17] <andypugh> hm2_tram_register_pre_read_write or similar.
[23:06:45] <andypugh> Yeah, calling it "setup" might be shorter, even if it isn't, in this case.
[23:07:03] <seb_kuzminsky> i'm not fundamentally opposed to extending the hostmot2 driver if there's a good reason for it, but i don't know enough about what you're doing to tell you how i feel about it
[23:07:09] <seb_kuzminsky> and sorry, i dont have time to learn it right now
[23:07:17] <SWPadnos> busy - that's good :)
[23:07:28] <andypugh> I think it is fairly easy, and won't affect anything which doesn't use it
[23:07:43] <seb_kuzminsky> any extension to the hostmot2 driver should probably come after the hm2 subdriver patch-set i've got simmering here somewhere
[23:07:52] <SWPadnos> any timing questions/issues?
[23:08:14] <seb_kuzminsky> i'll have to get back to this git history cleanup later tonight
[23:08:17] <seb_kuzminsky> bye guys
[23:08:19] -!- seb_kuzminsky has quit [Quit: Leaving]
[23:08:36] <SWPadnos> (I'm assuming, also withoug learning exactly what you're doing, that the initial write is to (a) send something on the SPI port, or (b) setup some addresses in the FPGA or something)
[23:08:45] <SWPadnos> without
[23:08:59] <andypugh> Was that a "don't do anything in Hostmot2 until some undefined point in the future" demand?
[23:09:02] <andypugh> Bah!
[23:09:05] <SWPadnos> heh
[23:09:13] <SWPadnos> I think it was more like, err, well maybe :)
[23:09:44] <andypugh> SPI needs a write to clock back the read data.
[23:09:56] <SWPadnos> ok, so there are timing issues
[23:10:19] <SWPadnos> since you can't read back data until the write is finished being clocked out
[23:10:34] <andypugh> In the case of the 7i65 you need to write some dummy data to get the new data back, otherwise it comes a servo thread late.
[23:10:50] <andypugh> Yes, but no. :-)
[23:10:56] <SWPadnos> sure. how many bits/bytes are we talking about?
[23:10:59] <SWPadnos> ?
[23:11:42] <SWPadnos> what I meant is that the receive buffer won't have valid data until enough clocks have been sent
[23:12:19] <andypugh> It is more a case of putting some data in the FPGA FIFO to tell the SPI devices to write to the FPGA recieve registers. It happens in FPGA space, independent of the PC code.
[23:12:59] <SWPadnos> I'm thinking of the interface between the FPGA and the subdevice, not the interface between the PC and the FPGA
[23:13:20] <andypugh> It is a case of putting the 8 x 32 bit writes before the process_tram_read, rather than after the preapre_tram_write.
[23:13:57] <SWPadnos> PC writes data to FPGA, FPGA then needs to clock that data out on the SPI port, while also clocking in data on the SPI input pin
[23:14:08] <andypugh> I don't think that the actual data transfer time is going to show, it will typically happen at 8 - 25 MHz
[23:14:28] <SWPadnos> all of those SPI clocks must be completed before there is valid data for the PC to read
[23:15:14] <SWPadnos> well, 8x32 = 256 bits, which at 8 MHz is 32 uS, or at 25 MHz is ~1.3 uS
[23:15:20] <SWPadnos> err
[23:15:27] <SWPadnos> 10.4 us maybe :)
[23:15:35] <andypugh> Yes. At the moment it has 1000uS to write it all back, so no timing issue, but the data that is being read and used for the calcs is 1000uS stale.
[23:16:19] <SWPadnos> I understand the problem. I'm just pointing out possible issues (I do that, being an embedded engineer guy :) )
[23:16:55] <andypugh> I suspect that the first data is already back in the FIFO while Hm2 is writing the next register.
[23:17:18] <andypugh> We already cheat and squeeze 17 writes into a 16-element FIFO..
[23:17:20] <SWPadnos> sure, you might be able to read some data before it's all clocked back in
[23:17:25] <SWPadnos> heh
[23:17:52] <andypugh> Putting 8 writes up-front makes that inelegance go away at least.
[23:18:01] <SWPadnos> one goes into the shift register immediately, so you have another 16 to stuff into the buffer :)
[23:18:06] <SWPadnos> hmm
[23:18:28] -!- aggrav8d has quit [Ping timeout: 258 seconds]
[23:19:07] <andypugh> Arguably it is a non-issue with the 7i65 as the analogue voltages are probably not real-time relevant (unless you were reading tachs, I suppose). But with the Resolver card it might be a different thing.
[23:19:10] <SWPadnos> theoretically, you could read all the other data from the FPGA while the SPI data is being clocked in
[23:19:46] <SWPadnos> well, whether the data is relevant or not is irrelevant. the RT code has to be able to send and receive everything within the RT driver
[23:20:19] <andypugh> I was going to fill the write-fifo then do all the other Hostmot2 functions, and read the BSPI registers last.
[23:21:01] <SWPadnos> does the TRAM work that way? (ie, does it order and combine reads/writes by address, or can you tell it to do something last?)
[23:21:34] <andypugh> This would be a new phase of TRAM writes.
[23:22:31] <SWPadnos> I'm thinking of the reads
[23:22:43] -!- willburrrr2003 has quit [Quit: Beware of programmers who carry screwdrivers.]
[23:22:51] <SWPadnos> I guess the most generic thing to do might be to add flags/orders to the TRAM setup
[23:23:07] <andypugh> Currently the sequence is TRAM-read, gpio-process-read, encoder-process-read, stepgen, sserial, bspi, ...
[23:23:08] <SWPadnos> similar to thread ordering, you just give it a position in the queue
[23:23:23] <SWPadnos> ok, so it does things by module rather than by address, that's OK
[23:23:34] <andypugh> Actually, it might be simpler to look at hostmot2.c, line 82. That's the sequence there.
[23:23:59] <SWPadnos> if I were sitting on a Linux machine with the source code handy, that would be very simple :)
[23:24:04] <andypugh> Then there are all the prepare-writes for each module, then the TRAM write.
[23:25:01] <andypugh> Nice try: http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/hal/drivers/mesa-hostmot2/hostmot2.c;h=70f9b3e0cc238a1c9b82e9581daa5a76617e1ee4;hb=HEAD
[23:25:05] <andypugh> Line 82 :-)
[23:25:10] -!- aggrav8d has quit [Ping timeout: 252 seconds]
[23:25:40] <SWPadnos> oh. see now *that* is convenient :)
[23:26:58] <andypugh> There is a tram_write at line 109. I was going to define a third TRAM list, to be written before the TRAM read.
[23:27:04] <SWPadnos> I believe line 82 is what actually does all the reading. lines 85-88 just process the data
[23:27:37] <andypugh> But having now looked at it, your point is correct. We need enough gap between the new write, and the read.
[23:33:10] <SWPadnos> hmmm
[23:33:10] <andypugh> At the moment TRAM isn't TRAM anyway. It is meant to use DMA to write a memory block, and then the FPGA re-maps that data to internal registers. But neither end has actually been written that way.
[23:33:10] <SWPadnos> yeah, there's no way at the moment to let a module decide that there is no data available
[23:33:11] <SWPadnos> I think it's more meant as an abstraction to the data on the FPGA (Transfer RAM), since it also works with the parport-connected device(s)
[23:33:11] <SWPadnos> the data structures are the same regardless of the bus over which the data is transferred
[23:33:11] <andypugh> yes, and it makes more sense with the parport as it saves sending address data. TRAM is also only 16 bits wide, which might be why it hasn't been used.
[23:33:11] <SWPadnos> ?
[23:33:21] <andypugh> http://www.pastebin.ca/2073003
[23:35:58] <SWPadnos> huh. well I don't remember talking about that way back when :)
[23:37:21] -!- skunkworks [skunkworks!~chatzilla@str-bb-cable-south2-static-6-78.dsl.airstreamcomm.net] has joined #emc-devel
[23:43:37] <andypugh> I am thinking that I might just leave things as they are. It appears to work fine for the one current user...
[23:44:10] <SWPadnos> heh
[23:45:25] <SWPadnos> I think it would be great to have a couple of things added: 1) "pre-read" functions/writes/whatever; 2) "ready check" functions/reads/whatever, 3) user-ordered reads/writes
[23:45:44] <SWPadnos> I'm just thinking through what the SPI driver actually needs to do:
[23:45:49] <SWPadnos> write dummy data
[23:46:06] <SWPadnos> wait until that data is all clocked out (and the new data clocked in, of course)
[23:46:11] <SWPadnos> read data
[23:46:25] <SWPadnos> write new commands/data (the real write)
[23:46:44] <andypugh> The concept of waiting in the realtime threads makes my teeth itch.
[23:46:59] <SWPadnos> well, that's where the user ordering comes in handy
[23:47:40] <SWPadnos> it can even be almost smart, by having the consumer of the data provide an estimated time to the queue-up function
[23:48:16] <SWPadnos> so say 3 sub-functions register pre-read writes. they each say how long it's expected to take before their data is available
[23:48:29] <andypugh> In a vehicle ECU we would trigger the writes on a crank tooth sometime before needed.
[23:48:31] <SWPadnos> nearly instantaneously in the case of something that just has to ask for an update to happen
[23:48:38] <SWPadnos> slower for SPI or other serial
[23:48:50] <SWPadnos> the queue function sends the slowest command first, and reads its data last
[23:48:57] <SWPadnos> sure
[23:49:20] <SWPadnos> if EMC were a single-purpose system, we could use sub-clock "phases" also
[23:51:02] <andypugh> I think both ideas fall way outside my limited competence
[23:51:43] <andypugh> And my motivation. I don't even own any of the Mesa SPI cards.
[23:51:58] <SWPadnos> heh
[23:52:35] <SWPadnos> well, I have no SSPI peripheral cards. I'm motivated but have no time
[23:52:45] <SWPadnos> (I do have loads of Mesa cards though)
[23:53:39] -!- Loetmichel has quit [Ping timeout: 260 seconds]
[23:53:50] <andypugh> Time to sleep, I have to wrestle with faulty software in cars tomorrow. I am amazed that a company like Delphi can ship us a production software that doesn't actually fire injectors. You would imagine that they might do _some_ testing....
[23:54:08] -!- fjay has quit [Ping timeout: 276 seconds]
[23:54:20] -!- uwe_ has quit [Ping timeout: 244 seconds]
[23:55:22] -!- Tom_itx has quit [Ping timeout: 244 seconds]
[23:55:28] Tom_shop is now known as Tom_itx
[23:55:36] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust1037.basl.cable.virginmedia.com] has parted #emc-devel
[23:59:57] -!- robh__ has quit [Ping timeout: 252 seconds]