nanorobot

Перепрошил STLink последней прошивкой. В итоге под виндой пришлось ставить новй драйвер. Но под виндой я не работаю, а перепрошитый STLink в линуксе не виден из OpenOCD. В директории /dev он присутствует как stlinkv3_0 и stlinkv3_2. Тема насчет STLink v3 + openocd гуглится, но есть нюанс. OpenOCD собирал по статье RTT с помощью OpenOCD (без J-Link и без софта от Segger) уважаемого arhiv_6. То есть хотелось бы сохранить возможность работы с Segger RTT, и использовать STLink с последней прошивкой. Собрал OpenOCD по ссылке https://mbd.kleier.net/integrating-st-link-v3.html , работу с STLink v3 поддерживает, но со скриптами, обеспечивающими работу с Segger RTT, как и ожидалось, нет. То есть это две разные ветки проекта OpenOCD? Может они где то пересекаются?

Готовый бинарник скачивал с сайта ST, все работало. Именно для этой дискавери. Но ссылкой не поделюсь, не помню. Прошло от полутора до двух лет. Вполне вероятно что тогда еще TouchGFX не был куплен ST, и демо я скачивал не с сайта ST, а с сайта TouchGFX.

Segger RTT в проекте для CortexM0. Linux/GCC/Eclipse. Причина в оптимизаци. Добавил опрос _SEGGER_RTT.acID[0] на ненулевое значение, все более менее пришло в норму. Почему более или менее а не плоностью: при включенной оптимизации высокого уровня обычно при пуске вывод на терминал не работает. НО если программу запаузить, и посмотреть содержимое буфера _SEGGER_RTT, то можно увидеть, что он заполнен отладочным выводом. Если после этого выполнение запустить снова, то вывод на терминал начинает выполняться. Но не всегда. Также это может зависеть от интенсивности вывода. В специальном проекте чисто для тестирования RTT, и не перегруженном другим функционалом, тоже все похоже. Для камней с ядром M4 таких заморочек с RTT не наблюдал. Как то все слегка загадочно. Но проблему, ради чего это все затевалось, решил.

при оптимизации > 0 все поля равны 0

Да, все именно так. спасибо. Сделал тестовый проект, чисто для отработки RTT. Без оптимизации все работает, а вот уже начиная с уровня оптимизаии=1, перестает. Засада в том, что проект, который требует отладки, при оптимизации=0, сам уже толком не работает. Я склоняюсь к мысли, что не работает именно из за недостатка скорости, недостаточной эффективности кода без оптимизации. Насколько помню RTT на M4 работало при разных уровнях оптимизации.

Вы не правы. 1. Почитайте статью. 2. Да, во всех случаях использую ST-Link V2. для М4 все работает как с STLink так и с JLink. Личный опыт. Или вы хотелм сказать что только JLink для CortexM0? Из собственного опыта?

Пользуясь статьей уважаемого arhiv_6 регулярно применяю Segger RTT для отладки проектов на STM32. До сих пор это были проекты на камнях с ядром М4. Сейчас возникла потребность отладки проекта на ядре CortexM0. И вот здесь имею сложности. Каждый раз получаю сообщение Searching for RTT control block 'SEGGER RTT хотя переменная _SEGGER_RTT в окне Expressions наблюдается, соответственно никакого вывода в терминал не происходит. Да, во всех случаях использую ST-Link V2.

Где то видел что процентов на 20 при той же тактовой частоте... Подводя итоги спровоцированного мной обсуждения, прихожу к субъективному выводу, что оптимальный (для меня) выбор - Renesas.

Достаточно для чего? Для генерации пикселклок? А для формирования изображения в буфере?

обЪем встроенной RAM в Н7 не позволяет использовать LCD 800x480 без внешней SDRAM, у которой, в свою очередь, быстродействие недостаточно.. сейчас есть некий Н7В3, с чуть большим обЪемом RAM, на пределе достаточном, но живьем нет нигде. У Вас есть опыт использования Н7 в подобных проектах (LCD 800x480)?

Главная вкусность PCB на двухслойке можно сделать для LCD 800х480, полагаю это скомпенсирует цену самого камня, bare metal все же по прежнему привлекает, несмотря на прежний негативный опыт с F429/F743. "не по зубам" - просто объективная оценка своего уровня компетенции, C STM32 чувствую себя уверенно, а тут терра инкогнита пока..

Renesas то тоже bare metal пользовали? Что-то не устроило в нем? Компилятор gnu или, может быть IAR? Вероятно какую то RTOS использовали? Прошу прощения, за обилие вопросов, очень уж меня этот камушек заинтересовал, да боюсь не по зубам мне будет.

разрешение в обоих случаях 800х480 / RGB565

У "товарища" (тоесть у меня) артефакты были совершенно иными, например при перерисовке окна, оно могло дергаться, частично ломаться и тд и тп. - было орпробовано на Discovery - F429 c 16 битовой SDRAM. Я предположил что это связано с недосточной пропускной способностью тракта ЯДРО- SDRAM-LTDC и вскоре я изготовил свой процессорный модуль на F439 c 32 битовой SDRAM. С этим модулем вышеописанные проблемы ушли. Но общая призводительнось заставляла желать лучшего. В дальнейшем, не ожидая особых улучшений, опробовал этот модуль с F746, особого прироста производительности не заметил, и глубже уже не рыл, перешел на линуксовую плату с iMX6ULL от starterkit.ru. Полагаю что природа артефактов на Вашей плате, совершенно другая, возможно связанная с использованием неких "плюшек" F746, которых нет в F439

не уверен, но SLIP это кажется практически то же самое, что и Wake, реализация которого описана Леонидом Ивановичем, правда для МК и для РС под виндой. Если это так, могу прислать свою версию (правильнее сказать, что она практически его, Леонида Ивановича, я внес незначительные правки), для линукса, Qt.