Updates for dslite2svd

[eldruin]

(Initially written by @thejpster at rust-embedded-community/tm4c-hal#44)

• 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]

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]

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

[dkm]

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

[adamgreig]

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]

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]

I'm fine with renaming and merging.

[eldruin]

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]

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]

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