For SWD transaction layer, only 3 operation is needed. 1. initializaion/finalization/config(set trn) 2. output sequency on SWD, which is used to make adi into SWD mode. 3. The other is the transaction itself, including read and write operation.
Any other applicapable feature? 2011/1/12 Tomek CEDRO <[email protected]> > On Wed, Jan 12, 2011 at 8:52 AM, David Brownell <[email protected]> > wrote: > >> From: Peter Stuge <[email protected]> > >> Subject: Re: [Openocd-development] SWD progress > >> To: [email protected] > >> Date: Tuesday, January 11, 2011, 11:06 PM > >> simon qian wrote: > >> > SWD in Versaloon is based on operation. > >> > For example: A read operation consists of : > >> > 1. Host send the 8-bit command, and trn > >> > 2. read 3-bit ack > >> > 3. read the 32-bit data and 1-bit parity > >> > 4. host send the last trn > >> > > >> > So Versaloon can do some error handler. > >> > >> Tomek, does it sound like this is similar to what libswd > >> outputs? > > Correct :-) These are the basic bus operations, wehere trn and parity > bit is also an operation in libswd for easier implementation (also > bitbang/bistream flush can be used from char array). Data can be > directly queued up on the *cmdq (command bidirectional queue) or first > bitstream can be generated for those operations and then queued up on > the *cmdq - there are helper functions already implemented that > realize this bistream, so no need to write them from scratch - ie. you > only need to provide addres, operation type and access port and helper > function will build request - then the request byte can be put on the > queue. This way we can put data on the queue and have good overview of > what is happening on the bus (swd-viewer), also something like svf > record can be done, wehere all transactions are stored on the queue > and then flushed out to file and then replayed with external software. > > > Sounds like a bit-level description of most any > > SWD wire transaction... > > If versalon driver needs packey payload anywas and does not construct > it itself, then you can use libswd helper functions to easily create > those data. If so it perfectly matches current libswd abilities, but > the problem also might occur when it is the cable itself that > constructs the bitstream from parameters like address, access port, > etc. > > >> In that case it might be easy to abstract > >> libswd/versaloon. > > Exactly! I am aware that still libswd is not yet functional but it > will be in a short time. Also this is good time to request > functionalities :-) > > >> How is this not already done in the SWD > > transpsort defs? Implementations of the SWD > > ops to read/write registers must do those > > bitop sequences as driver ops. > > The trick is that libswd can be standalone, it was written for another > purpose, but the integration with other utilities is critial, so I > have created something like abstraction layer - where there are > functions that can do TRN, BIT8 read/write and BIT32 read/write. The > trick is to have as low functions as possible that could flush the > queue out/into physical driver (or anything other utilizing existing > higher level drivers). TRN must be separate function to work on the > interface buffers. bit shift can be input or output and done from char > and int data type, so I have created two functions that will flush > n-bits, lsb/msb-first from char and int type. These functions are > driver specific, located in external file and separate for openocd, > urjtag and others.. please tahe a look at libswd_drv.c but these > functions are still open for constructive criticism as work in > progress (unfinished) :-) > > I hope this libswd organization is not too complex and in some ways > comfortable - if it prove itself, maybe after some modifications (and > lots of bugfixes), these utilities would be able to easily create > other serial transports such as spi, i2c, 1wire, and many others using > exiting cables that we already own :-) > > Best regards! :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > _______________________________________________ > Openocd-development mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/openocd-development > -- Best Regards, SimonQian http://www.SimonQian.com
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
