SAM RH707 Support

[blietaer]

Dear Michał and atsams-rs Team,

Many thanks for crediting me in the latest newsletter, despite my humble contribution ! 😅

As I am about to dig a bit more this SAM platform for both the SAM V71 & E70 (respectively Xult & MCLV2 boards) but also the SAM RH707 (on its evaluation kit board), I would like to understand from you guys if there is any room/need/willingness for converging efforts:

1.) I'll have to derive the SAM RH707 PAC from its .svd, and then hopefully its HAL: it is understood that specific PACs should now be hosted outside of this very atsams-rs repo: is this OK I simply hold it on my personal GitHub then ?
(And anything already done for SAM RH707 ? Is the HAL easily inspired from existing ones, once I have it PAC generated ?)

2.) I believe this whole atsamx7x-rust is based on the RTIC v1.x (or did I goof from branches? ) and I am mostly experimenting on RTIC v2.0.1 nowadays: is this valuable/appreciated if I push somehow/somewhere here my ported examples on RTIC v2.x ?

3.) Latest RTIC version seems to require a dedicated rtic-monotonics implementation for this whole SAM 7xx family MCU, if we want to have a timer-based one (today only the 'Systick' one is working fine (maybe it is enough for most of us...?): is this also already ongoing effort somewhere by someone ?

Sorry if this is the wrong place to ask these points: please rick-roll me to the appropriate Matrix channel (is the RTIC channel on Element the right place to discuss this as most of you guys pop-up over there ?)

Thank you,

Have a good one 🎅 !

Cheers,
Ben

[martinmortsell]

Hi Ben!
My understanding from quickly skimming the SAM RH707 datasheet is that it is largely compatible with the other MCUs supported in this HAL, so in my opinion supporting the RH707 here as well would make sense.

1. I think that once you have the PAC generation working properly it should be merged into the pac repo. Once the PAC is generated it should (in theory anyway) be usable with this HAL by adding additional feature flags for the new MCU.

2. Moving from RTIC1 to RTIC2 for the examples would make sense, if for no other reason than it being good practise to keep dependencies up to date. I don't think it will make a practical difference as the examples we have are simple enough that we do not really use any RTIC features.

3. There's not ongoing effort that I'm aware of but it would be a good thing to get done.

[michalfita]

Hi @blietaer,

Adding PAC is trivial, as we have the process automated. PAC would require SVDs for all variants of the new MCU.

What needs modification, however, is the ATPACKs Harvester to enable extracting SVDs from official Microchip's sources.

My worry is - and I don't have time experiment with - that IPs for peripherals in this new series may differ from those on SAME, SAMS and SAMV, as this is Microchip's design not original Atmel's, despite still being Cortex-M7. @martinmortsell is convinced it's mostly compatible, question is what's the percentage of that mostly and how much complication to feature flags any differences may introduce.

None of us has kits with that chip to run any checks or tests.

If you're willing to try, please start with making sure ATPACKs Harvester can download and extract right SVDs.

[blietaer]

Wow, great, many thanks for this quick and positive feedback to both of you.

Yes, I share the same worry: so ...let's dig and try, I have the board on my desk, a blinky test would be a nice first (although not deeply testing all PAC corner cases, of courses).

I was not aware of the ATPACKs Harvester: so this is the way to go ?
(I was heading to a vanilla svd2rust...)
Also, in your PAC repo, I see a python script: is this the entry door for the repo to pass a new MCU ?

And finally, so is this OK to keep this thread alive here as an 'issue' ? or do you want to move in another channel ?

[martinmortsell]

After Michał's comment I looked a bit more carefully at the datasheet, and I'd say the MCUs seem to be somewhat compatible, rather than mostly compatible. The peripherals that are shared might need some work, but it should be doable to integrate support into this hal.

And as he pointed out, we do not have access to development boards, so we cannot actually test the code.

[blietaer]

OK, understood, thanks !

I am happy to try and build my first PAC (and then adapt HAL if/as needed), testing it on my HW, ...but I'll have some (many) n00b questions... :/

Is that OK ?
Do I get you are the PAC/HAL guru here ? :)

[blietaer]

OK, so just installing the harverster the-cargo-way is failing on me... I am most probably missing something (should be done from a decent cargo folder ?)
Also, this tool seem to fetch (and parse?) the .svd directly from Microchip.
I got the .svd here on my local drive, from the usual Device Family Package (DFP), typically from their MPLAB Harmony repos: is this the intend of this tool to avoid this burden and have it automated in order to keep it up to date ?

[michalfita]

Do I get you are the PAC/HAL guru here ? :)

@tmplt & @martinmortsell wrote most of the HAL code so far, however, mostly as part of their full time job (Grepit AB work for Volvo). I started this years ago when SAMV70 was my main working platform, but never went past basics. And I redone the way we deal with PACs (finished recently; need proper release).

Now about the process:

Note
The DevOps for this is not finished

1. The atpacks-svd-harvester (check your typos) is a tool the atsamx7x-pac is using to download SVDs before commit for release.

2. The atsamx7x-pac uses svd2rust as library, so we generate crate structure for each variant from the update.py tool and publish. You have to run this manually on your clone if you wish to work on it. The directory is in the .gitignore to prevent accidental commit of thousands of files.

3. When the crate for particular MCU variant is downloaded, it has to be built for sources of PAC to appear, as they're generated in build.rs of the crate.

For your own experiments, you can play traditional way with local use of svd2rust over SVD files you have, just mind the version we're using as quite often they break API of generated PACs, so if you use too new, you'll start fixing broken code we're not ready for. We're currently to aim release based on 0.29.0.

Please don't publish any crates if you wish the support to be part of this organisation.

[michalfita]

I got the .svd here on my local drive, from the usual Device Family Package (DFP), typically from their MPLAB Harmony repos: is this the intend of this tool to avoid this burden and have it automated in order to keep it up to date ?

Yes.

This tools extracts SVDs from DFPs without need to download MPLAB Harmony every time - I'm not interested in vendor's IDEs especially when I work from command line on Linux.

[michalfita]

Margin note: To be complete, we should consider not only SAMRH707, but SAMRH71 and SAMV71-RT as well.

[blietaer]

Ah ! Sorry for the typo (careful: this was blindly cut'n'paste from your README...).
OK, will follow these nice guidelines first...

Yes, let's get rid of anything MPLAB related 🙈

[blietaer]

OK both PAC and Harvester seem to work properly with SAM RH7xx: I suggested changes to PR for both repo's...let me know how am I doing ?
Now I have a dedicated PAC for this MCU family, I believe it is about to play 'Where's Waldo?' comparing/diffing existing HAL+PAC for V71 and deduce SAM RH7xx from its own PAC... correct ?
On it.

[martinmortsell]

The datasheet will likely be very helpful here.

Setting up clocks and pins correctly will lay the foundation for most of the other peripherals.

The peripherals should be feature gated in src/lib.rs such that you only compile peripherals available on the RH707 when that feature is selected.

[tmplt]

From a cursory look at the datasheet the clock hierachy looks similar, at least. I'd start there for an eventual HAL adaption: peripheral clocks must explicitly be enabled before use on the X7Xs. After that comes the PIO, as Martin recommends.

I'd refrain from trying the X7X examples on your board until the implementation has been verified with the RH datasheets, just in case they put your hardware in an unknown state.

[tmplt]

Addendum: find the RH-equivalent of the ERASE pin. It may come in handy.