[denebopetukius 0]

не могу понять логику втыкания команд csync,ssync,idle в исходные тесты программ.

например:

 

void Init_PLL(void)
{
    volatile int test=0;
    sysreg_write(reg_SYSCFG, 0x32);        //Initialize System Configuration Register
    *pVR_CTL = 0x00FB;
    idle();
    *pSIC_IWR = 0x1;
    *pPLL_CTL = 0x2C00;
    ssync();
    idle();
}//end Init_PLL

 

или

 

void Init_SDRAM(void)
{
    if (*pEBIU_SDSTAT & SDRS) {
        //SDRAM Refresh Rate Control Register
        *pEBIU_SDRRC = 0x00000817;    
        //SDRAM Memory Bank Control Register
        *pEBIU_SDBCTL = 0x00000013;
        //SDRAM Memory Global Control Register    
        *pEBIU_SDGCTL = 0x0091998d;    
        ssync();
    }
}//end Init_SDRAM

 

подскажите, для чего в этих фрагментах нужны ssync(), idle() и csync() ?

 

при работе с программируемыми флагами PF 0..15 они нужны? если да то где?

 

и зачем в InitPLL() потребовалось записывать sysreg_write(reg_SYSCFG, 0x32) ?

 

P.S. сильно не пинайте - начал программировать ADSP 3 дня назад

Изменено 10 марта, 2009 пользователем denebopetukius

[boombox 0]

csync() - ожидает завершения операции в ядре;

ssync() - ожидает завершения операции на системной переферии;

 

Т.е. если вы хотите быть уверенным, что *pPLL_CTL действительно равен 0x2C00 и все предыдущие регистры будут присвоены заданным значениям необходимо ожидать завершения операции.

А idle() вводит процессор в ожидание, пока происходит настройка PLL и после того как PLL установилась генерится прерывание (включенное *pSIC_IWR = 0x1;) по которому процессор выходит из idle();

 

sysreg_write(reg_SYSCFG, 0x32) никакого отношения к PLL не имеет, просто включает CLOCK COUNTER.

Изменено 10 марта, 2009 пользователем boom

[Itch 0]

Вроде как стоит вставлять ssync() после каждой записи в регистры периферии. Если не использовать - вероятность нормальной работы сильно падает. Т.е. может и будет работать, а может и не будет...

[boombox 0]

Работать оно будет и причём нормально. Синхронизация csync и ssync необходимо использовать лишь только в тех случаях, когда следующая операция критична к выполнению предыдущей. И ставить их где попало нет смысла т.к. из-за этого упадёт быстродействие (фактически проц в ступоре пока не выполнится последняя операция).

[denebopetukius 0]

спасибо всем за ответы!

P.S. а я-то думал почему диод на флаге не сразу мигает ;)

[uriy 5]

С флагами отдельный вопрос. Прочтите работу с в ними в Anomaly list. Вы не указали процессор, поэтому не могу ткнуть пальцем. Для работы с флагами крайне желательно использовать макросы. В противном случае при определенных условиях значение флага будет не предсказуемо.

[denebopetukius 0]

камень bf532.

 

от флагов требуются:

 

-работа на вывод

-работа на ввод

-внешнее прерывание

 

пока работал на вывод через FIO_T, FIO_S, FIO_C

 

uriy, буду рад если подскажете, где могут ждать неприятности...

 

ревизия 0.5

[vik0 0]

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

http://www.analog.com/static/imported-file...evE.10.8.08.pdf

Аномалия 05000311.

И вообще крайне желательно внимательно изучить данный документ. Все (известные на данный момент :) ) аппаратные "грабли" там расписаны.