2014-12-25 07:58 PM
Hi everyone
So I've been trying to find reference on the datasheet of the STM32F072RB for the APB2 but with no avail.I am talking about this one http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00090510.pdfThat is in here:http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1574/LN1823/PF259605So what's the deal with that?I know the APB2 exists there because when i tried to use Timer17 it didn't work using APB1, since there's a 1 in there i assumed there's a 2.Checking in the source files i can see which peripherals are in APB1 and APB2. The clock configuration tool also provided that information.There's also the reference manual, and this actually refers the APB2/APB1 registers, but it doesn't really explain much about which peripherals use it.What's the deal with that? Where can i get more info about those busses and why they are different (and need to be)?2014-12-25 11:54 PM
I guess one might start with ARM's documentation, and design philosophy about it's systems.
The Peripheral Buses PB# are where functions unrelated to the core are parked, the slowest peripherals are on APB1 in the STM32 design, the bus is clocked slower, and thus draws less power in it's operation, and the clocks to it's peripherals can be turned off, again saving power. APB2 is where the faster peripherals (priority) are placed, and it is typically clocked faster. The choice of the clock speeds are ultimately controlled by the user. The Hardware Buses HB are more closely coupled with the core and the memory subsystems, they tend to run at the core speed so as not to slow it down, and perform operations like DMA where they arbitrate access between memory and the peripherals on the slower buses.2014-12-26 06:33 AM
2014-12-26 07:35 AM
Perhaps, but it's not exactly difficult to figure out what peripherals are on what bus. I would agree that the documentation is less than ideal, but it's a hard balance, and the people you'd want writing the documentation often aren't the ones working on it.
The documentation doesn't seek to reinvent the Cortex-Mx core, some level of contextual understanding is expected. For that the ARM TRM would be the first reference, and something like Joseph Yiu's Cortex books for a slightly difference perspective