Renesas 365: A New Web-Based Development Platform

Good embedded software should survive a hardware swap. If changing your MCU breaks your logic, your architecture is wrong. And that’s a problem. Because in the real world: - Parts go out of stock - BOMs shift - Boards get respun - Vendors get replaced If your firmware is tightly coupled to the silicon, every hardware change becomes a major rewrite. But if your architecture is clean: - Business logic sits above clear interfaces - Drivers are swappable - Hardware quirks are isolated, not scattered Remember, modern embedded systems aren’t static. They’re evolving platforms. And good platforms don’t fall apart when one component changes. So if you’re serious about maintainability, build your system like it might outlive the hardware it runs on.

🚗💻 Want to attract and retain the best software talent in automotive? Give developers the freedom to set up the tests they need in a stable environment - and ownership of the functionality they’re building - before they depend on other teams or hardware. With Virtual Integration Testing, you can: ✅ Test any vehicle logic early – without waiting for hardware ✅ Run stable, reproducible tests across ECUs, apps & features ✅ Iterate faster, collaborate in code, and cut integration costs It’s not just about testing – it’s about empowering developers to #getstuffdone and enjoy working in parallel on central functions and features that matter. 👉 Learn more https://lnkd.in/dQtf-FBi -and shift integration left to keep innovation moving! #getstuffdone #automotivesoftware #virtualintegration #remotivelabs

This has happened a lot for us at Frickly Systems GmbH: One or two days before we have to deliver hardware to a customer, the final revision of a PCB arrives. And one thing that always happens: An electronics engineer has changed the pin configuration, as this ways easier for them to do the layout. In our very first projects, we had written firmware where the hardware configuration was stored as constants at the beginning of source files. This was easy to change, but in this kind of situation I want to have code that is running on the new and the old revision. Because the first step I have to take is to validate that the new revision still works at least a good as the old one. Our current way of working is define the information the software needs in a devicetree. Together with systems that support devicetrees, like Linux and Zephyr, we can directly use different revisions or versions of hardware. If I now get a new revision of the hardware I just create a new DTS file for the revision and update the changes from the hardware. I do not have to change anything in the source files, not even some #if statements. But also the DTS of the existing revision does not have to change. So I am confident that I do not break anything with the old revision, while I test and bring up the new revision. This greatly helps to bring up hardware without stress and helps to deliver the late revision to the customer in time. What is a Devicetree? Think of devicetree as a blueprint for your hardware, a structured data format that describes what components exist on your board and exactly how they're connected. Instead of hardcoding hardware details into your software, you declare them in a clean, readable format that your drivers can consume at runtime. Why Devicetree is a Game-Changer 🔧 Decouples drivers from boards: One well-written driver can support dozens of boards through compatible strings and devicetree properties. 📋 Single source of truth: Bootloader, kernel, and user space all speak the same language about hardware addresses, IRQs, and connections. ⚡ Less board-specific code: Fewer per-board C files means easier maintenance and smoother upstreaming to mainline. 🚌 Perfect for SoC buses: Unlike PCI with auto-discovery, embedded buses need explicit description. 🧩 Flexible composition: Use .dtsi includes and overlays to build a library of reusable components. Define your SoC once, then specialize for each carrier board. ⚖️ Clean separation: Hardware facts live in devicetree; runtime policy stays in software where it belongs. The result? More maintainable code, faster hardware bring-up, and teams that can iterate independently without stepping on each other's toes. Want to dive deeper? I'm planning to share some practical examples and implementation details in upcoming posts. What's your experience with hardware abstraction in embedded systems? #EmbeddedSystems #DeviceTree #Linux #HardwareDesign #SoftwareEngineering #EmbeddedLinux

In embedded software, especially when working with layered architectures, many developers stumble on the difference between BSP (Board Support Package) and HAL (Hardware Abstraction Layer). Both abstract hardware, but they do so at different layers: ⚡ HAL (Hardware Abstraction Layer) : . Provides chip-level abstraction. . Offers a set of generic APIs to interact with microcontroller peripherals (GPIO, UART, I²C, SPI, Timers, ADC, …). . Makes firmware more portable across boards that share the same MCU family. ⚡ BSP (Board Support Package) : . Provides board-level adaptation. . Bridges the HAL (or drivers) to the specific hardware design of a given board. . Handles pin mappings, clock configuration, memory layout, external device drivers, and startup code. In simple terms , think of it this way: HAL = how the MCU peripherals work. BSP = how this specific board is wired. Together, they build the foundation that allows your application or RTOS to run seamlessly across different boards and products.

