Начало работы with scmRTOS, Несколько вопросиков Опции

[dxp]

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

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

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

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

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

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

[alux]

Вроде нашел еще один свой прокол : Скорость поступления данных из 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. Что за... Почему обнуляется глобальный флаг?

[alux]

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

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

[sevstels]

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

[IgorKossak]

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

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

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

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

[sevstels]

Тестировал на примерах scmRTOS v3 AVR.
Изменил только настройки для работы с симулятором.
Компилируется идеально, без ошибок или предупреждений.
Но старт отладки не происходит. Стал искать наличие *.d90, его нигде нет .... хотя в окне workspace он присутствует. Открыл несколько своих старых проектов, там симулятор работает без проблем.

Подумал, что в EWL версии ввели ограничение на размер кода.
Установил полную версию IAR 5.10a
Результат тот же - ни в одном примере c scmRTOS симулятор не работает и *.d90 не создаётся...

[IgorKossak]

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

[sevstels]

Пока пытаюсь найти причину сам.
Вот нашёл вот тут:
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]

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

Это одно и то же (одно в xcl файле, другое в настройках).
Опцию линкера -D смотрите.

[Ykidia]

Здравствуйте! Есть небольшой проектик под 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]

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

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

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

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

[Ykidia]

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

[sevstels]

Игорь, в общем, ничего к сожалению не получается.
Файл *.d90 создаётся, но симулятор всё равно не работает.

Прикрепленные файлы

 prj.zip ( 5.42 килобайт ) Кол-во скачиваний: 45

 

[IgorKossak]

Игорь, в общем, ничего к сожалению не получается.
Файл *.d90 создаётся, но симулятор всё равно не работает.

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

[sevstels]

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

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