On Wed, Jan 12, 2011 at 8:52 AM, David Brownell <davi...@pacbell.net> wrote: >> From: Peter Stuge <pe...@stuge.se> >> Subject: Re: [Openocd-development] SWD progress >> To: openocd-development@lists.berlios.de >> 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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