Excited to share my latest embedded systems project! I’ve been building an embedded software platform for the Renesas RH850/P1M (automotive-grade MCU) from scratch. The project integrates key modules that are common in industry-grade ECUs: Scheduler (SchM): Cooperative scheduler for periodic task execution without RTOS Watchdog Manager (WdgM): Safety layer with diagnostic hooks Timer Abstraction: 1ms system tick driver on TAUJ0 CRC-6 Implementation: Ensuring reliable SPI communication with data integrity checks Modular Project Structure: Clear separation of drivers, diagnostics, services, and application layers 📂 The full source is now available on GitHub: 👉 https://lnkd.in/gnGPyBcA This effort reflects the kind of bare-metal, safety-critical software that goes into automotive microcontrollers before scaling up to AUTOSAR or RTOS environments. Would love to hear feedback from the embedded community — especially around improving scheduler design, error handling strategies, and integration with AUTOSAR-like patterns. #EmbeddedSystems #Automotive #RH850 #BareMetal #CProgramming #Watchdog #Scheduler

The uncomfortable truth about firmware development: Every component you’re using today comes with an expiration date. That sensor? End of life next year. That MCU? A shortage could wipe it off your BOM. That radio? One regulatory change and it’s gone. So here’s the real question: When the part disappears, does your system survive? Too much firmware is written as if the hardware will live forever. But survival doesn’t belong to the silicon. It belongs to the contracts. The interfaces. The protocols. If your code is tightly coupled to a register map, you’ve built in an expiration date. If you abstract cleanly—ownership, timing, recovery boundaries—your system can outlive every datasheet. The lesson is simple: don’t design for the part. Design for the replacement. Great engineers don’t just write firmware that works. They write firmware that survives supply chains.

⚙️ The Art of Embedded Drivers In embedded systems, it’s never enough that the code “just works.” A driver must be designed to work right: ✅ With Recovery in mind – because things will fail. ✅ With Restart capability – so the system can get back on track without rebooting the whole product. ✅ With the discipline to design one robust solution, instead of patching 9 parallel systems just in case. Otherwise — you crash. That’s the true engineering challenge: Not only writing code, but crafting it to survive the unexpected. This is what separates a quick fix from a professional, resilient embedded system. 👉 That’s my approach to real-time embedded software: Every driver I build is not just functional — it’s built to recover, restart, and last. asaf.tvito@rtdevsoft.com +972-522564597

Insyde Software is Helping Power the Future of AI-Enabled Arm-based PCs Earlier this summer, we announced that InsydeH2O® UEFI BIOS delivers full support for Arm® Compute Subsystems (CSS) for Client platforms. Insyde Software is proud to provide the firmware foundation that will help accelerate innovation for AI-enabled Arm-powered PCs. Our early readiness and production-quality UEFI firmware empower our customers to: ✅ Speed up platform bring-up ✅ Reduce development complexity ✅ Launch next-gen AI-enabled PCs faster and with confidence Read our announcement: https://lnkd.in/gtu77k_k

What’s the Difference Between Hardware, Firmware, and Software in Electronic Design? Hardware is the physical part of your product: the circuit boards, chips, connectors, and all the tangible components. Firmware is the low-level, embedded code programmed directly onto hardware. It controls how the hardware operates and communicates with other systems. Think of it as the essential instructions that make hardware usable. Software is the higher-level application layer: the programs and interfaces that users interact with or that manage system functions on top of firmware. At DSL, we design all three elements in parallel. This integrated approach prevents development delays, improves system integration, and accelerates time-to-market, ensuring your product works seamlessly from hardware through to user experience.

📈 Ansys part of Synopsys and SYSGO - Embedding Innovations are teaming up to accelerate safety-critical software development and certification by up to 50%. By combining SYSGO’s PikeOS RTOS with Ansys SCADE model-based tools, engineering teams can: ✔️ Cut time-to-market and certification costs ✔️ Achieve the highest safety standards (DO-178C, ISO 26262, EN 50716, IEC 61508) ✔️ Safely mix high- and low-criticality applications on the same target ✔️ Support safety-critical multi-rate applications Together, we deliver a seamless workflow—from design in Ansys SCADE to integration in SYSGO CODEO—helping customers build safer, faster, and more reliable embedded systems. #SafetyCritical #EmbeddedSoftware #Ansys #SYSGO #DigitalSafety Download the one-pager 👇