Шаманъ

Очередь данных в стеке не формируется - формируйте ее отдельно, а потом обрабатывайте в PendSV. Но для данной задачи это неэффективно и не имеет смысла - есть LDREX/STREX, если его не хватает, то есть запрет части или всех прерываний.

Как по мне указанный пик (да и nuc970) достойный конкурент stm32f7/stm32h7 с внешней памятью. Появился бы он немного раньше, я бы этот пик очень может быть применил в одном своем проекте, где сейчас stm32f7+sdram внешняя используются. На счет "ниш" согласен с Вами - если на чем-нибудь можно получить требуемый результат, то почему бы и нет?

Это я случайно отправил недописанное сообщение :laughing: , прочитайте его еще раз, я отредактировал...

Самый простой вариант объявить HardFault обработчик вот так: void HardFault(void) { volatile int i=1; while(i); } Когда вывалитесь в hardfault установите i=0 и прошагайте до выхода из обработчика - с довольно большой вероятностью возврат произойдет в место возникновения проблемы (ну или около него). Посмотрите состояние регистров и дизассемблером, что там делалось. Если Вам не повезло и HF произошел где-то в другом месте, то смотрите состояние регистра BFSR, BFAR и т.д.

Самой удобной "программой" для рисования шрифтов для маленьких экранов для меня оказался встроенный графический редактор MS Visual Studio.

Интересно, а смотрели, что там компилятор нагенерировал в memset?

Возможно сказывается неидеальность ЧФД и его выходных цепей? Интересно, а изменение установок битов ABP влияет на процесс?

Да без разницы. Такое впечатление, что с resetом это вообще не связано (может они его внутри подключить забыли :laughing: ). Да, пишется в память. Например, вот так: $_TARGETNAME configure -event reset-init { # Configure PLL to boost clock to HSI x 4 (64 MHz) mww 0x40023804 0x08012008 ;# RCC_PLLCFGR 16 Mhz /8 (M) * 128 (N) /4(P) mww 0x40023C00 0x00000102 ;# FLASH_ACR = PRFTBE | 2(Latency) mmw 0x40023800 0x01000000 0 ;# RCC_CR |= PLLON sleep 10 ;# Wait for PLL to lock mmw 0x40023808 0x00001000 0 ;# RCC_CFGR |= RCC_CFGR_PPRE1_DIV2 mmw 0x40023808 0x00000002 0 ;# RCC_CFGR |= RCC_CFGR_SW_PLL # Boost JTAG frequency adapter_khz 8000 #Confgure PLL SAI to clock LTDC (to prevend TFT degradation during flash loading) mww 0x40023888 0x69011800 ;# RCC_PLLSAICFGR LTDC clock = 16 Mhz /8 (M) * 96 (N) / 6® mmw 0x40023800 0x10000000 0 ;# RCC_CR |= PLLSAION sleep 10 ;# Wait for PLL to lock mmw 0x40023830 0x000001E3 0 ;# AHB1ENR Enable GPIO A,B,F,G,H,I # Configure GPIO A mww 0x40020000 0xA8000080 ;# MODER mww 0x40020008 0xFC0000C0 ;# OSPEED mww 0x40020020 0x00E00000 ;# AFRL # Configure GPIO B mww 0x40020400 0x000A0280 ;# MODER mww 0x40020408 0x000F00C0 ;# OSPEED mww 0x40020424 0x000000EE ;# AFRH # Configure GPIO F mww 0x40021400 0x00100000 ;# MODER DE=OUTPUT mww 0x40021408 0x00000000 ;# OSPEED # Configure GPIO G mww 0x40021800 0x0280A000 ;# MODER mww 0x40021808 0x03C0F000 ;# OSPEED mww 0x40021820 0xEE000000 ;# AFRL mww 0x40021824 0x0009E000 ;# AFRH # Configure GPIO H mww 0x40021C00 0xAAA80000 ;# MODER mww 0x40021C08 0xFFFC0000 ;# OSPEED mww 0x40021C24 0xEEEEEEE0 ;# AFRH # Configure GPIO I mww 0x40022000 0x0028002A ;# MODER mww 0x40022008 0x003C003F ;# OSPEED mww 0x40022020 0x00000EEE ;# AFRL mww 0x40022024 0x00000EE0 ;# AFRH mmw 0x40023844 0x04000000 0 ;# APB2ENR |= LTDC #Configure LTDC mww 0x40016808 0x00270013 ;# SSCR mww 0x4001680C 0x002D0016 ;# BPCR mww 0x40016810 0x034D01F6 ;# AWCR mww 0x40016814 0x041F020C ;# TWCR mww 0x4001682C 0x000000FF ;# BCCR mmw 0x40016818 0x00002220 0 ;# GCR mmw 0x40016818 0x00000001 0 ;# GCR } Команда mww addr word записывает слово word в память по адресу addr, команда mmw addr set clear модифицирует слово по адресу addr в соответствии с битовыми масками set и clear

Да вроде как ничего особенного AT070TN92.2.

Эх, не читаете Вы то, что я пишу. Я не предлагал критически важные вещи делать зависимыми от программатора. В то же время иметь возможность установить в произвольное состояние любые порты/внутренние регистры/память это однозначно хорошо. На счет кто будет настраивать, я тоже отвечал: Хоть ну, хоть без ну, но попробуйте включить подсветку, питание драйверов при активном reset'е. У меня идут такие же медленно расплывающиеся цветные полосы, что и без reseta. В этом состоянии есть постоянное напряжение на "ячейках" ТФТ индикатора, которое приводит к его медленной порчи. Возможно в других ТФТ все по-другому, но в двух которые у меня именно так...

А зачем он мне, если OpenOCD вполне справляется? Тем более я пользуюсь gcc/gdb, и не уверен, что st-link или j-link беспроблемно стыкуются с gdb. Зачем это делать? OpenOCD умеет заливать проги в несколько сотен разных процессоров, и не только заливать ;) Но если Вам хочется сделать что-то особенное, то нет проблем добавить несколько команд в скрипт :) Прогу в ОЗУ корректировать не нужно, она сама по себе. А что там с st-link? Вообще-то без тактирования с включенным питанием драйверов любой ТФТ по идее медленно деградирует. В принципе, испортить его этим не получится - слишком мало времени занимает программирование, но все же мне приятнее, когда он в нормальном состоянии.

