Open gpgreen opened 2 weeks ago
I added DR8 in svd patch, now you can access the lower 8 bit of DR by use it.
Thats great! I just ran into a similar problem with USART DR. I have to convert my bytes to u16's, or use the raw pointer and volatile read/write
I pulled the repo and gave it a try. The DR8 registers (or accessors) didn't show in the patched svd, or in the generated rust code. I'm not sure why as I know little about svd2rust.
I also had to edit the makefile to remove the -f from the 'form' command. It is unknown in the version of form that I am using. ` ✩ [ubuntu-dev] /v/h/g/s/r/py32-rs > form -h Usage: form [options]
Options: -i, --input FILE input file to read instead of stdin -o, --outdir DIR set output directory -h, --help print this help menu -v, --version print the version
✩ [ubuntu-dev] /v/h/g/s/r/py32-rs > form -v form 0.10.0 `
I pulled the repo and gave it a try. The DR8 registers (or accessors) didn't show in the patched svd, or in the generated rust code. I'm not sure why as I know little about svd2rust.
Try run make clean
then make
? It works fine on my machine.
I also had to edit the makefile to remove the -f from the 'form' command. It is unknown in the version of form that I am using. ` ✩ [ubuntu-dev] /v/h/g/s/r/py32-rs > form -h Usage: form [options]
Options: -i, --input FILE input file to read instead of stdin -o, --outdir DIR set output directory -h, --help print this help menu -v, --version print the version
✩ [ubuntu-dev] /v/h/g/s/r/py32-rs > form -v form 0.10.0 `
After check the version of form
on my env, realized I'm using form 0.12.1
I had done make clean a couple of times to make sure. So this time I started a new container, followed the instructions of the README exactly, giving a clean environment. Still no change to the patched svd, or the generated code. No DR8 for either peripheral. Perhaps the version of svd2rust has changed and you have a newer one then is downloaded via the README.
After some trying, I found that the version of svdtools
was different from the one listed in the README.
The version on my env is 0.3.14
.
What version of svd2rust are you using. The '0.28.0' specified is quite far back.
0.28.0
currently, will try upgrade to a new version later.
At present, it is possible to upgrade svd2rust to 0.30.3
, and this pac will not compatible with the py32f0xx-hal
if you upgrade it to a higher version.
You must install the
svd2rust
with the--locked
option to avoid the invalid Punct error from proc_macro2 (When svd2rust's version below0.33.5
)
Upgrading svd2rust to a higher version is in my plans, but probably not in the near future.
I wanted to get this repo to match what you were using so I can generate the same rust code as you are getting. I am giving you another pull request with the updated versions of the tools. I can see the D8 registers in the generated code now using those versions. I haven't been using py32f0xx-hal as it is not up to the released 1.0.0 version of the embedded-hal traits. Are you planning on doing that?
I see you already updated the version, great! No pull request coming then.
I was working on getting SPI working for a small project using your crate and ran into a problem with the SPI peripheral. The data register per the datasheet will send/receive u8's or u16's. I was trying to use it in the u8 mode (the default on reset), but the crate only allows u16 read/writes to that register. The HAL implementation provided by Puya provides 2 methods of reading or writing that register. Looking at the code, the only difference is that one is reading a u8, the other a u16.
I haven't tried to implement this type of thing in svd so I did not try to fix the problem. There may be other peripheral registers in the device that work that way. For now, I will just use raw pointers and unsafe read/writes to get around it.