Visual Programming Languages: Thirteen Tools That Teach Code Before Syntax

We are in an AI era. A student can paste a homework prompt into a chatbot and get working Python back in seconds. That does not mean they can read the result, fix it, or tell a good loop from a lucky guess. Before kids step into AI usage, they still need the old core: what a program is, how logic branches, and why a computer only does what you asked, not what you meant.

Visual programming languages (VPLs) are the school-friendly way to build that core. You snap a block, draw a flowchart, or move a character, then watch the idea run. Typing, and later prompting, come after the student can see sequence, choice, and loops. A first class that dies on a missing semicolon never gets that far. A class that starts visual usually does.

This post walks through thirteen tools that keep showing up on school laptops, lab benches, and phone screens: Flowgorithm, MIT Scratch, Blockly, Snap!, Sketchware, Alice, MIT App Inventor, Kodu, Moenagade, Open Roberta, Kojo (Kogics), Visual Logic, and Flowcode. They are not one product family. They share one bet: if you can see the program, you can think about the program, and that thinking is still required in an AI classroom (Resnick et al., 2009; Cook, 2015).

Key Abbreviations in This Post

• VPL (Visual Programming Language): A language you build by placing shapes, not by typing source first.
• IDE (Integrated Development Environment): The editor, runner, and debugger in one window.
• CS1: A first university or college programming course.
• BYOB (Build Your Own Blocks): The Scratch fork that became Snap!. Adds first-class procedures.
• NEPO: The block language used in Open Roberta Lab (Fraunhofer IAIS).
• APK (Android Package): The install file an Android phone runs.
• SoC / MCU (Microcontroller): The small chip Flowcode and robot labs actually flash.
• EV3 / micro:bit / Arduino: Common classroom robots and boards that Open Roberta and similar tools target.
• Scala: The text language behind Kojo. Looks like a modern Java cousin, with a gentler start.
• Export / code gen: Turning a flowchart or block stack into C++, Java, Python, or similar.

The One-Minute Version

• Scratch, Snap!, Blockly: Puzzle blocks. Scratch is the kids' studio. Snap! is the university-strength cousin. Blockly is the library other apps sit on.
• App Inventor and Sketchware: Same block idea, aimed at a phone app. App Inventor is browser plus companion. Sketchware lives on the phone.
• Alice and Kodu: 3D stories and games. Sequence and events without a blank text file.
• Flowgorithm, Visual Logic, Flowcode: Executable flowcharts. The first two teach algorithms. Flowcode talks to real boards.
• Open Roberta: Browser blocks for robots. No local install fight with school IT.
• Moenagade: Blocks that become real Java you can open in NetBeans.
• Kojo (Kogics): Turtle, art, math, and Scala. Visual canvas, text language.

Why These Tools Exist

Text languages punish beginners twice. First for the idea. Then for the grammar. A Hello World in Java already hides classes, static methods, and string arrays. The student needed output. They got object-oriented ceremony (Cook, 2015).

Research on CS1 keeps finding the same pattern. Students spend the hour hunting syntax, then leave without a working algorithm. Visual tools cut the grammar tax so the hour goes to sequence, choice, loops, and events (Gudmundsen et al., 2012; Cooper et al., 2000).

Problem: a 14-year-old can describe "if the sprite hits the wall, bounce," but cannot type the event handler.
Cause: the language wants listeners, coordinates, and braces before it will move a pixel.
Effect: they quit, or they copy a snippet they cannot read. A block editor lets them snap when touching edge, bounce and see it work the same afternoon (Resnick et al., 2009).

That is the whole family in one story. The tools differ in shape: flowchart, puzzle, 3D stage, robot, phone, or turtle canvas.

Block Studios: Scratch, Blockly, Snap!

These three get mixed up in every faculty meeting. Scratch is a product kids open. Blockly is a JavaScript library you embed. Snap! is a Scratch descendant that treats procedures as data, which is why UC Berkeley can teach CS10 with it (Harvey & Mönig, 2010; Fraser, 2015).

MIT Scratch

Scratch came out of the Lifelong Kindergarten group at the MIT Media Lab, led by Mitchel Resnick. The public 1.0 release was 2007. Scratch 2.0 moved to the browser in 2013. Scratch 3.0 (2019) rebuilt the editor on Blockly (Resnick et al., 2009; Scratch Foundation, 2019).

You drag colored blocks: motion, looks, sound, events, control, sensing, operators, variables. Sprites live on a 2D stage. The community is the other half of the product. Kids remix shared projects, which is how a cat-chasing-a-mouse game becomes a thousand variants.

Use it when: ages 8 to 16, clubs, intro computing, media and storytelling. Not when you need a published Android store app or a PIC microcontroller.