Не знаю как в других, но OpenOCD шьет флеш-память с помощью маленькой вспомогательной программы в ОЗУ (другие думаю так же делают). Так что все работает, более того можно в скриптах включить PLL и получить приличное ускорение верификации программы. Проще OpenOCD наверное некуда. Подсветка не при делах - она ничего не портит (ну кроме разве что внешнего вида). А вот TFT который у меня хочет нормального тактирования вне зависимости от RESET.

Ну да, или с магией, по стандарту, но с кривой программой. Нет гармонии :)

Вашу мысль про устойчивость на аппаратном уровне поддерживаю, но чего это они все "в воздухе висят" во время программирования? Разве что инструмент программирования очень простой. В том же OpenOCD можно проинициализировать что угодно, и как надо (я, например, LTDC запускаю, чтобы матрицу не мучать во время программирования - показывает синенький экран :)).

В GCC более ранних версий предупреждений тоже не было, возможно у IAR все еще впереди :) Чтобы компилятор не ругался :) В реальности он у меня сейчас не ругается, но коряво это выглядит в коде, а когда красиво ругается. Нет. Он из-за стандарта ругается, ибо конструкция не по стандарту.

jcxz, тут больше вопрос не в том, как можно - сам знаю не один способ. Вариант с определением символов компоновщика вполне устраивает, просто программа написанная наиболее близко по смыслу не вписывается в стандарт С (хотя GCC все компилирует нормально, немного поругавшись). Вопрос скорее из серии перфекционизма :)

У меня стоит готовый T4-1 https://www.minicircuits.com/pdfs/T4-1.pdf , но можете намотать на небольшом ферритовом колечке в три провода. Еще пара моментов. У большинства кодеков выход VCOM очень слабенький, поэтому там нужен будет буфер-повторитель на каком-нить ОУ (лучше, если с полевиками на входе). Также параллельно входам кодека нужно еще добавить по конденсатору 1500пФ.

Автор помнится на time-nuts был? Раз пошло такое дело, то еще один пример от меня :) Вот кусок схемы блока ПЧ, 5МГц первая ПЧ, 24/35кГц вторая. Подключается прямо ко входам кодека. В оригинале (с АЦП CS5381) имеет Кш=13дБ, и IP3=+39дБм, односигнальный ДД 165дБ/Гц (в смысле приведенный к полосе 1Гц). Ради эксперимента использовал этот блок как приемник на 80/40м, проблем особых нет. Есть небольшой нюанс с делителем (для меня он не играет роли, т.к. первая ПЧ узкополосная), его можно обойти поставив 74АС74 и изменив подключение ключей.

