> необходимо будет подсчитывать микросекунды

что имеется ввиду?

Забей.

Кто может - делает, кто не может - учит. (с)

Сдается мне, нечто подобное на ЛОРе уже было.

А «подсчитывать микросекунды» надо при помощи таймера и прерываний. Никакой разницы между сями и ассемблером не будет. Если же преподаватель «считает микросекунды» циклом, надеясь, что никакое прерывание ему не помешает, большой ему привет.

это неправда. на С можно подсчитывать и микросекунды, и вообще всё что хочешь. Мне удобнее на С писать, ассемблера вообще почти нет в коде.

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

разрабатываю устройства на базе pic-ов, преподаю на 0.5 в универе. ЧЯДНТ?

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

Уходи в другой универ или думай своей головой.

срабатывание определенной функции в строго заданный в мкс интервал времени

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

засыпание на тот же интервал времени

И такие функции есть. Смотря что за микроконтроллер.

Но реализовать это через циклы - извращение то еще (у меня, кстати, sdcc циклы с пустым телом вообще выбрасывал, за исключением основного цикла в main: while(1), что как бы наводит на мысль :) )

Спасибо успокоили,а то как-то после слов про проблемы сразу закрались сомнения, особенно в силу того, что поработать с самим МП возможно только раз в две недели. То бишь моё предположение о том, что просто решили незаморачиваться с С, а чтоб писал сразу на Асме как все- имеет основание быть) Пишу для ПЛИС на основе silicon с8051f120

Напиши два фрагмента кода, в одном на асме сгенерируй задержку на базе подсчёта тактов, во втором на C сгенерируй такую же задержку, сравни отработку по числу тактов, сравни асмовский код там и там.

поработать с самим МП возможно только раз в две недели

А руки не стоят собрать стендик с МП себе? Что за МП? из семейства 51-ых небось?

Хм.. А можно, если не сложно подсказать или хоть описать общую идею того как можно реализовать ограничение работы функции по времени? Потому как чувствую, что это точно мне пригодится $)

> срабатывание определенной функции в строго заданный в мкс интервал времени

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

засыпание на тот же интервал времени.

в цэ есть такая функция.

> Если же преподаватель «считает микросекунды» циклом, надеясь, что никакое прерывание ему не помешает, большой ему привет.

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

Если речь идет об освоении работы с каким-то МП, то таки да, его асм надо знать, хотя бы в общий чертах, даже если не программировать на нем.

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

+1, опередил.

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

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

Но задача написать код, выполняющий определенную задачу и вписывающийся в определенное количество тактов - тот еще Сизифов труд.

>>А можно, если не сложно подсказать или хоть описать общую идею того как можно реализовать ограничение работы функции по времени?
чтобы функия _завершилась_ за заданное время - man /dev/hands и /dev/brain. Автоматизировать это нельзя. Только написать и оттестировать профайлером.
Если же нужно квантование по времени, то man RTOS

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

Значит, плохой выбран компилятор :)

>>в цэ есть такая функция.
в цэ нет такой функции, потому что она есть в библиотеке, поставляемой вместе с конкретным компилятором (з.ы. человек-зануда)

>А руки не стоят собрать стендик с МП себе? Что за МП? из семейства 51-ых небось?

Стоят, да только денег в бюджете пока нет чтоб собрать себе стендик :(

Сильно зависит от того, что за МП и что за Си, может быть, речь шла о >том, что у того Си нет нужных функций и их надо писать на асме.

МП силиконовский и собственно IDE с компилятором их же.

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

Согласен, мозг хорошо вправляет, очень.

Смотря какой МК. Если банальный Picmicro, то да, имеет смысл написать на асме, ибо быстрее выйдет. Если какой-нибудь Si-Labs C8051F320 с USB и прочими штуками - то лучше писать на С, ибо удобнее и приятнее.

Насчет микросекунд - прерывания и таймеры никто не отменял. Все это делается без проблем. Мой МК (на ядре 8051) без проблем целкал с частотой 0,5 микросекунды. Проша написана на С.

>Пишу для ПЛИС на основе silicon с8051f120

Это на ПЛИС. ПЛИС - немного другое.

Если банальный Picmicro, то да, имеет смысл написать на асме, ибо быстрее выйдет

Не сказал бы: процедура элементарного управления шаговым двигателем (с подсчетом шагов, регулированием скорости вращения и напряжения и подобными «плюшками») на сях - довольно коротенький код; а вот на ассемблере это - длиннючая простыня. Причем, т.к. ассемблер более низкоуровневый, запутаться намного проще.

А оптимизирует sdcc вполне прилично (периодически читаю ассемблерные листинги, производимые им).

Ну мб мои знания устарели. Я когда-то во времена учебы писал как раз штуку для управления шаговым двигателем (видать, все через это прошли) именно на асме. Хотя мы как раз асм и проходили, так что тут все ясно.

А я такую штуку по работе писал - для дистанционного управления приборами :)