Problem → cause → effect: a middle-schooler wants a game by Friday. A text IDE asks for a window toolkit first. Scratch gives a stage, a green flag, and a forever loop. They ship a playable sketch, then later ask what a real loop looks like in Python.

Blockly

Google released Blockly as open source in 2012. Neil Fraser and the Blockly team built a drop-in block editor: toolbox, workspace, code generators for JavaScript, Python, PHP, Lua, Dart, and others (Fraser, 2015).

You do not "switch a class to Blockly" the way you switch a class to Scratch. You put Blockly inside something else. App Inventor, Code.org, MIT Scratch 3, Microsoft MakeCode, and Open Roberta all sit on that idea. The blocks look familiar because the library taught the industry a visual grammar: C-shaped loops, puzzle-piece types, a trash can.

Use it when: you are building an editor, a lesson site, or a hardware tool and you do not want to invent snapping from scratch.

Snap!

Snap! (often written Snap) grew from BYOB, a Scratch modification by Jens Mönig and Brian Harvey. The goal was a ceiling, not only a floor. You can build your own blocks. Lists and procedures are first-class. You can write a map or a recursive tree without leaving the block world (Harvey & Mönig, 2010).

Berkeley's Beauty and Joy of Computing course uses Snap! so students meet abstraction before they meet Java braces. If Scratch is "make a game," Snap! is "make a language that makes games."

Use it when: high school AP-style computing, CS0/CS1 that wants functions as values, or a Scratch kid who outgrew the built-in palette.

Phone Apps: App Inventor and Sketchware

Two answers to "can I ship something my friends can install?" One assumes a laptop. One assumes only a phone.

MIT App Inventor

App Inventor started at Google in 2009 and moved to MIT in 2011 and 2012. The current MIT App Inventor is a browser IDE: Designer for screens and components, Blocks for behavior. The block engine is Blockly. Companion apps on Android (and later iOS) let you live-test without a full compile every click (Wolber et al., 2014; MIT App Inventor, 2024).

You get sensors, maps, speech, TinyDB, and web APIs as components. That is why a civic-tech class can build a pothole reporter in two weeks. The limit is the component set and the performance of the generated app, not the student's ability to type Java.

Sketchware

Sketchware put the same block idea on the Android device itself. You design a layout, snap logic, and build an APK on the phone. The original commercial app later stalled. The community kept the idea alive as Sketchware Pro (Sketchware Pro, 2023).

It is messy in the way phone-native tools are messy: storage permissions, signing keys, Play Store policy. It is also the only option in rooms where there is no laptop cart.

Problem → cause → effect: a college club wants a campus bus app. App Inventor gives Designer plus Blocks on a lab PC, then a QR install. A student with only a phone uses Sketchware and sideloads the APK. Same visual habit. Different hardware constraint.

Stories and Games: Alice and Kodu

Alice

Alice is a 3D environment from Carnegie Mellon University. Randy Pausch, Steve Cooper, and Wanda Dann built it so novices could tell a story in a virtual world while learning objects, methods, and events (Cooper et al., 2000). Alice 3 added a path toward Java and aligned characters with a commercial 3D gallery.

A student drops a person in a room, writes walk to the door, then say "hello". The camera and the character make bugs obvious. If the person walks through the wall, the algorithm is wrong. You do not need a debugger log.

Kodu

Kodu Game Lab came from Microsoft Research (Matt MacLaurin and team). It started on Xbox and later landed on Windows. Rules look like tiles: WHEN see apple DO move toward. Terrain, characters, and scoring sit in a small 3D world (MacLaurin, 2011).

Kodu teaches event-condition-action, not algebra. That is a feature. A primary class can build a collect-the-coins game without variables if they do not need them yet. When they do, score and pages are there.

Use Alice when the course wants objects and storytelling on a PC.
Use Kodu when the course wants a game controller, a hill, and a rover, and the students are younger.

Flowchart Trio: Flowgorithm, Visual Logic, Flowcode

Blocks hide syntax. Flowcharts hide almost everything except control flow. Intro algorithm courses love them because the chart is the program.

Flowgorithm

Devin Cook at California State University, Sacramento, built Flowgorithm as a free, executable flowchart language. You drop start, input, assign, output, if, loops, functions, and arrays. You run it. A watch window shows variables. Then you generate C#, C++, Java, JavaScript, Python, Ruby, Swift, Visual Basic, and more, interactively, so the student can see how a diamond becomes an if (Cook, 2015; Flowgorithm, 2024).

It is Windows-first, light, and honest about its job: teach logic, then hand the student a real language.

Visual Logic

Visual Logic (visuallogic.org) is a commercial executable-flowchart tool used in U.S. program-logic courses. It covers variables, input and output, conditions, loops, procedures, arrays, and files. The demo watermarks and will not save. Departments buy a license when they want a whole CS0 term on charts, then a jump to Python or Java (Gudmundsen et al., 2012; Crews & Murphy, 2009).

