Компилятор С for PIC Опции

[phantom]

Подскажите плиз, какой нынче С-компилятор для PIC-ов "в моде" и где его найти-ть. Давно уже с PIC-ами не работал, все как-то на АВР-ках. Помню раньше MPLAB был,но там с С не сложилось в свободной версии.. Заранее спасибо!

[Alex B._]

MPLAB - он вообще по жизни бесплатный.
Под какое семейство-то компилер нужен?
PIC16 - альтернативы Hi-Tech-у нет, есть на местном фтп в папке у Иваныча.
PIC18 - в общем-то тоже хай-тек рулит, хотя есть люди, успешно пользующиеся родным MCC18 - если нужен программный стек и реентерабельность (хай тек этого не умеет)
PIC24/dsPIC - только родный C30, без вариантов.
PIC32 - родной C32, GreenHills-а пока в сети нет

Как вариант под PIC16 и PIC18 - CCS (не путать с тексасовской средой =) - на фтп есть
http://www.ccsinfo.com/

SDCC - кроме того что он бесплатный ничего про него хорошего не слышал =)

[Сергей Борщ]

SDCC - кроме того что он бесплатный ничего про него хорошего не слышал =)

Сравнивал с MCC18. Препроцессор MCC18 не смог правильно обработать макросы, за что и был забракован.

[volodya]

Сравнивал с MCC18. Препроцессор MCC18 не смог правильно обработать макросы, за что и был забракован.

Нормально работают макросы, препроц. великолепно все отрабатывает. Работал достаточно долго. Даже подумываю купить "честную" лицензию у МЕЛКОЧИПА .

[Сергей Борщ]

Нормально работают макросы,

Код

#define  LED    A, 1, H
#define _setH(port,bit)         LAT##port |= (1 << bit)
#define _clrH(port,bit)         LAT##port &= ~(1 << bit)
#define _set(port,bit,val)      _set##val(port,bit)
#define on(x)                   _set (x)
#define _clr(port,bit,val)      _clr##val(port,bit)
#define off(x)                  _clr (x)

void Test()
{
   on(LED);
   off(LED);
}

Не компилится. Путается в количестве аргументов.

[volodya]

void Test()
{
on(LED);
off(LED);
}[/code]Не компилится. Путается в количестве аргументов.

Действительно! К сожалению для МСС Вы правы!
Сам таких вложений не использовал. = Особенности системы.

Сообщение отредактировал volodya - Dec 18 2007, 07:20

[Сергей Борщ]

Действительно!
Сам таких вложений не использовал.

А у меня это основной макрос доступа к портам. Поэтому более глубоко MCC тестировать не стал, хотя по описанию он действительно мощный.

[Alex B._]

А у меня это основной макрос доступа к портам. Поэтому более глубоко MCC тестировать не стал, хотя по описанию он действительно мощный.

Обертка функций в макросы вообще нехорошо с микрочипом. Просто потому, что и симулятор и дебаггер MPLAB не умеют в них входить (то же относится к инлайновым функциям) - несмотря на компилер.

А ИАР для дсПИКов? Такой ацтой, что и упоминать не стоит? Кто нить пробовал?

Просто забыл. Вполне хороший и быстрый код. До кучи EC++, чего ни один другой компилер для микрочипа пока не имеет. НО! Без плагина к MPLAB-у использовать IAR нет смысла, потому как с железными отладчиками его среда не работатет, да и симулятор там откровенно поганый. А плагин есть только к старой версии IAR (1.20), которая знает только о старых контроллерах. Нового плагина к 1.30 я не нашел, поэтому =(((

[Сергей Борщ]

Обертка функций в макросы вообще нехорошо с микрочипом. Просто потому, что и симулятор и дебаггер MPLAB не умеют в них входить

Возможно. У меня дебаггера нет. А объявить ногу в одном месте, и потом при необходимости в одном месте ее изменить - это гораздо удобнее и ошибкоустойчивее, чем во всем исходнике явно указывать порт и ногу.

[evc]

...объявить ногу в одном месте, и потом при необходимости в одном месте ее изменить - это гораздо удобнее и ошибкоустойчивее, чем во всем исходнике явно указывать порт и ногу.

тогда в *.h файле просто запишите (MCC30):

Код

#define MyPin PORTB4 // (например)

и потом везде где вам нужно обращаться к PORTB4, будете писать MyPin. Если нужно изменить, будете менять только в хедере.

[Сергей Борщ]

Код

#define MyPin PORTB4 // (например)

Заманчиво, не знал.

[Alex B._]

Заманчиво, не знал.

это шутка?

[Сергей Борщ]

это шутка?

Нет, просто не обратил внимания, что он умеет работать с битовыми переменными и что ноги портов объявлены как битовые переменные. Поскольку я пользуюсь компиляторами, в которых нет такого расширения, и часто приходится таскать код между разными платформами - привык пользоваться стандартными конструкциями типа port |= (1 << bit); В случае с битовыми переменными-выводами портов переносимости можно добиться, обернув их в макросы #define on(pin) pin = 1. Возьму на заметку. Но МСС18 использовать все равно не буду - этот проект уже закончен в SDCC, а новых на пиках, надеюсь, не будет. А если и будут - SDCC уже освоен и к эклипсе прикручен.

[evc]

Нет, просто не обратил внимания, что он умеет работать с битовыми переменными и что ноги портов объявлены как битовые переменные...

Знаете, это не совсем так... Это особенность адресации в майкрочиповских контроллерах - у них каждый пин (вообще бит SFR) имеет свой адрес, как регистр (напр. адрес PORTB4 = @PORTB + 4). Вот поэтому, объявляя "#define MyPin PORTB4", указываете препроцессору, что значение этикетки MyPin будет равно адресу пина PORTB4. Это все равно записать

Код

          unsigned char* MyPin;
          MyPin = @PORTB4;// = @PORTB + 4

(только это уже будет переменная в памяти процессора)

Пользуясь подобными выражениями (#define ...), можете не только выставлять или обнулять данного пина, но и читать его состояние. Направление пина не можете менять, поскольку в ПИК-е этим обязан совсем другой регистр (TRIS).

[Сергей Борщ]

Это особенность адресации в майкрочиповских контроллерах - у них каждый пин (вообще бит SFR) имеет свой адрес,

Это что-то новенькое. С х51 не путаете?

А существо вопроса в том, что в макросе я указываю не конкретный регистр (PORTx, TRISx, LATx), а имя порта (A, B, C) и уже внутри макроса из него получается имя нужного регистра в зависимости от необходимого действия. При использовании битовых полей такое невозможно.

[evc]

Это что-то новенькое. С х51 не путаете?...

Нет не новенькое (наверно я не очень, так, объяснил). У х51 немножко по-другому. У них регистр направления порта нет. Что бы настроит на вход нужно просто на порт выставить 1. В ПИК-ах есть регистр направления - именно TRIS (конечно, это вам хорошо известно). Дело в том, что вы о макросах говорите, а та конструкция, о которой я - обыкновенная директива препроцессора. Объявление константы "MyPin" со значением "адрес PORTB4".
Мне, в принципе, макросы не нравятся, потому что они съедают програмную память. Но это стоит учитывать только на маленьких процессорах. Зато код выполняется (если пользуетесь макросами) быстрее.

[Сергей Борщ]

Нет не новенькое (наверно я не очень, так, объяснил). У х51 немножко по-другому. У них регистр направления порта нет.

Это-то понятно. С каких пор у ПИКов каждый бит порта имеет свой адрес?

Мне, в принципе, макросы не нравятся, потому что они съедают програмную память.

Тоже чудеса рассказываете. Используемый мной (приведенный выше) макрос on(LED) преобразуется препроцессором(!) в С-выражение LATx |= ( 1<< bit), что, в свою очередь, компилируется в команду BSF LATx, bit. Где съедание памяти?

[Alex B._]

Это-то понятно. С каких пор у ПИКов каждый бит порта имеет свой адрес?
Тоже чудеса рассказываете. Используемый мной (приведенный выше) макрос on(LED) преобразуется препроцессором(!) в С-выражение LATx |= ( 1<< bit), что, в свою очередь, компилируется в команду BSF LATx, bit. Где съедание памяти?

чего-то он путает конечно =) Все там как обычно
Но макросы все равно зло в любом виде, хоть микрочип, хоть не микрочип. Тогда уж лучше инлайновые функции - компилер хотя бы тело функции сформирует если она явно по указателю будет вызвана