Карма: 26
Рейтинг сообщений: 108
Зарегистрирован: Чт ноя 04, 2010 01:56:36 Сообщений: 7439 Откуда: г. Москва
Рейтинг сообщения:0
SII писал(а):
Си -- сплошной рассадник ошибок, вызванных идиотскими правилами языка. На ассемблере я делаю этих самых ошибок на порядок меньше, чем на Си, хотя и больше, конечно, чем на нормальных языках вроде Паскаля или Ады
Вот тут темнишь. Если Си пропускает многие потенциально несущие ошибки выражения, то в асме проверок абсолютный ноль. Так что асм в этом смысле еще на порядок хуже Си. А то что ошибок делаешь меньше - так от того, что производительность программиста на нем на порядок ниже -)))
Цитата:
, где случайные глюки вроде == вместо = невозможны в принципе (на асме подобных ошибок по невнимательности я практически не делаю; вероятно, сказывается более низкий уровень самого языка, требующий постоянного внимания к деталям).
Странно. я на Си таких тоже никогда не делаю. Может все дело в опыте ? Ктому же, современные компиляторы предлагают множество настроек для более строгого контроля кода. Для критичных применений есть MISRA C, где вобще шаг вправо-влево от академического стиля считается критичной ошибкой. Правильный выбор настроек компилятора и опыт - полностью снимают какие то там 'проблемы' Си относительно устаревших языков.
Цитата:
Ну и ещё раз. Если речь зайдёт о создании программы, которую реально сложно писать на ассемблере (сложные вычисления и т.п.), я её буду писать на Паскале или Аде, но ни в коем случае не на Си.
И много под что есть эффективные компилеры этих языков ? -)
Далее, как насчет крупных проектов, которые делает отнюдь не один человек. Всем резко паскале-ады учить по причуде одного человека ? -))
Карма: 26
Рейтинг сообщений: 108
Зарегистрирован: Чт ноя 04, 2010 01:56:36 Сообщений: 7439 Откуда: г. Москва
Рейтинг сообщения:0
Да и код асмовый не переносим с платформы на платформу. очень не гибко и одноразово. Современные коммерческие Си компиляторы и оптимизированный код генерируют зачастую такой, что особо улучшать там руками нечего. Исключение, пожалуй, только какие то чисто вычислительные куски, которые можно ускорить правильным применением расширений наборов комманд, или хитрым раскидыванием по регистрам промежуточных результатов вычислений.
Сейчас как раз переношу проект с AVR32 на ARM7. более 4мб исходников, 3 недели и в общих чертах уже работает.
1) По проверке ошибок. Асм в этом плане, по большому счёту, не намного хуже Си, поскольку не так уж и много возможностей для совершения случайных ошибок: он не абсолютный ноль в части проверки ошибок. Например, там, где должно быть указано имя регистра и только оно, он не пропустит ни число, ни имя переменной, ни выражение, ну и т.д. Тем не менее, что с контролем там слабовато, с Вами трудно не согласиться. Применительно к системе команд ARM можно, например, забыть написать S в команде, которая должна менять флаги, и транслятор ни слова не скажет, поскольку запись остаётся корректной. Однако возможностей для подобных случайных (по невнимательности или там из-за случайного двойного нажатия клавы вместо однократного) в асме не больше, чем на сях. Ошибки же вроде неверного написания числовой константы или имени переменной вообще во всех языках программирования совершаются с одинаковой лёгкостью по понятным причинам. В общем, я не считаю, что асм в этом плане имеет сколько-нибудь существенно меньшую надёжность, чем Си. Но тут можно вопрос и с другой стороны рассмотреть: а зачем с одного ненадёжного языка (ассемблера) переходить на другой ненадёжный (Си)? Если уж переходить, то на реально надёжный (Паскаль, Ада и т.п.), благо, трансляторы для них, пусть и не шедеврального качества, имеются.
2) Производительность (моя, во всяком случае) на асме отнюдь не на порядок ниже, если речь идёт о низкоуровневых задачах. У меня основная часть времени (никак не меньше половины) уходит не на кодирование программы, а на продумывание, как её реализовать на алгоритмическом уровне, написание комментариев к подпрограммам (что делают, какие имеют входные-выходные данные и т.п.), а на всё это затраты времени одинаковы что для асма, что для ЯВУ.
3) Что Вы _вообще никогда_ не делаете подобных ошибок -- извините, не поверю, тем более, что в Си проблемы с надёжностью крутятся не только вокруг парочки =/==. Другое дело, что опытный программист подобные ошибки будет делать редко, а не через каждые 30 секунд, да и обнаруживать их будет достаточно быстро. Что касается меня, в первый раз я столкнулся с Си лет в 16, ну и после того, как полдня (буквально) -- из-за отсутствия опыта, естественно -- потратил на поиск как раз вот такой тупой случайной ошибки, сам себе сказал: "А какого, собсно, хрена, тебе надо выёживаться и изучать ещё один язык? Только потому, что А, Б и Ц считают, что он крутой? Но я-то прекрасно вижу, что всё, что я мог бы написать на Си, могу с тем же успехом написать на Паскале (который к тому времени я хорошо знал), который свободен от целого склада недостатков Си". В общем, тогда я на него забил. Потом лет пять приходилось писать почти исключительно на Си, поскольку работал в конторе, где именно его и использовали. Любви к нему мне это не добавило, скорей, наоборот, хотя случайных ошибок делал немного -- опыта поднабрался, естественно. Тем не менее, когда ушёл "на вольные хлеба", постарался поскорей забыть про работу на нём как страшный сон, и уже много лет ту же Визуал Студию если и запускаю, то исключительно для компиляции и, может, лёгкой модификации какого-нибудь примера, который нужно понять для себя. На ПК пишу исключительно на Дельфях (изредка используя асм), для микроконтроллеров -- пока только на асме.
4) Никакие параметры никакого компилятора не снимают проблемы Си и снять не могут, поскольку язык порочен изначально. В лучшем случае они помогают снизить их остроту и снизить число незамеченных ошибок (которые, тем не менее, на Паскале и тем более Аде невозможно допустить в принципе). Ну а "устаревшие языки" -- это немножко громко сказано. Сейчас, например, идёт подготовка к выпуску очередной спецификации Ады (последняя вышла в 2005-м, кажись).
5) Насчёт наличия эффективных компиляторов под разные платформы. Во-первых, кроссплатформенность лично меня не волнует абсолютно. Во-вторых, эффективность любого компилятора в плане качества генерируемого кода ниже моей личной эффективности: я без особых усилий и ухищрений пишу более компактный и быстрый код, чем выдают компиляторы (хотя не буду утверждать, что мой код оптимальный, поскольку с целенаправленной оптимизацией не слишком заморачиваюсь: в подавляющем большинстве случаев это попросту не требуется; кстати говоря, по этой причине мне, в общем-то, плевать, насколько эффективный код выдаёт компилятор: если будет что-то критически важное, я без всяких затруднений реализую это на ассемблере). В-третьих, для двух из трёх используемых мною в настоящее время платформ (IA-32 и ARM) компиляторы и Ады, и Паскаля есть (Ада входит в состав GCC, Паскаль -- в виде Фри Паскаля для ARM, у а на ИА-32 под Виндой -- он же либо Дельфи). Третья платформа -- AVR8, там пишу на чистом ассемблере, причём выбора нет из-за жёстких ограничений на память (в серийном производстве просто так не перейдёшь на другой микроконтроллер, поэтому приходится втискиваться в то, что заложили изначально).
6) Паскаль изучить можно за несколько часов. С Адой в полном объёме, конечно, посложней, но в достаточном для практической работы -- тоже вряд ли больше дня. А насчёт "причуды" Вы абсолютно неправы. Есть, например, задачи, где надёжность стоит абсолютно и безусловно на первом месте, и там речь идёт не о поиске абы каких "типа специалистов", коих пруд пруди (и все более-менее знают Си), а о действительно квалифицированных людях, коих многократно меньше, но которые без проблем адаптируются под требования проекта. Почему, например, ПО военного назначения в мире пишут главным образом на Аде (встречается и Паскаль -- например, на шведском истребителе "Грипен"; естественно, это не Дельфи, поскольку аппаратная платформа совершенно другая, но это не принципиально в данном случае)? Как раз из-за надёжности. Так что, если проект крупный и _серьёзный_, то всем вполне резонно выучить нормальный надёжный язык, а не использовать Си только потому, что "его все используют".
7) Насчёт переносимости я уже написал: _мне_ это абсолютно без разницы. Другое дело, что чисто прикладное ПО, не имеющее сколько-нибудь жёстких связей с используемой аппаратурой (максимум -- минимальные требования к разрешению экрана, свободному объёму на диске и т.п.) я бы не стал писать целиком на ассемблере (другое дело, что я писал бы не на Си, а на Паскале/Аде). А вот системное ПО (ядро ОС, драйверы и т.п.), а также прикладное, но жёстко связанное с используемой аппаратурой (какие-нибудь промышленные датчики, например) вполне можно делать непереносимым: во-первых, при переезде на другую платформу их всё равно придётся весьма существенно менять, так что переносимость там весьма и весьма относительна по-любому, а во-вторых, от эффективности этих компонентов зависит эффективность вычислительной системы в целом (как бы гениально не было написано прикладное ПО, оно будет тормозить, если ОС отжирает на себя половину ресурсов), поэтому можно и вложить побольше усилий и времени в создание действительно эффективной системы -- если, конечно, создаётся не нечто одноразовое.
Зарегистрирован: Чт май 21, 2009 13:54:07 Сообщений: 335 Откуда: Москва
Рейтинг сообщения:0
Errorkpi писал(а):
Вот возникла задача реализовать что-то действительно сложное и АВР для этого уже нехватает. Решил все таки освоить ARM. Я как сильный приверженец Atmel решил стартонуть с процессора AT91SAM7X128. Основное из-за чего он выбран - наличие Ethernet.
Вот хочу попросить совет: 1) Как его шить (к сожалению LPT порта у меня нет. Наиболее предпочтительно что-то USBшное) 2) Какая среда разработки наиболее удобна и стабильна 3) Есть ли какие-то глобальные проблемы с ARM.
1)Купить JetLink 2)Пользуюсь Кейлом. Вообще сред много, можто тот же ИАР. По моему мнению разницы нет. 3)Говорят, что они глюченные. Мне кажется это просто зависит от знаний разработчика в написании нормальных алгоритмов. Очень рекомендую скачать книгу "додэка - микроконтроллеры arm7 семейства at91sam7.2008". Можно сказать, что это даташит, только на русском.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Пять баллов!!! Изучаю ARM7, использую LPC2103 пока пишу на С, так как примеров на ASM-е не нашел. На сколько я посмотрел на ARM-ассемблер смысла в Си совсем не вижу (даже по объему текста). Единственно, что я получил – так это подорванную нервную систему. Что опыта на СИ у меня маловато - это факт, но как мне показалось, что бы не делать ошибки на Си, так это надо вообще не иметь представления а внутренней структуре ядра. Так как то, что выбрасывает Keil после компиляции, у меня ощущение, что я теннисный мячик прошиваю. После выброшу примеры. По поводу опыта, было бы не плохо чтобы его программисты NXP(Philips) поднабрались. Так как по их примерам складывается впечатление, что те кто пишет тех. документацию, вообще не общаются с разработчиками. Поссорились они что ли . До сих пор не могу понять как запретить прерывания, так как в Keil 4 на Asm –е этого сделать уже нельзя, а на Си (__disable_irq()) в железе не работает.
Карма: 26
Рейтинг сообщений: 108
Зарегистрирован: Чт ноя 04, 2010 01:56:36 Сообщений: 7439 Откуда: г. Москва
Рейтинг сообщения:0
Sturm 1 писал(а):
По поводу опыта, было бы не плохо чтобы его программисты NXP(Philips) поднабрались.
Интересно, причем тут программисты NXP ? И где вобще какие то следы их труда ты смог отыскать ? -)))
Цитата:
так как в Keil 4 на Asm –е этого сделать уже нельзя, а на Си (__disable_irq()) в железе не работает.
Нельзя сделать в асме ? -)) В асме можно сделать всё, что имет отражение в системе комманд процессора -))
Можно только посоветовать поднабраться опыта. И внимательней читать даташиты. Тот же асм при системе комманд ядра ARM7TDMI с его то ~40 коммандами это 0.01% программирование. А регистры и порты конкретного МК - оставшиейся 99.99%
Satyr, я так понял, что у человека проблема с использованием асма, встроенного в Си, а не голого. Тут можно посоветовать только внимательно изучить документацию (хелп) -- она мне показалась довольно приличной (во всяком случае, по сравнению с рядом других средств программирования).
Карма: 26
Рейтинг сообщений: 108
Зарегистрирован: Чт ноя 04, 2010 01:56:36 Сообщений: 7439 Откуда: г. Москва
Рейтинг сообщения:0
Смотрел я этот Keil - какой то он 'плюшевый' - какие то мастера да визарды и прямые настройки глубоко скрыты -)) Вобщем если что, в IARе все приятно и понятно, в том числе и с ассемблером
Зарегистрирован: Пн мар 07, 2011 19:52:52 Сообщений: 85
Рейтинг сообщения:0
Неправильно вопрос поставил- чтобы прерывание таймера0 например заработало еще что то включить там надо?-вот например в примере из книжки- В Кейле визард что то там сам делает,непонятно что там потом включить надо-а что не надо,похоже лучше на IAR перейти.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 16
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения