arduino / arduino/ArduinoCore-mbed
Issue with sdram.h using PLL2
- Dominant language
- C
- Stars
- 411
- Forks
- 225
- PR merge metrics
- No merged PRs in 30d
Description
Hello, I would like to bring up an issue caused by PLL2 being used. While by itself this is fine, the issue lies in the fact that many peripherals where exact timing is importantl can only use PLL2 (which becomes incustomizable when SDRAM is used), or PLL3 which is already used by the system and also not customizable, or peripheral clock which doesn't come with dividers and multipliers. This means there's a very limited usable spectrum of frequencies, meaning there are usecases like for example one in my stm Speeduino library, where a user may need to be able to specificy exact clock for the ADC to run at, while then wanting to use RAM for transfer of large amounts of values using DMA, or another usecase.
For this reason it would be great if arduino could try to not use one of these clock sources in core libraries, so they're left to be used by people where necessary.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by inspecting sdram.h and the core clock setup to understand how SDRAM selects PLL2 and how PLL3 is already consumed. Compare the clock constraints described for ADC timing, peripheral clocks, and DMA-based SDRAM use. Done means identifying and implementing a supported clock arrangement that preserves SDRAM while leaving an exact, usable peripheral clock configurable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- embedded-iot
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100