Выбор пути ... Assembler или C ? Опции

[Kalina]

Всем добрый день!

Недавно начал осваивать микроконтроллеры фирмы ATMEL. Первое с чем имел дело - AT90S2313, теперь перешёл на ATmega. Проэкты в основном небольшие (думаю это времено), пользуюсь AVR Studio. Язык, который использую - assembler. Часто посещаю форум, и особо часто попадаю на программы написанные на С.
Так вот, хочу задать вопрос всем, кто чувствует себя уже уверенными пользователями обоих языков, вы не могли бы обьяснить начинающему:

1. почему люди переходят с assemblera на C?
2. какие плюсы и минусы языка С?
3. где без языка С нельзя обойтись?
4. лично ваше мнение относительно обоих? (ненормативная лексика принимается:-)

Всем, кто отзовется, заранее благодарен!

[zltigo]

Для начала, дабы не раздувать в 999 раз флейм пройдитесь поиском по форуму.

[Vladimir_J]

Добрейшее время суток!!!
В свое время я тоже сильно раздумывал переходить или не переходить на Си, когда попробывал оценил
Представте Вы ехали на мерседеце, и Вам говорит содись на велосипед мол это класно свежий воздух, здоровье, а мерседец это же конфортнее. (Этой фразой можно объяснить разницу между ASM и Си).

А так просто надо попробывать, и Вы ивидите в чем разница.

А Вам удачи в Ваших начинаниях.
С Уважением, Владимир.

[SasaVitebsk]

Вот чисто практические данные.
http://electronix.ru/forum/index.php?showtopic=43498 к примеру.

[Omen_13]

Очередная религиозная война назревает?

На асме можно делать простые конструкции с предельным быстродействием за счёт использования особенностей архитектуры и команд, на С математика и навороченные платформонезависимые алгоритмы.
В теории конечно можете написать для себя математику с точкой на асме, но лучше потратить это время на освоение С...
Моё мнение - надо знать оба языка. ИМХО!!!


-----------
Уважаемый zltigo, в этой войне на меня не расчитывайте!

Сообщение отредактировал Omen_13 - Mar 3 2008, 21:08

[zltigo]

Очередная религиозная война назревает?

Только попробуйте!

[Omen_13]

zltigo, см. выше!

Добавлю еще:
Асм как язык привязан к семействам - насколько я помню 51, АВР и ПИКи по командам отличаются довольно капитально, т.е. при смене практически всё придётся писать с 0. Зная только асм вы принудительно ограничиваете себе "область применения". При написании проги больше 4 кБ надо очень постараться не наклепать ошибок.
С другой стороны при использовании С вы вносите элемент неизвестности - кто знает как компилятор разложит команды в машинный код и какие при этом могут возникнуть ошибки по вине разработчика компилятора (шашкой махать не буду - об этом уже говорили/спорили).
Изучить аппаратные особенности применяемого процессора всё равно придётся в не зависимости от того какой язык С или асм

[Дон Амброзио]

ИМХО, ассемблер - это база, которую ДОСКОНАЛЬНО должен знать любой программист-эмбеддер, считающий себя профессионалом. Если человек "плавает" в ассемблере, то (ИМХО конечно) он и на СИ не сможет написать хорошую программу для Target MCU. Потому что в отличии от писателей программ для компов, которые (если они не пишут низкоуровневые драйвера) больше решают задачи по обработке информации разработчики программ для микроконтроллеров рещают задачи управления железом и обработки сигналов в реальном времени

ИМХО, сначала нужно досконально изучить архитектуру и АСМ ( который является отражением архитектуры MCU ), а уж потом пиши на чём хочешь: хоть на СИ, хоть на Паскале, хоть на Басике...Хоть на Смаллталке наконец

[Дон Амброзио]

насколько я помню 51, АВР и ПИКи по командам отличаются довольно капитально, т.е. при смене практически всё придётся писать с 0.

Из опыта. А если проект написан на СИ разве не придётся всё писать практически с нуля?

Если Вы не пишите конечно какую-нибудь универсальную RTOS на продажу в которой априори закладывается возможность портирования на несколько архитектур.

А так. По-большому счёту большинтсво программ для MCU - это программы уникального применения, предназначенные для конкретного MCU в конкретном девайсе.

А насчёт переписывания с нуля? Я за много лет работы выработал целый ряд принципов организации программы, которые определяют какой набор мудулей должен быть в программе и как организовать алгоритм. А зная их написать код на любом языке - это плёвое дело. Я, например, легко портировал свою RTOS на АСМ-е с 51-й архитектуры под AVR. Разработка RTOS под 51 -ю архитектуру у меня заняла более полгода. А переписывание её под AVR заняло чуть больше недели....

Так что не с нуля

[rv3dll(lex)]

Си так и не смог выучить - не дано наверное



но что точно что если проект в упор работает на ассемблере (было много случаев, когда считал команды пропробывал несколько вариантов
это было в системе некоторой обработки, где 256 раз в секунду приходили новые данные с 12 каналов и в соответствии с частотой уже стоявшего контроллера на обработку можно было потратить 1100 циклов - меньше чем 100 циклов на канал) а там надо было умножать делить искать экстреммумы сравнивать с порогом сортировать расчитывать порог по шуму складывать в буфер и передавать по последовательной линии
это уже экстримальное программирование но параллельно каждой ассемблерной команде стояла её длительность и количество циклов от начала

на си этого сделать нельзя, задачи подобного рода не решаемы

[608]

Всем, кто отзовется, заранее благодарен!

