On Mon, Jan 28, 2013 at 2:25 PM, Laurent Gauch <[email protected]> wrote: > Asychronous io access is not the problem, the problem is how to > implement using it, in the goal to accelerate the JTAG and or SPI SWD > ... :-) > Also, we do not need true asynchronous io. Non-blocking fonction is not > so important here. But we have to think more about the access gestion -> > pipelining the access -> and let the host computer and the dongle as the > Amontec JTAGkey-2 to work as two prosess and not as one process, like now !
Hello Laurent :-) Can you please explain how would two process increase performance and why? How is asynchronous access currently implemented? What I understand synchronous access takes place on the clock edges. So we need to wait for "time slot". Asynchronous driver can send data as they appear. Lets say Target want to get a register, so it sends request to the adapter, which sends out bitsream and read the result. If we do is in an asynchronous manner we can get write and read "asap" in case of synchronous access we need to wait for time slot to write and next time slot to read. My question is - what is the current flaw in this design or implementation? How would two processes increase efficiency if one will neverthless need to wait for another? Thanks for your explanations :-) > The ft2232.c has the advantage to include the layout specific things. > Tomek will say this is bad. Again, I will say this is good to have this > hardcoded for stability for the end users. I did not say layout bad!!! I said hardcoding stuff is bad :-) This again relates to the swd misunderdstanding. Spen suggested that I should modify my code so there is only one configuration per ft2232 interface. I explained this is impossible because layouts are already hardcoded for JTAG transport, different layout is required for SWD, different Transport, etc, so another configuration files will show up. I have simply created swd_interface to reduce invasion into current code and decrease permutations from three variables (interface, transport, layout) into one (interface/layout).This is why I have said that I will not modify that part of the code, because it is optimal solution in this particular case, because I prefer to develop new driver based on mpsse-libusb.c that is more flexible. ft2232.c is considered obsolete and that change would be too drastic for the project and this is not really required :-) I prefer to work on the code that will use mpsse-libusb.c and allow to put more (if not all) configuration into TCL. Layouts are okay. Features are okay. Transports are okay. All desired functions are okay. The more we put into script not the hardcode the more flexibility we gain and those simple values can be easily put into scripts because there is no efficiency dependency over here :-) Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
