WINAVR

Здравствуйте, Уважаемый Leha!

Thu Sep 22 2005 08:57, Leha Bishletov wrote to Olga Nonova:

ON>> С-компилятор IAR сохраняет в том примере статус-регистр SREG не в ON>> стеке, как положено всем грамотным системам, а в R17. Теперь ON>> представьте, что в теле ISR произведен вызов подпрограммы на Си

LB> ...

LB> Тогда он сохранит его в стеке. Такая легкость в выборе наиболее LB> оптимального алгоритма сохранения SREG и не снилась программистам на LB> ASM.

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

ON>> А вот в мануалах ON>> C-компилятора GNU прямо и честно говорится, что ISR не гарантируют ON>> сохранность контекста при вызове из их тела сторонних подпрограмм. ON>> Иными словами, GNU-шники честно признали невозможность отследить ON>> сохранность контекста ISR в этом случае.

LB> Это говорится о программах на ASM или с ASM вставками или LB> компилированные другим компилятором, которые, естественно, не могут быть LB> проанализированы и о которых ни чего не известно.

Спасибо, Вы единственный, кто дал ответ без истерик и, главное, по-существу вопроса. К Вашим словам могу еще добавить, что в перечень опасных попадают еще и библиотеки в обьектных кодах. Причем библиотеки, скомпилированные тем же самым компилятором. Именно об этой ситуации предупреждают GNU-шники, когда говорят о запрете вызовов функций uCOS из тела ISR.

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Leha!

Thu Sep 22 2005 15:42, Leha Bishletov wrote to Olga Nonova:

ON>> Такая легкость маневров служит, по-моему, источником багов. Гораздо ON>> надежнее принять одно простое, пускай даже в отдельных случаях и ON>> неэффективное правило, но не становиться заложником "легкости ON>> маневрирования" компилятора.

LB> А еще лучше не отказываться от использования более удобного инструмента LB> из-за боязни, что он подведет. Компиляторы С давно уже выросли из LB> состояния "куча багов". Если есть какие-то опасения, то можно проверить LB> что он сгенерил. Почти всегда, все будет сделано как надо.

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

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

LB> Hет, библиотеки из под того же самого компилятора не могут создать LB> проблем.

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

ON>> Именно об этой ситуации предупреждают GNU-шники, когда говорят о ON>> запрете вызовов функций uCOS из тела ISR.

LB> А это, видимо, связано с нереентерабельностью функций uCOS, а не с LB> опасностью испортить какие-то регистры.

Имею некоторые возражения. Я получила GNU-пакет для M68K и наблюдаю, что freeware продукты представлены там в исходниках на С. uCOS в частности. При первом запуске MAKE любого прикладного проекта, компилятор изготавливает обьектные файлы всех включенных в проект модулей, считай библиотеку этой самой uCOS, которая в следующие разы уже не будет компилироваться (поскольку незачем). И вот, из расчета на последующие разы, авторы GNU компилятора ием не менее предупреждают- не пользуйтесь вызовами uCOS из тела ISR! Обратите внимание- работал один и тот же компилятор и все модули написаны в стандарте С, не на ASM! Если интересно, могу привести здесь точную цитату ихней фразы и ссылку на документ.

Всего Вам Хорошего Ольга

Fri Sep 23 2005 11:36, Andy Mozzhevilov wrote to Leha Bishletov:

AM> HÁÐpÉÍÅp, ËÏÍÐÉÌÑÔÏp ÍÏÖÅÔ Á×ÔÏÍÁÔÉÞÅÓËÉÅ ÐÅpÅÍÅÎÎÙÅ pÁÚÍÅÝÁÔØ ÎÅ × AM> ÓÔÅËÅ, AM> Á × ÐÁÍÑÔÉ (ËÏÍÐÉÌÉpÏ×ÁÎÎÙÊ ÓÔÅË), × ÜÔÏÍ ÓÌyÞÁÅ ÆyÎËÃÉÉ ÂyÄyÔ ÎÅ AM> pÅÅÎÔÅpÁÂÅÌØÎÙÍÉ.

èÍ, AFAIK ÓÕÝÅÓÔ×ÕÅÔ ÕËÁÚÁÔÅÌØ ÄÌÑ ÔÁËÏÇÏ ÓÔÅËÁ, É ÐÒÉ ËÁÖÄÏÍ ×ÙÚÏ×Å ÆÕÎËÃÉÉ ÏÎ ÂÕÄÅÔ ÉÚÍÅÎÑÔØÓÑ. ðÏ ÔÁËÏÊ ÓÈÅÍÅ ×ÓÅ ÂÕÄÅÔ ÎÏÒÍÁÌØÎÏ ÒÁÂÏÔÁÔØ, ÐÏËÁ ÜÔÏÔ ÕËÁÚÁÔÅÌØ ÎÅ ×ÙÌÅÚÅÔ ÚÁ ÐÒÅÄÅÌÙ ÏÂÌÁÓÔÉ, ÏÔ×ÅÄÅÎÎÏÊ ÐÏÄ ÓÔÅË. ó Õ×ÁÖÅÎÉÅÍ, äÅÎÉÓ