Си конечно лучше, но Ваша проблема, видимо, это отсутствие хорошего компилятора Си и еще, наверное, некому ввести в курс дела.
Рекомендую IAR (для AVR) и Keil (для 51), все это есть с лечениями. Что характерно, просматривая листинги асм-кода после компиляции, Вы еще лучше начнете писать программы на ассемблере. А также делать асм-вставки в Си-коды, в критичных местах. Но это уже высший класс, для этого надо много стараться и ковыряться в интернете, а также надо найти рядом помощника, чтобы подсказал.

Сообщение отредактировал 608 - Mar 4 2008, 07:03

[ReAl]

на си этого сделать нельзя, задачи подобного рода не решаемы

Ну, это и на тираж предполагаемый смотреть надо...
Если ожидаемый тираж пусть 1000 штук, зарплата программиста пусть 1000 баксов, протолчётся на асме считая такты он пусть лишний месяц - итого можно спокойно брать процессор на 2 бакса дороже и спокойно писать на С. Это будет как минимум не убыточно (затраты на программиста больше получаемой им зарплаты, надо ещё о сопровождении подумать).
Числа можно двигать туда-сюда и думать, стоит ли оно того.
А также не мешает проштудировать "историю одного байта" и подумать о том, что время сейчас несколько другое, если вдруг плнадобится не 256, а 320 раз в секунду или не с 12 а с 16 каналов - разрабатывать всё заново?

Конечно, есть крайние случаи - типа такого: тираж предполагается 10000/месяц, среднерыночная цена изделия так мала, что каждый цент на счету, из соображений потребления и быстродействия приходится каждый такт экономить - и это всё одновремённо.
Но что-то мне говорит, что в большинстве случаев это не так, на асме пишется по привычке/из любвы к искусству и можно или всё написать на С, или только критические 5% написать на асме.

[Baser]

У вас в корне неправильное понимание вопроса: "Выбор пути ... Assembler или C ?".

Это неправильно, потому что правильно: "Выбор пути: Assembler ==> Assembler и C ==> Assembler и C++ ==> То_Что_Дальше_Придумают"

То, что начали с ассма, хорошо. Без его знания правильно писать на Си будет трудно: в листинг на ассме частенько заглядывать приходится. А дальше - исходя из задачи по быстродействию: укладывается программа на Си по быстродействию в нужные рамки - тогда чистый C/C++. Не укладывается - критические секции на ассме. Вот и вся философия пути

[Dog Pawlowa]

Вот и вся философия пути

Да и философии тут нет никакой.
Один только момент - если вовремя не задуматься, как по другому можно сделать проект - значит потерять перспективу.

[rv3dll(lex)]

Ну, это и на тираж предполагаемый смотреть надо...
Если ожидаемый тираж пусть 1000 штук, зарплата программиста пусть 1000 баксов, протолчётся на асме считая такты он пусть лишний месяц - итого можно спокойно брать процессор на 2 бакса дороже и спокойно писать на С. Это будет как минимум не убыточно (затраты на программиста больше получаемой им зарплаты, надо ещё о сопровождении подумать).
Числа можно двигать туда-сюда и думать, стоит ли оно того.
А также не мешает проштудировать "историю одного байта" и подумать о том, что время сейчас несколько другое, если вдруг плнадобится не 256, а 320 раз в секунду или не с 12 а с 16 каналов - разрабатывать всё заново?

Конечно, есть крайние случаи - типа такого: тираж предполагается 10000/месяц, среднерыночная цена изделия так мала, что каждый цент на счету, из соображений потребления и быстродействия приходится каждый такт экономить - и это всё одновремённо.
Но что-то мне говорит, что в большинстве случаев это не так, на асме пишется по привычке/из любвы к искусству и можно или всё написать на С, или только критические 5% написать на асме.

тираж был единичный - 3 экземпляра - на самом деле это НИР
другой процессор поставить и изготовить новый образец никто бы не дал - ВПК блин - он наверное там до сих пор стоит)))

, да и стоимость его была не на 2 доллара больше речь о TMS2406 и TMS2812 5 лет назад они только появились.

скорость написания - согласен
знаковая арифметика не беспокоит
функций навалом
можно быстро написать работающий проект не беспокоясь о забытых переменных и LDP

[tntsasha]

Сначала писала на асме. После того как пробывал на С, про асм даже не вспоминаю. Действительно, как с велосипеда на мерс.

[researcher]

По теме:
http://ru.wikipedia.org/wiki/Си_(язык_программирования)
http://ru.wikipedia.org/wiki/Ассемблер

1. почему люди переходят с assemblera на C?
>>> Не знают ASM, задача использовать только Си, большой проект (в плане рутины),
причин может быть много .

2. какие плюсы и минусы языка С?
>>> Зависит от задачи (так сразу сказать нельзя).

3. где без языка С нельзя обойтись?
>>> Си – это фундамент. Разве можно что-то серьёзное построить без фундамента?

4. лично ваше мнение относительно обоих? (ненормативная лексика принимается:-)
>>> Оба надо знать.

ЗЫ
Тут многие сравнивают мерседес с велосипедом. Но на велосипеде можно проехать там, где мерседесу и не снилась даже.

[Carbon]

1. Си очень сильно экономит время разработки, экономит время затрачиваемое на поддержку старых проектов, многие написанные вещи (интерфейсы, протоколы обмена и др.) легко и быстро переносимы с контроллера на контроллер и даже на персоналку и обратно. На Си реально писать даже для очень мелких контроллеров без RAM или с микроскопическим RAM в 64байта.

