#7 Arrays and Pointer Arithmetic

Embedded Systems Programming Lesson-7 introduces you to arrays and basic pointer arithmetic in C. You will learn how to apply these concepts to take advantage of the more advanced features of the Stellaris GPIO DATA registers, which answers some questions asked in the comments to this video course posted on KZbin.
The lesson starts with explaining why the traditional read-modify-write sequence that you used in the previous lessons can be problematic when you add interrupts in the future.
Next, you see how this problem can be solved in hardware by using the address bits as a mask for updating the GPIO DATA bits. You get an understanding that this solution
requires many GPIO DATA registers, and you find out why the DATA register with the offset 0x3FC is so special.
Next, you try to use a brute-force solution from lesson-3 to synthesize the GPIO DATA register addresses manually and you verify that it works, although is not very elegant.
Next, you learn about arrays in C and their equivalence with pointers.
Next, you see how to index into an array and you learn about the equivalence between array indexing and pointer arithmetic.
Next, you verify the equivalence of the three approaches: address arithmetic, pointer arithmetic, and array indexing when it comes to the generated machine code.
You learn about the difference between address arithmetic and pointer arithmetic.
Finally, you learn about the two peripheral buses: APB and AHB in the LM4F microcontroller and you see how to switch the code to use the faster AHB.
The next lesson will be devoted to functions in C. Stay tuned...
------
Resources:
Companion web page for this video course:
www.state-mach...
GitHub repository for projects for this video course:
github.com/Qua...
KZbin playlist of the course:
• Modern Embedded System...

[@ljgmdad]

Very well done. The pace of progression through subject material is just right, and the topics have been chosen intelligently. And the instructor knows his stuff and possesses the rare ability to explain it clearly and succinctly. Looking forward to the upcoming lessons and I hope the appear soon. I'm subscribed!

[@c1tywi]

These videos are pure gold. I have yet to find something remotely as useful for properly learning embedded coding. Thank you Miro!

[@suman2806]

I have been coding embedded systems for a year without these basic knowledge. I always wonder how the libraries address the register finally i got to know how.Thank you so much for taking this initiative you are the best.

[@StateMachineCOM]

The STM32 Discovery board is also an excellent choice for learning embedded programming and ARM Cortex-M microcontrollers in particular.

[@yashesvi-raina]

This is a challenging and interesting lesson! after all not every course is a passive learning kind!

[@minhduyto37]

Thank you very much for such a great video! I finally understand the use of registers in setting the GPIO that I want.

[@neostack]

Miro, these tutorials are simply excellent. Well done and thank you for creating them. Cant wait for your future uploads. I have C experience but am new to microcontrollers. I've been following your examples on a Teensy 3.0 and using Linux, and it has taught me SO much! I love the fact that you analyse the arm instructions. Perfect!

[@aliitastan]

I appreciate your efforts sir, these videos help me so much to understand embedded systems. I started my career with the aid of your videos and I am really grateful.

[@zDoubleE23]

All I can say is holy sh*t this series is so good. I’m definitely going to buy your book!

[@StateMachineCOM]

Yes, absolutely, more lessons are coming up. I don't have an official syllabus, but my goal is to get as quickly as possible to interrupts, context switching, RTOS, and other such typically embedded subjects. But before I get there, I need to talk about functions for at least two lessons. And then, I probably need a lesson about the startup code, because this is how interrupt service routines (ISRs) are hooked up on Cortex-M. Anyway, the next lesson about functions is "in the works".

[@StateMachineCOM]

Arduino is by design a "rapid prototyping" platform. You can quickly build something that works and you are shielded from the complexities of the microcontroller. But Arduino (including the DUE board) is not a good platform for this type of course, because it does not provide the hardware debugger. In other words, you cannot "see" inside the microcontroller, you cannot single-step through the machine code, you cannot play with the registers, etc.

[@blackandrew00]

Miro, I really appreciate your efforts! Your lessons are very useful. I have been following all your lessons, but I programmed into a Freescale FRDM-KL25Z (Cortex M0+)... I had to play with it a little, but everything what you teached are working so. Thanks a lot, I am looking forward the next lessons, especially interrupts... thanks

[@sandpaper-egg-2020]

I recently got hired by a company for a mixed programming position. I had NO experience in embedded systems programming whatsoever and was struggling to catch up. This course single-handedly brought me up to speed with quality and clarity unrivaled by any other KZbin training course (and I have watched quite a few). If you have just found this course, keep going. You have come to the right place. The fact that Miro Samek has posted this course for free is the height of scholastic generosity. I have learned more from this course than any computer-science college class.

[@KananDethin]

Finally I understand the basic concepts about memory usage, At least sometimes :).

[@SergejsNazarovs]

Wonderful course! The unique feature of these lectures is that the machine code is discussed in detail. The information provided in the lessons is very useful. I look forward to the next ones! By the way, what do you think about STM32 microcontrolers and the Discovery board?

[@leohuang990]

Great to show a concrete reason (interrupts) for atomic RMWs. This MCU (its GPIO) implements bit-banding in quite an interesting way. Many MCUs simply map each bit in the bit-band region to a word in the alias region, w/o enumerating all possible bit-combinations. Thank you so much for introducing the AHB, the SYSCTL register to enable the AHB for GPIO, and the AHB aperture.

[@StateMachineCOM]

Good observation, but it's perhaps worth pointing out that the TivaC GPIO design goes beyond bit-banding. In the traditional bit-banding each bit has its own unique address. In the TivaC GPIO each bit *combination* has its own unique address. --MMS

[@leohuang990]

@@StateMachineCOM Great thanks for the information. Now I see this design is by Tiva-C. Your lectures are very helpful.

[@ahsanbaig74]

it is really great to see the WORLDS DEFINITIONS OF COMPUTER, with real PRACTICAL MEANINGS, THAT HUMANS CAN really UNDERSTAND............. BUT NO BODAY HAS DONE THIS BEFORE............. I am not a COMPUTER GUY BUT i am enjoying it every moment.......

[@AliNormukhamedov]

very nice !!! Thank you so much !! Best on youtube !

[@04mfjoyce]

Love these videos. Thank you for posting them!

[@StateMachineCOM]

The Freedom board is very nice and I'm glad to hear that you can also use it for this course. The generic ARM code should work almost identically, although Cortex-M0+ has a smaller instruction set than Cortex-M4F. Obviously, the code specific to the peripherals won't work and needs to be adapted. --Miro

[@stefanmanoharan]

Thank you for your fantastic explanations of embedded systems- almost 10 years later, it is still so relevant. I really appreciate your efforts. I have a question: in 3:47, when you're explaining the need for atomic writes, you mentioned that an interrupt can occur within the read-modify-write sequence, and the data to be written would be lost. Don't we face the same problem if we use the atomic write, and the ISR is called between the MOVS and STR command in 7:23? EDIT: Additionally, is this method of addressing ubiquitous in all Cortex M architectures? I'm using a SAMD21 chip with Cortex M0, and separate registers are provided for setting, clearing, and toggling pins, without having to read-modify-write the Data register. Additionally, there is an optional Pin Mask register they provide for independently controlling certain pins. Are these an analogous manifestation of the addressing format you're mentioning, or is it a separate concept altogether which happen to result in atomic writes?

[@StateMachineCOM]

No, pure write operations (like the one shown at 7:23) do not suffer from the race condition (race conditions are explained in lesson #20). The pure write will always write the same thing into the destination address regardless if it has been interrupted or not. But of course, if the destination address is *shared* with interrupts (or RTOS tasks), you could have a problem. But the write operation itself is OK. --MMS

[@StateMachineCOM]

Regarding the hardware design of GPIO to avoid the read-modify-write sequence: yes, you are right. I don't exactly know the GPIO hardware in the SAMD MCUs, but if they have separate "set" and "clear" registers, then they should exactly decouple the individual bits of GPIO. In other words, this would be a design that is safe for concurrency. BTW, the "set" and "clear" register design is used in the NVIC (present in all ARM Cortex-M), where you can "pend" and "unpend" a given interrupt with a pure-write that does not disturb other bits in the NVIC. --MMS --MMS

[@stefanmanoharan]

@@StateMachineCOM Thank you for the explanation! This clarified my question.

[@StateMachineCOM]

Lesson 8 has been published last night. Enjoy!

[@mengnan24]

Thank you for the great stuff! Question: is GPIO_PORTF_DATA_BITS_R[LED_RED] refers to the bit 0 on GPIO_PORTF_DATA_R and is GPIO_PORTF_DATA_R a 8-bit long register? Does "GPIO_PORTF_DATA_BITS_R[BLUE_RED] = 1" turn on the BLUE LED? Thank you!

[@StateMachineCOM]

+mengnan24 The LED_RED macro is defined at the top of main.c. It apparently references bit 1 (#define LED_RED (1U

[@muhammed_genco]

​@@StateMachineCOM I think you meant by alternatively this: "GPIO_PORTF_DATA_BITS_R[BLUE_LED] = 0x04U"

[@charankadimi5531]

Awesome ❤❤

[@stargategoku]

thanks a lot for posting this video.

[@dongolahmed]

you r the man ! ... your lessons are awesome

[@doctorrs5317]

Very nice tutorial. Thanks

[@quaternion-pi]

Brilliant and understandable! Thanks!

[@akt6775]

excellent tutorials,,,,,,,,,,,,,,, thanks for making

[@dyutimoybiswas71]

4:14 -- I want to learn more about this layout. Where can I find more?

[@KananDethin]

Thank you so much.

[@GEISTIFT]

struggling to understand the "GPIO_PORTF_AHB_DATA_BITS_R[R_LED] = R_LED;" part so GPIO_PORTF_AHB_DATA_BITS_R is an array we access a specific bit through array index [R_LED] - then we set the bit to R_LED? but if i add them up, the address isn't the same as using "GPIO_PORTF_AHB_DATA_R |= R_LED;" what am i missing here?

[@StateMachineCOM]

The GPIO_PORTF_AHB_DATA_­BITS_R[] array is not for the individual bits. It goes further than this. The GPIO_PORTF_AHB_DATA_­BITS_R[] array has an element for every possible **combination** of 8 bits. Therefore you have 256 such elements in this array. If it was for the individual bits only, you would have only 8 elements in the array. --MMS

[@GEISTIFT]

Quantum Leaps, LLC thank you Is there somewhere I can find more information on this?

[@StateMachineCOM]

All such things are described in the datasheet for the MCU, which you can get from TI (just google for your TM4C123GH6PM). Alternatively, the datasheet is available on the companion page for this video course at state-machine.com/quickstart/. Getting used to working with datasheets is an important skill for an embedded software engineer. --MMS

[@santhoshvai]

awesome lesson !

[@nemonobody9406]

Thank you for your lesson Mr. Miro. Can you explain to me why *((unsigned long volatile *)(0x40025000 + (LED_RED

[@nemonobody9406]

In detail, pointer to (GPIOF_BASE + (LED_RED

[@StateMachineCOM]

@@nemonobody9406 There is a big difference between a raw address and a pointer in C. Raw address, like 0x40025000, is just a number. In contrast, (unsigned *)0x40025000 is a pointer with a specific *type* . And in C there is a big difference between (address + offset1) and (pointer + offset2) because 'offset1' is different than 'offset2'. The 'unsigned' type happens to span 4 raw addresses. Therefore in C, offset1 is equivalent to offset2*4. Please think about it and experiment with the debugger. The understanding of the difference is *critical* for a proper understanding of pointers. --MMS

[@nemonobody9406]

@@StateMachineCOM Thank you very much! It helps me a lot

[@lemon6521]

I'm confused. We write to the address LED_RED in the data registers, but the value we write also needs to be LED_RED? It feels like I should assume that I would also write LED_BLUE to address LED_BLUE if I wanted to, but why should that be the case? If I'm only controlling the LED_BLUE bit, then it seems I should just write a 1 to it, not a 10 or 100. If I'm not just controlling the LED_BLUE bit, it seems like it doesn't matter if I go to the LED_BLUE address or the LED_RED or LED_GREEN one, I'll control the LED_BLUE bit just as easily regardless.

[@trangiahung1992]

awesome tutorial. Please make one more lesson to compare two bus method AHB and APB. Why is AHB faster than AHP and its application as I see in video with DMA and EEPROM.

[@StateMachineCOM]

I'm not sure that there is too much to show from the software perspective. The documentation from TI says that AHB is faster (possibly clocked faster) and the APB is only for backwards compatibility. As a software engineer, you simply accept such information from the hardware designers. But one perhaps interesting lesson would be to show how to use software to assist in measuring timing with an oscilloscope. I will make a note for such a lesson. --MMS

[@doctorrs5317]

@@StateMachineCOM The AHB is a pipelined, burst mode bus, thus us faster. Pipelined here means it processes address phase of one transaction, as it services the data phase of another at the same time.

[@ronilousumile7479]

Hello sir miro. I would like to clarify, what do you mean by we "don't need to scale the offset of the size of the element". So it means that in pointer arithmetic the LED_R which is equivalent to 0010 which is 2 in decimal, will it be equal to 1 in pointer arithmetic and in indexing no bitwise sihifting needed?

[@ehsanillo]

Hi Miro.I wonder if AHB and APB are part of ARM core design? I mean all other cortex M MCUs, for example, STM32F3, use the same architecture?

[@StateMachineCOM]

I am not a hardware designer, but afaik the AHB and APB are generic interface specifications applicable to all sorts of chips. The designers of the TivaC MCUs (actually, the original designers at LuminaryMicro, later acquired by TI) decided to use these buses in their chip to connect peripherals to the CPU. Other chip manufacturers, like ST, probably used something else. The bottom line is that the peripherals and internal interfaces is exactly where the chips from different vendors differ. They all use identical cores (ARM Cortex-M), but they compete on peripherals. I hope this makes sense. --MMS

[@mmarusic66]

If someone use stm32f4 discovery board, for performing atomic bitwise handling you can use GPIOx_BSRR register instead GPIOx_ODR register.

[@sabeethan]

Hi Miro, your courses are excellent and helps me understand programming of ARM processors in depth. I have a small doubt in this lesson though. When you reset the LED_RED using array indexing at 11:34, you assign it to zero. I was a little confused as to why you do not use ~LED_RED. i.e, should the code to reset the LED not be: GPIO_PORTF_DATA_BITS_R[LED_RED] = ~LED_RED;

[@StateMachineCOM]

Sabeethan: the GPIO bits are simply not wired directly to the bits, so you don't set and clear them with the usual binary operations of the form GPIO |= BIT and GPIO &= ~BIT. Instead the hardware guys at TI (actually at Luminary Micro, who designed the GPIO) have used the address lines in a more creative way to allow you direct and atomic access to every *bit combination*, not just to individual bits. This lesson attempts to actually explain all this. Especially, you might want to watch again the segment from 4:11, where I explain the conceptual schematics of the GPIO.

[@sabeethan]

Quantum Leaps, LLC Thank you Miro :)..

[@hakuhakuji]

It took me a while to understand that changing single bits by using the offset made from the same bits has nothing to do with bit-binding in this case

[@gudimetlakowshik3617]

Can you please interface any real time sensors??..like ultrasonic sound sensors or any sensors with this board??...cauz i would like to know how to access the GPIO pins in order to get the data and process them with this board....

[@celilylmaz4426]

I think this modifying individual bits concept is known as bit banding and applicable for specific memory segments.

[@StateMachineCOM]

This lesson does NOT use "bit-banding" (please google for the term), although the GPIO design in TivaC MCU is somewhat similar in the general idea. So, while the described GPIO design is specific only to TivaC, bit-banding is the feature supported by all ARM Cortex-M3 and higher CPUs. Bit-banding is a way of aliasing memory regions. Specifically, each bit in a region of memory (the Bit-band Region) is mapped to an entire word in a second memory region (the Bit-band Alias Region). That way reads/writes to the Bit-band Alias Region end up reading/writing a single bit in the Bit-band Region. --MMS

[@celilylmaz4426]

@@StateMachineCOM Yes sir, thanks for the explanation.

[@muhammedebeid8723]

I have a question, there are four disassembly modes in the IAR, what should i use? and does it make any difference if i debug my code with real board?

[@Strogden1]

At 10:44, Miro said that the left-shift LED_RED value was due to 4-byte size of the address. I thought that shift was because of not using the two lowest-order address bits (A0 and A1). No?

[@StateMachineCOM]

The narration at 10:44 is actually correct. It says that the GPIO registers are 4-byte wide and NOT that the size of an address is 4-bytes. All addresses in ARM Cortex-M are 4-byte size, so this is not relevant. Important is that the addressed entities are 4-byte words, which means that addresses must be divisible by 4. This is equivalent to saying that the two LSBs in the address must be zero (A0==0 and A1==0). --MMS

[@Strogden1]

@@StateMachineCOM oh, now I get it. Thank you!

[@ammar217]

Nice explanation...

[@vahidam61]

Hi Miro, hope you are doing well! 1) Do I understand truly that "Tiva™ C Series MCUs PinMux Utility " can be used to configure Tiva pins graphically ()and then it generates the corresponding C code)? 2) If so, do you know how to download it (as it seems that there is no file here: www.ti.com/tool/tm4c_pinmux)? 3) I haven't done comunication between Microcontroller and PC. would you please give me some hints to start (may be introduction of some sources, examples, etc)? Many thanks in advance,

[@xy7914]

What is exactly the thing that makes : 1) the instruction "GPIO_PORTF_DATA_R |= LED_RED" ASSEMBLED with 3 instructions and 2) the instruction "*((unsigned long volatile *)(0x40025000 + (LED_RED

[@Chataou]

Hello, what is the function of .W in the instruction "ORR.W"?

[@jamesmurphy5499]

I was really enjoying this course with ease until I got to this lesson and I am lost completely. I am stuck here because I don't understand the hardware of this board and how it's connected to the registers

[@mattl3397]

Great stuff. quick question. In the line of code GPIO_PORTF_AHB_DATA_BITS_R[LED_BLUE] = LED_BLUE; why do you have to set it to LED_BLUE(4) to turn on the LED why can't it just be 1 or some other value.

[@mattl3397]

Randy Franky Not sure if this is the right answer but looking back at the video my understanding now is that it is only looking at the LED_BLUE bit in this case 4 or 0100. so values such as 1,2,3 in decimal will have no effect on it but values such as 4,5,6 will turn on the blue LED because the 3 bit value is set to 1.

[@qiangxiao3389]

Matt L GPIO_PORTF_AHB_DATA_BITS_R[LED_BLUE] equal to 0x40025010, and map to address lines are 0b0100 0000 0000 0010 0101 0000 0001 0000. you will see the address line of LED_BLUE is 1(note that the two lowest-order address lines A0 and A1 are not used, because the hardware requires all addresses to be divisible by 4.). so, the address line LED_BLUE is selected, and now we should give data to data lines. at 4:24 of video, according to "The bit can be changed only when the connected address line is 1, otherwise the bit is unaffected, regardless of the value of the attached data line." you should give the LED_BLUE(which is 0b100 in binary, just the second bit affect the output ) to data lines. forgive me for my poor Eglish (come from China).

[@ayanghosh96]

Basically,for a simple mC,such as 8051,for eg. Port 0, has only one specific address and that's that.you can write/read only to this one address. But in this case, For this entire port, There isnt only one specific address to this particular port, rather 2^32 unique addreses refering to this single port, i.eEVERY POSSIBLE COMBINATION of GPIO(a port) bits would have its own UNIQUE UNIQUE ADDRESS. So depending on which address u select, certain bits will be masked/unmasked.So even if u write logical high to a certain masked bit,iT WONT MATTER, BUT ANOTHER ADDRESS PERTAINING TO THE SAME PORT MIGHT. Am i right somewhat?

[@StateMachineCOM]

The explanation of the GPIO design in the TivaC MCU is almost correct, except that there are 2^8 unique addresses for each GPIO port (for 8 bit combinations). To really appreciate the advantages of this GPIO design, please watch Lesson 20 (kzbin.info/www/bejne/aZnEaGWPbdWsepY ), where you will see how it helps you avoid race conditions.

[@Catalingeorgedum]

Thanks!

[@gauravminocha9335]

At 11:10, aren't you doing (1U

[@StateMachineCOM]

+Gaurav Minocha If you mean the index into the GPIO_PORTF_DATA_BITS_R[] array, then NO, the left-shift by 2 is not necessary. This is because the array itself is declared as uint32_t, which is a 4-byte quantity. Therefore the left-shift happens implicitly to reach the right array element. I suppose a similar question was already asked and answered for this particular video.

[@muxx9992]

The array is { 0x40025000, 0x40025004, 0x40025008, ... , 0x400253FC }, and the third element is exactly 0x40025008, so yes, the expressions are equivalent. The elements differ by 4 bits because the array contains consecutive addresses of 32-bit long registers.

[@janghalib2078]

Thank you so much. I spent hours trying to figure this out.

[@tp8600]

@@muxx9992 thanks a lot! this was really really confusing me!

[@airsubzero]

@@muxx9992 That was much of help! thank you!

[@nagahg]

At 11:13, I'm having difficulty understanding the pointer arithmetic, Can you kindly explain in detail?

[@StateMachineCOM]

The GPIO addressing in TivaC is quite advanced. I used it to illustrate the concept of arrays in C, but perhaps it is too complex for the very first introduction to the subject. --MMS

[@nawaryoussef]

I was continuing with you and all the lesson worked fine. However, at some point I downloaded lesson 7 from your blog and tried to make it work, but I couldn't. I am getting errors because of the macros used for bit-wise operations like: SYSCTL_RCGCGPIO_R. I am using Tiva board withTM4C123GH6PM, so I downloaded and replaced the old one with the header file corresponding to my board, also I changed the "Device" in "Options", but still getting same error. Any idea, it could be stupid mistake somewhere, but if you have any idea I appreciate it. Thanks

[@bnoden432]

Use the same header file as in the video. I'm using the same board as you and mine worked fine. I copied the header file from users.ece.utexas.edu/~valvano/Volume1/lm4f120h5qr.h

[@nishvarma8274]

Hi Miro! even after indexing, the compiler is using the same read and write method as I noticed in the disassembly. GPIO_PORTF_DATA_R |= LED_RED; and GPIO_PORTF_DATA_BITS_R[LED_RED] = LED_RED; are following the same read and write operation. They both have LDR.N and STR in my compiler disassembly. While on the other hand your disassembly shows just STR for the indexed one. Am i doing something wrong?

[@StateMachineCOM]

The discrepancies between your disassembly and what is shown in the video are most likely caused by the different levels of optimization used. Specifically, the additional LDR instructions are there to put the right information into the registers. At higher levels of optimization the compiler might keep the information in the registers already to avoid re-loading the registers via costly LDR instructions. In that case you won't see as many LDRs. But at lower levels of optimization, the compiler just generates LDRs to load the data every time. This seems to be your case. --MMS

[@preetiduraipandian2467]

What would we have to do turn On Blue and Red LED at the same time? What would be the array index for GPIO_PORTF_AHB_DATA_BITS_R for that?

[@StateMachineCOM]

The following line of code will turn both Red and Blue LEDs on: GPIOF_AHB->DATA_Bits[LED_RED | BLUE_LED] = LED_RED | BLUE_LED; --MMS

[@preetiduraipandian2467]

@@StateMachineCOM Thank You !

[@evenardo]

GPIO_.........._R[LED_BLUE] |=LED_BLUE |= will be safe , and = will be clear other bits .

[@HeliosFire9ll]

Hey QP, is there ever a time we'd choose AHB over APB? And just to make sure, when I tried to use APB and AHB at the same time it wouldn't work. Do you have to decide whether to use APB and AHB or can you use both at the same time?

[@StateMachineCOM]

+Helios Fire I'm not aware of any situation where the older APB would be superior to the newer AHB, so I would always recommend AHB. The older APB is only still there for backwards-compatibility with existing code, which these processors still need to run. Regarding compatibility between APB and AHB, they are mutually exclusive meaning that you need to choose and then consistently use one or the other, but not both at the same time. The datasheet it very clear about it, so no wonder that your attempt to mix AHB and APB has failed.

[@HeliosFire9ll]

Thanks! I just wanted to make sure

[@oz4232]

i read somwhere but dont remember, it says for power saving aim, APB is selectable over AHB

[@janghalib2078]

How is GPIO_PORTE_DATA_BITS_R[LED_RED] equal to 40025008 ?

[@eduardosepulveda2747]

GPIO_PORTE_DATA_BITS_R = (volatile unsigned long *) (Pointer to 4 bytes data) GPIO_PORTE_DATA_BITS_R = 40025000 (direction) LED_RED = 2 GPIO_PORTE_DATA_BITS_R[0] = 40025000 (from 0 to 3 -> 4 bytes) GPIO_PORTE_DATA_BITS_R[1] = 40025000 + 4 = 40025004 (from 4 to 7 -> 4 bytes) GPIO_PORTE_DATA_BITS_R[2] = 40025000 + 8 = 40025008 (from 8 to 11 -> 4 bytes)

[@janghalib2078]

Thank you

[@inanisneminem]

@@eduardosepulveda2747 how is 40025000 to 40025003 equal to 4 bytes? isn't it only equal to 2 bytes since those addresses are in hex? each digit of that address is 4 bits (1/2 byte) right? Sorry, I'm really confused

[@eduardosepulveda2747]

@@inanisneminem Please don't apologize, asking should never be a problem . unsigned long = 32 bits = 4 bytes Every address in memory refers to a byte (8 bits) . 40025000 -> 1 byte 40025001 -> 1 byte 40025002 -> 1 byte 40025003 -> 1 byte In a array of unsigned longs every position of the array refers to a single "unsigned long" (32bits/4 bytes) Position [0] of array of refers to direction 40025000 Position [1] of array of refers to direction 40025004 So, position [1] of array refers to 4 bytes after previous direction, because previous direction should refer to 4 bytes data (unsigned long) we have to leave 4 bytes between 2 consecutive positions of a array of "unsigned longs". Please keep asking, keep learning, keep fighting ;)

[@inanisneminem]

@@eduardosepulveda2747 Thanks for your detailed reply! I got it now!

[@bbogdanmircea]

I tried to play with the code for Lesson7, I added a #define USE_AHB and based on it either used the AHB or the APB registers, but when I execute the debugger doesn't go instruction by instruction like you are showing. What am I doing wrong?

[@StateMachineCOM]

To step through the disassembly code one instruction at a time, you need to *click* on the disassembly window. Otherwise, if you are still in the C code window, the debugger might try to step one "C line" at a time, which typically involves steps of several machine instructions at a time. --MMS

[@bbogdanmircea]

@@StateMachineCOM #if defined(USE_AHB_BUS) SYSCTL_GPIOHBCTL_R |= (1U

[@bbogdanmircea]

