Hello Carlson and thank you for your support! :-) On Sun, Aug 21, 2011 at 9:09 PM, Carlson Gary <gcarl...@carlson-minot.com> wrote: > I didn't realize there was a fork for SWD support, so my original attempt > was based on the master branch. Nevertheless I cloned the fork that you > indicated and immediately ran into a number of compiler issues trying to > compile it on a Mac OS X platform. The patch attachment covers most of the > changes necessary to address those problems. These should be neutral for > other platforms, but you may want to make sure. > (..)
Thank you for your patches Ill take look at them, test and apply where possible, also update the libswd.h as you stated so its ready to use from submodule :-) > The single change in the header plus those listed in the patch file allowed > me to successfully compile openocd from the fork on OS X. But unfortunately > the problems did not end there. After a successful build, running the tool > gets a little further then before, but still bombs out fairly quickly: > (..) Yes, as for now the transport-target integration is not yet complete (and the adi_v5_swd is not my code so I cannot confirm if its working, there were some things I didnt like about it), only the dirver-libswd to make transport work, stay tuned, work in progress :-) If you have good insight on JLink and maybe other high-level command-based devices (like RLink) please concentrate on implementing drivers API for those devices that will allow generic access to the bus with "bitbang" and "transfer" operations as implemented for FT2232 cables in "interface" structure. Only FT2232 cables are now capable to run SWD with libswd as all drivers were designed to work only with JTAG having jtag-specific calls I had to implement some generic functions that could allow transports other than JTAG - this is why "bitbang" (set selected bitmask on selected port pins) and "transfer" (send/receive data stored in *char) was created and should do the job for device with no logic that know nothing about SWD (or other transport). This is why we need to create drivers using bitbang and transfer for high-level interfaces, or something else that would allow generic access to the bus and transport implementation. This way we should be able to implement any possible transport on any possible interface :-) Please let me know if the bitbang and transfer is enough for high-level interfaces to implement the transport.. If so it would be nice to see "bitbang" and "transfer" implementation for interfaces other than FT2232. 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