Fri Sep 23 2005 12:56, Denis Y. Borisov wrote to Andy Mozzhevilov:

AM>> HÁÐpÉÍÅp, ËÏÍÐÉÌÑÔÏp ÍÏÖÅÔ Á×ÔÏÍÁÔÉÞÅÓËÉÅ ÐÅpÅÍÅÎÎÙÅ pÁÚÍÅÝÁÔØ ÎÅ × AM>> ÓÔÅËÅ, AM>> Á × ÐÁÍÑÔÉ (ËÏÍÐÉÌÉpÏ×ÁÎÎÙÊ ÓÔÅË), × ÜÔÏÍ ÓÌyÞÁÅ ÆyÎËÃÉÉ ÂyÄyÔ ÎÅ AM>> pÅÅÎÔÅpÁÂÅÌØÎÙÍÉ.

DYB> èÍ, AFAIK ÓÕÝÅÓÔ×ÕÅÔ ÕËÁÚÁÔÅÌØ ÄÌÑ ÔÁËÏÇÏ ÓÔÅËÁ, É ÐÒÉ ËÁÖÄÏÍ ×ÙÚÏ×Å DYB> ÆÕÎËÃÉÉ ÏÎ ÂÕÄÅÔ ÉÚÍÅÎÑÔØÓÑ.

åÓÌÉ ÏÂÒÁÝÁÀÔÓÑ ÐÏ ÕËÁÚÁÔÅÌÀ, ÔÏ ÞÅÍ ÔÁËÏÊ ÓÔÅË ÏÔÌÉÞÁÅÔÓÑ ÏÔ ÏÂÙÞÎÏÇÏ? ëÏÍÐÉÌÉÒÏ×ÁÎÎÙÊ ÓÔÅË ÄÌÑ ÔÏÇÏ É ÄÅÌÁÅÔÓÑ, ËÏÇÄÁ ÐÏ ÕËÁÚÁÔÅÌÀ ÏÂÒÁÔÉÔØÓÑ ÎÅÌØÚÑ.

VLV

"óÐÅÛÉÔÅ ÄÅÌÁÔØ ÄÏÂÒÏ, ÐÏËÁ ÅÇÏ ÎÅ ÓÄÅÌÁÌÉ ×ÁÍ"

úÄÒÁ×ÓÔ×ÕÊÔÅ, õ×ÁÖÁÅÍÙÊ Andy!

Fri Sep 23 2005 08:47, Andy Mozzhevilov wrote to Olga Nonova:

ON>> óÐÁÓÉÂÏ. éÍÅÎÎÏ ÔÁË É ÐÏÓÔÕÐÁÀ- ÏÂÑÚÁÔÅÌØÎÏ ÐÒÏÓÍÁÔÒÉ×ÁÀ × ÌÉÓÔÉÎÇÁÈ ON>> ËÒÉÔÉÞÅÓËÉÅ ÍÅÓÔÁ Ó ÁÓÓÅÍÂÌÅÒÎÙÍÉ ËÏÄÁÍÉ, ÞÔÏ ×ÙÄÁÌ ËÏÍÐÉÌÑÔÏÒ. äÏ×ÅÒÑÊ, ON>> ÎÏ ÐÒÏ×ÅÒÑÊ!

AM> é ÍÎÏÇÏ ÂÁÇÏ× ËÏÍÐÉÌÑÔÏpÁ yÖÅ ÎÁÊÄÅÎÏ, ÍÏÖÎÏ ÏÐyÂÌÉËÏ×ÁÔØ ÉÈ ÓÐÉÓÏË?

ñ ÎÅÄÁ×ÎÏ ×ÌÅÚÌÁ × ó É ÂÁÇÏ× ÎÁÛÌÁ ÐÏËÁ ÎÅÍÎÏÇÏ. HÏ ÓÏÈÒÁÎÅÎÉÅ ËÏÎÔÅËÓÔÁ, SREG × ÞÁÓÔÎÏÓÔÉ, × ÓÁÍÉÈ ÖÅ ÒÁÂÏÞÉÈ ÒÅÇÉÓÔÒÁÈ, ËÁË ÔÕÔ ÕÖÅ ÐÏËÁÚÁÌ ËÏÌÌÅÇÁ âÅÌÏÕÓÏ× ÎÁ ÐÒÉÍÅÒÅ ó-IAR, ÜÔÏ ÚÎÁÅÔÅ ÌÉ... ÎÁ×Å×ÁÅÔ ÎÁ ÇÒÕÓÔÎÙÅ ÍÙÓÌÉ.