Compared with Flowgorithm, Visual Logic is less about multilingual export and more about a closed teaching loop: draw, run, grade.

Flowcode

Flowcode, from Matrix TSL in the United Kingdom (the company once known as Matrix Multimedia), is a commercial visual IDE for embedded systems. Students draw flowcharts or use a mix of flowchart, blocks, and C, then simulate and download to PIC, Arduino, AVR, and other boards. Education licenses pair with E-blocks, AllCode robots, and curriculum packs for motors, sensors, and comms (Matrix TSL, 2024).

Do not treat Flowcode as a CS1 flowchart toy. It is an electronics and mechatronics tool that happens to be visual. The "Hello World" is an LED, not a console line.

Problem → cause → effect: a technician course must teach PWM before it teaches pointers. Flowcode lets the student chart "read pot, write duty cycle," simulate the LED brightness, then flash a board. They meet C later, when the generated code is no longer magic.

Robots and a Java Bridge: Open Roberta and Moenagade

Open Roberta

Open Roberta Lab is a browser environment from Fraunhofer IAIS in Germany, grown out of the Roberta initiative that put robots in schools. The language is NEPO, a Blockly-inspired block set. Pick a robot, snap actions and sensors, run a simulation or download. Targets have included LEGO EV3, NXT, WeDo, Calliope, micro:bit, Arduino-class boards, NAO, and others. Generated code depends on the target: Java, Python, C/C++, MicroPython (Fraunhofer IAIS, 2024).

The classroom win is logistics. No admin rights. Any OS. One URL. A teacher can move from EV3 one term to micro:bit the next without rewriting the pedagogy.

Moenagade

Moenagade is a small, honest tool. Franz-Josef Schmitt (fesch) published it around 2017 from Luxembourg (moenagade.fisch.lu, GitHub fesch/Moenagade). It is GPL-3. Blocks describe beginner Java structures. The point is the live conversion to real, executable Java that you can later open in NetBeans or Unimozer (Schmitt, 2017).

It is limited on purpose. Other block tools hide the text. Moenagade exists because the author wanted students to see the Java appear while they still remember why they snapped the loop.

Kojo, from the Kogics Foundation

People write "Kogics" on a syllabus and mean Kojo. Kogics is the foundation. Kojo is the learning environment Lalit Pant built: desktop app for Linux, Windows, and Mac, plus a web app. The language is Scala. The first contact is often turtle graphics, then pictures, animation, games, music, and even Arduino (Kogics Foundation, 2024).

Kojo is a hybrid, not a pure VPL. You type. The canvas answers. That is closer to Logo and Processing than to Scratch. Indian state curricula have used it in grades 7 to 10 because one tool can cover drawing, math, and a path into a real industrial language.

Use it when: you want art and algebra in the same window, and you are willing to teach a little text on day one.

How the Thirteen Compare

Which Tool Fits the Room

Do not start with the brand on a conference slide. Start with the artifact and the hardware you already own.

• Kids, games, remix culture: Scratch. If they outgrow it, Snap!.
• Phone in their pocket: App Inventor if you have laptops. Sketchware if you do not.
• 3D story, objects, later Java: Alice.
• Controller and a landscape: Kodu.
• CS0 algorithm unit, Windows lab: Flowgorithm (free) or Visual Logic (licensed, save/grade workflow).
• Electronics, PIC, Arduino kits you already bought from a UK catalog: Flowcode.
• Robot cupboard, locked-down school PCs: Open Roberta in the browser.
• Must see Java this term: Moenagade, then NetBeans.
• Math, art, India-friendly curriculum, Scala later: Kojo.
• You are the one writing the editor: Blockly.

A Classroom Path That Does Not Trap Students

Visual tools fail when they become a gated community. The student can snap forever and still freeze in front of a blank main. The better path is short and visible.

1. See the idea. Stage, flowchart, or robot. One output on day one.
2. Snap or draw the steps. Sequence, then if, then loop. Name the pattern out loud.
3. Run and watch. Step mode if the tool has it (Flowgorithm's watch window, Scratch's single-step, robot simulation).
4. Fix the bug you can see. The sprite walks through the wall. The LED never lights. The flowchart never reaches Output.
5. Export once, on purpose. Flowgorithm to Python. Moenagade to Java. Open Roberta to the target language. App Inventor students open the built APK and talk about events in words that will match later Java listeners.

Problem: year-10 students ace Scratch and fail the first Python quiz.
Cause: the course never showed that a C-shaped block is a while, and never made them type one.
Effect: they call visual languages "not real." Pair every unit with a 20-minute export or rewrite. The tool is a scaffold, not a career.

What These Tools Are Not

