Người mới bắt đầu PIC 16F .. sự khác biệt về cú pháp chương trình khi sử dụng các trình biên dịch khác nhau

9

Như tôi đã đề cập, tôi mới bắt đầu lập trình pic16f877a. Bây giờ tôi có thể làm việc với màn hình 7 đoạn. Hiện tại tôi đang sử dụng trình biên dịch ccs. Không có gì sai với điều đó. Nhưng tôi thích trở thành một lập trình viên độc lập. Vì vậy, tôi đồng thời muốn làm việc trong các trình biên dịch khác như IAR hoặc Hitechc. Tôi muốn biết liệu "khai báo tuyên bố chương trình trong trình biên dịch" ngoài ccs sẽ khác nhau không? Xin hướng dẫn tôi cách tiếp cận điều này. Tôi sẽ hoan nghênh tất cả các hình thức gợi ý. Cảm ơn trước.

pic compiler

— VV Rao
nguồn

9

Thật tuyệt vời khi bạn muốn được biên dịch độc lập! Thật không may, trình biên dịch hitech và CCS cho PIC cấp thấp sử dụng rất nhiều khai báo tiền xử lý cụ thể của trình biên dịch, các thói quen truy cập pin cụ thể của trình biên dịch và trong trường hợp các thói quen cụ thể của trình biên dịch CCS cho các chức năng lõi truy cập như SPI, I2C, ADC, v.v.

Không thể viết mã của bạn thành không phải trình biên dịch cụ thể nếu không có nhiều bộ tiền xử lý #define, #ifdef, #ifndef, v.v. để có quyền truy cập vào các phần cụ thể của mỗi trình biên dịch được cung cấp. Điều này sẽ làm cho mã của bạn không thể đọc được.

Điều tốt nhất bạn có thể nhắm đến là độc lập IDE và sử dụng một cái gì đó như nhật thực, vì vậy ít nhất bạn đang sử dụng cùng một IDE. Điều này sẽ dẫn đến việc mất các trình hướng dẫn CCS để thiết lập các chức năng cốt lõi, nhưng sẽ giúp bạn linh hoạt hơn trong việc sử dụng cùng một IDE.

Một điều khác cần xem xét là cả hitech và CCS đều không có (ít nhất là trong quá khứ) một trình liên kết trình biên dịch c thực sự và yêu cầu bạn sử dụng "#include myfile.c" mà cá nhân tôi coi thường ... nhưng đó là một câu chuyện khác.

Tôi chưa nhận xét về trình biên dịch IAR vì tôi chỉ sử dụng CCS và hitech. Cả hai đều hoạt động tốt, nhưng tôi chưa bao giờ thực sự hài lòng với sau khi di chuyển từ nền tảng Motorola (bây giờ là freescale) và sử dụng trình biên dịch metrowork tiên tiến hơn vào thời điểm đó. Trình biên dịch IAR có vẻ tốt nhưng tôi chưa bao giờ sử dụng nó.

— smashtastic
nguồn

Nếu bạn có thể xử lý ở lại hoặc trên pic18 thì bạn nên xem trình biên dịch c18. Nó có một lượng lớn hỗ trợ. IAR đang bỏ hỗ trợ PIC, họ sẽ không bán giấy phép bảo trì nữa.

— Kortuk

Theo hiểu biết của tôi thì kiến trúc PIC16 / 12/10 không ánh xạ rất tốt với ngôn ngữ C. Do đó, trình biên dịch C phải có một số cấu trúc bất thường & không chuẩn để bù cho kiến trúc PIC. Kết quả cuối cùng là không có trình biên dịch nào tương tác.

— Sói Connor

7

Nếu bạn đang sử dụng các phần PIC18, tôi muốn giới thiệu trình biên dịch C18 từ Microchip. Nó phù hợp chặt chẽ hơn nhiều với ANSI C so với trình biên dịch CCS. Tôi không chắc chắn về trình biên dịch Hi-Tech vì tôi chưa sử dụng nó. Như đã nói trước đây nếu bạn thực sự cần tạo mã độc lập cho trình biên dịch, bạn sẽ cần sử dụng nhiều chỉ thị tiền biên dịch. Tôi khuyên bạn nên xem một số chương trình ví dụ về Microchip hỗ trợ nhiều trình biên dịch để có ý tưởng về cách thực hiện.

— mjh2007
nguồn

c18 cho pic18, c30 cho pic24 và dspic, c32 cho pic32!

— Kortuk

CCS rất hay ở chỗ một số thứ đơn giản hơn để thực hiện (ví dụ như ngắt và hẹn giờ - tất cả các ví dụ về Microchip bạn đã viết ASM để có các ngắt hoạt động ngay trong C18), nhưng nó gần với ANSI C.

— J. Polfer

Bạn chỉ cần một hướng dẫn lắp ráp và đó là GOTO được sử dụng để thiết lập vectơ ngắt để trỏ đến thói quen dịch vụ ngắt.

— mjh2007

3

Thật không may, bạn sẽ thấy rất khó để tìm một chương trình độc lập trình biên dịch cho vi điều khiển. Có một số vấn đề, đây chỉ là hai:

Sự khác biệt về thiết bị ngoại vi, đặt tên SFR, v.v. (đặc biệt là so với các bộ xử lý khác, nhưng ngay cả với các trình biên dịch từ cùng một họ), và;
Các tính năng không chuẩn trên một số trình biên dịch như cài đặt các bit riêng lẻ hoặc các cấu trúc khác nhau để gọi mã lắp ráp.

Sê-ri 16F rất hạn chế về kiến trúc và không thực sự được thiết kế để hỗ trợ trình biên dịch C. Đó là lý do tại sao không có GCC cho nó.

— Thomas O
nguồn

3

Hãy xem SDCC . Nó hỗ trợ nhiều thiết bị PIC16 và PIC18. GCC hỗ trợ PIC24 và DSPIC.

— Toby Jaffey
nguồn

tôi đã hỏi về sự khác biệt trong các câu lệnh trong khi sử dụng các trình biên dịch khác nhau .. dù sao tôi cũng đã biết thêm về 1 trình biên dịch 'sdcc' .. cảm ơn rất nhiều ..

— VV Rao

2

Các khía cạnh có khả năng nhất là phụ thuộc vào trình biên dịch là:

sử dụng các bit đơn (đặc biệt là trong các cổng IO)
kích thước của số nguyên và char được ký hoặc không dấu
con trỏ hài hước: C18 phân biệt con trỏ rom và ram :(
cầu chì cấu hình
bận chờ đợi

Cách ưa thích của tôi để xử lý việc này là viết macro cho các khía cạnh này và yêu cầu trình biên dịch chọn macro chính xác dựa trên các macro được xác định trước của trình biên dịch. Tôi đã tạo một thư viện RFM70 và các ứng dụng ví dụ theo cách này chạy trên PIC14 (HiTechC), PIC16 (C18) và ARM (GCC).

(cập nhật) Thư viện RFM70 của tôi đã hoàn tất. Nó hỗ trợ C trên PIC 16F (trình biên dịch Hitech), C và C ++ trên LPC11114 (Cortex) và LPC2148 (ARM7TDMI) (trình biên dịch GCC) và Arduino (ATMega128, trình biên dịch GCC). Điều này được tạo ra (bao gồm cả tài liệu doxygen) từ cùng một nguồn bằng cách thực hiện một số tiền xử lý trong tập lệnh Python. Hỗ trợ Jal đang được phát triển, có thể ProtonBasic sẽ làm theo. http://www.voti.nl/rfm70

— Đồ trang sức van Ooijen
nguồn