Цитата(defunct @ Feb 17 2009, 01:43)
Чем собираете? Если IAR'ом - отдайте под стек все что есть (так как сейчас - у Вас даже на буфер одного сектора нехватает).
Если WinAVR'ом, тогда как посчитали объем стека?
Собираю в IAR 3.20. Как уже говорил, все ёмкие файловые переменные EFSL_Filesystem, File, EFSL_Storage, в том числе содержащий кэш сектора да и другие, как -то буфер, куда читается содержимое сектора поместил в глобальные переменные. В листинге глубина main CSTACK=16, понятно, что полную глубину надо просуммировать, на вскидку получится не более 200. Да я и пробовал варианты, когда эти переменные были в стеке, естественно стек был почти максимальным.
Цитата(defunct @ Feb 17 2009, 01:43)
Для FS столь низкая тактовая? Может проц захлебывается данными от SD и обработкой UART'a?...
Если нет подходящего кварца, на внутреннем осцилляторе с OSCCAL = 0xFF получите частоту близкую к 13Mhz.
Чтоб не ставить конверторы уровня для SD, я взял L разновидность с Fosc max =8MHz, а STK500 больше 3.68 МГц разгонять не рекомендуют, якобы разводка ПП слишком универсальна - может быть не стабильна. UART много не нагружаю, - вместо отладочных строк вывожу байтовый код, что-то вроде: SendTraceByteToUART(0x34);
Цитата(defunct @ Feb 17 2009, 01:43)
Всяко бывало. Причиной всему чаще всего - ошибка в программе.
Гм.., но питание SD не прерываете? т.е. как я понял, прервать питание на карте и затем снова ее инициализировать - это единственный способ сброса SD карты? В Отличие от DataFlash памяти, где есть Reset?
Цитата(defunct @ Feb 17 2009, 01:43)
Первое - рассчитать или промониторить количество свободных MIPS'ов проца.
И приведите код функций с этой строчкой:
Стало быть, одной из возможных причин может быть слишком малая скорость взаимодействия с карточкой? Target устройством будет Mega64, пока не отладил все составные части программы не хотелось бы приступать к разводке платы. Из оставшихся модулей это файловая система и алгоритм upgrade, естественно тоже с карточки. Не считаете ли Вы, перенос на Mega64, подъем до 8 МГц может решить проблему?
CODE
euint8 atmega_spi_send(atmegaSpiInterface *iface, euint8 data)
{
euint8 incoming=0;
// PORTB &= ~(iface->pinSelect);
SPDR = data;
while(!(SPSR & (1<<SPIF)))
incoming = SPDR;
// PORTB |= iface->pinSelect;
return(incoming);
}
Пробовал условие цикла заменить на while((!(SPSR & (1<<SPIF))) && (!flagSPIInt))
flagSPIInt взводится в прерывании (пробовал разные продолжительности: CK/256 -> 17.6 mS)
Далее в функции чтения сектора, что-то вроде
CODE
for(uLoop=0; uLoop<4; uLoop++)
{
sd_clear_buff(ssp);
if (sd_Command(ssp,CMDREAD, (euint16) (place >> 16), (euint16) place) != 0)
{
ssp->spi_CS_OFF(ssp->spiHwInterface);
SendTraceByteToUART(0x2F);
continue;
}
SendTraceByteToUART(0x31);
cardresp=sd_Resp8b(ssp); /* Card response */
if (flagSPIInt)
{
ssp->spi_CS_OFF(ssp->spiHwInterface);
SendTraceByteToUART(0x2F);
continue;
}
sd_clear_buff() выглядит следующим образом
CODE
void sd_clear_buff(SdSpiProtocol *ssp)
{
sd_resetSPITimer();
ssp->spi_CS_OFF(ssp->spiHwInterface);
ssp->spiSendByte(ssp->spiHwInterface,0xff);
ssp->spiSendByte(ssp->spiHwInterface,0xff);
}
Это позаимствовал у FlashFile от prllc
Цитата(demiurg_spb @ Feb 17 2009, 12:13)
Чтоб небыло проблем с SS настройте ее на вывод или включите pullup обязательно.
Про pullup хорошая идея, внутренний сгодится?
Цитата(demiurg_spb @ Feb 17 2009, 12:13)
Таймеры и т.д. это уже извращения ИМХО.
Когда есть конструкции вида: while(!(SPSR & (1<<SPIF)))
есть вероятность повиснуть там навсегда, и, тогда либо неуправляемый сброс от сторожевой собаки, либо своя управляемая обработка.
Ну это как если бы вынул сидюк из CDROM во время чтения, а Windows завис и потребовалась перезагрузка!
Цитата(freux @ Feb 17 2009, 13:21)
Про pullup хорошая идея, внутренний сгодится?
Ерунду сморозил: SS линия настроена на выход, внутреннего pullupа быть не может:
CODE
...
/* Set as master, clock and chip select output */
DDR_SPI = (1<<DD_MOSI) | (1<<DD_SCK) | 1;
...
PB0 - SlaveSelect
Сообщение отредактировал freux - Feb 17 2009, 10:27
EFSL стабильна?, Файловая система на Mega32 подвисает
Feb 16 2009, 21:40
