PIC 16F початковий .. різниця в програмному синтаксисі при використанні різних компіляторів


9

Як я вже згадував, я тільки почав програмувати pic16f877a. Зараз я можу працювати з 7-ти сегментними дисплеями. В даний час я використовую компілятор ccs. Нічого поганого в цьому немає. Але я вважаю за краще бути незалежним програмістом компілятора. Тож я одночасно хочу працювати в інших компіляторах, таких як IAR або Hitechc. Хочу знати, чи буде "декларація програмної заяви у компіляторах", окрім ccs, відрізнятися? Підкажіть, будь ласка, як підійти до цієї речі. Я вітаю всі форми пропозицій. Заздалегідь спасибі.

Відповіді:


9

Це чудово, що ви хочете бути компілятором незалежним! На жаль, компілятори hitech та CCS для PIC низького класу використовують багато специфічних для компілятора декларацій препроцесора, специфічних для компілятора підпрограм доступу, а у випадку компілятора CCS - специфічні підпрограми для основних функцій доступу, таких як SPI, I2C, ADC тощо.

Неможливо записати свій код як некомпіляторний без безлічі препроцесорів #define, #ifdef, #ifndef тощо, щоб отримати доступ до певних частин того, що пропонує кожен компілятор. Це зробить ваш код нечитабельним.

Найкраще, що ви могли б прагнути - це бути незалежним IDE і використовувати щось на зразок затемнення, так що ви принаймні використовуєте ту саму IDE. Це призведе до втрати майстрів CCS для налаштування основних функцій, але надасть вам більшу гнучкість у використанні того ж IDE.

Інша річ, яку слід врахувати, - це те, що і hitech, і CCS не мають (принаймні, в минулому) справжнього посилання компілятора c і ​​вимагали від вас використовувати "#include myfile.c", який я особисто зневажаю ... але це вже інша історія.

Я не коментував компілятор IAR, оскільки використовував лише CCS та hitech. Обидва працювали нормально, але я ніколи не був дуже задоволений тим, як переїхав з платформи Motorola (тепер вільний масштаб) та використовував компілятор metroworks, який був на той час більш просунутим. Компілятор IAR виглядає добре, але я ніколи його не використовував.


Якщо ви можете впоратися з перебуванням на pic18 або вище, то слід поглянути на компілятор c18. Він має велику кількість підтримки. IAR скидає підтримку PIC, вони більше не продаватимуть ліцензій з технічним обслуговуванням.
Кортук

Як я зрозумів, архітектура PIC16 / 12/10 не дуже добре відповідає мові C. Тому компілятори C повинні мати деякі незвичайні та нестандартні структури, щоб компенсувати архітектуру PIC. Кінцевий результат - жоден із компіляторів не взаємодіє.
Вонор Коннор

7

Якщо ви використовували частини PIC18, я рекомендував би компілятор C18 від Microchip. Він набагато більше відповідає ANSI C, ніж компілятор CCS. Я не впевнений у компіляторі Hi-Tech, оскільки я не використовував його. Як було сказано раніше, якщо вам дійсно потрібно зробити компілятор незалежним кодом, вам потрібно буде використовувати безліч директив перед компілятором. Я рекомендую переглянути деякі приклади програм Microchip, які підтримують декілька компіляторів, щоб зрозуміти, як це робиться.


c18 для pic18, c30 для pic24 та dspic, c32 для pic32!
Кортук

CCS добре в тому , що деякі речі простіше зробити (переривання і таймери, наприклад - все приклади Microchip є ви пишете ASM , щоб отримати переривання на право роботи в С18), але ближче до ANSI C.
J. Польфер

Вам потрібна лише одна інструкція по збірці, і це GOTO, який використовується для установки вектора переривання, щоб вказати на процедуру служби переривання.
mjh2007

3

На жаль, вам дуже важко знайти незалежну програму для мікроконтролера. Проблем є кілька, ось лише дві:

  1. Відмінності периферійних пристроїв, іменування SFR тощо (особливо в порівнянні з іншими процесорами, але навіть із компіляторами з того ж сімейства), і;

  2. Нестандартні функції деяких компіляторів, такі як встановлення бітів окремо або різних структур для виклику асемблерного коду.

Серія 16F дуже обмежена з точки зору архітектури і насправді не створена для підтримки компілятора C. Ось чому для цього немає GCC.


3

Погляньте на SDCC . Він підтримує багато пристроїв PIC16 та PIC18. GCC підтримує PIC24 та dsPIC.


Я запитав про відмінності у твердженнях під час використання різних компіляторів .. все одно я дізнався про ще 1 компілятор 'sdcc' .. велике спасибі ..
В. В. Рао

2

Найбільш вірогідними аспектами, які залежать від компілятора, є:

  • використання одинарних бітів (особливо в портах вводу-виводу)
  • розміри цілих чисел та знаків, що підписуються чи не підписуються
  • смішні покажчики: C18 розмежовує покажчики рома та барана :(
  • конфігураційні запобіжники
  • зайнятий чеканням

Мій кращий спосіб вирішити це - написати макроси для цих аспектів і дозволити компілятору вибрати правильний макрос на основі визначених для компілятора визначених макросів. Таким чином я створив бібліотеку RFM70 і приклади програм, які працюють на PIC14 (HiTechC), PIC16 (C18) і ARM (GCC).

(оновлення) Моя бібліотека RFM70 завершена. Він підтримує C на PIC 16F (компілятор Hitech), C і C ++ на LPC11114 (Cortex) і LPC2148 (ARM7TDMI) (компілятор GCC) та Arduino (ATMega128, компілятор GCC). Це генерується (включаючи доксигенну документацію) з того самого джерела, виконуючи деяку попередню обробку в сценарії Python. Підтримка Jal знаходиться в стадії розробки, можливо, ProtonBasic піде за ним. http://www.voti.nl/rfm70

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.