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

[phantom]

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

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

sdcc можно глянуть. Слегка глючный, но бесплатный.

[phantom]

А MPLAB полный случаем нигде не пробегал?

[vanner]

MPLAB - полнее не бывает . Сейчас с ней поставляется lite версия комплятора Hi-Tech. Правда что в нем поддерживается не знаю. Все си-компиляторы к нему прикручиваются отдельно.
Для PIC18 и PIC24 можно использовать студенческие версии компиляторов Microchip С18 и С30 соответственно. От полной отличаются отключением оптимизации по истечению триала.

[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);
}

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

[phantom]

Надо под PIC16 - PIC18. Посмотрел на ФТП там в разделе PUB\MCs\_PIC_ в каталогах - пусто (HI-Tech..) это что за штучки? Я вообще Тotal Commander-om смотрю...

[DL36]

Надо под PIC16 - PIC18. Посмотрел на ФТП там в разделе PUB\MCs\_PIC_ в каталогах - пусто (HI-Tech..) это что за штучки? Я вообще Тotal Commander-om смотрю...

Иваныча смотри

[volodya]

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

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

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

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

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

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

[oran-be]

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

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

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

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

[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 уже освоен и к эклипсе прикручен.

[Baser]

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

Встроенные макросы для прямого побитного объявления портов и других SFR-ов есть и в компиляторах HTPICC, HTPIC18 для ПИКов. Пример:

Код

#define pin_PFail       RB5
#define pin_1w_in       RE2
#define pin_1w_out      RA5

И в ИАРовских компиляторах, в частности IAR AVR 4.21. Пример:

Код

#define poGreenLED      PORTB_Bit6
#define poRedLED        PORTB_Bit7

Вот цитата из файла iom128.h:

Код

/* Examples of how to use the expanded result:
* TCCR2 |= (1<<5);
* or if ENABLE_BIT_DEFINITIONS is defined  
* TCCR2 |= (1<<COM21);
* or like this:
* TCCR2_Bit5 = 1;
* or like this:
* TCCR2_COM21 = 1;
*/

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

И в ИАРовских компиляторах, в частности IAR AVR 4.21.

Да, вспомнил, что мне не понравилось в таком подходе - объявив таким образом конкретный пин, я могу с ним делать только два действия - on и off. А через свои чудо-макросы - on, off, читать, менять направление, читать направление и прочее. При использовании битовых полей универсальности не получается - невозможно будет сделать if(signal(SCLK)) { dir_out(SCLK); off(SCLK); } if(dir(SCLK) { on(SCLK); dir_in(SCLK); } - придется отдельно объявлять SCLK_PIN, SCLK_DIR, SCLK_OUT. В общем: если макросы дают больше удобств - зачем от них отказываться?

[Baser]

...

Да, к слову, нет ли под рукой ссылочки, где описывается макропроцессор с применением двойных ##.
Сложные макросы никогда не применял и до сих пор не понимаю значения ## , хотя они широко применяются в хидерах компиляторов.

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

Да, к слову, нет ли под рукой ссылочки, где описывается макропроцессор с применением двойных ##.

Гугля дает много ссылок по запросу "c preprocessor". Я обычно пользуюсь вот этой, разделы 3.4, 3.5

[Baser]

Гугля дает много ссылок по запросу "c preprocessor". Я обычно пользуюсь вот этой, разделы 3.4, 3.5

Спасибо, теперь буду знать умные слова stringification (#) и token pasting or token concatenation (##).
Раньше мне везде попадалось только описание Traditional macros, ISO макросы всеми замалчивались

[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. Где съедание памяти?

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

[Baser]

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

Ну, если так рассуждать, то любой бит регистрового файла в пределах одной страницы у ПИК-ов имеет уникальный адрес, состоящий из адресов байта+бита. Это поддерживается на уровне системы команд. Побитовая адресация части SFR-ов на уровне системы команд есть и у AVR и у MCS51 семейства.

Но на самом деле адрес регистра и адрес бита находятся в разных адресных пространствах и мешать их нельзя. В ANSI С нет операций с отдельными битами, поэтому разработчики компиляторов изголяются кто как может. Приведенный вами пример с PORTB4 это уже фича компилятора. Например, вот выдержка из мануала на HTPICC:

PICC supports bit integral types which can hold the values 0 or 1. The bit variable facility may be combined with absolute variable declarations (see page 153) to access bits at specific addresses. Absolute bit objects are numbered from 0 (the least significant bit of the first byte) up. Therefore, bit number 3 (the fourth bit in the byte since numbering starts with 0) in byte number 5 is actually absolute bit number 43 (that is 8bits/byte * 5 bytes + 3 bits).

For example, to access the power down detection flag bit in the RCON register, declare RCON to be a C
object at absolute address 03h, then declare a bit variable at absolute bit address 27:

static unsigned char RCON @ 0xFD0;
static near bit PD @ (unsigned)&RCON*8+2;

Note that all standard registers and bits within these registers are defined in the header files provided.

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

Мне, в принципе, макросы не нравятся, потому что они съедают програмную память. Но это стоит учитывать только на маленьких процессорах. Зато код выполняется (если пользуетесь макросами) быстрее.

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

[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, а это уже две инструкции.

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

[Alex B._]

Насчет адреса у каждого бита - конечно есть. Вся память ПИК-ов побитово адресируемая.

Что за бред? Память пиков не адресуема побитово, шина адреса - 8 бит + переключение банков. Это чисто фича хай-тека, за счет которой первые версии компилятора при использовании битовых переменных уделали старинный микрочиповский компилер, о котором сейчас никто не помнит. Обращение к битовой переменной компилируется в bsf/bcf/btfss/btfsc, вот и все. Хай-тек просто облегчил себе задачу, усложнив жизнь программистам, которые сейчас потихоньку перетаскивают код на более современные архитектуры.
С точки зрения хай-тека у каждого микрочиповского бита адрес есть, но говорить так нельзя. Некоторые и MCC18 и IAR-ом пользуются.

Вот вам другой пример - Cortex-M3. Тут уже можно сказать, что у каждого бита есть свой адрес, потому как есть адресуемые "bit-bang" области. Запись по выровненному адресу 1 устанавливает соответствующий бит, запись 0 - сбрасывает, аналогично чтение. И это фича архитектуры а не компилятора, которая позволяет с битами работать атомарно

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

угу... смайлика только не хватает...

[evc]

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

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

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

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

[Alex B._]

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

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

[evc]

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

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

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

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

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

Вот вам объяснение этого "несуществующего" термина:

Термин существует. Но то, что есть у ПИКов - не битово-адресуемая память. Я вам уже приводил пример, когда доступ к такому "битово-адресуемому" биту приводит к порче соседних. Именно потому, что память - байтово-адресуемая. Попробую еще такой аргумент: раз каждый бит имеет адрес, значит можно завести указатель на бит и работать с конкретным битом через такой указатель?

[evc]

...

Да, я согласен, что они это криво сделали. Скорее всего отмазались...
И да, я согласен, что в других процессорах это сделано по-настоящему. Но в сравнение с х51-ой серии, для меня доступность каждого бита - плюс. Будь осторожным при работе с портами и все!
Вот поэтому (и не только, но с большим сожалением!) в свое время и перешел на ПИК-ах.

[DL36]

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

Действительно очень удобно, и С30 прекрасно все понимает.
Вопрос такого плана третий параметр в #define LED A, 1, H определяет направление передачи вход/выход я правильно понял? Или это способ коммутации выхода с помощью LATx или TRISx

[Baser]

Действительно очень удобно, и С30 прекрасно все понимает.
Вопрос такого плана третий параметр в #define LED A, 1, H определяет направление передачи вход/выход я правильно понял? Или это способ коммутации выхода с помощью LATx или TRISx

Этот параметр определяет активный уровень сигнала
H - активный уровень высокий,
L - активный уровень низкий.

Соответственно макросы, которые оперируют АКТИВНЫМ или ПАССИВНЫМ уровнями порта, будут ориентироваться на этот параметр.

Пример:

Код

#define  LED    A, 1, L

On(LED); // Установить порт RA1 в НИЗКИЙ уровень (перевести в АКТИВНЫЙ уровень).

Вот вам для примера мой файл макросов для AVR-ок. Переделать под ПИКи не сложно.
Авторство не мое, я только под свои пристрастия кое-что изменил. Авторы указаны в шапке, народ их должен знать
 portmacros.txt ( 3.72 килобайт ) Кол-во скачиваний: 1347

(расширение поменяйте на portmacros.h)

[DL36]

Этот параметр определяет активный уровень сигнала
H - активный уровень высокий,
L - активный уровень низкий.

Соответственно макросы, которые оперируют АКТИВНЫМ или ПАССИВНЫМ уровнями порта, будут ориентироваться на этот параметр.

Пример:

Код

#define  LED    A, 1, L

On(LED); // Установить порт RA1 в НИЗКИЙ уровень (перевести в АКТИВНЫЙ уровень).

Вот вам для примера мой файл макросов для AVR-ок. Переделать под ПИКи не сложно.
Авторство не мое, я только под свои пристрастия кое-что изменил. Авторы указаны в шапке, народ их должен знать

Конечно должен, спасибо.

Вот ... сразу не догадался что Н это высокий.

Я еще использую режим работы по типу открытого стока записав в защелку порта 0 и переключая его с выхода на вход и обратно. Букву тогда надо написать наверно OD.

А вообще спасибо, давно искал нечто подобное но не мог определится с тем, что нужно.
Мой вариант добавил работу с открытым стоком и аналоговыми входами.

[DL36]

Атомарная работа с портами в С30 статья
и откорректированный макрос для атомарной работы с портами в С30

Тема началась тут.

[_Pasha]

Атомарная работа с портами в С30

Я вот подумал, раз С30 по своей природе ГЦЦ-шный, можно туда притянуть конструкции атомарного доступа из WinAVR (atomic.h) - как образец самого элегантного решения.

[DL36]

Я вот подумал, раз С30 по своей природе ГЦЦ-шный, можно туда притянуть конструкции атомарного доступа из WinAVR (atomic.h) - как образец самого элегантного решения.

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

[_Макс]

Что можно использовать для PIC10? IAR и MPLAB его не поддерживают

[andron86]

Код

#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);
}

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

Даа... , я как понимаю влезь в ухо и вылези через ж..у. Это так буквально программисты понимают слово кодирование. :-) Не обижайтесь Сергей, просто зачем так, даже если это только пример?

[zltigo]

Даа... , я как понимаю влезь в ухо и вылези через ж..у.

Незабвенная Эллочка-людоедка тоже не смогла-бы оценить ни одно литературное произведение - уж больно у нее словарный запас и круг потребностей был мал.

[andron86]

Незабвенная Эллочка-людоедка тоже не смогла-бы оценить ни одно литературное произведение - уж больно у нее словарный запас и круг потребностей был мал.

:-) Ваш юмор понятен:-). Просто когда программисты, в этих трёх строчках, ошибки ищут по три месяца, тогда да.... Кстати, в двоичном кодировании 2 знака и всё прекрасно, а можно было и все 33 буквы русского могучего использовать - представляете, как бы выглядели эти сочинения! :-) Имхо, чем проще написан код, тем работоспособнее он, отпадает зависимость от своеобразностей разных компиляторов, повышается читаемость итд. итп.

