defunct

да разумеется UART в режиме SPI запустить можно. Только у меня в проекте были задействованы все UART'ы, и три SPI.. Для связи с ARM'ом SPI в режиме Slave для обеспечения duplex 5 Mhz канала. В итоге выяснилось, что у XMEGA большие проблемы с SPI TX'ом. В режиме Slave'а передается эхо принятого символа (возможно из-за приоритета DMA который ниже чем приоритет ядра проца, и DMA просто иногда не успевает засунуть новый символ во-время)... workaround - для проблемы с эхо из тех что находил в инете - передавать в режиме мастера, а в мастере не работает DMA вообще. Ситуация патовая... Насколько помню, после экспериментов получилось добиться устойчивого двунаправленного обмена по DMA в режиме SPI MODE0/2 на частоте 1Mhz... (Mode1/3 - эхо символы выскакивают на более низких частотах.. т.е. надо было бы понижать частоту SPI еще больше). В общем SPI модуль XMEGA немного огорчил, в остальном чип хороший.

Куда-то зачем-то слазить )) Это вопрос скорей религиозный. Я до сих пор в новые проекты закладываю ATmega128 / XMegaA3. Как периферийный сопроцессор цены им нет. В xmega есть недочет - невозможность работы SPI в режиме мастера через DMA, но для сопроцессора быть мастером и не надо.. также у меня в ходу mega16/168 и tiny13 для новых разработок. Ровная архитектура, куча наработок, просто уникальные супер-скоростные для своей мощности GPIO. Всякий овощ полезен, как говорится, и слазить только потому что что-то где-то вышло на пару центов дешевле это несерьезно, разве только у вас там миллионные партии. Позвольте не согласиться ) Выбор не очевиден ) Наработки часто играют более важную роль. Если у меня есть отлаженная и проверенная годами библиотека под Б, и нет отлаженной библиотеки под A. Я выберу Б, пусть A имеет бОльшие возможности, дешевле и быстрее. Время на отладку / переписывание библиотеки под A, а также учет архитектурных/схематических/электрических отличий может вылиться в куда бОльшие затраты, чем экономия пусть $200-$300 на партии в 100шт. ) Даже если опустить время на допиливание библиотек, риск наткнуться на непредвиденную ситуацию очень высок. (На моей практике был случай - заложил камень побыстрее/подешевле и с бОльшим числом возможностей в устройство электро-учета. а он возьми и начни зависать )) не спас ни внутренний watchdog, ни внешний. В итоге 3 выезда на объект, перепрошивка всех устройств, аж пожалел что не поставил туда проверенную мегу. фикс был понижение тактовой частоты на 10% от указанной производителем максимальной)... PS: очень рад видеть что форум живет, и старожилы (zltigo, prottoss, Сергей, и многие другие) все еще здесь!

Возможно что-то с PLL нахомутано, либо программа отключает JTAG пины.. Чип можно разлочить (стереть содержимое флеша и вернуть JTAG в рабочее состояние) специальной последовательностью переходов из JTAG в SWD режим и обратно при актином сигнале Reset. Смотрите секцию datasheet "Recover a "Locked" Microcontroller". J-Link это умеет делать непроизвольно. Достаточно 4 раза запустить и закрыть J-Link Commander при зажатом Reset (он там при старте пытается найти МК и переключается между JTAG и SWD, что приводит к разлочиванию МК). Думаю нет, там этот LM Flash Programmer хочет какую-то особенность в схематике которая есть только в TI'ых демо платах. Через ULINK у меня разлочить не получилось. J-Link'ом без проблем как описал выше.

В Loopback отловил, что уходит неправильный фрейм. Ошибка тут оказалась: (U32 *)&pTxBuf, ^ был напуган :) Спасибо за направление.

Спасибо, это хороший вопрос! Натолкнул меня на мысль включить режим loopback и посмотреть, что там получается. Отпишу как будет результат.

Доброго времени суток! Добрался до девайса, который спроектировали 4 года назад :) уже и чипы "not recommended for new design" LM3S9B92 ревизия C5, но партия железок спаяна, поэтому есть острая необходимость доделать. Сделал RX по DMA, как отдельный процесс, работает довольно гладко. А с TX беда. По статусам показывает что фрейм отправлен, но реально фрейм не уходит. Привожу упрощенный кусочек кода (оттестированный). Пакет на отправку однотипно подготавливается для случая с DMA и без DMA. вот этот кусочек подготавливает данные к отправке: U32 buffer[2048 >> 2]; // 2KB to conver whole TX fifo void nic_TxPacket(U8 *pPacket, U32 size) { U16 len; U8 *pTxBuf = (U8 *)buffer; len = size - (ETHERNET_HDR_LEN); // size - 14 (TX len should contain data payload len w/o eth hdr) memcpy(&pTxBuf[0], &len, sizeof(len)); // put frame len first memcpy(&pTxBuf[2], pPacket, size); // copy rest of the packet Подготовленный фрейм лежит в pTxBuf. Вот этот кусочек работает на ура (здесь проц напрямую пишет в TX fifo подготовленный фрейм): U32 *p = (U32 *)pTxBuf; size += 2; // inc by "len" field size = (size + 3) >> 2; // convert size into word count while(size--) MAC_DATA_R = *p++; MAC_TR_R = MAC_TR_NEWTX; while(MAC_TR_R & MAC_TR_NEWTX); если пытаюсь то же самое отправить по DMA - получаю статус DMA - все ОК, статус MAC - Tx complete. Но фрейма на выходе с девайса не вижу.. pdma_RunAutoTxfer32(EMAC_TX_DMA_CHANNEL, (U32 *)EMAC_FIFO_ADDR, // ==0x40048010 (U32 *)&pTxBuf, size + 2); while(udma_Busy(EMAC_TX_DMA_CHANNEL)); MAC_TR_R = MAC_TR_NEWTX; while(MAC_TR_R & MAC_TR_NEWTX); код функции "pdma_RunAutoTxfer32(): #define EMAC_RX_DMA_CHANNEL 6 #define EMAC_TX_DMA_CHANNEL 7 #define udma_Busy(Chan) (UDMA_ENASET_R & (1 << (Chan))) typedef struct tagUDMA_TASK_DESCRIPTOR { V32 Src; // contains pointer to the end of the source buffer (inclusive) V32 Dst; // contains pointer to the end of the dest buffer (inclusive) V32 Ctrl; V32 reserved; } UDMA_TASK_DESC, *PUDMA_TASK_DESC; void pdma_RunAutoTxfer32(U32 Chan, U32 *pDst, void *pSrc, U32 size) { U32 cnt = (size + 3) >> 2; U32 ChanMask = (1 << Chan); PUDMA_TASK_DESC pTask = udma_GetPrimaryEntry(Chan); cnt -= 1; pTask->Src = (U32)pSrc + (cnt << 2); // pointer to the last word inclusive pTask->Dst = (U32)pDst; // for PDMA TX dest is peripheral data reg pTask->Ctrl = 0 | UDMA_CHCTL_DSTINC_NONE | UDMA_CHCTL_DSTSIZE_32 | UDMA_CHCTL_SRCINC_32 | UDMA_CHCTL_SRCSIZE_32 | UDMA_CHCTL_ARBSIZE_1 | (cnt << UDMA_CHCTL_XFERSIZE_S) | UDMA_CHCTL_XFERMODE_AUTO ; UDMA_ALTCLR_R |= ChanMask; // use primary entry (clear alternate) UDMA_ENASET_R |= ChanMask; // enable channel UDMA_SWREQ_R |= ChanMask; // generate soft request to push channel } Буду благодарен если меня ткнут носом, что я делаю не так!

не должно быть наоборот. Результат приводится к большей разрядной сетке. unsigned имеет больше значащих разрядов чем signed.

А для чего делается короткий пульс (запись 1 в порт когда пин настроен на вывод)? подозреваю что если есть внешний pull-up достаточно управлять только DDR'ом.

Если программа написана правильно, то никакой разницы в ее работе с оптимизацией или без - нет. Отсюда и -O0 и -Os - обе боевые прошивки, -O0 чуть медленнее и чуть толще. Я отлаживаю оптимизированный C-код постоянно, но это от безысходности. Неоптимизированный у меня просто не помещается в девайс отсюда я ставлю на первое место именно этот пункт. Cравнивая удобство того как отлаживать оптимизированный и неоптимизированный - то однозначно подымаю две руки за то, что неоптимизированный код отлаживать удобнее. Переползание на оптимизированный код произойдет само собой, не нужно с этого начинать. не всегда есть под рукой второй или хотя бы wide monitor, иногда приходится работать и с 1280x1024, съеденное дизассемблером место отнимает значительную часть у окошка с С-кодом.

Для каких ip доступна ссылка? для "ua" - закрыта

Просто собирайте с отключенной оптимизацией для отладки -O0. После отладки не забудьте оптимизацию вернуть на место -Os / -O2 А смысл? Такое разве только от безысходности: - -O0 прошивка не влазит в чип - баг проявляется с оптимизацией и не проявляется без оной. - не хватает производительности без оптимизации Во всех других случаях много эффективней будет отлаживать C код чем дизассемблер.

Дык, pack=1 это значение по-умолчанию. А как насчет pack = 4. Принимает без вопросов и warning'ов, но на деле выравнивания на 4 не делает (в 4.2.2).

http://www.avrfreaks.net/index.php?name=PN...874&start=0 У меня правда установлен GCC4.2.2 так что не имел возможности посмотреть работает ли упомянутый багфикс в 4.3 / 4.4. Но то что выравнивание не работает в 4.2.2, а также игнорируется #pragma pack это есть такое.

Не встречал такой опции в студии. Да и IAR позволяет подключить всего один такой файл, а бывает нужно много. В общем случае для подключения бинарнарников к чему угодно можно использовать программу-конвертер, которая преобразует бинарник в Сишный или в asm'овый (требуемый язык) массив результат конвертера (.c/ .asm и т.п.) потом просто подключаете к проекту. запуск конвертера можно прописать в makefile так что при сборке проекта все требуемые бинарники предварительно сконвертируются автоматически.

Так пропадет возможность мониторить входной сигнал во время генерации собственного.