On Wednesday, 2 August 2017 at 00:39:24 UTC, Mike wrote:
> Looking at your code though, I probably should have used Adam's dom.d too; std.xml was weird to say the least.

There's a couple functions in dom.d too that might have simplified this:

foreach(EnumsTop; Flds.getElementsByTagName("enumeratedValues")){
	foreach(Enums; EnumsTop.getElementsByTagName("enumeratedValue")){
		foreach(child; Enums.childNodes){
			if(child.tagName=="description"){EnumV.description  = child.innerText();}
			if(child.tagName=="name"       ){EnumV.name         = child.innerText();}		
			if(child.tagName=="value"      ){EnumV.value        = child.innerText();}
		}


This pattern is used throughout, and it is pretty nice. Not saying it is wrong!

But that could prolly be written:

foreach(Enums; Flds.querySelectorAll("enumeratedValues > enumeratedValue")) {
    EnumV.description  = Enum.optionSelector("description").innerText();
    EnumV.name  = Enum.optionSelector("name").innerText();
    EnumV.value  = Enum.optionSelector("value").innerText();
}




The various *selector functions do CSS selector syntax. querySelector/querySelectorAll returns the first/all matching element, or null if none. requireSelector returns the first matching, or throws exception if there is none. optionSelector returns a wrapper object that is never null so you can call its methods, but they return null if it was.

Meaning you don't have to explicitly check presence, the .innerText just returns the null string if the element wasn't there.


The idea of these is to make navigating xml like this a bit more convenient.

On 8/1/17 8:34 PM, Mike wrote:
> On Tuesday, 1 August 2017 at 14:52:51 UTC, Steven Schveighoffer wrote:
> 
>> Mike, I have to say still your talk in 2014 was one of my favorites. One of the things that was so impressive to me was the way you scraped the PDF to generate all the registers automatically. Having worked with STM chips (not ARM, but really basic 8-bit versions), I can definitely appreciate all the work this saves.
> 
> I'm not sure my work is worthy of such kind words, but thank you.

Sorry, it was awesome. You should own it. I think many people were impressed with what you were able to achieve, especially those who have dealt with embedded programming.

> The PDF screen utility is here: https://github.com/JinShil/stm32_datasheet_to_d.  I'm not sure if it still compiles and works, but I might need to update it someday.
> 
> It generates much better code and more complete documentation than svd_to_d.  Most silicon vendors don't appear to invest much into their SVD files, so the SVD files are often incomplete and lacking the documentation that makes "good code + a good IDE = a substitute for the datasheet".
>
> If I were creating a professional product, I'd probably prefer scraping the PDF over using the SVD files, or maybe some way to merge the two.
> 

Yes, if the datasheet is wrong, they probably hear about it more, and fix it more readily than some xml files. Much harder to fix etch than it is to update some software.

In addition, I bet the software engineers take both into account and defer to the spec, meaning the bugs in the SVD may not get reported.

I would prefer the more accurate picture if it were me. In fact, you may be able to give them a better tool to generate the SVD file from the pdf :)

-Steve

On Wednesday, 2 August 2017 at 13:31:40 UTC, Steven Schveighoffer wrote:
> On 8/1/17 8:34 PM, Mike wrote:
>> On Tuesday, 1 August 2017 at 14:52:51 UTC, Steven Schveighoffer wrote:
>> 
>>> [...]
>> 
>> I'm not sure my work is worthy of such kind words, but thank you.
>
> Sorry, it was awesome. You should own it. I think many people were impressed with what you were able to achieve, especially those who have dealt with embedded programming.
>
>> The PDF screen utility is here: https://github.com/JinShil/stm32_datasheet_to_d.  I'm not sure if it still compiles and works, but I might need to update it someday.
>> 
>> It generates much better code and more complete documentation than svd_to_d.  Most silicon vendors don't appear to invest much into their SVD files, so the SVD files are often incomplete and lacking the documentation that makes "good code + a good IDE = a substitute for the datasheet".
> >
>> If I were creating a professional product, I'd probably prefer scraping the PDF over using the SVD files, or maybe some way to merge the two.
>> 
>
> Yes, if the datasheet is wrong, they probably hear about it more, and fix it more readily than some xml files. Much harder to fix etch than it is to update some software.
>
> In addition, I bet the software engineers take both into account and defer to the spec, meaning the bugs in the SVD may not get reported.
>
> I would prefer the more accurate picture if it were me. In fact, you may be able to give them a better tool to generate the SVD file from the pdf :)
>
> -Steve

I'm not completely sure but I would guess that the documentation was generated from the .svd files. If you think about it doing the documentation by hand would be another thing that the chip manufactures would have to validate against. If the documentation is generated from the .svd and the documentation is correct than the .svd file is also correct.

On Monday, 31 July 2017 at 08:51:16 UTC, Mike wrote:
> https://github.com/JinShil/svd_to_d
>
> SVD_to_D is a command-line utility that generates D code from ARM Cortex-M SVD files.
>
> [...]

I just clicked through some random files in the example folder, this line seems broken: https://github.com/JinShil/svd_to_d/blob/master/examples/atsamd21g18a/AC.d#L13

On Saturday, 5 August 2017 at 20:08:39 UTC, WebFreak001 wrote:

> I just clicked through some random files in the example folder, this line seems broken: https://github.com/JinShil/svd_to_d/blob/master/examples/atsamd21g18a/AC.d#L13

Fixed. Thanks!