HAL: increase internal feature granularity, PR guideline for revs. A/B

[tmplt]

After comparing PACs it was concluded that rev. B of all SVDs (from which crates with the b-suffix are generated) include a more exhaustive memory-mapped API in comparison to rev. A. Most notable are perhaps the usage of USART::us_{mr,csr,cr}_{usart,spi}_mode in rev. B and USART::us_{mr,csr,cr} in rev. A. Of note in A is that some peripherals function register fields have different meaning depending on a master switch; i.e., when using USART in SPI mode auxilliary fields have different effects.

The idea of always using B SVDs/PACs sprung up but was altimately dropped after a brief conversation with Microchip: A/B have hardware changes for the Ethernet and CAN peripherals.

It is logical to support both revisions due to chip shortages.

So in summary, and with combination with §2 (below; see also §1 on page 14), we should add internal feature flags for permutations of the following predicates:

• Product series (different peripheral setups, certain characteristics):
  • V71
  • V70
  • E70
  • S70
• Pin count (fewer pins = less peripherals; only a concern for a PIO module)
  • J (64 pins)
  • N (100 pins)
  • Q (144 pins)
• Flash memory density (for convenience, e.g. live firmware updates)
  • 21 (2048K)
  • 20 (1024K)
  • 19 (512K)
• Device variant (revision)
  • A
  • B

Further, in order to speed up development, I propose that PRs must not implement an API for both rev. A and B.

[michalfita]

This is a bit bizzare. Last time I checked couple years ago there was no Rev A on sale (at least Vs and Ss). Moreover, there was no right data sheets for Rev A and use of some peripherals is different, meaning to support both we effectively need two branches of HALs.

[michalfita]

Checked a few, both A and B have availability dates from May 2023.

[tmplt]

to support both we effectively need two branches of HALs.

Yes. In practise this would be checking feature = revA or feature = revB in relevant modules.

In any case, because I'm only working with rev. B at the moment, I only plan to commit code for rev. B; hence the PR proposal.

[michalfita]

TBH my intention was only to support Rev B - the only time I saw Rev A chip was pre-sales dev board from Atnel 7 years ago. As far as I remember representative told us to not plan Rev A for production. It's hard to belive the fab would like produce both these days.

I don't mind making distinction, but B has to be the default.

[tmplt]

but B has to be the default

Agreed. We can target B for now and yield an appropriate error in build.rs if A is used. This effectively blocks use of half of the PACs in the repo when using the HAL, but we can remove them later down the line if A isn't used at all.

Current rev. A PAC READMEs should probably be amended to indicate their outdated nature.