// the find
bilalamjad24/Bio-Med-Sensing-Device-
Bio-Medical Sensing Device with On-Device AI This project implements a smart biomedical sensor using FreeRTOS and TinyML on the STM32F407VE. It collects physiological data, runs local AI inference to detect anomalies, and communicates results via BLE. Designed for real-time, low-power embedded applications in healthcare.
A bare-metal CMake skeleton for an STM32F407VE board, meant to read three sensors and pass results over a BLE dongle. The description pitches it as a FreeRTOS and TinyML anomaly detector, but the README and file tree show a project still at the wiring-up stage. It suits embedded developers who want a starting layout for an STM32 project, not anyone expecting a working health monitor.
- The layout is a sensible starting point: one header per sensor and one for the BLE dongle in include/, implementations in src/drivers/, and the toolchain file and linker script under cmake/ keep the board target out of the sources.
- CMSIS core headers, the F4 device headers and the startup assembly are vendored, so the build does not depend on the ST HAL or CubeMX-generated code. That keeps the dependency surface small, though you then write the peripheral code yourself.
- The README gives an out-of-tree CMake build with a dist-clean target and points to Cortex-Debug with OpenOCD and ST-Link, which is the usual debugging setup for this board.
- The description claims FreeRTOS scheduling, on-device TinyML inference and BLE reporting. None of that shows up in the tree: no RTOS sources, no model file, no inference runtime. Read the description as a plan, not a description of the code.
- The README says drivers go in src/drivers/ 'when hardware arrives', so the sensor and BLE files are probably stubs. Anyone adopting this would be writing the drivers, the anomaly model and the task structure from scratch.
- No wiring, pinout, sensor part numbers or BLE dongle model are documented, so a reader cannot tell which hardware the drivers target. There are no tests and no way to exercise the logic off the board.
- Editor and OS files are committed: .DS_Store files and the .settings/ IDE bundle stores are in the tree. It is a small thing, but it suggests the repo was not cleaned up before it was published.