[zltigo]

Просто когда программисты, в этих трёх строчках, ошибки ищут по три месяца

Может это на самом деле не программисты???

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

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

[andron86]

именно с этой целью

Как раз эта цель и привела к тому, что компилятор оказался не работоспособен.

Может это на самом деле не программисты???

Может.
Не все художнинки аля Малевич.

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

Как раз эта цель и привела к тому, что компилятор оказался не работоспособен.

Это тараканы препроцессора. Если он не отвечает стандарту - макросы тут не при чем. Полагаю, вы не поняли всех прелестей этих макросов, поэтому они вам и показались слишком сложными.

[andron86]

интересует обычно более высокие уровни абстракции

Sorry за флуд :-) я это в этом контексте понимаю:

С точки зpения банальной эpудиции, каждый индивидуум, кpитически мотивиpующий абстpакцию, не может игноpиpовать кpитеpии утопического субьективизма, концептуально интеpпpетиpуя общепpинятые дефанизиpующие поляpизатоpы. Поэтому консенсус, достигнутый диалектической матеpиальной классификацией всеобщих мотиваций в паpадогматических связях пpедикатов, pешает пpоблему усовеpшенствования фоpмиpующих геотpансплантационных квазипузлистатов всех кинетически коpеллиpующих аспектов. Исходя из этого, мы пpишли к выводу, что каждый пpоизвольно выбpанный пpедикативно абсоpбиpующий обьект pациональной мистической индукции можно дискpетно детеpминиpовать с аппликацией ситуационной паpадигмы коммуникативно-функционального типа пpи наличии детектоpно-аpхаического дистpибутивного обpаза в Гильбеpтовом конвеpгенционном пpостpанстве, однако пpи паpаллельном коллабоpационном анализе спектpогpафичеких множеств, изомоpфно pелятивных к мультиполосным гипеpболическим паpаболоидам, интеpпpетиpующим антpопоцентpический многочлен Hео-Лагpанжа, и возникает позиционный сигнификатизм гентильной теоpии психоанализа, в pезультате чего надо пpинять во внимание следующее: не только эзотеpический, но и экзистенциальный аппеpцепциониpованный энтpополог антецедентно пассивизиpованный высокоматеpиальной субстанцией, обладает пpизматической идиосинхpацией. Но так как валентностный фактоp отpицателен, то и, соответственно, антагонистический дискpедитизм дегpадиpует в эксгибиционном напpавлении, поскольку, находясь в пpепубеpтатном состоянии, пpактически каждый субьект, меланхолически осознавая эмбpиональную клаустоpофобию, может экстpаполиpовать любой пpоцесс интегpации и диффеpенциации в обоих напpавлениях, отсюда следует, что в pезультате синхpонизации, огpаниченной минимально допустимой интеpполяцией обpаза, все методы конвеpгенционной концепции тpебуют пpактически тpадиционных тpансфоpмаций неоколониализма. Hеоколонии, pазмножающиеся почкованием, имеют вегетационный пеpиод от тpех до восьми фенотипических гомозигот, но все они являются лишь фундаментальным базисом социогенетической надстpойки кpиогенно-кpеативного пpоцесса геpонтологизации. Увеличить этот базис можно с помощью гектаплазменного ускоpителя биоинеpтных коллоидных клеток контагиозной конкpетизации, однако введение конкpетизации влечет за собой пpименение методов теоpии множеств и дистpибутивного анализа, что обусловлено тем, что тpансцендентальная поликонденсация неpоноспоpы в пеpплексном хаосе может инбабулиpовать комплексный моpфоз только тогда, когда конституент доминанты квазитенденциально унивеpсален, и пpоисходит довольно внезапно. Очевидно, что все вышесказанное пpоливает свет на теоpию пpедикативных ощущений субъекта, абсолютно нефункциональных в условиях абстpактного хаоса.

Это тараканы препроцессора. Если он не отвечает стандарту - макросы тут не при чем. Полагаю, вы не поняли всех прелестей этих макросов, поэтому они вам и показались слишком сложными.

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

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

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

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

[testerplus]

Что можно использовать для PIC10? IAR и MPLAB его не поддерживают

HT-PICC и CCS

[loghir]

Подскажите ПЛЗ простейший исходник для тестирования компилятора. (Стыкую MPLAB IDE с HT_PICC, толку мало - не компилится.)

[Ruslan1]

Подскажите ПЛЗ простейший исходник для тестирования компилятора. (Стыкую MPLAB IDE с HT_PICC, толку мало - не компилится.)

Какое семейство и какой компилятор? надеюсь не PRO ?

для PIC18

Код

#include <pic18.h>
void main(void)
{
}

для PIC16:

Код

#include <pic.h>
void main(void)
{
}

ну и конечно в мплабе семейство соответствующее выбрать нужно.

[loghir]

Ruslan1, спасибо!

МК - PIC16F628

В MPLAB IDE 8.46 компиляция не идет ни с Hi-Tech PIC C-compiler v9.60 std,
ни с Hi Tech PICC v8.05pl2. (Оба активированы).
Еще у меня есть MPLAB IDE v8.30, буду с ним пробовать.

[loghir]

Поставил MPLAB IDE v8.30. (перезагрузил комп)
В окне создания проекта выбрал как на картинке:
Создал файл, подключил к проекту.

Код

#include <pic.h>
void main(void)
{
}

Пишет ошибку:

Build D:\Work\C\test_9_6 for device 16F628A
Using driver C:\Program Files\HI-TECH_9.60\bin\picc.exe

Executing: "C:\Program Files\HI-TECH_9.60\bin\picc.exe" -q -g --asmlist --chip=16F628A "--errformat=Error [%n] %f; %l.%c %s" "--msgformat=Advisory[%n] %s" "--warnformat=Warning [%n] %f; %l.%c %s" -P --char=unsigned -C D:\Work\C\test11.c
Warning [176] D:\Work\C\test11.c; 4.0 missing newline
Warning [337] D:\Work\C\test11.c; 3.1 line does not have a newline on the end

Может, надо было не picc.exe подключать?

Эскизы прикрепленных изображений

 

[xemul]

Создал файл, подключил к проекту.

Код

#include <pic.h>
void main(void)
{
}

Пишет ошибку:

Warning [176] D:\Work\C\test11.c; 4.0 missing newline
Warning [337] D:\Work\C\test11.c; 3.1 line does not have a newline on the end

Warning - предупреждение.
missing newline, line does not have a newline on the end - компилятор предупреждает, что программа не заканчивается символом перевода строки. Эти предупреждения на работе программы точно не скажутся, просто неаккуратненько.
Описания сообщений об ошибках и предупреждениях см. в docs\manual.pdf в каталоге установки компилятора. Не забудьте воспользоваться англо-русским словарём.

