Initial port for STM32F4 Discovery

[WizardUli]

This is my first try at porting Tock. It only implements a minimum to run buttons and _chello examples. The RCC, GPIO and EXTI modules are far from complete. Right now I'm also using default clock source.

I'm creating this PR in a hope to start discussion about how to organize the stm32 crates and I plan to continue the work on the peripherals.

[WizardUli]

Btw. I'm open to moving my porting effort from the older F4 Discovery board to one of the F4 Nucleo boards. It seems to me that they may be a little more popular, I'm not sure though.

[brghena]

This is a great start. I'm really excited to see work on the STM32s.

One point towards thinking about the Discovery vs Nucleo boards is that I'm not sure if distributors are still selling the STM32F4Discovery board anymore. Digikey, for example, marks it as obsolete: https://www.digikey.com/product-detail/en/stmicroelectronics/STM32F4DISCOVERY/497-11455-ND/2711743

[alevy]

On the other hand, the nucleo boards have virtually no peripherals on them, while the discovery boards all have some sort of sensor at least.

Availability is definitely an important consideration, but other things equal I'd vote for discovery boards.

[ppannuto]

There are still plenty of discovery boards that are active (just with slightly different chips): http://www.st.com/en/evaluation-tools/stm32-mcu-discovery-kits.html?querycriteria=productId=LN1848

Perhaps one of the active F4 discovery boards is the best of both worlds?

[brghena]

This one particularly looks cheap, available, and has multiple sensors on it http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f411ediscovery.html

However, I'm judging entirely on those aspects. Not at all on what would be close to the code you've already written @Grawp, which is definitely important.

[george-hopkins]

First of all, thank you for the great work! It's awesome to see new ports just a few days after creating this repository.

Unfortunately, I don't have any board to test it myself. As @alevy already mentioned, the patch is already in a very good shape and I'm also voting for merging it. It will make working on other ports as well a consolidating common code easier that way.

[WizardUli]

Just to let you know I'm still continuing the work on GPIO and EXTI.

[halazouna]

Hello, First thank you for the work done. I'm working on a comparative study between MPU-based isolation architectures and I wanted to test Tock-OS, the only board I have is the stm32f429zi-discovery. I tried to use your code with some minor modifications like GPIO pins for leds and also the makefile, because I don't use openOCD. I'm trying to blink a led, so I flashed the kernel first using jtag, then using tockloader I flashed the blink application we can find in userland/examples/blink/ , but it didn't work. So I tried to debug, (I'm using eclipse with gdb by the way), and I found that in debug mode it is stuck in the main loop:

loop {
        unsafe {
            chip.service_pending_interrupts();
            for (i, p) in processes.iter_mut().enumerate() {
                p.as_mut().map(|process| {
                    sched::do_process(platform, chip, process, AppId::new(i), ipc);
                });
                if chip.has_pending_interrupts() {
                    break;
                }
            }

            support::atomic(|| {
                if !chip.has_pending_interrupts() && process::processes_blocked() {
                    chip.prepare_for_sleep();
                    support::wfi();
                }
            });
        };
    }

I'm really new Tock OS, is there something I'm missing? Have you tried to blink a led, and worked properly, or does it need some work to make it work?

Thank you, Kind regards, asensaoui

[george-hopkins]

@asensaoui I'm not very familiar with the STM32F4, so @Grawp can probably provide better support. In the meantime, could you set a breakpoint at sched::do_process(...) and check if the function is called? If you have some spare time, you could try building a newer kernel from my kernel-20180516 branch which might resolve the issue.

[halazouna]

@george-hopkins Thank you for you reply. I solved my issue. The application is called and turns on/off a led. However, the blink example doesn't work because I think the alarm is not initialized (delay_ms() not working), I'm trying to port the timers to make the alarm works.