Mitsufan

Подставить файл инициализации отладчика "stm32f4xx_swo.ini", чтобы настроить работу SWO. stm32f4xx_swo.txt

Поддержка SWO в Keil для stlink появилась в 4.50. Настройка совместима с ulink, поэтому все что описано в лабораторной для ulink подходит теперь и stlink. Вот выдержка из релиза: For backward compability of projects the old STLink Debugger driver has been marked as deprecated. Please update your projects to the version STLink Debugger. The new STLink Debugger features and configuration dialog matches ULink2. In particular Serial Wire Output is now supported. Для работы Trace нужно открывать дополнительные порты ITM, порт ITM0 только для printf(). На 12 странице лабораторной есть нужная картинка. Вообще, там все очень хорошо расписано.

Отладка с помощью ST-Link/V2 в Keil через SWO уже работает. 1. Подставить файл инициализации отладчика "stm32f4xx_swo.ini", чтобы настроить работу SWO. Файл искать в примерах keil\arm\boards\st\stm3240g-eval. 2. Чтобы заработал printf() через ITM (в окно Debug Viewer) нужно переопределить fputs() в ITM_SendChar(). Там же в примерах есть файл retarget.c. На закладке Trace нужно снять галку Privelege/Port 7..0 - printf() работает через порт ITM0. И вообще для printf() достаточно только одной галки Enable/Port0, лишней информацией можно перегрузить сигнал SWO. Вот здесь об этом подробнее: STMicroelectronics STM32: Cortex-M4 Lab

Да уж, наблюдая за процессом появления новых прошивок для SIM900, складывается впечатление, что все это делается исключительно под рынок exUSSR и собственные цели развития SIM900 у компании отсутсвует. Т.е. не будь энтузиазма Cadilo и может каких-то российских представителей, работу по доведению SIM900 вообще свернули бы. Это и понятно - рынок 3G надо развивать. P.S. Хотя релиз-ноте пока еще не русском, значит долой грустные мысли :)

MIPS - PIC32, скрипты для линкера от родного микрочиповского C32. С предыдущими сборками KGP все работало. А где можно посмотреть изменения для GCC 4.7, желательно прямой линк.

Что-то линкер из последней сборки для MIPS стал ругаться на инверсию атрибута в описании блока памяти в скрипте линкера. MEMORY { kseg1_data_mem (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x20000 } ../../../mips-kgp-elf/bin/ld.exe: invalid syntax in flags collect2: ld returned 1 exit status Меняю ld.exe на предыдущий (4.6.0 от 25.07.2010) - все нормально компилируется.

Вопрос к CADiLO. Так можно ли подключаться к SIM300 от контроллера с питанием 3.3В с использованием последовательных резисторов? Недавно на форуме вы вроде бы говорили, что только 3В допустимо. Теоретически, по аналогии с микроконтроллерами с защитными диодами, работать с 3.3В сигналами и резисторами модуль должен, но как происходит реально в жизни, сталкивались ли вы (или ваши клиенты) с проблемами при 3.3В питании?

Printf в симуляторе elf-run из под Win32 действительно не работает. В том числе и если запускать target sim в gdb. Об этом уже спрашивали на ARM форуме Sourcery, правда без ответа... Не работает вывод и в симуляторе сборки Клена. Наверное, какая-то общая проблема в заглушками (системными вызовами) для функций _write и т.п. Надо качать ограниченную по времени версию полнофункционального Sourcery c IDE и использовать эмулятор qemu. Тогда printf заработает. Потом можно даже научиться запускать target qemu в gdb и вернуться к применению lite компилятора. К тому же, в qemu можно хотя бы приблизительно считать процессорное время таймером c0_count, а как это делать в sim я так и не нашел. Если я не прав (сам только недавно связался с gcc), с удовольствием выслушаю подсказку. Может надо Mingw доустанавливать?

Сейчас все заработало и графит тоже, правда эффект от него ничтожный - надо тестировать больше. И в некоторых случаях, старый MPLAB C32 дает все-таки лучший код (меньше и быстрее). А с PIC32 ситуация усложняется наличием кэша, когда для ускорения циклы развернули (-funroll_loops), но получили промахи в кэше и в итоге скорость упала. Хотя все это мелочи по сравнению с настройкой компилятора на использование родных и микрочиповских библиотек. Нормально это пока сделать не удается.

ошибки: сначала cc1.exe потребовал для работы libstdc++-6.dll, затем libgcc_s_sjlj-1.dll, закончилось все сообщением "The procedure entry point __qxx_personality_v0 could not be located in the dinamic link library libstdc++-6.dll."

Опция -floop-interchange выполняет лишь одну из возможных трансформаций кода, когда компилятор использует Graphite оптимизатор. Вот, что сообщает ваш компилятор, когда я задаю эту опцию: "sorry, unimplemented: Graphite loop optimizations cannot be used". А вот указание для использования этой опции: "To use this code transformation, GCC has to be configured with '--with-ppl' and '--with-cloog' to enable the Graphite loop transformation infrastructure". Может все-таки графит прикручен не полностью? Хотя и без этой опции результат отменный, а эффект от нее на моих тестах менее 1%. Итак, ваш компилятор дает самый быстрый (чем больше марков, тем лучше) и компактный код для PIC32. Это, кстати, опровергает утверждение разработчиков MPLAB C32 о том, что переход с GCC3.x.x на GCC4.x.x не оправдан из-за сильного увеличения кода при компиляции "на скорость".

Поздравляю, вот результаты для популярного теста Coremark для PIC32 MPLAB C32 v1.10b (GCC3.4.4) - 166.31 Coremark, размер кода теста - 30652 Sourcery G++ Lite 4.4-147 (GCC4.4.1) - 184.72 Coremark, размер кода теста - 23772 KGP 20100418 (GCC4.6.0) - 200.60 Coremark, размер кода теста - 23120 Все компилировалось с оптимизацией: -O3 -funroll-loops. Последние Sourcery имеют еще graphite loop оптимизацию (-floop-interchange), которая чуть улучшает результат. У вас она не поддерживается. Еще у меня линкер ругнулся на незнакомый таргет elf32-tradlittlemips, который задан в микрочиповском скрипте (я использовал его для линкера). Замена на elf32-littlemips помогла. Полученный ELF файл теста Coremark не захотел импортироваться в MPLAB, хотя файлы тестов попроще проходили. Но такое раньше было и с Sourcery в ранних версиях MPLAB, возможно дело в нем.

Перед поиском ответа, сначала нужно избавиться от предубеждений в отношении PIC24 и PIC32. Какие претензии в плане производительности могут быть к 16-разрядному ядру с 24-битной командой! (PIC24), которое читает/пишет RAM c одновременной сложной модификацией адреса за один такт, складывает два регистра и помещает результат в третий - за один такт, конвеер команд при переходе восстанавливает за два такта. И все это на частоте 40 МГц, без всяких тактов ожидания и почти без сталлов. RISC 32-битникам оно конечно уступает здесь (на этом тесте), но только за счет разрядности. То же можно сказать и про PIC32, который есть MIPS32 с оценкой производительности 1.56DMIPS/MHz против 1.25 у Cortex-M3 и менее 1.0 у ARM7/9. И при этом FLASH у него быстрее, чем у LPC17xx, плюс полноценный кэш имеется, хоть и маленький :) Добавлю, что представители ARM участвовали в разработке Coremark и как раз именно ARM использует его в своих PR целях. Например, как Cortex-A9 двоекратно побивает Atom.

Ситуация: Есть GSM-модуль на плате, которая устанавливается в металлический корпус. Корпус может заземляться, а может и не заземляться - на объектах будет получаться по разному. Для подключения антенны используется специальный коаксиальный кабель с SMA разъемом, который крепится на корпусе гайкой. Соответственно в этой точке минус платы будет соединен с корпусом. Вопрос: Можно или лучше не надо подключать минус платы к корпусу в других точках (например, через металлические стойки крепления)? Стойки крепления платы будут рядом (менее 10 см) c местом крепления разъема SMA. Ситуация осложняется тем, что к плате может подключаться не развязанный RS485, поэтому с минуса платы на заземленный корпус могут протекать какие-то уравнивающие токи и интуитивно понятно, что лучше их не пускать только по антенному кабелю.

Klen, можете собрать ветку 4.5 для MIPS ELF под Win32 хост?