[dxp 34]

Отладчиком (JTAG) не пользуюсь по причине отсутствия свободных выводов. Наблюдаю визуально по программе: перестает реагировать на кнопки и не выводит результат на экран через очередь сообщений.

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

 

А в чем же дело? Два процесса ждут Signal, каждый от своего EventFlag. В процессах после Wait() идет Sleep(). Когда из третьего процесса (из п. меню) даю ef1.Signal() и ef2.Signal() для процессов, то все виснет. В смысле остальные процессы не работают. Что я делаю не так ? :05:

Не могу сказать, "удаленно лечить не умею" :). Попробуйте на симуляторе прогнать, возможно, там можно будет увидеть проблему.

 

Про OS::EventFlag мы знаем только один баг, и он проявляется в ситуации, когда два процесса ждут одновременно одного и того же флага. Общего утвержденного решения пока нет - есть частные, но они имеют проблемы с совместимостью поведения. Наиболее близким к желаемому вариантом является bug_1878045_fix, но он пока как следует не оттестирован, ждет своей очереди. Но два отдельных непересекающихся флага - это не сюда.

 

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

[alux 0]

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

 

PS. Перед отправкой в канал сделал проверку свободного места:

          if(MsgQueue.get_count() < 3)
            MsgQueue.push(&ReDraw);