LB>>> á ÜÔÏ, ×ÉÄÉÍÏ, Ó×ÑÚÁÎÏ Ó ÎÅÒÅÅÎÔÅÒÁÂÅÌØÎÏÓÔØÀ ÆÕÎËÃÉÊ uCOS, Á ÎÅ Ó LB>>> ÏÐÁÓÎÏÓÔØÀ ÉÓÐÏÒÔÉÔØ ËÁËÉÅ-ÔÏ ÒÅÇÉÓÔÒÙ.

ON>> éÍÅÀ ÎÅËÏÔÏÒÙÅ ×ÏÚÒÁÖÅÎÉÑ. ñ ÐÏÌÕÞÉÌÁ GNU-ÐÁËÅÔ ÄÌÑ M68K É ÎÁÂÌÀÄÁÀ, ÞÔÏ ON>> freeware ÐÒÏÄÕËÔÙ ÐÒÅÄÓÔÁ×ÌÅÎÙ ÔÁÍ × ÉÓÈÏÄÎÉËÁÈ ÎÁ ó. uCOS × ÞÁÓÔÎÏÓÔÉ.

AM> uCOS - ÜÔÏ ÎÅ freeware, ×Ï ×ÓÑËÏÍ ÓÌyÞÁÅ, ÎÁÞÉÎÁÑ Ó ×ÅpÓÉÉ 1.10

HÅ×ÁÖÎÏ. á ×ÁÖÎÏ, ÞÔÏ Õ ÍÅÎÑ ÅÓÔØ ÉÓÈÏÄÎÉËÉ uCOS É ËÏÍÐÉÌÑÔÏÒ ÉÈ ËÏÍÐÉÌÉÒÕÅÔ ÓÏ×ÍÅÓÔÎÏ Ó ÍÏÄÕÌÑÍÉ ÐÒÉÌÏÖÅÎÉÑ. ðÒÉ ÜÔÏÍ, ÎÉËÁËÉÈ ÇÁÒÁÎÔÉÊ ÐÏ ÓÏÈÒÁÎÅÎÉÑÀ ËÏÎÔÅËÓÔÁ ÐÒÅÒÙ×ÁÎÉÊ Á×ÔÏÒÁÍÉ ÞÅÓÔÎÏ ÎÅ ÄÁÅÔÓÑ.

ON>> ðÒÉ ÐÅÒ×ÏÍ ÚÁÐÕÓËÅ MAKE ÌÀÂÏÇÏ ÐÒÉËÌÁÄÎÏÇÏ ÐÒÏÅËÔÁ, ËÏÍÐÉÌÑÔÏÒ ON>> ÉÚÇÏÔÁ×ÌÉ×ÁÅÔ ÏÂØÅËÔÎÙÅ ÆÁÊÌÙ ×ÓÅÈ ×ËÌÀÞÅÎÎÙÈ × ÐÒÏÅËÔ ÍÏÄÕÌÅÊ, ÓÞÉÔÁÊ ON>> ÂÉÂÌÉÏÔÅËÕ ÜÔÏÊ ÓÁÍÏÊ uCOS, ËÏÔÏÒÁÑ × ÓÌÅÄÕÀÝÉÅ ÒÁÚÙ ÕÖÅ ÎÅ ÂÕÄÅÔ ON>> ËÏÍÐÉÌÉÒÏ×ÁÔØÓÑ (ÐÏÓËÏÌØËÕ ÎÅÚÁÞÅÍ).

AM> ïÓÎÏ×ÎÁÑ ÉÄÅÏÌÏÇÉÑ uCOS - ÍÁÓÛÔÁÂÉpyÅÍÏÓØ ÎÁ ÜÔÁÐÅ ËÏÍÐÉÌÑÃÉÉ, ÐÏÜÔÏÍy AM> ÐÏÌØÚÏ×ÁÎÉÅ ÅÄÉÎÏÖÄÙ ÓËÏÍÐÉÌÉpÏ×ÁÎÎÙÍÉ ÏÂßÅËÔÎÉËÁÍÉ ÅÓÌÉ É ÎÅ ÎÅ×ÏÚÍÏÖÎÏ, AM> ÔÏ ËpÁÊÎÅ ÎÅyÄÏÂÎÏ. åÓÌÉ ËÏÎÆÉÇypÁÃÉÑ uCOS ÎÅ ÍÅÎÑÅÔÓÑ, ÔÏ make, ÏÔÓÌÅÄÉ× AM> ÚÁ×ÉÓÉÍÏÓÔÉ ÅÅ É ÎÅ ÔpÏÇÁÅÔ, É ×ÓÅ pÁÂÏÔÁÅÔ.

