ljerry

Хм, не догадался внимательнее глянуть на результаты поиска по их сайту... На странице LPC313x ссылка только на даташит более чем годичной давности, в котором ни слова про потребление. Всем большое спасибо за помощь!

Нет такого раздела, как класса. Был бы - и вопроса бы не было.

Кто работал с LPC3130/LPC3131, подскажите, пожалуйста: какое потребление у этих процессоров? Особенно интересует ток потребления ядра. К сожалению, ни в даташите, ни в аппликухах подобной информации нет.

Еще раз повторю, на входе MCLR стоит цепочка вида R-C-R, как на рисунке из Reference Manual'а. Сигнал от программатора приходит непосредственно на вывод MCLR микроконтроллера (то есть конденсатор и сигнал от программатора разделены резистором R1 - см. рисунок ниже). Вопрос возник потому, что возникла необходимость удалить несколько компонентов с платы (места на ней крайне мало), и без внешней цепи сброса остается уповать только на power-on reset. Собственно, вопрос был о том, насколько надежно работает внутренний сброс в PIC24F, а не о том, как правильно построить цепь внешнего сброса.

В схеме стоит R-C-R цепочка, программированию не мешает. Просто есть необходимость разгрузить плату от одних элементов в пользу других.

Да, у меня так и сделано. Просто плата крайне мелкая, и 2 детали (конденсатор и резистор) хотелось бы убрать. Собственно говоря, ответ я уже нашел в референс мануале - стормозил поначалу насчет там посмотреть, пытался в основном даташите ответ нарыть :laughing: Сделано это было перестраховки ради, чтобы в дальнейшем не словить проблем с платами, не желающими запускаться. Просто именно с PIC24F я еще не работал, а делать еще одну итерацию по печатным платам что-то не хочется. Так, а вот с этого места поподробнее, плиз. Дайте-ка ссылочку на аппнот применительно к PIC24F, где такое сказано (что конденсатор на MCLR именно недопустим).

Вопрос такой: насколько стабильно будет стартовать схема на PIC24F (уточнение: используется PIC24FJ32GA002, внутренний регулятор для ядра включен), если удалить конденсатор с вывода MCLR? Достаточно ли будет комбинации POR+BOR? Заранее благодарен за ответы.

Рекомендую хорошую книжку "Алгоритмические трюки для программистов", там подобных фокусов много

После while(...) надо точку с запятой ставить :) Вот так: while (!(AT91C_BASE_DBGU->DBGU_CSR &AT91C_US_TXRDY)); А то у Вас получается следующий код: AT91C_BASE_DBGU->DBGU_THR = 0x41; while (!(AT91C_BASE_DBGU->DBGU_CSR &AT91C_US_TXRDY)) { AT91C_BASE_DBGU->DBGU_THR = 0x54; } while (!(AT91C_BASE_DBGU->DBGU_CSR &AT91C_US_TXRDY)) { AT91C_BASE_DBGU->DBGU_THR = 0x41; } while (!(AT91C_BASE_DBGU->DBGU_CSR &AT91C_US_TXRDY)) { AT91C_BASE_DBGU->DBGU_THR = 0x0D; } Удачи!

У меня PDC и с USART 'ом используется, правда, только в передающем канале. Заодно этот обработчик будет хорошим индикатором системной ошибки. Напишите потом, заработало или нет - самому интересно стало :)

