Video

The question "Can I use XYZ board for this course?" is by far the most frequently asked in this course. The answer is NO. To follow along and benefit the most, you need to use one of the supported boards. This strong hardware dependence is precisely the very nature of embedded systems. Embedded software runs on a specific CPU and controls a specific set of peripherals (input/output pins, timers, communication, etc.) Please just watch a few lessons of this course to get a feel of what's all about. --MMS

@@StateMachineCOM no problem, I will buy one anyway. Do you need the red one or white or both, sorry I was confused. Also, I get this sometimes, when speak say 'coding language' we use certain terminologies which we personally take for granted. However when talking to a total noob, its best to try to not use those terms, and simplify it a little. Like buy the red one, plug it it, then follow..... Sorry, its just I want to continue the course and get a cert, just the terms are overwhelming in the beginning. Love your content though and will stick with it till the end.

Indeed, the traditional RTOS solution for a shared resource like the I2C bus would be to protect it with a mutex. Unfortunately, this sweeps a lot of problems under the rug. Among others, the behavior of all contending threads (BatteryMonitor, Actuators, BatteryCharger) is no longer "real-time" in the sense that it is impossible to analyze (e.g., with RMS/RMA method). I2C is not particularly fast, so the mutex might be blocking for a very long time. The non-blocking event-driven approach forces you to confront such implicit coupling directly. One option would be to create a dedicated I2C_Broker AO, which would encapsulate the I2C bus so that all other AOs would post events to the I2C_Broker. The I2C_Broker then can resolve any potential conflicts around the shared resource but must be careful to process the incoming events quickly so that its event queue and event pools don't overflow. Here, the "Deferred Event pattern" is quite useful (please google for it). Another option would be to create only one AO that would encapsulate the I2C bus and contain other functionality (BatteryMonitor, Actuators, BatteryCharger) as the "Orthogonal Component pattern" (again, please google for it). With this design, you acknowledge that an AO is really a real-time priority level. Since all the components are only as "real-time" as the I2C bus allows, they all should run at the same priority as assigning different priorities doesn't help in "real-time".

Please visit the companion web page to this video course at www.state-machine.com/video-course . Among others, you can find there links to very inexpensive USB logic analyzers and free software. --MMS

The best practice is to avoid casting, so use something like &r1.super or &me->super. However, sometimes generic code (e.g., library code) must deal with deeper class hierarchies, where it's unknown whether you need &x1.super or perhaps &x1.super.super. In such a generic code, an explicit upcast is sometimes unavoidable. But in any case, no misalignment should happen as discussed at 7:15. Finally, you mention MI (Multiple Inheritance), which is an entirely different discussion. The simple method presented here obviously works only for Single Inheritance (SI) and does NOT work for MI. And since you ask for best practices, I recommend staying the hell out of MI and don't open that can of worms at all. --MMS

@@StateMachineCOM Thanks for the great recommandations !

LR stands for "Link Register". At 6:15 you can see that the BL instruction saves the PC (Program Counter) into LR so that the function can return back to the place it was called from. SP stands for "Stack Pointer". It is explained at 7:45. You can also watch the next couple of lessons that explain the call stack and the SP in more detail. --MMS

@@StateMachineCOM Thanks

You need to download the Tiva/Stellaris Extension for KEIL Vision "MDK_Stellaris_ICDI_AddOn.exe" and then you need to install it (run the exe file). The download is available from the companion web page to this course at: www.state-machine.com/video-course

I'm really glad to hear that you appreciate the course. This whole video channel does not use "monetization" to avoid wasting the viewer's time. The CZcams algorithm might be actually punishing such videos by limiting their exposure because they don't bring advertising revenue. Therefore, if you *really* want to help this channel and keep such content, please consider spreading the word about this course in the comments to other CZcams videos, in various embedded forums (e.g., www.reddit.com/r/embedded/ ), and by word of mouth. Thank youi! --MMS

The unique approach of this course is to step down to the machine level frequently and *show* you exactly what happens inside your embedded microcontroller (see the video description). For this teaching method, this course needs a robust, easy-to-use, single-step, source-level *debugger* that provides various views, such as disassembly view, CPU register view, stack view, memory view, watch view, etc. The free, command-line tools you mention are great, but they precisely lack a professional, visual *debugger*. A debugger has been also missing in platforms such as Arduino. The closest free and open tools to the requirements of this course are still Eclipse-based toolsets (e.g., STM32Cube) or VSCode extensions. The debugging in Eclipse is generally slow, not particularly reliable, and idiosyncratic ("Debug configurations"). VSCode extensions with OpenOCD are similar in nature and just not for beginners. If you know anything better, by all means, please share.

