PC applications that interact with MCUs are used by developers for a number of reasons, such as data visualization, monitoring during testing campaigns, and command and control via a GUI. In this article, we’ll explore mapping an MCU’s peripherals to your personal computer to simplify development of PC applications built for embedded systems.
If your goal is to poke and prod firmware things like GPIO or SPI/I2C/UART type protocols from a PC application layer, it seems to me that you could achieve that more easily by using an FTDI chip.
Would at least have the advantage of consolidating your code base to just one application layer repo, instead of having to worry about any MCU compatibility.
Many MCUs offer a wide range of peripherals, including complex protocols like the CAN bus or analog components like ADC, DAC, and operational amplifiers, in addition to the more basic GPIO, SPI, I2C, and UART functionalities. FTDI and similar chips are excellent for certain tasks, but they can’t match the versatility and functionality of MCUs when it comes to handling these advanced features.
Here are examples illustrating the usage of CAN bus, DAC (Digital-to-Analog Converter), ADC (Analog-to-Digital Converter), and PWM (Pulse-Width Modulation) functionalities coupled with the instrumented SDK:
https://github.com/remotemcu/remcu_examples/blob/master/stm32f4_discovery/jupyter-notebook/stm32f4_discovery.ipynb
https://github.com/remotemcu/remcu_examples/tree/master/stm32f4_discovery/CAN_BUS
When it comes to hardware testing, generating test signals from a PC application proves advantageous is in hardware testing. When working with a board equipped with a microcontroller unit (MCU), the PC application can directly generate test signals without relying on firmware modifications. This approach streamlines the testing process, allowing for quick and efficient signal generation for various testing scenarios.
Yeah that’s reasonable - I haven’t found a USB CAN interface that I love.
I rarely have to do any testing with as heavy or real time a lift as you describe but this is a neat trick in case I ever get there. 
Many MCUs offer a wide range of peripherals, including complex protocols like the CAN bus or analog components like ADC, DAC, and operational amplifiers, in addition to the more basic GPIO, SPI, I2C, and UART functionalities. FTDI and similar chips are excellent for certain tasks, but they can’t match the versatility and functionality of MCUs when it comes to handling these advanced features.
Here are examples illustrating the usage of CAN bus, DAC, ADC, and PWM functionalities coupled with the instrumented SDK:
https://github.com/remotemcu/remcu_examples/blob/master/stm32f4_discovery/jupyter-notebook/stm32f4_discovery.ipynb
https://github.com/remotemcu/remcu_examples/tree/master/stm32f4_discovery/CAN_BUS
When it comes to hardware testing, generating test signals from a PC application proves advantageous is in hardware testing. When working with a board equipped with a microcontroller, the PC application can directly generate test signals without relying on firmware modifications. This approach streamlines the testing process, allowing for quick and efficient signal generation for various testing scenarios.
I noticed that the article did not mention how to handle interrupts generated by MCU peripherals. I think interrupts are not supported in current cases, is that right?