Проверил. Проблема осталась. Т.е. когда два процесса ждут каждый свой EventFlag , то при подаче Сигналов из третьего процесса, программа виснет. То же самое и для одного общего флага. Кроме этого не могу понять, почему максимально возможное значение АЦП 0xffffff , которое я отправляю через очередь сообщений для TProcLCD, на индикатор выводится 0x4b7fffff. В данным момент в канал больше никто ничего не посылает. Проверял printf действительное значение АЦП перед запуском ОС (0xffffff) ? :(

 

 

PS2. Так, это уже слишком... При входе в пункт меню устанавливаю глобальный флаг (не EventFlag): Flags |= MEASURE; В процессе TMeasure в качестве отладки использую инвертирование знакоместа на ЖКИ и printf:

OS_PROCESS void TMeasure::Exec()    //TProc1
{
    for(;;)
    { 
      monitoring.Wait();
      
//      while(Flags & MEASURE)
      for(unsigned char i=0;i<20;i++)
      {      
        PCInt1.Wait();    // Ждем окончания преобразования АЦП (RDY => 0)
        //measure();  
        MsgQueue.push(&Blink);
        printf_P("\n\rFlags: %d\n", Flags);
        Sleep(500);
      }
    }
}

Выяснилось, что после нулевой итерации Flags = 1, а после первой Flags=0 ! При этом в других процессах нет обращений к Flags. Что за... :07: Почему обнуляется глобальный флаг?

[alux 0]

Прошу прощения за невнимательность. Проблема с обнулением глобального флага связана с использованием ф-ции printf.

 

PS. Кстати, этот маленький эксперимент с printf натолкнул меня на мысль, что возможная проблема с неправильным выводом данных на ЖКИ (0x4b7fffff вместо 0xffffff) связана с тем, что в реализации ReDraw используются функция-"пожиратель" стека: sprintf_P. А под процесс ProcLCD, в котором используется этот метод выделено 200 байт. Необходимо заменить sprintf на что-нибудь полегче. И к тому же это могло приводить к зависанию программы. Я прав?

[Gradient 1]

Хочу поинтересоваться, это только у меня не запускается симулятор IAR в проекте с scmRTOS, или так и должно быть?

[IgorKossak 0]

... в реализации ReDraw используются функция-"пожиратель" стека: sprintf_P. А под процесс ProcLCD, в котором используется этот метод выделено 200 байт. Необходимо заменить sprintf на что-нибудь полегче. И к тому же это могло приводить к зависанию программы. Я прав?

Более чем правы.

 

Хочу поинтересоваться, это только у меня не запускается симулятор IAR в проекте с scmRTOS, или так и должно быть?

У меня запускается и симулятор и эмулятор.

А без scmRTOS запускается? Или что Вы понимаете под фразой "не запускается"?

[Gradient 1]

Тестировал на примерах scmRTOS v3 AVR.

Изменил только настройки для работы с симулятором.

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

Но старт отладки не происходит. Стал искать наличие *.d90, его нигде нет .... хотя в окне workspace он присутствует. Открыл несколько своих старых проектов, там симулятор работает без проблем.

 

Подумал, что в EWL версии ввели ограничение на размер кода.

Установил полную версию IAR 5.10a

Результат тот же - ни в одном примере c scmRTOS симулятор не работает и *.d90 не создаётся... :(

[IgorKossak 0]

sevstels, приложите к сообщению файл проекта (.ewp) и файл .ewd с настройками отладчика.

[Gradient 1]

Пока пытаюсь найти причину сам.

Вот нашёл вот тут:

http://scmrtos.sourceforge.net/releases/avr/

 

-DENABLE_BIT_DEFINITIONS

-I$TOOLKIT_PATH$\AVR\inc

-I$TOOLKIT_PATH$\AVR\inc\dlib

 

TOOLKIT_PATH - отсутствует такое определение в IAR5.10

Есть TOOLKIT_DIR, см EWAVR_UserGuide.pdf стр 263(303)

 

DENABLE_BIT_DEFINITIONS - тоже не нашёл такого нигде..

а вот ENABLE_BIT_DEFINITIONS есть

[IgorKossak 0]

DENABLE_BIT_DEFINITIONS - тоже не нашёл такого нигде..

а вот ENABLE_BIT_DEFINITIONS есть

Это одно и то же (одно в xcl файле, другое в настройках).

Опцию линкера -D смотрите.

[Ykidia 0]

Здравствуйте! Есть небольшой проектик под scmRTOS, ранее созданный для IAR EWARM 4.41, микроконтроллер LPC2148. Поставил EWARM 5.11 для пробы, но как-то не удается сделать так, чтобы, как и раньше, в векторах по адресам #00-#3F мирно сосуществовали как части из стандартного cstartup, так и части из OS_Target_asm. Поменял сегменты на секции, ORG на LTORG и т.д., но при компиляции в векторах присутствует либо только код из cstartup (т.е. нет частей ОС для программного и аппаратных IRQ/FIQ прерываний), либо только из OS_Target_asm (т.е. по 0-му вектору например находится какой-то мусор). Пытался менять :ROOT(x) в строках объявлений секций, что и приводило к вытеснению либо содержимого cstartup.s, либо OS_Target_asm.s.

Что нужно сделать либо есть может у кого уже адаптированный OS_Target_asm.s для EWARM 5.11 ? Спасибо.

[spf 0]

Что нужно сделать либо есть может у кого уже адаптированный OS_Target_asm.s для EWARM 5.11 ? Спасибо.

 

Господа! Ну зачем все пихать в одну тему ?????

 

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

PS:

А еще лучше задать вопрос в рассылке scmRTOS.

[Ykidia 0]

Хорошо-хорошо, уже создал. Зачем кричать-то? :)

[Gradient 1]

Игорь, в общем, ничего к сожалению не получается.

Файл *.d90 создаётся, но симулятор всё равно не работает.

prj.zip

[IgorKossak 0]

Игорь, в общем, ничего к сожалению не получается.

Файл *.d90 создаётся, но симулятор всё равно не работает.

С Вашими настройками симулятор запустился и работает.

Попробуйте отключить опцию Debugger->Setup->Setup macros на случай если подхватываются левые макросы. Отключите плагины Debugger->Plugins если они криво встали. Если ничего не поможет, переустановите продукт.

[Gradient 1]

Если ничего не поможет, переустановите продукт.

 

Ничего не помогло, переустановка тоже.

А спасло простое нажатие на кнопочку "Factory Settings" по пути: Project->Options->Simulator->Factory Settings. Странно конечно, нет там вроде никаких установок. Но заработало ... :07: