Aner 5 30 марта, 2015 Опубликовано 30 марта, 2015 · Жалоба С# это условно копи пасте Java, но попозже. Сишники с двумя плюсами погнались за явовскими вкусностями типа гарбаш коллектора и тд и накатали свою решётку. TCP стек на ассемблер ну месяц от силы на М4, знаю американских перцев, которые только и пишут на асе под кортексы. Чуть дольше писать, чем на си, но такие челы имеются, и ценятся. Думаю от прикладных задач зависит. Зачем 10 лет ждать? Как только вы начнете портировать код с STM32F7 на Atmel SAM7S (или обратно), то вас тут же проберут такие корчи, что не разогнетесь. :) А вроде бы один и тот же M7. Архитектура то да, а вот фасад с заборами и решетками у каждого свой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 30 марта, 2015 Опубликовано 30 марта, 2015 · Жалоба Зачем 10 лет ждать? Как только вы начнете портировать код с STM32F7 на Atmel SAM7S (или обратно), то вас тут же проберут такие корчи, что не разогнетесь. sm.gif А вроде бы один и тот же M7. Но как только появиться операционка с удобным фреймворком и кто-то ее сделает для одного и другого проца, сразу будет достаточно код только скопировать... Надо заметить что в этом случае код написанный на Ассемблере завязнет гораздо капитальнее Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 48 30 марта, 2015 Опубликовано 30 марта, 2015 (изменено) · Жалоба В этом смысле я понимаю тех кто решил работать с ассемблером на Cortex. А я нет, во первых, асм хорош тогда, когда имея тини13 с кило флеша на борту, я делал считыватель 1wire на котором читал ключ, цифровой термодатчик, работал термостат с аналоговым задатчиком и все это передавалось по программному уарту. На сях это бы в память не влезло, а тут еще 250 байт осталось! На армах не вижу никакого смысла программить на асме, кроме вставок в си. Сколь вы будете программить сетевой стек типа lwip на асме, потому, что без него вы не попадете в ваши любимые облака А главное, зачем... С# - имеет автоматический сборщик мусора, больше не надо заботиться чтобы количество delete совпадало с количеством new - очень удобно. Много удобных типов, самописание типов. Int.Parse(....) - разбор строки в число. А как бонус идет то что программа компилируется не в машинные коды, а в промежуточный язык, в итоге программа становиться процесоро-независимым, на любом проце поднимите фреймворк, и запускай программы. Понятно, хотя считаю динамическое выделение памяти злом, особенно в работе с хардварными девайсами и в режимах хотплаг, особенно, но это о пичках, в ООП без нее не обойтись. А вот "процесоро-независимым" считаю вообще не особо актуальным, т.к. 99% програм на дотнетах пишутся под винду на х86 машинах... Изменено 30 марта, 2015 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба А смартфоны? А планшеты? Пополз микрософт и на другие платформы... На сях это бы в память не влезло, а тут еще 250 байт осталось! Откуда взялся миф что код на С всегда больше чем на Ассемблере? Он больше когда пишут быстро и просто, но если задаться целью убиться об размер.... Не забываем опять же что есть оптимизация, которая иногда делает удивительные чудеса) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба Откуда взялся миф что код на С всегда больше чем на Ассемблере? Он больше когда пишут быстро и просто, но если задаться целью убиться об размер.... Не забываем опять же что есть оптимизация, которая иногда делает удивительные чудеса) В некоторых случаях ручками можно получить код компактнее, но эти случаи очень уникальны. Например, 24-битная арифметика на AVR (из жизни). В мелких задачах (а именно такие задачи решают "моргальщики светодиодом"), КПД можно поднять чуть ли не в разы, но в серьезных проектах С-оптимизация уделает любой asm-код начального уровня. Помницо... лет 5 назад... мерялся с С в части подсчета md5 (Cortex-M3): взял алгоритм из описания и сбацал его на Си за пару минут. На asm пыхтел дольше и... проиграл. В итоге удалось чуть-чуть победить С, когда использовал команды групповой загрузки регистров из памяти. С учетом полного объема кода выигрыш оказался мизерным. Вывод: asm в серьезных проектах нужно знать для чтения листингов, а не для разработки. Кста, в avr мне до сих под проще написать на asm (не забуду войну с С, когда нужно было написать с точностью до тактов soft-UART передатчик). Кста2, а генерацию VGA картинки (прием символов по UART и отображение их на VGA-мониторе) для cortem-m3 делал на C без единой asm-строчки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба Я смотрю развиваются несколько стандартных войн: 1) AVR vs ARM / Cortex 2) IAR vs KEIL 3) ASM vs C (как же без этого) Правда развиваются вяло, так как энтузиастов уже маловато. ))) По моему сейчас уже даже оптимизацией вручную на среднем проекте нет смысла заниматься. Компилятор хорошо оптимизирует наиболее распространённые языковые конструкции. Начинаешь умничать - иди смотри результат компиляции. Не факт, что он будет лучше. А в целом, самое дорогое - это время. Тратить год на перенос проекта под ASM, по моему преступление против себя. Выигрыш будет ровно такой, какой будет за счёт выхода нового проца за это же время. )) Я M7 позиционирую для работы с TFT. В своё время был знаменитый LPC2478 - сделал на нём проект. Потом появился нога в ногу LPC1788 на кортексе, так только за счёт шинной архитектуры был выигрыш процентов на 20%. Это было даже визуально видно на дисплее 4.3" 480x272x16. Поскольку в целом даже этого камня хватало для более менее приличного проекта, то думаю М7 потянет 7", естественно без всякого видео. Ну я про stm. На М4 даже и не успел с TFT поработать. Уж больно сложный проект был. Более 2-ух лет. ))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба А в целом, самое дорогое - это время. Тратить год на перенос проекта под ASM, по моему преступление против себя. Выигрыш будет ровно такой, какой будет за счёт выхода нового проца за это же время. )) А это зависит от того какие ошибки чаще делаете. 90% времени это отладка. Если по любому во время отладки все смотрят скомпиленный код, то не лучше ли его сразу писать на asm? Здесь еще отягчающее обстоятельство может быть в том, что человек не использует нормальные инструменты для отладки вроде IAR или Keil-а, а сидит на голом GCC. У того тоже могут быть серьезные причины. Так что у каждой войны свой контекст, просто надо в нем разобраться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба Это вялое разжигание указанных войн, но неплохой вброс для следующей. У меня больше времени уходит на архитектуру. А при хорошей архитектуре отладка занимает мизерное время. Дольше тратиться на написание стандартных тестов, проверки функциональности устройства. Из всего этого мне ни разу не удобнее на АСМе потому что дольше, и текст хуже читаем. Ошибки которые не учитывает архитектура - это системные, то есть функционал который не был учтен, а такие ошибки опять же легче править при нормальном удобно написанном проекте... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба Если по любому во время отладки все смотрят скомпиленный код, то не лучше ли его сразу писать на asm? Во время отладки я смотрю на отладочную консоль через UART. Иногда попадаются HardFault с указанием адреса проблемной инструкции - только в этом случае и смотрю листинг, чтобы понять в какой функции рухнуло. Уж точно не борюсь за такты и за байты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 42 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба SAM V71 Xplained Ultra Evaluation Kit Atmel уже выпустил демо-плату для V71 (это почти как E7, только автомобильный)! Цена $136.25 в партии из 10 шт. Тут User Guide для нее, а тут на нее схемы, герберы и прочая документация. Под S70 и E70 тоже обещают такого же вида платы выпустить, но пока ничего конкретного не нашла. Но плата получилась очень симпатичная. На нее сверху, как на Arduino, можно свою самоделку водрузить, благо разъемчики для этого есть. http://www.atmel.com/tools/ATSAMV71-XULT.aspx Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RabidRabbit 0 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба Как только вы начнете портировать код с STM32F7 на Atmel SAM7S (или обратно), то вас тут же проберут такие корчи, что не разогнетесь. :) А вроде бы один и тот же M7. Тут, наверно, ачипятка - SAM7S всё же ARMv4T, полноценный ARM :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
A. Fig Lee 0 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба В некоторых случаях ручками можно получить код компактнее, но эти случаи очень уникальны. Например, 24-битная арифметика на AVR (из жизни). В мелких задачах (а именно такие задачи решают "моргальщики светодиодом"), КПД можно поднять чуть ли не в разы, но в серьезных проектах С-оптимизация уделает любой asm-код начального уровня. Зависит. Вот sdcc для CC2530 (8051) такой код производит, что хочется обнять и плакать.. Ну понятно, он же клепает дженерик и не пользует все его свистульки для облегчения жизни: второй DPTR, восемь банков Rx регистров.. Но когда читаю асм код.. Не знаю, не пробовал IAR для этого.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 42 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба Тут, наверно, ачипятка - SAM7S всё же ARMv4T, полноценный ARM :) Да, по ошибке вместо SAM S7 написала SAM7S. Свой пост поправила. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 48 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба А смартфоны? А планшеты? Пополз микрософт и на другие платформы... Откуда взялся миф что код на С всегда больше чем на Ассемблере? Он больше когда пишут быстро и просто, но если задаться целью убиться об размер.... Не забываем опять же что есть оптимизация, которая иногда делает удивительные чудеса) Да пусть ползет куда хочет, но львиная доля - это псишники под виндой. Миф берется из реальности, ибо та же самая прога, с учетом оптимизации и т.п. не влезала на 100 байт... Мое предположение - происходила инициализация "по умолчанию" того, что мне было не нужно, си, как правило много bitbang-операций заменяет на код "прочитал-изменил-записал", когда нативно это делается 1 командой, ну и вход-выход в прерывания, как правило сохраняет больше регистров, а на асме можно сэкономить, выделив регистры в "глобальное" использование, без сохранения... Во время отладки я смотрю на отладочную консоль через UART. Иногда попадаются HardFault с указанием адреса проблемной инструкции - только в этом случае и смотрю листинг, чтобы понять в какой функции рухнуло. Уж точно не борюсь за такты и за байты. Полностью поддерживаю, ибо сначала скелет проги делаю на бумаге, разбиваю на модули, затем пишу модуль и проверяю его, после написания всех модулей, проверяю сборку. В асм код смотрел только дважды - 1) когда делал бутлоадер, 2) когда делал переключатель задач. Для всего остального есть консоль, либо жк-индикатор, или экран. За такты и байты не борюсь, но если есть возможность сделать код оптимальнее - не отказываюсь. Я M7 позиционирую для работы с TFT. В своё время был знаменитый LPC2478 - сделал на нём проект. Слабоваты они для дисплеев, разве, что только в качестве более расширенных жк-индикаторов. Чтоб был нормальный дисплей и на нем не было слайд-шоу, нужно по крайней мере ддр2или3 и какой-либо апп. ускоритель. Я смотрю развиваются несколько стандартных войн: 1) AVR vs ARM / Cortex 2) IAR vs KEIL 3) ASM vs C (как же без этого) Каждое для своей категории: 1) авр для мелких задач, арм для задач быстродействия, сети, дисплеев 2) на любителя, я выбрал иар, т.к. считаю, что у него более путная иде и неплохой компилятор. 3) си уже дефакто везде, на чистом асме "ваяют" только маньяки... Кста2, а генерацию VGA картинки (прием символов по UART и отображение их на VGA-мониторе) для cortem-m3 делал на C без единой asm-строчки. Ну если сам делал это на меге128, на асме правда, то уж кортекс-то с этим на раз-два справится Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 31 марта, 2015 Опубликовано 31 марта, 2015 · Жалоба а на асме можно сэкономить, выделив регистры в "глобальное" использование, без сохранения... Хорошие RTOS-ы (MQX) имеют спец опции для управления объемом сохраняемого контекста. 3) си уже дефакто везде, на чистом асме "ваяют" только маньяки... Не забываем про поддержку очень старого оборудования. Например в RTOS NuttX штатно идет эмулятор команд Z80. Вот эмуляция всяких зайлогов тоже интересная тема для M7. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
