Hello Evan :-)
Please take a look at http://stm32primer2swd.sf.net to see my ideas on what
you proposed, I also wondered on that :-)
OpenOCD needs more general reorganization than just next modification of
the structures. I would propose to first set a functional blocks, set the
information flow, set the API, then code it.
Functional blocks would be openocd_ctx, interface, transport, target,
memory, os, ... OpenOCD would be context centric and the context would hold
all necessary data like interface driver and target
configuration/functions. This will not only allow to use different
interfaces at time but also many targets and maybe openocd threads...
Maybe using objects and virtualization would be some better solution, maybe
pure C is enough :-)
Do you like my idea on organization? This would dramaticaly increase
understanding on what happens where and when, which will help in tracing
problems and adding new features... which seems really rough task at the
moment.
Best regards :-)
Tomek Cedro
Ps/2: have you verifies the bitbang and transfer implementation possibility
in rlink drivers I asked you recently? :-)
On Nov 5, 2012 4:42 AM, "Evan Hunter" <[email protected]> wrote:
> Hi all,****
>
> ** **
>
> I would like to modify the adapter driver interfaces to allow per-instance
> driver variable structures.****
>
> ** **
>
> This would:****
>
> **· **Get rid of loads of static and global variables.****
>
> **· **Allow multiple interfaces****
>
> ** **
>
> The proposed prototypes below mostly add this per-instance variable as an
> instance handle.****
>
> Drivers could keep using the current system and be modified when suitable
> to use the per –instance parameters.****
>
> ** **
>
> Is this something that is wanted? ****
>
> Do you have any thoughts on the proposed organisation below?****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Evan****
>
> ** **
>
> Proposed interface driver prototypes:****
>
> {****
>
> char *name;****
>
> const char **transports;****
>
> const struct swd_driver *swd;****
>
> const struct command_registration *commands;****
>
> ** **
>
> int (*create)(Jim_GetOptInfo *options, int interface_num,
> adapter_handle_t *new_handle);****
>
> int (*destroy)(adapter_handle_t handle);****
>
> ** **
>
> int (*init)(adapter_handle_t handle);****
>
> int (*quit)(adapter_handle_t handle);****
>
> ** **
>
> int (*speed)(adapter_handle_t handle, int speed);****
>
> int (*power_dropout)(adapter_handle_t handle, int
> *power_dropout);****
>
> int (*srst_asserted)(adapter_handle_t handle, int
> *srst_asserted);****
>
> ** **
>
> /* JTAG functions - to be split out into separate
> structure soon */****
>
> int (*execute_queue)(adapter_handle_t handle, struct
> jtag_command *cmd_queue);****
>
> int (*khz)(adapter_handle_t handle, int khz, int
> *jtag_speed);****
>
> int (*speed_div)(adapter_handle_t handle, int speed, int
> *khz);****
>
> ** **
>
> };****
>
> ** **
>
> ** **
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> OpenOCD-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
>
>
------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