В общем, рекомендую нарисовать что-либо навроде: void __SSC_PeripheryInit( void ) { // SSC Control Register AT91C_BASE_SSC->SSC_CR = AT91C_SSC_SWRST; /* (SSC) Software Reset */ // !!! PDC !!! AT91C_BASE_SSC->SSC_PTCR = AT91C_PDC_RXTDIS | AT91C_PDC_TXTDIS; // current buffer AT91C_BASE_SSC->SSC_TPR = (unsigned long)(sscProcessor->TXbuffers[ sscProcessor->mainBuffer ]); AT91C_BASE_SSC->SSC_TCR = sscProcessor->buffersLength; AT91C_BASE_SSC->SSC_TNPR = (unsigned long)(sscProcessor->TXbuffers[ sscProcessor->shadowBuffer ]); AT91C_BASE_SSC->SSC_TNCR = sscProcessor->buffersLength; // starting RC/TM AT91C_BASE_SSC->SSC_PTCR = AT91C_PDC_RXTEN | AT91C_PDC_TXTEN; // !!! SSC !!! // SSC Receive Clock Mode Register AT91C_BASE_SSC->SSC_RCMR = ((0x2 << 0) & AT91C_SSC_CKS) | ((0x4 << 8) & AT91C_SSC_START); // AT91C_BASE_SSC->SSC_RCMR = ((0x2 << 0) & AT91C_SSC_CKS) | AT91C_SSC_CKI | ((0x3 << 8) & AT91C_SSC_START); // SSC Receive Frame Mode Register AT91C_BASE_SSC->SSC_RFMR = ((15 << 0) & AT91C_SSC_DATLEN) | AT91C_SSC_MSBF; // SSC Transmit Clock Mode Register AT91C_BASE_SSC->SSC_TCMR = ((0x2 << 0) & AT91C_SSC_CKS) | AT91C_SSC_CKI | ((0x4 << 8) & AT91C_SSC_START);; // SSC Transmit Frame Mode Register AT91C_BASE_SSC->SSC_TFMR = ((15 << 0) & AT91C_SSC_DATLEN) | T91C_SSC_MSBF; // SSC Control Register AT91C_BASE_SSC->SSC_CR = AT91C_SSC_RXEN | AT91C_SSC_TXEN; } __arm void PSSC_InterruptHandler(void) { unsigned long STATUS = AT91C_BASE_SSC->SSC_SR; if (STATUS & AT91C_SSC_ENDRX) { // first, updating buffer count if (sscProcessor->mainBuffer == FIRST_BUFFER) { sscProcessor->mainBuffer = SECOND_BUFFER; sscProcessor->shadowBuffer = FIRST_BUFFER; } else { sscProcessor->mainBuffer = FIRST_BUFFER; sscProcessor->shadowBuffer = SECOND_BUFFER; } // current TX buffer AT91C_BASE_SSC->SSC_TNPR = (unsigned long)(sscProcessor->TXbuffers[ sscProcessor->mainBuffer ]); AT91C_BASE_SSC->SSC_TNCR = sscProcessor->buffersLength; // current RX buffer AT91C_BASE_SSC->SSC_RNPR = (unsigned long)(sscProcessor->RXbuffers[ sscProcessor->mainBuffer ]); AT91C_BASE_SSC->SSC_RNCR = sscProcessor->buffersLength; // posting semaphore to signal codec 'bout buffers switched OSSemPost( sscProcessor->buffersSwitchSemaphore ); } /////////////////////////// /////////////////////////// /////////////////////////// AT91C_BASE_AIC->AIC_IVR = 0; AT91C_BASE_AIC->AIC_ICCR = (1 << AT91C_ID_SSC); AT91C_BASE_AIC->AIC_EOICR = 0; } Вот :) Использую PDC совместно с DBGU, UART и SPI. В принципе идеология использования PDC совместно с SPI такая же, как и при использовании с SSC. Так что пробуйте. Правда, инициализацию собственно SSC я взял из Вашего кода как есть, так что пусть она будет на Вашей совести :)

Из кода не видно - дефайны не показаны. К тому же останавливать его нужно только перед инициализацией (на всякий случай) и перед завершением работы. В прерывании трогать его просто нельзя. Если используется двойная буферизация, то разницы не будет, и один вызов действительно можно сэкономить. В противном случае обязательно нужны раздельные ветки, иначе обязательно словите проблему. Теперь по приведенному Вами коду. Есть там ветка, начинающаяся с проверки условия RXBUFF. Так вот, в момент возникновения этого события потеря одного фрейма уже произошла и сдвиговый регистр передатчика уже содержит некорректные данные. Почему так происходит - см. мое сообщение, отправленное в 15:53. По какой причине это происходит - скорее всего, из-за запрета прерываний на большое время, возможно, обработчиками других прерываний.

В общем, я бы порекомендовал такую идеологию построения кода: А. Инициализация: 1. Останов кодека; 2. Запрет SSC и PDC - приемника и передатчика (на всякий пожарный); 3. Загрузка указателей буферов и их длин в PDC для приемника и передатчика, причем как пар TPR-TCR и RPR-RCR, так и пар TNPR-TNCR и RNPR-RNCR; 4. Разрешение PDC для приемника и передатчика; 5. Разрешение приемника и передатчика; 6. Запуск кодека. Б. Обработчик прерываний: Можно использовать обработчик с проверкой только события ENDRX, но кошернее (ИМХО) использовать раздельные ветки с проверкой событий ENDRX и ENDTX. В обработчике выполняем запись в пары TNPR-TNCR и RNPR-RNCR. Если хотите использовать события TXBUFE и RXBUFF, то для них обязательно должны быть отдельные ветки. Ну как-то вот так :)

Хотелось бы посмотреть именно на исходный код. Синхронны-то они только на шине, а в проце обрабатывать их надо по-разному. Для приемника можно включить и настроить канал PDC уже в момент приема первого слова, главное - успеть это сделать до завершения приема. С передатчиком ситуация другая: нужно сначала настроить и включить PDC, только потом включить передатчик (а иначе он может начать брать данные из буфера PDC только после отправки первого слова) и в самом конце разрешить работу внешнего устройства. Если эта последовательность нарушается - есть вероятность сбоя (как говорится, плавали, знаем :) ). В общем, надо код смотреть P.S. Кстати, еще один момент: приемный и передающий каналы PDC заканчивают работу в разные моменты времени - передающий после передачи предпоследнего слова, а приемный - после приема последнего слова. И для них нужны отдельные обработчики прерываний, иначе есть шанс либо не успеть прогрузить передающий канал (при использовании прерывания от приемного канала), либо можно не до конца использовать приемный буфер - последнее слово данных попадет в начало нового буфера (при использовании прерывания от передающего канала). А у Вас все сидит в одном прерывании. Правда, при использовании прерывания от приемного канала и при двойной буферизации работать должно.

Думаю, что проблема возникает из-за того, что программа не успевает подгрузить передающий канал PDC вовремя (из-за того, что прерывание запрещено слишком долго, скорее всего, на время обработки других прерываний). На сей случай рекомендую использовать двойную буферизацию, с помощью пар регистров SSC_TNPR - SSC_TNCR и SSC_RNPR - SSC_RNCR. Удачи!