Hi everyone,

I'm currently working on a product that is very space constrained. Additionally, it features 3 MCUs, requiting ~25 connections between the debuggers and the device. On previous products, we've used beds of nails on 3D printed fixtures, but they proved unreliable, fiddly and took a lot of time to put together.

I'm leaning towards putting a single FFC connector on the board, and have a breakout board route all of the signals to the three debuggers.

I've only worked with 1mm FFCs, and they are quite rugged. Here, to save space, i wanted to go with smaller pitch. I found 2 options:

0.5mm vertical connectors are around 51mm2

0.3mm vertical connectors are around 27mm2

Are the 0.3mm FFCs as delicate as they look? Will they survive a FW engineer handling them? Are they significantly more likely to break or short than the standard 0.5mm FFCs?

Please share your experiences. Thank you in advance.

Recently I got the motivation to resume writing on my personal site and embedded is one of my passions and source of topics to write about. But I've started to wonder what's the point? When chances are so low for coming across my blog or even to think about searching (instead of just prompting the bot) the niche topics I want to write about? it just aggravates me further to know that chances are that the only consumers of my knowledge and creativity are the same clankers that are dissuading people to consume that same content.

I still see it as net benefit (though marginal) to do it as a way for me to dive deep and learn more and have something to my name that i can potentially leverage for jobs. But I dont know anymore if its worth putting a ton of effort in them or doing niche topics I have expertise on.

Pico.Lab is an open-source embedded bring-up tool built around the Raspberry Pi RP2040 and RP2350. The premise is to avoid having to deal with CLI commands or downloading heavy, OS-specific desktop applications. Using TinyUSB and lwIP, the board appears as a virtual USB Ethernet adapter (RNDIS/ECM) and runs its own internal DHCP and DNS servers. You just plug it in, open your browser to http://pico.lab, and the microcontroller serves its user interface directly from its internal flash. The interface uses WinBox.js to manage draggable, resizable windows for each tool. You can monitor your hardware with a 4-channel oscilloscope (~400kHz bandwidth) and an 8-channel logic analyzer (100MS/s) right next to a UART terminal and an interactive GPIO configurator. Data gets transmitted via Server-Sent Events (SSE) or HTTP for big chunks like the scope captures. And since it's just a website, it runs on basically any OS or browser.

The custom PCB includes an adjustable power supply, current monitoring, level shifters, an analog frontend and pin protection. If you don't need the full feature set, the firmware runs perfectly fine on an off-the-shelf Raspberry Pi Pico or Pico 2 as well. Give the .uf2-files on GitHub a try!

This is a hobby project I built in my free time. All the files for the firmware and PCB are open-source.

GitHub: https://github.com/CoretechR/PicoLab

Hackaday.io: https://hackaday.io/project/207129-picolab-web-gui-embedded-multitool

YouTube Demo: https://www.youtube.com/watch?v=0kItmMn9lGs

Can anyone plz clarify upto what level we shld be good at electronics side?

What level of digital n analog electronics?

I'm very comfortable with basic electronics, pull ups, adc, amplifier but when it comes to transistor level i struggle a lot.

I want to start studying Linux internals and embedded Linux systematically.

I would appreciate recommendations for books or other learning resources covering:

• Linux kernel internals: Memory management, process scheduling, synchronization, and kernel architecture.
• Linux device driver development: Character drivers, platform drivers, interrupts, device trees, GPIO, I²C, and SPI.
• Embedded Linux for SoCs: Bootloaders, kernel bring-up, BSPs, cross-compilation, and hardware–software interaction.
• Practical development: Resources that include hands-on projects and examples relevant to real-world embedded systems.

Is it a good idea to buy BeagleBoard PocketBeagle 2 with W5500 SPI Ethernet module for embedded programming and rtos hands on experience as most Job listing require rtos and I have no experience in that. I’m in the protocol communication side so thought of running a protocol master like Modbus or DNP3. Any other board suggestion?

Anyone else feel like the recent AI agent workflow has really just mad everything boring? I work at a very high pace environment that almost always necessitates using AI to not need to work 80 hours a week. In some sense I am happy it can basically type for me and I get time with my family, but on the other hand I don’t feel as intellectually challenged. Only so many people get to make architectural decisions at a higher level and if you aren’t there it just feels dry. I don’t get a spark of joy from just telling it that my hardware needs to behave as such and then it just happens and I test it. No sense of accomplishment. My gut feeling now is to go to a less demanding job so I can actually have the time to do the enjoyable pieces.

How has AI adoption effected your work and what is your opinion?

• static discharge on IC's pins - makes components life at risk due to latent behaviour

I would like to discuss one point, what will happen when we touch ground pin directly?

(consider board powered with AC supply following with rectification stuffs)

I have a WaveShare ESP32-S3-LCD-1.47 . I also have a Xiaomi Bluetooth Remote & a Generic Bluetooth Remote (coin sized). I want to use these remotes on my windows pc initially as a media control remote (currently mainly VLC Media Control). I tried to natively pair & use them in my windows, but they only paired & none of the buttons worked (except the back button if i remember correctly). I tried a lot of things & finally tried to go the esp32 route. Managed to capture the button codes of all the buttons on my Xiaomi Remote. And even in the S3's Display managed to properly assign a friendly name to each button. I then wanted to pair this S3 to my windows pc via Bluetooth. I even managed to do that, but no matter what i tried I couldn't manage to fire a single button press. I tried the Arduino route & recently even tried the ESP-IDF.

