Tôi không hiểu được câu hỏi của bạn
Mã nguồn tại đây
Vẫn chưa hiểu rõ bạn muốn hỏi gì
Chủ blog, làm phiền hỏi bạn một chút. Tôi chỉ sửa đổi module nguồn phụ, thay module giảm áp DCDC của bạn bằng module NDP2355KC. Tôi sử dụng cuộn cảm công suất là PSPMAA0605H-100M-ANP. Sau đó, xảy ra vấn đề là khi tôi cấp đầu vào 16V hoặc điện áp tương tự, khi muốn thiết lập điện áp đầu ra khoảng 10V, hệ thống tự khởi động lại (khi cấp nguồn qua cổng C) hoặc bị quá tải dòng điện, đầu ra ngay lập tức ở mức dòng tối đa (khi cấp nguồn từ bộ nguồn ổn áp). Khi dùng nguồn DC để cấp điện, đầu nguồn sẽ chuyển sang chế độ CC và điện áp cấp ra khoảng 6V. Ngoài ra, MOSFET trên board nóng lên rất nhiều. Bạn có thể phân tích nguyên nhân được không? Cảm ơn bạn.
Kiểm tra xem đầu ra có bị đoản mạch không
Nhìn vào bố trí PCB của bạn
Đầu ra cũng không bị đoản mạch
Đường lấy mẫu có vẻ như không được nối, và việc lấy mẫu dòng điện không sử dụng đường đi Kelvin
Đó là do cái điện trở bị xoay nhầm một chút, PCB không có vấn đề. Tôi thực sự không để ý đến việc đo dòng điện cần phải dùng phương pháp Kelvin, cảm ơn bạn đã nhắc nhở.
Làm cách nào để cấu hình HRTIM kích hoạt lấy mẫu ADC tại điểm giữa của chu kỳ PWM vậy? Mình đã thử cấu hình nhưng thời điểm kích hoạt không chính xác, bị trễ hơn rất nhiều so với giá trị cài đặt. Mình nên kiểm tra từ đâu để tìm ra vấn đề?
Chụp màn hình xem bạn cài đặt thế nào.
Tôi chỉ sử dụng C, D là dành cho việc mở rộng sau này
Tôi kiểm tra và phát hiện ra rằng thời điểm đảo trạng thái chân PC15 của tôi luôn chậm hơn 2.5uS so với thời điểm tôi cài đặt, dưới đây là hàm kiểm tra của tôi
// Hàm callback
void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc)
{
// ADC1_2_IRQHandler();
if (hadc->Instance == ADC2)
{
GPIOC->ODR ^= GPIO_PIN_15;
Control_Loop_Update(); // Vòng lặp điều khiển tần số cao của bạn
// GPIOC->ODR ^= GPIO_PIN_15;
}
else if (hadc->Instance == ADC1)
{
// GPIOC->ODR ^= GPIO_PIN_13;
// flag_adc1 = 1;
PID_V();
GPIOC->ODR ^= GPIO_PIN_13;
}
// HAL_GPIO_WritePin(GPIOB, GPIO_PIN_15, GPIO_PIN_RESET); // Kéo xuống mức thấp
}
Không hiểu sao thứ tự của cái ảnh chụp màn hình này lại bị lộn xộn 
Bạn ơi, bản thân cách kiểm tra của bạn đã có vấn đề rồi. Bạn toggle IO trong HAL_ADC_ConvCpltCallback, thì cái đo được tuyệt đối không phải là „thời gian kích hoạt", mà là „thời gian lấy mẫu ADC + thời gian chuyển đổi + độ trễ phản hồi ngắt + chi phí xử lý khổng lồ của thư viện HAL".
Bạn vào xem mã nguồn của HAL_ADC_IRQHandler là biết ngay, thư viện HAL của ST trước khi gọi callback này phải kiểm tra cả mớ trạng thái thanh ghi, trôi mất 1~2µs ở giữa là chuyện quá bình thường. Cộng thêm thời gian lấy mẫu cấu hình trong ảnh chụp màn hình của bạn là 6.5 Cycle, chuyển đổi còn tốn thêm 12.5 Cycle, đây toàn là thời gian thực tế.
Muốn đo được điểm kích hoạt thực tế, cứ cấu hình trực tiếp một chân đầu ra so sánh của timer, dùng máy hiện sóng bắt sóng PWM và tín hiệu đầu ra so sánh đó. Nếu nhất định phải đo trong ngắt, thì vứt thư viện HAL đi, tìm thẳng điểm vào ngắt ADC trong file startup, toggle GPIO ngay ở dòng lệnh đầu tiên, bạn sẽ thấy độ trễ giảm hẳn ngay lập tức.
1 Lượt thích
Tôi vừa xem ảnh chụp màn hình CubeMX của bạn, bạn kiểm tra lại mấy điểm sau nhé:
- Nguồn kích hoạt ADC của bạn đang cấu hình là
Timer C Compare 3, tôi thấy trong phần cấu hình Timer C bạn đặt Compare 3 thành46080 / 4. Nếu chu kỳ PWM của bạn là 46080, thì điểm giữa không nên là/2sao? (Trừ khi bạn đang dùng chế độ căn giữa (center-aligned mode), thì lúc đó phải tính toán lại cụ thể). - Cạnh kích hoạt ADC mà bạn chọn là
Trigger detection on the falling edge(kích theo sườn xuống), bạn có chắc chắn sự kiện kích do HRTIM tạo ra ở vị trí bạn mong đợi là sườn xuống không? Thông thường người ta hay cấu hình sườn lên theo mặc định nhiều hơn. - Giống như bạn ở trên đã nói, 2.5uS chắc chắn là overhead của phần mềm. Với tần số chính của G474 là 170MHz, 2.5uS tương đương với việc thực thi hơn 400 lệnh rồi, toàn bộ đều tiêu tốn cho việc vào ngắt, đẩy stack và các lệnh IF trong thư viện HAL. Khuyên bạn nên dùng DMA, để ADC lấy mẫu xong thì kích hoạt DMA truyền tải luôn, đừng dùng ngắt CPU để đợi.
1 Lượt thích
Đúng vậy, sau đó mình test thêm thì thấy nhét vào hàm ADC1_2_IRQHandler, độ trễ gần như không còn.
Các bác ơi, hiện tại mình đang trong quá trình test, ban đầu chức năng hoạt động bình thường („gợn sóng“ đầu ra rất lớn, tần số giống với tần số chuyển mạch của mình nhưng bị khuếch đại, tần số của nó rất cao, như hình dưới), sau đó mình thêm vài tụ đầu ra, rồi cấp nguồn lại thì ADC của con 32 hình như bị hỏng hết rồi. Giờ dữ liệu đo được từ các chân ADC dù đầu vào ngoài là bao nhiêu thì chúng cũng cho ra giá trị giống hệt nhau, điều này có thể do nguyên nhân nào gây ra? Điện áp đầu vào của mình là 40V, đầu ra cài đặt 30V, tải là 20R. Mình muốn hỏi sau module test này có cần phải thêm một linh kiện để bảo vệ các chân của con 32 không? Nếu có thì có loại nào được khuyên dùng không? Cảm ơn các bác!
Không hiểu bạn đang nói gì, đây có phải là board mã nguồn mở của tôi không?
Tô-pô thì giống nhau, chỉ là cái này do tôi tự vẽ
Câu hỏi của tôi là
-
Trong biểu đồ đo thành phần AC đầu ra của tôi, tại sao lại xuất hiện đỉnh nhọn rất cao này? Trong một chu kỳ chuyển mạch của tôi, nó xuất hiện 4 lần, tôi nên làm thế nào để loại bỏ ảnh hưởng này
-
Trong quá trình test bo mạch, phần ADC của STM32 đã bị hỏng hết. Tôi không biết tại sao phần ADC lại bị hỏng, trước chân ADC của tôi còn có một bộ lọc thông thấp RC, nhưng kết quả là chân ADC vẫn bị hỏng, nguyên nhân nào có thể gây ra điều này? Trước đây tôi đặt câu hỏi vì nghi ngờ chân ADC bị hỏng, giờ cơ bản đã xác định là thực sự bị hỏng. (Tôi đoán là do đỉnh nhọn của thành phần AC trong hình trên quá cao dẫn đến chân ADC của con 32 bị hỏng, không biết suy đoán của tôi có đúng không) Tôi đã làm hỏng hai vi điều khiển rồi, đều là do chân ADC bị hỏng, nhưng không tìm ra nguyên nhân
-
Nếu tôi muốn thêm bảo vệ cho chân ADC của con 32, để đầu vào ADC nằm trong khoảng 0-3.3, có phương pháp/linh kiện nào hiệu quả không