nrf52833 is treated the same as nrf52830, whereas nrf52833 has PO and P1 same as nrf52840
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- zig
- Lĩnh vực
- embedded-iot
Hướng nghiên cứu
Search the MicroZig files for the GPIO version enum and the .nrf52, .nrf52833 => .nrf5283x mapping shown in the issue. Compare the nRF52833 GPIO port details with the nRF52830 and nRF52840 references linked in the report. Done means nRF52833 is handled with the two-port variant while nRF52830 retains its existing behavior; run the relevant GPIO tests or checks.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
nrf52833 is treated the same as if it only has one GPIO port, whereas nrf52833 has two, PO and P1, same as nrf52840. The difference is: 33 has p1.00 - p1.09 and 40 has p1.00 - p1.15.
const version: enum {
nrf51,
nrf5283x,
nrf52840,
} = switch (compatibility.chip) {
.nrf51 => .nrf51,
.nrf52, .nrf52833 => .nrf5283x,
.nrf52840 => .nrf52840,
else => compatibility.unsupported_chip("GPIO"),
};
in this enum above, which is littered across microzig files this line: .nrf52, .nrf52833 => .nrf5283x, is incorrect and I have had to change the enum to reflect this as shown below:
const version: enum {
nrf51,
nrf5283x,
nrf52840,
} = switch (compatibility.chip) {
.nrf51 => .nrf51,
.nrf52 => .nrf5283x,
.nrf52840, .nrf52833 => .nrf52840,
else => compatibility.unsupported_chip("GPIO"),
};
- Ngôn ngữ chính
- Zig
- Star
- 2.3k
- Fork
- 198
- Merge trung bình
- 1 ngày 8 giờ
- Pull request đã merge (30 ngày)
- 37
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ZigEmbeddedGroup/microzig
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
ZigEmbeddedGroup/microzig#1086 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 69/100
ZigEmbeddedGroup/microzig#1085 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
ZigEmbeddedGroup/microzig#1061 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
ZigEmbeddedGroup/microzig#1059 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
regz: AVR peripherals generated at address 0 when the register-group name matches the module (ATDF)Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
ZigEmbeddedGroup/microzig#1072 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của ZigEmbeddedGroup/microzig
Issue tương tự
-
docs
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
adidshaft/grok-gadgets#202 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
FujiNetWIFI/fujinet-firmware#1908 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
firmware: transmit() doesn't reset rfTxCurBufIdx, so RFxmit after RFxmitLong can send wrong bytesCó thể đã có người làm @hermes-crew-337 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
atlas0fd00m/rfcat#182 ·
-
followup
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
pidProfiles: #15546 grows pidProfile_t (228 → 234 bytes) without a PG version bump — profiles saved by earlier master builds load shiftedCó thể đã có người làm @Firat17aze đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
betaflight/betaflight#15826 ·
Maintainer thường phản hồi trong vòng 2 ngày