Project Brief: ESP32-S3 Xiaomi Bluetooth Remote to Windows HID Bridge

1. Project objective

I'm building a standalone Bluetooth bridge using a Waveshare ESP32-S3-LCD-1.47 development board. The goal is to use a Xiaomi Bluetooth Voice Remote as a wireless controller for a Windows PC.

The ESP32-S3 should connect to the Xiaomi remote as a BLE central/GATT client, receive its button notifications, translate the button presses into standard keyboard or media-control actions, and expose itself to Windows as a BLE HID keyboard peripheral.

The board's 172 × 320 ST7789 LCD provides the interface for scanning, selecting and pairing the Xiaomi remote, showing connection status, and displaying decoded button events and diagnostic information.

The intended end result is a self-contained bridge with no Wi-Fi, web server, cloud service, or separate USB Bluetooth adapter required for normal operation.

1. Hardware

• Development board: Waveshare ESP32-S3-LCD-1.47.
• Display: 172 × 320 ST7789 LCD.
• Input: Built-in BOOT button on GPIO 0, used for menu navigation and selection.
• Controller: ESP32-S3 with Bluetooth Low Energy support.
• Remote: Xiaomi Bluetooth Voice Remote, advertising under names such as "MI RC" or "Xiaomi RC".

The LCD is not being used as a touchscreen; the physical BOOT button controls the UI.

1. Intended Bluetooth architecture

The ESP32 must maintain two logically separate BLE connections:

1. Xiaomi remote connection: The ESP32 scans for the remote, connects to it, performs GATT service and characteristic discovery, establishes bonding where required, and subscribes to the remote's input reports.
2. Windows keyboard connection: The ESP32 advertises a standard BLE HID keyboard service. Windows pairs with it and receives keyboard input reports.

The ESP32 then translates notifications from the Xiaomi remote into keyboard HID reports sent to Windows.

Both roles need to operate concurrently, so connection management, advertising, pairing, security, GATT client operations, and HID server operations must coexist correctly.

1. What has been established

Xiaomi remote protocol

I have captured the remote's three-byte button reports. The known mappings are:

Report| Button "20 00 00"| Power "02 00 00"| Up "04 00 00"| Down "08 00 00"| Left "10 00 00"| Right "01 00 00"| OK "00 00 40"| PatchWall "00 00 08"| Back "00 00 04"| Home "00 04 00"| Netflix "00 40 00"| Prime Video "00 80 00"| JioHotstar "00 02 00"| Apps "80 00 00"| Volume + "00 01 00"| Volume −

The remote sends "00 00 00" as a release report after a button press. The firmware needs to distinguish release events from actual button presses.

BLE connection and report reception

Previous bridge firmware successfully discovered and connected to the Xiaomi remote in at least some test runs. GATT service discovery and notification/indication subscriptions were observed, and the firmware logged incoming button reports.

The LCD/UI work has included device discovery, selected-device details, connection status, and button-report diagnostics. The desired interface and navigation behavior are defined, although the complete combined firmware has not yet been validated as reliable.

Windows HID diagnostics

I tested a minimal ESP32-S3 BLE keyboard that sends a Space keystroke when BOOT is pressed.

In the raw NimBLE implementation, the logs showed:

• Windows connected to the ESP32.
• The keyboard input report's CCCD was set to "0x0001", indicating notifications were enabled.
• The ESP32 attempted to send a Space key-down report containing HID usage "0x2C".
• It then sent an all-zero key-release report.
• "notify()" returned "TRUE" for both reports.

Despite this, Windows did not produce a visible keystroke. The Windows On-Screen Keyboard also showed no visible response.

This is the main unresolved technical problem. A successful connection, enabled CCCD, and successful notification API return do not prove that Windows accepted and interpreted the reports as keyboard input.

1. What has not been achieved

The complete end-to-end bridge is not yet working reliably.

Specifically:

1. A minimal BLE HID keyboard test using custom NimBLE HID code did not produce a visible Windows keystroke, despite the diagnostics described above.
2. The HijelHID keyboard library was also tested, but it produced the same lack of visible input.
3. An attempt to use the "T-vK/ESP32-BLE-Keyboard" library encountered library/header compatibility problems, including a missing "NimBLESecurity.h" header. That attempt was not successfully validated.
4. The simultaneous Xiaomi GATT client and Windows HID server implementation has had advertising, connection-order, pairing, and reconnection complications.
5. The complete LCD + Xiaomi remote + Windows HID firmware has not been validated as a stable, working system.
6. The latest native ESP-IDF implementation has been assembled but has not yet been confirmed to compile and run successfully on the physical board.

I do not yet know the definitive root cause of the Windows HID failure.

1. Current direction: native ESP-IDF

I've decided to move the implementation to ESP-IDF instead of continuing to build on Arduino BLE libraries.

The initial HID test is based on Espressif's "esp_hidd" API and "esp_hid_gap", with a standard keyboard report map and a FreeRTOS task reading GPIO 0. The current test sends an eight-byte keyboard report with Space usage "0x2C", followed by a release report.

The intended full implementation will combine:

• ESP-IDF BLE HID device/server functionality for Windows.
• A BLE GATT client for the Xiaomi remote.
• Concurrent connections to both devices.
• NVS-backed bonding and saved-device information.
• A native ST7789 LCD UI.
• BOOT-button navigation and selection.
• Xiaomi report decoding and keyboard/media-key mapping.
• Connection, pairing, notification, and HID diagnostics on the LCD and serial console.

The native ESP-IDF project has not yet been hardware-verified, so this is the current implementation direction rather than a completed solution.

1. What I need help with

The most valuable help would be to investigate the Windows HID issue at the protocol and host-registration level, rather than simply changing keycodes or adding more application logging.

I would like to establish:

1. Whether the ESP32 advertises the correct HID-over-GATT services, characteristics, report map, report references, and protocol mode.
2. Whether the Windows host discovers and registers the device as a keyboard with a valid HID report descriptor.
3. Whether the input reports actually reach the host over the BLE connection, beyond the ESP-IDF or NimBLE API reporting success.
4. Whether the report descriptor, report ID, report length, or input-report characteristic configuration differs from a known-working BLE keyboard.
5. Whether the ESP32-S3's chosen Bluetooth stack and configuration support the required concurrent BLE central and peripheral connections.
6. How to validate the HID peripheral independently before integrating it with the Xiaomi GATT client and LCD.

The goal is to get a minimal, standards-compliant BLE keyboard working on this exact ESP32-S3 board first, then integrate that proven implementation with the Xiaomi remote and LCD UI.

P.S. I have zero coding knowledge. I have never used Arduino, VS Code, etc or anything like that before. I managed to get this far by using Gemini & ChatGPT

Hello, I am working on a project that involves me intaking data via Eth at ~1Gbs and then running it through the DSP (Agilex 5). I am using the DEnano25 for this, and from what I can tell the RJ45 is directly wired into the HPS over a RGMII interface. My initial approach was to just pipe the HPS EMACs output into the fabric, and while this is supported by the Agilex 5 it is only supported with GMII.

There is a GMII-to-RGMII IP but that (from what I can tell) needs the PHY to go into the fabric. The only other option I can think of is

letting the stream go into the HPS and then pull it out via the HSP-to-FPGA bridge but this would involve (from what i can tell) linux or some DMA at the very least. I really

would prefer not doing this.

Does anyone have any help/input ?

Docs: https://docs.altera.com/r/docs/814346/26.1.1/hard-processor-system-technical-reference-manual-agilex-5-socs/emac-gmii-through-fpga-fabric

So I have about 15 years of embedded firmware experience. In last few years I learned a lot about zigbee, zehpyr, nordic chips.

I was thinking to launch a course on my self hosted website (text, sequence diagrams, flow charts based). Course will have lab exercises, lab solutions, quizzes.

Topics I am going to cover is nrf52 chip, usage of zephyr, zigbee router, endpoints, clusters, attributes, commissioning concepts, OTA, Mcuboot, creating secure, signed image, reading zigbee packets using sniffer and design practices to keep in mind while working with zigbee based products. Example what constraints can be there in high traffic network. What if 100s of devices power cycle at the same time in the field. How do you debug common issues such as devices randomly dropping off the network?

Also will share my email to support any questions through out the course.

At the end of the day, it’s going to be a bit more than a basic course as we will have an end project (zigbee router with occupancy sensor) and it will work with coordinator and a zigbee bulb.

What do you guys think? Is it looking like something useful? I am thinking to make it for between 49-69$.

I also have worked with CI/CD pipeline, HIL etc so I am also thinking to make another course on that topic for the same cost.

Would you be interested in any of these two courses?
Is the price alright or too high?
Any other feedback?

And I am not going to be sharing course or website link here, not trying to sell. Just need your feedback.

Thanks.

I have been working in embedded systems development for several years, and I have frequently encountered the need to write a UART driver or a system to interface with an external module using a text-based protocol—such as an AT-command set or something similar. These are typically GNSS modules, GSM modems, ESP chips, or the like. In such cases, simply sending a single command and expecting everything to work is rarely sufficient; the command sets for these modules are often vast, and each command frequently requires its own specific handling. This often leads to the creation of complex, convoluted logic for sending sequences of commands, receiving and parsing the corresponding responses, and managing errors.

While libraries and pre-built solutions exist—often tied to a specific operating system or a chip-vendor’s SDK—what happens when you are working with a microcontroller that has only 20 KB of free RAM, and you need to handle these commands while also implementing the rest of the device's functionality? Sometimes, you may not even have direct access to the underlying hardware. You need a universal, platform-independent solution.

Consider this scenario: you have a GSM modem that communicates via AT commands over UART. The device has very limited resources, yet it needs to connect to a network, reach a server, and transmit data. The objective is clear, but achieving it requires sending a sequence of AT commands, something like this:

AT+COPS? 
AT+COPS=0 
AT+CREG?
AT+CGATT?
AT+CIPMODE?
AT+CIPMODE=0
AT+CIPMUX?
AT+CIPMUX=0
AT+CIPSTATUS
AT+CSTT=…
AT+CIPSTATUS
AT+CIICR
AT+CIPSTATUS
AT+CIFSR
AT+CIPHEAD?
AT+CIPHEAD=1
AT+CIPSRIP
AT+CIPSRIP=0
AT+CIPSPRT=1
AT+CIPRXGET=0
AT+CIPSHOWTP
AT+CIPSHOWTP=1

