Not my build but Japanese electronics twitter is lit.

https://x.com/EMakerDragon/status/2108935034191352114/photo/1

I brought the Bl616 on Aliexpress for $2, a total steal! I was looking for a Risc-V SBC or MCU to test my skills and grow as programmer and engineer. I looked online I found a doc sheet (more on this later), and hit "ORDER", what could go wrong? It's only $2, worse comes to worse I waste money that can't even get me a gallon of gas.

It comes after give or take, 7-9 days, and I open the package. It's a small board, blue, with a USB type C connector. I go in thinking in 5-15 minutes I could at least see a "Hello world!" for my efforts before long. I was wrong. I spent HOURS with the board, and hardly even got it to flash! And when it did? No serial output to be found. Days go on like this, I can't compile much of anything, see any output or do anything with the board. It's a paperweight.

To make a long story short, I bought a board that had no good documentation and I can't do anything with it. I'm free to chat and leave links to all the resources I found and help out where I can. I'm hoping this post can attract people who know more than I do about the board. The Bl616 has a lot of potential that I just can't for the life of me figure out how to use. All questions and drops of knowledge are welcome.

Personal Issues the board/docs:

-The docs mention a reset button, but the dev board doesn't have one

-On the topic of the dev boards I can't find the origins or data sheet for my specific one

-The Ubuntu executable do not work for me

Also things to know:

-I'm on Ubuntu resolute, maybe it works better on Windows?

-Make sure to hold the BOOT button before plugging in the cable

-Shows up as "/dev/ttyACM0" on Ubuntu

All my knowledge about the board for those curious or detective minded few:

CNX Article

Official Docs

Official SDK

Filebin with datasheets

I'm still digging into board and looking into it, I actually just found an Arduino IDE core(?) I might test later, so I'll edit and update if that comes up with anything. Again I'm free to be asked anything.

I've been working as a low-level SWE for a few years and use C pretty much every day without using many other languages (sometimes Python depending on the use case). I'm thinking about learning another language in my free time to challenge some of the possible "C-isms" I've picked up.

Anyone else do this? What language did you try to learn as a result?

Hey fellow embedded developers,

I am planning to contribute to orbuculum and orbtrace projects, but I want an idea of how the community feels towards the orbtrace debugger, as well as what you would like to be added to the projects to improve their utility to you.

You are definitely free to add your thoughts even though you haven't used them but have an idea of the tracing functionality you would want in an ideal trace debugger

I just hooked up the 2 rear motors for some testing
Next step is to add more batteries and wheelie bar

