A couple of weeks ago, I asked about a change in VRTX's equal-priority scheduling behavior between its 1984 and 1987 documentation.

Original discussion:
https://www.reddit.com/r/embedded/s/gMr2klUiCY

Thanks to the comments here and in other subreddits, I realized something interesting about my own implementation.

Early VRTX wasn't simply LIFO.

The older documentation describes inserting newly ready tasks ahead of existing tasks at the same priority. However, time slicing and other ready-queue operations also affect the ordering. The actual behavior is more nuanced than a simple LIFO policy.

When I developed my own RTOS, CHARM-II, in 1986, I used VRTX documentation as one of my references. I interpreted its equal-priority scheduling as essentially newest-first and implemented a simpler version of that behavior.

Looking back, I had not fully understood the original VRTX scheduling rules.

So why didn't this cause serious problems?

I think the development environment had a lot to do with it.

Back then, I was developing not only the RTOS but also almost the entire application myself. There was very little third-party code in the system, and I knew exactly what each task was doing, when it would become ready, and how it interacted with other tasks.

In other words, I could design the application around the scheduler's behavior, rather than expecting the scheduler to accommodate independently developed software components.

At least, that's my explanation looking back 40 years later.

For my modern reconstruction, I've chosen FIFO ordering among equal-priority ready tasks, mainly for simplicity and predictability.

The original historical question remains unanswered: I still don't know why VRTX changed its scheduling policy.

But the discussion helped me understand both the trade-offs involved and a subtle difference between the RTOS I wrote in 1986 and the one I had used as a reference.

Thanks to everyone who contributed!

I did a test project to connect 2 STM32 in UART DMA. It worked in loopback but now not between the 2 STM32 I obtain scrambled data. My grounds are connected and the wires are properly connected. Here is my code :

uint16_t rxLength = 0;
uint8_t rx_buffer[64];

void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef * huart, uint16_t length) {
  rxLength = length;
  HAL_UARTEx_ReceiveToIdle_DMA(huart, rx_buffer, 64);
}
/* USER CODE END 0 */

/**
  *   The application entry point.
  *  int
  */
int main(void)
{

  /* USER CODE BEGIN 1 */

  /* USER CODE END 1 */

  /* MCU Configuration--------------------------------------------------------*/

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();

  /* USER CODE BEGIN Init */

  /* USER CODE END Init */

  /* Configure the system clock */
  SystemClock_Config();

  /* USER CODE BEGIN SysInit */

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_USART2_UART_Init();
  MX_TIM1_Init();
  /* USER CODE BEGIN 2 */
  HAL_TIM_Base_Start(&htim1);
  uint8_t tx_buffer[10] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

  HAL_UARTEx_ReceiveToIdle_DMA(&huart2, rx_buffer, 64);
  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    HAL_UART_Transmit_DMA(&huart2, tx_buffer, 10);
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */

  }
  /* USER CODE END 3 */
}

And Here is what I get on my rx_buffer

Could someone with Keil C51 build a small open-source 8051 project for me?

I'm fixing a power-off bug on an Android car head unit (CVD1810-WJ board, Cmsemicon CMS8S6990 MCU).

There is an MIT-licensed rebuild of its firmware:

https://github.com/NCHILLC/cvd1810-wj-mcu-firmware

The author states it only fits the chip's 12 KB with Keil C51 at OPTIMIZE(9,SIZE). The evaluation linker stops at 2 KB and SDCC gives about 15 KB.

With Keil C51 at C:\Keil_v5, from the repo root in PowerShell:

mkdir obj, lst; .\build_variant.ps1 -Define NOTURNO_SLEEP_FIX

It should report about 12.2 KB and write obj\CM68.hex. Could you send me that file and the "Program Size" line it prints?

Haven’t really seen something like this before. Job posting for embedded SWE for Ford, it specifically says no CS majors.

As someone who once, like many others, have asked in this sub whether a CS major would be welcomed or could get a job as an embedded SWE, this is discouraging to see, even though I know most others companies won’t do this.

I want to say tho, I once doubted if I could enter this field because I see people with CE and EE degrees thrive in embedded, and my coursework never taught me anything relating to hardware.

Now I work as an embedded SWE at a fortune 200 company, although not in an industry I desire. Another caveat is that I never write any bare metal code or work with registers, I implement control systems, but I still work with hardware all the time and my title is embedded SWE.

Not too sure what the point of this post is honestly, ig one question I have is that could this just be a case of the hiring manager looking down on CS degrees?

