Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asus TSICT file format (.asc) #45

Open
piernov opened this issue Sep 4, 2016 · 3 comments
Open

Asus TSICT file format (.asc) #45

piernov opened this issue Sep 4, 2016 · 3 comments

Comments

@piernov
Copy link
Member

piernov commented Sep 4, 2016

Not an issue, just for keeping track of the supported formats.

I just implemented support for the *asc files. This format is plain text (not encoded). This format relies on a directory containing the following files: format.asc, parts.asc, pins.asc, nails.asc, nets.asc and sometimes a .bom file.
It is very similar with the .bdv format since in fact, the .bdv format is made with concatenated format.asc, pins.asc and nails.asc and encoded.
Basic implementation is available on my feat/asc-support branch and will be merged in inflex-ui-features. See inflex/OpenBoardView#43 and inflex/OpenBoardView#55 .
It supports loading format.asc, pins.asc and nails.asc only.

Attached is the binary and boardview files.

Asus F5V, r1.1.zip
X550CCR2.zip
ASUS TSIC.zip

piernov pushed a commit to piernov/OpenBoardView that referenced this issue Oct 27, 2016
Add (Github) repository owner and current branch in build info
@inflex
Copy link
Member

inflex commented Nov 2, 2016

Available now in the merged OBV R7.3 onwards.

Do we want to close this @piernov ?

@piernov
Copy link
Member Author

piernov commented Nov 2, 2016

We don't support all the information available in those files, but we can add them later as needed. I left the issue open to "document" about the supported formats. We should really write some pages in the Wiki (or elsewhere) about them…

@MattSturgeon
Copy link
Contributor

@piernov the README is a good place to list supported formats, if you want to go into more detail then the wiki makes sense

Regarding keeping"probably fixed" issues or similar open: my preference is to close the issue when you think it is fixed or finished to a "good enough" standard and then open new, smaller issues if needed in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants