Hello, Pavel Berdashkewich! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 15 Oct 2005 18:21:34
+0400:
PB>>> Программа реального времени должна не _писаться_ быстро, а PB>>> _работать_.
DO>> Программа реального времени должна успевать за реальным DO>> временем.
PB> Совершенно верно! PB> А с учетом того, что ресурсов, как правило, всегда не хватает, PB> программа должна работать как можно быстрее.
Это очень сильно зависит от решаемых задач. Иногда приходится работать на пределе возможностей железа и вручную оптимизировать узкие места (причем не обязательно это именно на ассемблере делать, иногда можно и сишный код подрихтовать так, чтобы он компилировался в эффективные конструкции). А иногда именно по быстродействию есть приличный запас.
DO>> Быстрее ей не надо.
PB> Речь не идет о запасе в сотни процентов.
Разница в сотни процентов между результатами говорит о принципиально неправильном подходе в случае получения одного из них, а не о языке программирования.
PB> Если такой запас есть, то железо нагружается дополнительными PB> алгоритмами, либо удаляется лишнее железо.
Если это лишнее железо есть. Пример. Есть у меня разработка, уже довольно старая, где раньше стоял pic16c73 на 4 МГц. Используется почти вся его периферия и где-то
90% ROM (программа практически вся на С). Сейчас в это изделие ставится более дешевый 16f73, где он продолжает работать на 4МГц. Новое издели с очень похожей программой уже изначально разрабатывалось под 16f73 и там уже стоит кварц на 20 МГц (вопрос потребления в разумных пределах не стоит). Если в версии программы для 4МГц устройства я еще задумывался о том что написано в обработчике 1мс таймерного прерывания, то в 20МГц версии мне об этом думать уже совсем не приходится. Запас примерно десятикратный (он был примерно двукратный на 4МГц). Какое железо мне выкинуть и что я с этого получу? Какими алгоритмами его грузить, если программа во-первых все, что от нее требуется и так делает, а во-вторых уже занимает почти всю память?
dima
formatting link