In one sentence, as my preference for future extendability I have
chosen approach that involves modular design with external submodules
(just like in object programming) rather than extending one big
structure (i.e. command queue) like it was done before. This should
allow adding new functionalitie
Hello Gary :-)
On Tue, Aug 23, 2011 at 3:43 PM, Gary Carlson
wrote:
> I think the solution with high-level interfaces is to allow them to do their
> bitstream magic directly if they have that capability and for low-level
> interfaces turn to libswd or other future libraries for other transports.
Hi Tomek,
I think the solution with high-level interfaces is to allow them to do their
bitstream magic directly if they have that capability and for low-level
interfaces turn to libswd or other future libraries for other transports. I
have doubts about the feasibility of trying to make most high-
Hello Gary :-)
On Tue, Aug 23, 2011 at 2:24 AM, Gary Carlson
wrote:
> I have zero prior experience with the FT2232 so I took a very brief scan of
> its driver code. I get the feeling that this type of device allows fairly
> low-level access to interface port pins. If this is true I can see the
Hi Tomek,
I have zero prior experience with the FT2232 so I took a very brief scan of
its driver code. I get the feeling that this type of device allows fairly
low-level access to interface port pins. If this is true I can see the
logic behind a bitbang function as this provides the generic abst
Thank you for this hint on printing pointers! :-) Although there is no
word about "%p" in the manual, it works on FreeBSD so it should also
work on MacOSX as it is derivative :-)
With LOG_INFO("New SWD context initialized at %p", (void
*)jtag_interface->transport->ctx); we get:
%telnet localhost
On Mon, Aug 22, 2011 at 8:23 AM, Carlson Gary
wrote:
> [...]
> I seem to have a faint recollection that a few non-gnu compilers don't
> always support "%p" as a formatting code.
Hu...
I run a quick and not exhaustive check.
%p is part of ANSI C, at least in latest versions. Cannot find when i
Antonio,
Yes...I concur. That is a better solution as it is agnostic to bus width
and lets each platform compiler deal with the issue more cleanly. The
solution I proposed admittedly would still be a problem on some
architectures.
I seem to have a faint recollection that a few non-gnu compilers
On Mon, Aug 22, 2011 at 7:21 AM, Tomek CEDRO wrote:
> Hello Carlson and thank you for your support! :-)
>
> On Sun, Aug 21, 2011 at 9:09 PM, Carlson Gary
> 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
Hello Carlson and thank you for your support! :-)
On Sun, Aug 21, 2011 at 9:09 PM, Carlson Gary
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 numb
Hi Tomek,
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
Some more information on details/usage in [1]. Target use TAP for JTAG
and DAP for SWD, so we need to create union containing both inside
with common API, or initialize only one of them at time and null other
to let know which one is in use, or create null pointer and cast it
based on transport typ
On Fri, Aug 19, 2011 at 1:09 AM, Carlson Gary
wrote:
> (...)
> Debug: 35 45 command.c:151 script_debug(): command - ocd_transport
> ocd_transport select swd
> Error: 36 45 target.c:435 get_current_target(): BUG: current_target out
> of bounds
Hello Gary, did you try the openocd-libswd fork or
I have an Energy Micro EFM32 Gecko board in my hands at the moment that
provides a SWD debug interface (no JTAG). With some level of SWD support
now available in OpenOCD, I was a little curious how much effort it would
take to bridge this over to the EFM32 evaluator with its onboard jlink.
To tha
14 matches
Mail list logo