А в чем смысл? В середине июня обещали вроде обновление "конкурентов" до 7 версии GCC. А как еще можно интерпретировать проблему с генерацией кода и показания загрузки процессора?

При токе около 40мА BFG591 у меня на столе выдавал IP3o = +44dBm :) Схема с ОБ и трансформаторной ООС, Ку около 9дБ, частоты 14..30МГц. Так что думаю это вполне реально. А, так то ж совсем другое дело. Я про один BFG135 говорил.

IP3=+35dBm это по входу или по выходу? Ну и про Кш=0.1..0.2дБ и прочее я так понимаю речь не про BFG135? А то я имел ввиду их. Если про них, то я совсем от прогресса отстал...

Рекурсия там есть - именно из-за нее в HardFault выпадает программа. Что неправильно - тут и обсуждать особенно нечего. С этой версией без -flto запустилось. Загрузка процессора в среднем больше на 2%, чем на 6.3.1, код больше на 6кБ. Сейчас с -flto соберу посмотрю. Мда... с -flto полная лажа - загрузка процессора больше в 2.5раза. Картина такая же, как на 6.3.1 при включении -flto и -ggdb3 :(

Странный подход у Вас. "Ничего вроде" - Вы ж понимаете, что это ни о чем не говорит. Ну да ладно. У меня используется в УВЧ BFG591 (+- то же самое, что и BFG135). В варианте с "бесшумной" ООС (усилитель Нортона с ОБ) он действительно по ДД очень крут. Но такой УВЧ в плане развязки выход-вход можно сказать совсем никакой. Т.е. гетеродин Вашего приемника будет излучать через антенну, не знаю существенно ли для Вас это. Другой нюанс это устойчивость такого каскада. Третий - трансформаторы дорогие, а Вы писали про минимальную стоимость. Без ООС ничего путного с ним, ИМХО, не выйдет, с "резисторной" ООС угробится Кш. А так, да, хороший УВЧ на нем можно сделать, весь вопрос подойдет ли для конкретного применения.

Не, там похоже все печальнее, ибо кроме "заглушки" есть еще остатки цикла и, главное, рекурсия. Что никак нормальным быть не может: Не вопрос, но у меня cortex-m7 (stm32f746). Да, memmove, memset и memcpy достаточно.

ну я просто из исходников libgcc.a от 6.3.1 закинул себе в проект все три функции, потому предположил, что они там должны быть. Вы видели код memset? Как Вы думаете это похоже на нормальный код? Вот исходник memset (взят из исходников libgcc.a от 6.3.1, но это никакого значения не имеет), что сгенерировал GCC 8.0.0 Вы можете посмотреть выше: /* Public domain. */ #include <stddef.h> void * memset (void *dest, int val, size_t len) { unsigned char *ptr = dest; while (len-- > 0) *ptr++ = val; return dest; } У меня тоже работает все, причем под любой версией "штатного" GCC. Могу еще попробовать собрать 8.0.0, но без -flto. Скомпилировал проект без -flto, и что Вы думаете...вот, так с точки зрения GCC 8.0.0 должны выглядеть функция memse (исходник см. выше), та же беда, что и с -flto: 2:memset.c **** #include <stddef.h> 3:memset.c **** 4:memset.c **** void * 5:memset.c **** memset (void *dest, int val, size_t len) 6:memset.c **** { 28 .loc 1 6 0 29 .cfi_startproc 30 @ args = 0, pretend = 0, frame = 0 31 @ frame_needed = 0, uses_anonymous_args = 0 32 .LVL0: 33 0000 10B5 push {r4, lr} 34 .cfi_def_cfa_offset 8 35 .cfi_offset 4, -8 36 .cfi_offset 14, -4 37 .loc 1 6 0 38 0002 0446 mov r4, r0 39 .LVL1: 7:memset.c **** unsigned char *ptr = dest; 8:memset.c **** while (len-- > 0) 40 .loc 1 8 0 41 0004 12B1 cbz r2, .L4 42 0006 C9B2 uxtb r1, r1 43 .LVL2: 44 0008 FFF7FEFF bl memset 45 .LVL3: 46 .L4: 9:memset.c **** *ptr++ = val; 10:memset.c **** return dest; 11:memset.c **** } 47 .loc 1 11 0 48 000c 2046 mov r0, r4 49 000e 10BD pop {r4, pc} 50 .cfi_endproc 51 .LFE0: 52 .size memset, .-memset klen, tсть какие-нибудь соображения?