Скорость ног SAM7, проблема с выводом Опции

[Iezuit]

Добрый день!
На AT91S64 начал программно (т.е. сам через порт, а не через стандартные функции периферии) выводить информацию на ноги частотой ~10-15 МегаГерц но, по осциллографу, выходит не более 1. Подскаже, я чего-то не понимаю или это ошибка, связанная с мои неправильными действиями?

[bureau]

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

[aaarrr]

На AT91S64 начал программно (т.е. сам через порт, а не через стандартные функции периферии) выводить информацию на ноги частотой ~10-15 МегаГерц но, по осциллографу, выходит не более 1. Подскаже, я чего-то не понимаю или это ошибка, связанная с мои неправильными действиями?

Программно можно выводить с частотой не более 1/4 MCK (две записи APB на цикл, каждая запись 2 такта MCK). Так что с 10-15МГц будут проблемы, но точно должно получаться больше 1.

[Iezuit]

Ниже привожу код (IAR). Прошу прощения, что не сделал сразу.

Код

#include <inarm.h>
#include "main.h"


void AT91F_LowLevelInit(void) @ "ICODE"
{//low_level_init

    AT91C_BASE_MC->MC_FMR = AT91C_MC_FWS_0FWS;

    AT91C_BASE_PMC->PMC_MOR = (( AT91C_CKGR_OSCOUNT & (0x40 <<8) | AT91C_CKGR_MOSCEN ));
    // Wait Main Oscillator stabilization
    while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MOSCS));

    AT91C_BASE_PMC->PMC_PLLR = AT91C_CKGR_USBDIV_1 |
                    (16 << 8) |
                               (AT91C_CKGR_MUL & (405 << 16)) |   //18.432*(405+1)/250=29.933
                               (AT91C_CKGR_DIV & 250);
    // Wait for PLL stabilization
    while( !(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_LOCK) );
    while( !(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY) );

    AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_PRES_CLK;
    // Wait until the master clock is established
    while( !(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY) );

    AT91C_BASE_PMC->PMC_MCKR |= AT91C_PMC_CSS_PLL_CLK;
    // Wait until the master clock is established
    while( !(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY) );

    AT91C_BASE_WDTC->WDTC_WDMR = AT91C_WDTC_WDDIS;
}



int main()
{

  AT91F_LowLevelInit(); //инициализируем рабочую частоту

//разрешаем периферические часы  
  AT91F_PMC_EnablePeriphClock(AT91C_BASE_PMC,(1 << AT91C_ID_PIOA)/);


AT91F_PIO_CfgOutput(AT91C_BASE_PIOA,SCREEN_DB|SCREEN_D_C|SCREEN_RES|SCREEN_WR|SCREEN_RD);

  AT91F_PIO_CfgDirectDrive(AT91C_BASE_PIOA,SCREEN_DB);

while (1)
  {
   AT91F_PIO_ClearOutput(AT91C_BASE_PIOA,SCREEN_WR);
AT91F_PIO_ForceOutput(AT91C_BASE_PIOA,0x5555<<16);
AT91F_PIO_SetOutput(AT91C_BASE_PIOA,SCREEN_WR);
    }  
  
}

Стандартная отладочная плата SAM7S64
При частоте - 30 MHz (от PLL, кварц - 18.432) в режиме Thumb, период главного цикла (по осциллографу) - 2 мкс, 0 на SCREEN_WR примерно 0.5мкс, 1 - 1мкс

в режиме ARM, период главного цикла (по осциллографу) - 2 мкс, 0 на SCREEN_WR 0.75мкс, 1 - 1.25мкс
Скложилось впечатление, что само обращение к порту происходит крайне медленно (ИАР обрезанный, ассемблер посмотреть не могу )
Предполагал, что АРМ должен обеспечивать большую скорость - ведь даже на меге результаты лучше!
Или я что-то делаю не так?

Сообщение отредактировал Iezuit - May 5 2008, 08:11

[aaarrr]

А оптимизация-то включена?

[Iezuit]

А оптимизация-то включена?

если я правильно понимаю, что оптимизация на компиляцию в режиме Debug влияет, то от включения оптимизации ничего не меняется.
При переносе содержимого цикла в RAM, период цикла сокращается до 1мкс

Сообщение отредактировал Iezuit - May 5 2008, 09:29

[bureau]

2 Iezuit
Неправильно понимаешь. Ты сравни с и без, и посмотри на АСМовский код что иар генерит.

Сообщение отредактировал bureau - May 5 2008, 09:37

[Iezuit]

2 Iezuit
Неправильно понимаешь. Ты сравни с и без, и посмотри на АСМовский код что иар генерит.

У меня к сожалению обрезанный по функциональности ИАР, и посмотреть асмовский код я не могу.
В прочем, разница при включении оптимизации нет только в режиме Thumb - на АРМ оптимизация помогает.
На АРМ оптимизацией получается 0.8 мкс на цикл. Все равно медленно

[amw]

Код

while (1)
  {
   AT91F_PIO_ClearOutput(AT91C_BASE_PIOA,SCREEN_WR);
AT91F_PIO_ForceOutput(AT91C_BASE_PIOA,0x5555<<16);
AT91F_PIO_SetOutput(AT91C_BASE_PIOA,SCREEN_WR);
    }  
  
}

Ну если чуть поразмыслить, то получается что-то вроде

Код

    ldr r0, =AT91C_BASE_PIOA
label:
    ldr r1, SCREEN_WR
    str r1, [r0 + КАК_ЕГО_ТАМ_PIOA_CLR]
    mov r1, #0x5555 lsl 16; Не уверен, что это можно mov
    str r1, [r0 + КАК_ЕГО_ТАМ_PIOA_SET]
    bic r1, r1, 0xFFFFFFFF; ??????
    str r1, [r0 + КАК_ЕГО_ТАМ_PIOA_CLR]
    ldr r1, SCREEN_WR
    str r1, [r0 + КАК_ЕГО_ТАМ_PIOA_SET]
    b label

Посчитайте такты.

[Iezuit]

Посчитайте такты.

Спасибо!
Скачал описание ассемблера с атмела и посчитал. Результат меня расстроил.
А есть ли какие-то альтернативные способы? Задача стоит так: обеспечить общение АРМ с OLED экраном по паралленому интерфейсу (8битная шина). На Меге приемлемая скорость получалось за счет использования механизма работы с внешней памятью (т.е. чтение и запись аппаратно устанавливались). А в АРМе есть какие-нибудь возможности несколько быстрее общаться с шиной?

[KAlex]

У меня к сожалению обрезанный по функциональности ИАР, и посмотреть асмовский код я не могу.

Это как? А куда ж листинги деваются?

[Iezuit]

Это как? А куда ж листинги деваются?

Не генерируются листинги, заблокирована эта возможность, т.к. ИАР - кикстарт, версия с кучей ограничений

[KAlex]

Здесь все давно разжевано.

[vet]

простое дергание ноги должно выливаться в гораздо меньший объем кода:

Код

//   for (;;) {
//     *AT91C_PIOA_CODR = 50;
//     *AT91C_PIOA_SODR = 50;
//   }

        LDR      R0,??xx_1 ;; 0xfffffffffffff430
        LDR      R1,??xx_1+0x4 ;; 0xfffffffffffff434
        MOVS     R2,#+50
??xx_2:
        STR      R2,[R1, #+0]
        STR      R2,[R0, #+0]
        B        ??xx_2

[aaarrr]

Ну, amw написал уж очень страшный вариант. На деле на одну запись в порт требуется 3 такта MCK, т.е. конструкция из 3-х записей + переход должна выполняться за 12 тактов процессора или 400 мксек.