Опрос: в чем пишете проги для pic'ов?
Всем привет!
Время от времени приходится питсать программки для контроллеров (пиков)-бывают иногда приступы электроники. По привычке пишу проги в MPLAB’е уже древней версии 5.70.40. Так вот долго не позанимашься этим, и уже начинаешь забывать конкретные вещи, приходится хвататься за книжку и вспоминать команды, структуру контроллера и всякие другие тонкости работы…
Подскажите, а точнее скажите, кто чем в этом деле пользуется? Про бейсик слышал, а чем хорош? Смысл на Си переходить есть?
Спасибо!
Смысл на Си переходить есть?
Конечно есть! 😃 Контроллеров 1000 штук, от разных производителей. А си - и в африке си.
Конечно есть! 😃 Контроллеров 1000 штук, от разных производителей. А си - и в африке си.
Какже!! Щаззз! Специфика остается один фиг. На C вы только облегчите себе организацию данных и переходов и циклов, а порты всякие и прочая перефирия всеравно специфична
Специфика остается один фиг.
Дмитрий, это вы мне рассказываете? 😃 Ясный пень, специфика остается! Только вам уже не надо думать о том, как реализовать в командах данного процессора тот или иной алгоритм, а лишь о том, как его привязать к имеющемуся железу: порты ввода-вывода, флеш, таймеры и прочие возможности. К тому же, есть столько “замечательных” процессоров, ассемблер которых является не то что образцом дебилизма, а я бы сказал, настоящим издевательством.
Предположим, вам приходится писать программу под неизвестный процессор. Вместо того, чтобы думать как эффективнее использовать возможности данной железки, вы будете гадать как в ней с помощью какой-нибудь косвенной индексной адрессации к массиву обратиться и можно ли это вообще сделать в силу использования в данном процессоре, например, гарвардской архитектуры.
Есть общеизветный факт. Если программист высокой квалификации, профессионал, пишет две одинаковые по сложности программы: одну на си, другую на ассемблере, то программа на си более надежна и содержит в среднем меньше ошибок. Если он пишет то жа самое на аде какой-нибудь, то программа будет еще надежнее.
То же самое касается стиля программирования. Программа написанная линейно (как, например, на бейсике, или как пишет большинство программистов на ассемблере) менее надежна чем такая же программа, написанная структурно (как обычно пишут на си или на паскале без использования goto и меток). Но программа, написанная объектно на c++ или java еще более надежна чем структурная на простом си.
Если речь заходит о критичных по времени вычислениях, то это тоже не аргумент, потому что во-первых оптимизация алгоритма в среднем в 100 раз эффективнее программной оптимизации, во-вторых современные кросс-компиляторы ничем не уступают, а в 80% случаев превосходят программиста по оптимизации кода, и в-третьих, отдельные критичные секции можно писать и на ассемблере. Если стоит задача получить максимально надежный и оптимальный во всех отношениях код, то нужно пользоваться всеми доступными средствами.
Я лично профи по мк себя не считаю, но программистом на PC работаю 15 лет. Для мк пишу для собственного удовольствия, и стараюсь везде использовать C. После компиляции обязательно изучаю листинг, и корректрирую C-код, если вижу что компилятор не смог ее нормально оптимизировать. Но такое бывает довольно редко. Например, CC5X ошибается только в использовании RP-флагов (для PIC’ов). Всегда порываюсь переписать тот или иной кусок на ассемблере, но после раздумий понимаю, что особенно не выиграю.
Кстати, не надо ругать PIC’и. Я думаю, что у его создателей была какая-то высокая цель, когда они придумывали его архтектуру 😵 Тем более, на C она (архитектура) не мешает 😃
Кстати, не надо ругать PIC’и.
Я не ругаю пики (на самом деле мне вспомнился i8051). У любого производителя есть свои тараканы. Язык си позволяет не думать о них, так как это задача других людей - разработчиков кросс-компиляторов для конкретной платформы.
Время от времени приходится питсать программки для контроллеров (пиков)-бывают иногда приступы электроники.
При аналогичных приступах 😃 использую Микрочиповский ассемблер и СС5х компилятор для С.
Почему использую ассемблер? Многие приложения, которые я писал, требовали или жесткой привязки к внешним событиям (например, управляющих сигналов от приемника), или не менее точного тайминга (опять-таки, близкая тема - программный ШИМ для управления двигателем). Оказывалось, что намного проще вручную написать и подсчитать времена, чем полагаться на С-компилятор, когда малейшее исправление в исходном коде приводит к изменению объектного кода.
С другой стороны, большая часть кода может быть написана на С. Именно так и следует поступать, особенно когда требуется хоть какая-то переносимость. Программу на ассемблере даже с одного ПИК’а на другой на том же ядре не так-то просто перетащить, не говоря уж о переносе кода, скажем, с 12 на 16 серию. Самая большая моя программа на ассемблере для ПИК’а размером в 2000 строк - и это уже где-то на пределе управляемости надежностью. Все-таки из моей практики, подавляющая часть кода - платформенно-независимая (или может быть сделана такой с минимальными усилиями).
Что касается качества кода, например, СС5х компилятора, то меня он вполне устраивает. Правда, на всякий случай, обязательно просматриваю код, проверить, что этот компилятор нагородил. Иногда получается черте что, но с желанием переписывать борюсь - а зачем, если все и так работает, причем как по времени, так и по памяти?
Поэтому вывод мой такой - переходить на С смысл, безусловно, есть.
…задача других людей - разработчиков кросс-компиляторов для конкретной платформы.
Я как раз из разряда вот таких вот людей. 😃 Я чуть выше написал, что иногда, когда смотрю в код от СС5х, руки чешутся написать кросс-компилятор, причем для Модулы-2, на ПИК. Тут немножко рекламы пойдет, можно? 😃 Мы как раз этим занимаемся, делаем самые (ну или одни и самых) быстрые компиляторы в мире, например, для Java. Excelsior Вот даже для российских спутников делаем кросс-компиляторы Компиляторы для спутников Так что для PIC соорудить - раз плюнуть.
Архитектура PIC - вполне нормальная, хотя система команд и минимальная, оптимизаций на ней можно много сделать. (А интересно, почему на PIC не сделали слота задержки при перехода как на MIPS, а тупо исполняют nop?) Как правило, чем более запутанная и сложная система команд, тем проще оптимизатору сделать нечто такое-эдакое. На VAX’е с его разнообразием команд наш оптимизатор такое рожал, что вручную никаким чудесным образом сделать не получится.
Так что переходить надо на С, чтобы время зря не терять, а ассемблер - ну, иногда можно и на ассемблере, по-старинке. 😃
Мы как раз этим занимаемся, делаем самые (ну или одни и самых) быстрые компиляторы в мире
быстрые компиляторы или компиляторы генерящие быстрый код? большая разница 😛
быстрые компиляторы или компиляторы генерящие быстрый код? большая разница 😛
Согласен! 😃 Конечно, здесь я имел в виду второе - компиляторы, генерирующие оптимальный код.
Кстати, не всегда “оптимальный” - значит быстрый. Бывает, что размер кода намного более важен. Например, как раз было необходимо упихать все бортовое ПО в заданный объем, не помню уж, сколько было доступно, по-моему, 512 кБ на-все-про-все. Ну, пришлось извращаться, но сделали, код был совершенно невменяемый местами, зато компактный.
Сегодня достал PROTON+ LITE (v2.1)- компилятор для PICBasic’а. Доволен как слон!
Полно всяких функций, надо почитать, поразбираться… Рискну предложить её неискушенным
в программировании моделистам, хотя конечно от знания контроллера она не избавляет.
Ну, может быть код у неё не такой оптимальный как у Си, но зато не надо и голову ломать.
Всем привет.
Во время Приступов - к сожалению только Асм.
И рад бы на платформенно-независимом С - но не осилил пока.
Синтаксис бэйсика всё-таки ближе - некоторые отладочные куски
писал на MS-basic для проверки алгоритмов, потом уже писал на асме
в MPLAB. Версию MPLAB приходится обновлять - старый не поддерживает
PIC18 и dsPIC30 серии - а в них асм сложнее, команд больше более чем вдвое, хотя мнемоники и похожие.Зато 30 серия асм уже похож на ностальгический для меня PDP11 асм - уже есть блок рабочих регистров 16х16 и способы адресации типа косвенной автоинкрементной ну и стек уже с программно-доступным указателем/регулируемой длинной.
Так что если кто поделится ссылками на бесплатные/доступные ПИК бэйсик или на ПИК Си компиляторы - буду весьма благодарен. Сам Микрочип свой Си компилятор либо 60 дней пробничек, либо более килобакса - рабочаа версия - грабит. Но явно и вполне отделяет профи от любителей по языковому принципу в соответствии с вышеизложенным Тохой общеизвестным правилом.
Удачи всем в начинаниях.
Дмитрий, это вы мне рассказываете? 😃
Можно и так сказать. Работаю с пиками лет 8. Каждый день 😃
К тому же, есть столько “замечательных” процессоров, ассемблер которых является не то что образцом дебилизма, а я бы сказал, настоящим издевательством.
Да, RISC, такова его сущность (хотя пик можно так называть с большоооой натяжкой) 😃 На любителя. И тем не менее ненавижу CISC всем сердцем!
Если стоит задача получить максимально надежный и оптимальный во всех отношениях код, то нужно пользоваться всеми доступными средствами.
Вот по-этому эффективнее использовать смешанное программирование.
Всем привет!
Время от времени приходится питсать программки для контроллеров (пиков)-бывают иногда приступы электроники. По привычке пишу проги в MPLAB’е уже древней версии 5.70.40. Так вот долго не позанимашься этим, и уже начинаешь забывать конкретные вещи, приходится хвататься за книжку и вспоминать команды, структуру контроллера и всякие другие тонкости работы…
Подскажите, а точнее скажите, кто чем в этом деле пользуется? Про бейсик слышал, а чем хорош? Смысл на Си переходить есть?Спасибо!
И Бейсик и Си не нужны если знаеш ассемблер и работаешь один. В пиках не так много памяти что бы загаживать её Си и.т.д. В книжки всё равно лазить придётся, читать про таймеры ацп и.т.д и ещё придётся в книжки по Си лазить. Команд пике всего 33, язык Си гораздо дольше учить будешь. Так что Си это мода и лишний гемморой. Си может пригодиться для коллективного програмирования мощных процессоров, типа как в сотовых телефонах.