Может, надо было не picc.exe подключать?

Universal Toolsuite всё делает за Вас, и уже достаточно давно делает это правильно. Если сомневаетесь, ответы в docs\quickstart.pdf и хелпах мплаба.

[Ruslan1]

Ruslan1, спасибо!

МК - PIC16F628

В MPLAB IDE 8.46 компиляция не идет ни с Hi-Tech PIC C-compiler v9.60 std,
ни с Hi Tech PICC v8.05pl2. (Оба активированы).
Еще у меня есть MPLAB IDE v8.30, буду с ним пробовать.

1. как я понял, у вас уже все идет. поздравляю.
2. Если глючит на такой программе- то что-то с установкой компилятора не так. Насколько я помню, у Хайтека есть что-то бесплатное, но с ограничениями. на попробовать вполне хватит.
3. Я сам PIC16 давно не пользовал, PIC18 их покрыли как бык овцу, но нареканий не было, и PIC18 с Хайтеком отлично работает (только не PRO!). Но вот если Вы собираетесь на что-то более современное майкрочиповское переходить в перспективе- наверное лучше сразу Майкрочиповские компиляторы брать, Хайтек это тупик. Но вроде бы как раз для PIC16 и выбора нет, только hi-tech.
4. А чего МПЛАБ такой старый, вроде 8.56 уже есть. Если уж переставляете, то наверное новье не хуже старья будет

[Bronislav]

4. А чего МПЛАБ такой старый, вроде 8.56 уже есть. Если уж переставляете, то наверное новье не хуже старья будет

Вообще-то 8.63 и нормально работает с НТ 9.81 PRO для PIC16

[Ruslan1]

Вообще-то 8.63 и нормально работает с НТ 9.81 PRO для PIC16

А, ну да. 8.63, чего-то глянул на иконку 8.63 на экране, а руки 8.56 отстучали. странно
Насчет PRO- я имел неприятности на PIC18 с этими версиями, 9.63 например, они иногда очень революционно оптимизировали, несмотря на volatile, разрушались данные в глобальных переменных (массивы в несколько килобайт). Надеялся что глюк в руках- не нашел. Откатился обратно на STD. Думаю что логика у них одинаково сделана для разных семейств, вот и обхожу PRO стороной, не стоит оно того (ну или может уровень написания моих программ недостаточен для PRO, но в-общем не срослось у нас