#21 Foreground-Background Architecture ("Superloop")
HTML-код
- Опубликовано: 31 июл 2024
- Introduction to the ubiquitous foreground-background architecture, also known as the "superloop" or main+interrupts. Apart from being interesting in its own right, foreground/background is the starting point for all embedded software architectures and, among others, is an important stepping stone to understanding a Real-Time Operating System (RTOS), which was perhaps the most requested subject for me to explain. So, you can view this lesson as a prerequisite for the upcoming lessons about the RTOS as well as other architectures.
------
Resources:
Companion web page for this video course:
www.state-machine.com/quickstart
GitHub repository for projects for this video course:
github.com/QuantumLeaps/moder...
Transcript of this lesson:
www.state-machine.com/course/...
Music credits:
The background music comes from:
www.bensound.com/royalty-free... 
Наука
![So You Want to Be an EMBEDDED SYSTEMS ENGINEER | Inside Embedded Systems [Ep. 5]](http://i.ytimg.com/vi/m8w2FzqU5jg/mqdefault.jpg)
NOTE: The source code, as presented in the video, might cause compilation errors with the newer MDK-ARM / uVision toolsets. This is because the underlying compiler in MDK-ARM has been changed to "Compiler-6", while the older "Compiler-5" is considered now obsolete. The updated code that compiles cleanly with "Compiler-6" is available from the companion website at:
www.state-machine.com/video-course
and from GitHub:
github.com/QuantumLeaps/modern-embedded-programming-course
Dear Mr. Samek, I cannot emphasize enough how much I have learned by following your lessons. Thank you for sharing your knowledge
I can watch any tuturials from this guy. Awesome. please continue your channel.
Probably the best end of year thing that can happen programmatically.
What a great way to start the new year, with an awesome new instruction video by Miro. Thank you sir for sharing your Embedded knowledge to the masses.
Learned so much from your previous lessons. Welcome back!
Great to see you back! I have enjoyed your series very much :)
your videos are absolutely insane and so is the representation
always waiting for new stuff
Wow.... Even before I see the video, am very excited to hear from you after a very long time. Thanks for the comback Sir!! Happy new year !!
wow one more video after long long time... Looking forward to more videos hopefully at regular intervals ;)
Thank you Sir....
another awesome video from Dr. Samek many thanks :)
7:21 For anyone wondering how the while-loop condition ((BSP_tickCtr() - start) < ticks) in the BSP_delay function always works even when the counter wraps around from hex all-Fs to hex 0 is because the counter variable here is implemented as a uint32_t type, which has the same 32-bit precision as the fundamental int type on the ARM processor.
For example, let us assume that we call the function with ticks argument equal to 5 and that start evaluates to 4294967293. 5 SysTick interrupts later, the counter rolls over the maximum value of 4294967295 so that BSP_tickCtr() returns 2. We expect the loop condition to evaluate as false and exit, but you may think that (2 - 4294967293) would evaluate to -4294967291, which is less than our ticks of 5, making the condition true and continuing the loop (indefinitely). However, this does not happen because when the (BSP_tickCtr() - start) part of the condition is evaluated, integer promotion converts both operands (and their combined result) to unsigned int type, which does not widen it. The (2 - 4294967293) evaluates to 5, which is equal to our 5 ticks, and the loop exits as expected. Similarly, the while-loop condition also always runs successfully if the counter is implemented as a int32_t type, or as any type with more than 32-bit precision.
WARNING: If we were to instead implement our counter with a type having less precision than the fundamental int type on the ARM processor, such as uint8_t, int8_t, uint16_t, int16_t, etc., the above scenario would indeed result in a never-ending loop and program hang. For example, let us use a uint8_t type counter and call the function with ticks argument equal to 5 and assume start evaluates to 253. 5 SysTick interrupts later, the counter rolls over the maximum value of 255 so that BSP_tickCtr() returns 2. This time, (2 - 253) will evaluate to -251 (not 5) because this number can fit within the integer-promoted result type of (signed) int. Our left-hand condition value will always be less-than our ticks value of 5.
To summarize, if you implement your counter as having less precision than that of the fundamental int type on your machine (e.g., 32-bit for ARM, 16-bit for MSP430, etc.), then a counter wrap-around during while-loop execution will result in the condition forever evaluating as true and the loop running indefinitely, causing program hang. This is due to the C Language Standard's integer promotion rule, which widens all types with precision less-than or equal-to that of int during evaluation, to either int or unsigned int.
Please watch Lesson 11 for more information on type precisions, including how they interact when mixed in an expression. A detailed explanation about integer promotion and the "usual arithmetic conversions" can be found on the 'Implicit Conversions' page of the cppreference website, or in the 'Conversions' section of the appropriate C Standard.
Yes, absolutely, you need to be careful with the wrap-around and this might be NOT portable to other CPUs with different word size. --MMS
Thank you very much for the explanation I searched entire internet for the answer and did not find it I should have looked at comments earlier
To see the translated videos at the under of your web page made me happy :-)))
Such a great video!
Thank you for sharing your knowledge!!
The guy is Back !!
Can not wait for seeing RTOS videos
Brilliant videos!! I just want to say thank you for all your time and effort. Looking forward to more videos in the future (:
Your videos are the best!
thank you. this is great and a true treat 🙂
Awesome lesson, thanks!
Thank you for the great video!
very good lesson!
Thanks for the great tutorial Miro. Just a comment on license manager. There is no PSN (Product Serial Number) associated with the evaluation version which seems to be the only available free option. So that licensing step can be skipped without any issue.
Also, the archived version of this lesson is not the starting package but the final version at the end of the tutorial. I think it would be useful to include both starting and final packages in the course project archive to make it easier to kick off the course and follow the steps.
HI,
Thank you for this great cours. I can't understand how the delay function works in conjunction with the systick_handler. the latter is to trigger each STRELOAD. so what is the link between STRELOAD and the delay of BSP_delay?
For those you are using a newer version of Keil, debugging might not work (Keil hangs/Debugging exits immediately) due to a well-known bug. The fix is here: users.ece.utexas.edu/~valvano/Volume1/Window8KeilDebuggerFix.htm
very good
The best
Many thanks for the lessons. What is your relation to Atego?
Thanks for this great content. I'm a bit upset since you switched to a non-free IDE. I wonder, *1-* Can "vim+gcc+make" be used in embedded development? For example can it be used to program TM4C123? *2-* Do FOSS solutions like Eclipse fall short to Keil or IAR? *3-* What do you yourself use or recommend us to use?
Hope more videos about QP.
Thanks for the clear explanation. Blocking Vs Non-Blocking, what is the best way for energy efficient coding?
The key to energy efficient coding is to utilize the low-power sleep modes of the CPU and peripherals as much as possible. The most convenient way to achieve this is to have only one place in the code when the CPU/peripherals are turned off (to be woken up by an interrupt). In the foreground/background architecture, this is easier to achieve in the non-blocking, event-driven paradigm, because you can simply test for the "idle condition" at the end of the fast-executing main loop. In contrast, when you use blocking (polling), you need to think about low-power modes in every blocking call (e.g., inside the BSP_delay() function and other functions that block). In the upcoming lessons about RTOS, you will see that the blocking paradigm can be "saved" by using multitasking and that an RTOS offers a single "idle thread", where you can conveniently place the system in a low-power mode. Hopefully this makes sense to you. --MMS
Please introduce how can we build programs on Linux?
Is there any Linux variant of this KEIL MDK toolset?
Greetings Team QP,
I couldn't get how was the clocking frequency was initialed in the program,
{
SystemCoreClockUpdate();
SysTick_Config(SystemCoreClock / BSP_TICKS_PER_SEC);
}
As I am a starter I couldn't able to figure it out from my side, I could understand that this part is most integral part of the code (setuping clock frequency ) and could you also suggest any reference to know more about system clock configuration. This would be a great if you suggest any thanks in advance!
The clock configuration is performed in the module system_TM4C123GH6PM.c which is part of the provided uVision project. You can find this file in the qpc folder: qpc\3rd_party\ek-tm4c123gxl\system_TM4C123GH6PM.c . The function that configures the clock is SystemInit(). It is called from the startup code startup_TM4C123GH6PM.s, which is also included in the uVision project. To learn more about the startup code, please watch lessons 13-15. --MMS
Hi sir, thanks for amazing course. But I'm confusing at the foreground/background model at 9:11. Why the length of ISR is different for each other? I think ISR systick decrease counter every machine cycle repeatedly in constant, so why it is different? I see in the program you stop and start interrupt in the BSP_tickCtr() function but I still don't understand why it effect the lenght of each ISR?
Thanks for paying attention! You're right that in this particular example, each invocation of the ISR should take about the same time to execute. But in the picture at 9:11, I wanted to show a *generic* case, where ISR invocations can take different times to execute, and also, there might be different ISRs. I hope you can easily imagine that there might be IF statements or even loops inside ISRs. The main point is that you cannot count on ISRs to always have the same execution time. Finally, the picture at 9:11 does not show another factor, which is the time interrupts are *disabled* in the background loop. That time causes ISRs to execute later and that delay is also variable, depending on how long the interrupts are disabled in various parts of the background and also when the ISR fires. All of these factors introduce jitter. --MMS
i found debuggin error " i downloaded Tiva driver from site and still i can't get it in the selection of debugger "
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
How to run this lesson 21 on IAR ?
I got error "SystemCoreClock is undefined".
The project download for this lesson-21 has been augmented with the IAR workspace, which was tested to build the code correctly. Please download lesson21.zip from the companion page (state-machine.com/quickstart ) or from GitHub (github.com/QuantumLeaps/modern-embedded-programming-course ). --MMS
As always, awesome video. Just one question: is it necessary to use __disable_irq() in the BSP_tickCtr function? It seems there is no race condition there since BSP_tickCtr only reads the 32bit value.
Yes, in this particular case of a 32-bit processor, the simple reading of the l_tickCtr variable (as opposed to read-modify-write operation) happens to be atomic. But even a simple reading of a variable shared between the background loop and the ISRs *might* be unsafe if it is not atomic (e.g., on a 16-bit processor). Therefore it is a good practice to perform such an operaration in a critical section. If anything else, such a crtical section serves as a comment that the programmer has *thought* about race conditions. Also, such code is portable without any "ticking bombs". I hope you get the point. --MMS
Totally got it. Thanks so much for the clear answer.
@@StateMachineCOM Firstly thanks for great vides, here I have one hint if you will improve your application by adding more different interrupts, to my mind the best idea/ approach is not to disable the global interrupt for the whole system, only disable the dedicated interrupt in this case system tick interrupt, Miro what do you think?
Yes, you can be more selective with disabling interrupts and the NVIC in Cortex-M allows you to disable interrupts individually. However, this is not practical for system-level software such as Real-Time Operating System (RTOS), which is discussed in lessons 22-28. The problem there is that the RTOS does not "know" which specific interrupts to disable, and most of the interrupts interact with the RTOS anyway. But some RTOS kernels, including the QXK kernel discussed in lessons 26-28 support so called "zero-latency" interrupts, by selectively disabling interrupts only up to the specified interrupt priority level. Please watch the lessons and pay attention to the "interrupt latency" sections. --MMS
@@maciejcebula3353 Yes, disabling just the interrupt that "touches" the shared variable (SysTick in this case) will be sufficient for guaranteeing mutual exclusion. But here, you need to consider the computational cost of doing so, and it turns out that surgically disabling and enabling specific interrupts is significantly more *expensive*. It requires accessing memory-mapped registers, for which you need to clobber at least one CPU register. In comparison, disabling interrupts globally takes only one single-cycle instruction (CPSID I) and re-enabling another single-cycle instruction (CPSIE I). No CPU registers clobbered and no expensive LDR/STR instructions (at least two cycles each). Also, as long as the total interrupt disabling time is shorter than the longest CPU instruction (which is the case here), you don't really increase the interrupt latency of the system. (The longest CPU instruction is exception-entry/exit of at least 12 CPU cycles.) For these reasons, I would say that global interrupts disabling works better in this case. --MMS
Thanks for such an amazing embedded software playlist. Sir I have two questions. In the main function you have defined the function SystemCoreClockUpdate() and Systick_config function. In the systick_config function you have passed SystemCoreClock variable as an argument. In the CMSIS documentation it is stated that the function SystemCoreClockUpdate() updates the new clock value of the systick timer as well as the Arm core CPU but you havent provided any parameter to this function so why called this function ?? And the second thing is, the argument passed to Systick_Config function is SystemCoreClock/100, because in the video sir you havent provided any argument to SystemCoreClockUpdate(), so according to the datasheet the clock to systick timer is systemclock/4 which is 4000 and dividing it by 100 which is the value of bsp_ticks_per_second comes out 40,000 which does fire the systick interrupt after every 100 ticks. But in the video you said systick fires at 100_ticks_per_second but how?.
This question is about the design of CMSIS, specifically of the CMSIS functions SystemCoreClockUpdate() and SysTick_Config(). These functions are NOT defined in this project. Instead, SystemCoreClockUpdate() is defined in the CMSIS file system_TM4C123GH6PM.c (which is included in the project) and the function SysTick_Config() is an inline function defined in core_cm4.h header file.
The CMSIS design is indeed a bit clumsy in this respect. But when you look at the definition of SystemCoreClockUpdate() (in system_TM4C123GH6PM.c), you will see that it has a side effect of setting the CMSIS global variable SystemCoreClock based on the registers of the specific MCU (TivaC in this case).
In the end, however, this is a completely inconsequential detail for understanding the main premise of this lesson, which is "Foreground-Background Architecture". It's good to try to understand the details, but I hope you are not losing the forest for the trees! --MMS
Is there a point of too much background structure? One project I did have different 180+ files in a fairly simple IoT application.
Hi - Why do you think that the reading of l_tickCtr need to be under the critical section? What type of race condition do you see if the reading of the l_tickCtr is not protected by critical section? thanks
On a 32-bit CPU, reading a 32-bit l_tickCtr variable is probably safe from race conditions because the 32-bit LDR instruction is atomic. However, on a 16-bit or an 8-bit CPU such a read would no longer be atomic and so a race condition would be possible. My goal in this lesson was precisely to emphasize such concurrency hazards and to point out portable protection mechanisms. --MMS
I don't go to main with debug and it go to " LDR r0,=0xE000ED08 ; System Control Block/Vector Table Offset Reg". Can you help me pls.
Please make sure that you select "run to main" in the debugger setting (the debug configuration dialog box has a checkbox). If you don't select "run to manin", the code execution will start from the reset vector. --MMS
HI,Dr. Samek,why after I downloaded the new 21lesson you provided and put the qpc folder in the correct location (the same as the tm4c123-keil folder), I got these two identical compile errors into KEIL:ek-tm4cl23gxl/cmsis compiler.h(41): error: 'cmsis_armclang_ltm.h' file not found. This header file clearly exists in ek-tm4c123gxl.
I'm not sure what happened with the lesson-21.zip download, but please download it again and give it another try. The projects have been recently updated and are now self-contained, meaning that you don't need any other software components to build and run the projects. The download section of the companion web-page at www.state-machine.com/video-course#Videos has been also updated and a prominent note has been added about the self-contained nature of the projects. --MMS
@@StateMachineCOM THANKS for your answer but i download and decompressing it again it still has two same error.Then i change cmsis_armclang_ltm.h in the project to cmsis_armclang.h.Firstly,it said 95 warnings and then hit the build button again and it turned into 0error 0warning. However, when I downloaded the program into the TM4C, the light on the board did not blink as expected.
Thank you very much for your answer, I will continue to find the cause of the error@@StateMachineCOM
@@JZL-et4nr I just downloaded lesson-21.zip from www.state-machine.com/video-course again, uncompressed it, and opened the project in my KEIL uVision V5.38.0.0. It *works for me* flawlessly, so I really don't know what to fix. Please check that you indeed are using the latest version. --MMS
Thank you Dr. Samek, the lesson21 project download works as expected.
However, I was playing around with the code and it seems that after replacing some of the function calls in main() with their corresponding function body (such as BSP_init() and BSP_ledGreenOn(), for example), the board locks up when trying to run the debugger. The LM Flash Programmer is then needed to unlock it. Revert these changes back to their respective function calls and everything works fine again. I attempted to debug this issue myself by comparing the disassembly of both scenarios but nothing obvious stood out to me, e.g., stack/reset vector values look correct, etc. What could be causing this? Perhaps a project/configuration issue or something related to uVision itself?
As you've just discovered, the initialization of the embedded board is sensitive code. For example, if you don't enable *correctly* the clock to a given peripheral, any access to that peripheral might end up in the HardFault_Handler exception. In fact, I suspect that this is happening and your board keeps quickly resetting (through the Q_onAssert() handler). In that case, the hardware debugger cannot get hold of the CPU and you end up with a locked-up board. But this is also a good opportunity for you to learn that in embedded systems nothing works until everything works. So, it is critical to start with *working* code (which you have!). Now, you can make changes in *small* steps, changing only one thing at a time and always checking if the thing still works. As soon as it stops you will know which step broke it. It might sound like a lot of work, but it will take less time than writing this comment. I hope that this general advice makes sense to you. --MMS
@@StateMachineCOM The more I experiment, the more strange this issue seems.
I start out with your working project download code. Then in main(), I replace the BSP_init() function call with its function body, and everything still builds/debugs cleanly (the TM4C header include and LED macros must also by added to main(), as well). Then, I replace the BSP_ledGreenOn() function call with its body (i.e., `GPIOF_AHB->DATA_Bits[LED_GREEN] = LED_GREEN;`), and now I get a board lockup on debug. More unusual is that if I instead only replace the BSP_ledGreenOff() function call with its body (i.e., `GPIOF_AHB->DATA_Bits[LED_GREEN] = 0U;`), it also leads to a board lockup. In other words, the changing of a single line of code with another single line of code (replacing either function call with its body) is enough to corrupt the board.
Also, using the IAR project files to make these changes and build/debug the board works fine, so the problem looks to be happening within uVision specifically.
@@abominabletruthman Finding a compiler error is rare, but it happens. Have you tried to change the compiler optimization (e.g., -O0 or -Os balanced)? --MMS
@@StateMachineCOM I just performed the procedure above for all available optimization levels and the only one that does not corrupt the board is -O0. All others result in a lockup. So, any optimization at all creates this issue, though I still cannot make out what exactly is causing it when comparing the disassembly views of the good and bad executables. Whatever it is, it does seem to be a bug with Arm Compiler V6.19.
@@abominabletruthman This might be an issue of pipelining in the CPU. Specifically, after enabling the peripheral clocks for GPIO, you cannot access the GPIO peripheral immediately. ARM CPU provides special instructions to make sure that instructions don't run into each other (see ISB -- Instruction Synchronization Barrier and DSB -- Data Memory Barrier). I recommend using both of them after configuring the GPIO clocks and AHB use but before accessing the GPIO. In fact, all project downloads have been updated to use the calls __ISB(); __DSB(); Please see the GitHub repo for the course at: github.com/QuantumLeaps/modern-embedded-programming-course --MMS
18:00 can u plz explain this diagram with pseudo code example for every architecture in 1 small video ?
That's exactly the plan: to explain all the embedded software architectures from the diagram. The plan is to go chronologically: from the RTOS (1960s-1970s), through event-driven and object-oriented programming (1980s), to modern state machines and active objects (1990s), to "reactive programming" (2000s). Stay tuned... --MMS
am waiting and thanks for ur time
In the first 20 lessons everything worked well. However in the lesson21 after building the project when I press Debug button it tells me 'No ULINK2/ME device found'. And then "Error: Flash Download failed - Target DLL has been cancelled". I installed uVision V5.29.0.0, Toolchain MDK-Lite Version 5.29.0.0 and used Pack Installer to install Tiva support. By the way, in the Debug tab of Project options for Target no Stellaris option in the Debuggers field as it was in two previous IDE. What did I miss? Thank you.
The uVision 5.29 IDE works with the TivaC board. Your uVision project cannot connect to the TivaC board, because apparently it tries to use "ULIN2/ME" hardware debugger. For the TivaC board you need to install the "Keil::TM4C_DFP" device pack. You do this through the "Pack Installer", which is available on the Build toolbar.
--MMS
Stellaris ICDI has been removed from uVision. I was facing the same problem here. I followed these instructions and it worked right away: www.keil.com/support/docs/4196.htm
Just change it to Stellaris ICDI after installation
@@gabemvp Thanks! Was looking for a solution for this, and thought comments might help, you sure did :)
@@TheNordrian I'm glad it worked :)
@@gabemvp Great. I had the same problem and this worked. Thanks.
a question MR MIRO "sorry for annoying you"
when I check this parameter [ SystemCoreClock ] , I find so strange value >> 50 000 000 ... why this happened , although we do NOT use PLL , and if keil uses the PLL automatically , why does it do that !
Please take a closer look at the uVision project for this lesson-21. Specifically, look in the group 'ek-tm4c123gxl'. You should see there two files: startup_TM4C123GXL.s and system_TM4C123GXL.c. The startup (file in assembly) calls the function SystemInit() from the Reset_Handler. This SystemInit() is defined in system_TM4C123GXL.c, so open this file and search for this function. When you do, you'll see that SystemInit() configures the CPU clock to use PLL, which explains the value 50MHz. --MMS
@@StateMachineCOM yeah .. you alright . I ve checked the TM4C123GXL.c file and i found there is a default value for RCC register thanks MR MIRO ...
@@StateMachineCOM BTW you are the best teacher I ve ever learned from ...thaaank u very much for these helpful lessons .. may god bless u
@@omarayman5318 another way is to checkbox the BYPASS PLL in the system configuration file/wizard...
@@UCZcuyApXHiYcMBjsjOb8ZyQ999 thank you , I m gonna try to do it using this checkbox ..
anyway I did it manually in the code
sooo you should not do mix between blocking and non blocking systems?
That's right. You should not mix blocking and non-blocking programming paradigms. Truly blocking components are also difficult to combine together, because the blocking makes them unresponsive. That's the main reason for using RTOS (please watch the next vidoe ruclips.net/video/TEq3-p0GWGI/видео.html ). In contrast, non-blocking code *is* composable, meaning that you can combine many event-driven code snippets in one big loop, and they will still work. But you can do better than that. Please watch the segment of lessons about "Active Objects" ( ruclips.net/video/l69ghMpsp6w/видео.html ) and later about state machines ( ruclips.net/video/EBSxZKjgBXI/видео.html ). --MMS
Thanks for interesting topics. But from what I understand is that the code blink LED should be called from hardware interrupt such as system handler, hardware timer (foreground task), not calling from main function (background task). From your both code all the blink LED is call from main function. What you called non block version is just move the delay code to main function. And the lesson is not clear what purpose of background and foreground task. In your example, it only mentioned to increased the systick counter. How about call the delay from foreground here, it is easier to undertand is it?
Yes, absolutely, a dead-simple action like turning an LED on and off would be easiest to do directly from the ISR. But this would miss the point here, which was demonstrating the foreground-background architecture and the issues involved. I'm not sure if a more complex, "real-life" example would be a better teaching aid. Certainly, the Arduino "Blink" program shows the exact same structure, but nobody complains because Arduino completely hides the "foreground" (ISRs).
Hello MMS - what do you mean by "home grown executives"? If not in this video, do you cover in future videos? Thanks
I'm not sure where I used the phrase "homegrown executives". But if you mean other types of embedded architectures, then the next segment of 7 lessons is about the RTOS (Real-Time Operating System). Also, there are two videos about SST ("Super Simple Tasker"), which is a preemptive but non-blocking real-time kernel. I also plan to talk about cooperative kernels. --MMS
@@StateMachineCOM - the phrase is mentioned in the picture at video time 18.00.
@@jankeshchakravarthy9389 One example of a "homegrown executive" is "The one line RTOS" ruclips.net/video/g-Lq3vz00Yw/видео.htmlsi=GnK8v7iKPfhbqI-u
Hey everybody,
How to get the PSN (Product Serial Number) to get the LIC ?
It´s mondatory in the forme to fullfil .
Thanks
You have probably requested an evaluation license for IAR EWARM. You need to request the size-limited KickStart version. --MMS
@@StateMachineCOM Do I need to enter IAR KickStart license number as PSN?
For debuggin error I downloaded Tiva driver from site this time could not load lesson.axf file error appear.
Your TivaC LauchPad board might be "locked up". Please visit the companion page to this video course at www.state-machine.com/video-course and download the Application Note "Troubleshooting TivaC LaunchPad". This document describes how to "unlock" a bricked board. --MMS
@@StateMachineCOM After including QPC path to target compiler resolved.
how do I know which code to protect from race condition?
A very good question, because often you don't know which code to protect!!! Therefore, it is much better to prevent race conditions by design rather then to retroactively avoid them by means of mutual exclusion. In the later lessons of this video course I show the event-driven programming style with "active objects", which can prevent race conditions by design. --MMS
:D Wow
and the REAL Oscar goes to Dr. Samek, not the trash in Hollywood that "thinks" they are smart.
Well, in the sequential blocking code if you might used if condition instead of while -> it would also spend time in main loop, because in event driven code you used if condition where in blocking code you used while condition........... P.S. event driven switch case is more preferable.
Replacing the polling while() loop with an if() statement would require completely changing the whole code structure, or the "blinky" code will not blink as expected. Such transformation would change the sequential code into something else: the event-driven code. Now, event-driven code might be more preferable, but it comes with its own set of challenges, one of them being that event-driven and sequential paradigms don't mix well. This will be the subject of many more upcoming videos of this course. --MMS
I had a problem in my Keil uVision V5.29, I could not Debug or install my code on my Tiva board, I searched for that I found a new problem and the solution is:
Use an add-on installer that brings back the support for Stellaris ICDI to MDK v5.29 and above. Just download and install "MDK_Stellaris_ICDI_AddOn.exe" from link below;
www.keil.com/support/docs/4196.htm
My Error was:
Cannot load driver 'C:\Keil_v5\ARM\BIN\lmidk-agdi.dll'.
Possible Reasons:
- Driver DLL could not be found in the specified path
- Driver DLL requires additional DLL's which are not installed
- Required Hardware Drivers are not installed
Debugger aborted !
Thanks for the tip Muhammed. Saved me a lot of time.
For people confused (like me) about ((BSP_tickCtr() - start) < ticks), think of this like a clock. A clock at 1pm, but 4 hours prior, we have 9am. --> 1-4 = -3 + 12 = 9.
Now for unsigned int , which is a 32 bit number, the value ranges from 0 to 4294967295 (0xFFFFFFFF), therefore the total number of values are 4294967295 +1 = 42949672956, which is exactly like 12 hours, we call this MAX_VALUES.
So if we have the condition where start value was 4294967293,
1 systick interrupt -> 4294967294 ,(BSP_tickCtr() - start) = 1
2 systick interrupt -> 4294967295 ,(BSP_tickCtr() - start) = 2
3 systick interrupt -> 0 (roll-over) , (BSP_tickCtr() - start) = -4294967293 + (MAX_VALUES) = 3
4 systick interrupt -> 1 , (BSP_tickCtr() - start) = -4294967292 + (MAX_VALUES) = 4
And so on...
Hope this helps ( I am writing this to take a snapshot for myself).
hi, when building i get, the following cant find files error
Build started: Project: lesson
*** Using Compiler 'V6.16', folder: 'C:\Keil_v536\ARM\ARMCLANG\Bin'
Build target 'dbg'
assembling startup_TM4C123GH6PM.s...
startup_TM4C123GH6PM.s: error: A1023E: File "..\qpc\3rd_party\ek-tm4c123gxl\arm\startup_TM4C123GH6PM.s" could not be opened: No such file or directory
ArmClang: error: no such file or directory: '../qpc/3rd_party/ek-tm4c123gxl/system_TM4C123GH6PM.c'
ArmClang: error: no input files
compiling system_TM4C123GH6PM.c...
bsp.c(5): error: 'TM4C123GH6PM.h' file not found
#include "TM4C123GH6PM.h" /* the TM4C MCU Peripheral Access Layer (TI) */
^~~~~~~~~~~~~~~~
1 error generated.
compiling bsp.c...
".\dbg\lesson.axf" - 4 Error(s), 0 Warning(s).
Target not created.
Build Time Elapsed: 00:00:01
thanks for you time.
It seems that you are missing the qpc software which is a separate component. You need to download the [qpc.zip](www.state-machine.com/course/qpc.zip) file (the link to qpc.zip is provided in the "Project Downloads" column on the companion web page). You then unzip it so that the qpc directory is at the same level as your lesson-21 directory. The qpc software will be needed in most lessons moving forward. --MMS
was facing same issue thanks for reply, both must be at same level, lesson-21 and qpc in unzipped format
@@StateMachineCOM