Компилятор С 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. Где съедание памяти?

[evc]

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

Сергей, сразу хочу уточнить, что я с вами не спорю. Вы нашли себе способ делать "переносимые" программы, вот и хорошо! Я просто хотел вам напомнить, что есть и другие способы обращаться к битам в ПИК-ах. Мне кажется, что так легче "общаться" с ними, но это только (одно) мнение.
Насчет адреса у каждого бита - конечно есть. Вся память ПИК-ов побитово адресируемая. Каждому биту можно присвоит этикетку. Адрес каждого бита получается, как комбинация из адреса байта и номер бита. А номер бита это и есть его адрес в рамках байта. Вот поэтому, думаю, вполне справедливо сказать, что у каждого бита есть собственный, уникальный адрес. Что нельзя сказать, например, о х51-ых, т.к. у них нельзя выше определенного адреса обращаться напрямую к битам.
Насчет макросов, если ваш компилятор такой "умный", то да, вы правы. Но я видел как не настолько "умный" компилятор транслирует setPin(Port, pin) = Port |= (1<<pin) как movlw 4; iorwf PORTB,f, а это уже две инструкции.

это шутка?

чего-то он путает конечно =)

Это вы зря Alex B._, к людям так, с пренебрежением относитесь ...

Сообщение отредактировал evc - Dec 24 2007, 12:10

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

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

Сказать-то так можно, но точно так же через пару {адрес байта, номер бита} можно обратиться к любому отраженному на память биту любого контроллера, и микрочип здесь никакой не особенный. Более того, он самый обычный, ибо команды bcf, bsf являются read-modify-write для всего байта, т.е. происходит чтение-запись всех битов регистра. С этим связана их особенность, когда такая команда, выполненная для одного из битов PORTx может изменить содержимое битов, выводы которых настроены на ввод. Т.е. фактически команда реализуется тремя действиями - чтение, наложение маски по И/ИЛИ, запись результата. То, что это выполняется одной командой, а не тремя - в контексте "адресуемости" несущественно.

Что нельзя сказать, например, о х51-ых, т.к. у них нельзя выше определенного адреса обращаться напрямую к битам.

Можно точно также делать чтение-наложение маски-запись. Зато до этого адреса можно обращаться действительно к конкретному биту, никоим образом не "задевая" соседние. Вот именно это (насколько я понимаю) называется "каждый бит имеет собственный адрес".

Насчет макросов, если ваш компилятор такой "умный", то да, вы правы. Но я видел как не настолько "умный" компилятор транслирует setPin(Port, pin) = Port |= (1<<pin) как movlw 4; iorwf PORTB,f, а это уже две инструкции.

Я обычно смотрю в листинг. Такое поведение тоже встречал, но в довольно старых компиляторах и при отключенной оптимизации. При включении оптимизации все опробованные в последнее время компиляторы делают все как надо, а я всегда компилирую с включенной оптимизацией.

[evc]

...точно так же через пару {адрес байта, номер бита} можно обратиться к любому отраженному на память биту любого контроллера, и микрочип здесь никакой не особенный...

В том то и дело, что нельзя (одной инструкцией). Не смотря на то, что у него инструкция выполняется за 12(и до 48) тактов, в 89C52 нельзя написать: SETB register.3 (например), если register находится за адрес 0х2F. Можно, конечно, организовать что-то подобное RMW, но это уже будут как минимум 3 инструкции. В связи с этим я могу получить на выходе ПИК-а 5МГц при 10МГц такт (системный), но это невыполнимо у АРМ-ах, например...

...Это чисто фича хай-тека, за счет которой первые версии компилятора при использовании битовых переменных уделали старинный микрочиповский компилер, о котором сейчас никто не помнит...

Читайте внимательнее, HI-TECH здесь ни при чем и это именно архитектурная "фича".
О, и Алекс, а м.п.ф! (вот и смайлик, должно хватить уже!)

[Alex B._]

Читайте внимательнее, HI-TECH здесь ни при чем и это именно архитектурная "фича".

еще раз - наличие битовых операций во всей адресуемой памяти нельзя называть "побитовой адресуемостью", нет такого термина. Это именно инструкции работы с битами и ничего больше.
Я вам привел хороший пример с Cortex-ом - вот там биты адресуются

[evc]

...наличие битовых операций во всей адресуемой памяти нельзя называть "побитовой адресуемостью", нет такого термина...

Выходит у вас не читать внимательно это рецидив.
Вот вам объяснение этого "несуществующего" термина:

Дефиниция за: Адресуемость
Достижимость. Когда что-то бывает адресуемое, его можно распознать и манипулировать, не трогая его окружения. Например, пикселы экрана и РАМ память адресуемые. Каждого элемента картинки на экране можно включать/выключать (засветит/затемнить), и каждую ячейку (каждого байта) памяти тоже можно записать и читать независимо от остальных.

Оригинал на английском здесь.
А если еще сомневаетесь в (не)существованием этого термина, напишите в поисковике "bit-addressable". Может быть и удивитесь ...
Что еще сказать? С наступающим праздником!