Вот такая штука вышла. Сейчас переходим постепенно на CAN-интерфейс. Менять напряжение хочу ШИМ'ом (чтобы не заморачиваться с многодиапазонными блоками питания).

> Если какой-нибудь Si-Labs C8051F320 с USB и прочими штуками - то лучше писать на С, ибо удобнее и приятнее.

Да, именно для него и пишу :) Согласен, что удобнее, но вот возник такой вот спор, потому и решил спросить совета у специалистов :)

мы пишем микроассемблере.

То что лучше писать на асме он конечно не прав (доказательство тривиально, есть множество задач, где на С пишется быстрей и удобней). Знать асм нужно (тоже тривиально, когда прогаешь для такого низкого уровня, должен понимать, что и как происходит с МК). Когда нужно формировать на выходах сигналы с точной привязкой ко времени, то без асма не обойтись. Например формирование четкой статичной картинки на экране монитора. Нужны тики, время исполнения команд и прочее битодрочерство. На С такое не напишешь (что бы там не говорили ололо-шники). В общем, учим и асм и С, при этом когда пишем на С, смотрим получившийся асм.

А то блин, потом появляются кадры которые везде и всюду вставляют деление и вещественные числа, а потом удивляются, почему так все медленно и криво.

> А «подсчитывать микросекунды» надо при помощи таймера и прерываний. Никакой разницы между сями и ассемблером не будет. Если же преподаватель «считает микросекунды» циклом, надеясь, что никакое прерывание ему не помешает, большой ему привет.

1) Прерывания можно явным образом запретить. Или их вообще может не быть в данном процессоре
2) Таймера тоже может не быть в данном конкретном МК

А вообще,

«Когда ты пишешь на ассемблере, ты разговариваешь с процессорами на их языке, и они могут поведать тебе много интересного ...» (с) (Один чел с wasm.ru)

:)

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

прерывания - полезная, но не обязательная фича :)

А все-таки, чем полезным может заниматься контроллер без прерываний?

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

ПЛИС - немного другое

Да что уж там: ПЛИС, микроконтроллеры, дискретная логика, транзисторы и реле --- всё суть одно и то же.

На самом деле, вещи принципиально разные в плане устройства и методов разработки. Другое дело, что на относительно жирной ПЛИС можно реализовать «софтовый» микроконтроллер.

Сообщение, разумеется, адресовано не вам, а ТС, не разобравшемуся, подо что он пишет.

P.S.

C8051F320

8051 RIP.

Спасибо, учту на будущее, просто предмет назвали микроконтполлерами, а выдали ПЛИС со словами: вперёд, за Родину, отсюда и путаница в голове, потому как раньше встречаться с этими «зверьми» недоводилось( Спасибо за ответы, теперь можно спокойно вздохнуть мне и взяться за дело) И вопрос не по теме, почему они rip? И насколько реально достать такую ПЛИС?

ПЛИС --- это программируемая логическая интегральная схема, русское название для PLD, собирательное название для FPGA, CPLD и прочего. Это этакий набор логических вентилей и функциональных блоков, которые пользователь может соединить между собой по своему желанию. Проекты на таких устройствах обычно выполняются с использованием языков описания аппаратуры, HDL. Это не программы в классическом понимании. Это --- формальное описание, на основе которого с помощью специальных САПР может быть синтезирована прошивка для ПЛИС. В итоге вы получаете микросхему, выполняющую нужные вам функции, зачастую параллельно. За подробностями --- в интернет.

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

Так что 8051 --- это не ПЛИС. Это семейство микроконтроллеров. А RIP это семейство потому, что древнее, и на данный момент у него имеется множество более продвинутых (и дешёвых) конкурентов в лице AVR, PIC, STM8, ну и, конечно, мелких ARM, на пример Cortex-M3, за которыми будущее.

Большое спасибо за краткий ликбез, буду мучать дальше Гугл в поисках инфрмации)

Большое спасибо за краткий ликбез, буду мучать дальше Гугл в поисках инфрмации)