https://community.element14.com/technologies/embedded/Embedded systems programming, design and products; also microcontrollers, programmable logic, memory, DSP and controllers. en-USTelligent Community 12https://community.element14.com/technologies/embedded/m/managed-videos/151820Tue, 22 Sep 2026 17:03:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3680a495-9643-479d-95ab-e65bfcc04ee9shabazHere's the movie: https://amzn.to/2O2EU3M Opening scene (news scene) from I Am Legend. Please note that I may be paid from links in this content.flu vaccinefluvaccineI Am Legend (Film)coronavirus vaccinecoronaviruscorona virushttps://community.element14.com/technologies/embedded/b/blog/posts/connecting-ai-to-the-physical-world-with-mcp-and-a-pi-pico-wTue, 22 Sep 2026 05:39:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d8e38409-8320-48c7-93ae-28348010f8ccshabazTable of Contents Introduction MCP Explained Working with MCP Using a Simple MCP Server Library Building and Running the Code Connecting the Agent Summary Introduction AI agents can be extremely useful, but it would often be helpful if they could directly interact with the physical world. For instance, one might develop a control system, and then get the AI to fine-tune it automatically, by adjusting outputs and taking measurements. You could connect an oscilloscope to the AI, and let it take measurements, modify controls, and inspect the ‘scope screenshots. There’s a fairly crude but useful thing called Master Control Program Model Context Protocol (MCP) which many AI agents can work with, if the user provides functionality in a server that listens and responds to MCP. There are ready-made MCP servers for a load of useful scenarios. I decided to implement one in a microcontroller (Pi Pico W). MCP Explained MCP is ridiculously simple in theory. The AI agent (which acts as the client) can be configured with the server details (such as IP address), and then on startup, the agent will send a server/discover message to learn what categories of things the server supports. The server responds back with “capabilities” which are essentially “tools” and “resources”. Next, the client asks for a list of tools and the server provides that in a response. An example tool could be as simple as a relay. The client then asks for a list of resources - a sensor could be a resource. Later, when the agent wishes to activate a tool (a relay in this example) the agent (client) will send a “tools/call” message with the required relay state, and the server responds accordingly. If the agent was curious to know the resource value (such as temperature) then it will send a “resources/read” message for the server to respond to. That’s it pretty much. The secret to why this works as well as it can, is that the responses to the tools and resources list requests contain verbose descriptions about what the tools and resources are about. It gives the agent useful information it can stick in its context, and include that when making decisions. There are a few more MCP messages not mentioned here (there's a ping-pong diagram of real network traffic later), but the important ones are covered. As far as the MCP server creator is concerned, they need to be creative in describing their sensors and actuators in a description field which will get populated in the list responses, and then attach their GPIO or whatever to their server callbacks for when the appropriate messages come across from the AI. That is it, and let’s believe everything is perfectly fine; none of this is crude and half-baked. I’m sure there are some business opportunities in this area; surely someone must be working on some sort of gateway, to enforce some rules so that real-world equipment isn’t destroyed when the machines take over. In the meantime, that’s all on the MCP server implementor. Working with MCP The best way to work with MCP is to find an MCP library for the programming language you’re comfortable with, and then the majority of the hard work is done for you, it’s just a matter of integration. In my case, I wanted to use a small microcontroller with WiFi capability, and there isn’t a suitable library for that. With some experimentation, it was found that plain HTTP can work. The MCP client (agent) sends a HTTP POST request to the MCP server (microcontroller), and the server returns a response containing JSON content, and closes the connection. The agent simply opens another connection for the next request. This is very convenient on a small embedded system because the server doesn't need to maintain a persistent connection. I have only tested this implementation with Antigravity, so other MCP clients may behave differently.I am sure someone will eventually come up with a more robust MCP server library for microcontrollers, but for now at least something works. Using a Simple MCP Server Library I placed code in a pico_w_mcp repository , which can be easily used with a Pi Pico W, which has 2.4 GHz WiFi built-in. The code is in just one source file mcp_server.cpp, and it has a header file of course. Here’s how to use the server in custom projects. First, create an object of class MCPServer (the name you pass it here might need to be the name you later register with the agent too): MCPServer mcp(“pico_w_mcp”); Then, define some callbacks for all the tools and resources (i.e. actuators and sensors). A tool callback (setMotorPWM in this example below) receives arguments supplied by the agent and performs an action. A resource callback such as readHumidity simply supplies the requested data: static bool setMotorPWM(MCPArgs &args, char *out, size_t out_size, void *) { float pwm = args.getFloat("pwm"); set_motor_pwm(pwm); snprintf(out, out_size, "Motor PWM set to %.1f%%", pwm); return true; } static bool readHumidity(char *out, size_t out_size, void *) { // assume value is in float humidity snprintf(out, out_size, "%.1f percent", humidity); return true; } Then, register all the tool callbacks: MCPServer::MCPTool motor = mcp.tool( "set_motor_pwm", "Set the motor PWM duty cycle from 0.0 to 100.0 percent.", setMotorPWM); motor.param ( "pwm", "PWM duty cycle in percent, from 0.0 to 100.0." ); And register all the resource callbacks: mcp.resource("sensor://humidity", "humidity", "Current relative humidity in percent.", readHumidity ); Then, start up the MCP server! mcp.begin(8000); Building and Running the Code The repository has a complete demo project, and to use it, the Pi Pico C/C++ SDK needs to be installed. Follow the build instructions in the SDK documentation. In my case, I use a PowerShell script (it is in the GitHub repo) although if anyone wants to use that, it will need to be edited since it has hard-coded paths to suit my set-up. For the demo project, the WLAN SSID and password either need to be typed into the main.cpp code, or provided as parameters during the build process. It’s just a demo, you wouldn’t do this for a real project of course. Once the code is built, the firmware is transferred to the Pi Pico W in the usual way (hold down the BOOTSEL button on the Pi Pico W and insert the USB cable, then release the button, then drag the firmware file onto the drive letter that appears on the PC, and then the firmware will upload and immediately begin running). A serial port will appear on the PC, which can provide debug information if required. You can check your network tools to see what IP address the Pi Pico W got assigned from the router. Connecting the Agent Consult the documentation for the system you’re using. With Antigravity CLI, all that needs to be done is to type the following in a Linux shell or Windows PowerShell (change the IP address to match the Pi Pico, and notice that the pico_w_mcp name that was used in the source code is used; I’m not sure if that is essential, but it’s what I did): agy mcp add --type http pico_w_mcp http://192.168.1.159:8000/mcp Next, run Antigravity, and try typing in something that needs interaction with the MCP server. If you’re curious, run WireShark at the same time. The diagram here shows the interaction I saw on my PC (click to enlarge). Here's what the serial console revealed from the Pi Pico point of view: Summary A simple HTTP server can provide enough MCP functionality to allow an embedded device to interact directly with an AI agent. A simple demo was illustrated using a Pi Pico and a cut-down minimal MCP server implementation mainly just to get the idea of how to use the protocol, and if you’re using a more powerful device, then it would certainly be better to use an established MCP server library. I can’t guarantee the simple library described here will work for you, but if you ever give it a try I’d be interested to hear how it goes. Thanks for reading.Model Context ProtocolrpiintermediatemcpGeminiantigravityraspberry_pi_projectspi picohttps://community.element14.com/technologies/embedded/b/blog/posts/mspm0-project-with-vs-code-cmake-and-gcc---part-7-middleware-example-stepper-motor-controlSat, 19 Sep 2026 09:12:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e9e2ca2c-8582-462e-b956-52369a253fe9Jan CumpsIn this blog series, I build a Texas Instruments MSPM0 example with VS Code as IDE, and CMake as build infrastructure. In the next series of posts, I try to create a stepper motor project. It will be based on TI's stepper motor middleware. TI has examples for several stepper motor drivers that I don't have. Those examples have firmware for the MSPM0, and a GUI to configure and test motors. They are a good starting point that I can adapt for the stepper drivers that I own. The first attempt is to get that existing stepper middleware project going: drv8889-q1evm-gui-firmware . I will try to complete these 3 activities: run the example from TI's GUI Composer. compile MSPM0 firmware on CCS port the project to VS Code, where I'll do the development GUI Composer example TI's Gallery has the example that I want to start from: MSPM0L-DRV8889Q1-EVM-GUI . When you click the tile, it will open GUI Composer. From there you can run the GUI. First, plug in the the MSPM0L1306 LaunchPad. Then run the GUI. It will connect to the LaunchPad, and load the firmware. You can then configure the driver, and make the motor spin or step. Because I don't have the right hardware for this example, I tested it by probing the step pin output with an oscilloscope. It works. Compile example firmware with CCS I used Code Composer Studio to download and inspect TI's firmware project. The project is available in Resource Explorer. You can import it from there. I first compiled and loaded the project. That worked perfectly. Then I inspected sources and project settings, to understand how the project is set up: most peripheral config is done via SysConfig it uses the middleware HAL and stepper driver drv8889-q1. They are copied from the MSPM0 SDK. the main function runs a GUI style loop. custom GUI code reacts on messages coming from the GUI Composer application, over UART using JTAG and direct variable binding between GUI and firmware. driverlib and IQMath libraries are used Port to VS Code I started from MSPM0 project with VS Code, CMake and GCC - part 6: empty "template" project , and reused these files from the CCS project: main GUI code sysconfig I didn't copy over the module files. I adapted the CMake script, to find and include them in their SDK location during build. In the original sysconfig file, project generation was disabled. TI does that in several of their examples, because they use other tools to prepare example projects. I re-enabled that. Then I changed the setup, so that sysconfig generates the instructions to include the correct two libraries. All worked fine. The VS Code project is attached. In a next step, I'll try to make a testbed that sends commands to the UART, just like the GUI does. Then test if I can make it generate the STEP and DIR signals. The ideal starting point for adaption to a different stepper motor IC. VS Code project: community.element14.com/.../mspm0_5F00_stepper_5F00_20260919.zip (check this post for the expected VS Code workspace settings: MSPM0 project with VS Code, CMake and GCC - part 6: empty "template" project ) part of the EasyL1105 series. all postsMSPM0easyL1105MSPM0L1306https://community.element14.com/technologies/embedded/b/blog/posts/mspm0-interrupt-messaging-systemSun, 13 Sep 2026 12:48:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d274f3ce-7746-489b-9e5e-83ecd6825df7Jan CumpsYou can handle MSPM0 interrupts via the traditional service request handler. But it also has a messaging system. With message handlers, you can route notifications from one peripheral to another. In this example: react on a button click and toggle a LED. With the EasyL1105 kit. This is TI's event_input_triggers_output example. SysConfig adapted to EasyL1105. What does the project do? When you press or release the user button, an trigger is generated. It's set up to send an event message. The led pin is set up to toggle when it receives an event result is that the led chan ges state when you push or release the user button. A manual blinky All of this is configuration. There is no logic related to this on the C source. image: excerpt from TI MSPM0 EVENT module introduction Resources used: LED 1 PA27 USER BUTTON PA16 Event channel 1 Resources not used: TI's project uses the clock tree. I've switched it off and use the default clock. image source: EasyL1105 GitHub project Button configuration LED configuration check Event You don't have to set anything here. It's a result of configuring the button and LED GPIOs. main The code just sets the controller in a low power mode that allows execution of interrupts. All our logic is managed by the setup we just did. #include "ti_msp_dl_config.h" int main(void) { SYSCFG_DL_init(); /* Calling WFI after calling DL_SYSCTL_enableSleepOnExit will result in * only ISR code to be executed. This is done to showcase the device's * low power consumption when sleeping. */ DL_SYSCTL_enableSleepOnExit(); while (1) { __WFI(); } } I designed this in VS Code, starting from the template project MSPM0 project with VS Code, CMake and GCC - part 6: empty "template" project . That VS Code project is attached. If you use Code Composer Studio, you can create the project from the New Project wizard. Both choices will work the same. Thank you for reading. VS Code project for EasyL1105: community.element14.com/.../EasyL1105_5F00_event_5F00_input_5F00_triggers_5F00_output.zip part of the EasyL1105 series. all postsMSPM0L1105MSPM0easyL1105VS Codevscodehttps://community.element14.com/technologies/embedded/b/blog/posts/mspm0-project-with-vs-code-cmake-and-gcc---part-6-empty-template-projectSat, 12 Sep 2026 14:32:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:5f7b062e-d4a7-4507-920e-7335f22f1c09Jan CumpsIn this blog series, I build a Texas Instruments MSPM0 example with VS Code as IDE, and CMake as build infrastructure. In the previous posts, I created an end to end flow, from install over build to debug, tested on LaunchPad and EasyL1105 kit. In post 6, I try to make an easy start point. An empty project, and the steps to adapt it for your project. The previous posts tackled a few aspects at a time. And following them from start to end gives you a working project. This one is single shot: minimal steps, starting from a preconfigured template project. This blog assumes that you have (see previous posts for detailed instructions): GCC cross compiler for arm (arm-none-eabi), V14.2 or higher. CMake 3.29 or higher Ninja v1.13.1 or higher. TI SysConfig mspm0 SDK 2.11 or higher Microsoft CMake Tookit for VS Code extension TI Embedded Development For VS Code TI Cortex-Debug: Device Support Pack - Texas Instruments MSPM0 (can be installed form TI Embedded Development) TI Embedded Debug for VS Code (can be installed form TI Embedded Development) If you have a lower version of some components, you can try if it works. You may have to make some changes in that case. It also assumes that you have these entries in your workspace settings (see previous posts for detailed instructions): , "settings": { "cmake.cmakePath": "C:/Users/jancu/.pico-sdk/cmake/v4.2.1/bin/cmake.exe", "cmake.generator": "Ninja", "cmake.environment": { "CMAKE_PROGRAM_PATH": "C:/Users/jancu/.pico-sdk/ninja/v1.13.2/ninja.exe", "SYSCONFIG_CLI": "C:/ti/sysconfig_1.28.1/sysconfig_cli.bat", "SDK_ROOT": "C:/ti/mspm0_sdk_2_11_00_07" }, "cmake.enableTraceLogging": false, "cmake.loggingLevel": "info", "ti-embedded-debug.armToolchainPath": "c:/Users/jancu/Documents/toolchains/arm-gnu-toolchain-15.2.rel1-mingw-w64-i686-arm-none-eabi/bin", "cortex-debug.armToolchainPath": "c:/Users/jancu/Documents/toolchains/arm-gnu-toolchain-15.2.rel1-mingw-w64-i686-arm-none-eabi/bin" } If you happen to use the Raspberry Pico VS Code extension, you will already have GCC, CMake and Ninja. They are all installed by that extension. Check for /.pico-sdk on your computer. SysConfig can be downloaded from TI . The MSPM0 SDK can be cloned from GitHub . Or download it from TI . You install the VS Code extensions in the IDE, like any other extension. You will have to adapt to your installation(s). To get at the JSON file, select Settings -> Workspace -> Open Settings (JSON) Those are the prereqs. Now we're ready for action. Let's call our project mspm0_e14 . 1: download project and add it to your workspace A zipped VS Code project is attached at the end of this post. Download and unzip it to a place of your choice. Rename the resulting folder to your project name: mspm0_e14. rename mspm0_empty.cpp to mspm0_e14.cpp rename mspm0_empty.syscfg to mspm0_e14.syscfg adapt .vscode/settings.json to your installation the SysConfig file is configured for a MSPM0L1306 Launchpad. Change that to your device via the SysConfig GUI. In VS Code, select File -> Add Folder to Workspace, and select the mspm0_e14 If VS Code asks for the toolchain, select your cross compiler. If you don't do it now, you still have a chance to select (and change) in the next step. 2: Open the project in CMake Toolkit, configure, build Select the CMake Toolkit, and select the folder you just added to the workspace. You can also change the toolchain if needed. Configure the project, by clicking on the button that appears when you hover over Configure. Then build, by clicking on the button that appears when you hover over Build. The project will generate 2 firmware binaries. One for loading by a debugger, the other a .hex for shabaz' bootloader. 3: Debug This step requires that you have a debugger, either on your LaunchPad, or a standalone XSD110 Select the VS Code Run and Debug button. There will be an entry for TI Embedded Debug. The debugger will stop at the first executable line of code in main() 4: make your own design When step 1 - 3 work, you have a good baseline to start building your own design. Use SysConfig to select and configure your peripherals (GPIO, I2C, UART, ...). If you add files to your project, take care to add them to the CMakeLists.txt. Typically in this section: # C files set(SOURCES If you create header files in subfolders, add these subfolders in this section: # Directories searched for header files include_directories( If you add libraries via the SysConfig GUI, the CMake script will find them. If you want to add other libraries, adapt these two sections: target_link_directories(${CMAKE_PROJECT_NAME} PRIVATE ) # Libraries and linker command files target_link_libraries( ${CMAKE_PROJECT_NAME} PRIVATE ) If you want a C main file, rename the .cpp file to .c, and change this entry in the CMake script: # C files set(SOURCES ${CMAKE_SOURCE_DIR}/${CMAKE_PROJECT_NAME}. c Good luck! attachment: the VS Code project community.element14.com/.../mspm0_5F00_empty_5F00_20260912_5F00_01.zip post 5: MSPM0 project with VS Code, CMake and GCC - part 5: Open .syscfg file in SysConfig GUI example that uses the template: MSPM0 interrupt messaging system part of the EasyL1105 series. all postsMSPM0L1105gccMSPM0easyL1105VS CodecmakeMSPM0L1306vscode