freux

Попробую в ближайшем подходе! Убедился, действительно, исходники efsl включают incoming = SPDR; в цикл, а вот FlashFile от prllc - нет, у них цикл пустой, только проверка флага. Спасибо, что обратили на это внимание! :a14: Карта выбирается в начале sd_Command() esint8 sd_Command(SdSpiProtocol *ssp,euint8 cmd, euint16 paramx, euint16 paramy) { ssp->spi_CS_ON(ssp->spiHwInterface); ssp->spiSendByte(ssp->spiHwInterface,0x40 | cmd); if (flagSPIInt) return (-1); ssp->spiSendByte(ssp->spiHwInterface,(euint8) (paramx >> 8));/* MSB of x */ if (flagSPIInt) return (-1); ssp->spiSendByte(ssp->spiHwInterface,(euint8) (paramx)); /* LSB of x */ if (flagSPIInt) return (-1); ssp->spiSendByte(ssp->spiHwInterface,(euint8) (paramy >> 8));/* MSB of y */ if (flagSPIInt) return (-1); ssp->spiSendByte(ssp->spiHwInterface,(euint8) (paramy)); /* LSB of y */ if (flagSPIInt) return (-1); if (cmd == 0) /* Checksum (should be only valid for first command (0) */ ssp->spiSendByte(ssp->spiHwInterface,0x95); else /* Eat response, we don't care for now */ ssp->spiSendByte(ssp->spiHwInterface,0xff); if (flagSPIInt) return (-1); return (0); } Также привожу модифицированную функцию чтения сектора (может еще что-нибудь найдете): esint8 sd_readSector(SdSpiProtocol *ssp,euint32 address, euint8* buf) { euint8 cardresp; euint8 firstblock; euint8 c, uLoop; euint16 fb_timeout=0xffff; euint32 i; euint32 place; const euint16 len=512; /* FIXME */ SendTraceByteToUART(0x30); SendLongToUART(address); /*DBG((TXT("sd_readSector::Trying to read sector %u and store it at %p.\n"),address,&buf[0]));*/ place=512*address; 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; } SendTraceByteToUART(0x32); for(i=0; ((i<1000)&&(cardresp!=0xFE)); i++) { sd_resetSPITimer(); cardresp=sd_Resp8b(ssp); if (flagSPIInt) { ssp->spi_CS_OFF(ssp->spiHwInterface); break; } } SendTraceByteToUART(0x33); if (cardresp==0xFE) { for(i=0;i<512;i++){ sd_resetSPITimer(); c = ssp->spiSendByte(ssp->spiHwInterface,0xff); if (flagSPIInt) { ssp->spi_CS_OFF(ssp->spiHwInterface); break; } if(i<len) buf[i] = c; } SendTraceByteToUART(0x34); if (flagSPIInt) continue; /* Checksum (2 byte) - ignore for now */ ssp->spiSendByte(ssp->spiHwInterface,0xff); ssp->spiSendByte(ssp->spiHwInterface,0xff); ssp->spiSendByte(ssp->spiHwInterface,0xff); SendTraceByteToUART(0x35); ssp->spi_CS_OFF(ssp->spiHwInterface); return(0); } // if (cardresp==0xFE) } // for uLoop<4 sd_Resp8bError(ssp,cardresp); ssp->spi_CS_OFF(ssp->spiHwInterface); return(-1); } SPI Master, но есть еще один Slave - это DataFlash, и вот там SS пином выступает PB4 А предпосылки - это вынимание пользователем карточки во время записи, дефективная карточка, сам пользователь дефективный..

Собираю в IAR 3.20. Как уже говорил, все ёмкие файловые переменные EFSL_Filesystem, File, EFSL_Storage, в том числе содержащий кэш сектора да и другие, как -то буфер, куда читается содержимое сектора поместил в глобальные переменные. В листинге глубина main CSTACK=16, понятно, что полную глубину надо просуммировать, на вскидку получится не более 200. Да я и пробовал варианты, когда эти переменные были в стеке, естественно стек был почти максимальным. Чтоб не ставить конверторы уровня для SD, я взял L разновидность с Fosc max =8MHz, а STK500 больше 3.68 МГц разгонять не рекомендуют, якобы разводка ПП слишком универсальна - может быть не стабильна. UART много не нагружаю, - вместо отладочных строк вывожу байтовый код, что-то вроде: SendTraceByteToUART(0x34); Гм.., но питание SD не прерываете? т.е. как я понял, прервать питание на карте и затем снова ее инициализировать - это единственный способ сброса SD карты? В Отличие от DataFlash памяти, где есть Reset? Стало быть, одной из возможных причин может быть слишком малая скорость взаимодействия с карточкой? Target устройством будет Mega64, пока не отладил все составные части программы не хотелось бы приступать к разводке платы. Из оставшихся модулей это файловая система и алгоритм upgrade, естественно тоже с карточки. Не считаете ли Вы, перенос на Mega64, подъем до 8 МГц может решить проблему? 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) Далее в функции чтения сектора, что-то вроде 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() выглядит следующим образом 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 Про pullup хорошая идея, внутренний сгодится? Когда есть конструкции вида: while(!(SPSR & (1<<SPIF))) есть вероятность повиснуть там навсегда, и, тогда либо неуправляемый сброс от сторожевой собаки, либо своя управляемая обработка. Ну это как если бы вынул сидюк из CDROM во время чтения, а Windows завис и потребовалась перезагрузка! Ерунду сморозил: SS линия настроена на выход, внутреннего pullupа быть не может: ... /* Set as master, clock and chip select output */ DDR_SPI = (1<<DD_MOSI) | (1<<DD_SCK) | 1; ... PB0 - SlaveSelect

Адаптировал EFSL версии 0.3.4 на ATMega32L на STK-500 под SD. Отладочные строки убрал во flash, все файловые переменные - глобальные, размер стека - 0х180, потребление памяти 1 879 bytes of DATA memory, размер кода несущественен - во flash укладывается. Examplы - копирование файла, вывод содержимого файла в UART проходят без проблем. Усложнил main - добавил командный процессор - и стал выводить содержимое файлов один за другим. И тут возникли зависания. Отладчика нет. Обложил печатью, и выяснил, что зависания происходят в функции посылки команды - sd_Command. Посмотрел исходники FlashFile v2.10 от Progressive Resources LLC, подправил sd_Command() и sd_readSector() на манер, как это сделано у prllc. Результат тот же, - несколько раз файл считывается и выводится, затем, при чтении сектора того же файла зависает в sd_Command(). На печать вывожу так же #сектора при вызове sd_readSector() - сектора все те же, что и читались успешно. Очевидно зависание в while(!(SPSR & (1<<SPIF))); У Трамперта в "AVR-RISC микроконтроллерах" сказано, что в режиме "мастер" текущая передача может быть прервана подачей 1 в линию SS. Счетчик разрядов и внутрення логика Slave сбрасываются. Оператор while(!(SPSR & (1<<SPIF))) в sd_Command() я добавил флагом, который взводится таймером через некоторое время после посылки команды так, чтобы исключить зависания. Если флаг взведен, поднимаю линию SS. Однако SD попав в это состояние больше не воспринимает команды - зависание исключено, но и секторы карты больше не читаются. Теперь подумываю о прерывании питания на карту и ее повторной инициализации в случае продолжительного ожидания в SPI. F osc = 3.68, F spi пробовал /2, /4 и /8 - безразлично. Никто не испытывал подобных проблем? Что посоветуете?

Вставлять в обработчик прерывания задержку равно, как и ожидание, обсуждаемое выше - плохой стиль. Лучше, тот же Transmit вызывать в бесконечном цикле по флагу в main_e, а в прерывании этот самый флаг взводить.

Состояние седьмой ноги PortD меняется в прерывании дважды - т.е возвращается в первоначальное состояние - это может быть просто не заметно глазу. Я бы рекомендовал делать просто инверсию бита на 7 ноге. Тогда при первом принятом символе загорится, при втором - потухнет и т.д.

Означает: STK500 ... обнаружено. То, что вам, по-видимому, надо сделать написано далее и вами не приведено. Видимо, придется браться за английский, раз пользуемся зарубежным творением..

Еще раз, Прерывание от INT1 разрешается ldi rin,0b10000000 out gicr,rin в "массе" кода с коментариями: ..включить двигатель ..включить тормоз ..сводим губки .. еще губки, и т.д. больше нигде в GICR разрешение INT1 не заносится Это так задуманно? Ведь в самом INT1 прерывании оно запрещается занесением в GICR нуля

Ничего не понял. Светодиод на D? 0 --> в DDR порта, порт на вход. Terapefft, может ну иго нафиг, программирование это. Может, будем людей лечить??

Мне показалось, что в обработчике прерывание от INT1 запрещается, и более нигде не разрешается (за исключением первичной инициализации).

Тяжело глядеть ассемблер, однако.. Не случается ли так, что прерывание от INT1 больше одного раза не происходит? Попробуйте прикрыть функциональность в обработчике прерывания, а вместо этого сделать реверс светодиоду, т.е, если не горит, то включить, если горит - выключить.

Где-нибудь сказано, что CNT_INT1 - это обработчик прерывания INT1?

Может приведенное ниже не столь красиво, ибо отсутствуют в выражении "всякие" там 1000, -9999 .. и другие десятичные цЫфры, зато давольно-таки оптимально, если глянуть в ассемблерный листинг: if (buf[1] > 0x0F) temperature = 0xFF00; else temperature = 0; temperature = temperature | (buf[0] >> 3) | (buf[1] << 5); WriteOutTemp(temperature); ... ... #pragma optimize=2 void WriteOutTemp(int temperature) { unsigned char nHalf = 0; temperature = temperature >> 1; if (SREG_C == 1) nHalf = 5; printf("T=%d.%d\r\n", temperature, nHalf); } С точностью один знак после запятой работает изумительно. А где printf, там и на индикатор вывести просто

..\ARM\

Та, та, белый, белый, совсем карячий! Поступить можно так, - пойти на сайт первоисточника - Atmel в раздел Application Notes, найти там AVR318, - там и описание и код на С для IAR. Можно проявить настойчивость, и сходить на сайт Dallasa, вы не поверите,- там тоже полно информации о том, как работать с 1-Wire интерфейсом.

Может Prog_ID объявить как массив: code char* code Prog_ID[] = {__FILE__, __DATE__, __TIME__}; ?