#12 Structures in C and Cortex Microcontroller Software Interface Standard (CMSIS)
HTML-код
- Опубликовано: 14 май 2014
- This lesson talks about the C structures. You will also get introduced to the Cortex Microcontroller Software Interface Standard (CMSIS), which uses structures to access hardware in Cortex-M microcontrollers.
------
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... 
Наука
Your work is precious Sir, thankyou very much for given this informations for free, while you could create a paying course !
I had started learning Embedded system from 8051. I had programmed my first application in assembly but 8051 is very simple microcontroller with very few registers and therefore it was really easy. After that i moved to PIC and AVR. I programmed them using many different IDE and was always using API's for that and therefore i didn't have fundamental knowledge about how hardware works. When i started working with ARM, i tried really hard to understand all the API as deep as possible but felt like impossible task after seeing thousands of line in every header file with strange register name.
Today i have learn most useful feature of Embedded low-level software development which would help me in a long run. Thanks a lot sir. So far i haven't seen any book which explains all these low-level stuff in such details. I really appreciate your selfless service to all the beginners of Embedded world.
+Chadresh Patel A lot of people started with the good ol'8051, the PIC (PIC10/12/16/18), and later the AVR. But the problem with all these processors is that they have been designed before the widespread use of high-level programming languages (such as C) in the embedded work. Consequently, all these machines are awkward to program in C, mostly because they have very limited stack. But event when the stack is adequate, like in the AVR, other problems show up, such as difficulty in accessing constant data in ROM. (AVR is a Harvard architecture, where ROM is accessed with different CPU instructions than the RAM, so using just the 'const' keyword is not sufficient for the compiler). The bottom line is that the "C compilers" for all these older 8-bitters require some non-standard extensions.
In contrast, modern embedded CPUs, such as ARM, have been specifically designed for high-level language programming. ARM Cortex-M takes it to the logical conclusion, where even interrupt service routines are regular C functions (see Lesson-18 in my "Embedded Programming" video course).
Chadresh Patel Nothing better could be said than what you have said, I learned tons of information and I am planing to re-watch all videos as I continue working in embedded systems.
Probably the best Embedded software course on the internet.
Amazingly detailed step-by-step hands-on course! Thank you.
These demonstrations and explanations based on assembly codes are really useful to see the effects of our choices on the hardware side. That's amazing, thank you sir.
this series is so good I have no words. very hardware-focused, as it should be, by a very knowledgeable person
The best embedded programming course I have ever followed, congratulation and thanks
Francesco Villanese Great isnt it! Really explains the low level stuff and how to use the datasheet.
Thank you for your work. We are all waiting for the next lesson!
man, this tutorial helped me so much.. as i have just started in a new position and needed to understand a project and fast, and you made everything make sense. thank u so much!
Great video series!
I knew CMSIS helped with portable code but this is the first time I saw a clear explanation of how CMSIS works and relates to vendor specific headers.
Great work Mr Samek, thank you!
I love you Miro Samek!! Ive learnt a lot of things, whats happening under the hood.. I cannot express my gratitude more than this.. Thanks a lot! Bring in more videos Please.
Thank you very much!!! Usually such high qualitive content is not free.
You have a talent for teaching, man.
Simply superb. Well done and thank you.
Thank you for the nice tutorials. Hope you will continue the nice work.
Excellent explanations. Thanks for sharing your knowledge.
Thanks,
Gives clear understanding of Structure data alignment in memory by compiler and Hardware dependency.
Just gotta say you are awesome. Your videos should replace any programming course I got in uni.
Thank you for such an informative video.
great series! I loved it!
Wonderful lesson .... thank you sir
What a great playlist. Wow!
Great vid, thanks a lot!!!
next great lesson
Thank you.
Brilliant :) , Should I ask about the next lesson or it is too early :-D
Thank's a lot.
I know I'm 6 years late, but from the bottom of my heart, THANK YOU. This video just helped me a LOT. So much you can't even imagine. From someone who knows nothing about embedded systems and only a handful of C/C++ programming concepts and syntax, trying to figure out CMSIS structure-style register definitions was extremely difficult. But you really cleared it up very nicely and in a very methodical manner. Once again, thank you very much.
I only have one question though. Since non of the structures in CMSIS are instantiated, and instead are hardcoded to point to a particular point in memory space (register/ram/flash/etc.), that means these do not consume RAM right? Because they are all resolved to direct register addresses during compilation. I'm assuming because the magic line it when we #define the structure pointers to the hex addresses. This was what has been confusing me for a while now.
Yes, that's correct. Most structures (C structs) declared in CMIS do not take RAM or ROM. Instead they "map" the registers of already existing peripherals. The CMSIS structs are then "anchored" at specified base addresses (through the #define macros), to that the data members provide offsets from those base addresses. (Please remember that a C struc is just a bunch of named offsets from the beginning of the struct). This provides the "mapping" of already existing hardware registers, which allows you to conveniently access the registers from C. --MMS
@@StateMachineCOM Aha, then my understanding is right. Thank you. I was trying to figure this out for some time now. I even asked a question on Stack Overflow and the responses helped too. Can I post a link to your video here on my Stack Overflow question so it can help others?
Unfortunately my editor (IAR 8.32.2) doesn't help with structure elements drop down list - only 'working' message is blinking once. What can I do with it ?
Thanks for this excellent videos. In this lesson 12 please can you explain why was added the DATA member to the GPIO_TYPE structure from tm4c_cmsis.h ? You say to review lesson 7 but I didn't understand. Thanks.
Thanks a lot for the course and make it available for all.Is there any books or resources for application based embedded system development, rather than a blinky program where it described how to get input from various sensors, motors, calculate the result and then send it to output objectives? My background is neither electrical or programming , I just started to learn it. Need advice.
If I am dealing with, for instance, Keil rather than IAR, is there a problem ?!
You are genius,
When the next lesson ?
If you write a book about embedded c, I will be the first one buying it
exactly, if he wrote a book on ARM programming in C ... it will be a really great hit.
If I generate my own project I get problems with finding the CMSIS core librariy. I copy the "tm4c_cmsis.h" header file from your git repo and add it to the project. I'm getting the "Pe 1696" error: "cannot open source file "core_cm4.h"". If I include the CMSIS core path for my preprosessor, then the error disappears but now the auto-complete feature for the struct-fields does not work.
The strange thing is that everything works smoothly when using your lesson-files. In this case, I don't need to specify the CMSIS core path and also the autocomplete feature works fine.
And I cannot find any project setting that are different for your project-files... Any clues ?
StateMachineCOM Dr. Semik may I ask when will you relsease the next brilliant one? :)
I get a page not found error when visiting www.statemachine.com/quickstart ??
Hi Miro！
Thank you so much for your tutorial, I benefit a lot from your video,
I have a question about the RCGC2 you use in this lesson which you replced the previous RCGCGPIO register, i checked the datasheet they have different offset which one is 0x108 and the other is 0x608, these two both seem to be used for the clock gating control for GPIO so what's the difference between both,thank you.
Yu Sun According to the datasheet, the RCGCGPIO is the recommended one for enabling clocks to the GPIO peripherals. The RCGC2 register is provided for backwards-compatibility only and has some side effects.
Anyway, while the lesson still shows the RCGC2 register, the actual code download for lesson17 (www.state-machine.com/quickstart/lesson17.zip ) uses the new register RCGCGPIO. I hope that this answers your question.
--MMS
I'm a little confused. suppose there is an instruction 0x2028 at the address 0x58, then why is it that at address 0x58 the instruction is stored like 0xf88d2028 and not 0x2028f88d ? Maybe this is a basic question but please help me clarify in brief.
Good morning Eng.Merosamic
from Where can i get tm4c_cmsis.h file?
The viewer "High Altitude Observer" posted the following question, which I can't find anymore:
"Sir, I have a question regarding this chapter 12. I am using the same tools (IAR EWARM + Tiva C board), but the header file "tm4c_cmsis.h" is nowhere to be found. I searched all the directories"
Here is my reply:
The header file "tm4c_cmsis.h" has quite a bit of history. It has been derived from "lm4f_cmsis.h", which was compliant with the first version of the CMSIS standard.
Since then CMSIS has evolved, and the name convention has changed. According to newer CMSIS this file should be called .h, where is the full name of the MCU (see www.keil.com/pack/doc/CMSIS/Core/html/_templates_pg.html ). Therefore the name of this file should be named "TM4C123GH6PM.h".
Now, if you search IAR directory, you will find the file "TM4C123GH6PM.h" in the folder IAR\ARM_KS_7.40\arm\inc\TexasInstruments. But that file is **incorrect** and you should not use it. As of IAR EWARM version 7.40, the file has incorrect setting for such critical stuff as __NVIC_PRIO_BITS (is 0, but should be 3), __MPU_PRESENT (is 0, but should be 1), __FPU_PRESENT (is 0, but should be 1), etc.
There is also another version of the file named "TM4C123GH6PM.h" distributed in TivaWare. That version is not compliant with CMSIS at all and I would not recommend it.
Finally, there are other versions of the "TM4C123GH6PM.h" header file distributed with other toolsets. The best one I've encountered is from the ARM-KEIL MDK (from the TM4C_DFP Software Pack). This version seems to be actually correct.
So, moving forward, I will probably adapt the "TM4C123GH6PM.h" header file from ARM-KEIL MDK.
--MMS
+Quantum Leaps, LLC Sir I am using TivaWare drivers and software files in code composer studio. But i want to change my device header file as per your suggestion. I have two questions.
1. How to get new file from keil software distributor (As per your suggestion).
2. If i replace new device file with my original device file(provided by TI) than will all other API's from driver library work or not?
+Chadresh Patel To my knowledge, TivaWare is NOT compatible with the CMSIS. Consequently, the CMSIS-compliant header file (such as TM4C123GH6PM.h) will NOT work with TivaWare. So, unfortunately, you need to choose, either you go with TivaWare or you go with CMSIS.
+Quantum Leaps, LLC I want to go with CMSIS. please guide me from where I can find device file. I have other doubt related to bare metal chip programming. How to know about functioning of peripherals? one method is to read datasheet from cover to cover and get knowledge about programming of proper registers sequentially. but I feel it will take lots of time. is there any tutorial for that? And once I know any peripheral in detail than I would like to write my own device driver(compliant with CMSIS). Is there any tutorial for that as well??
+Chadresh Patel If you want to go with the CMSIS, probably your best option is to go straight to the source, that is to ARM Ltd. ARM provides their own toolset through KEIL (a company that ARM Ltd. acquired). The ARM-KEIL toolset (called ARM-MDK) supports CMSIS and provides CMSIS-compatible driver libraries through the software "Packs". There is a free size-limited version of the toolset at www.keil.com/arm
Hi, I understand that in order to use CMSIS is better to install Keil so why this course is based on IAR instead?
Otherwise, where can be found the tm4c_cmsis.h file?
The tiva c comes with their own libraries and api for setting up gpio, timers, etc.,... do you recommend using your method of using gpio and adding code as you go along or use the tiva ware api functions?
I'm assuming its better the way you tuaght us is because you only add the code that you use and its also portable so it won't get all confusing with so many includes as I saw in the tivaware examples for everything they have using the ti compiler.
The TivaWare library that you are referring to predates the CMSIS specification, and consequently it uses its own ways to access the hardware. So, you need to decide to use TivaWare, you should not use CMSIS header files and the GPIO code presented in this course. I find CMSIS better for the purposes of teaching.
Does the lone DATA member of the GPIO structure refer to the configuration of GPIO Data bits in which all 8 GPIO bits are enabled? i.e. offset 0x3fc?
Also, can you please elaborate a bit more on the RESERVED1[ ] array member? I understand that it exists so the the remaining GPIO struct members align with the offsets indicated in the Datasheet, but why is there such a huge gap between GPIOAFSEL and GPIODR2R to begin with? Does the RESERVED1[ ] array member have any particular function?
+Aditya Kapoor The GPIO structure is explained in Lesson 7 (see ruclips.net/video/pQs8vp7JOSk/видео.html). From this lesson, you will see that the address offset (4*0xFF == 0x3FC) enables all 8-bits of the GPIO.
Regarding the large gap in addresses (RESERVED1[55] member), I really don't know why the chip designers at TI have decided to leave it. But remember, that no memory or other hardware resources are wasted here. The gap is simply created by a particular way of connecting the address lines. The 32-bit address space (4GB) of the ARM processor is so vast that a few hundred bytes of unused address space don't really matter.
--MMS
Great tutorial as all in this series!
I tried to reproduce the example with Keil MDKv5 using the current version of Keil.TM4C_DFP.1.1.0 CMSIS Pack (dated 23. March 2015).
In TM4C123GH6PM.h, GPIOF_AHB is a pointer to a GPIOA_Type structure where the first 256 elements are reserved and Read-only.
Therefore the bit-specific write method does not work as in the video.
Instead, the bit-band alias addresses of GPIOF_AHB->DATA bits must be used.
Do you have an explanation for what seems to be a restriction in this version of CMSIS?
Apparently there are multiple versions of the TM4C123GH6PM.h header file. The one included in ARM/Keil MDK does not take full advantage of the powerful GPIO addressing. (There is another one in the TivaWare, which is not even aware of CMSIS). I would highly recommend to use the header file included in the project downloads (from the companion web-page to this video course at www.state-machine.com/quickstart/ ). Also, you can find ther the corrected TM4C123GH6PM.h header file, see www.state-machine.com/quickstart/TM4C123GH6PM.h . -MMS
Hey QP, does anyone in the industry want you to program registers or do we as embedded engineers use libraries?
+Helios Fire Higher-level libraries and APIs (Application Programming Interfaces) hide the low-level register manipulation and are sometimes advantageous. But, ultimately every embedded programmer should understand the internal implementation of the libraries, because very often this is the only way to figure out exactly what the library is doing. Quite often, also, the use of low-level registers is actually clearer, and can be directly correlated to the Datasheet. Finally, and I mention this intentionally as last item, low-level register programming is faster and more efficient than calling library functions. While I don't recommend optimizing the code too early or at the expense of readability, the low-level register access is often the only way to achieve fast-enough implementation.
God!
In Keil with Armclang 6.21 the "_packed "identifier does not seem to work. Checking the docs I came across:
typedef struct {
uint8_t y;
uint16_t x;
} __attribute__((packed)) Point;
The armclang docs don't say why __packed doesn't work, but it does say this works too. For some reason the complier says it ignores it when it's straight after typedef, and someone on stackoverflow said it has to be after the right bracket for the complier not ignore it. I'm not sure why, but this worked for me.
@jorgis123 Thank you for pointing out how to pack a struct in armclang. Besides the syntax you provide, the "packed" attribute can be also provided right after the struct keyword like that (I find this option a bit more readable):
typedef struct __attribute__((packed)) {
uint8_t y;
uint16_t x;
} Point;
@@StateMachineCOM Ah, I see what I did wrong. I reversed the order like this, as I assumed similarity to the __packed syntax:
typedef __attribute__((packed)) struct
I agree your method is way more readable, but I misread the docs and didn't get it to work.
Thank you!
sir, when will be the next lesson?
I am always asking this question :-) I can not wait this long duration between the lessons
Hi Mr Samek or who's reading this! In minute 30:00 you start typing the SYSCTL structure members, but my IDE is only showing a scroll down list of the RESERVED members (which I see in the tm4c_cmsis.h file, are only the ones that are arrays). How can I enable selecting the other members, in this case, the RCGC2, GPIOHSCTL, etc? Thanks
Hi Mr Samek, I have the same issue, would be so nice, if you can reply the solutions.
Same issue
Hi Miro, I'm having a bit of an #include nightmare here. I think there's a bit of discrepancy between your tutorial and the 2019 version of IAR that I am currently using.
Initially, the preprocessor couldn't find TM4C123GH6PM.h, so I added an additional include path of IAR\arm\inc\TexasInstruments\
Then, the preprocessor couldn't find core_cm4.h, so I added an additional include path of IAR\arm\CMSIS\Include\
The next one really stumped me. It couldn't find system_TM4C123GH6PM.h and neither could I. I search the whole IAR\ directory and that file simply doesn't exist. Any tips here? Thanks.
I really don't see any problems with the latest IAR EWARM 8.32.2. The projects for all lessons build cleanly. Perhaps you have modified the projects and have broken something in the process (?) I would recommend to start fresh by simply downloading the projects from the companion page to this video course at: www.state-machine.com/quickstart/ --MMS
Ivan hu, are you using free version of IAR EWARM?... Is your problem reaolved now... Even I'm having same problem
How can I get all the cmsis support includes at once.? Right now adding all files one by one. (Great tutorial, really helpful. Enjoying it)
You don't need to add the individual CMSIS header files to the project! All you need to do is to add the CMSIS directory to the compiler include path. This is done in the "Options" dialog box, "C/C++ Compiler" category, Preprocessor tab. There you find the "Additional include directories (one per line):" box. --MMS
@@StateMachineCOM Thanks for helping out, Miro. Will do that!
Hi, thank you so much for this course. I have one problem: Using the TM4C123GH6PM I always get the error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)". I added "#define __FPU_PRESENT 1" in your "tm4c_cmsis.h" which works but leaves me a feeling of doing something that shouldn't be done... Is there a more "official" way?
Are you using the project downloaded from state-machine.com/quickstart ? These projects shouild be configured correctly and, as you can see in the video, they don't report such problems. Regarding the FPU, the TivaC123 is a Cortex-M4F (with FPU), but a software project can be configured not to use the FPU. I suspect that your problem is related to some incorrect selection of the device in the general settings. Apparently, the toolchain "thinks" that you have a device without the hardware FPU. Please check your project settings. --MMS
Thank you very much for your quick response. So I'll check my settings...!
Hello Sir,
thank you very much for the nice course. When I want to change from (Cortex-M4) to (Cortex_M0), I got error that (Cortex_M0) is not same as (Cortex_M!). Any help will be appreciable!
I can't reproduce the problem in IAR EWARM 9.10.2. What IDE/version are you using? --MMS
I'm not founding the CMSIS for the tm4c1294 MCU's. Do you know where can I find it?
Try to google for "tm4c1294 CMSIS header file". You should get some hits from the TI user community. Apparently many people are asking for it. --MMS
Is it possible to use CMSIS files in Code Limited version of IAR... I'm not able to add and use CMSIS files
Hello Mr. Samek, thank you very much for your nice course.
When I wanna compile, get this error. Could you please help me to solve it.
Fatal Error[Pe1696]: cannot open source file "core_cm4.h"
The file "core_cm4.h" is part of the CMSIS, which you need to download from the companion web-page (see www.state-machine.com/course/CMSIS.zip). You then need to unzip this into a directory at the same level as your lesson-12 project. --MMS
When I'm searching a particular byte in memory 1 view by an address using automatic search, it always behaves like there's no Little Endian format actually. But the values are still written in the right place. Is there some tricks should notice? This behaviour is too confusing. Looks like this behaviour is changes when I switch to different modes as two bytes etc.
The exact byte order in memory is clearly visible only in the 1-byte view. In 2-byte and 4-byte views the debugger shows you the values with the endianness already applied. For example, in a 1-byte memory view, you might see the following bytes 0x11, 0x22, 0x33, 0x44. The same bytes in the 4-byte view would show as 0x44332211 on a little-endian machine. (Just try it in the debugger because ARM Cortex-M is little-endian). On a big-endian machine, the same bytes in the 4-byte view would show as 0x11223344. This goes back to our human notation, which is "big-endian" because we start with the most significant bytes first. This seems to go back to the Arabic numerical notation we adapted in our Western left-to-right writing. (The original Arabic notation is little-endian because Arabic writing goes right-to-left.) --MMS
0x500-0x420 = 0xE0 = 224 in decimal. This is the offset between GPIOAFSEL AND GPIODR2R. Could you explain me RESERVED1 array is only 220 byte? Thank you
I have exactly tha same question.
For anyone still wondering:
GPIOAFSEL is a 4-byte register starting at offset 0x420, ending at 0x423. Then, starting at offset 0x424, there is an unused reserved block until register GPIODR2R starting at offset 0x500. 0x500 - 0x424 = 0xDC = 220 = 55 * 4, which is why RESERVED1 is an array of 55 4-byte elements.
In IAR Arm 8.22.2, the compiler was complaining about "core_cm4.h was not found". I had to go to Project options -> General Options -> Library Configuration and enable the checkbox "Use CMSIS".Then the error got away...Still I couldn't manage to make IAR's autocomplete work.
The projects accompanying this video course are designed to be self-contained and not to rely on the compiler-provided libraries. Specifically to CMSIS, it is provided in the separate download with lesson 19 (see the CMSIS download at www.state-machine.com/quickstart/ ). Most likely the IAR version of the CMSIS will work as well, but there could be some version discrepancies. Therefore it is recommended that you use the software downloads that have been tested with the projects. I hope this makes sense to you. --MMS
Thank you James. I had the same problem and now my code compiles, simulates and runs on the board smoothly. I personally prefer to write the code myself along with the lesson so I can have a feeling of each step, plus I understand better if I look and do step by step to be aware of my own mistakes and correct them.
Hi, Does anybody know why IAR 7.80.3 editor does not show structure members when typing?
go to tools, options, debugger, check "automatically choose all instances"
I think you mean autocomplete, which can be shown by typing : cntrl + space
Thanku Miro for such great lectures. In this lesson, we see about the struct size. So basically, the struct is 4B, so that the processor can easily work with aligned data which leads to better code. Am I right??
Normally for most C structs you should not worry about the memory alignment, because the compiler will add any necessary padding both within the struct and at the end of struct. The concern for optimal size and alignment comes up only for structs that are used a lot, such as events (see later lessons about "Event-Driven Programming"). But it is perhaps a good habit to order your struct members from the biggest to the smallest size. That way you minimize the wasteful padding within the struct. I hope this makes sense to you. --MMS
when i do the changes for the leds i get
Error[Pe142]: expression must have pointer-to-object type
for this line of code:
GPIOF_AHB->DATA[LED_BLUE] = LED_BLUE;
all he others that i renamed as in the cmsis document are fine.
I'm using the header file from TM4C_DFP Software Pack
Please download the lesson12 project from the companion page to this course (www.state-machine.com/quickstart ). If you look at this code, the access to the GPIOF data register is coded as follows: GPIOF_HS->DATA_Bits[LED_RED] = LED_RED; I'm not sure why your code is different.
Its different because i used "TM4C123GH6PM.h" header from ARM-KEIL MDK (from the TM4C_DFP Software Pack) CMSIS and not the one that you have in your project zip file.
In the new header file there isn't a "data_bits" array anymore of 256.
The new file doesn't have GPIOF_HS like in yours. Its has GPIOF_AHB
I'll just use you lesson zip to continue your course frmo now on.
Hello Dr. Samik,
Thanks again for your nice courses.
I also have another issue, When I wanna compile, get this error. Could you please help me to solve it.
Fatal Error[Pe1696]: cannot open source file "core_cm4.h"
In the project that I created the path that opens the "core_cm4.h" file is different than path of the lessson 12 from your website, is there any way to chnage the default path?
path of the project define by me: C:\Program Files\IAR Systems\Embedded Workbench 9.0_2\arm\src\flashloader\NXP\FlashQN9080\chip_qn908x\cmsis\core_cm4.h
path for the course of your website: C:\Program Files\IAR Systems\Embedded Workbench 9.0_2\arm\CMSIS\Core\Include\core_cm4.h
In IAR EWAR you can use the CMSIS library that ships with the toolchain (so you don't need to include your own CMSIS). To select CMSIS in IAR, open the Project Options dialog box ( menu Project -> Options...). Inside there choose Category: "General Options" on the left. On the right, go to the "Library Configuration" tab. CMIS configuration is in the lower-right corner. Please check the "Use CMSIS" box. --MMS
Hey Miro, great tutorials but I didn't understand one thing. p1.y is 1 byte and p1.y = 0xAAU shows the value stored in p1.y is 0xAA in the watch window. Shouldn't it be 0xAU since the most significant nibble (0xA) will be truncated ? Is it because ARM is little endian ?
Why do you think that a nibble (i.e. 4 bits out of 8 bits in a byte) would be truncated? Why do you think endianness of the CPU would lead to data truncation? Why should *any* data be lost, for that matter? I mean, a struct in C is there to group data together, which applies equally to a packed structure. A struct would be rather unusable if it were to lose data under any circumstances... --MMS
@@StateMachineCOM Damn, I'm a dumbass. That U at the end of 0xAAU meant unsigned, right ? I thought it was a part of hex. SMH.
hello what this means ? I think some link is not good , but I don't know what
Fatal Error[Pe1696]: cannot open source file "core_cm4.h"
Please google for "Error[Pe1696]". One link that I"v found is: e2e.ti.com/support/wireless_connectivity/f/155/t/110195.aspx
StateMachineCOM thx. I know I'm not in position to ask but a tutorial in which we can see an example for how to read from adc and how to generate a pwm or a Uart implementation. Those subjects are very important. Thanks again !
How to download/ access "tm4c_cmsis.h" header file?
Please visit: state-machine.com/quickstart advertised in every video as well as in every video description.
Hello sir, great lectures. I already in embedded world for more than 2 years yet, I learn a lot from these. I highly appreciate your willingness to share your knowledges.
But, I have one question that I just thinking about it recently.
What will be the differences between these two line below ?
uint8_t x = 0x00u;
uint8_t y = 0x00;
I remember in your previous video that the precision of computation is not depend on the left-hand side of the assignment.
Then, what will be the bad effect, If I keep using the second line of the above assignment ? Will it do any harm ?
Thank you
Both assignment statements will work just fine, but both will actually end up in an implicit type conversion. The first assignment (x = 0x00u) will convert from unsigned int (0x00u) to uint8_t. The second assignment (y = 0x00) will additionally involve the signed-to-unsigned conversion. The compilers will accept all this, but static analysis tools might flag it as a warning (depending on how strict you set them). If you want to be pedantic, you could say: x = (uin8_t)0x00. Because you apply an explicit cast here, it does not matter if you cast from 0x00u or 0x00.
Thank you very much for sparing your time for this explanation. now It looks clearer.
Hello,
First, let me say thank YOu for this tutorial series, itis the best I've ever seen!
Why I'm writing: I have 2 problems with IAR itself.
First: When I start type: "w." then it doesn't show me the elements of w struct. However the program runs well, so I think this is just matter of setting up IAR.
Second: When I was translating the code, IAR couldn'tfind the elements of \IAR Systems\Embedded Workbench 7.5\arm\CMSIS\Include
However it was searching in C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.5\arm\inc and in the project file directory. After I copied the content of CMSIS\INclude to the project folder, it was running well.
Can You please help me to find the settings?
Thank You very much!
Regards: A.G.
It seems that your IAR EWAR might have some installation issues. Perhaps the easiest remedy is to uninstall it (from Programs and Features Windows menu) and install is from scratch. --MMS
Thank You for the help. I'm going to do it!
And it works well!! :) Thank You for the support!
I'm having issues with the pointers. From what I learned don;t you need to give the offset to the base and the offset of GPIO_PORTF_AHB_DIR_R(which is 0x40025000(base) + 0x400(offset)) ? How does the compiler know that GPIO_PORTF->DIR = 0x40025400 when DIR doesn't have anything in it. I see 0x40025000 -> ?? = (LED_RED | LED_BLUE)
+Helios Fire I'm not sure that I understand your question. But to the compiler the DIR member of the GPIOA_Type structure is just an offset (0x400 in this case). The compiler does not "know" what is or will be at this offset. But the compiler can count the sizes of all structure members from the beginning. So, if you say GPIOF_AHB->DIR, it knows that you are talking about address (0x4005D000 + 0x400). That's all there is to it.
But how is the DIR = 0x400 when we didn't define it? I understand we had a typedef of GPIOA_Type but like pp->x, shouldn't DIR be empty like the x pp is pointing to?
+Helios Fire I guess that your problem is that you see a pointer only as an address. This is not the full picture. A pointer is an address PLUS the type information. So, the pointer named GPIOF_AHB of type "GPIO_Type*" (note the star) tells the compiler that the chunk of memory at the address contained by the pointer should be treated as the GPIO_Type structure. So, now the compiler knows that the structure member DIR is offset by 0x400 bytes from the address contained in the pointer. I hope that is starts to clarify what pointers are.
I'm beginning to understand better. The last problem I have is how does the compiler know that the structure member DIR is offset by 0x400 bytes from the address contained in the pointer?
+Helios Fire The compiler knows the definition of the GPIO_Type structure. There, the compiler can see two members: uint32_t DATA_Bits[255] and uint32_t DATA before the DIR member. So, the compiler calculates the space needed by those two members, which is 4*255 + 4 = 1024 = 0x400 (the factor 4 is sizeof(uint32_t)). Therefore the offset of DIR is 0x400 from the beginning of the structure.
21:25
Nice lesson thank you! Does Tiva C hasSPL (standard peripheral library ) like STM32? (www.rowleydownload.co.uk/arm/packages/index.htm?www.rowleydownload.co.uk/arm/packages/stm32f10x_stdperiph_lib_updates.htm )
Texas Instruments supports the Tiva microncontrollers with the extenisve "TivaWare" software library (just google for "TivaWare"). I would guess that "TivaWare" is similar to "STM32 SPL". Other vendors of ARM-Cortex-M micros (such as Atmel, Freescale, NXP, Cypress, etc.) also seem to provide increasingly complete software support. This competition is good for us developers. That's one of the main reasons why this course uses Cortex-M as the teaching platform.
--MMS