embassy-rs / chiptool Goto Github PK

Arrays of registers are currently supported, but the program does not support arrays of fields.

A strinpped-down example of an unsupported field array...

<?xml version="1.0" encoding="utf-8"?>
<device schemaVersion="1.3" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="CMSIS-SVD.xsd">
  <vendor>Test</vendor>
  <vendorID>test</vendorID>
  <name>generic</name>
  <series>Generic</series>
  <version>1.0</version>
  <description>Generic</description>
  <cpu>
    <name>CM0PLUS</name>
    <revision>r0p1</revision>
    <endian>little</endian>
    <mpuPresent>true</mpuPresent>
    <fpuPresent>false</fpuPresent>
    <vtorPresent>1</vtorPresent>
    <nvicPrioBits>2</nvicPrioBits>
    <vendorSystickConfig>0</vendorSystickConfig>
  </cpu>
  <addressUnitBits>8</addressUnitBits>
  <width>32</width>
  <resetValue>0x00000000</resetValue>
  <resetMask>0xFFFFFFFF</resetMask>
  <peripherals>
    <peripheral>
      <name>GPIO</name>
      <baseAddress>0x00000000</baseAddress>
      <addressBlock>
        <offset>0</offset>
        <size>512</size>
        <usage>registers</usage>
      </addressBlock>
      <registers>
        <register>
          <name>OUT0</name>
          <addressOffset>0x000</addressOffset>
          <size>32</size>
          <access>read-write</access>
          <resetValue>0x00</resetValue>
          <resetMask>0xFF</resetMask>
          <fields>
            <field>
              <dim>32</dim>
              <dimIncrement>1</dimIncrement>
              <name>PIN[%s]</name>
              <bitRange>[0:0]</bitRange>
              <access>read-write</access>
            </field>
          </fields>
        </register>
      </registers>
    </peripheral>
  </peripherals>
</device>

and the resulting error.

> cargo run generate --svd .\field_array_test.svd
    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running `target\debug\chiptool.exe generate --svd .\field_array_test.svd`
thread 'main' panicked at '"pin%s" is not a valid Ident', C:\Users\ga29s\.cargo\registry\src\index.crates.io-6f17d22bba15001f\proc-macro2-1.0.36\src\fallback.rs:708:9
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/e9e1bbc7a820c472b39d3de54b3049bf14050655/library\std\src\panicking.rs:578
   1: core::panicking::panic_fmt
             at /rustc/e9e1bbc7a820c472b39d3de54b3049bf14050655/library\core\src\panicking.rs:67
   2: proc_macro2::fallback::validate_ident
             at C:\Users\ga29s\.cargo\registry\src\index.crates.io-6f17d22bba15001f\proc-macro2-1.0.36\src\fallback.rs:708
   3: proc_macro2::fallback::Ident::_new
             at C:\Users\ga29s\.cargo\registry\src\index.crates.io-6f17d22bba15001f\proc-macro2-1.0.36\src\fallback.rs:642
   4: proc_macro2::fallback::Ident::new
             at C:\Users\ga29s\.cargo\registry\src\index.crates.io-6f17d22bba15001f\proc-macro2-1.0.36\src\fallback.rs:652
   5: enum2$<proc_macro2::imp::Ident>::new
             at C:\Users\ga29s\.cargo\registry\src\index.crates.io-6f17d22bba15001f\proc-macro2-1.0.36\src\wrapper.rs:691
   6: proc_macro2::Ident::new
             at C:\Users\ga29s\.cargo\registry\src\index.crates.io-6f17d22bba15001f\proc-macro2-1.0.36\src\lib.rs:952
   7: chiptool::generate::fieldset::render
             at .\src\generate\fieldset.rs:24
   8: chiptool::generate::render
             at .\src\generate\mod.rs:121
   9: chiptool::gen
             at .\src\main.rs:192
  10: chiptool::main
             at .\src\main.rs:105
  11: core::ops::function::FnOnce::call_once<enum2$<core::result::Result<tuple$<>,anyhow::Error> > (*)(),tuple$<> >
             at /rustc/e9e1bbc7a820c472b39d3de54b3049bf14050655\library\core\src\ops\function.rs:250
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: process didn't exit successfully: `target\debug\chiptool.exe generate --svd .\field_array_test.svd` (exit code: 101)

Until this is added I can manually modify the SVD file.

It doesn't look like it would take too much to add support for this, but it is late, and I may forget about this before fixing it.

Running chiptool with:

chiptool generate  --svd svdfile.svd

results with:

thread 'main' panicked at src/transform/mod.rs:104:60:
called `Result::unwrap()` on an `Err` value:
Err: on rename Fieldset "EMIOS_1::regs::C2_0", new name "emios_1::regs::C20" already exist
....

is there anyway to disable this automatic transformation? since both C20 and C2_0 exists on HW, after transformation name conflict rises.

Various STM32 register bits have this rule: "Reserved, must be kept at reset value."
The modify function in chiptool-generated PACs technically doesn't follow this rule, because it always writes back to these bits the value that was read. In 99% cases this is probably fine, but I just spent hours debugging a problem on STM32F215 where this matters.

Here's the relevant part of the reference manual:

Bit 31 is marked as reserved, and the reset value for that bit is 0. Quite interestingly the bit is also marked as "rw"...usually reserved bits don't have read/write information in the reference manuals. After debugging a strange problem for hours, I found out that bit 31 actually read 1 at some point (but not always!) during execution, and I was using modify to update the non-reserved parts of the register. This meant I wrote 1 back to this reserved bit and the peripheral started to misbehave. Making sure bit 31 is always written as 0 magically fixed the problem.

This is just one example, and now that I know about the problem, I can avoid it by using write or masking out this one bit. However, it would be better if we could automatically follow this rule, since debugging these kind of issues is a pain, and reserved bits are very common so a similar problem could in theory happen pretty much anywhere.

I noticed after a long session of debugging that the default value of every fieldset is set to 0. My assumption and expectation was that a fieldset's default value would be the reset value defined in the SVD.

Was this a conscious decision or simply something not implemented? I wanted to check before putting in work to implement it.

I'd be curious to hear thoughts from you guys on adding a mocking framework like mockall for PAC-generation?

Basically, I'd like to be able to rp-pac { version = "0.1.0", features = ["mocking"] } as a dev-dep, and have something like this in the generation (for example):

#[cfg(all(test, feature = "mocking"))]
use mockall:automock;
...
// in fieldset.rs
...
#[cfg_attr(all(test, feature = "mockall", automock))]
pub struct #name (pub #ty);

#[cfg_attr(all(test, feature = "mockall", automock))]
impl #name {
    #items
}
...

Then, in my code I could use:

#[double]
use pac::PWM as PWM;

Which would automatically expand PWM to MockPWM when I'm in test -- this would let me mock registers etc. so that I can more easily test that the registers end up with the correct values (logic-wise, at least) in drivers without needing to involve a board.

Concrete example is working on this PR where via mocks I could manually step through the PWM counter and verify that the correct div/top/compares/etc. are set for each step in a test.

Thoughts?