Mã STM32 đầu tiên của tôi - vui lòng chỉ trích tôi

Tôi vừa viết mã đầu tiên của mình trên STM32 - đèn LED nhấp nháy. Nó kết hợp một mảnh từ các nguồn khác nhau; vui lòng chỉ trích tôi để tôi có thể học cách viết mã phù hợp và không học thói quen ngu ngốc.

#include "stm32f30x.h"

void SysTick_Handler(void);
void TimingDelay_Decrement(void);
void Delay(__IO uint32_t nTime);

static __IO uint32_t TimingDelay;

int main(void)
{
  RCC->AHBENR  |=  ((1UL << 21) );                  // Enable GPIOE clock??
  GPIOE->MODER |= (1 << 2*8);                       // PIN 9 as output

//GPIOE->BSRR = 1 << 9;                             // LED ON
//GPIOE->BSRR = 1 << 9 << 16;                       // LED OFF
//GPIOE->BRR = 1 << 9;                              // LED OFF

    if (SysTick_Config(SystemCoreClock / 1000))
    { 
    /* Capture error */ 
    while (1);
  }

    while(1)
    {
        GPIOE->BSRR = 1 << 8;   
        Delay(50);
        GPIOE->BRR = 1 << 8;
        Delay(50);
    }
}

void SysTick_Handler(void)
{
  TimingDelay_Decrement();
}

void Delay(__IO uint32_t nTime)
{
  TimingDelay = nTime;

  while(TimingDelay != 0);
}

void TimingDelay_Decrement(void)
{
  if (TimingDelay != 0x00)
  { 
    TimingDelay--;
  }

}

Tại sao tôi phải bật đồng hồ GPIOE? Và sự khác biệt giữa 1UL << 21và 1 << 21?

Trên STM32, tất cả các thiết bị ngoại vi theo mặc định bị tắt và không nhận được bất kỳ tín hiệu đồng hồ nào. Điều này giúp tiết kiệm rất nhiều năng lượng (và buộc bạn phải suy nghĩ về sự tương tác giữa các chân khi bạn viết mã). Nếu bạn muốn sử dụng GPIOE, bạn cần nói với STM32 để bật đồng hồ của nó.

1UL << 21 thay đổi một unsigned long giá trị 1 21 bit sang trái. 1 << 21thay đổi một số số có giá trị bằng 1, nhưng đó là một số loại mặc định, có thể có hoặc không unsigned long, và bạn không nhất thiết phải biết mặc định hệ thống của bạn rộng bao nhiêu. Nó sẽ thay đổi theo nền tảng và trình biên dịch. Trong thực tế, UL có thể thay đổi theo nền tảng và trình biên dịch là tốt. Tốt nhất là sử dụng typedefs của thư viện, đó là những điều chắc chắn.

(uint32_t)1 << 21và (uint64_t)1 << 21không rõ ràng.

Nhìn chung, trông khá đẹp. Có thể sử dụng thêm một số ý kiến.

SysTick_Handler có phải là trình xử lý ngắt không? Nếu vậy, hãy nói như vậy. Tôi ngạc nhiên không có thuộc tính nào khai báo điều này (hầu hết các C được nhúng cho các bộ xử lý khác có từ bị ngắt ở đâu đó theo định nghĩa của tên trình xử lý). Tôi giả sử rằng phải được thiết lập trong #DEFINE trong tệp .h hệ thống ở đâu đó. Quá tệ, họ giấu nó đi như thế.

SysTick_Handler thường được gọi như thế nào? Tôi biết điều đó được thiết lập trong cuộc gọi SysTick_Config, nhưng bạn không nói gì về nó.

Các đơn vị cho cuộc gọi Trì hoãn là gì? Một phần nghìn giây? Nói vậy

Đèn LED nào trên bảng bạn đang thao tác với GPIOE-> BSRR = 1 << 8?

Hàm TimingDelay_Decrement có thực sự cần thiết không? Tại sao không đặt mã của nó vào trong SysTick_Handler? Người ta thường cố gắng tránh các cuộc gọi không cần thiết trong một trình xử lý ngắt. Không tạo ra sự khác biệt ở đây, nhưng đôi khi có thể xử lý quan trọng.