ðÒÅÄÌÁÇÁÅÔÅ ÎÅ ÐÏÌØÚÏ×ÁÔØÓÑ MAKE? ëÁÖÄÙÊ ÒÁÚ ×ÓÀ ÇÒÏÍÁÄÕ ÉÓÈÏÄÎÉËÏ× ËÏÍÐÉÌÉÒÏ×ÁÔØ?

ON>> é ×ÏÔ, ÉÚ ÒÁÓÞÅÔÁ ÎÁ ÐÏÓÌÅÄÕÀÝÉÅ ON>> ÒÁÚÙ, Á×ÔÏÒÙ GNU ËÏÍÐÉÌÑÔÏÒÁ ÉÅÍ ÎÅ ÍÅÎÅÅ ÐÒÅÄÕÐÒÅÖÄÁÀÔ- ÎÅ ON>> ÐÏÌØÚÕÊÔÅÓØ ON>> ×ÙÚÏ×ÁÍÉ uCOS ÉÚ ÔÅÌÁ ISR!

AM> :)))) á ÎÁÆÉÇÁ ÔÏÇÄÁ ÏÎÁ ÎyÖÎÁ, ÅÓÌÉ ÎÅ ÐÏÌØÚÏ×ÁÔØÓÑ? AM> ï Î Á Ö Å p r e e m p t i v e, AM> ÔÏ ÅÓÔØ ×ÙÚÙ×ÁÔØ ÓÅp×ÉÓÙ ÉÚ isr É ÐÏÄÎÉÍÁÔØ ÚÁÄÁÞÉ × ÎyÖÎÙÊ ÍÏÍÅÎÔ - ÜÔÏ AM> ÅÅ ÏÓÎÏ×ÎÁÑ ÆyÎËÃÉÑ.

äÁ, Ñ ÔÏÖÅ ÔÁË ÄÕÍÁÀ. ïÄÎÁËÏ, ×ÓÐÌÙÌÉ ÐÏÄ×ÏÄÎÙÅ ËÁÍÎÉ.

ON>> ïÂÒÁÔÉÔÅ ×ÎÉÍÁÎÉÅ- ÒÁÂÏÔÁÌ ÏÄÉÎ É ÔÏÔ ÖÅ ËÏÍÐÉÌÑÔÏÒ É ×ÓÅ ÍÏÄÕÌÉ ON>> ÎÁÐÉÓÁÎÙ × ÓÔÁÎÄÁÒÔÅ ó, ÎÅ ÎÁ ASM! åÓÌÉ ÉÎÔÅÒÅÓÎÏ, ON>> ÍÏÇÕ ÐÒÉ×ÅÓÔÉ ÚÄÅÓØ ÔÏÞÎÕÀ ÃÉÔÁÔÕ ÉÈÎÅÊ ÆÒÁÚÙ É ÓÓÙÌËÕ ÎÁ ÄÏËÕÍÅÎÔ.

AM> ïÞÅÎØ ÉÎÔÅpÅÓÎÏ.

÷ÏÔ Ä×Á ÏÔÒÙ×ËÁ ÉÚ ÍÁÎÕÁÌÁ ÐÏ ÒÅÁÌÉÚÁÃÉÉ ÐÒÅÒÙ×ÁÎÉÊ × C-GNU ÄÌÑ ColdFire. ÷ ÐÅÒ×ÏÍ ÐÉÛÕÔ: ...7 is the highest. Use caution with level 7, since it is unique in that it is a non-maskable interrupt. If you use level 7, the ISR cannot call any uCOS functions, or use the INTERRUPT( ) macro. úÄÅÓØ ÐÏÎÑÔÎÏ, ÞÔÏ level 7 ÉÓÐÏÌØÚÏ×ÁÔØ ÎÅ ÎÁÄÏ, ÅÓÌÉ ÈÏÞÅÛØ ÏÄÎÏ×ÒÅÍÅÎÎÏ ×ÙÚÙ×ÁÔØ ÉÚ ISR ÆÕÎËÃÉÉ OS. á ÔÅÐÅÒØ, ÞÔÏ ÍÙ ×ÉÄÉÍ ×Ï ×ÔÏÒÏÍ ÏÔÒÙ×ËÅ ÜÔÏÇÏ ÍÁÎÕÁÌÁ: /* WARNING WARNING WARNING Only a very limited set of RTOS functions can be called from within an interrupt service routine. Basically, only OS POST functions should be used. No I/O (read, write or printf may be called), since they can block. */ é ÞÔÏ ÔÅÐÅÒØ ÐÒÉËÁÖÅÔÅ ÄÕÍÁÔØ? ÷ÓÅÇÏ ÷ÁÍ èÏÒÏÛÅÇÏ ïÌØÇÁ