Updates for dslite2svd - Githubissues

rust-embedded-community / tm4c-rs

Converter of register descriptions from the TI DSLite format to CMSIS SVD format

BSD Zero Clause License

3 stars 2 forks source link

Updates for dslite2svd #1

Open eldruin opened 3 years ago

eldruin commented 3 years ago

(Initially written by @thejpster at https://github.com/rust-embedded-community/tm4c-hal/issues/44)

[x] Can we turn on the issue tracker on the dslite2svd fork.
[ ] Can we set up a GitHub Action to build the SVD files
[ ] Can we delete the SVD files from this repo (I never like auto-generated code in my repos)
[ ] Can we rename this repo tm4c-rs and structure it in a similar way to stm32-rs.
[ ] Can we merge the tm4c-hal repo into the new tm4c repo.
[ ] Can we do a few rounds of pushing to crates.io and updating Cargo.toml.

I accept the above are strong opinions, but the are only weakly held so feel free to rebut!

thejpster commented 3 years ago

Thanks!

An alternative to one repo per PAC is a pac-repo like I think they use for STM32 (https://github.com/stm32-rs/stm32-rs). I'm not sure which is easier from a maintenance point of view.

eldruin commented 3 years ago

I am not sure either, maybe we can ask the @adamgreig for his opinion here?

dkm commented 3 years ago

Happy to help in any possible way as I'm trying to learn as much as possible.

adamgreig commented 3 years ago

I am not sure either, maybe we can ask the @adamgreig for his opinion here?

For STM32 I'm sure having a single repo has made maintenance a huge amount easier. There are so many chips and many are so similar. I don't think it's especially hard to set up, or at least not significantly harder than multiple repositories. atsamd do the same for their large number of devices, although they've moved away from svdtools patching and are using XSLT instead. They also include the HALs in the same repository, which I imagine makes coordinating changes easier (in stm32-rs, there's a lag from PAC update to HAL update, though mostly because it's different teams doing the various HALs). nrf-rs use one repo per PAC I believe, but with only a few different devices to maintain.

Given for your two repos you'd have to duplicate CI and building and possibly need to PR the same changes to both PACs, perhaps a single repo would be easiest here?

eldruin commented 3 years ago

Thank you @adamgreig! That clears it up for me.

@thejpster What do you think about renaming this repo tm4c or tm4c-rs and rearrange things like in stm32-rs? Maybe even including tm4c-hal?

thejpster commented 3 years ago

I'm fine with renaming and merging.

eldruin commented 3 years ago

Can somebody provide an URL for the TM4C support packages for Energia? In GitHub actions we cannot interact with the GUI and stuff like that.

thejpster commented 3 years ago

It's in this download: http://energia.nu/downloads/downloadv4.php?file=energia-1.8.10E23-linux64.tar.xz

➜  energia-1.8.10E23 find -name "*.xml" | grep tm
./hardware/tools/DSLite/common/targetdb/Modules/Tiva_TM4C/tm4c1294kcpdt/sysctl.xml
./hardware/tools/DSLite/common/targetdb/devices/tms320f28377s.xml
./hardware/tools/DSLite/common/targetdb/devices/tm4c1294ncpdt.xml
./hardware/tools/DSLite/common/targetdb/devices/tm4c123gh6pm.xml

thejpster commented 3 years ago

There's also this script which seems to use some JavaScript tool to download dslite files based on a ccxml file.

https://github.com/energia/ccxml/blob/master/fetch_dslite.sh