Changes to support missing comments and missing access fields

[osterwood]

[lynaghk]

Thanks for the PR, exciting to have more people joining the Zig party =D

Can you link to the SVD and chip you ran into problems on? I'd love to take a closer look myself to understand what's what.

[osterwood]

I ran into issues with ATSAMD09D14A and ATSAMD51G19A. Note, I've not actually used the generated zig files after these changes. The regex change in enums-by-usage solves (I think) this error on the Microchip SVDs:

[{:type clojure.lang.Compiler$CompilerException,
    :message
    "Syntax error compiling at (generate_registers.clj:297:1).",
    :data
    {:clojure.error/phase :compile-syntax-check,
     :clojure.error/line 297,
     :clojure.error/column 1,
     :clojure.error/source
     "/Users/chris/Documents/github/svd2zig-origin/generate_registers.clj"},
    :at [clojure.lang.Compiler load "Compiler.java" 7652]}
   {:type java.lang.NumberFormatException,
    :message "For input string: \"0x2\"",
    :at
    [java.lang.NumberFormatException
     forInputString
     "NumberFormatException.java"
     67]}],
  :trace
  [[java.lang.NumberFormatException
    forInputString
    "NumberFormatException.java"
    67]
   [java.lang.Integer parseInt "Integer.java" 660]
   [java.lang.Integer parseInt "Integer.java" 778]
   [generate_registers$enums_by_usage$iter__1976__1980$fn__1981$fn__1986
    invoke
    "generate_registers.clj"
    50]
   [clojure.core$update invokeStatic "core.clj" 6185]
   [clojure.core$update invoke "core.clj" 6177]
   [generate_registers$enums_by_usage$iter__1976__1980$fn__1981
    invoke
    "generate_registers.clj"
    47]

The Microchip SVDs also don't have docs on all register enums, which was causing a lot of empty lines in the re-formatted zig files, so I added a check there.

Lastly, not all registers have an "access" field on the top level, so generated zig sometimes looked like this:

pub const NAME = nil.init(VALUE)

Where NAME and VALUE were good, but code had "nil" instead of "Register". It also looks like Microchip SVDs sometimes have access entries on individual register fields, but not on the parent register -- right now those field attributes are completely ignored.

I'm exited to dive more into Zig on bare metal. If you have any public code which uses this SVD-generated code, I've love to take a look at it -- I think it would help bringup on these SAMD processors I'd like to use.

[lynaghk]

Thanks for the context! I'll take a look at those SVDs and see if I can replicate the issue and understand your fixes. Makes sense from what you've described though --- not surprised there are more vendor differences in the SVDs.

I haven't done much Zig embedded because of this open compiler bug https://github.com/lynaghk/svd2zig/issues/5 and because I've been researching some other ideas about how to choose pins and set registers using constraint solvers rather than manually from an imperative programming language (some notes: https://kevinlynagh.com/pinfigurator/). I expect once that's fleshed out I'll revisit Zig.

[lynaghk]

I pushed up some commits fixing the issues you noticed, thanks! I tested with the ATSAMD51G19A.svd accessible here http://packs.download.atmel.com/

Unfortunately the generated Zig isn't quite ready to go yet; the DHCSR register has at bit offset 16 two fields: DBGKEY field (write-only) and S_REGRDY (read-only). The generation code https://github.com/lynaghk/svd2zig/blob/d51bd9446913d6a3c15c463aa124b86c1bf77ca7/generate_registers.clj#L86

assumes that a register's fields don't overlap and in this situation generates invalid output (negative "reserved space").

Any thoughts on how we should resolve this?

One possibility would be to separate the fields into synthetic read-only and write-only views into the entire register.