Re: SVD -> header generator
Greg, I agree with your point here– that these files are another kind of data sheet, and that it is ok to generate header files and other code from them. -adam On Fri, Jul 3, 2020 at 4:52 PM 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 > > > > -- Adam Feuer
Re: SVD -> header generator
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 >> >> >> >> >
Re: SVD -> header generator
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 > > > >
Re: SVD -> header generator
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
Re: SVD -> header generator
Both of these I also linked are far more restrictive: https://raw.githubusercontent.com/posborne/cmsis-svd/master/data/STMicro/License.html TI is another example with further restrictions. https://github.com/posborne/cmsis-svd/blob/master/data/TexasInstruments/TM4C123GH6ZRB.svd --Brennan On Fri, Jul 3, 2020, 4:29 PM Matias N. 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. > > On Fri, Jul 3, 2020, at 18:25, Brennan Ashton wrote: > > Just a warning on generating code from these files. Many of the have > > explicit restrictions on using them which may not be compatible with BSD > or > > Apache. For example NXP > > > https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd > > > > I'm not sure on the legal side about this but it is why I have avoiding > > using them to generate headers. Maybe Apache Legal could give us > guidance. > > > > --Brennan > > > > On Fri, Jul 3, 2020, 1:45 PM Matias N. wrote: > > > > > Hi, > > > I thought about doing this for a long time and I just did it, wasn't > > > really hard. > > > If you're not aware, CMSIS-SVD file format is an XML based definitions > of > > > peripherals and registers available in a given MCU. This is typically > used > > > for debugging but it is quite useful for generating header > definitions. I > > > wrote a quick python script that is able to generate register > definitions > > > and base addresses of peripherals. It is based on > > > https://github.com/posborne/cmsis-svd which includes both the SVD > python > > > parser and a really complete database of SVD files. > > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen > (be > > > sure to check the README on how to use) > > > > > > Example output (the console output properly tabulates data, format may > > > look broken in the email): > > > > > > Generate memory map: > > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > > > > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > > > ... etc > > > > > > Register definitions: > > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > > > > > /* Register offsets > > > */ > > > > > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > > > mode.*/ > > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > > > mode.*/ > > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > > > ... etc > > > > > > /* Register definitions > > > */ > > > > > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_TXEN_OFFSET) > > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_RXEN_OFFSET) > > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_START_OFFSET) > > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_STOP_OFFSET) > > > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_DISABLE_OFFSET) > > > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_RSSISTART_OFFSET) > > > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_RSSISTOP_OFFSET) > > > ... etc > > > > > > Best, > > > Matias > > >
Re: SVD -> header generator
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. On Fri, Jul 3, 2020, at 18:25, Brennan Ashton wrote: > Just a warning on generating code from these files. Many of the have > explicit restrictions on using them which may not be compatible with BSD or > Apache. For example NXP > https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd > > I'm not sure on the legal side about this but it is why I have avoiding > using them to generate headers. Maybe Apache Legal could give us guidance. > > --Brennan > > On Fri, Jul 3, 2020, 1:45 PM Matias N. wrote: > > > Hi, > > I thought about doing this for a long time and I just did it, wasn't > > really hard. > > If you're not aware, CMSIS-SVD file format is an XML based definitions of > > peripherals and registers available in a given MCU. This is typically used > > for debugging but it is quite useful for generating header definitions. I > > wrote a quick python script that is able to generate register definitions > > and base addresses of peripherals. It is based on > > https://github.com/posborne/cmsis-svd which includes both the SVD python > > parser and a really complete database of SVD files. > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be > > sure to check the README on how to use) > > > > Example output (the console output properly tabulates data, format may > > look broken in the email): > > > > Generate memory map: > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > > ... etc > > > > Register definitions: > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > > > /* Register offsets > > */ > > > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > > mode.*/ > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > > mode.*/ > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > > ... etc > > > > /* Register definitions > > */ > > > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_TXEN_OFFSET) > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RXEN_OFFSET) > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_START_OFFSET) > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_STOP_OFFSET) > > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_DISABLE_OFFSET) > > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RSSISTART_OFFSET) > > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RSSISTOP_OFFSET) > > ... etc > > > > Best, > > Matias >
RE: SVD -> header generator
Hi Matias, > I thought about doing this for a long time Yes So many times...Thank you for doing it! David -Original Message- From: Matias N. [mailto:mat...@imap.cc] Sent: Friday, July 03, 2020 1:45 PM To: dev@nuttx.apache.org Subject: SVD -> header generator Hi, I thought about doing this for a long time and I just did it, wasn't really hard. If you're not aware, CMSIS-SVD file format is an XML based definitions of peripherals and registers available in a given MCU. This is typically used for debugging but it is quite useful for generating header definitions. I wrote a quick python script that is able to generate register definitions and base addresses of peripherals. It is based on https://github.com/posborne/cmsis-svd which includes both the SVD python parser and a really complete database of SVD files. The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be sure to check the README on how to use) Example output (the console output properly tabulates data, format may look broken in the email): Generate memory map: $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ ... etc Register definitions: $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 /* Register offsets */ #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX mode.*/ #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX mode.*/ #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ ... etc /* Register definitions */ #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_TXEN_OFFSET) #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_RXEN_OFFSET) #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_START_OFFSET) #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_STOP_OFFSET) #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_DISABLE_OFFSET) #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_RSSISTART_OFFSET) #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_RSSISTOP_OFFSET) ... etc Best, Matias
Re: SVD -> header generator
It seems really strange to me that the output file of a code generator tool is something that would be within the scope of a license of the SVD file itself. If I were to write that same output myself by hand what would be different? Anyway, we can look further into the validity of that licensing restriction before using it. Regarding bitfields, it is indeed possible since they are part of the SVD files. I just haven't worked on that yet. I will look into it. Best, Matias On Fri, Jul 3, 2020, at 19:35, Adam Feuer wrote: > Brennan, > > Ah, I see. The data files all have their own individual licenses, yes, some > are not open source. Ugh. > > Yeah, I wouldn't use a tool to generate it unless the data file was using a > compatible license... > > -adam > > On Fri, Jul 3, 2020 at 3:30 PM Brennan Ashton > wrote: > > > They are not all Apache 2.0. The NXP ones are a mixed bag, some call > > out BSD, some just liability disclaimer, looks like the example I gave > > was not the best one. > > > > For STM this file is restricted in a way that is not compatible. > > Personally I think that is a mistake on the part of STM, but here we > > are... > > > > https://raw.githubusercontent.com/posborne/cmsis-svd/master/data/STMicro/License.html > > > > TI is another example with further restrictions. > > > > https://github.com/posborne/cmsis-svd/blob/master/data/TexasInstruments/TM4C123GH6ZRB.svd > > > > --Brennan > > > > On Fri, Jul 3, 2020 at 3:19 PM Adam Feuer wrote: > > > > > > Brennan, > > > > > > All the files in this repo are Apache 2.0 licensed: > > > > > > https://github.com/posborne/cmsis-svd/blob/master/LICENSE-APACHE > > > > > > Doesn't that cover the license issue? The header is only a liability > > > disclaimer. > > > > > > -adam > > > > > > > > > > > > On Fri, Jul 3, 2020 at 2:25 PM Brennan Ashton > > > > > wrote: > > > > > > > Just a warning on generating code from these files. Many of the have > > > > explicit restrictions on using them which may not be compatible with > > BSD or > > > > Apache. For example NXP > > > > > > https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd > > > > > > > > I'm not sure on the legal side about this but it is why I have avoiding > > > > using them to generate headers. Maybe Apache Legal could give us > > guidance. > > > > > > > > --Brennan > > > > > > > > On Fri, Jul 3, 2020, 1:45 PM Matias N. wrote: > > > > > > > > > Hi, > > > > > I thought about doing this for a long time and I just did it, wasn't > > > > > really hard. > > > > > If you're not aware, CMSIS-SVD file format is an XML based > > definitions of > > > > > peripherals and registers available in a given MCU. This is typically > > > > used > > > > > for debugging but it is quite useful for generating header > > definitions. I > > > > > wrote a quick python script that is able to generate register > > definitions > > > > > and base addresses of peripherals. It is based on > > > > > https://github.com/posborne/cmsis-svd which includes both the SVD > > python > > > > > parser and a really complete database of SVD files. > > > > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen > > (be > > > > > sure to check the README on how to use) > > > > > > > > > > Example output (the console output properly tabulates data, format > > may > > > > > look broken in the email): > > > > > > > > > > Generate memory map: > > > > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > > > > > > > > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > > > > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > > > > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > > > > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > > > > > ... etc > > > > > > > > > > Register definitions: > > > > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > > > > > > > > > /* Register offsets > > > > > */ > > > > > > > > > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > > > > > mode.*/ > > > > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > > > > > mode.*/ > > > > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > > > > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > > > > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > > > > > ... etc > > > > > > > > > > /* Register definitions > > > > > */ > > > > > > > > > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > > > > > NRF51_RADIO_TASKS_TXEN_OFFSET) > > > > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > > > > > NRF51_RADIO_TASKS_RXEN_OFFSET) > > > > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > > > > > NRF51_RADIO_TASKS_START_OFFSET) > > > > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > > > > > NRF51_RADIO_TASKS_STOP_OFFSET) > > > > > #define
Re: SVD -> header generator
Brennan, Ah, I see. The data files all have their own individual licenses, yes, some are not open source. Ugh. Yeah, I wouldn't use a tool to generate it unless the data file was using a compatible license... -adam On Fri, Jul 3, 2020 at 3:30 PM Brennan Ashton wrote: > They are not all Apache 2.0. The NXP ones are a mixed bag, some call > out BSD, some just liability disclaimer, looks like the example I gave > was not the best one. > > For STM this file is restricted in a way that is not compatible. > Personally I think that is a mistake on the part of STM, but here we > are... > > https://raw.githubusercontent.com/posborne/cmsis-svd/master/data/STMicro/License.html > > TI is another example with further restrictions. > > https://github.com/posborne/cmsis-svd/blob/master/data/TexasInstruments/TM4C123GH6ZRB.svd > > --Brennan > > On Fri, Jul 3, 2020 at 3:19 PM Adam Feuer wrote: > > > > Brennan, > > > > All the files in this repo are Apache 2.0 licensed: > > > > https://github.com/posborne/cmsis-svd/blob/master/LICENSE-APACHE > > > > Doesn't that cover the license issue? The header is only a liability > > disclaimer. > > > > -adam > > > > > > > > On Fri, Jul 3, 2020 at 2:25 PM Brennan Ashton > > > wrote: > > > > > Just a warning on generating code from these files. Many of the have > > > explicit restrictions on using them which may not be compatible with > BSD or > > > Apache. For example NXP > > > > https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd > > > > > > I'm not sure on the legal side about this but it is why I have avoiding > > > using them to generate headers. Maybe Apache Legal could give us > guidance. > > > > > > --Brennan > > > > > > On Fri, Jul 3, 2020, 1:45 PM Matias N. wrote: > > > > > > > Hi, > > > > I thought about doing this for a long time and I just did it, wasn't > > > > really hard. > > > > If you're not aware, CMSIS-SVD file format is an XML based > definitions of > > > > peripherals and registers available in a given MCU. This is typically > > > used > > > > for debugging but it is quite useful for generating header > definitions. I > > > > wrote a quick python script that is able to generate register > definitions > > > > and base addresses of peripherals. It is based on > > > > https://github.com/posborne/cmsis-svd which includes both the SVD > python > > > > parser and a really complete database of SVD files. > > > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen > (be > > > > sure to check the README on how to use) > > > > > > > > Example output (the console output properly tabulates data, format > may > > > > look broken in the email): > > > > > > > > Generate memory map: > > > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > > > > > > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > > > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > > > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > > > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > > > > ... etc > > > > > > > > Register definitions: > > > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > > > > > > > /* Register offsets > > > > */ > > > > > > > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > > > > mode.*/ > > > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > > > > mode.*/ > > > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > > > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > > > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > > > > ... etc > > > > > > > > /* Register definitions > > > > */ > > > > > > > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_TXEN_OFFSET) > > > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_RXEN_OFFSET) > > > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_START_OFFSET) > > > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_STOP_OFFSET) > > > > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_DISABLE_OFFSET) > > > > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_RSSISTART_OFFSET) > > > > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + > > > > NRF51_RADIO_TASKS_RSSISTOP_OFFSET) > > > > ... etc > > > > > > > > Best, > > > > Matias > > > > > > > > > -- > > Adam Feuer > -- Adam Feuer
Re: SVD -> header generator
They are not all Apache 2.0. The NXP ones are a mixed bag, some call out BSD, some just liability disclaimer, looks like the example I gave was not the best one. For STM this file is restricted in a way that is not compatible. Personally I think that is a mistake on the part of STM, but here we are... https://raw.githubusercontent.com/posborne/cmsis-svd/master/data/STMicro/License.html TI is another example with further restrictions. https://github.com/posborne/cmsis-svd/blob/master/data/TexasInstruments/TM4C123GH6ZRB.svd --Brennan On Fri, Jul 3, 2020 at 3:19 PM Adam Feuer wrote: > > Brennan, > > All the files in this repo are Apache 2.0 licensed: > > https://github.com/posborne/cmsis-svd/blob/master/LICENSE-APACHE > > Doesn't that cover the license issue? The header is only a liability > disclaimer. > > -adam > > > > On Fri, Jul 3, 2020 at 2:25 PM Brennan Ashton > wrote: > > > Just a warning on generating code from these files. Many of the have > > explicit restrictions on using them which may not be compatible with BSD or > > Apache. For example NXP > > https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd > > > > I'm not sure on the legal side about this but it is why I have avoiding > > using them to generate headers. Maybe Apache Legal could give us guidance. > > > > --Brennan > > > > On Fri, Jul 3, 2020, 1:45 PM Matias N. wrote: > > > > > Hi, > > > I thought about doing this for a long time and I just did it, wasn't > > > really hard. > > > If you're not aware, CMSIS-SVD file format is an XML based definitions of > > > peripherals and registers available in a given MCU. This is typically > > used > > > for debugging but it is quite useful for generating header definitions. I > > > wrote a quick python script that is able to generate register definitions > > > and base addresses of peripherals. It is based on > > > https://github.com/posborne/cmsis-svd which includes both the SVD python > > > parser and a really complete database of SVD files. > > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be > > > sure to check the README on how to use) > > > > > > Example output (the console output properly tabulates data, format may > > > look broken in the email): > > > > > > Generate memory map: > > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > > > > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > > > ... etc > > > > > > Register definitions: > > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > > > > > /* Register offsets > > > */ > > > > > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > > > mode.*/ > > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > > > mode.*/ > > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > > > ... etc > > > > > > /* Register definitions > > > */ > > > > > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_TXEN_OFFSET) > > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_RXEN_OFFSET) > > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_START_OFFSET) > > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_STOP_OFFSET) > > > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_DISABLE_OFFSET) > > > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_RSSISTART_OFFSET) > > > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + > > > NRF51_RADIO_TASKS_RSSISTOP_OFFSET) > > > ... etc > > > > > > Best, > > > Matias > > > > > -- > Adam Feuer
Re: SVD -> header generator
Brennan, All the files in this repo are Apache 2.0 licensed: https://github.com/posborne/cmsis-svd/blob/master/LICENSE-APACHE Doesn't that cover the license issue? The header is only a liability disclaimer. -adam On Fri, Jul 3, 2020 at 2:25 PM Brennan Ashton wrote: > Just a warning on generating code from these files. Many of the have > explicit restrictions on using them which may not be compatible with BSD or > Apache. For example NXP > https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd > > I'm not sure on the legal side about this but it is why I have avoiding > using them to generate headers. Maybe Apache Legal could give us guidance. > > --Brennan > > On Fri, Jul 3, 2020, 1:45 PM Matias N. wrote: > > > Hi, > > I thought about doing this for a long time and I just did it, wasn't > > really hard. > > If you're not aware, CMSIS-SVD file format is an XML based definitions of > > peripherals and registers available in a given MCU. This is typically > used > > for debugging but it is quite useful for generating header definitions. I > > wrote a quick python script that is able to generate register definitions > > and base addresses of peripherals. It is based on > > https://github.com/posborne/cmsis-svd which includes both the SVD python > > parser and a really complete database of SVD files. > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be > > sure to check the README on how to use) > > > > Example output (the console output properly tabulates data, format may > > look broken in the email): > > > > Generate memory map: > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > > ... etc > > > > Register definitions: > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > > > /* Register offsets > > */ > > > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > > mode.*/ > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > > mode.*/ > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > > ... etc > > > > /* Register definitions > > */ > > > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_TXEN_OFFSET) > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RXEN_OFFSET) > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_START_OFFSET) > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_STOP_OFFSET) > > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_DISABLE_OFFSET) > > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RSSISTART_OFFSET) > > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RSSISTOP_OFFSET) > > ... etc > > > > Best, > > Matias > -- Adam Feuer
Re: SVD -> header generator
Just a warning on generating code from these files. Many of the have explicit restrictions on using them which may not be compatible with BSD or Apache. For example NXP https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd I'm not sure on the legal side about this but it is why I have avoiding using them to generate headers. Maybe Apache Legal could give us guidance. --Brennan On Fri, Jul 3, 2020, 1:45 PM Matias N. wrote: > Hi, > I thought about doing this for a long time and I just did it, wasn't > really hard. > If you're not aware, CMSIS-SVD file format is an XML based definitions of > peripherals and registers available in a given MCU. This is typically used > for debugging but it is quite useful for generating header definitions. I > wrote a quick python script that is able to generate register definitions > and base addresses of peripherals. It is based on > https://github.com/posborne/cmsis-svd which includes both the SVD python > parser and a really complete database of SVD files. > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be > sure to check the README on how to use) > > Example output (the console output properly tabulates data, format may > look broken in the email): > > Generate memory map: > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > ... etc > > Register definitions: > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > /* Register offsets > */ > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > mode.*/ > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > mode.*/ > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > ... etc > > /* Register definitions > */ > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_TXEN_OFFSET) > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_RXEN_OFFSET) > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_START_OFFSET) > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_STOP_OFFSET) > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_DISABLE_OFFSET) > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_RSSISTART_OFFSET) > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_RSSISTOP_OFFSET) > ... etc > > Best, > Matias
Re: SVD -> header generator
Very good Matias! Indeed, registers definition is a boring part of creating a new NuttX port, your tool makes it a breeze! BR, Alan On 7/3/20, Adam Feuer wrote: > Matias, > > This looks like it would be a lot of help bringing NuttX up on a new > microprocessor. Thanks! > > -adam > > On Fri, Jul 3, 2020 at 1:46 PM Matias N. wrote: > >> Hi, >> I thought about doing this for a long time and I just did it, wasn't >> really hard. >> If you're not aware, CMSIS-SVD file format is an XML based definitions of >> peripherals and registers available in a given MCU. This is typically >> used >> for debugging but it is quite useful for generating header definitions. I >> wrote a quick python script that is able to generate register definitions >> and base addresses of peripherals. It is based on >> https://github.com/posborne/cmsis-svd which includes both the SVD python >> parser and a really complete database of SVD files. >> The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be >> sure to check the README on how to use) >> >> Example output (the console output properly tabulates data, format may >> look broken in the email): >> >> Generate memory map: >> $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 >> >> #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ >> #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ >> #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ >> #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ >> ... etc >> >> Register definitions: >> $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 >> >> /* Register offsets >> */ >> >> #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX >> mode.*/ >> #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX >> mode.*/ >> #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ >> #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ >> #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ >> ... etc >> >> /* Register definitions >> */ >> >> #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + >> NRF51_RADIO_TASKS_TXEN_OFFSET) >> #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + >> NRF51_RADIO_TASKS_RXEN_OFFSET) >> #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + >> NRF51_RADIO_TASKS_START_OFFSET) >> #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + >> NRF51_RADIO_TASKS_STOP_OFFSET) >> #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + >> NRF51_RADIO_TASKS_DISABLE_OFFSET) >> #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + >> NRF51_RADIO_TASKS_RSSISTART_OFFSET) >> #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + >> NRF51_RADIO_TASKS_RSSISTOP_OFFSET) >> ... etc >> >> Best, >> Matias > > > > -- > Adam Feuer >
Re: SVD -> header generator
That's a great one! Does it do bitfields? I gave it a quick try and I only got register definitions. Regardless, that could be a great time saver! On Fri, Jul 3, 2020 at 9:57 PM Adam Feuer wrote: > > Matias, > > This looks like it would be a lot of help bringing NuttX up on a new > microprocessor. Thanks! > > -adam > > On Fri, Jul 3, 2020 at 1:46 PM Matias N. wrote: > > > Hi, > > I thought about doing this for a long time and I just did it, wasn't > > really hard. > > If you're not aware, CMSIS-SVD file format is an XML based definitions of > > peripherals and registers available in a given MCU. This is typically used > > for debugging but it is quite useful for generating header definitions. I > > wrote a quick python script that is able to generate register definitions > > and base addresses of peripherals. It is based on > > https://github.com/posborne/cmsis-svd which includes both the SVD python > > parser and a really complete database of SVD files. > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be > > sure to check the README on how to use) > > > > Example output (the console output properly tabulates data, format may > > look broken in the email): > > > > Generate memory map: > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > > ... etc > > > > Register definitions: > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > > > /* Register offsets > > */ > > > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > > mode.*/ > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > > mode.*/ > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > > ... etc > > > > /* Register definitions > > */ > > > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_TXEN_OFFSET) > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RXEN_OFFSET) > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_START_OFFSET) > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_STOP_OFFSET) > > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_DISABLE_OFFSET) > > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RSSISTART_OFFSET) > > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + > > NRF51_RADIO_TASKS_RSSISTOP_OFFSET) > > ... etc > > > > Best, > > Matias > > > > -- > Adam Feuer
Re: SVD -> header generator
Matias, This looks like it would be a lot of help bringing NuttX up on a new microprocessor. Thanks! -adam On Fri, Jul 3, 2020 at 1:46 PM Matias N. wrote: > Hi, > I thought about doing this for a long time and I just did it, wasn't > really hard. > If you're not aware, CMSIS-SVD file format is an XML based definitions of > peripherals and registers available in a given MCU. This is typically used > for debugging but it is quite useful for generating header definitions. I > wrote a quick python script that is able to generate register definitions > and base addresses of peripherals. It is based on > https://github.com/posborne/cmsis-svd which includes both the SVD python > parser and a really complete database of SVD files. > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be > sure to check the README on how to use) > > Example output (the console output properly tabulates data, format may > look broken in the email): > > Generate memory map: > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ > ... etc > > Register definitions: > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 > > /* Register offsets > */ > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX > mode.*/ > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX > mode.*/ > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ > ... etc > > /* Register definitions > */ > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_TXEN_OFFSET) > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_RXEN_OFFSET) > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_START_OFFSET) > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_STOP_OFFSET) > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_DISABLE_OFFSET) > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_RSSISTART_OFFSET) > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + > NRF51_RADIO_TASKS_RSSISTOP_OFFSET) > ... etc > > Best, > Matias -- Adam Feuer
SVD -> header generator
Hi, I thought about doing this for a long time and I just did it, wasn't really hard. If you're not aware, CMSIS-SVD file format is an XML based definitions of peripherals and registers available in a given MCU. This is typically used for debugging but it is quite useful for generating header definitions. I wrote a quick python script that is able to generate register definitions and base addresses of peripherals. It is based on https://github.com/posborne/cmsis-svd which includes both the SVD python parser and a really complete database of SVD files. The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be sure to check the README on how to use) Example output (the console output properly tabulates data, format may look broken in the email): Generate memory map: $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51 #define NRF51_POWER_BASE 0x4000 /* Power Control.*/ #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/ #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/ #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/ ... etc Register definitions: $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51 /* Register offsets */ #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX mode.*/ #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX mode.*/ #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/ #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/ #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/ ... etc /* Register definitions */ #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_TXEN_OFFSET) #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_RXEN_OFFSET) #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_START_OFFSET) #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_STOP_OFFSET) #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_DISABLE_OFFSET) #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_RSSISTART_OFFSET) #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + NRF51_RADIO_TASKS_RSSISTOP_OFFSET) ... etc Best, Matias
