Re: [Openocd-development] SVF to XSVF Converter, and Patches

[Rick Altherr]

On Dec 12, 2008, at 8:51 AM, Dick Hollenbeck wrote:

Hello,

Please let me introduce myself.  I am an embedded developer of 25
years.  Software is my thing.


your xsvf.c.



Questions:

1)  How do you receive patches, simply as an attachment to this list?
Or is there a better way?

I wrote an SVF to XSVF converter in python and it is at a point where it needs testing. While I am doing that I am improving the diagnostics in

Generate a diff using the Subversion 'svn diff' command. It is best to make the diff against trunk since things have been changing quickly. Send the diff as an attachment to the list and we will review and commit it.

2) What is your editor tabs vs. spaces policy, any style document

tabs, which I normally do not use.  Suggestions on a filter to run
through before sending would be helpful.  Jedit is an outstanding
editor, but I think most folks use it with spaces.

available. Jedit is what I use, and it is having a damn hard time with

As far as I can tell, there is no established standard. I would love to institute one.

a separate directory?  I also have an XSVF file dumper to show the
contents of the XSVF file, also written in python.

3) Do you want the SVF to XSVF converter as part of this project, say in

These could be useful, but might not be entirely appropriate as part of OpenOCD. I'll leave it up to others for commentary.

4) Under what circumstances would a person get write permission to the
repository?

Contribute frequently and ask nicely.

5) Why the short names for the "enum tap_state"s?  These are simply

spec from ASSET InterTech, Inc.   For example TAP_E2D which is
ridiculously cryptic, would become TAP_DREXIT2.

enums, they don't control the size of the generated code, but as chosen they are way too cryptic for most humans. I would suggest a global edit to TAP_<SVF STATE> where <SVF STATE> is the same spelling as in the SVF

I would support such a change. Feel free to provide a patch that has this change only. Make sure to catch all the uses across the entire source base.

Thanks in advance,

Dick Hollenbeck


_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

--
Rick Altherr
kc8...@kc8apf.net


 -- Unsigned

"He said he hadn't had a byte in three days. I had a short, so I split it with him."

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development