Am 20.11.18 um 21:38 schrieb Marc Schink:
>> Hi all,
>>
>> i started this discussion on the irc #openocd. As PaulFertser suggested,
>> lets move it to the mailing list.
>>
>> To make at least some of the commands more consistent, i decided to
>> rework adapter related part. Initial patch is here:
>> http://openocd.zylin.com/4774
> 
> Awesome, thanks for the (radical) work!

:) i hope not so many users will hate me..

>> adapter transports (set list of supported transports by adapter)
> 
> I don't get what this command actually does. Can you explain? Do we have
> a similar command at the moment?

commit 93f2afa45f4cfcb8afd08dae5a17996dba5c7a9c
Author: David Brownell <dbrown...@users.sourceforge.net>
Date:   Fri Jul 2 16:45:28 2010 -0400

    initial "transport" framework

    This adds the guts of a transport framework with initialization,
    which should work with current JTAG-only configurations (tested
    with FT2232).

    Each debug adapter can declare the transports it supports, and
    exactly one transport is initialized.  (with its commands) in
    any given OpenOCD session.

      * Define a new "struct transport with init hooks and a few
     "transport"  subcommands to support it:

         "list" ... list the transports configured (just "jtag" for now)
         "select" ... makes the debug session use that transport
         "init" ... initializes the selected transport (internal)

      * "interface_transports" ... declares transports the current interface
        can support.  (Some will do this from C code instead, when there are
        no hardware versioning (or other) issues to prevent it.

    Plus some FT2232 tweaks, including a few to streamline upcoming
    support for an SWD transport (initially for Luminary adapters).

    Eventually src/jtag should probably become src/transport, moving
    jtag-specific stuff  to transport/jtag.

    Signed-off-by: David Brownell <db@helium.(none)>


>> By "adapter khz" and "adapter transports", i'm not 100% sure. For the
>> firs one, I can imagine some thing like "adapter tclk rate <rate>".
> 
> I would vote for "adapter speed".

I would need some argumentation, why "speed" and not "khz" or "rate" or
"freq".

-- 
Regards,
Oleksij


_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to