Прикручиваю ось к LPC2478, Есть и будут вопросы) Опции

[haker_fox]

Добрый день, коллеги!

Скачал последнюю версию порта для LPC2xxx. К сожалению, на LPC2478 код не запускается, пришлось маленько пофиксить инициализацию периферии, немного ассемблера в одном из файлов ОСи. Вроде дело пошло. Задачи запускаются. Я не уверен в надежности и стабильности, пока тестирую.

Пока первый вопрос.

Как я понял, планировщик может вызываться из прерывания системного таймера и по софтовому прерыванию. Это задается опцией scmRTOS_CONTEXT_SWITCH_SCHEME. Мне кажется, что для LPC2478 софтовое прерывание не нужно. Достаточно таймерного. Я правильно понимаю? Т.е. можно использовать scmRTOS_CONTEXT_SWITCH_SCHEME = 0?

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

Спасибо!

[haker_fox]

Новое интересное поведение)
Программа работает великолено. Решил на LCD вывести картинку 480x272x24. На Питоне написал скрипт, который конвертнул картинку в const const

CODE

uint32_t logoImg[] = { ... }

. На каждый пиксель, естественно, 4 байта. Получил размер массива 272 * 480 * 4 = 522 240 байт. Массив находится в хидере, который цепляется к программе. Вот тут-то начинается интересный эффект...

При вызове функции OS::sleep или любой другой, вызывающий переключение контекста, программа виснет на время, много превышающее заданный таймаут. Затем, продолжает нормально работать. Причем на sleep у меня построен небольшой цикл, который выводит каждый 15 мс на экран точку (типа линейка, показывающая процесс). Так вот, одна точка висит вместо 15 мс около минуты, затем дорисовываются все точки с необходимой скоростью. Что интересно, если массив маленько урезать, килобайт этак на 30, то программа работает без нареканий. Картинка, конечно, выводится с артефактами.

Посмотрел, что линкер ложит массив "по середине" прошивки.

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

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

Спасибо! Извините, если немного сумбурно...

[AHTOXA]

Посмотрел, что линкер ложит массив "по середине" прошивки.

Попробуйте изменить имя массива на z_logoImg - ляжет в конец
На самом деле сильно вряд ли, что недопрыгивает. Думаю, что начав выполнять код картинки, проц бы уже ни за что не вернулся к нормальному выполнению программы.
Посмотрите размерности индексных переменных при обращении к массиву. Вдруг где не хватает?

[haker_fox]

Попробуйте изменить имя массива на z_logoImg - ляжет в конец
На самом деле сильно вряд ли, что недопрыгивает. Думаю, что начав выполнять код картинки, проц бы уже ни за что не вернулся к нормальному выполнению программы.
Посмотрите размерности индексных переменных при обращении к массиву. Вдруг где не хватает?

Теперь массив объявле так

CODE