Arm Keil MDK-Community Edition does NOT require a PSN "product serial number." The procedure for registering the "Community Edition" is described at www.keil.arm.com/mdk-community/ . "Community Edition" is adequate for all projects of this video course. In fact, all of them have been prepared and tested with an ARM Keil MDK-Community Edition. --MMS

@@StateMachineCOM Entirely my fault then, truly sorry. Thank you very much for clarification!

@@zero2717 Quick update: As an exercise, I just performed an update of my Keil MDK-Community from version 5.39 to 5.40. The Keil website seems a bit messed up, reporting some "issues", but after some poking around, I landed at the website www.keil.com/demo/eval/arm.htm , where they have a short registration form, but then eventually they allow you to download the MDK540.exe installer (5.40 is the latest version at this time). I was able to successfully install 5.40, and my existing "Keil MDK Community (non-commercial free of charge)" license has survived. The tool seems to work correctly. --MMS

@@StateMachineCOM Thank you very much! Seems like I had to do a little more digging, my fault.

There are two separate pieces of software here: (1) Tiva/Stellaris USB Drivers for Windows and (2) Tiva/Stellaris Extension for KEIL uVision. Both are available from the companion web page to this course at: www.state-machine.com/video-course#Resources . After downloading the Tiva/Stellaris Extension for KEIL, you need to *install* it also. --MMS

I install all of them but still when I'm trying to find Debuger in selection it's not yet there. ​@StateMachineCOM

@@StateMachineCOM I DID ALL THE PROCEDURE AND STILL IS STILL NOT THERE

​@@StateMachineCOMBut the procedure are the Same and I did them to a different laptop one which have windows 10 and other 11 pro but yet is same problem

Meaning I download Drivers and it's Extension.

The project download for lesson #27 has been updated to include project stm32c031-qxk-keil (STM32 NUCLEO-C031, QXK kernel, KEIL IDE). The download is located in the usual place: www.state-machine.com/course/lesson-27.zip --MMS

@@StateMachineCOM Thank you

The assertion shown in the video at 29:20 can fire for many reasons all related to the fact that the same object (s1) is *shared* between two concurrent threads (blinky1 and blink2). One such scenario is that blinky2 gets preempted by blinky1 inside the Shape::distance() operation. Specifically, consider preemption during the calculation of dx = x - other->x (after loading the first x into a register but before loading the other->x into a register). Then blinky1 will call s.moveby(7,8) and *change* the other->x. When blinky2 resumes, it will load other->x into a register and calculate a non-zero difference! Strictly speaking, this situation is called a "data race". But the main point is that such ticking bombs are in the code in spite of "encapsulating" the s1 object because C++ encapsulation (or Java encapsulation for that matter) don't encapsulate anything in terms of *concurrency*. --MMS

