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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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



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

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

это шутка?

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

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

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

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

Да, вспомнил, что мне не понравилось в таком подходе - объявив таким образом конкретный пин, я могу с ним делать только два действия - 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. В общем: если макросы дают больше удобств - зачем от них отказываться?

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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



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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Пример:


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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