const uint32_t z_logoImg[] = {

Вот, что видим в map-файле

CODE

.rodata._ZL9z_logoImg
                0xa0222160    0x7f800 ./obj/FDesktop.o

Секции в скрипте линкера объявлены так (все во внешней SDRAM)

CODE

MEMORY
{
    RAM (rw)    : ORIGIN = 0xA0600000, LENGTH = 512k
    FLASH (rx)    : ORIGIN = 0xA0200000, LENGTH = 1024k
}

Массив упорно ложится ну не совсем по середине, конечно, но реже прошивку на лапопам

При обращении к массиву используется цикл

CODE

        uint32_t* dst = ( uint32_t* )0xa0000000;

        for( int i = 0; i < 480 * 272; i++ )
            *dst++ = z_logoImg[ i ];

Вроде с индексами все в порядке

В общем такое ощущение, что размер массива сильно мешает. Но из расределения памяти видно, что никаким образмо область FLASH не может затереть область RAM, т.к. между ними 4 метра...

Блин, загадка!

[AHTOXA]

Массив упорно ложится ну не совсем по середине, конечно, но реже прошивку на лапопам

Странно. Если он в rodata, то всяко должен лежать после .text:

Код

        *(.text)                   /* remaining code */
        *(.text.*)                 /* remaining code */
        *(.rodata)                 /* read-only data (constants) */
        *(.rodata*)

Попробуйте убрать из цикла обращение к logoImg:

Код

        uint32_t* dst = ( uint32_t* )0xa0000000;
    for( int i = 0; i < 480 * 272; i++ )
            *dst++ = i;

Узнаем, кто виноват. Может видеобуфер тормозит.

[haker_fox]

Узнаем, кто виноват. Может видеобуфер тормозит.

Нет, видеобуфер точно не тормозит. Система виснет до вывода картинки. Извините, что не пояснил этот момент сразу. Сама картинка выводится "влет" А до вывода картинки происхоид основательная задержка в sleep, затем все sleep'ы отрабатываются правильно. Программа работает сутками, никаких ошибок...

Если обращение к массиву переместить в другое место к коду - проблема остается...

Кажется, я просчитался:
Если прошивка ложится с адреса 0xa0200000, а массив лежит с 0xa0222160, то он лежит после прошивки (она занимает 145760 байт). Т.е. после секции .text. Но все равно, последний адрес в map-файле это

CODE

text.align     0xa02a3188        0x0
                0xa02a3188                . = ALIGN (0x8)
                0xa02a3188                _etext = .
                0xa02a3188                _data_image = _etext

.data           0xa0600000      0x8d0 load address 0xa02a3188
                0xa0600000                . = ALIGN (0x4)
                0xa0600000                _data = .

Как я понимаю, это фрагмент нам позволяет убедится в том, что секция .data лежит очень далеко после секции .text Т.е. переменные и стек не могут затираться?!

Вставил в оську отладочный код

CODE

void TBaseProcess::sleep(timeout_t timeout)
{
    TCritSect cs;

    FHAL::halPrintf( "\r\nSleep 0" );
    Kernel.ProcessTable[Kernel.CurProcPriority]->Timeout = timeout;
    FHAL::halPrintf( "\r\nSleep 1" );
    Kernel.set_process_unready(Kernel.CurProcPriority);
    FHAL::halPrintf( "\r\nSleep 2" );
    Kernel.scheduler();
    FHAL::halPrintf( "\r\nSleep 3" );
}

На злосчастной функции выводится

CODE

Sleep 0
Sleep 1
Sleep 2

Т.е. висим прилично в шедулере, пока не знаю где.

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

CODE

Sleep 0
Sleep 1
Sleep 2
Sleep 3.
Sleep 0
Sleep 1
Sleep 2
Sleep 3.
Sleep 0
Sleep 1
Sleep 2
Sleep 3.
Sleep 0
Sleep 1
Sleep 2
Sleep 3.

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

В шедулере висим на этом

CODE

os_context_switcher(Curr_SP_addr, Next_SP);

Причем, если отладочного дебага добавить/убавить, то иногда не висим! Дело в выравнивании? Но, как мне кажется, в скрипте все настроено... Да и каким образом массив в конце может влиять на что-то за несколько строк кода до его чтения? Блин, я уже заинтригован

[Сергей Борщ]

В шедулере висим на этом

CODE

os_context_switcher(Curr_SP_addr, Next_SP);

Какой метод передачи управления используется? Если по прерыванию, то, возможно, какое-то прерывание на это большое время блокирует остальные и до вызова обработчика переключения контекста дело просто не доходит. Хотя, тогда висели бы в этом обработчике а не в переключении контекста. В общем надо копать в эту сторону - почему не вызывается прерывание переключателя контекста. И почему оно потом вдруг вызывается.

[haker_fox]

Какой метод передачи управления используется? Если по прерыванию, то, возможно, какое-то прерывание на это большое время блокирует остальные и до вызова обработчика переключения контекста дело просто не доходит. Хотя, тогда висели бы в этом обработчике а не в переключении контекста. В общем надо копать в эту сторону - почему не вызывается прерывание переключателя контекста. И почему оно потом вдруг вызывается.

У меня так

CODE

#define  scmRTOS_CONTEXT_SWITCH_SCHEME          0

Да уж... загадка на выходные...

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

CODE

T0TC = 0;

Сергей Борщ, долгих лет и счастья! Ваша наводка мне очень помогла! Теперь все работает прекрасно!

Очень интересно, как это связано с длинной массива?