Electronics Introduction

 You treat the “config file” as a small block of non-volatile data and give it a safe place + a simple protocol, rather than literally thinking “files on a PC”. Here’s a practical way to do it. 1. Decide where to store the config Depending on your MCU and how big the config is: Internal EEPROM (AVR, some STM8 , some STM32 , PIC , etc.) Easiest: byte-wise writes, survives reset and power off. Great for a few bytes to a few kB (baud rate, calibration constants, flags…). Internal Flash (most Cortex-M, ESP32, etc.) Use one or more flash pages/sectors reserved for config. You must erase a whole page before rewriting; limited erase cycles (often 10k–100k). Common for MCUs without EEPROM (STM32, nRF, etc.). External non-volatile memory I²C/SPI EEPROM/FRAM/Flash if you need more space or don’t want to wear out internal flash. FRAM is great when you want many writes (wear basically not a problem). SD card / filesystem Overkill for tiny conf...

Think of an Arduino Nano shield PCB in KiCad as: A board with two rows of female headers that match the Nano’s pins, plus whatever parts you want to connect to those pins. “Wiring” is really just connecting Nano pins (on the schematic) to your parts , then routing those nets on the PCB. I’ll walk you through it step-by-step. 1. Decide what the shield should do Before KiCad: Which Nano pins do you need? (D2–D13, A0–A7, 5V, 3V3, GND, VIN…) What will you connect? e.g. joystick module: X→A0, Y→A1, SW→D2 LEDs on D3/D5 I2C connector on A4/A5, etc. Write this mapping down; you’ll literally implement that in the schematic. 2. In the schematic: use Nano symbol as the “connector” Assuming you already have an Arduino Nano symbol (from previous step / library): Create a new KiCad project for the shield. Open Schematic Editor . Place the Arduino Nano symbol This symbol represents the female headers where the Nano will plug in. Its pins D0, D1, 5V, GND… are yo...

 Using DMA in circular mode on STM32 basically means: “Keep filling the same buffer in RAM over and over, wrapping around when you reach the end.” This is perfect for continuous ADC sampling , UART RX streams , audio , etc. Here’s how to do it, in practical steps. 1. Basic idea Peripheral data register → DMA → RAM buffer. DMA writes: buf[0] … buf[N-1] then automatically wraps back to buf[0] and continues. Your code never restarts the DMA; it just reads from the buffer while DMA keeps filling it. 2. Create the buffer in RAM Example for an ADC (16-bit samples): # define ADC_BUF_LEN 256 uint16_t adc_buf[ADC_BUF_LEN]; Example for UART RX (8-bit): # define UART_RX_BUF_LEN 128 uint8_t uart_rx_buf[UART_RX_BUF_LEN]; Make sure the buffer is global or static so it stays allocated. 3. Configure DMA in circular mode (HAL example) Let’s say you’re using STM32Cube HAL. 3.1. In CubeMX / code, set: Direction : Peripheral → Memory Mode : DMA_...

 You don’t actually set the pull-up itself “high or low” — you either let the pull-up win (high) or override it by driving low . Let’s break it down in FPGA terms. 1. What a “pull-up pin” really is A pull-up (internal or external resistor to VCC) makes the pin: HIGH by default (when nothing is driving it), but still allows something to pull it LOW (switch, another device, or your FPGA output). So for a pull-up pin you usually have these modes: Input with pull-up → used for buttons, open-collector signals, etc. Open-drain / open-collector style output with pull-up → used for shared lines (I²C-like). You control HIGH/LOW by either: Releasing the pin (high-impedance Z ) → pull-up makes it HIGH Actively driving 0 → forces it LOW 2. HDL pattern: open-drain pin with pull-up Say you have an I/O pin io_line with a pull-up (internal or external). In Verilog: // Top-level port inout wire io_line; reg drive_low; // 1 = pull line low, 0 = releas...

 Short answer: electrically they’re mostly the same as GPIOs, but they are not identical in function or “gotchas”. Also, be careful: “GPIO 2” ≠ “pin 2” on the header. 1. If you meant physical pin 2 vs pin 4 On Raspberry Pi 5 : Pin 2 = 5 V power Pin 4 = 5 V power Both are fixed 5 V supply pins , not GPIO at all. You cannot use them like GPIO4.  So: ❌ Pin 2 does not work like GPIO 4 (BCM 4). It’s just a 5 V output from the power supply. 2. If you meant BCM GPIO2 vs BCM GPIO4 On the Raspberry Pi 5 header: GPIO2 = BCM2, physical pin 3 → default I²C1 SDA   GPIO4 = BCM4, physical pin 7 → a “normal” GPIO with extras like GPCLK0 , and often used as the default 1-Wire pin . They are similar in that: Both are 3.3 V GPIOs in the same IO bank on Pi 5. You can configure each as input or output in your code. But they differ in details: Fixed pull-up on GPIO2 GPIO2 (and GPIO3) have a permanent pull-up to 3.3 V because they are the mai...

Short answer: almost all applications on microcontrollers are designed to run “forever”, usually inside some kind of loop – but not every single line of code is literally inside a while(1) loop. Let’s unpack that a bit. 1. Why “infinite loop” is so common Microcontrollers usually: Power up Run some startup code (set up stack, clocks, memory) Call your main() Then are expected to run as long as the device has power Unlike a PC program, there’s no operating system saying “OK, you’re done now, exit”. So firmware is typically structured as: int main ( void ) { setup_peripherals(); init_stuff(); while ( 1 ) { // “superloop” read_inputs(); update_state(); control_outputs(); } } This is why you see so many: while(1) in bare-metal C for(;;) in some code loop() function in Arduino (which the core actually calls in a loop internally) So: the top-level logic is usually in a forever loop . 2. But not everything ...