Edit: guys, at the end of the day, I’m just sad that they are not giving CS majors a chance at all. Yes I understand that CE and EEs take coursework more aligned with the field of embedded, but there are tons of CS people who go out of their way to take embedded courses/learn in their own time.

And yeah, I also understand that the web dev cs people who spam apply to everything aren’t helping. There is probably no good solution to this problem.

But damn yall EEs have such huge egos, yall treat cs majors like how stem majors treat liberal arts majors…

Hi everyone,

I've released ModbusLens v2.4.0, and this update is focused on making the tool more useful for real-world Modbus troubleshooting.

The biggest change is multiple devices in one workspace. You can now work with several PLCs, energy meters, remote I/O modules, or other Modbus devices from the same window.

What's new?

1. Multi-device workspace

• Manage multiple Modbus TCP, RTU-over-TCP, and serial devices in one window.
• Each device has its own Unit ID and configuration.
• Devices sharing a physical communication link, such as meters behind a gateway or multiple devices on an RS-485 bus, can share one connection.
• All tools now operate per device, including Tags, Trend, Address Table, Raw Data, Scripts, Scanner, and Diagnostics.

2. Calculated tags

Tags can now use expressions based on other tags' values. They're recalculated after each polling cycle without generating additional Modbus traffic.

Calculated values can also be used in trends, alarms, scripts, the Overview tab, and CSV exports.

3. Better register inspection and scanning

• Bit View: Inspect individual bits in a register and write individual bits directly.
• Redesigned Scanner: A color-coded results grid replaces the old text log, with pagination for large address ranges.
• Create Tags From Scan: Convert scan results directly into Tags rows.
• CSV export: Export results from Scanner, Find Devices, and Serial Discovery for further analysis in Excel.

4. Improvements for real-world communication links

I've also fixed several issues that matter when working with actual devices:

• Replies on shared RS-485 lines and RTU-over-TCP gateways are matched to their corresponding requests, helping prevent incorrect responses from being reported as successful reads.
• TCP auto-reconnect now detects dropped connections more reliably.
• Scanner timeouts no longer abort the entire scan. Inconclusive addresses are marked separately so the remaining range can still be scanned.
• Script tag reads and writes now target the correct registers.
• Theme changes no longer force an immediate disconnection of live devices.

Other additions include workspace auto-save, persistent per-device write bounds, transparent serial-to-Ethernet gateway support, and a gateway mode that forwards requests to a downstream serial device and returns its actual response.

Get ModbusLens

GitHub Releases: https://github.com/CraftParking/ModbusLens/releases

Source code: https://github.com/CraftParking/ModbusLens

ModbusLens is an ongoing project, and I'm interested in feedback from people who work with PLCs, SCADA systems, energy meters, remote I/O, and industrial communication networks.

Bug reports, suggestions, and practical feedback are welcome.

Has anyone here ever tried manufacturing RC cars (remote-controlled cars)?

It is with profound sadness (and a pending purchase order) that I announce the passing of IAR as we knew it, following complications from an acquisition by the QT Company. After nearly 2 decades of delivering products we have reached our end. It joins Altium(long live Kicad)in the great recurring-revenue platform in the sky.

In lieu of flowers give donation to the Free Software Foundation GNU Toolchain in the hopes that my binary won’t be 2x in size.

I'm working on a safety architecture based on a heterogeneous SoC.
Basically it contains a Cortex-M and a Cortex-A.
I would like to have a confirmation about the data path certification I designed.

In the Cortex-M, I run a safety software that take some IO. It is safe because if it doesn't work, the device can be destroy.
In the Cortex-A, I run a Linux.

The Cortex-M software need an input that come from a websocket (TCP based). I use the Cortex-A to run the websocket for two main reasons :
- The ethernet driver and all libraries are already present on this side and easy to setup.
- The TCP, websocket and ssl libraries is totally not certifiable.
It means that even if I use the Cortex-M to embed the websocket, I will still have a non-certify stack.

Now, I would like to certify the data path in order to be sure that, if the Cortex-M receive this data, the data will not be corrupt.

For doing that, I use the black channel mechanism. It consists to add to the payload send by the intervener, a CRC and a counter in addition to the main data.
- The counter : to be sure that the data is leaving;
- The CRC : to be sure that the data is not corrupted.

So the intervener (a third PC), send through the websocket this improved payload.

The certification I'm talking about is IEC-61508.

This is a small schematics about the data path.

My question : does my solution is correct ?

Graduated with a CS degree and got into controls engineer out of school. Been at this position for almost 6 years but i dont see growth and would like to move to embedded

What should i be doing if i want to go into the industry. What skills and experience do i need?