They are not a replacement for data structures, complexity, or systems programming. They will not make a production backend. Blockly inside a factory HMI is still an HMI, not a proof that blocks scale to every domain.

They also are not all free, and they are not all alive at the same speed. Visual Logic and Flowcode are commercial. Sketchware's original store listing went quiet. Moenagade's last public push was 2018. Scratch, Snap!, Blockly, App Inventor, Open Roberta, Kojo, and Flowgorithm are the ones you can plan a three-year curriculum around without holding your breath.

Pick the living tool that matches the artifact. Keep the export step. Treat the colorful blocks as a way to think, not as a place to hide.

References

• Cook, D. D. (2015). Flowgorithm: Principles for teaching introductory programming using flowcharts. ASEE Annual Conference. https://peer.asee.org/flowgorithm-principles-for-teaching-introductory-programming-using-flowcharts
• Cooper, S., Dann, W., & Pausch, R. (2000). Alice: A 3-D tool for introductory programming concepts. Journal of Computing Sciences in Colleges, 15(5), 107–116.
• Crews, T., & Murphy, C. (2009). A guide to working with Visual Logic. Course Technology.
• Flowgorithm. (2024). Flowgorithm: Flowchart programming language. http://flowgorithm.org/
• Fraser, N. (2015). Ten things we've learned from Blockly. In 2015 IEEE Blocks and Beyond Workshop (pp. 49–50). IEEE. https://developers.google.com/blockly
• Fraunhofer IAIS. (2024). Open Roberta Lab. https://lab.open-roberta.org/
• Gudmundsen, D., Olivieri, L., & Sarawagi, N. (2012). Reducing the learning curve in an introductory programming course using Visual Logic. Journal of Computing Sciences in Colleges, 27(4), 10–12.
• Harvey, B., & Mönig, J. (2010). Bringing "no ceiling" to Scratch: Can one language serve kids and computer scientists? Constructionism 2010. https://snap.berkeley.edu/
• Kogics Foundation. (2024). Kojo. https://www.kogics.net/kojo
• MacLaurin, M. (2011). The design of Kodu: A tiny visual programming language for children on the Xbox 360. Proceedings of the 38th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (pp. 241–246). ACM.
• Matrix TSL. (2024). Flowcode for education. https://flowcode.co.uk/education/
• MIT App Inventor. (2024). MIT App Inventor. https://appinventor.mit.edu/
• Resnick, M., Maloney, J., Monroy-Hernández, A., Rusk, N., Eastmond, E., Brennan, K., Millner, A., Rosenbaum, E., Silver, J., Silverman, B., & Kafai, Y. (2009). Scratch: Programming for all. Communications of the ACM, 52(11), 60–67. https://scratch.mit.edu/
• Schmitt, F.-J. (2017). Moenagade [Computer software]. GitHub. https://github.com/fesch/Moenagade
• Scratch Foundation. (2019). Scratch 3.0. https://scratch.mit.edu/
• Sketchware Pro. (2023). Sketchware Pro [Computer software]. GitHub. https://github.com/Sketchware-Pro/Sketchware-Pro
• Wolber, D., Abelson, H., Spertus, E., & Looney, L. (2014). App Inventor 2: Create your own Android apps. O'Reilly.

Read More

Bluetooth, BLE, UWB, RFID, and nRF(NFC): What Is the Same, What Is Different

 

Five names show up on every short-range wireless slide. Four of them are radios or tag systems. One of them is a chip brand. Teams mix them up, then pick the wrong one and spend a year fixing range, battery, or cost.

This post puts Bluetooth Classic, Bluetooth Low Energy (BLE), Ultra-Wideband (UWB), Radio-Frequency Identification (RFID), and Nordic nRF next to each other: what they share, where they split, and which use case each one actually wins.

Key Abbreviations in This Post

• BT (Bluetooth Classic): The original Bluetooth radio. Built for audio and continuous data, not tiny coin-cell sensors.
• BLE (Bluetooth Low Energy): A different Bluetooth radio mode. Same 2.4 GHz band, much lower power, used for sensors, beacons, and phone pairing.
• UWB (Ultra-Wideband): Short pulses over a very wide band. Measures time of flight to get distance to about 10 cm.
• RFID (Radio-Frequency Identification): A reader talks to a tag. Many tags are passive: no battery. Used to identify things, not to stream music.
• NFC (Near-Field Communication): A short-range HF RFID flavor (13.56 MHz). Payments and tap-to-pair. About 4 cm.
• nRF: Nordic Semiconductor's chip family (nRF52, nRF53, nRF54). Hardware that usually runs BLE, Thread, or Matter. Not a radio standard.
• RSSI (Received Signal Strength Indicator): How loud the radio sounds. Used to guess distance. Often wrong by meters.
• ToF (Time of Flight): How long the radio wave takes to travel. Used by UWB for real distance.
• SoC (System on Chip): Processor, radio, and memory on one die. An nRF52840 is an SoC.

The One-Minute Version

• Same job, different physics: all five show up in "talk to a nearby thing" products. They do not do that job the same way.
• Bluetooth Classic: headphones, speakers, car audio. Needs more power. Streams data.
• BLE: sensors, beacons, phone apps, "find my" wake-up. Cheap, everywhere, bad at exact distance.
• UWB: "how far, and in which direction, for real." Car keys, AirTag arrows, warehouse safety.
• RFID: "what is this tag?" Access cards, inventory, livestock. Passive tags can last forever.
• nRF: the silicon you solder when the product speaks BLE (and often Thread or NFC). You still choose the protocol.

One Picture of the Family

If you remember one line: Bluetooth, BLE, UWB, and RFID are how devices talk. nRF is a part you buy so a device can talk BLE.

What Is the Same

They overlap because products need the same three verbs: find, identify, connect.

• Short range. Meters to tens of meters for most jobs. Not a cellular replacement.
• Unlicensed or shared bands for the radio flavors (2.4 GHz for BT/BLE; 3.1 to 10.6 GHz for UWB; several RFID bands).
• A reader and a thing. Phone and earbuds. Phone and tag. Gate and badge. Forklift and badge.
• Often stacked. An AirTag uses BLE to be discovered and UWB to draw the arrow. A hotel lock may use RFID for the card and BLE for the phone.
• Security is optional until it is not. Pairing, encryption, and distance-bounding are add-ons. Cheap beacons and cheap RFID tags are easy to clone if you skip them.

What Is Different

	Bluetooth Classic	BLE	UWB	RFID	nRF
What it is	Radio protocol	Radio protocol	Radio protocol	Tag + reader family	Chip / SoC brand
Main job	Stream audio / data	Low-power connect	Measure distance	Identify a tag	Run the firmware
Band	2.4 GHz	2.4 GHz	3.1 to 10.6 GHz	125 kHz, 13.56 MHz, 860 to 960 MHz	Depends on radio on the die (usually 2.4 GHz)
Typical range	10 m (room)	10 to 50 m; long-range modes more	10 to 50 m (line of sight)	4 cm (NFC) to 10+ m (UHF)	Whatever protocol you flash
Distance accuracy	Poor (RSSI)	Poor (RSSI); better with AoA	About 10 cm (ToF)	In field or not; not a tape measure	N/A
Tag / device power	Battery, hours of audio	Coin cell, months to years	Battery; ranging costs more than BLE advertise	Often none (passive)	The MCU plus radio current
Cost of the "tag"	Whole gadget	A few dollars	Higher (special chip + antenna)	Cents to a dollar (passive)	Chip price, not a tag
Phone support	Universal	Universal	Flagships (Apple, Samsung, Google, and growing)	NFC only on most phones; UHF needs a reader	Inside many BLE gadgets, not the phone itself

Each One, With a Real Example

Bluetooth Classic: the headset

You pair AirPods-class buds or a car stereo. The radio stays up and moves audio for hours. Classic Bluetooth (BR/EDR) was built for that continuous link. Putting the same job on BLE is possible in later specs, but most cars and speakers still speak Classic for audio.

Use when: the user hears or sends a stream. Do not use when: you need a five-year battery on a sticker.

BLE: the sensor and the "hello"

A heart-rate strap, a temperature logger, or a supermarket beacon advertises every second. A phone app connects, reads a few bytes, disconnects. BLE was designed for that duty cycle. Almost every smartphone can talk to it. Distance from signal strength is a guess: walk behind a fridge and "3 meters" becomes "12 meters."

Use when: phones must see you, power is tight, data is small. Do not use when: a forklift must stop at 1.5 m, not "somewhere nearby."

UWB: the tape measure

A digital car key measures time of flight. A relay thief in the street cannot make the radio wave travel faster than light, so the car stays locked. An iPhone draws an arrow to an AirTag because UWB gives distance and angle, not just "nearby." IEEE 802.15.4z is the secure-ranging standard behind most phones and cars (IEEE, 2020).

Use when: centimeters and anti-relay matter. Do not use when: you need a 5-cent tag on every carton.

RFID: the nametag

A warehouse portal reads a hundred UHF tags on a pallet as it rolls through. A badge on a lanyard opens a door at 13.56 MHz. A cow ear tag at 134 kHz survives mud. The tag is often a coil and a chip with no battery. The reader supplies the energy. RFID answers "who is this?" It does not play a podcast or report live GPS.

Use when: you must identify many cheap things, or tap a card. Do not use when: the thing must call a cloud API every minute with no reader nearby.

nRF: the board you design

A product spec says "BLE sensor, 2 years, over-the-air updates." The engineer picks an nRF52840 or nRF54 series part from Nordic Semiconductor, writes Zephyr or nRF Connect SDK firmware, and ships BLE. Some nRF parts include NFC for tap-to-pair. nRF is not competing with UWB as a standard. Nordic is a silicon vendor. Qorvo, NXP, and others make the UWB chips. You can put both on one board.

Use when: you are building the gadget. Do not say: "we will use nRF instead of BLE." That sentence does not parse.

Use-Case Chooser

How Products Combine Them

Real Use Cases (Problem → Cause → Effect)

1. Office access with phones only

Problem: Staff lose plastic cards. Security wants phone unlock.

Cause: RFID cards are cheap but they are extra plastic. BLE "nearby" unlocks the door from the sidewalk.

Effect: Keep RFID for visitors and backups. For phones, use BLE to wake and UWB (or a tight NFC tap) to prove the person is at the reader, not in the parking lot.

2. Lost keys in a house

Problem: A BLE-only tag says "nearby." You still search for ten minutes.

Cause: RSSI cannot point. Walls change the number.

Effect: BLE finds the room. UWB draws the last-meter arrow. That is why finder tags added UWB.

3. Retail inventory

Problem: A store wants to know which jackets are on which rack.

Cause: Putting a BLE or UWB battery in every garment is cost and waste.

Effect: Sew a UHF RFID inlay. Walk a handheld reader. Count a thousand items. Use BLE only on the scanner, maybe on an nRF board.

4. "We specified nRF for location"

Problem: A spec sheet lists nRF as the location technology.

Cause: The team named the chip, not the measurement method. nRF running BLE still uses RSSI unless you add AoA hardware or a UWB chip.

Effect: Rewrite the spec: protocol first (BLE vs UWB vs RFID), then pick silicon (nRF, Qorvo, Impinj, NXP).

A Simple Decision Rule

1. If the thing has no battery and you only need an ID, use RFID (NFC if a phone must tap).
2. If a phone app must talk cheaply for years, use BLE. Build it on nRF or a peer SoC.
3. If a human must hear a stream, use Bluetooth Classic.
4. If you must prove distance or point at the thing, add UWB. Keep BLE for discovery.
5. Never treat nRF as a substitute for UWB or RFID. It is the engine, not the road.

Bluetooth Classic moves sound. BLE moves small data on a diet. UWB measures time so distance is real. RFID names cheap things, often with no battery. nRF is Nordic's SoC that usually speaks BLE.

They are the same only at the slogan level: short-range wireless. They differ in physics, power, cost, and what question they can answer. Pick the question first. Then pick the radio. Then pick the chip.

References

• Bluetooth SIG. Bluetooth Core Specification (Classic and Low Energy). https://www.bluetooth.com/specifications/specs/
• IEEE. (2020). IEEE 802.15.4z-2020: Enhanced ultra wideband physical layers and associated ranging techniques. IEEE Standards Association.
• ISO/IEC 18000 and ISO/IEC 14443. RFID and proximity-card (NFC) air interfaces.
• Nordic Semiconductor. nRF52, nRF53, and nRF54 series product pages. https://www.nordicsemi.com/
• GS1. EPC UHF Gen2 for item-level RFID. https://www.gs1.org/

Read More

Install Linux on Raspberry Pi: A Picture Guide for CLI, GUI, and Custom Builds

 

This is a picture-first guide. Each numbered graphic is a step. You can install a desktop Linux, a headless server Linux, or a Linux you built yourself. The board stays the same. Only the image on the microSD card changes.

Key Abbreviations in This Post

• SBC (Single-Board Computer): A complete computer on one board. Raspberry Pi 5 and Pi 4 are SBCs.
• CLI (Command-Line Interface): Text terminal. No desktop. Used for servers and headless Pis.
• GUI (Graphical User Interface): Desktop with windows, mouse, and a monitor.
• Imager / rpi-imager: Official Raspberry Pi tool that writes an OS image to a card. Has GUI and CLI modes.
• Lite image: Raspberry Pi OS without a desktop. SSH and terminal only.
• Headless: Run the Pi with no monitor. You log in over the network.
• pi-gen: Official script that builds custom Raspberry Pi OS images.
• Yocto: Build system for reproducible embedded Linux (uses the meta-raspberrypi layer).
• Buildroot: Simpler builder for small appliance images.
• SSH (Secure Shell): Remote login over the network.

The One-Minute Version

