Дружим AD7490 с sam7s через SPI используя DMA Опции

[Goofy]

Для начала преобразования AD7490, требует падающий фронт на CS, поэтому приходиться после завершеня передачи двух байтов запроса ждать, пока МК вернёт высокий уровень на CS. И следом идёт приём результата преобразования предыдущего запроса, параллельно запись запроса текущего.

Код

...
for (i=0; i<=13;i++ )
{  
//массив запросов с соответсвующими адресами каналов АЦП
ADC1Request[i*2]=(1<<7)|( (i) <<2)|(1<<1)|1;        
ADC1Request[i*2+1]=(1<<5)|(1<<4);//(1<<5) | (1<<4);//| (1<<6);  

}
...

void RequestADCData12Bit (TADCData12Bit* DataStruct)
{


ADC1ChipSelect();


AT91F_SPI_ReceiveFrame(pSPI,buf,2,(char *) DataStruct,26);    
//первые два байта с ненужными данными, последующие записываются в структуру из unsigned short    


SPI_Tx( ADC1Request,2);
//передача первого запроса
ADC1ReqLeft=13; //количество оставшихся запросов


}

обработчик прерывания по пустому буферу передачи

Код

__irq void SPI_Handler (void)
{


if (pSPI->SPI_SR & AT91C_SPI_TXBUFE){

  if (ADC1ReqLeft)
{
pSPI->SPI_CR=AT91C_SPI_LASTXFER;

while ( !(*AT91C_PIOA_PDSR & AT91C_PA11_NPCS0) );  //ждём пока вернётся наверх CS
ADC1ReqLeft--;


pSPI->SPI_TCR=2;
//разрешаем PDC передать последующие два байта массива запроса

}
}

Данные извлечь этот подход позволяет. Но! В младшем байте каждой из посылок (принятых результатов преобразования) находятся произвольные данные, пока что ни с чем не кореллирующие. А в старшем байте всё хорошо. То есть на выходе на графике значений с АЦП я вижу ступеньки с высотой 256.
Самое интересное что если запрашивать данные поодиночке с одного канала, то всё работает, данные идут корректные. Но хочеться чтобы всё было быстро и изящно.
Где посоветуете искать причину?

[sergik_vrn]

Для начала преобразования AD7490, требует падающий фронт на CS, поэтому приходиться после завершеня передачи двух байтов запроса ждать, пока МК вернёт высокий уровень на CS. И следом идёт приём результата преобразования предыдущего запроса, параллельно запись запроса текущего.
Данные извлечь этот подход позволяет. Но! В младшем байте каждой из посылок (принятых результатов преобразования) находятся произвольные данные, пока что ни с чем не кореллирующие. А в старшем байте всё хорошо. То есть на выходе на графике значений с АЦП я вижу ступеньки с высотой 256.
Самое интересное что если запрашивать данные поодиночке с одного канала, то всё работает, данные идут корректные. Но хочеться чтобы всё было быстро и изящно.
Где посоветуете искать причину?

для начала тупой вопрос - а Вы уверены, что АЦП успевает производить преобразование с той скоростью, с которой вы ему их задаете? косвенно на эту мысль наводит упоминаниео нормальной работе при одноканальном преобразовании (насколько я ничего не помню, при смене канала коммутатора у AD-шных АЦП время преобразования удваивается)

[Goofy]

для начала тупой вопрос - а Вы уверены, что АЦП успевает производить преобразование с той скоростью, с которой вы ему их задаете? косвенно на эту мысль наводит упоминаниео нормальной работе при одноканальном преобразовании (насколько я ничего не помню, при смене канала коммутатора у AD-шных АЦП время преобразования удваивается)

Преобразование записанного в регистр канала начинается при последующим дёргании CS, сначала пересылаются биты адреса канала, а следом идут биты данных, с каждым клоком приводя преобразование очередного бита. Судя по ДШ всё должно быть так. Варьировал и частотами, и временем паузы на линии CS...

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

Сообщение отредактировал Goofy - Dec 17 2007, 19:05