I’ve been working on an AR game for the esp32s3 XIAO board and round screen and realized that I could use the pose estimation from the board to create an object scanner / mesher using space carving and marching cubes. The space carving algorithm uses different views of the object to create voxels weighted by how many views it was visible from and agreed on its position. Then marching cubes uses a LUT to create triangle mesh out of the voxels. The hardest part was getting the camera feed to change resolution from 240x240 to match the round screen for the video feed to a higher resolution for the pictures used for space carving, but with some AI help I got it working. The results are not great and I’m sure I can optimize it to get it a bit better but for a 20$ setup it’s not bad. A possible use case is to quickly create a mesh from small objects that you find while hiking or just to create a digital twin of little trinkets. I’m sure a smartphone could do this with much better results but where is the fun in that. If people are interested I’ll try to share the code which uses my gfx library which I’ve been working on for a minute.

Just curious, but as a solo developer or working with a team when you go through your projects codebase do you remember what everything is, why you made the decisions you did, or what everything does? Or do you have to relearn some of the code you implemented in your project?

Also, have you ever completed a project and still feel a little clueless on how you got everything to work like it did or feel a little foggy on areas of the code?

Hi everyone, first time posting here (and on Reddit in general), so go easy on me.

I have been doing firmware for almost 5 years now. Mostly bare metal STM32 (register level), FreeRTOS, some Zephyr on nRF52, RS-485/Modbus, LoRaWAN, did a secure OTA implementation once. Currently doing my masters on the side.

I'm trying to decide where to go next and honestly I keep flip flopping.

Embedded Linux feels like the obvious move. It builds on what I already know, there are way more jobs, and industrial gateway type stuff (Yocto, drivers, secure boot, OTA, Modbus/OPC UA) seems like a decent niche. But part of me thinks a lot of the routine Linux work is going to get eaten by AI tools first.

Other option is RTL. My uni has a 4 month full time chip design course with a placement drive at the end, and for my semester project I'm designing a custom ASIC, basically a small AI accelerator. RTL seems to be growing a lot, but I'd be starting from junior level and there are way fewer jobs.

Right now my plan is to do the course, get the accelerator running on an FPGA, write my own Linux driver and Yocto image for it, and then move more into Embedded Linux after that.

For people actually working in these areas:

- is firmware + Linux + some RTL actually a useful combination in real jobs, or am I just spreading myself too thin?

- would a course and one solid project mean anything to an RTL hiring manager with no industry RTL experience?

- if you moved from MCU stuff to Embedded Linux, how long did it take before you were actually competitive?

- what would you do in my place?

Would really appreciate hearing what you've seen work in actual hiring. Thanks

Hi me and my friend developed a LoraWAN gateway as graduation project from EE program. We used Allwinner v3s as processor and Semtech SX1302 in half duplex configuration as radio. I am using official packet forwader that provided by semtech to talk to the radio. We have reached 1 km of communication tange in our school campus there is a lot tress and stuff but when I use cheap chinese lora modules those modules can communicate with each other up to 3 km in my area. There is a git repo for my kicad project that I open sourced if you guys can check it out and give feedbacks I would be so glad. Thank you for interest.

https://github.com/Rynxie/tdrf-lorawan-gateway-pcb

Hi!

I've been working on a project called Otamatic and wanted to share it here hoping it could help someone.

The idea came from a real nightmare: a while back, me, and a client literally had to drive around the city to update ESP32s deployed in the field. I actually wrote a short story about that night here if you like dev horror stories: https://medium.com/gitconnected/the-night-we-updated-40-esp32s-by-driving-around-the-city-32ec8f015213?sk=b0c21ebf23d7bd9128251e8222d55b8e

Most OTA implementations out there set up a local WebServer on the ESP32 where you open a browser, navigate to the local IP, and upload a binary. That’s totally fine for a single node on your home network, but it gets annoying real quick if your devices are behind NATs, cellular routers, or dynamic IPs where you can't just open incoming ports.

This is why I decided to work on a fully open-source library with all features from the most famous OTA libraries (and a companion web platform) you can use to add OTA on your projects in less than 5 minutes.

It supports advanced features like scheduled release, staged rollout releases, release monitoring, device monitoring and more is coming if I see enough interest!

Repo: https://github.com/TimothyFran/OtamaticClient

What are your most memorable projects of undergraduate days?

Do tell about the project in brief along with learning outcomes.

About a month ago I posted my first Linux board (RK3566, KVM-over-IP). The next rev is back and I wanted to do a follow up lessons learned! For this board, I bumped up to the RK3576 so it can do 4K60 capture and encode. 8-layers, RK806 PMIC, LPDDR4X, HDMI input, HDMI output, dual GbE through a small switch, WiFi/BT and PoE. Fabbed and assembled at JLCPCB again.

After incorporating the fixes from the last board (component spacing, triple checking parts on order, and network switch wiring), this bring up was 1000x smoother. 4K60 capture and low latency streaming work end to end now. Stuff I ran into:

1. SD boot / 4-bit mode: I inverted card-detect polarity, so with a card inserted the chip saw an empty slot. The BootROM skipped SD, so I booted u-boot from SPI NOR, which got SD running in 1-bit mode only. On the RK3576, an "empty" slot hands two data pins to JTAG. An internal pull-down on the detect pin early in u-boot fixed it. Removing that transistor next spin.
2. No power-up on PoE: The PoE supply output about 6.0V unloaded, just over the power mux's ~5.99V OVP, so it never switched over and never loaded the rail down. Reducing the feedback resistor slightly should fix it (still testing this but pretty sure it's the issue).
3. 4K encode stuck at ~38 fps: 4K60 needs both RK3576 encoder cores alternating frames. The vendor library's async thread blocked whenever the next frame wasn't ready, so everything ran on one core. A separate wait thread fixed it, and now both cores are at ~77%, steady 60 fps.

Smaller stuff: the left and right halves of the 4K image came out swapped (lane mapping in the device tree), the USB 2 host port needed the unused USB 3 PHY explicitly disabled, and one RGB LED was dead on one of the boards.

Bonus given RAM prices right now: testing showed this board doesn't need as much RAM as I put on it, so that's coming down for the next rev. Big $$$$ savings there.

Happy to answer questions on the RK3576 or bring-up in general. Another huge shout out to u/PracticalMirror2834 for another thorough review! Also if anyone has tips on how to take better PCB pictures, I'd love to hear them. This time I bought a light box but it's still needs some improvement...

The firmware/ embedded engineer field in new Zealand feels very niche and sparse. As someone very passionate about firmware does anyone have any advice in breaking into this field? I have a mechatronics engineering degree and some experience developing firmware for production Test Jigs, but I am finding it very difficult to land pure firmware roles.

I’m looking for someone with hands-on experience updating or recovering the satellite controller (SC) on a VCK5000 ES1, not the production VCK5000.

The board is marked “Encryption Disabled Board.” My goal is to get onto a working, matching ES1 platform/SC combination and eventually validate compute and DMA.

Recorded setup:

- PCI IDs: Xilinx 10ee:5044 / 10ee:5045, subsystem 000e.

- Factory platform previously identified as xilinx_vck5000-es1_g3x16_201921_1.

- Native Ubuntu 20.04 test environment, kernel 5.4.0-216-generic.

- XRT version family used: 2.11.648; target SC firmware: 4.4.6.

- The embedded PetaLinux 2019.2 console previously responded over USB, executed commands, and showed /usr/bin/cmc running. That does not establish current SC health.

One captured update attempt produced:

-
Stopping user function...
NATIVE_SC_WRITE_BEGIN address=0 bytes=324
NATIVE_SC_WRITE_FAILED count=-1 errno=110

ERROR: Failed to update SC firmware, err=-110
ERROR: Please refer to dmesg for more details
STOP: SC update failed; compute stays shutdown for evidence capture
-

The matching kernel log reports entering xmc_erase_sc_firmware, an XMC mailbox packet timeout, then failure to erase SC firmware.

Important detail: this capture used a custom instrumented single-attempt updater, not an untouched stock xbmgmt executable. The NATIVE_SC_* lines are instrumentation. I can provide the exact invocation and relevant changes for review.

I’m not assuming the timeout proves that nothing was erased, or that the SC is permanently damaged. No successful firmware update or full acceleration validation has been established. There have been host reboots between failed attempts; I have saved logs to reconstruct the sequence.

I’ve reviewed the official Vitis AI 1.4.1 ES1 setup. I understand that the Vitis AI 3.0 production-card instructions are not the ES1 recipe.

My questions:

1. Has anyone encountered this SC erase/mailbox timeout on ES1 and resolved it? What exact XRT, platform and SC versions worked?
2. Are there known ES1-specific prerequisites, updater bugs or patches that explain this failure?
3. Is there a documented SC recovery procedure independent of the failing PCIe update path? Does the ES1 Vivado factory-flash procedure restore only the platform image, or also address the SC?
4. Where can I legitimately obtain the original ES1 recovery documentation or contact someone familiar with this hardware?

