@jordibatlledelallave As you say, WFI is called with interrupts still disabled (with PRIMASK), and the interrupts remain *disabled* after the CPU wakes up. You can see this at 23:35. So, you must enable interrupts because nothing else will! This is precisely the special property of the PRIMASK register I referenced at 27:30 (Joseph Yiu's book). PRIMASK disables interrupts but still allows the CPU to be WOKEN UP by an interrupt (see the "Wake-up conditions" in Yiu). --MMS

Oh, gotcha! Thanks for the clarification

@jamesterpaul My KEIL uVision project for the NUCLEO-C031C6 board produces object files that start with "ELF". Please try to download lesson-14.zip from the companion web-page: www.state-machine.com/quickstart . I also checked that the GNU objdump utility works for the main.o file produced by this project. --MMS

This info is in the TM4C123GH6PM Datasheet (available on the companion web-page www.state-machine.com/video-course#Resources . You can search the PDF for "GPIODIR", which you find on page 663. On this page, you look for GPIO Port F and you find its address 0x4002.5000. Finally, you add the Offset 0x400 (provided in small print below the GPIO addresses). All this ends up as address 0x4002.5400, which you see at 9:50. Regarding the individual bits, they are explained on the same page. You need to know which LEDs are connected to which GPIOF bits, and this is described in the manual for the TivaC board (also provided on the companion web-page). --MMS

Mixing signed and unsigned representations is tricky, and its correctness depends on the context. Therefore, explicit casting is often necessary. Using a bigger integer (like your suggested int64_t) only kicks the can down the road, because precisely the same argument can be made at the end of the dynamic range of the bigger integer (0x8000000000000000). --MMS

SysML is an example of a bigger modeling language aimed at the whole system, not just software. The QM modeling tool supports only the state diagrams, which are fully compatible with the state diagrams of SysML. In this sense, QM can be used to model the state behavior of various system components, not necessarily just software components. Of course, non-software components cannot take advantage of QM's code-generation capabilities. But for software, QM can be a lightweight, no-nonsense, "low ceremony" tool that will get the job done. --MMS

@@StateMachineCOM Is SysML a modeling language you would recommend for embedded system design or is there a simpler one?

@@juanorlando9783 SysML (similar to the whole UML) is complex, and only small parts are "constructive," meaning elements that can be used for final implementation. Big methodologies like that have been tried and failed because elements that are not useful in the final product are abandoned. Hierarchical state machines are one of the few exceptions because they are "constructive" and can be used to generate production code that otherwise would be error-prone to create by hand. But here again, the danger is that if this feature is not used, state diagrams will get abandoned just like the rest of it. In this sense, automatic code generation is essential for the success of modeling in software. --MMS

After some messing around and trying to get the original files to work I just decided to use STMCube code generator completely. When using the files from the Github instead just use the code generation from STMCube and copy the main.c function from the Github into the Cube folder and delete the source folder

It seems that the APB and AHB in TivaC are mutually exclusive, so you should use one or the other, but not both. The APB is provided for backward compatibility. The AHB is faster and should be preferred.

Please google for lm4f120h5qr.h. --MMS

Unfortunately, no. Even though QP is licensed under the GPL, and GPL requires all applications that use QP to be open source, no company has opened up their real-world projects. This widespread non-compliance with GPL is disconcerting.

That is disconcerting. You are very generous to provide a GPL dual license for such a wonderful framework. Perhaps the FSF could help you if you know of companies that are non-compliant.

First question: a state machine needs different states to react differently to the same signal. For example, a "Blinky" state machine that blinks an LED reacts to the same TIMEOUT event signal differently. One reaction is to turn the LED on (e.g., in the entry action to the "on" state), and the other is to turn the LED off (e.g., in the entry action to the "off" state). Second question: to wait for a published event, an Active Object must subscribe to that event signal. Of course, a single Active Object can subscribe to multiple event signals. Then, whenever one of the subscribed events gets published, it will be "posted" to all subscribers. The events will then processed, starting with the highest-priority subscriber Active Object.

@@StateMachineCOM Thanks for your quick respond. I understood my misconception in the first question thanks Second question: I need to do an action when two evens or more happen ex: GPIO signal 1 is High and GPIO signal 2 is High and Timeout In a real example a state transion is needed when the timeout of the current state is fired and a motor is stopped and a clutch is released those are 3 different event generators that i am subscribed to each would notify alone but I want to servce there notifcations together previously I would use if(timeout && motorisStopped && clutchIsreleased) { //do something } how to make the same with qp?

@@ashrafkamel1287 The status of your GPIO pins are *guard conditions*, not events. So, when your TIMEOUT event arrives, you just check GPIO-signal-1 and GPIO-signal-2. There is a whole lesson dedicated to guard conditions: kzbin.info/www/bejne/iHi0g5-iq9eAr7ssi=62pfV211JxSvaZnq . Actually, you can all your questions by watching the whole playlist about state machines: kzbin.info/aero/PLPW8O6W-1chxym7TgIPV9k5E8YJtSBToI --MMS

Yes, precisely, manually setting the stack pointer (SP) to the beginning of RAM at 0x20000000 is how the fault has been "injected" into the program to test the error handling. But this has an interesting application: it shows you how to *detect stack overflow*! Specifically, if you place the whole stack at the beginning of RAM, overflowing the stack means that the SP would drop below 0x20000000, and from this video, you know that this causes the HardFault exception! Traditionally, the stack is placed at the end of RAM, not the beginning of RAM. But this placement won't detect stack overflow. Instead, the overflowing stack would corrupt the RAM below it. For this reason, I recommend placing the stack at the beginning of RAM. --MMS

@@StateMachineCOM if __stackless is not available for other compilers like stm32, then we have to code the Hardfault handler in assembly to check whether the stack is valid or not. if not valid then call NVIC_reset. Am I right here ?

Yes and no, depending on how you learn and what you want to gain from this course. A few early lessons run in the simulator entirely on your host computer, so these lessons don't require a broad. However, later lessons run only on real hardware. You can still watch and learn from such lessons, but doing the exercises on your own board would reinforce the learning and would give you more confidence that you can actually do it on your own. I hope that this reasoning makes sense to you. --MMS

Either way will help the project avoid human error. One possible issue with "keying off the max of the previous" is that it means that private signals will be exposed too, since that final private signal would have to be exposed to allow the next AO starting value. If we define ranges only, then it is up to each active object to define the signals within that range, and other AOs can avoid any knowledge of the other AOs. Mixed with a sprinkling of static_assert(...), the build will help protect from overflowing assigned ranges too. These concerns probably mainly apply to large projects where I want to avoid human error and also want to avoid too many inter-dependent modules from a compile time point of view. To some extent, just defining all the signals in a single header would take care of this too. But I just like the idea of: printf("sig: %d ", event->sig); having some clarity/directly by just visually looking at the value of the signal.

This lesson #29 about OOP only starts with the previous lesson #28 with some "blinkys", but it changes that code entirely to use "shapes" (the Shape base class and subclasses). Therefore, the project downloads for this lesson no longer have any "blinkys" and no longer run on real hardware; instead, they use the Simulator. Please download lesson-29.zip from the companion web page: www.state-machine.com/video-course . Actually, any time you run into problems like this, please just download the corresponding project. Then you can compare that known-good project with your own and see precisely where you differ. I hope this makes sense. --MMS

The video description has been modified to contain a definition of QP Frameworks.

It depends on what your program is supposed to do. Simpler programs can indeed be organized as a single state machine. However, a single-state machine can be in only one state at a time, which might not fit your problem. For example, communication software often must handle several communication channels, where each channel can be in a different state, so most naturally each channel should have its own state machine. Another limitation of a single state machine is the run-to-completion (RTC) processing. So, once it starts with an event, it must finish before processing another event. If this processing takes long, other events might not be serviced fast enough to meet your real-time constraints. The solution is to use different state machines running at different priority levels so the long-running RTC steps of low-priority state machines can be preempted by the high-priority state machines. All this means that in practice, you typically structure your programs as multiple state machines and have to deal with concurrency among those state machines. And here is precisely where the Active Object pattern and active object frameworks like QP come in.

I'll just re-iterate what @StateMachineCOM noted. Real world programs based on QP tend to involve dozens of active objects. Each active object has its own state machine. See the section Tip #3 - Define a Basic Software Architecture, where I discuss the top level executor and the N services. Each of those has its own state machine. Some of them might be very simple. Some complex. The drivers may (or may not) also consist of state machines.

The post() function is declared inside the Task class in the sst.hpp header file (located in the Super-Simple-Tasker/include directory). The Task::post() is defined in the sst.cpp source file (in the Super-Simple-Tasker/sst_cpp/src directory). These are the most sensible places to put such a central functionality. --MMS

Indeed, the newer IAR EWARM seems to disallow loading code for Cortex-M0 onto a target reporting Cortex-M4. Unfortunately, I cannot change that. But, the project for the KEIL Vision IDE for this lesson has been updated to compile for the M0, but run on the M4. Please download from the companion page and try. --MMS

@@StateMachineCOM Thanks, I will try this. I get the hack to do it in IAR. First, I have selected the "core - M0" and build the project. then again selected the Device - "TM4C123GH6PM" now from Projects > Download > Download file. I have flashed the device with M0 compiled .out (bin). Later for debug, I run "Debug without download"

@@StateMachineCOM Thanks, I will try it. I also managed to do it in IAR. First, I have selected "M0" and build the project. then, again I have changed the "Device : tm4c123gh6pm". After that I downloaded the code into flash with Projects > Download > Download file. To debug the M0 code in M4, I run the "Debug without download option".

Absolutely, it *is* possible to run SST at much higher CPU frequencies, at which point the kernel performs even better. In fact, SST will be so fast that it would require a much faster logic analyzer, so the cheap 24MHz analyzer won't be adequate anymore. Now, adjusting the CPU clock is not trivial. It requires adjusting several registers in the clock-control section, waiting for the PLL (Phase-Lock Loop) to settle, etc. There are whole tools (e.g., STM32CubeMX), which allow you to set it up correctly. --MMS

Projects that involve real peripherals, such as the GPIO, generally don't run in the simulator. Perhaps the simulator could be configured to accept reads/writes to the address range starting at 0x40000000, but I haven't investigated it. For these lessons, please just use the real board. --MMS

Ho so? Please explain.

Indeed, the term "blocking" is extended here to mean any form of waiting in line until some external event happens. For example, busy waiting for a time delay is considered "blocking" in this context. Traditionally, "blocking" tends to mean only by a context switch in an RTOS. However, any form of "blocking" should be clearly distinguished from performing computations. For example, some complex floating-point computations on a CPU without the FPU might take considerable CPU time. This happens in line, but this is NOT waiting for an external event. --MMS

STM32F10 won't work directly with the provided projects, which currently are for the TivaC LauchPad and the NUCLEO-C031C6 boards. Maybe the F10 could be added in the future, but it's not there yet. Regarding the cost, it has been always carefully considered in choosing the boards. For example, the C031C6 MCU is advertised as the most cost-effective and as a replacement for 8-bitters. The board is available for $10.97, which is a fraction of any book or paid-for course. I really don't know how to make it any cheaper than that. --MMS

Thank you for the question. It has been about 5+ years since I last tried to use QUTEST for a real-world firmware project. Myself and that team at the time decided QUTEST was best for driver level testing OR integration testing, where you might want to test just a subset of active objects at the same time on the target hardware (think IoT network testing). Otherwise, we preferred the approach described in the video. In fact, that same team, on the next project, drove the firmware development almost entirely with this approach. QUTEST was still used some, but more niche/driver oriented tests. From a TDD point of view, where we generally desire fast test execution and fast test cycles, I prefer the approach described in this video.

There is NO requirement that a local variable is in RAM, and the C-compiler is allowed to allocate such variables the way it sees fit. It turns out that keeping the 'counter' variable inside a CPU register is optimal because it avoids memory access. (Every memory access costs at least 2 CPU cycles, and you need LDR instruction to read and STR instruction to write back, which adds up to at least 4 additional cycles for incrementing 'counter'). If there are more variables than registers, the compiler must start using the RAM, but again, there is no strict requirement that the local variables be in certain memory locations. The main point here is that allocation and management of local variables is left to the compiler and you that's precisely why some compilers generate faster code than others. --MMS

This course is going to continue with new material, but there is NO NEED to update the first 20-30 lessons. The fundamentals presented in those lessons don't change and remain as relevant today as ever. But even the choice of the hardware (ARM Cortex-M4F CPU) remains absolutely spot on. So, don't wait and waste your time. Just dive in and learn! --MMS

Very good observation! Under the priority-based scheduler higher-priority task *must* necessarily block for any lower-priority tasks to ever run. And yes, there are other scheduling algorithms, where blocking would not be mandatory. For example, many RTOSes allow you to assign the *same* priority to multiple tasks. In that case (and if no higher-priority task is ready-to-run), the RTOS will execute all tasks with the same priority in the round-robin fashion. Such round-robin scheduling based on time slices has been discussed in this course in lesson #24 RTOS Part-3: Automating the scheduling with round-robin policy ( kzbin.info/www/bejne/honCfXevnr2ma7ssi=-4aJeLXt6K5ip2Ij ). --MMS

@@StateMachineCOM Thanks a lot for the answer Sir You have very good teaching skills.

That's true that KEIL Compiler-6 at optimization level -O0 generates LDR/ADDS/STR instructions for every increment of the counter variable. If you remove the 'volatile' keyword from the counter variable definition, all optimizations above -O0 (O1/O2/etc) will completely skip the incrementing of the counter. So in the end it seems impossible to generate code like IAR did. This actually shows the power of the 'volatile' specification and that without it compilers are free to optimize that any way they like (including skipping the whole incrementing altogether). --MMS

@@StateMachineCOMThanks! tried that, usual signed integer and optimization at O0 and the generated assembly is same as previous.

This video might require a bit more effort to fully understand, but the reward is also higher. Understanding the automatic context switch is your gateway to understanding the RTOS at a much deeper level than is usual in the industry. --MMS

In all cases like "my project works differently than yours..." the only sane advice is to compare and see for yourself what's different. Specifically, you should: (1) download the project for this lesson from the companion web-page to this course at www.state-machine.com/video-course , (2) build and run that project on your board and verify that it behaves as in the video, and (3) compare *your* project to the official one. A good free differencing tool is WinMerge (please google for it). The tool can compare whole directories. --MMS

It seems like a hardware problem with my board. This issue does not occur when I switch a different pin in the idle thread i.e instead of switching the red LED(PB14 in my case), I switch PA12 in the idle thread instead.

In all cases like "my project works differently than yours..." the only sane advice is to compare and see for yourself what's different. Specifically, you should: (1) download the project for this lesson from the companion web-page to this course at www.state-machine.com/video-course , (2) build and run that project on your computer and verify that it behaves as in the video, and (3) compare your project to the official one. A good free differencing tool is WinMerge (please google for it). The tool can compare whole directories. --MMS

Frankly, I don't know where to find the correct USB drivers for Linux and whether they would work. This course uses Windows as the development host machine because for better or worse, Windows has been historically chosen by the embedded community. Admittedly, this is changing now, but still most embedded tools are designed primarily for Windows.

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.

@@PyJu80 The primary embedded board for this course is the TivaC LauchPad (EK-TM4C123GXL). The board is oldish now, but still in production and available from suppliers like DigiKey, Mouser, and directly from TI. If you wish to follow this course most closely, get TivaC LaunchPad. It is based on ARM Cortex-M4F CPU, which continues to be the workhorse of the industry. The other board is the STM32 NUCLEO-C031, which is newer and based on ARM Cortex-M0+ CPU. That board is actually less powerful than TivaC, but has a more modern on-board debugger (ST-Link) and is expected to have a longer lifespan. Project files for the NUCLEO-C031 are provided, but they are slightly different than the projects for TivaC presented in the videos. If you wish to get the NUCLEO-C031 board, please do, but this is not necessary to benefit from the course. I hope this clarifies the situation. --MMS

@@StateMachineCOM I'm sorry to ask this. Tiva C launchpad and NUCLEO-C031 is hard to find here in my country, only some series from NUCLEO that are available in here ( NUCLEO-F446RE STM32 Nucleo-64 development board with STM32F446RE MCU , STM32 Nucleo G474RE Development Board Microcontroller , and STM32 Nucleo-64 G0B1RE Development Board MCU ) is it okay for me to use one of these boards I mentioned above ? Or should I buy this Raspberry Pi Pico RP2040 ARM Cortex M0+ instead ? I'm very new about MCU ( barely made the LED's blink with Arduino Uno R3 ) so should I really be super duper precise with the board especially with Nucleo or any Nucleo Series is alright to follow this course smoothly ? If i have to be precise ( ARM Cortex M0+) my only choice is to buy the cheap Raspberry Pi Pico RP2040, so is that okay too ? Thank you so much, sorry to bother you on this question, I do really want to use your course as a big step to be an Embedded Systems Engineer.

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".