I just added support for bitfields. It defines the _SHIFT, _MASK and specific value definitions, as well as description as a comment. I tried to be clever about when not to print obvious values and to maintain a reasonable formatting. I think it works pretty well. You can see the output for RADIO peripheral here:
https://gist.github.com/v01d/6e5afc8ff922f6d0240c390540f21827 Feel free to submit issues in the gitlab project if you find any problem and have a suggestion to improve it. Best, Matias On Fri, Jul 3, 2020, at 21:28, Matias N. wrote: > I agree with your understanding. I followed the same reasoning. If this data > is on a public datasheet, the header is indistinguishable from one manually > created from the SVD. Unless the text description of each register is > considered > some kind of original artwork, but that could be even omitted if desired. > > Best, > Matias > > On Fri, Jul 3, 2020, at 20:52, Gregory Nutt wrote: >> >> > I just looked at that header and looks like a "no warranty" disclaimer. >> > Does not impose any restriction on generation code based on that file. >> >> I am not an attorney and not qualified to give a legal opinion. But that >> has never stopped me before. >> >> A copyright covers the presentation of a materials, not the content of >> materials. If using the same definitions as are provided by one header >> file in another header file were a breach of some copyright, the whole >> world would be in trouble. 'Wine' duplicates windows definitions for >> compatibility. Linux duplicates some BSD definitions for compatibility >> for BSD and POSIX definitions compatibility. NuttX duplicates some >> Linux definitions for compatibility. >> >> There was a a lawsuit about this several decades ago when when Unix >> claimed that it owned all of the Unix interface definitions. That suit >> failed and it was ruled that you cannot copyright an interface. So we >> are free to define compatible interfaces without concern for copyright >> issues. >> >> Another related case had to do with bitmap fonts of traditional fonts >> like Times Roman. Scalable fonts can be protected because the scaling >> is an algorithm; custom bit map fonts can be protected because they are >> original artwork. But bitmaps of traditional fonts cannot be protected >> because they are neither. >> >> In my "legal opinion", I would think that that all of these apply. >> Register definitions define an interface and that interface is openly >> documented in various sources. We know that creating header files from >> those openly documented specs is acceptable (we do that all of the >> time). So I cannot see that there could be a legal issue with >> automatically generating Apache 2.0 header files from those XML files. >> >> You might ask the position of the person that claims ownership of those >> XML files, but I cannot see how the license on the XML files that >> contain a public interface definition could limit our freedom to >> generate our own header files for that public interface provided that we >> do not re-distribute the copyrighted XML files. Justin certainly will >> have a different opinion. >> >> Greg >> >> >> >> >
