kabhijit
/
EmbeddedLab2023
1
0
Fork 0
Code Pull Requests Releases 1 Activity
EmbeddedLab2023/Blink/main.c

69 lines
1.2 KiB
C
Raw Normal View History

Add base code
2023-09-01 17:32:58 +05:30
#include <stdint.h>
#include "tm4c123gh6pm.h"
#define ZERO_DEF 0
/**
* main.c
*/
void counter_loop (void);
Refactor PORTF Init Code into function
2023-09-01 20:00:30 +05:30
void GPIO_PORTF_Init(void);
Add base code
2023-09-01 17:32:58 +05:30
int main(void)
/*
* GPIODATA ->> 0xE
* GPIODIR ->> COnfigure each pin as I/P or O/P >> <0000 1110> = 0xE
* GPIOPCTL
GPIOSLR -- Slew Rate Control
x GPIOPUR -- Pull Up Enable -- 0x11
x GPIOPDR -- Pull Down Enable
x GPIOODR -- OpenDrain
x GPIODEN -- GPIO Digital Enable -- 0x00011111 >> 0x1F
*/
{
Refactor PORTF Init Code into function
2023-09-01 20:00:30 +05:30
GPIO_PORTF_Init();
Add base code
2023-09-01 17:32:58 +05:30
register uint32_t x = ZERO_DEF;
Refactor PORTF Init Code into function
2023-09-01 20:00:30 +05:30
Quick Aside to debug GPIO ISRs Problem: It is seen that the GPIO ISR was getting called more than once for every button press. Diagnosis: The last instruction in the GPIO Interrupt handler is a write to the ICR register which clears the interrupt. However, this write takes multiple cycles, depending on the caching involved. As a result, after the instruction to write to ICR, the microcontroller exits from the ISR function but the write has not yet completed. The controller sees this as a pending interrupt and goes into the ISR again. However, by the time the controller enters the ISR this second time the ICR write has indeed happened, and it appears to be a spurious interrupt call. If the code is run in single-step debug mode, it gives the code enough time to write to the ICR register and therefore the ISR is not called a second time. Solution: Wait for a few cycles *after* the ICR write instruction and before exiting from the ISR. The official documentation recommends a DSB instruction but that may not be enough to account for vendor-specific write-caching. In such a case a simple write to a register location should be enough. Additional Info: https://developer.arm.com/documentation/ka003795/latest/
2023-09-04 17:49:23 +05:30
GPIO_PORTF_DATA_R = 0x4;
// while(1)
// {
// GPIO_PORTF_DATA_R = 0x0;
// GPIO_PORTF_DATA_R = 0x2;
// GPIO_PORTF_DATA_R = 0x4;
// GPIO_PORTF_DATA_R = 0x8;
// GPIO_PORTF_DATA_R = 0xE;
// }
Add base code
2023-09-01 17:32:58 +05:30
while (1)
{
x++;
counter_loop();
Quick Aside to debug GPIO ISRs Problem: It is seen that the GPIO ISR was getting called more than once for every button press. Diagnosis: The last instruction in the GPIO Interrupt handler is a write to the ICR register which clears the interrupt. However, this write takes multiple cycles, depending on the caching involved. As a result, after the instruction to write to ICR, the microcontroller exits from the ISR function but the write has not yet completed. The controller sees this as a pending interrupt and goes into the ISR again. However, by the time the controller enters the ISR this second time the ICR write has indeed happened, and it appears to be a spurious interrupt call. If the code is run in single-step debug mode, it gives the code enough time to write to the ICR register and therefore the ISR is not called a second time. Solution: Wait for a few cycles *after* the ICR write instruction and before exiting from the ISR. The official documentation recommends a DSB instruction but that may not be enough to account for vendor-specific write-caching. In such a case a simple write to a register location should be enough. Additional Info: https://developer.arm.com/documentation/ka003795/latest/
2023-09-04 17:49:23 +05:30
GPIO_PORTF_DATA_R ^= 0x2;
Add base code
2023-09-01 17:32:58 +05:30
}
}
Refactor PORTF Init Code into function
2023-09-01 20:00:30 +05:30
void GPIO_PORTF_Init(void)
{
SYSCTL_RCGC2_R |= SYSCTL_RCGC2_GPIOF;
GPIO_PORTF_DEN_R = 0x1F;
GPIO_PORTF_PUR_R = 0x11;
GPIO_PORTF_DIR_R = 0x0E;
}
Add base code
2023-09-01 17:32:58 +05:30
void counter_loop (void)
{
Quick Aside to debug GPIO ISRs Problem: It is seen that the GPIO ISR was getting called more than once for every button press. Diagnosis: The last instruction in the GPIO Interrupt handler is a write to the ICR register which clears the interrupt. However, this write takes multiple cycles, depending on the caching involved. As a result, after the instruction to write to ICR, the microcontroller exits from the ISR function but the write has not yet completed. The controller sees this as a pending interrupt and goes into the ISR again. However, by the time the controller enters the ISR this second time the ICR write has indeed happened, and it appears to be a spurious interrupt call. If the code is run in single-step debug mode, it gives the code enough time to write to the ICR register and therefore the ISR is not called a second time. Solution: Wait for a few cycles *after* the ICR write instruction and before exiting from the ISR. The official documentation recommends a DSB instruction but that may not be enough to account for vendor-specific write-caching. In such a case a simple write to a register location should be enough. Additional Info: https://developer.arm.com/documentation/ka003795/latest/
2023-09-04 17:49:23 +05:30
uint32_t count = 0xFFFFFF;
Add base code
2023-09-01 17:32:58 +05:30
while(count>0)
count--;
}