Để dễ đọc và để giảm khả năng mắc lỗi, hãy sử dụng macro thay vì số ma thuật.

stm32f30x.h chứa macro cho (hy vọng) tất cả các giá trị đăng ký. Vì thế:

RCC->AHBENR  |=  ((1UL << 21) );                  // Enable GPIOE clock??
GPIOE->MODER |= (1 << 2*8);                       // PIN 9 as output

có thể được viết như:

RCC->AHBENR  |= RCC_AHBENR_GPIOEEN;    // Enable GPIOE clock.
GPIOE->MODER |= GPIO_MODER_MODER8_0;   // PIN 8 - not 9! - as output.

(Thật vậy - nhận xét ban đầu đã sai ở đây; sử dụng macro làm cho điều này rõ ràng hơn!)

Tương tự, mã chuyển đổi pin có thể được viết là:

GPIOE->BSRR = GPIO_BSRR_BS_8;   
Delay(50);
GPIOE->BRR = GPIO_BRR_BR_8;
Delay(50);

Đi xa hơn, GPIO_MODER_MODER8_0không rõ ràng lắm, vì vậy tôi có thể thêm một macro của riêng mình:

#define GPIO_MODER_MODER8_OUT   GPIO_MODER_MODER8_0

Điều đó có thể gây ra một chút mệt mỏi nếu bạn đang thiết lập nhiều chân, vì vậy bạn có thể làm:

#define GPIO_MODER_OUT(pin)     (((uint32_t) 1) << (2 * (pin)))

Ngoài ra, dòng trên giả định rằng các bit trong MODERđó đã là 0x0 hoặc 0x1. Nếu chúng ta không thể cho rằng, thì chúng ta cần xóa chúng trước:

GPIOE->MODER &= ~GPIO_MODER_MODER8;
GPIOE->MODER |= GPIO_MODER_OUT(8);

Cũng thế:

Nếu các hàm được khai báo ở đầu tệp không được sử dụng ở bất kỳ nơi nào khác, hãy khai báo chúng static. Điều này ngăn chặn chúng được sử dụng trong bất kỳ tập tin khác do nhầm lẫn.

Nếu trình biên dịch cho phép, mainnên được khai báo là void, không trả về một int, vì nó không bao giờ trả về.

Đây là một nitpick thực sự: TimingDelaychỉ là một số thông thường; nó không được sử dụng khi đại diện thập lục phân là phù hợp. Vì vậy TimingDelay_Decrement, trong đó, so với không, sử dụng 0, không 0x00. Điều này cũng làm cho nó phù hợp với so sánh trong Delay.

Nếu tôi hiểu đúng, __IOđánh dấu một biến là volatile, và, tôi nghi ngờ, được sử dụng để đánh dấu các thanh ghi có thể đọc và ghi được. TimingDelaythực sự cần phải được volatile, vì nó được cập nhật trong một ngắt - nhưng tôi có xu hướng sử dụng volatilehơn là __IO, để chỉ ra rằng đó không phải là một đăng ký.

nTimekhông cần phải volatile(hoặc __IO), vì nó chỉ là một tham số hàm bình thường, được truyền bởi giá trị, được đọc một lần.

Điều này về mặt kỹ thuật nên thuộc về xem xét mã .

Đề nghị duy nhất của tôi là bạn nên che / thay đổi bit nên là macro hoặc các chức năng mô tả những gì đang diễn ra. Nhận xét là tốt nhưng chúng không hoạt động và cuối cùng bất cứ điều gì các ý kiến ​​nói không có nghĩa gì; đó là mã được tính (và chúng sẽ không đồng bộ). Làm cho mã trở thành các bình luận với phân rã chức năng:

RCC->AHBENR  |=  ((1UL << 21) );  

trở thành

enableGpioe() {
    RCC->AHBENR  |=  (1UL << 21);  
}

và điều này

GPIOE->BSRR = 1 << 9; 

trở thành

void setLEDStatus(LED led, Status status) {
     led = 1 << status;     // I don't know your struct members.
}

khi nào

Đèn led

và

Trạng thái

là enum. Tối thiểu, bạn có thể biến chúng thành MACROS. Điều này sẽ giúp bạn giảm bớt việc phải nhớ đúng mặt nạ bit để thực hiện nhiệm vụ.