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


Странно. я на Си таких тоже никогда не делаю. Может все дело в опыте ?
Ктому же, современные компиляторы предлагают множество настроек для более строгого контроля кода. Для критичных применений есть MISRA C, где вобще шаг вправо-влево от академического стиля считается критичной ошибкой.
Правильный выбор настроек компилятора и опыт - полностью снимают какие то там 'проблемы' Си относительно устаревших языков.


И много под что есть эффективные компилеры этих языков ? -)

Далее, как насчет крупных проектов, которые делает отнюдь не один человек. Всем резко паскале-ады учить по причуде одного человека ? -))

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

Сейчас как раз переношу проект с AVR32 на ARM7. более 4мб исходников, 3 недели и в общих чертах уже работает.

Satyr, без всякого холивара

1) По проверке ошибок. Асм в этом плане, по большому счёту, не намного хуже Си, поскольку не так уж и много возможностей для совершения случайных ошибок: он не абсолютный ноль в части проверки ошибок. Например, там, где должно быть указано имя регистра и только оно, он не пропустит ни число, ни имя переменной, ни выражение, ну и т.д. Тем не менее, что с контролем там слабовато, с Вами трудно не согласиться. Применительно к системе команд ARM можно, например, забыть написать S в команде, которая должна менять флаги, и транслятор ни слова не скажет, поскольку запись остаётся корректной. Однако возможностей для подобных случайных (по невнимательности или там из-за случайного двойного нажатия клавы вместо однократного) в асме не больше, чем на сях. Ошибки же вроде неверного написания числовой константы или имени переменной вообще во всех языках программирования совершаются с одинаковой лёгкостью по понятным причинам. В общем, я не считаю, что асм в этом плане имеет сколько-нибудь существенно меньшую надёжность, чем Си. Но тут можно вопрос и с другой стороны рассмотреть: а зачем с одного ненадёжного языка (ассемблера) переходить на другой ненадёжный (Си)? Если уж переходить, то на реально надёжный (Паскаль, Ада и т.п.), благо, трансляторы для них, пусть и не шедеврального качества, имеются.

2) Производительность (моя, во всяком случае) на асме отнюдь не на порядок ниже, если речь идёт о низкоуровневых задачах. У меня основная часть времени (никак не меньше половины) уходит не на кодирование программы, а на продумывание, как её реализовать на алгоритмическом уровне, написание комментариев к подпрограммам (что делают, какие имеют входные-выходные данные и т.п.), а на всё это затраты времени одинаковы что для асма, что для ЯВУ.

3) Что Вы _вообще никогда_ не делаете подобных ошибок -- извините, не поверю, тем более, что в Си проблемы с надёжностью крутятся не только вокруг парочки =/==. Другое дело, что опытный программист подобные ошибки будет делать редко, а не через каждые 30 секунд, да и обнаруживать их будет достаточно быстро. Что касается меня, в первый раз я столкнулся с Си лет в 16, ну и после того, как полдня (буквально) -- из-за отсутствия опыта, естественно -- потратил на поиск как раз вот такой тупой случайной ошибки, сам себе сказал: "А какого, собсно, хрена, тебе надо выёживаться и изучать ещё один язык? Только потому, что А, Б и Ц считают, что он крутой? Но я-то прекрасно вижу, что всё, что я мог бы написать на Си, могу с тем же успехом написать на Паскале (который к тому времени я хорошо знал), который свободен от целого склада недостатков Си". В общем, тогда я на него забил. Потом лет пять приходилось писать почти исключительно на Си, поскольку работал в конторе, где именно его и использовали. Любви к нему мне это не добавило, скорей, наоборот, хотя случайных ошибок делал немного -- опыта поднабрался, естественно. Тем не менее, когда ушёл "на вольные хлеба", постарался поскорей забыть про работу на нём как страшный сон, и уже много лет ту же Визуал Студию если и запускаю, то исключительно для компиляции и, может, лёгкой модификации какого-нибудь примера, который нужно понять для себя. На ПК пишу исключительно на Дельфях (изредка используя асм), для микроконтроллеров -- пока только на асме.

4) Никакие параметры никакого компилятора не снимают проблемы Си и снять не могут, поскольку язык порочен изначально. В лучшем случае они помогают снизить их остроту и снизить число незамеченных ошибок (которые, тем не менее, на Паскале и тем более Аде невозможно допустить в принципе). Ну а "устаревшие языки" -- это немножко громко сказано. Сейчас, например, идёт подготовка к выпуску очередной спецификации Ады (последняя вышла в 2005-м, кажись).

5) Насчёт наличия эффективных компиляторов под разные платформы. Во-первых, кроссплатформенность лично меня не волнует абсолютно. Во-вторых, эффективность любого компилятора в плане качества генерируемого кода ниже моей личной эффективности: я без особых усилий и ухищрений пишу более компактный и быстрый код, чем выдают компиляторы (хотя не буду утверждать, что мой код оптимальный, поскольку с целенаправленной оптимизацией не слишком заморачиваюсь: в подавляющем большинстве случаев это попросту не требуется; кстати говоря, по этой причине мне, в общем-то, плевать, насколько эффективный код выдаёт компилятор: если будет что-то критически важное, я без всяких затруднений реализую это на ассемблере). В-третьих, для двух из трёх используемых мною в настоящее время платформ (IA-32 и ARM) компиляторы и Ады, и Паскаля есть (Ада входит в состав GCC, Паскаль -- в виде Фри Паскаля для ARM, у а на ИА-32 под Виндой -- он же либо Дельфи). Третья платформа -- AVR8, там пишу на чистом ассемблере, причём выбора нет из-за жёстких ограничений на память (в серийном производстве просто так не перейдёшь на другой микроконтроллер, поэтому приходится втискиваться в то, что заложили изначально).

6) Паскаль изучить можно за несколько часов. С Адой в полном объёме, конечно, посложней, но в достаточном для практической работы -- тоже вряд ли больше дня. А насчёт "причуды" Вы абсолютно неправы. Есть, например, задачи, где надёжность стоит абсолютно и безусловно на первом месте, и там речь идёт не о поиске абы каких "типа специалистов", коих пруд пруди (и все более-менее знают Си), а о действительно квалифицированных людях, коих многократно меньше, но которые без проблем адаптируются под требования проекта. Почему, например, ПО военного назначения в мире пишут главным образом на Аде (встречается и Паскаль -- например, на шведском истребителе "Грипен"; естественно, это не Дельфи, поскольку аппаратная платформа совершенно другая, но это не принципиально в данном случае)? Как раз из-за надёжности. Так что, если проект крупный и _серьёзный_, то всем вполне резонно выучить нормальный надёжный язык, а не использовать Си только потому, что "его все используют".

7) Насчёт переносимости я уже написал: _мне_ это абсолютно без разницы. Другое дело, что чисто прикладное ПО, не имеющее сколько-нибудь жёстких связей с используемой аппаратурой (максимум -- минимальные требования к разрешению экрана, свободному объёму на диске и т.п.) я бы не стал писать целиком на ассемблере (другое дело, что я писал бы не на Си, а на Паскале/Аде). А вот системное ПО (ядро ОС, драйверы и т.п.), а также прикладное, но жёстко связанное с используемой аппаратурой (какие-нибудь промышленные датчики, например) вполне можно делать непереносимым: во-первых, при переезде на другую платформу их всё равно придётся весьма существенно менять, так что переносимость там весьма и весьма относительна по-любому, а во-вторых, от эффективности этих компонентов зависит эффективность вычислительной системы в целом (как бы гениально не было написано прикладное ПО, оно будет тормозить, если ОС отжирает на себя половину ресурсов), поэтому можно и вложить побольше усилий и времени в создание действительно эффективной системы -- если, конечно, создаётся не нечто одноразовое.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

1)Купить JetLink
2)Пользуюсь Кейлом. Вообще сред много, можто тот же ИАР. По моему мнению разницы нет.
3)Говорят, что они глюченные. Мне кажется это просто зависит от знаний разработчика в написании нормальных алгоритмов.
Очень рекомендую скачать книгу "додэка - микроконтроллеры arm7 семейства at91sam7.2008". Можно сказать, что это даташит, только на русском.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Питание на всё с USB взял,5 в немного сажается,поэтому контрастность не очень..

Надписью ошибся конечно- LPC2387 на самом деле.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Вопрос- RTC_CCR= ?? чтоб часики затикали с часового кварца, ато никак не получается пока ???

В дальнейшем я тоже на ARMы хочу перейти, но пока нет возможности и времени.
С AVR 8 я уже разобрался, примерно что к чему уже знаю.

Похвастаю и я

Что,откуда,почём?

LCD LS020 - siemens cx65 200р целый телефон
LCD PCD8544 - nokia 100 руб
Etherus http://www.evodbg.com/index.php?option= ... &Itemid=49

И самое интересное- платка что за?

[quote="SII"]Satyr, без всякого холивара

Пять баллов!!! Изучаю ARM7, использую LPC2103 пока пишу на С, так как примеров на ASM-е не нашел. На сколько я посмотрел на ARM-ассемблер смысла в Си совсем не вижу (даже по объему текста). Единственно, что я получил – так это подорванную нервную систему. Что опыта на СИ у меня маловато - это факт, но как мне показалось, что бы не делать ошибки на Си, так это надо вообще не иметь представления а внутренней структуре ядра. Так как то, что выбрасывает Keil после компиляции, у меня ощущение, что я теннисный мячик прошиваю. После выброшу примеры. По поводу опыта, было бы не плохо чтобы его программисты NXP(Philips) поднабрались.
Так как по их примерам складывается впечатление, что те кто пишет тех. документацию, вообще не общаются с разработчиками. Поссорились они что ли . До сих пор не могу понять как запретить прерывания, так как в Keil 4 на Asm –е этого сделать уже нельзя, а на Си (__disable_irq()) в железе не работает.

Интересно, причем тут программисты NXP ? И где вобще какие то следы их труда ты смог отыскать ? -)))

Нельзя сделать в асме ? -)) В асме можно сделать всё, что имет отражение в системе комманд процессора -))

Можно только посоветовать поднабраться опыта. И внимательней читать даташиты. Тот же асм при системе комманд ядра ARM7TDMI с его то ~40 коммандами это 0.01% программирование. А регистры и порты конкретного МК - оставшиейся 99.99%

MRS r0,CPSR
ORR r0,r0,#192
MSR CPSR,r0

Разобрался с внутренними часами- регистр управления тактированием поставил так-RTC_CCR = 0x1011 и затикало с часового кварца.

Satyr, я так понял, что у человека проблема с использованием асма, встроенного в Си, а не голого. Тут можно посоветовать только внимательно изучить документацию (хелп) -- она мне показалась довольно приличной (во всяком случае, по сравнению с рядом других средств программирования).

Смотрел я этот Keil - какой то он 'плюшевый' - какие то мастера да визарды и прямые настройки глубоко скрыты -))
Вобщем если что, в IARе все приятно и понятно, в том числе и с ассемблером

Обьясните на пальцах,как включить прерывания

__enable_irq() в IARе

Неправильно вопрос поставил- чтобы прерывание таймера0 например заработало еще что то включить там надо?-вот например в примере из книжки-

В Кейле визард что то там сам делает,непонятно что там потом включить надо-а что не надо,похоже лучше на IAR перейти.

А правда,что там так можно?-
IO1DIR_bit.P1_20=1;