• GUI desktop: Install Raspberry Pi Imager, pick your Pi model, pick Raspberry Pi OS Desktop (or Ubuntu Desktop), write the card, plug in HDMI, power on.
• CLI / headless: Same Imager, pick Raspberry Pi OS Lite (or Ubuntu Server). Turn on SSH and Wi-Fi in Imager settings. Power on. Then ssh user@raspberrypi.local.
• CLI from a Linux PC: sudo rpi-imager --cli image.img.xz /dev/sdX after lsblk confirms the card.
• Custom product image: Build with pi-gen, Yocto, or Buildroot. Flash the resulting .img the same way.
• Never guess the disk. Writing to the wrong /dev/sdX wipes a laptop drive.

Match the image to the board. A Pi 5 image will not boot a Pi 3. Prefer 64-bit images unless you have a 32-bit-only reason.

• Raspberry Pi board and official 5 V USB-C supply (Pi 5 needs a capable 5 V / 5 A supply).
• microSD card, 16 GB or larger, Class A2 if you can.
• USB card reader on your PC.
• For GUI: HDMI cable, monitor, keyboard, mouse.
• For CLI: Ethernet or Wi-Fi, plus another computer for SSH.

Flavor	Type	Use it when
Raspberry Pi OS Desktop	GUI	Best first image. Official drivers, camera, GPIO tools.
Raspberry Pi OS Lite	CLI	Headless servers, kiosks you SSH into, IoT.
Ubuntu Desktop / Server	GUI / CLI	You already know Ubuntu packages and cloud-init.
Debian	CLI (or add a desktop)	Closest to upstream Debian on Pi hardware.
DietPi	CLI	Small, fast, lots of one-click software recipes.
Alpine Linux	CLI	Tiny footprint, containers, appliances.
Fedora / Manjaro ARM	GUI	You want those desktop stacks on a Pi.

1. Download Imager from raspberrypi.com/software (Windows, macOS, or Linux). On Raspberry Pi OS: sudo apt install rpi-imager.
2. Open Imager. Choose Device (Pi 5, Pi 4, Zero 2 W, and so on).
3. Choose OS:
   • Raspberry Pi OS (64-bit) for a desktop.
   • Raspberry Pi OS Lite for CLI.
   • Other general-purpose OS for Ubuntu, Alpine, and more.
4. Choose Storage: your microSD (check the size so you do not pick the wrong disk).
5. Open OS Customisation (gear): set hostname, username, password, Wi-Fi, locale, and enable SSH.
6. Write. Eject. Insert the card in the Pi. Power on last.

# 1. See disks. Find the card by size.
    lsblk
    
    # 2. Unmount any auto-mounted partitions
    sudo umount /dev/sdX1 /dev/sdX2
    
    # 3a. Official CLI (verifies the write)
    sudo rpi-imager --cli raspios.img.xz /dev/sdX
    
    # 3b. Or classic pipeline
    xzcat raspios.img.xz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync
    sync

If the card shows as /dev/mmcblk0, write to /dev/mmcblk0, not mmcblk0p1.

Complete country, timezone, password, and updates. Enable SSH in Raspberry Pi Configuration if you will leave the monitor later. Then sudo apt update && sudo apt full-upgrade.

ssh youruser@raspberrypi.local
    # or ssh youruser@192.168.x.x   (check your router)

On current Raspberry Pi OS, Imager writes first-boot settings for you. That is safer than hand-editing the boot partition. If you must do it by hand on an older image, place an empty file named ssh on the boot partition.

• Ubuntu: Imager → Other general-purpose OS → Ubuntu. Desktop or Server. First login follows Ubuntu's cloud-init / first-boot notes.
• Debian: Use a Raspberry Pi Debian image built for your model, then flash with Imager or dd.
• DietPi: Download the Pi-model image from dietpi.com. Flash. First boot is a text installer for software stacks.
• Alpine: Listed under Other general-purpose OS in Imager, or follow the Alpine Raspberry Pi wiki.
• Fedora / Manjaro ARM: Download the aarch64 image for your Pi, then use Imager "Use custom" or the CLI.

sudo apt update && sudo apt full-upgrade
    sudo raspi-config
    # 1 System Options → Hostname, Password, Wireless
    # 3 Interface Options → SSH, SPI, I2C, Serial
    sudo reboot

A. pi-gen (custom Raspberry Pi OS)

Use this when you want Debian-like Raspberry Pi OS, but with your packages, user, and first-boot scripts baked in.

git clone https://github.com/RPi-Distro/pi-gen.git
    cd pi-gen
    
    # config file (example)
    cat > config << 'EOF'
    IMG_NAME=myproduct
    RELEASE=bookworm
    LOCALE_DEFAULT=en_US.UTF-8
    TARGET_HOSTNAME=myproduct
    FIRST_USER_NAME=admin
    ENABLE_SSH=1
    STAGE_LIST="stage0 stage1 stage2"
    EOF
    
    # Add extra packages in stage2/00-packages or a custom stage
    sudo ./build.sh
    # Output: deploy/*.img

Stages in short: 0 = bootstrap, 1 = base system, 2 = Lite (CLI), 3 = desktop extras, 4 = full desktop, 5 = recommended apps. Stop at stage2 for a custom CLI image.

B. Yocto + meta-raspberrypi

Use this when the Pi is a product: you need a locked-down rootfs, a software bill of materials, and repeatable builds.

git clone git://git.yoctoproject.org/poky
    git clone https://github.com/agherzan/meta-raspberrypi.git
    source poky/oe-init-build-env build
    # add meta-raspberrypi to conf/bblayers.conf
    # in conf/local.conf:
    #   MACHINE = "raspberrypi5"
    bitbake core-image-minimal
    # Flash the .wic or .rpi-sdimg from tmp/deploy/images/

C. Buildroot

Use this when the image must be small and boot fast.

git clone https://gitlab.com/buildroot.org/buildroot.git
    cd buildroot
    make raspberrypi5_defconfig    # or raspberrypi4_defconfig
    make menuconfig
    make -j$(nproc)
    # Flash output/images/sdcard.img

sha256sum deploy/myproduct.img
    sudo rpi-imager --cli deploy/myproduct.img /dev/sdX
    # Boot one board. Check SSH, app, and GPIO.
    # Only then clone the card or repeat the CLI write.

Real Use Cases (Problem → Cause → Effect)

1. Classroom of 20 desktop Pis

Problem: Students need a mouse, browser, and Thonny on every desk.

Cause: A Lite image has no desktop. Hand-configuring 20 cards wastes a day.

Effect: Flash Raspberry Pi OS Desktop with Imager. Set the same Wi-Fi and user in OS Customisation. Clone the first good card.

2. Home lab server in a drawer

Problem: No spare monitor. You want Docker and SSH only.

Cause: A full desktop wastes RAM and SD writes.

Effect: Flash Raspberry Pi OS Lite or Ubuntu Server. Enable SSH in Imager. ssh in and install Docker.

3. Factory kiosk that must not grow extra packages

Problem: Field units drift after apt upgrade and random desktop apps.

Cause: A general-purpose OS is not a product image.

Effect: Build with pi-gen (Debian-like) or Yocto (locked firmware). Flash the same .img on every unit. Disable unused interfaces in the build.

4. Tiny IoT node on a Zero 2 W

Problem: A desktop image will not fit well on a small card and a small CPU.

Cause: Desktop stacks assume a Pi 4/5 class board.

Effect: Use Alpine or DietPi, or a Buildroot image. Headless. SSH only.

Benefits for Teams That Ship Pi Products

If you do this	You get
Flash a stock Lite image + SSH	Fast prototype. Good for labs and one-off gateways.
Use Imager customisation on every card	Known hostname, user, Wi-Fi, and SSH without a monitor.
Build with pi-gen	Your app and users already installed. Same image for a classroom or a kiosk fleet.
Build with Yocto	Reproducible firmware, license list, smaller attack surface, longer product life.
Build with Buildroot	Smallest card, fastest boot, simple appliance.
Hash and test one board first	You do not clone a broken first-boot into 200 units.

Safety Rules (Read Once)

1. Confirm the SD device with lsblk. Wrong target wipes a PC disk.
2. Power the Pi after the card is seated. Do not hot-swap microSD on a running Pi.
3. Use a proper power supply. Undervoltage causes random first-boot failures.
4. Change the password on first login. Do not leave default credentials on a network.
5. Backup a known-good card: sudo dd if=/dev/sdX bs=4M status=progress | xz > gold.img.xz.

Installing Linux on a Raspberry Pi is writing the right image to a microSD card. Imager is the GUI path. rpi-imager --cli or dd is the CLI path. pi-gen, Yocto, and Buildroot are the custom-build path.

Start with Raspberry Pi OS Desktop if you have a screen. Start with Lite plus SSH if you do not. Build a custom image only when you will flash the same card many times or ship a product. The pictures above are the map. The command boxes are the ones to type.

References

• Alpine Linux. Raspberry Pi. https://wiki.alpinelinux.org/wiki/Raspberry_Pi
• Buildroot. The Buildroot user manual. https://buildroot.org/downloads/manual/manual.html
• Canonical. Install Ubuntu on a Raspberry Pi. https://ubuntu.com/download/raspberry-pi
• Raspberry Pi Ltd. Getting started: Install an operating system. https://www.raspberrypi.com/documentation/computers/getting-started.html
• Raspberry Pi Ltd. Raspberry Pi Imager. https://www.raspberrypi.com/software/
• RPi-Distro. pi-gen: Tool used to create Raspberry Pi OS images. https://github.com/RPi-Distro/pi-gen
• Yocto Project. meta-raspberrypi. https://github.com/agherzan/meta-raspberrypi

Read More