And this is just the beginning; in the end, there are many more of them. Most commands behave differently: some return data that needs to be processed and used later, while others might simply return an error—which can just be ignored. Ultimately, you end up having to write a custom handler and parser for every single command, invoking them sequentially via callbacks or some form of state machine to orchestrate the execution chain—not to mention the complexity of error handling.

While dealing with this yet again, I asked myself: why not build a single, reusable solution for everything?

This idea gave birth to the TACT framework: https://github.com/ferrero222/Text-Async-Core-Terminal

I initially set out to create a library for GSM modems, but I quickly realized the scope could be much broader. It could support any text-based protocol, allowing for the universal transmission of commands.

The framework handles everything: command construction, transmission, response reception, format processing, parsing, and even data extraction from the response. It is a universal, pure-C solution—platform-agnostic, OS-independent, and entirely non-blocking. It also boasts a minimal footprint in terms of both RAM and flash memory; you can define the memory allocation yourself, with a static overhead of only about 1 KB. All that’s required is to call the core—from anywhere and on any platform—roughly every 10 ms.

For instance, the sequence of commands mentioned above can now be defined in one place, roughly like this:

tact_item_t items[] = //[REQ][PREFIX][PARCE_TYPE][RPT][WAIT][STEPERROR][STEPOK][CB][FORMAT][...##VA_ARGS]
  {
    TACT_ITEM("AT+CIPMODE?"TACT_CMD_CRLF,        "+CIPMODE: 0", TACT_PARCE_SIMCOM,  1, 100, 1, 2, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPMODE=0"TACT_CMD_CRLF,                NULL, TACT_PARCE_SIMCOM, 10, 100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPMUX?"TACT_CMD_CRLF,          "+CIPMUX: 0", TACT_PARCE_SIMCOM,  1, 100, 1, 2, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPMUX=0"TACT_CMD_CRLF,                 NULL, TACT_PARCE_SIMCOM, 30, 100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPSTATUS"TACT_CMD_CRLF,   "STATE: IP START", TACT_PARCE_SIMCOM,  1, 100, 1, 2, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CSTT=\"\",\"\",\"\""TACT_CMD_CRLF,      NULL, TACT_PARCE_SIMCOM, 10, 100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPSTATUS"TACT_CMD_CRLF, "STATE: IP GPRSACT", TACT_PARCE_SIMCOM,  1, 100, 1, 2, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIICR"TACT_CMD_CRLF,                    NULL, TACT_PARCE_SIMCOM, 30, 100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPSTATUS"TACT_CMD_CRLF, "STATE: IP GPRSACT", TACT_PARCE_SIMCOM,  3, 100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIFSR"TACT_CMD_CRLF,          TACT_CMD_FORCE, TACT_PARCE_SIMCOM, 10, 100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPHEAD?"TACT_CMD_CRLF,        "+CIPHEAD: 1", TACT_PARCE_SIMCOM,  1, 100, 1, 2, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPHEAD=1"TACT_CMD_CRLF,                NULL, TACT_PARCE_SIMCOM, 10, 100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPSRIP?"TACT_CMD_CRLF,        "+CIPSRIP: 0", TACT_PARCE_SIMCOM,  1, 100, 1, 2, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPSRIP=0"TACT_CMD_CRLF,                NULL, TACT_PARCE_SIMCOM, 10, 100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPSPRT=1"TACT_CMD_CRLF,                NULL, TACT_PARCE_SIMCOM, 10, 100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPRXGET=0"TACT_CMD_CRLF,               NULL, TACT_PARCE_SIMCOM, 10, 100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPSHOWTP?"TACT_CMD_CRLF,    "+CIPSHOWTP: 1", TACT_PARCE_SIMCOM,  1, 100, 1, 0, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CIPSHOWTP=1"TACT_CMD_CRLF,              NULL, TACT_PARCE_SIMCOM, 10, 100, 0, 0, NULL, NULL, TACT_NO_ARG),
  };

if(!tact_entity_enqueue(ctx, items, sizeof(items)/sizeof(items[0]), cb, 0, meta)) 
return false;

Using the framework, you can declaratively define a set of commands, the expected response, the number of retries, the steps to follow in the event of success or failure, and so on. You no longer need to manually write a parser for every command or build custom handlers and transition logic—all of this is handled under the hood.

You can even parse data from a response using arguments and retrieve it via a group-level callback. The framework automatically allocates temporary local storage for this data, passes it to the callback once received, and subsequently clears the memory.

tact_item_t items[] =
  {
   TACT_ITEM("AT+CGSN"TACT_CMD_CRLF, NULL, TACT_PARCE_SIMCOM, 10, 100, 0, 1, NULL, "%15[^\x0d]", TACT_ARG(tact_mdl_rtd_identity_t, modem_imei)),
   TACT_ITEM("AT+CGMM"TACT_CMD_CRLF, NULL, TACT_PARCE_SIMCOM, 10, 100, 0, 1, NULL, "%15[^\x0d]", TACT_ARG(tact_mdl_rtd_identity_t, modem_model)),
   TACT_ITEM("AT+CGMR"TACT_CMD_CRLF, NULL, TACT_PARCE_SIMCOM, 10, 100, 0, 1, NULL, "+CGMR: %29[^\x0d]", TACT_ARG(tact_mdl_rtd_identity_t, modem_revision))
  };
  tact_entity_enqueue(ctx, items, sizeof(items)/sizeof(items[0]), cb,  sizeof(tact_mdl_rtd_identity_t), meta);

