爪乃乇ᗪ丂ㄚ丂ㄒ

Storing Audio data in an SPI Flash Memory This is the second article of the Audio Processing Project on the STM32 F411 Discovery Board. This article focuses on developing the SPI driver and the Library for the W25Q64FV 64 M-bit Serial Flash Memory from Winbond. The W25Qxx series of chips are Serial NOR Flash memory devices with capacities ranging from 4 MB to 128 MB and utilize the Serial Peripheral Interface for communication with microcontrollers. Checkout the STM32F411 Reference Manual (RM0383) and the Datasheet for W25Q64FV 64M-bit SPI Flash Memory .  Developing the SPI Driver Since some of the SPI1 and SPI3 peripheral pins are already occupied by the JTAG interface on the STM32F411 Discovery Board, we will use the SPI2 peripheral for our communication with the external flash memory. Remember to enable the clock to the GPIO Port B and SPI2 peripheral in the RCC registers. For driving the NSS line Low and High to Select and Deselect the Slave device, we can write functions that set

Echo Algorithm & Parameter Tuning The echo effect is a widely used audio processing technique that mimics sound reflections in different environments. Fundamentally, the echo algorithm works by capturing an audio input, introducing a delay to the signal, and blending it back with the original sound. This method requires fine-tuning parameters like delay time, feedback, and amplitude, enabling the generation of multiple repetitions that can differ in intensity and timing. Delay time specifies how long it takes for the echoed sound to return, while feedback determines the amount of the output signal that is redirected back into the input. The delay time is set to 300 milliseconds, determining the duration between the original signal and its echoed repetition. This value creates a noticeable gap that allows listeners to perceive the echo distinctly. The feedback level is configured to 0.7, which indicates that 70% of the output signal is fed back into the input.  Reading Audio Data fr

NOR Flash Memories & the Need for Wear Leveling NOR Flash is a type of non-volatile memory used to store data that needs to persist even when a device is powered off. NOR Flash is typically organized into sectors or blocks, which can be individually erased and reprogrammed.  Due to the physics of flash cell structure, memory cells suffer from “wear” with every Program/Erase cycle (P/E cycle). This means flash memory has a finite usable life. If a flash memory exceeds this limit, the storage capability becomes unreliable. Wear Leveling is a common technique used by storage media  to enhance the longevity of the storage media. Flash memory cells can only be programmed from a 1 to a 0 state. In order to set any cell from 0 to 1 state, the cell has to be erased to a 1. In order to update any already programmed memory sectors/blocks, the sectors/blocks have to be first erased and then reprogrammed, hence the P/E cycle. Depending on how often an application updates the flash content, fre

Need for Cross-Compilation In the context of Embedded Linux, target devices often lack the resources to compile their own binaries due to their constrained hardware. Consequently, developers need to compile these binaries on a more powerful host device and then transfer them to the target device. This process necessitates a toolchain designed to compile binaries for the target architecture on the host device. In the context of a Raspberry Pi 4, this would involve compiling binaries for an aarch64 target architecture on an x86_64 host device. Since we are using Buildroot to configure and generate the images, we have a few options for cross-compiling toolchains. We can either use: The internal toolchain built by Buildroot. An external toolchain available online. You can read more about the Cross-Compilation toolchain in Buildroot's Manual External Toolchain If an external toolchain is preferred for application development, a few options are available: Download and Set Path Obtain a