2. Плюсы:
+легко читаемый и изменяемый исходник,
+безопасность (ограничение области видимости для переменных, контроль синтаксиса языка и соответствия типов данных со стороны компилятора),
+легкость работы со структурированными данными (с точностью до бита),
+динамическое использование памяти под переменные,
+битовые и низкоуровневые операции,
+наличие стандартного набора библиотек,
+можно в текст исходника на Си включать кусок на ассемблере,
+много чего ещё...
Минусы:
-сложность изучения некоторых вещей - арифметика указателей, выделение памяти,
-естесственно, что в критически важных по скорости и по объему кода вещах Си не уместен,
-компиляторы Си обычно стоят денег.

3. Без Си кодирование навароченных и длинных алгоритмов займет много времени, потеря которого не оправдывается когда мегагерц и памяти много. Если мечтаете в будущем произвольно менять мк.платформы, то нарабатывайте для своих задач исходники на Си.

[zltigo]

Тут многие сравнивают мерседес с велосипедом. Но на велосипеде можно проехать там, где мерседесу и не снилась даже.

Впомнился анекдот времен освоения выпуска "Жигулей". Концовка такая - "и чего только не придумают эти русские, что-бы не строить хороших дорог".

[rv3dll(lex)]

тойота - управляй мечтой
жигули не ссы доедем)))))

я наверное сильно отстал от жезни
раньше систы ругались, что для работы с отдельными битами если контроллер их поддерживает - приходилось работать с масками читать потом записывать или вставки на ассемблере - сейчас изменилась ситуация?

[Сергей Борщ]

раньше систы ругались, что для работы с отдельными битами если контроллер их поддерживает - приходилось работать с масками читать потом записывать или вставки на ассемблере - сейчас изменилась ситуация?

Сейчас они изучили препроцессор - вся морока раз и навсегда прячется в десятке макросов. Да и уровень оптимизаторов не стоит на месте: вон сколько криков "верните мне мой код!" ;)

[Kalina]

Да, вы меня убедили, что всё-таки С изучать прийдётся. Видно я правильно сделал, то начал с asm@, теперь его нужно укрепить, чтоб навсегда остался в памяти, как азбука, а вот тогда и начинать вникать в сишку. Проблемой в изучении С я пока вижу различного вида "глюки" и "приколы" , которые встречались при начале изучения контроллеров и по мере уменьшались. Хорошо, что алгоритм работы моего проэкта пока не оперирует большими объёмами данных, а требуют временной точности, вплоть до тактов.
Насколько я понимаю прогресс двигает нас вперёд (частоты, разрядность, объёмы), как вы думаете в будующем останется место простым 8 разрядным контроллерам? Или они полностью "исчезнут" , а для работы с тем, что появится, без языка высокого уровня не обойтись?

[Omen_13]

8 битники останутся, только их ниша может сократиться - тяжелые процы станут дешевле.

[vshemm]

У Си есть еще один большой плюс - портируемость . Особенно это заметно в тех проектах, где математики много.
К тому же, использование Си совсем не означает отказ от ассемблера.
Вывод: нужно уметь пользоваться и тем и тем и знать плюсы-минусы каждого

[singlskv]

как вы думаете в будующем останется место простым 8 разрядным контроллерам? Или они полностью "исчезнут" ,

что бы вам не говорили местные модераторы
но я пока еще не видел 32бит контроллеров с 6,8,14,20,28 ногами

когда появятся, возможно я полностью перейду на 32бит, хотя еще желательно, 20ма току не только
с 4 ног... а с любых...

а насчет C vs Asm, Asm нужно просто знать, а писать можно на любом языке, но
лучше конечно на С...

[DimaD]

Kalina привет!!! Надо знать и Си, и асм. Проще тогда будет переходить от одного типа контроллеров к другому (я имею ввиду AVR и MSP). Си это скорость написания программ, но больше по обьему кода. В конце концов, можно делать вставки асма в Си. Я сегодня уделю время для Си. Попробую кое-что. Пиши в аську!

[ReAl]

да и стоимость его была не на 2 доллара больше речь о TMS2406 и TMS2812 5 лет назад они только появились.

Ну так я же и говорю, что числа можно двигать. Тираж не 1000 шт, а 300шт - уже $6 разницы незаметно, тираж 100шт - уже $20 незаметно...
Просто далеко не всегда это понимает руководство. А иногда и не только руководство. Я сам иногда "да чё там, ну назачем для такой прикидки ставить явно в 4 раза превышащий по ресурсам кристалл", а потом ну не так, чтобы мучаюсь, но неудобство испытываю .

что бы вам не говорили местные модераторы
но я пока еще не видел 32бит контроллеров с 6,8,14,20,28 ногами

Luminary Micro LM3S101/102 - 28 ног ARM,

LM3S101-IRN20 ARM, 20MHz, 8kB flash, 2kB RAM, 2x32-bit Timers, RTC, 1xCCP, 1xUART, 1xSSI/SPI, 2xCMP, 2..18 GPIO, -40..+85C, 28-pin SOIC

В Киеве (Элтис) ~11грн (5.05грн/$) за штуку, <10грн мелкий опт.

По поводу велосипед vs мерседес.
Ну, С как раз не мерседес. Мерседесы где-то там около питона. С - это склад всякого барахла, из которого можно при нужде по-быстрому слепить то фордик, то "Ниву" какую (уже можно найти на осенних сельских дорогах места, где велосипед и не пройдёт), то танк небольшой. И ехать по асфальту на форде быстрее велосипеда, и по наглухо заросшему кустарником склону (там, где велосипед едет верхом на велосипедисте - с асмом часто такая аналогия бывает) проехать на танке и ещё и после себя дорогу оставить, по которой в сухую погоду и велосипедисты поедут (это я об отладить быстро алгоритм на С, а при нужде выписать критические части на асме).
Конечно, железа ;) это всё потребует больше, чем велосипед.