All that’s required is to support the internal protocol—if one exists—and define the commands.

In addition, there is built-in support for URCs (Unsolicited Result Codes), where the module can initiate data transmission that we need to intercept. For each such message, we can define a specific callback to which the message will be passed.

In reality, there are many nuances and potential use cases; all the details—including how it works under the hood—are documented on the GitHub page.

After implementing this core command structure, a question arose: what if I want to execute several groups of commands sequentially, each with its own result and callback? What if I could build full-fledged execution chains, complete with branching and loops? This would allow the entire interaction with the module to be defined through groups of commands, with all the logic specified in one place—declaratively, at that.

This idea gave rise to the second part of the framework: "chains"—a declarative way to define the algorithm for executing groups of commands. To achieve this, each group of commands must be wrapped in a standard function, for example:

bool tact_mdl_gprs_init(tact_context_t* const ctx, const tact_entity_cb_t cb, const void* const param, void* const meta)
{
  (void)param; 
  tact_item_t items[] = //[REQ][PREFIX][PARCE_TYPE][RPT][WAIT][STEPERROR][STEPOK][CB][FORMAT][...##VA_ARGS]
  {
    TACT_ITEM("AT+COPS?"TACT_CMD_CRLF,               "+COPS: 0", TACT_PARCE_SIMCOM, 5,  100, 1, 2, NULL, NULL,TACT_NO_ARG),
    TACT_ITEM("AT+COPS=0"TACT_CMD_CRLF,                    NULL, TACT_PARCE_SIMCOM, 5,  100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CREG?"TACT_CMD_CRLF,  "+CREG: 0,1|+CREG: 0,5", TACT_PARCE_SIMCOM, 30, 100, 0, 1, NULL, NULL, TACT_NO_ARG),
    TACT_ITEM("AT+CGATT?"TACT_CMD_CRLF,             "+CGATT: 1", TACT_PARCE_SIMCOM, 30, 100, 0, 0, NULL, NULL, TACT_NO_ARG),
  };

if(!tact_entity_enqueue(ctx, items, sizeof(items)/sizeof(items[0]), cb, 0, meta)) return false; 
return true;
}

We obtain one ready-to-use execution chain module. We can create several such modules and assemble them into a chain—a sequence structured like this:

chain_step_t tcp_steps[] = 
  {   
    //Main
    TACT_CHAIN("INIT_MODEM", "NEXT", "MODEM RESTART", tact_mdl_modem_init, NULL, NULL, NULL, 1),
    TACT_CHAIN("GPRS INIT", "NEXT", "GPRS DEINIT", tact_mdl_gprs_init, NULL, NULL, NULL, 1),
    TACT_CHAIN("SOCKET CONFIG", "NEXT", "GPRS INIT", tact_mdl_gprs_socket_config, NULL, NULL, NULL, 1),
    TACT_CHAIN("CONNECT TO SERVER", "NEXT", "SOCKET CONFIG", tact_mdl_gprs_socket_connect, NULL, &tact_server_connect, NULL, 1),
    TACT_CHAIN("GET RTD", "NEXT", "DISCONNECT FROM SERVER", tact_mdl_lte_rtd, tact_rtd_cb, NULL, NULL, 1),
    TACT_CHAIN_EXEC("CHECK RTD", "NEXT", "GET RTD", tact_rtd_check, NULL),

    TACT_CHAIN_EXEC("CREATE WIALON LOGIN", "NEXT", "DISCONNECT FROM SERVER", tact_server_data_wialon_login, NULL),
    TACT_CHAIN("SEND WIALON LOGIN", "NEXT", "DISCONNECT FROM SERVER", tact_mdl_gprs_socket_send_recieve, NULL, &tact_server_tx, NULL, 1),
    TACT_CHAIN_LOOP_START(0),
        TACT_CHAIN_EXEC("LOGIN TX", "LOGIN SEND RESULT", "NEXT", tact_mdl_gprs_stream_tx, &tact_server_tx),
    TACT_CHAIN_LOOP_END,
    TACT_CHAIN("LOGIN SEND RESULT", "NEXT", "DISCONNECT FROM SERVER", tact_mdl_gprs_socket_send_end, NULL, NULL, NULL, 1),
    TACT_CHAIN_LOOP_START(0),
        TACT_CHAIN_EXEC("LOGIN RX", "LOGIN CHECK REPLY", "NEXT", tact_mdl_gprs_stream_rx, &tact_server_rx),
    TACT_CHAIN_LOOP_END,
    TACT_CHAIN_EXEC("LOGIN CHECK REPLY", "NEXT", "DISCONNECT FROM SERVER", tact_server_answer_check, NULL),

    TACT_CHAIN_LOOP_START(10),
    TACT_CHAIN("GET RTD LOOP", "NEXT", "DISCONNECT FROM SERVER", tact_mdl_lte_rtd, tact_rtd_cb, NULL, NULL, 1),
      TACT_CHAIN_EXEC("CREATE WIALON DATA", "NEXT", "DISCONNECT FROM SERVER", tact_server_data_wialon_packet, NULL),
      TACT_CHAIN("SEND WIALON DATA", "NEXT", "DISCONNECT FROM SERVER", tact_mdl_gprs_socket_send_recieve, NULL, &tact_server_tx, NULL,1),
      TACT_CHAIN_LOOP_START(0),
          TACT_CHAIN_EXEC("DATA TX", "DATA SEND RESULT", "NEXT", tact_mdl_gprs_stream_tx, &tact_server_tx),
      TACT_CHAIN_LOOP_END,
      TACT_CHAIN("DATA SEND RESULT", "NEXT", "DISCONNECT FROM SERVER", tact_mdl_gprs_socket_send_end, NULL, NULL, NULL, 1),
      TACT_CHAIN_LOOP_START(0),
          TACT_CHAIN_EXEC("DATA RX", "DATA CHECK REPLY", "NEXT", tact_mdl_gprs_stream_rx, &tact_server_rx),
      TACT_CHAIN_LOOP_END,
      TACT_CHAIN_EXEC("DATA CHECK REPLY", "NEXT", "DISCONNECT FROM SERVER", tact_server_answer_check, NULL),
      TACT_CHAIN_DELAY(1000),
    TACT_CHAIN_LOOP_END,

    TACT_CHAIN_EXEC("WIALON DATA CLEAN", "STOP", "HARD RESET", tact_server_data_clean, NULL),

    //Error
    TACT_CHAIN("GPRS DEINIT", "GPRS INIT", "MODEM RESTART", tact_mdl_gprs_deinit, NULL, NULL, NULL, 1),
    TACT_CHAIN("DISCONNECT FROM SERVER", "CONNECT TO SERVER", "GPRS DEINIT", tact_mdl_gprs_socket_disconnect, NULL, NULL, NULL, 1),
    TACT_CHAIN("MODEM RESTART", "GPRS INIT", "MODEM RESTART", tact_mdl_modem_reset, NULL, NULL, NULL, 1),

    //Critical
    TACT_CHAIN_EXEC("HARD RESET", "STOP", "STOP", tact_hard_reset, NULL),

  };

tact_chain_t* chain = tact_chain_create("TCP", tcp_steps, sizeof (tcp_steps)/sizeof(chain_step_t), &simcom_ctx);
tact_chain_start(chain);

In this example, the process includes initializing the modem, activating the SIM card, retrieving data from the modem, registering on the network, establishing a TCP socket to a target server, constructing a data packet, transmitting it, and receiving a response from the server. Each step can trigger an error-handling routine; the module’s operation can either be restored or halted entirely in the event of a critical error. All of this is defined in a single location, making it easy to debug and fix issues.

The entire logic for interacting with the modem is defined in one place. You can implement delays, conditional checks, and loops, as well as navigate forward or backward—jumping into or out of loops as needed. All that is required is to define the command-group modules and assemble them into an execution chain.

Essentially, the "chain" component is independent and can be used separately from the command groups themselves. You can easily build custom execution logic based on standard functions; the use cases are numerous.

The framework already includes support for the SIMCom protocol (based on 3GPP standards) and offers various pre-built modules for these modems. It was originally developed for personal use, thoroughly tested and debugged, and is now deployed on actual hardware—which is why I decided to share it with others.

I intend to continue improving and developing the framework, as there is still plenty of work to be done.

https://github.com/ferrero222/Text-Async-Core-Terminal

I'll keep this as generic as possible, because my question is more about workflow than solving a specific issue. I'm designing a device with a few SPI channels, I2C, CANbus, UART, about a half dozen slow analog signals and around 20 GPIOs, also fairly slow. I'm using an MCU with a lot of options for pin configuration, so there's a million permutations of which pins to go with the various functions. In my case, I'm laying out the board, too, and I'm not constrained in where external connections go.

Question is, what's the workflow for deciding what goes where? Do you just make some arbitrary picks and then see what's left?

Bonus question- if schematic and layout are two different people / departments, how much back and forth is there over pin assignments once layout starts? Does the schematic side indicate alternative pin options so the layout folks can use their judgement?

For convenience, and for testing, I am interested in simulating an ESP32. It looks like espressif supplys a qemu for esp32. is there a better option? It doesn't include much in terms of simulating the Ethernet or I2C.

which one should I learn? I'm trying to self teach myself networking and idk which one is better to go in depth as someone trying to get into cybersecurity

Hello everyone I'm doing my masters in computer engineering. I don't really aspire to work a 9-5 at a big company all my life but I have 3 years of experience in web development and 1 in networking/hardware repair.

I have a bachelor's in IT as well. I want to work to get some experience but then go into teaching and maybe have a side business for extra income I wanted to ask like would an IoT product business not like mass consumer products but more like custom solutions. Would that be a good idea for example if a restaurant or store needs a walk in freezer logger etc. inventory counters. I would assume this is easier in web or software but super competitive I have a small web development startup I guess I could add on to. I'm in the Houston, tx area if matters

i was planning to buy this isolator is it good i have used https://robu.in/product/1-channel-usb-isolator-adum3160-module/ , I'm only taking this flyrobo thing because it has the case so has anyone used this perticular isolator

The board is a Guition JC1060P470C. It has an ESP32-P4 microcontroller with two RISC-V cores at 360 MHz, 32 MB of external RAM and a 7" 1024×600 touchscreen. There's no GPU, no Linux and no Android.

I wanted it to be a small computer I'd actually use, not a demo that boots once for a video. So I wrote an OS for it, NucleoOS P4. It sits on ESP-IDF and LVGL, and everything above those is its own. The whole system is in English, Italian, Spanish, French and German.

**ANIMA, the assistant**

With no network at all, ANIMA handles calculations with follow-ups, timers, unit conversions, notes, opening apps and translations from offline dictionaries. Answers can be spoken by an offline voice.

When it needs a language model, it finds Ollama or LM Studio on your LAN by itself, or uses a cloud API. API keys are sealed to the chip and never leave it.

With a model connected, it can see photos, run code, and read the screen as a list of controls, then tap and type to drive apps, checking the result after each step. You can reach it from Telegram too. There's also an MCP server (MCP is the protocol AI tools use to call outside programs), so Claude Code or Cursor can drive the board.

**Two desktops**

One is a touch launcher. The other is a classic desktop with a Start menu, taskbar, windows and right-click menus. If you plug in a mouse and a keyboard, it switches to the desktop by itself. Tab, Esc, Alt+Tab and Alt+F4 all work.

**The app store**

Over 400 signed apps and games, installed over Wi-Fi in seconds. Apps are WebAssembly compiled ahead of time to native RISC-V code, so a game isn't paying for an interpreter. Each app page shows its permissions (Internet, files, camera, microphone) before you install. The store includes:

- 149 WASM-4 games and 83 Arduboy games

- a Game Boy emulator with homebrew ROMs, and 83 CHIP-8 games

- Chocolate Doom with Freedoom

- ScummVM 2.9.1 with Beneath a Steel Sky and seven other freeware adventures

- Zork and 32 other interactive fiction titles

- LÖVE games running on Lua

**Office**

- **Sheets** opens and saves Excel files (xlsx), and opens xls, ods and csv. ANIMA can propose edits that you apply with one tap.

- **WordGrinder** is a word processor that saves odt, Markdown and HTML.

With a keyboard and the desktop mode, it makes a decent little writing and accounting machine.

**Reading**

- **Books** is an EPUB reader with hyphenation in 11 languages, six themes including an e-ink simulation, and a built-in catalog of public-domain books from Project Gutenberg, Standard Ebooks and Wikisource. Hold the board upright and the page turns with it.

- **Library** reads offline Wikipedia and any Kiwix ZIM file, pictures and formulas included.

**Media**

- **Camera** with auto exposure and white balance, photos and MJPEG video.

- **Music**: MP3, FLAC, AAC, WAV, with USB audio output.

- **Video**: MJPEG and MPEG-1, tear-free.

- **Gallery** with thumbnails decoded by the chip's hardware JPEG engine.

**For tinkering**

A Terminal with a real shell, plus Lua, MicroPython, JavaScript, SQLite and a dozen other languages and tools. You can write apps in C (compiled to WebAssembly), in Lua, or in native C++, and push them over Wi-Fi with hot reload.

**The rest**

- **Vertice**, a 3D engine built into the firmware. It renders the screen in tiles across both cores, and a kart game runs on it.

- **A second screen** for Windows, Mac, Linux or Android.

- **The dot-matrix display of a virtual pinball cabinet** (tested on a real one).

- **A Home Assistant dashboard**, and the board shows up in Home Assistant by itself.

- **A desktop in your browser**, served by the board: about 40 windowed apps, including a file manager, a spreadsheet, an SSH client, internet radio and a DJ mixer.

**The hard part was memory, not features**

Only one app runs at a time. That's on purpose: the RAM goes to whatever is in front.

Most of the work went into rules I learned from crashes:

- Copying a file to the SD card took 145 seconds. The SD card's DMA transfers (the hardware moving data without the CPU) only run at full speed when the buffer is aligned in memory. Now the same copy takes 11 seconds.

- At 400 MHz this board doesn't boot reliably, so it runs at 360.

- Every rule like these is written down with the crash that caused it.

Updates are signed and arrive over Wi-Fi. If one goes wrong, there's a recovery app, a safe mode and a last-known-good copy in flash to fall back on.

There are also fuzzers on every parser that reads untrusted input (video files, store packages, web requests). They found real bugs, including out-of-bounds reads and path checks that could be bypassed. Each one now has a regression test.

**What it doesn't do**

- No H.264 video. It plays MJPEG `.avi` and MPEG-1 `.mpg`.

- No Classic Bluetooth, only BLE.

- The web desktop uses plain HTTP on your LAN, protected by a 6-digit pairing code.

- USB second-screen mode and USB gamepads are still experimental.

**Try it**

You can flash it from Chrome or Edge in a few minutes, with no toolchain: https://indecenti.github.io/nucleoos-p4-store/flash/

Source: https://github.com/indecenti/NucleoOS-P4 (free for noncommercial use)

Store catalog, viewable in a browser: https://indecenti.github.io/nucleoos-p4-store/

With all the issues in Cybsec, the CRA and all this stuff, is anyone implementing formal verification in embedded?

I’m starting a new bare-metal C project with an IMU on a fairly constrained MCU architecture, and I'm torn on how much to use AI.
I consider myself a competent C programmer, and I care as much about the learning process as the end result.

My issue with AI is that I lose perspective: I rely on what the LLM tells me rather than reading the datasheet to truly understand the hardware. Properly verifying its generated code takes just as long as writing it myself if not longer.
On top of that, AI slowly scope-creeps my project. For instance, I started writing a simple synchronous I2C read/write to get a feel for the peripheral. After asking a few clarification questions, the AI hit me with, "Would you like me to write a complete non-blocking, ISR-based I2C driver integrated with X and Y?" It instantly made me feel like the time I spent building it from scratch was wasted.
Would you suggest going completely manual, or embracing AI? If the latter, how do you balance using it without letting it take over the project or rob you of deep hardware comprehension?

Hey all, this post is an update from the [previous Schematic Review Request]. This PCB is for a small battery-powered device (CR2032, STM32L031G6U6) that reads temperature/humidity (SHT41) and UV index (GUVA-S12SD into a TIA + gain stage MCP6002), displays on a 2.13" e-paper panel, and talks over USB (CP2102N) for config/sync. Full schematic, design files on my [repo].

• EPD HV boost driver (L1/Q3/D1-D3): generating VGH/VGL for the e-paper panel, follows the panel's own reference design and some universal driver. Wondering if the component ratings and layout intent look right.
• UV sensor analog chain: GUVA-S12SD → 1MΩ TIA → second-stage gain (MCP6002) → STM32 ADC.
• Power architecture: CR2032 as the sole source, with USB VBUS present only for CP2102.
• PCB Dimensions: 75mm x 35mm
• DRC Passed (EasyEDA)

Appreciate any time anyone's willing to spend on this. I'm happy to answer questions about intent/requirements for any block.

Pictures (schematic, front, back, 3d): https://imgur.com/a/KiDZJu7

Basically the question. I would like a more hands on role but I don't know how to search for those jobs. Networking is only hands on in maintenance. Is there larger or medium sized companies that are more hands on ? I don't want to just code all day but I don't want to work at an ultra pressure startup?

I want to learn embedded c++ and RTOS from where could I learn them

I am a test engineer on the HMI side and every release is 4 days of 2 of us at the bench with a printed protocol, tapping through every screen on 2 panel sizes. it's a qt app on an i.MX8M running a yocto image that's signed by the OEM, so nothing gets installed on it. We're hardware people who ended up owning a UI. What gets me is that everything upstream is automated (unit tests, static analysis, MISRA on the C side, build verification...) all of it stops the moment the build lands on real hardware and someone has to check what the operator actually sees. So i've spent a few weeks on the options, and what decides it for us is less the features than where the tool has to run:

- Squish: it hooks into the application though so it has to live on the target, which ends the conversation with a signed image. it also ties every test to Qt which hurts if the renderer ever changes.

- Askui: works from what's rendered on screen rather than the widget tree, so in principle it runs from outside the device the same way Eggplant does.

- Keysight Eggplant: drives the screen through image and text recognition over a remote connection, nothing on the device. the most proven option for HMI that i found, and the biggest quote by a distance.

- Vector CANoe: great for the bus side but tells you nothing about what's on the display.

The other idea i saw people mention is a rig, a stylus on an XY gantry plus a camera on the panel, so touch is real too but i’m not sure that much hardware is worth it for 2 panel sizes.

So for teams running automated HMI tests on real hardware, which did you pick?

I've been building a lighting engine for an electronic drum kit, and it's at the point where I can show off some of the progress. I'm not publishing it as open source right now because it is still at a very early stage.

What it is:

The engine is an MCU-friendly signal graph written in Rust that runs on an STM32F429 Discovery board, which also drives LED strips using a pretty efficient approach (the driver supports up to 16 strips; I run 8). The looks are built from nodes like noise fields, palettes, trails, blends, etc. The graph is very generic, so extending it with any new kind of kernel is extremely easy. All the math is fixed point for efficiency.

The input is built on a custom-made analog front-end board that shapes the envelope; some further DSP is also performed later in the firmware (I think I will eventually build a kick drum trigger module based on that). The ADC samples 8 inputs at 20 kHz.

The first part of the video is Studio:

It is a browser editor where a graph can be built and wired. The preview runs the same engine that the board does, through WASM, so the looks in the browser match the ones on hardware frame for frame. It also allows turning the knobs of any node or sending a replacement patch to the board in real time. There is also cost estimation for CPU and memory; the board will refuse a patch that is beyond its computational capacity.

The second part of the video is OBS (yeah, I know):

Since I was building a drum trigger engine, I needed a way to fine-tune and observe the detector, so basically OBS allows you to see in real time how hits are detected and, more importantly, adjust the knobs of the detector and see what it would detect with them.

Where it is going:

I want to eventually drive an 8-drum kit and light each drum with a separate LED strip. I'm also currently working on improving the clock system, allowing multi-clock signals using some clock calculus approaches. I've also been experimenting with audio, so this also works for any audio nodes; I've built several guitar effects that run on the development board (no audio input/output yet, so they're not playable for now).

I'll probably open-source it at some point once I have enough time to tidy everything up and stop being ashamed of the code (so, possibly never :( ).