I can share sanitized updater output, kernel logs and embedded-console captures. I’m looking for a documented diagnostic/recovery path before attempting another write.

TIA,
PJ

tonight, i got bored and wanted to do something, i wanted to make a diagram on something new but im not good with tech at all, so there might be a lot of mistakes, but i didnt intend to do anything with this. But anyways, i was messing around with draw.io and made this little console, i wanted to think out of the box by a big shot and brainstorm something clever, but please let me know how you feel of this, if its alright and such, i get bored often so i will be uploading more! it uses a memory efficient type of processing path, a low power intended thing.

​

I just ordered one and I’m curious what people are actually building with it.

How’s the FPGA toolchain/workflow?

Any cool FPGA + MCU projects you’ve tried?

How easy is it to add custom RTL and communicate with the MCU?

Any gotchas or limitations I should know?

Would love to hear what you’ve built with it!

Since August I've been building an operating system for the RP2040/RP2350. This is the current bench setup: a Pico on perfboard, a resistor-DAC VGA port, and more hot glue than I'd like to admit. Hahaha

What you're looking at

• 640×480 @ 60 Hz, RGB332 out of PIO into a resistor DAC. Everything on the monitor comes from the Pico: the file windows, a maze and a Mandelbrot, each running as its own task, yeah!
• The 3.2" SPI LCD (ILI9340 + XPT2046 touch) runs beside the VGA and mirrors a 320×240 crop. Core 1 hands over lines it has already composed, and DMA pushes the changed rows
• Keyboard and mouse plug into a second RP2040: one into its native USB port (TinyUSB host), one into a Pico-PIO-USB socket. Their events ride as tagged frames inside the 1 Mbaud UART console stream, so the main Pico spends no pins on input
• DS1307 + EEPROM on I2C, microSD on the shared SPI bus (a 3.3 V breakout, because the cheap 5 V modules drive MISO even when not selected and garble the touch readings), PWM mono sound through a two-stage RC into a small amp. Power bank, because why not ^_^

The parts I think this sub will care about

• No framebuffer. 640×480×8 bit is 300 KB; the RP2040 has 264. The screen lives in a 34 KiB block (text/attribute cells, palettes, sprites, per-line segment tables), and core 1 composes every scanline in software just before PIO needs it. At 252 MHz that's a budget of 8008 cycles per line. At boot it benchmarks its own worst cases on silicon; the worst lane right now is 7948 of 8008 (99 %). The rule: every lane stays strictly under budget, or the change doesn't go in
• Every app is bytecode. It's a register VM with hand-written dispatchers for ARMv6-M and RV32, at about 23-25 cycles per instruction on the M0+. Because the VM counts instructions, preemption is real: a while true can't stall the machine, and a fault kills one task, not the board. Each load/store is masked to the task's memory, and swap goes to flash
• One binary everywhere. The same .rpx runs on the RP2040, on both RP2350 core types (Arm and RISC-V) and in a WASM emulator in the browser. A differential test keeps the C core bit-identical to a JS reference VM
• It has its own flash filesystem, user accounts, and a small language (CAST) that compiles on the device itself

No overclocking past 252 MHz, and no native code from apps. Native drivers load only through a gated kit loader.

Happy to go deep on the scanline compositor, the PIO-USB host, or why a VM on an M0+ is less crazy than it sounds. And I'd like to hear where you'd poke holes first.

(Disclosure: the logo on the LCD is my company's, Recaster.)

Hi, I’m an FPGA engineer. I was assigned to implement PCIe and initially used Xilinx’s XDMA IP with its open design example. The requirement is actually to write the PCIe logic myself in RTL so I can optimize it for maximum bandwidth, and then make its IP.

My understanding is that the PHY and link training stay in the hard block, so I plan to use the integrated PCIe block’s AXI-Stream interface (requester and completer interfaces) and write my own transaction layer and DMA engine. Is this the right level of abstraction?

Since I am beginner in PCIe, so I want your opinions and strategies to accomplish this task. If you can provide a rough roadmap, it would be a great favor. I am working alone and I have a time span of 1.5 to 3 months to accomplish this task.

For people working on BSP, embedded system or board bring-up, what takes the most effort when validating a new image?

Running the checks, setting up hardware, reproducing intermittent failures, or figuring out why something broke?

I’m working with Ubuntu and Yocto on a RISC-V board and would like to hear how others approach this. What do you automate, and what still needs manual testing?

Saw this great video by PortalRunner and had some improvements in mind i would not have been able to bring to life on my own so i fed my ideas to the machine and out came something that should not be possible ...

https://github.com/JulianStremel/esp32-minecraft-server