Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SparkFun Pro Micro assumes 16 MHz clock for both 3.3V and 5V variants #614

Open
whatthehecker opened this issue Dec 27, 2024 · 0 comments · May be fixed by #620
Open

SparkFun Pro Micro assumes 16 MHz clock for both 3.3V and 5V variants #614

whatthehecker opened this issue Dec 27, 2024 · 0 comments · May be fixed by #620

Comments

@whatthehecker
Copy link

(I am pretty new to the whole Rust ecosystem so please bear with me if I am overlooking something obvious)

The SparkFun Pro Micro, just like the SparkFun Pro Mini has a 3.3V/8MHz and a 5V/16MHz variant. For the Pro Mini, there's two different feature flags (sparkfun-promini-5v and sparkfun-promini-3v3) which result in different clock speeds in clock.rs:

        feature = "sparkfun-promini-5v",
        feature = "trinket-pro",
        feature = "nano168",
    ))]
    pub type DefaultClock = avr_hal_generic::clock::MHz16;
    #[cfg(any(feature = "trinket", feature = "sparkfun-promini-3v3"))]
    pub type DefaultClock = avr_hal_generic::clock::MHz8;

In contrast, the sparkfun-promicro flag does not differentiate between the two variants and always assumes a 16 MHz clock.
It seems as if both variants are meant to be supported, since boards.toml explicitly mentions both versions:

[promicro.usb-info]
    port-ids = [
        { vid = 0x1B4F, pid = 0x9205 }, # 5V
        { vid = 0x1B4F, pid = 0x9206 }, # 5V
        { vid = 0x1B4F, pid = 0x9203 }, # 3.3V
        { vid = 0x1B4F, pid = 0x9204 }, # 3.3V
    ]

Treating both variants the same seems to be incorrect, the 3.3 V variant has a 8 MHz clock and should be treated differently than the 5V variant (SparkFun boards.txt which mentions this difference here).

Should both variants be behind different feature flags so they are treated differently?

@tones111 tones111 linked a pull request Dec 31, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant