Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: AT91SAM7S не успевает читать данные с PIO!?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
DAPA
Есть AT91SAM7S256 на один пин поступает сигнал синхронизации, по которому с нужно считать с других пинов в память данные(параллельная шина), но как ни крути больше в цикле считывания не удаётся, даже, инкрементировать переменную больше 100 раз, вместо положенных 256!!!
Вот фрагмент отвечающего за эото кода:
Код
uint16_t MAS_DAT[LENTH];
...
__inline void Get_Data(void) {
    volatile uint16_t *poi = (uint16_t*) MAS_DAT;
    volatile uint16_t i = 0, l = 0;
    uint32_t tmp1,tmp2;
    while (pPIO->PIO_PDSR & VSYNC) {
        i = 0;
        while (pPIO->PIO_PDSR & HSYNC) {
            //i++;
            //while(pPIO->PIO_PDSR&(1<<30));//CLK
            tmp1 = (pPIO->PIO_PDSR>>5);
            tmp2 = (pPIO->PIO_PDSR>>5);
             *poi = (uint16_t)(tmp2<<8)|tmp1;
             poi++;
        }
        //asm("add %[value], %[value],#1" : [value] "=r" (l));
        l++;
        while (!(pPIO->PIO_PDSR & HSYNC) && (pPIO->PIO_PDSR & VSYNC));
    }
    poi = (uint16_t*)MAS_DAT;
    *poi = i;
    poi++;
    *poi = l;
}

smile3046.gif 1111493779.gif
aaarrr
Хоть бы длительность HSYNC написали для порядка.
DAPA
Пардон, виноватsm.gif
Период следования импульсов HSYNC примерно 260 мкс, из которых высокий уровень занимает ~42мкс, в течении которых и надо успеть считать данные с PIO 256 раз
aaarrr
Цитата(DAPA @ Aug 11 2011, 16:49) *
Период следования импульсов примерно 0.18 мкс

Это каких импульсов? Я правильно понимаю, что tHSYNC = 0.18 * 256 = 46.08us?

Если так, то полученное значение 100 проходов цикла очень похоже на суровую правду жизни:
Цикл выполняется за 22 такта; если процессор выполняет программу из RAM на частоте 48МГц, это составляет 458.33ns
46.08 / 0.45833 = 100.5
DAPA
Дело в том что подобная задача решалась( не мной sm.gif ) на atmega, и тот факт, что мега успевает а арм нет, не даёт покоя!!!
aaarrr
Цитата(DAPA @ Aug 11 2011, 16:49) *
Период следования импульсов HSYNC примерно 260 мкс, из которых высокий уровень занимает ~42мкс, в течении которых и надо успеть считать данные с PIO 256 раз

ОК, 42 / 256 = 164нс на считывание, или 9 тактов процессора при MCK = 55MHz. Одно считывание занимает 4 такта + 1 такт на сдвиг + 2 такта на запись в память = 7 тактов.
То есть теоретически можно успеть, если развернуть цикл и не проверять состояние HSYNC во время считывания.
DAPA
Спасибо за развёрнутый ответsm.gif
Но считывание должно происходить в то время, когда HSYNC в высоком уровне.
(Просто речь идёт о чтении данных с камеры sm.gif, HSYNC - синхронизация строк )
aaarrr
Цитата(DAPA @ Aug 11 2011, 17:20) *
Но считывание должно происходить в то время, когда HSYNC в высоком уровне.

Если частота постоянная, то можно только ловить фронт HSYNC.
Genadi Zawidowski
Код
    volatile uint16_t *poi = (uint16_t*) MAS_DAT;
    volatile uint16_t i = 0, l = 0;

Хотелось бы узнать смысл квалификатора volatile во второй строчке. Ну и в первой, за одно.
Ещё, по недоброй традиции копипэймта, и pPIO как volatile обявили? Так Вы всё сделали для замедления программы.
Цитата(DAPA @ Aug 11 2011, 17:20) *
(Просто речь идёт о чтении данных с камеры sm.gif, HSYNC - синхронизация строк )


разумнее было бы ловить фронт (через IRQx) и считывать конкретное количество сэмплов.
Похожая (по ловле HSYNC) задача была при реализации on screen display.
Подумайте о применении АЦП с последовательным интерфейсом - и использовании ПДП на SSC.
aaarrr
Цитата(Genadi Zawidowski @ Aug 12 2011, 13:14) *
Хотелось бы узнать смысл квалификатора volatile во второй строчке. Ну и в первой, за одно.

Смысла нет, но на скорость работы интересующего участка не влияет никак.

Цитата(Genadi Zawidowski @ Aug 12 2011, 13:14) *
Ещё, по недоброй традиции копипэймта, и pPIO как volatile обявили? Так Вы всё сделали для замедления программы.

Ну, по косвенным признакам, этого нет. А тормоз получился бы знатный, да.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.