Hello Laurent :-) On Thu, Jun 16, 2011 at 7:25 AM, Laurent Gauch <laurent.ga...@amontec.com> wrote: > BAD ! and WHY it is too JTAG-ONLY?
ask guys that wrote it, you mentioned helped in this ;-) > For me the queue_flush and execute_queue should be the mechanism to be used > for ALL transport, JTAG and new one as SWD. > As you can see, the queue management is done in the DRIVERs, since it is > dongle specific. should be, but if you look at the source code you will understand why creating generic bitstream and signal driving routines was more useful to implement ANY transport in a clean fashion rather than further expanding switch/case and additional structures. urjtag had this done from begining and it was almost trivial to implement swd and it is trivial to implement an other transport.. except its less use of it than in openocd. > I remember when I helped Dominic Rath, the author of openocd, about to > enqueue command for having a better download speed. > OpenOCD start with JTAG transport, but the mechanism of queue should be > present for any king of transport. who said there is no queue and there can be no optimalization in transfer()? > If not, we will degrade the transport speed. > We ALL know the pure bitbang is really bad when we talk about > "USB-x-transport" due to the latency of the USB. for ft2232 its using mpsse so there is one layer of data queueing in program memeory queue and then in mpsse chip buffer. if functionality is verified and functional you are entitled to optimise its efficiency.. now i concentrate to create clean and versatile design that works :-) > There are ways to have both SWD and JTAG passed in a queue of command, and > the same queue. By definition, a queue of commands is not related to any > transport. > The command queue just pack the command bytes to have a better speed, larger > byte packets. again noone said there is no queue. openocd commands are queued as they were, calling commands that call driver to flush data :-) >> the idea is to become transport independent, so the context and queue >> will be now part of given transport. > > SWD is specific data transport protocol as the JTAG, as the I2C, as the > 1-WIRE.. > If libswd is transport independent, why do you call it libswd. libswd is a standalone library that implements low level swd transport. the bridge between libswd and openocd (and its higher layers as target) must comply with current openocd design. libswd was already inegrated with urjtag using ONLY 4 functions (!). the case with openocd is different because organization of the program is different, much more complex. the modular design and independence of each of the components means that we have functional boxes that can be tied together, with no fear that when we remove one box the others wont work. > Or do you want to provide libjtag libswd libi2c lib1wire. In this case > openocd has jtag.c why not a swd.c ? yes! each transport will hava its own subdirectory or even library. there is still jtag.c because full code redesign and rewrite of openocd will take few months to accomplish, i have mentioned that, while as for now i just want o make swd work least invasive as possible. > Why did you not copy/paste and rename the the JTAG_ by SWD_ and call the > SWD_ from you libswd, instead to call JTAG functions from you libswd. > OK, this will duplicate the code in the driver, but that's will help to > introduce the SWD API. when the job is finished i can respond to such questions, right now i am repeating myself on things that are unfinished and might change soon :-) >> i wanted to rename this stuff before but it took too much >> time, so i decided to first make transport working and later >> reorganize openocd interals as time is limited... >> > > OK, time is limited. > But, the bad thing is that the SWD API is not yet specified. With Dominic > Rath, we have specified the JTAG API before implementing the specific driver the api is selected by ADIv5 and existing target implementation in a form of arm_adi_v5.c. just as it works for jtag iam working to make it work with swd. why it is undocummented like the rest of the code? ask the authors :-) if you want the api/reference to the libswd take look at the project website :-) Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
