Выставить биты данных на ШД Микроши в диапазоне 8000H-BFFFH

[Ведущий_специалист]

Подключал как то stm к рк86, проблемы такой не было, была другая проблема, стм банально не успевал войти в прерывание по сигналам RD или WR. Пропуская обращение и получалась каша. А так - да, коллеги выше правильно подсказали - неправильно настроены порты микроконтроллера.

[Advertiser]

[HardWareMan]

Т.е., прерывания продолжают стрелять, ок. А RCC гарантированно настроен правильно?

[xintrea]

Т.е., прерывания продолжают стрелять, ок. А RCC гарантированно настроен правильно?

Ты код смотрел? Нет там никаких прерываний. В новой версии (еще не заливал) я даже добавил при инициализации, как у тебя:

int main(void)
{
    clockInit();
    portClockInit();
    disableGlobalInterrupt();
    ...
}

// Остановка глобальных прерываний
void disableGlobalInterrupt(void)
{
    __asm volatile (
        "CPSID	f\n"
    );
}

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

И еще я провел два чистых эксперимента. Решил, что коль установка 0x00 оптимизируется, то надо сделать две вещи:

• Собрать весь проект с -O0,
• Устанавливать в первом случае 0x0F вместо 0x00 (все равно мы мониторим старший бит, и при 0x0F в нем так же будет 0), чтобы не срабатывала оптимизация установки 0x00.

Так я и сделал. Сборка с 0x0F и 0xFF стали отличаться только в единственном месте, вот так:

<  80004b2:     b292            uxth    r2, r2
<  80004b4:     f442 6270       orr.w   r2, r2, #3840   ; 0xf00
---
>  80004b2:     f062 02ff       orn     r2, r2, #255    ; 0xff
>  80004b6:     b292            uxth    r2, r2

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

Странная конструкция orr.w r2, r2, #3840; 0xf00 действительно дает 0x0F, можно сравнить с таким примером:

LCD_DATA_PORT->BSRR=0x00FF0000 | (sColor&0x00FF);
0x08000bbe:   orr.w r7, r7, #16711680 ; 0xff0000

Так что показали эти два чистых эксперимента? Да то же самое. Установка с 1 на 0 дает "провал" в ~120нс. Установка с 0 на 1 дает "полочку" в ~700нс. Объяснить почему так я своим скудным умишком не могу.

Ну и самый первый вопрос остался: почему установка с 1 на 0 такая короткая? По алгоритму отпускание удерживания нуля не может начаться раньше, чем желтая линия вернется к единице. Вначале STM должен увидеть, что /32К или /RD не 0, и только после этого отпустить удерживать 0. А на деле этого не происходит. И почему так - тоже не ясно.

- - - Добавлено - - -

Еще важно, какие оптимизации включены при компиляции (ключи -o в GCC, например).

Выше написал, сделал проверку с -O0.

[tnt23]

Еще важно, какие оптимизации включены при компиляции (ключи -o в GCC, например).

[tnt23]

if(workAddrDiapason!=0) // Если сигналы /32К и /RD физически не установлены в 0

Мне думается, что тут не "и", а "или" (хотя бы один из /32K или /RD не установлен)

[HardWareMan]

if(workAddrDiapason!=0) // Если сигналы /32К и /RD физически не установлены в 0

Мне думается, что тут не "и", а "или" (хотя бы один из /32K или /RD не установлен)

У него перед этим стоит это:

uint32_t workAddrDiapason = GPIOA->IDR & (GPIO_IDR_IDR10_Msk | GPIO_IDR_IDR11_Msk)

И 0 там будет только если оба в нуле будут. А условие выше срабатывает на 1 для отключения шины, иначе включает и эта ветка после else.

[xintrea]

И 0 там будет только если оба в нуле будут. А условие выше срабатывает на 1 для отключения шины, иначе включает и эта ветка после else.

Да, именно так. В if-ветке обрабатывается ситуация когда не оба в нуле, там режим ножки выставляется как input чтобы не влиять этой ножкой на подключаемую схему. В else-ветке включается режим выхода и выставляется нужное значение на ножке (в эксперименте-1 выставляю 0, в эксперименте-2 выставляю 1).

Для варианта выставления нуля (эксперимент-1), этот ноль выставляется на слишком короткое время. Ноль должен удерживаться как минимум до момента восходящего фронта на желтой линии. После этого еще нужно время чтобы STM-ка поняла, что не оба сигнала в нуле, и только после этого перестать удерживать ноль. А по графику мы видим, что ноль перестает удерживаться гораздо раньше. И почему так происходит, я не могу понять.

[tnt23]

Еще из мыслей навскидку - не доверяю локальным переменным с областью видимости в пределах ветки цикла. Попробуйте вынести объявление переменной повыше, или вообще сделайте ее статической/volatile.

uint32_t workAddrDiapason

[xintrea]

Еще из мыслей навскидку - не доверяю локальным переменным с областью видимости в пределах ветки цикла.

Новое слово в программировании? Нельзя же так к алгоритмизации относиться.

Но! Я проверю, я готов поверить в любую дичь.

[Serg6845]

Новое слово в программировании? Нельзя же так к алгоритмизации относиться.

Но! Я проверю, я готов поверить в любую дичь.

надо брать листинг того что нагенерил компилятор и вникать. возможно просто бага компилятора.
и еще - я бы для проверки перенес кусок кода со 165 по 181 строки в район 145 строки. чем-то мне этот кусок подсознательно не нравится...