This crate contains the svd2rust product of chip description files (SVDs) provided for the EFR32xG1 family of microprocessors (which does not include EFR32xG11 and EFR32xG12).
Device designations of EFR32 files appear to be structured like this:
EFR32[family]G[series-and-config][performance][featureset]F[flashzize][temperaturegrade][package][pincount]
- The family part is typically a letter ("B" for "Blue Gecko", "M" for "Mighty Gecko", "F" for "Flex Gecko" etc.
- The series-and-config part is a one to two digit number indicating the series in the first digit and the confg in the second if present.
- Performance grade is a letter.
- Feature set is a numeric code related to radio frequencies.
- Flash size is given in kB.
- Temperature grade and package type are letters, pin count is numeric.
(Source: EFR32MG1 and EFR32FG14 data sheets. Note that these are the order codes also used in the SVD file names and descriptions; designations printed on the chips are encoded differently.)
Unlike in the EFM32 series, the family part does not indicate regular peripheral internal revisions any more. (In EFM32, a Leopart Gecko would have slightly different clocks than a Tiny Gecko); they only indicate differences in the radio stacks (where funnily, Flex Gecko is the least flexible as it can only do proprietary networking).
Given that radio components are not shown in the SVDs and svd2rust does not touch memory sizes, all components but the series-and-config can be ignored for matters of generating svd2rust code. The EFR32MG1P133F256GM48 is used as the representative chip in the source, but the author assumes that all EFR32 chips with series-and-config equal to "1" can be used with this crate.
Beware that mixing register crates between series-and-config versions will not work; for example, the GPIO bit in the CMU_HFPERCLKEN0 register has moved between 1 and 12.
This crate has nothing special about the way it is used compared to any other svd2rust crate, so see its documentation or the generic chip documentation.
For easy use of some limited peripherals, have a look at the efm32gg-hal crate (don't let the name distract you), or the Thunderboard BSC that has examples.
The actually authored (or, in case of the SVD file, vendor-provided) sources
are kept in the master branch, where the svd2rust produced files are never
committed.
Before the crate is re-published, master gets merged into the
after-svd2rust branch, where make clean all is executed and the resulting
crate can be used locally, tested and uploaded.
All code and text checked into this repository, except the SVD files, was written by chrysn [email protected] and is published under the "MIT or Apache-2.0" terms indicated in the Cargo file.
The SVD file has its own license section, and is licensed under the terms of the Zlib license; in the author's understanding that file's license terms do not have any bearing on the license of produced Rust binaries.