I realize that documentation is not a very "sexy" subject. However, the embedded software development industry is under increasing pressure to deliver safety-related products. In such cases, documentation is not negotiable. Moreover, it must comply with the applicable functional safety standards, and all of them require *traceability*. You can purchase complex and costly requirement management tools (or generally ALM tools, which generally don't include source code traceability), or you can try a free and open-source alternative (like Spexygen). --MMS

I don't know. Maybe you could install Windows? Seriously, for better or worse, embedded community has chosen Windows as the primary host OS for embedded development. Therefore most tools (e.g., KEIL uVision, IAR, etc.) are available on Windows, so if you want to enter this market you should adapt to the established practices. Now, there are ways to do embedded development on Linux and macOS (e.g., VSCode + additions), but the installation is more advanced and not suitable for beginners. The tool installation issues already are the biggest problem as it is, please just check the comments in this video course. --MMS

Thank you, worked for me.

@@ironmanatee5949 gl hacking 🤓

thank you for saving me the headache, worked for me and I'm using Windows 11

I recommend that you watch two more lessons (#9 and #10) about the functions and the call stack because this might clarify a lot of things for you. And also, you now have all the tools to investigate your questions yourself! Just open the debugger and single step through the instructions in disassembly right before the function call, inside the function, and after it returns. When you do this, you'll see that code is always in ROM (adresses staring with 0x0000xxxx on TivaC and close to 0x0800xxxx on STM32). Data, including the stack is in RAM (addresses starting with 0x2000xxxx). The instructions are stored sequentially, but there are branch instructions that change the flow of control. One of these branch instructions is function call BL <function-address-in-ROM>. The other branch is function return BX lr. Please watch them as you step through the code. --MMS

@@StateMachineCOMThanks for replying back❤️ Thought to do so. Proceeding with lesson 9...

I'm really not sure what's going on with your KEIL uVision installation. I've just double checked, and the CMSIS packs are available from the ARM webstie (see www.keil.arm.com/packs/ . For TivaC, please search for TM4C_DFP : www.keil.arm.com/packs/tm4c_dfp-keil/boards/ ). The ARM::CMSIS is available at ARM.CMSIS.6.1.0.pack . Regarding the Stellaris ICDI extension, it should also be still available at: www.state-machine.com/course/MDK_Stellaris_ICDI_AddOn.exe . In summary, it appears that your KEIL uVision installation seems to be broken. --MMS

@@StateMachineCOM Thank you for the reply, Miro. I will try these, thanks.

This is precisely the subject of the *next* lesson "How interrupts work on ARM Cortex-M?". Please watch czcams.com/video/O0Z1D6p7J5A/video.htmlsi=ILDEFJRX6C3S_qAx

@@StateMachineCOM Thank you

Yes, the STM32 NUCLEO-C031 can be used for this course. Specifically, most of the project downloads (see www.state-machine.com/quickstart ) now also include versions for the NUCLEO board. However, if you want to follow the lessons exactly as they are presented in the videos, the original TivaC LauchPad is also still available. --MMS

That's precisely why I step down to the disassembly level. But the real lesson from this video should be to avoid *sharing* because sharing is at the root of all evil. And actually, the pure race conditions as shown here are just the tip of the iceberg. Even more common are various data races, where some complex data gets changed while preemption happens. After the preemption, the data is partially old and partially new (it's corrupted). Again, without sharing such a frequent problem wouldn't happen. --MMS

The simulator applies address ranges that are typical for Cortex-M microcontrollers. Addresses starting from 0x2000000 are allocated to RAM. Addresses starting from 0x4000000 are typically used for external devices. Please see the Cortex-M memory model: developer.arm.com/documentation/dui0552/a/the-cortex-m3-processor/memory-model

This lesson #13 uses the standard startup code generated by KEIL uVision. To get this code, you need to open the provided project in KEIL uVision. The act of opening the project will cause the generation of additional directories in your project folder. Among others, you will get the RTE folder (Run-Time Environment). Inside this directory, you need to go to RTE\Device\STM32C031C6Tx. Deep inside there, KEIL has generated the startup file startup_stm32c031xx.s, which is in assembly (not in C), but you can study this file. In the subsequent lessons (#14 and higher), you will use the customized startup code written in C. Please watch the subsequent lessons. --MMS

@@StateMachineCOM Thank you for the quick reply.

Your experience is very common during the transition from sequential (the "intuitive" way) to event-driven ("backward!"). I assure you that the transition *is* worth it. Regarding the repetitions in the state machine, they reflect the nature of the problem. It's not like your sequential problem is not repetitious (just at it!) But the traditional "flat" state machines have also another class of repetitions, which can be eliminated by using *hierarchical* state machines. This course has several lessons about all sorts of state machines. Here is the playlist: czcams.com/play/PLPW8O6W-1chxym7TgIPV9k5E8YJtSBToI.html

Change the install directory to: C:\Users\<user>\AppData\Local\Keil_v5 or wherever you have Keil_v5 install located.

@@ironmanatee5949 Yeah, I figured it was this. I was working with three different directories, and I only tried two of them at first. Then I went back and tried the last one, and it worked.

You're approaching it wrong. The most important fact to remember is that "in embedded programming, nothing works until everything works" ( I discuss this in the video czcams.com/video/kcpHuuEt1xs/video.htmlsi=NuerVMfiTBsExGxg ). Therefore, if your system doesn't work, you cannot make it work by tweaking it aimlessly. Even less chance has an outsider, like me, to diagnose your problems. Instead, you should take advantage of something that already works (the provided project). Then, you can *compare* it to your version and the differences will show you the problem. A good free differencing tool is essential. I use the free WinMerge tool (google for it). Please note that you *can* compare the uVision project files also (they are in XML). In the end, the purpose of this course is not to give you a fish, but to teach you how to fish. I hope you see my point. --MMS

@@StateMachineCOM thank you for the inputs. I was essentially doing the comparison between my file and the course download manually (comparing 2 windows) - didn't know something like winMerge exists, it's a game changer!

If you wish to follow this course exactly as it was presented, TivaC LaunchPad is nice to have. However, the newer NUCLEO-C031C6 board should also be sufficient for this course. Regarding the schematics, a simplified version is available in the document "STM32 NUCLEO-C031C6 Board" available on the companion website: www.state-machine.com/video-course#STM32C031 . Also, the projects for the NUCLEO-C031C6 are available (such as for this lesson-04) so, you should be able to build and run them on your board: www.state-machine.com/course/lesson-04.zip . --MMS

IAR Systems had been offering the free, size-limited "KickStart" version of their IAR toolset for decades. Only recently, the management of the company has changed and the free licensing of any kind has disappeared. Things were different when this video course was starting, but frankly, I don't blame IAR. There is just too much piracy and disregard for licensing. Everybody suffers because of this: both vendors and developers. --MMS