It seems that once you activate the AHB bus, if you flash a code that will write APB registers, you will get a stack error. Any idea how to switch properly between AHB and APB? I tried to reset the bit SYSCTL_GPIOHBCTL_R &= ~(1U

[@HeliosFire9ll]

I'm still unsure why 3FC is being used. I know FF = 1111 1111 which is 256 which are all possible data registers for GPIO port F. But we shift to the left two ( 2

[@StateMachineCOM]

+Helios Fire All addresses of peripheral registers are aligned at 4-byte boundary, so address lines A0 and A1 are not used to access the peripherals. Apparently this was easier to implement for the hardware designers. Please note that no memory or other resources are really wasted. The peripherals are simply wired such that A0 and A1 are ignored. But, of course, A0 and A1 are used in many other memory accesses. For example the LDRB/STRB instructions access individual bytes, which can be at odd addresses.

[@gauravminocha9335]

+Quantum Leaps, LLC "All addresses of peripheral registers are aligned at 4-byte boundary, so address lines A0 and A1 are not used to access the peripherals".. I am still trying to understand it..if all addresses of peripheral registers are aligned to 4 byte then why would they skip A0 and A1? or it is just the way designer made a choice..

[@StateMachineCOM]

+Gaurav Minocha To understand why address lines A0 and A1 are not used for addressing 4-byte aligned peripheral registers, please write the following sequence of numbers in binary: 0, 4, 8, 12, 16, .... I hope you would get something like 0000, 0100, 1000, 1100, 10000, ... Now please notice that all of these addresses have "00" at the end. These are the lines A0 and A1.

[@rolandoaguilera3114]

Im a bit confused, (0x40025000 + (LED_RED

[@JO-qi9um]

If you skip the 2 unuse bits, you'll see it set only the bit 1

[@jp_engineer]

Remember GPIO_PORTF_DATA_R = 0x400253FC, which gives you the address to access all the GPIO in PORTF 0x400253FC = 0x40025000 + 0x3FC , where 0x40025000 is the base address. Now to your question. (0x40025000 + (LED_RED

[@VuNguyen-ws6nt]

lesson 8, please!

[@abdo199199]

not clear why did you use 0x3fc as an offset for the data register instead of 0x000 ?

[@StateMachineCOM]

+abdelrahman tarief Please take a look again at the wiring of the GPIO data and *address* lines (around 5:22 in the video). In order to write to a given GPIO bit, both the connected data line *and* the connected address line must be 1 (high). Please also notice that the two lowest-order address bits (A0 and A1) are not connected to any GPIO bits. This means that you need to shift the desired bit combination (in addresses) by two spots. So, for example, if you wish to set all 8 address bits to 1 (0xFF), you need to shift it by two 0xFF

[@abdo199199]

+Quantum Leaps, LLC yes thanks for your clarification, but does that mean there is 256 different Gpio data registrar ?

[@StateMachineCOM]

+abdelrahman tarief Yes, that's exactly right. There are 256 GPIO DATA registers! You can see it in the TM4C123GH6PM.h header file, the GPIOA_Type typedef. The first 255 of these registers are named DATA_Bits[255] and the 256-th one is named DATA (immediately following DATA_Bits). I hope this starts to make sense now.

[@abdo199199]

+Quantum Leaps, LLC ok your videos are helping me to much, one last question where can I find the definition of global interrupt enable function (I) ? because it seems that I cant use the PRIMASK register to modify this bit

[@StateMachineCOM]

+abdelrahman tarief The IAR toolset provides a very fast, so called intrinsic function for disabling and enabling interrupts. These functions are called __disable_interrupt() and __enable_interrupt(), respectively. Note that you would need to include the system header file called to be able to use these functions. These intrinsic "functions" don't really cause any function call and return, but the compiler simply emits the "CPSID I" and "CPSIE I" machine instructions for them. These instructions indeed set and clear the PRIMASK register. The Cortex-M3 and higher CPUs have also an alternative, more selective, way of disabling interrupts by means of the BASEPRI register. I plan to cover all these things in the upcoming lessons about race conditions, because disabling interrupts is one (crude) method of preventing such race conditions.

[@7race725]

Could someone kindly explain me why GPIOF_BITS_DATA_R[LED_RED] where LED_RED = 10 binary coreesponds the address bias + 1000 binary (or 0x08 hex)? As i can understand, that register address is 40025000 and that address points to the beginning of array of 32 bit registers. And 1-s indicate those bits, that could be modified. For that reason the offset 3FC make us possible to work with all 8 pins of particular GPIO : A, B, C ... F. Two last bits are for service purposes. As we anyway can only have control of 8 bits, so, how that array looks like? [ 40025000, 40025001, 40025002, 40025003, 40025004... 40025008...]. The last one indicated here is 40025008 whom position doesn't correspond to index 2 (LED_RED = 10 binary or 2 dec, i mean 1

[@Strogden1]

"As we anyway can only have control of 8 bits, so, how that array looks like? [ 40025000, 40025001, 40025002, 40025003, 40025004... 40025008...]" The array addresses are [ 40025000, 40025004, 40025008, 40025000C, 400250010... 400250014...]. Each array element is a 32-bit address so it takes 4 bytes to store an element.

[@o.alejandrobauernfeind2062]

@@Strogden1 thank you for your explanation, it helped me a lot

[@rommelvillon6811]

I tried commenting out " // SYSCTL_RCGCGPIO_R |= (1U