PIC 16F dla początkujących .. różnica w składni programu przy użyciu różnych kompilatorów

9

Jak wspomniałem, właśnie zacząłem programować pic16f877a. Mogę teraz pracować z 7-segmentowymi wyświetlaczami. Obecnie używam kompilatora ccs. Nic w tym złego. Ale wolę być programistą niezależnym od kompilatora. Więc jednocześnie chcę pracować w innych kompilatorach, takich jak IAR lub Hitechc. Chcę wiedzieć, czy „deklaracja instrukcji programu w kompilatorach” inna niż ccs będzie inna? Proszę, poprowadź mnie, jak podejść do tego. Z zadowoleniem przyjąłbym wszystkie formy sugestii. Z góry dziękuję.

pic compiler VV Rao
źródło

Odpowiedzi:

9

Tak dobrze, że chcesz być niezależny od kompilatora! Niestety kompilatory hitech i CCS dla niższych PIC używają wielu specyficznych dla kompilatora deklaracji preprocesora, specyficznych dla kompilatora procedur dostępu do pinów, aw przypadku specyficznych dla kompilatora CCS procedur dostępu do podstawowych funkcji, takich jak SPI, I2C, ADC i tak dalej.

Nie jest możliwe napisanie kodu, który nie jest specyficzny dla kompilatora, bez dużej ilości preprocesora #define, #ifdef, #ifndef itd., Aby uzyskać dostęp do określonych części tego, co każdy kompilator ma do zaoferowania. To spowodowałoby, że Twój kod byłby nieczytelny.

Najlepszą rzeczą, na którą możesz dążyć, to być niezależnym od IDE i używać czegoś takiego jak zaćmienie, więc przynajmniej używasz tego samego IDE. Spowoduje to utratę kreatorów CCS do konfigurowania podstawowych funkcji, ale zapewni większą elastyczność w korzystaniu z tego samego IDE.

Inną rzeczą do rozważenia jest to, że zarówno hitech, jak i CCS nie mają (przynajmniej w przeszłości) prawdziwego linkera kompilatora c i wymagały użycia „#include myfile.c”, którego osobiście gardzę… ale to inna historia.

Nie komentowałem kompilatora IAR, ponieważ używałem tylko CCS i hitech. Oba działały dobrze, ale nigdy nie byłem zadowolony z migracji po migracji z platformy Motorola (teraz freescale) i użyciu kompilatora metroworks, który był wówczas bardziej zaawansowany. Kompilator IAR wygląda dobrze, ale nigdy go nie użyłem.

smashtastic
źródło
Jeśli poradzisz sobie z pozostaniem na lub powyżej pic18, powinieneś spojrzeć na kompilator c18. Ma duże wsparcie. IAR rezygnuje z obsługi PIC, nie będą już sprzedawać licencji z obsługą.
Kortuk
Rozumiem, że architektura PIC16 / 12/10 nie odwzorowuje zbyt dobrze języka C. Dlatego kompilatory C muszą mieć pewne nietypowe i niestandardowe struktury, aby skompensować architekturę PIC. Rezultatem końcowym jest brak współdziałania kompilatorów.
Connor Wolf,
7

Jeśli korzystasz z części PIC18, poleciłbym kompilator C18 firmy Microchip. Jest znacznie bardziej zgodny z ANSI C niż kompilator CCS. Nie jestem pewien co do kompilatora Hi-Tech, ponieważ go nie używałem. Jak już powiedziano wcześniej, jeśli naprawdę chcesz, aby kod był niezależny od kompilatora, będziesz musiał użyć wielu dyrektyw prekompilatora. Polecam przyjrzeć się niektórym przykładowym programom Microchip, które obsługują wiele kompilatorów, aby dowiedzieć się, jak to zrobić.

mjh2007
źródło
c18 dla pic18, c30 dla pic24 i dspic, c32 dla pic32!
Kortuk
CCS jest fajny, ponieważ niektóre rzeczy są prostsze do zrobienia (na przykład przerwania i timery - wszystkie przykłady Microchip napisały ASM, aby przerwać pracę bezpośrednio w C18), ale jest bliżej ANSI C.
J. Polfer
Potrzebujesz tylko jednej instrukcji asemblera, a mianowicie GOTO, która jest używana do ustawienia wektora przerwania w celu wskazania procedury obsługi przerwań.
mjh2007
3

Niestety okaże się, że bardzo trudno jest znaleźć niezależny od kompilatora program dla mikrokontrolera. Jest kilka problemów, tutaj są tylko dwa:

  1. Różnice w urządzeniach peryferyjnych, nazwach SFR itp. (Zwłaszcza w porównaniu z innymi procesorami, ale nawet w przypadku kompilatorów z tej samej rodziny), oraz;

  2. Niestandardowe funkcje niektórych kompilatorów, takie jak ustawianie bitów indywidualnie lub różne struktury do wywoływania kodu asemblera.

Seria 16F jest bardzo ograniczona pod względem architektury i tak naprawdę nie została zaprojektowana do obsługi kompilatora C. Dlatego nie ma na to GCC.

Thomas O
źródło
3

Spójrz na SDCC . Obsługuje wiele urządzeń PIC16 i PIC18. GCC obsługuje PIC24 i dsPIC.

Toby Jaffey
źródło
zapytałem o różnice w instrukcjach podczas korzystania z różnych kompilatorów .. w każdym razie dowiedziałem się o jeszcze 1 kompilatorze „sdcc” .. bardzo dziękuję ..
VV Rao,
2

Najbardziej prawdopodobne aspekty zależne od kompilatora to:

  • za pomocą pojedynczych bitów (szczególnie w portach IO)
  • rozmiary liczb całkowitych i znak są podpisane lub niepodpisane
  • śmieszne wskaźniki: C18 rozróżnia wskaźniki rom i ram :(
  • bezpieczniki konfiguracyjne
  • zajęty czekaniem

Moim preferowanym sposobem radzenia sobie z tym jest pisanie makr dla tych aspektów, a kompilator wybiera prawidłowe makro na podstawie predefiniowanych makr specyficznych dla kompilatora. W ten sposób stworzyłem bibliotekę RFM70 i przykładowe aplikacje, które działają na PIC14 (HiTechC), PIC16 (C18) i ARM (GCC).

(aktualizacja) Moja biblioteka RFM70 jest teraz kompletna. Obsługuje C na PIC 16F (kompilator Hitech), C i C ++ na LPC11114 (Cortex) i LPC2148 (ARM7TDMI) (kompilator GCC) oraz Arduino (ATMega128, kompilator GCC). Jest to generowane (w tym dokumentacja doxygen) z tego samego źródła przez wykonanie wstępnego przetwarzania w skrypcie Python. Wsparcie Jal jest w fazie rozwoju, może nastąpi ProtonBasic. http://www.voti.nl/rfm70

Wouter van Ooijen
źródło