cargo:warning=/home/void/FreeRTOS-rust/freertos-rust/src/freertos/shim.c: In function 'freertos_rs_get_configCPU_CLOCK_HZ': cargo:warning=/home/void/FreeRTOS-rust/freertos-rust/src/freertos/shim.c:117:10: error: 'configCPU_CLOCK_HZ' undeclared (first use in this function) cargo:warning= 117 | return configCPU_CLOCK_HZ; cargo:warning= | ^~~~~~~~~~~~~~~~~~

I realize this probably needs be defined in the examples / FreeRTOSConfig.h . Not sure what value to put there though...

First of all, thanks for your hard work on this project.

I took the stm32f411 black pill example and promoted it to a free-standing repo. I was very happy to see it works nicely with defmt and newer versions of the stm32f4xx-hal. However, I did observe that the blinking frequency is way higher than 1Hz.

https://github.com/barafael/really-fast-buttons/blob/a2081814e0dbff1d8ebc5d2aaa62761cebbb0252/freertos-tasks/src/main.rs#L70

More like 6Hz estimated. This was also the case before I upgraded the hal dependencies and set

        let clocks = rcc.cfgr.use_hse(25.MHz()).sysclk(48.MHz()).freeze();

I'm not sure if this issue is even in the right place, perhaps I shouldn't touch the timer configuration when FreeRTOS already does it?

Quoting the docs:

[...] binary semaphores created using xSemaphoreCreateBinary() are created in a state such that the the semaphore must first be 'given' before it can be 'taken'

The Semaphore API only allows locking, and then dropping the guard, which means there is no way to "give" a binary semaphore. This API also makes using Semaphores as synchronization tools unwieldy.

thread 'main' panicked at 'Directory freertos_port_dir does not exist: FreeRTOS-Kernel/portable/GCC/Linux', freertos-rust-examples/build.rs:61:38

Looks like this is recent regression following change from in-tree copy of Kernel to submodule. I checked upstream and can't find trace of that Linux folder ever being there, maybe it was added to the local copy in this repo

It looks like there is an edit to a critical function, here:

https://github.com/lobaro/FreeRTOS-rust/blob/master/freertos-rust-examples/FreeRTOS/Source/tasks.c#L3041

While bringing this up on a Cortex M4, I was getting hardfaults in the PendSVHandler after vTaskSwitchContext was called.

This commit changes back to the base FreeRTOS source without the above edit. The source is removed from this repo, and is changed to a submodule.

It wasn't possible for a task to get its own handle, making features like wait_for_notification unusable without the aid of some dangerous juggling of global variables.

Tasks are now handed their handle as an argument, making it so they can safely make use of such features.

I also cleaned up some warnings that have cropped up with updates to Rust and ran cargo fmt on the project.

Hello, I've got a simple LED blinking example with two tasks and queue / message passing

This runs on stm32f303 (Cortex M4) hardware, specifically on the low-cost Robotdyn mini-M4

What's the best way to integrate this with the examples in this repo? I noticed that the Cortex-M3 example has a bunch of comments indicating the example is not functional.

Add basic CI script to check incoming pull requests and help maintain stability of master branch. Currently it only checks things that are working, but I left lines in place (commented out) for things that we plan to improve.

Currently checks:

• Build succeeds for the main library (warnings allowed)
  • freertos-rust
  • freertos-cargo-build
• Examples build (for the one that already works)
  • stm32-cortex-m4-blackpill

Not yet checked:

• fmt
• test
• clippy
• Build is clean (deny warnings)
• All examples build
• Examples build clean (deny warnings)

Some of the current issues under discussion should allow us to check builds for linux and win examples soon.

Toolchains are only set to nightly since the allocator_api still needs that.

Also related to recent discussions, it's not clear if running this on ubuntu-latest means that we might miss some build issues on windows (where build succeeds on linux but not on windows). For future investigation outside of this PR.

Previous changes in #36 broke the non-Linux examples since the port base path by default was not set correctly. This PR changes the mechanism to use the user-supplied value if available, otherwise fall back on the portable directory inside the FreeRTOS kernel root.

I confirmed that these examples work for me (with adding #define configCPU_CLOCK_HZ to avoid #35). The other have previously-existing build failures, at least on my machine.

• linux
• stm32-cortex-m4-blackpill (build only)
• win

@johnathancn please double check that this change still works for your use case.

We've had a bunch of accidental build breakages in the examples recently (understandably so, since users often don't have more than one platform available to test with) so I'm going to make it a priority to get a CI script running for PR's.

I am trying to build this package with the latest nightly, and I am getting the following error:

error[E0282]: type annotations needed
 --> build.rs:8:7
  |
8 |     b.heap("heap_4.c".to_string());              // Set the heap_?.c allocator to use from
  |       ^^^^ cannot infer type for type parameter `P` declared on the associated function `heap`

error: aborting due to previous error

Notably, in my build.rs, I made the modification of explicit String conversion, otherwise I get a cargo error about mismatched types: b.heap("heap_4.c".to_string() );

Relaxing the signature to: pub fn heap(&mut self, file_name: String) appears to resolve the build issue, although that is just a guess, and other regressions may be introduced.

Woudl it be possible to add Cargo features for the various bits of functionality? For example, I only want the allocator; otherwise I'm working with a no_std + alloc crate.

It seems the blackpill example blinks at the incorrect rate. It should blink with one toggle per second (0.5 Hz blink rate) with the given task timings but is going too fast. This is likely due to configCPU_CLOCK_HZ being set incorrectly.

See #44

Currently, the dependencies are tied to the target-triple in freertos-rust-examples/Cargo.toml, and the build.rs ties example paths directly to targets.

After some tinkering with cargo, it seems there might not be a way to improve on this.

However, if each "example" is reorganized into its own cargo binary project, then:

• the target triple can be put into .cargo/config.toml for each
• dependencies for each can be made unique
• build.rs does not need to link targets to example paths

proposed reorg here: https://github.com/apullin/FreeRTOS-rust/tree/examples_reorg/freertos-rust-examples/examples/stm32f407-segger-trace

This might be moot, since the "examples" should just be templates, and any new project would have a project-specific build.rs and config.toml anyway.

However, this way, each refactored example would be a template to copy & adapt directly (just paths, I think?) for new projects.

The project was created in the urge of using Rust for our embedded development and was a first proof of concept. Unfortunately the real world makes it much harder to migrate to rust than I would like. That's the reason why we do not use the library in production yet.

On the other side I see a lot of interest in moving the code forward and welcome this a lot. I just feel too inactive on GitHub to maintain the project alone with the Quality it deserves.

If there is someone who like to help maintaining the library I'm open for suggestions.

@schteve I just merged a lot of PR from you. If you have long term interest to use and develop the library, just let me know. @reitermarkus same holds for you.

This and other projects may require a delay provider (for example: https://github.com/stm32-rs/stm32f4xx-hal/blob/master/src/delay.rs) that provides delayms and delayus functions. lt should be possible to provide this functionality as part of this package. I am new to rust (I thought it could be a better option than c), but I use pdMS_TO_TICKS in C.