Peter C. Wallace pravi: > On Thu, 1 Apr 2010, Peter C. Wallace wrote: > > >> Date: Thu, 1 Apr 2010 08:34:34 -0700 (PDT) >> From: Peter C. Wallace <p...@mesanet.com> >> Reply-To: EMC developers <emc-developers@lists.sourceforge.net> >> To: EMC developers <emc-developers@lists.sourceforge.net> >> Subject: Re: [Emc-developers] EPP timeout >> >> On Thu, 1 Apr 2010, Slavko Kocjancic wrote: >> >> >>> Date: Thu, 01 Apr 2010 10:25:24 +0200 >>> From: Slavko Kocjancic <esla...@gmail.com> >>> Reply-To: EMC developers <emc-developers@lists.sourceforge.net> >>> To: EMC developers <emc-developers@lists.sourceforge.net> >>> Subject: [Emc-developers] EPP timeout >>> >>> Hello... >>> >>> As I have near finished driver for EPP boards I have one problem. As >>> computer >>> is common staretd with CNC machine off the EPP board respond to al IO with >>> timeout. EPP timeout is aprox 10uSec. So if I wan't to write 5 bytes that >>> can >>> least over 50uSec. And in that case the computer freeze. The solution seems >>> to be to check EPP timeout after every IO. That's works but make big >>> overhead. On my EPP board (sem's to be slowest one) the fastest cycle is 2uS >>> long. The timeout is on aprox 11uS. But the read from status port (to check >>> timeout) least 1.5uS. So if I get that approach then I have (for 3/3 byte >>> IO) >>> 6 x 2.0uS 12uS for real IO >>> 6 x 1.5uS 9uS overhead to check Timeout >>> total 21uS and system got little slower already >>> >>> Then I realize that checking how long in/out can be faster. >>> So if write_board routine take more than predetermined time to execute then >>> execution shall be aborted and checked what's realy wrong. >>> >>> maybe the best way is to check if out/inp routine take more than 5uS. If is >>> more then probably is something wrong. >>> >>> in write_board there is argument PERIOD. I can't find what is this. Time ?!? >>> >>> I have only RDTSC instruction in mind but afraid to use as can be dissabled >>> (privileged) >>> >>> Can someone help?? >>> >>> >>> >>> And here is working (but unfinished) driver hal_eppport.c >>> >>> >>> >>> >> EPP timeout is per single byte transfer. You should not get a timeout error >> regardless of how long a burst of transfers lasts. If you are getting EPP >> timeouts, I would check your hardwares handshaking. Also good to notice the >> difference between EPP1.7 and EPP1.9 >> >> >> Peter Wallace >> Mesa Electronics >> >> > > Oh, I didnt read the top of your message carefully, you are saying that the > card is off at startup so you get timeouts and you have this running in a > fast base thread so you use up all available CPU time. > > Maybe your driver can just do a single test I/O cycle each thread until it > gets a good transfer (no timeout) and then enable the full data transfer. If > it ever gets a timeout when running (check at end of block), you could go > back > into the "wait for good transfer" mode > >
I just try something like this. I read driver for mesa but seems that board must be on before emc else will fail. (fpga prog) As here are simple driver I wan't to alow the emc2 and after that machine on. As I know the timeout is latched. So I can make burst of few bytes and check at the end if timeout was. That's work. But if timeout ocur in 1'st byte then other 4 just make time long enought to triger rtapi error that can't do the work. So now I trying to get measurment for each IO and if last too long I triger error state and alow to be examined what happends in next cycle's. seems to be working.. just need little polishing.. Slavko. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