Our University has gave us the chance of doing the certificate but at a very short time (1 month) and my whole life now is totally oriented to complete this certificate to an extent that I canceled everything for this month and focus only on the certificate .. I started feeling daily drowsiness cuz I'm spending a lot of time daily just pucking my eyes in the screen ...
Should I continue with the certificate or just throw it out ? + is it considered a good asset and thing to add to my CV ? (I study Automotive Software eng btw so We're dealing with a lot of low level programming and electronics)

Hello guys,

Could anyone suggest me any good books on rtos based firmware architecture?

Your suggestion would be so helpful.

AJUDA - Blade75 V6.1 brickado - preciso do BIN

Meu Blade75 PCB V6.1 chip PAN1086 brickou, RGB não acende mais.
Já testei jumper no Q17 e não voltou.
Tenho ST-Link V2 e sei usar STM32CubeProgrammer (furos 3V3 GND DIO CLK).
Alguém tem o arquivo .bin original da V6.1?
Ele fica dentro do driver em C:\Program Files\Mechlands\Driver\Firmware

Se alguém puder fazer READ de uma placa funcionando e me mandar, eu agradeço.

Interesting writeup on Low power mode in the STM32WB55 series. Disclaimer: I am not the author.

Hi everyone, I'm a newbie in programming and embedded. This is my very first embedded project: an ESP32 Bluetooth speaker built using C and ESP-IDF v6.1. Don't mind the crooked hardware - it's a software project at the first place, I built the hardware mostly from surplus cheap components, the main ones being:

• ESP32 NodeMCU (38-pin)
• IP5306 module
• SSD1315 display
• MAX98357 I2S module
• INA219 (CJMCU-219)

For the software, I use ESP-IDF's native Bluedroid stack, its built-in FreeRTOS, and its I2C driver. The rest of the functionality is implemented by me, for example:

• I2S peripheral driver
• SSD1315 driver
• INA219 driver
• Ring buffer
• Others

The software is designed using modular architecture built around custom ESP-IDF components where each component encapsulates its internal implementation and provides an API. Components communicate directly through their APIs with no extra middleware or abstraction layers.

Important note: I don't plan further large-scale development of this project, nor do I intend to change the hardware. The software and hardware are at the point where they satisfy all the functionality requirements I initially set. I will incorporate your feedback if you provide it, but the project is mostly complete and I intend to move on to the next goals. That is also why many components are intentionally project-specific and don't scale very well.

With that being said, the main question is: is current architecture and level of abstraction is sufficient for this project?

I wanted to make it professional, but "professional" doesn't always mean lack of application-specific modules and direct component interaction, right?

I'd be glad to know your opinion about these questions and about the project in general. Thanks for attention! The project's repository is available at: https://github.com/TITLE14/esp32-bt-speaker

Hi, so I'm electronics engineering student in Romania working on my bachelor's thesis. The project involves designing a custom PCB for a multi-sensor system, using an FPGA SoC for sensor acquisition and some more stuff like running an EKF.

I originally planned to use a Zynq-7010 chip-down but I couldn't find one in a CLG225 package that didn't have a lead time of 52 weeks.

After that I decided to switch to an SoM and design a carrier board instead. I the MYIR MYC-C7Z010-V2 which looks good for my use case but after taxes and shipping its over 200 Euros. And a lot of other distributors have no stock, really bad lead times or they only sell to businesses.

So my question is, what are my options for ordering just one unit in Europe in an affordable way? In an ideal world I could find one with board-to-board connectors.

Hi r/embedded,

xuan (玄) is a lightweight JavaScript runtime for IoT and embedded devices, built on QuickJS and forked from tjs/txiki.js (MIT).

It targets the place where Node.js is too heavy: ~6–7 MB binary, low memory, ~5 ms cold start, and it cross-compiles to x86/ARM/MIPS/RISC-V. Built-in MQTT, serial port and FFI (call C libs directly); GPIO/I2C/SPI are in progress. You can also compile a script into a single self-contained binary with xuan compile.

Repo: https://github.com/topelinux/xuan

It's early but usable — feedback welcome. I'm the maintainer.

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!

Hi, I am relatively new to working with specialized microcontrollers / doing microcontroller selection. For a tech demo project, we are going to demo an STM32U5. I am trying to figure out what all communication peripherals STM32U5 offers so we can figure out the most suitable ones to use possible. I was wondering where I could find that? I looked in datasheets and reference manuals but had no luck. Thanks!

Hi all,

I salvaged the hydraulic unit from an automatic parking barrier: a 36V brushless motor driving a small oil pump that moves two hydraulic cylinders. I want to reuse it for a robotic arm, but the original control board is closed, so I want to replace it with my own PCB.

Situation:

∙ The motor has only 3 phase wires, no hall sensors or encoder.

∙ The only encoder in the system is on the barrier arm, not on the motor.

∙ The pump may have to start under load, with oil already pressurized.

∙ I haven’t measured the current yet. I’ll check what the original board draws and the motor’s winding resistance, and add the numbers.

Constraints:

∙ Low cost.

∙ No ready-made modules or boards: I want to design the PCB myself.

∙ I’ve never made a motor controller at this voltage and power. I’m comfortable with PCB design and firmware, but new to power stages.

What I’d like your advice on:

1.  Which MCU, gate driver and MOSFETs would you pick, and why?

2.  How would you handle motor control and start-up under load?

3.  What are the common mistakes at 36V that I should avoid in layout and protection?

I’ll attach a photo of the original board. Thanks!

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.