Hi! I have just read through adiv5.1, and my understanding of the read operation is somewhat different:
I understood that after you read DRW register, it should return an ACK_OK, with unpredictable data. And on the next read of the register (even with TAR changed) it returns the data of the previous read operation, and issues the next request on the bus. If you do not want to issue another read, just read the RDBUFF register of the DP So in order to read address 0x1234 and 0x5678, you: Set up mem-ap, tar = 0x1234 Read DRW, get an ACK_OK (let's presume the read takes a lot of time) set up mem-ap, tar=0x5678 Read DRW, get an ACK_WAIT (last read is still pending). Read DRW, get an ACK_WAIT (...) .... (Read completes) Read DRW, get an ACK_OK. Now the SW issues a read to 0x5678, and returns the data at address 0x1234. (Read completes fast) Read RDBUFF, get an ACK_OK with data at address 0x1234. With writes, you get an ACK_OK first, and then on the next write (if the previous completed) you might get an ACK_FAULT, but that is because the first write operation failed for some readon (for ex. peripheral was not powered on, and generated a bus fault). Please say how this sounds, I'll look up the exact chapter numbers in the docuementation, if needed. Regards, Ákos On 13 March 2012 09:40, CeDeROM <cede...@tlen.pl> wrote: > 2012/3/13 Sven Krauss <sven.kra...@web.de>: >> sorry for my long time of inactivity doe to other jobs. A while ago I send a >> patch making arm_adi_v5.c independent from transport layer. I created a >> third solution: >> To preserve the performance I changed the interface to the transport layer. >> Both, dap_queue_ap_write and dap_queue_ap_read gets a pointer to a data >> array not a single value. The adi_v5_jtag now implements the loop reading >> the registers via jtag transport layer. So other transports like SWD can >> implement it's own efficient method reading a register multiple times. > > Yes, double pointers (or pointers array as you state) are mandatory > when executing/operating on eqneueued elements from the past and when > we don't want to flush the queue on each read, I found that out too > :-) I have considered that, but I don't want to change the API unless > absolutely necessary, so I try to find some other solution first, if > not possible, we need to change the API slightly. > > Anyway, the pointers will increase the efficiency, while the main > problem right now is the error handling and retry by the OpenOCD > itself... I hope anyone will take the challenge and implement it in > OpenOCD, until then I am working on error handling and retry at the > libswd/transport level, which seems to be a circus, but also seems it > started to work recently :-) > > Best regards :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > OpenOCD-devel mailing list > OpenOCD-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openocd-devel ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