Итого я на велосипеде катаюсь (в обеих обсуждаемых смыслах ) для удовольствия и чтобы тонус не терять.
А на работу... На метро , в это время машины в пробках местами двигаются медленнее пешехода.
Это если бы я катался пусть не на уровне участника тур-де-Франс, но где-то близко - то я бы велосипедом зарабатывал, а для развлечения что-то другое придумал бы

[Kalina]

Проще тогда будет переходить от одного типа контроллеров к другому (я имею ввиду AVR и MSP).

Добрый день, DimaD!

А вы бы не могли объяснить подробнее, что значит проще ? Это означает, что можно будет не влазить в дебри MSP, а поверхностно его изучить? Или я чего-то не так понял.

[DimaD]

Приведу пример на тех двух программистах, которые выполняют нам некоторые заказы. Один из них -- схемотехник (очень классный), второй -- программист (еще лучше). Зная Си, им ничего не стоит написать программу (очень быстро) либо для MSP430F427, либо для ATtiny15. Конкретный контроллер выбирают из нужд прибора. Не влазя в дебри, они используют AVR и MSP. Асемблер для этих контроллеров сильно отличается. Вот так!

[Сергей Борщ]

Это означает, что можно будет не влазить в дебри MSP, а поверхностно его изучить? Или я чего-то не так понял.

Скажем так - при освоении последних нескольких семейств (x51, HC12, ARM7, PIC18) программа начинала делать осмысленные действия уже через полчаса после File->New (примерно столько нужно на прочтение документации по нужному периферийному модулю, например - портам, если хотим мигать светодиодом). А понимать, что написано на ассемблере в листинге я начал через несколько недель.
Точнее так: мой первый процессор был PIC16, для него я писал только на ассемблере. Вторым был x51. приступая к работе с ним я узнал, что для микроконтроллеров бывает С. С тех пор ассемблер для всех остальных процессоров я изучаю по листингам компиляторов. Последний раз для x51 писал 9, а для HC12 - 6 лет назад. Их ассемблер давно забыл. А исходники для них на С до сих пор читаю свободно.

[upc2]

Всем добрый день!

Недавно начал осваивать микроконтроллеры фирмы ATMEL. Первое с чем имел дело - AT90S2313, теперь перешёл на ATmega. Проэкты в основном небольшие (думаю это времено), пользуюсь AVR Studio. Язык, который использую - assembler. Часто посещаю форум, и особо часто попадаю на программы написанные на С.
Так вот, хочу задать вопрос всем, кто чувствует себя уже уверенными пользователями обоих языков, вы не могли бы обьяснить начинающему:

1. почему люди переходят с assemblera на C?
2. какие плюсы и минусы языка С?
3. где без языка С нельзя обойтись?
4. лично ваше мнение относительно обоих? (ненормативная лексика принимается:-)

Всем, кто отзовется, заранее благодарен!

Хорошо , что вы уже задумались. Значит сами до всего дойдете.

Программировать контроллеры Siemens можно на 9 языках. Вот здесь бы не запутаться.

[Kalina]

осмысленные действия уже через полчаса после File->New (примерно столько нужно на прочтение документации по нужному периферийному модулю, например - портам, если хотим мигать светодиодом).

Значит при переходи с одного семейства к другому, при использовании С, минимум необходимо будет знать основые параметры, указаные на первой странице даташита,(по ним прикидывать возможность использования данного контроллера в проэкте), а при необходимости, если ничего не получается , лезть глубже?

[DimaD]

Kalin@ смелее переходите на Си. Я уже мигаю светодиодами. Скачай WinAVR для Си, он поддерживается в AVRStudio последней версии.

[Сергей Борщ]

Значит при переходи с одного семейства к другому, при использовании С, минимум необходимо будет знать основые параметры, указаные на первой странице даташита,

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

Программировать контроллеры Siemens можно на 9 языках. Вот здесь бы не запутаться.

"Настоящие программисты пишут на Фортране на любом языке"

[zltigo]

"Настоящие программисты пишут на Фортране на любом языке"

Перефразируя эту классическую фразу - "Настоящие эмбеддеры пишут на ASM на любом языке"
и это к сожалению совсем не весело . По нынешним временам я бы предпочел работать с человеком который начинал с высокоуровневых языков. Ну а ASM уже потом от уровня "читаю и перевожу со словарем" можно при необходимости продвигать.

[upc2]

Перефразируя эту классическую фразу - "Настоящие эмбеддеры пишут на ASM на любом языке"
и это к сожалению совсем не весело . По нынешним временам я бы предпочел работать с человеком который начинал с высокоуровневых языков. Ну а ASM уже потом от уровня "читаю и перевожу со словарем" можно при необходимости продвигать.

10-я возможность Сиеменсов утилита Prodave предоставляющая все возможности управления контроллером для любого высокоуровнего языка в DLL-библиотеках.

[Kalina]

Я уже мигаю светодиодами

А слабо на С для меги8 реализовать измеритель скорости движения авто, управлением шаговым двигателем указателя стрелки, выводом на ЖКИ, обработку аварийных ситуаций и это всё в реальном времени. Но сама фишка заключается в том, чтобы уместить всё это в 2 кБ!!!!!!!!!!!

[Сергей Борщ]

Но сама фишка заключается в том, чтобы уместить всё это в 2 кБ!!!!!!!!!!!

Вот и объясняйте теперь - какая вам разница, записаны в остальные 6К флеша 0xFFFF или какие-то другие байты? При примерно одинаковом уровне владения С и АСМ одна и та же задача на С реализуется в несколько раз быстрее, чем на АСМ. Вот сэкономленное время я знаю куда деть, а сэкономленые 6К - ума не приложу... У меня был один проект, когда довольно большой кусок кода в дополнение к загрузчику надо было впихнуть в 2К область загрузчика. Код (и код загрузчика тоже) был за неделю написан и отлажен на всех 8К на С, потом были взяты ассемблерные файлы после компилятора и ужаты вручную. Ужимание заняло еще неделю. Я не представляю, сколько бы я писал это на ассемблере с нуля.

[Kalina]

Я не представляю, сколько бы я писал это на ассемблере с нуля.

Вы абсолютно правы. Проэкт, о котором я писал, сделали два человека, я и мой друг. Мы разделили его на две части. На это всё ушло около 6 месяцев. Самое трудное было при совмещении блоков. Мы уйму времени тратили для того, чтобы устранять "глюки". Приходилось отслеживать каждый регистр, даже байты в ОЗУ пересекались. Но теперь я для себе вынес один урок - если алгоритм составлен правильно, программа ВНИМАТЕЛЬНО!!!! написана, значит она будет работать с первой компиляции. Или, как говорят, правильно собраная схема в настройке не нуждается.
С одной стороны на С возможно писать было бы быстрее, легче( если бы я её знал ) но я почему-то ИМХО я бы не добился той точности и быстродействия, что требовалась.

[zltigo]

Но сама фишка заключается в том, чтобы уместить всё это в 2 кБ!!!!!!!!!!!

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

[singlskv]

Проэкт, о котором я писал, сделали два человека, я и мой друг. Мы разделили его на две части. На это всё ушло около 6 месяцев.

Наверное я чего то недопонимаю но 2Кбайта 6месяцев и еще на 2их ???

то есть, примерно 250 человекодней
2Кб <=> =<1024 команды на асм

то есть вы писали не более 4асемблерных команд за день ?

[Kalina]

Наверное я чего то недопонимаю

Сейчас я вам объясню, и вам всё станет понятно.

1. Разработка, которой мы занимаемся, первая в нашей практике, мы недавно только дипломы защитили . Сами же выступали в роли ведущих, так как начальника, который бы мог нас направить или нам помочь у нас не было.
2. Всё что нам предоставили на рабочем месте - это один компьютер на двоих, STK-500, осцилограф, паяльник и доступ в интернет.
3. По образованию мы радиотехники, и такая вещь как программирование МК было всего лишь нашим хобби в институте. Зная архитектуру атмела, его систему команд и ассемблер сложность состояла в написании алгоритмов и понимании функционирования всего устройства.
4. Эти 6 месяцев для нас скорее всего были временем показать, что мы справимся с разработкой, короче как испытательный срок !

то есть, примерно 250 человекодней
2Кб <=> =<1024 команды на асм
то есть вы писали не более 4асемблерных команд за день ?

5. Интересно, а сами вы пользуетесь таким методом подсчёта?

P.S. ИМХО есть ещё одно преимущество С, для неё написано много библиотек, или просто я плохо искал *.аsm ?

Сообщение отредактировал Kalina - Mar 5 2008, 19:15

[singlskv]

Сейчас я вам объясню, и вам всё станет понятно.
1. Разработка, которой мы занимаемся, первая в нашей практике, мы недавно только дипломы защитили . Сами же выступали в роли ведущих, так как начальника, который бы мог нас направить или нам помочь у нас не было.
............................

Ну, тогда все объяснимо и понятно, просто у Вас прозвучала фраза
"а слабо ли уместить в 2Кб......." , которая не очень вяжется с Вашим нынешним объяснением...
Учитывая Ваше объяснение, могу предположить что и на С можно влезть в те же 2К.

5. Интересно, а сами вы пользуетесь таким методом подсчёта?

Нет конечно, но просто есть какие то разумные рамки,
а те сроки которые указали Вы по крайней мере на порядок отличаются от реальных.

P.S. ИМХО есть ещё одно преимущество С, для неё написано много библиотек, или просто я плохо искал *.аsm ?

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

[DimaD]

С одной стороны на С возможно писать было бы быстрее, легче( если бы я её знал ) но я почему-то ИМХО я бы не добился той точности и быстродействия, что требовалась.

Вот именно, легче и быстрее, если владеть асмом и Си одинаково. А вот по поводу точности --- готов поспорить.
Вам ведь известно, что такое токоизмерительные клещи!!! Так вот, точность измерения тока 2%. Диапазон - 600А. При этом они сами калибруются (без всяких там подстроечников), и тоже обрабатывают кучу информации, TRMS, есть ЖКИ. Код на Си занимает 12 КБ!!!!!! Время от начала разработки до полного завершения прибора -- 3мес. Так на асме быстрее будет?
Просто я вот к чему веду. При переходе к созданию все более и более серьезных проектов, переход с асма на Си просто необходим.

[mart-13]

Вот именно, легче и быстрее, если владеть асмом и Си одинаково. А вот по поводу точности --- готов поспорить.
Вам ведь известно, что такое токоизмерительные клещи!!! Так вот, точность измерения тока 2%. Диапазон - 600А. При этом они сами калибруются (без всяких там подстроечников), и тоже обрабатывают кучу информации, TRMS, есть ЖКИ. Код на Си занимает 12 КБ!!!!!! Время от начала разработки до полного завершения прибора -- 3мес. Так на асме быстрее будет?
Просто я вот к чему веду. При переходе к созданию все более и более серьезных проектов, переход с асма на Си просто необходим.

Вы хотите сказать, что точность аппаратного АЦП контроллера, которым по всей видимости Вы измеряете Ваш ток зависит от Вашей программы, или еще хуже от языка, на котором она написана?????

[Kalina]

по поводу точности --- готов поспорить.

Я бы поспорил, но не на что !!!! Давай лучше обсудим: под точностью измерения скорости я подразумевал точность измерения временного интервала (измеряю же частоту). Так вот, мне необходимо измерять и выводить на ЖКИ скорость с точностью 0,1 км/ч. На скорости 220 км/ч (что соответствует частоте сигнала 421,5 Гц), изменение периода сигнала приблизительно на 1,2 мкс вызывает изменение скорости на 0,1 км/ч.

Но самое трудное организовать измерение с такой точностью в real-time параллельно с такими процессами:
1. Дижением стрелки прибора, используя шаговый двигатель в режиме микрошаге.
2. Организовать вывод на ЖКИ
3. Вести учёт аварийных ситуаций.
4. Вести учёт пройденого расстояния.

Задаю вопрос всем, кто работал с подобными вещами, возможно ли это реализовать на С?

[DimaD]

Давайте обсудим эту тему и многое другое за !!!
А то еще поссоримся.

[Kalina]

Давайте обсудим эту тему и многое другое за !!!

Давай обсудим эту тему здесь, а вот многое другое , кончено, можна и за пивом !

А то еще поссоримся.

!!!! -

[rv3dll(lex)]

БЛИН если на то пошло всю память 51 контроллера можно забить одинаковой командой инвертировать бит порта - один в том числе написать этот код и в векторах прерываний в смысле в месте которое для них отведено

при этом на обычном 51 с кварцем 12 мегагерц для ровного счёта с выхода этого порта пойдёт 500 килогерц, что в принципе невозможно сделать на си

я даже не уверен что с той же скоростью на си в смысле будет работать

метка "инвертировать бит"
джамп на метка, написанное на асме

извините не писал для 51 больше 5 лет - не помню команды

[zltigo]

Но самое трудное организовать измерение с такой точностью в real-time параллельно с такими процессами

У как все запущено . Используется аппаратный таймер который за время интегрирования в десятки - сотни миллисекунд считает имульсы. Количество последовательных интервалов интегрирования можно менять в заисимости от скорости для достижения нужной точности. Все оставшееся время можно играть вальсы Шопена.... В чем проблема? В обработке прерываний частотой не более, чем 421,5 Hz?

[Kalina]

У как все запущено . Используется аппаратный таймер который за время интегрирования в десятки - сотни миллисекунд считает имульсы. Количество последовательных интервалов интегрирования можно менять в заисимости от скорости для достижения нужной точности. Все оставшееся время можно играть вальсы Шопена....

Насколько мне позволяют понимать мои знания, вы привели пример электроно-счётного частотомера(последовательный метод)?
Диапазон скоростей, которые я измеряю, находится в интервале 3-220 км/ч. Для определения отсутствия сигнала V<3 км/ч(нулевая скорость), мне необходимо поставить ограничения на максимальный период входного сигнала 0.17 с. (прямоуголные импульсы с датчика скорости) Это означает меньше 5 импульсов в секунду, при необходимости обновлять ЖКИ минимум 2-3 раза в секунду(данные для стрелки обновлять ещё чаще), теперь вопрос а возможно ли будет таким методом отличить скорости 3 (Период следования импульсов = 0.177 с.) и 3,1 км/ч (Период следования импульсов = 0.172 с.), это как импульсы прийдётся считать?

[zltigo]

Насколько мне позволяют понимать мои знания, вы привели пример электроно-счётного частотомера(последовательный метод)?

Нет. Измерение длительности периода c возможными разборками c переполнения таймера/не срабатывания таймера на низких скоростях (когда времени много) и максимальными требованиями считывания-накопления значений таймера не чаще чем за две с лишним миллисекунды на скорости 220.

[mart-13]

Нет. Измерение длительности периода c возможными разборками c переполнения таймера/не срабатывания таймера на низких скоростях (когда времени много) и максимальными требованиями считывания-накопления значений таймера не чаще чем за две с лишним миллисекунды на скорости 220.

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

[Carbon]

Можно измерять период подсчитывая импульсы аппаратным таймером. Только на вход таймера подавать клоки от внутреннего генератора (например 1 или 8 или 16МГц клок, таймер 16 бит). Сигнал от датчика скорости подавать на вход прерывания, а по прерыванию считывать значения с таймера. Таким образом, двух импульсов с датчика скорости достаточно чтобы с точностью до длительности клока (62,5наносек) определить период импульсов с датчика скорости и сразу пересчитать их в км/час. Считанный счетчик сбрасываем в 0 и ждем следующего прерывания. Вся задача укладывается в двадцать строк на Си.

[Сергей Борщ]

Таким образом, двух импульсов с датчика скорости достаточно чтобы с точностью до длительности клока (62,5наносек) определить период импульсов с датчика

Если считывать значение из таймера в прерывании - то точность будет сильно ниже. А вот если использовать специально предназначенный для этого режим захвата (capture) таймера, то вполне реально. И на С и даже на Паскале (точно-точно, сам делал, правда, не по своей воле ).

при этом на обычном 51 с кварцем 12 мегагерц для ровного счёта с выхода этого порта пойдёт 500 килогерц, что в принципе невозможно сделать на си

я даже не уверен что с той же скоростью на си в смысле будет работать

метка "инвертировать бит"
джамп на метка, написанное на асме

Ну это не смешно. Отряхнул от пыли Кейл uVision 1.24, датированный 97 годом:

Код

#include <AT892051.H>                /* special function register declarations   */
                                     /* for the intended 8051 derivative         */
#define    Lampa    P1_0

void main (void)
{
    for(;;)
        Lampa = ~Lampa;
}
--------------------------------------------
            ; FUNCTION main (BEGIN)
                                          ; SOURCE LINE # 6
                                          ; SOURCE LINE # 7
                                          ; SOURCE LINE # 8
0000         ?C0001:
                                          ; SOURCE LINE # 9
0000 B290          CPL     P1_0
0002 80FC          SJMP    ?C0001
                                          ; SOURCE LINE # 10
0004 22            RET    
            ; FUNCTION main (END)

6 минут вместе с копированием результата в форум. Почти уверен, что можно как-то объявить функцию как noreturn и подавить ret. Ну а уж скопировать одну строчку на всю память что на С что на асме - труда столько же.

извините не писал для 51 больше 5 лет - не помню команды

Я не писал 6 или 7, команд тоже не помню, но задачу решил не заглядывая в даташит. А вам слабО? ;)

[rv3dll(lex)]

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

[Carbon]

Если считывать значение из таймера в прерывании - то точность будет сильно ниже. А вот если использовать специально предназначенный для этого режим захвата (capture) таймера, то вполне реально. И на С и даже на Паскале (точно-точно, сам делал, правда, не по своей воле ).

А если по прерываниям таймера от переполнения считать количество этих переполнений, то можно измерять очень и очень точно длительность очень-очень длинных импульсов.

[zltigo]

Калина уже разобрался с методами и алгоритмами измерений промежутков времени.

С алгоритмами-то разбираться не сложно - все уже придумано до нас. А вот с реализацией, похоже, нешуточные проблемы.

вообще я что-то не понял о чем вы толкуете, уважаемый zltigo: то вы считаете импульсы, то уже измеряете период...

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

[rv3dll(lex)]

из своего процессорного опыта - это было по необходимости - так я рассыпушечник 133-164ла3-7 и всё такое ,,,,,,,,,,,,,,,,,CPLD потом FPGA )))) может у меня был такой неправильный подход - все процессы должны выполняться параллельно - в процессоре псевдо параллельно

а именно нарисовать схему = нарисовать эпюры сигналов а далее команды по временной оси - вопрос с чередованием не снят

любые операции можно проредить командами с периферией

сейчас выглядит глупо))) но программы аонов конца 80х начала 90х в 4к пзу возможностями не страдали
сам писал по 400 кбайт на ассемблере под TMS

[Kalina]

Уважаемые форумчане, большое спаисбо за тот опыт работы с языками программирования, которым вы поделелись. Кто бы что не говорил, а знать, конечно, необходимо оба языка, иначе никогда не будет права выбора, так как выбирать будет не из чего . Конечным принятым решением было начало освоения С.
P.S. Какую литературу вы могли бы посоветать для начинающего? И ваше мнение о книге "Программирование на языке C для AVR и PIC микроконтроллеров" Шпак Ю.А.?

[Прохожий]

Уважаемые форумчане, большое спаисбо за тот опыт работы с языками программирования, которым вы поделелись. Кто бы что не говорил, а знать, конечно, необходимо оба языка, иначе никогда не будет права выбора, так как выбирать будет не из чего . Конечным принятым решением было начало освоения С.
P.S. Какую литературу вы могли бы посоветать для начинающего? И ваше мнение о книге "Программирование на языке C для AVR и PIC микроконтроллеров" Шпак Ю.А.?

Эту книгу советовали на этой площадке неоднократно, но я не поленюсь и посоветую ее Вам лишний раз:
Керниган, Брайан У., Ритчи, Деннис М.
Язык программирования С, 2-е издание.: Пер. с англ. - М.: Издательский дом "Вильямс", 2007. - 304 с.: ил. - Парал. тит. англ.
ISBN 979-5-8459-0891-9 (рус.)
ББК 32.973.26-016.2.75
К36
УДК 004.438
Покупал здесь приблизительно за 300 руб. Может есть где-нибудь еще подешевле...

[Сергей Борщ]

вопрос с чередованием не снят

В таких случаях я обычно говорю "И чтобы он еще за пивом бегал!"

сейчас выглядит глупо))) но программы аонов конца 80х начала 90х в 4к пзу возможностями не страдали

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

Керниган, Брайан У., Ритчи, Деннис М.
Язык программирования С, 2-е издание.:

Ее можно легко найти в Интернете (достаточно спросить у гугля "Керниган Ритчи"), например вот или вот, но нужно именно второе издание! С момента выхода первого издания язык очень сильно изменился.

[rv3dll(lex)]

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

я понял что это не моё и ушел сначала проц пдюс логика потом логика в проце а сейчас и программист пишет своё а я своё ))) и ответ на тему в 90 процентов случаев всё можно написать на СИ в 5 прочентах на ассемблере а в 5 оставшихся в грамотном подходе проектирования
и ещё в плисинах использую свой кодовый язык - при написании своего процессора - в плисинахпамять двупортовая - поэтому на 1 блок 4 кбита в альтере например вешаю 2 проца с разных сторон)) работа в кодах по таблице - это даже ниже ассемблера)))

[Прохожий]

Ее можно легко найти в Интернете (достаточно спросить у гугля "Керниган Ритчи"), например вот или вот, но нужно именно второе издание! С момента выхода первого издания язык очень сильно изменился.

К сожалению, так и не научился читать с экрана, а если печатать 289 страниц формата А4, то потом неудобно читать, да и по деньгам приблизительно то же и выйдет. Не сочтите за рекламу, но книга достаточно хорошо издана, текст программок структурирован, рисунки внятные, формат самый подходящий. Мне, лично, так удобнее.
К стати, что скажете о таком решении упр. 2.9 (подсчет числа единиц в байте) из этой книги?

Код

int bitcount (unsigned x)
{
int b=0;
while (x&=(x-1)) b++;
return b;
}

Сообщение отредактировал Прохожий - Mar 6 2008, 19:17

[Kalina]

вот или вот, но нужно именно второе издание!

Большое спасибо за ссылки, Керниган понятно и просто объясняет, приводя большое количество примеров. Уже печатаю !

да и по деньгам приблизительно то же и выйдет.

Если не секрет, где вы книги покупаете?

Сообщение отредактировал Kalina - Mar 6 2008, 20:35

[Прохожий]

Если не секрет, где вы книги покупаете?

А Вы по моей ссылке пройдите. Это книжный интернет-магазин. Оплата наложенным платежом.

[Pyku_He_oTTyda]

Прохожий

Спасибо! Хороший магазин с демократичными ценами.

[Demeny]

К стати, что скажете о таком решении упр. 2.9 (подсчет числа единиц в байте) из этой книги?

Код

int bitcount (unsigned x)
{
int b=0;
while (x&=(x-1)) b++;
return b;
}

Решение неправильное. Для числа 0x80, например, результат равен 0.

[Algol]

По поводу эффективного программирования на Си и для снятия многих вопросов из этой темы посоветую прочитать статью
Си без Си

[Demeny]

По поводу эффективного программирования на Си и для снятия многих вопросов из этой темы посоветую прочитать статью
Си без Си

Операторы ветвления.
Эти операторы встречаются в программах наиболее часто и, одновременно с этим, наиболее часто являются источником ошибок в программах.
............................
Сравнивая операторы while и do… while можно заметить, что второй оператор имеет на одну команду перехода меньше по сравнению с первым и, стало быть, его использование более предпочтительно.
.............................
Совет по оптимизации (C, asm): старайтесь там, где возможно, использовать оператор do…while.

Я плакалъ ... Керниган с Ритчей отдыхают.

[mdmitry]

Код

int bitcount (unsigned x)
{
int b=0;
while (x&=(x-1)) b++;
return b;
}

Посмотрите книгу "Алгоритмические трюки для программистов" Генри Уоррен

[andron86]

К стати, что скажете о таком решении упр. 2.9 (подсчет числа единиц в байте) из этой книги?

Код

int bitcount (unsigned x)
{
int b=0;
while (x&=(x-1)) b++;
return b;
}

я бы сказал вот так :-)

Код

int bitcount (unsigned x)
{
int b=0;
while (x){
x &= (x-1);
b++;
}
return b;
}

[zltigo]

Я плакалъ ... Керниган с Ритчей отдыхают.

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

[Прохожий]

я бы сказал вот так :-)

Код

int bitcount (unsigned x)
{
int b=0;
while (x){
x &= (x-1);
b++;
}
return b;
}

Я сделал вот так:

Код

unsigned char bitcount (unsigned char x)
{
unsigned char b=0;
if(x)
    {
    b=1;
    while (x&=(x-1)) b++;
    }
return b;
}

После трансляции получил следующее:

Код

979:               unsigned char bitcount (unsigned char x)
  0BA2    D912     RCALL 0xdc8
  0BA4    52E6     MOVF 0xfe6, F, ACCESS
980:               {
981:               unsigned char b=0;
  0BA6    6ADF     CLRF 0xfdf, ACCESS
982:               if(x)
  0BA8    0EFE     MOVLW 0xfe
  0BAA    50DB     MOVF 0xfdb, W, ACCESS
  0BAC    E011     BZ 0xbd0
983:                   {
984:                   b=1;
  0BAE    0E01     MOVLW 0x1
  0BB0    6EDF     MOVWF 0xfdf, ACCESS
985:                   while (x&=(x-1)) b++;
  0BB2    0EFE     MOVLW 0xfe
  0BB4    04DB     DECF 0xfdb, W, ACCESS
  0BB6    6E3C     MOVWF 0x3c, ACCESS
  0BB8    50D9     MOVF 0xfd9, W, ACCESS
  0BBA    0FFE     ADDLW 0xfe
  0BBC    6EE9     MOVWF 0xfe9, ACCESS
  0BBE    0EFF     MOVLW 0xff
  0BC0    20DA     ADDWFC 0xfda, W, ACCESS
  0BC2    6EEA     MOVWF 0xfea, ACCESS
  0BC4    503C     MOVF 0x3c, W, ACCESS
  0BC6    16EF     ANDWF 0xfef, F, ACCESS
  0BC8    50EF     MOVF 0xfef, W, ACCESS
  0BCA    E002     BZ 0xbd0
  0BCC    2ADF     INCF 0xfdf, F, ACCESS
  0BCE    D7F1     BRA 0xbb2
986:                   }
987:               return b;
  0BD0    50DF     MOVF 0xfdf, W, ACCESS
988:               }
  0BD2    52E5     MOVF 0xfe5, F, ACCESS
  0BD4    D192     BRA 0xefa

Компилятор МСС18, оптимизация включена. Кроме непонятно зачем вставленного MOVLW 0xfe в операторе if(х)... все остальное полностью соответствует концепции псевдостека, поддерживаемого этим компилятором. В связи с этим и некое разрастание кода.

Сообщение отредактировал Прохожий - Mar 7 2008, 19:53