added bare6

examples/rtic_bare6.rs

@@ -55,7 +55,7 @@ const APP: () = {
 
         let rcc = device.RCC.constrain();
 
-        // let _clocks = rcc.cfgr.freeze();
+        let _clocks = rcc.cfgr.freeze();
 
         // Set up the system clock. 48 MHz?
         // let _clocks = rcc
@@ -63,12 +63,21 @@ const APP: () = {
         //     .sysclk(48.mhz())
         //     .pclk1(24.mhz())
         //     .freeze();
-        let c = rcc
-            .cfgr
-            .sysclk(64.mhz())
-            .pclk1(64.mhz())
-            .pclk2(64.mhz())
-            .freeze();
+
+        // let _clocks = rcc
+        //     .cfgr
+        //     .sysclk(64.mhz())
+        //     .pclk1(64.mhz())
+        //     .pclk2(64.mhz())
+        //     .freeze();
+        //
+        // let _clocks = rcc
+        //     .cfgr
+        //     .sysclk(84.mhz())
+        //     .pclk1(42.mhz())
+        //     .pclk2(64.mhz())
+        //     .freeze();
+
         // pass on late resources
         init::LateResources {
             GPIOA: device.GPIOA,
@@ -145,7 +154,7 @@ fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
 //    SYSCLK - the clock that drives the `core`
 //    HCLK   - the clock that drives the AMBA bus(es), memory, DMA, trace unit, etc.
 //
-//    Typically we set HCLK = SYSCLK / 1 (no prescale) for our applications
+//    Typically we set HCLK = SYSCLK / 1 (no pre-scale) for our applications
 //
 //    FCLK   - Free running clock running at HCLK
 //
@@ -210,6 +219,13 @@ fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
 //
 //    ** your answer here **
 //
+//    Try to setup the clock according to:
+//
+//    What happens?
+//
+//    `rcc.cfgr.sysclk(84.mhz()).pclk1(42.mhz()).pclk2(64.mhz()).freeze();`
+//
+//    ** your answer here **
 //
 //    Commit your answers (bare6_0)
 //
@@ -257,8 +273,6 @@ fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
 //
 //    ** your answer here **
 //
-//    Commit your answers (bare6_3)
-//
 //    Now change the constant `OFFSET` so you get the same blinking frequency as in 1.
 //    Test and validate that you got the desired behavior.
 //
@@ -300,13 +314,14 @@ fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
 //       `w.mco2().bits{0b00}` is equivalent to
 //       `w.mco2().sysclk()` and improves readability.
 //
-//    Replace all bit-patterns used by the function name equivalents.
+//    Replace all bit-patterns used in `clock_out` by the function name equivalents.
+//    (alternatively, use the enum values.)
 //
 //    Test that the application still runs as before.
 //
 //    Commit your code (bare6_5)
 //
-// 6. Now reprogram the PC9 to be "Low Speed", and re-run at 84Mz.
+// 6. Now reprogram the PC9 to be "Low Speed", and re-run at 48Mz.
 //
 //    Did the frequency change in comparison to assignment 5?
 //
@@ -317,13 +332,40 @@ fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
 //    ** your answer here **
 //
 //    Make a screen dump or photo of the oscilloscope output.
-//    Save the the picture as "bare_7_84mhz_low_speed".
+//    Save the the picture as "bare_6_48mhz_low_speed".
 //
-//    Commit your answers (bare7_3)
+//    Commit your answers (bare6_6)
+//
+// 7. Try setting the clocks according to:
+//
+//    `rcc.cfgr.sysclk(64.mhz()).pclk1(64.mhz()).pclk2(64.mhz()).freeze()`;
+//
+//    Does the code compile?
+//
+//    ** your answer here **
+//
+//    What happens at run-time?
+//
+//    ** your answer here **
+//
+//    Try setting the clocks according to:
+//
+//    `rcc.cfgr.sysclk(84.mhz()).pclk1(42.mhz()).pclk2(64.mhz()).freeze();`
+//
+//    Does the code compile?
+//
+//    ** your answer here **
+//
+//    What happens at run-time?
+//
+//    ** your answer here **
 //
+//    Is that a correct?
 //
+//    Optional: If you find it incorrect, file an issue to `stm32f4xx-hal` describing the problem.
+//    (Remember always check already open issues, and add to existing if related.)
 //
-// 6. Discussion
+// 7. Discussion
 //
 //    In this exercise, you have learned to use the stm32f4xx-hal
 //    to set the clock speed of your MCU.
@@ -335,7 +377,7 @@ fn clock_out(rcc: &RCC, gpioc: &GPIOC) {
 //    by leveraging the abstractions provided by the PAC.
 //
 //    As mentioned before the PACs are machine generated by `svd2rust`
-//    from vendor provided System View Desciptions (SVDs).
+//    from vendor provided System View Descriptions (SVDs).
 //
 //    The PACs provide low level peripheral access abstractions, while
 //    the HALs provide higher level abstractions and functionality.