- Каким образом указать линкеру воткнуть функции из Test.h(hpp) файла
в нужную область памяти? gcc. И чтобы отладка работала. Сейчас
делаю через атрибут, но это нужно пройти по каждой
вызываемой-подвызываемой функции и проставить этот атрибут. - Constantin24(03.08.2020 11:55, ARM, полностью)
- Вышла "юбилейная" версия STM32CubeMX 6.0.0 - Kceния(27.07.2020 20:03, ARM, ссылка, полностью)
- Хочу калибровочные значения записать во Flash. STM32F746, IAR 8.11.
Как выделить место во Flash, что бы транслятор это понимал и не
пытался на этой странице памяти разместить часть программы или
другие константы. Хотелось бы это сделать не трогая установки в
Project и не изменяя *.icf. - Sl(31.07.2020 19:16, ARM, полностью)
- В Keil v5 наткнулся на грабли: Какого-то хрена компилятор вызывает
не ту функцию, что требуется (похоже втуливает что то с
выравниванием 4). В результате hard fault... Как лечить? Гyдвин(616 знак., 23.07.2020 15:52, ARM, полностью)
- Короче... Особо буйные могут успокоиться, хлебнуть галоперидольчику
и скинуть смирительную рубаху. Бага нет! "Нестандартный язык" от
ARM все предусмотрел еще в 4 версии. Просто для v5 похоже сменились
"умолчания" для ключа компилятора "--pointer_alignment=xxx". Ну или
можно описать структуру вот так: Гyдвин(3109 знак., 25.07.2020 20:08)
- У вас на плате никаких передатчиков нету? С GSM модемом на борту и
процем STM32L151 тоже на hard fault нарвались, и плата в 4 слоя
была хорошо экранирована внутренними слоями, пока антенну на 90
градусов не развернул, hard fault не проходил. Программисты в шоке. - Visitor(25.07.2020 16:32)
- Короче, все печально. Поспрашивал коллегу, который занимается
частью проекта, в котором остались упакованные структуры. В IAR
точно также. Это не ошибка. Это сознательная диверсия. Некуда
ехать, приехали. - VLLV(24.07.2020 12:44)
- Функция memcpy не должна требовать выравнивания. Не морочь мозги,
покажи исходник на C. - fk0(23.07.2020 17:20)
- Хм... Дело обстоит еще интереснее - если прошагать отладчиком в
окне дизассемблера, эта __aeabi_memcpy4() отрабатывает без
hardfault. LPC1768 есличо... - Гyдвин(23.07.2020 16:03)
- IH.conag и buffer имеют тип char? - BlackMorda(23.07.2020 16:06)
- ВОТ!!! Гyдвин(1055 знак., 23.07.2020 19:10)
- Лично я не догоняю смысл одновременного использования #pragma
pack(1) и __align(4) применительно к struct {} Zoro(615 знак., 25.07.2020 16:19)
- ВОТ: SciFi(352 знак., 24.07.2020 10:28, ссылка)
- Aioeeeaaoiioaaie ieeooaaiieeo iaaiie! fk0(2534 знак., 23.07.2020 21:52, ссылка)
- в man memcpy написано что она принимает аргументы типа void* 3m(875 знак., 24.07.2020 08:41)
- А теперь представь, что "проверка адреса" выехала в compile time
(чтоб как раз не тратить на неё время, о чём ты пишешь) и всё
становится логично. Адреса в момент компиляции может и неизвестны,
но их атрибуты (выравнивание) берутся из типов и известны. - fk0(24.07.2020 11:32)
- C " ВСЕГДА" не согласен (от того и пострадамши :) Выравниваю для
контроллеров, в которых это требуется - для того же MSP430. Для
ARM7TDMI тоже бы учел. Но тут, млять, Cortex M3, аффтары которого с
момента появления били себя пяткой в грудь, что поддерживается
побайтный доступ, и x86 c Паскалем на другом конце. И до каких то
пор это было без извратов - есть стандарт для memcpy() и приведения
указателей. В том же Keil v5, если использовать библиотеку
"microLIB", все пучком - Гyдвин(27 знак., 24.07.2020 09:01)
- Это особенность ARM-архитектуры. При чтении/записи 32х-разрядного
числа игнорируются младшие два бита адреса. Архитектура x86 без
проблем может читать/писать по любому адресу. - Ale3000(24.07.2020 08:35)
- Все-таки остается одна неясность: il-2(361 знак., 24.07.2020 08:00 - 08:05)
- Речи правильные толкаешь :) Но компилятор, которому явно привели
тип указателя, но он "вызывает оптимизированную функцию которая
быстро копирует 32-битными словами" не имеет права на жизнь ;) - Гyдвин(23.07.2020 22:13)
- Почему "явное приведение типа указателя" считается каким-то
значимым аргументом? Всё равно перед вызовом memcpy эти указатели
неявно приведутся к void*. С тем же успехом можно в спортлото
написать. - SciFi(24.07.2020 09:57)
- gcc "чудный и замечательный" компилятор Zoro(183 знак., 24.07.2020 00:39)
- Проблема в том, что у тебя в программе _нет_ такого типа (U32, но
только "упакованный"). Если его руками создать, как в примере по
ссылке (внутри IY) -- то оно даже будет как надо работать.
Упакованные структуры это очень неполноценное и нестандартная
надстройка над C/C++. Не продуманная. Костыль. Её неспроста нет в
стандарте. Она "недоделанная" и не совсместима с моделью памяти и
системой типов C/C++. Стандартными (для C++, не для C) средствами
можно изголиться и сделать fk0(552 знак., 23.07.2020 22:28)
- Нет уж... Тысячи строк кода, драйверы, куски стороннего кода (та же
FatFs) и пр. как то не способствуют выворачиванию всего наизнанку.
А по этому топику: Cortex M3 (LPC17) имеет аппаратную побайтную
адресацию, посему фтопку компилер, взомнивший себя шибко
грамотным... Более ранняя версия работала "как в мудрых книгах
написано" - привели указатель к void* или char*, вызывается
предсказуемая библиотечная функция побайтного копирования (и все
остальные из string.h). И Гyдвин(118 знак., 23.07.2020 23:39)
- Говнокода. И не такие уж и тысячи. Практически всё что завелось не
на x86 такого говнокода не содержит. Потому, что и MIPS, и ARM --
это аппаратное исключение при невыравненном обращении и дальше либо
фиксация ошибки, либо программная эмуляция команды с невыравненным
чтением-записью (очень не быстро...) И даже на современном x86
словить исключение при невыравненном обращении -- запросто
(векторные инструкции). Ещё раз, повторю, упакованные структуры --
НЕ СТАНДАРТНАЯ ХЕРНЯ. fk0(3121 знак., 24.07.2020 01:19, ссылка)
- Все же тут похоже на глюк компилятора. PACKED это такой же
модификатор структуры как volatile или const которые должны
распространяться на все члены структуры. Соответственно, когда
делается &a.b на выходе должен получаться указатель с
соответствующим модификатором. А тут модификатор PACKED потерялся,
остальное последствия. Но я не большой знаток. - AlexBi(24.07.2020 09:53)
- А какой тип будут иметь по-твоему тогда члены структуры? Если в
структуры положить структуры и их тоже сделать packed -- получится.
А если в структуре уже лежит обычный int? Явно ж записано, что
такое-то поле -- int и с ним могут что-то делать и нельзя неявно
подменить тип -- работать перестанет (программист может начать
где-то сравнивать типы, например). Сама идея упакованных структур
-- не продуманная, в ней есть логические противоречия. - fk0(24.07.2020 11:46)
- В данном случае члены структуры должны становиться packed. А как,
по-твоему, работает (должно работать) volatile структура? Будут ее
члены каждый раз перечитываться? Указатель на члена структуры будет
volatile? AlexBi(405 знак., 24.07.2020 13:50)
- С чего ты решил, что они кому-то что-то должны? Где это написано?
Тип поля, если это не вновь определяемая на месте структура, уже
определён ранее и измениться никак не может (иначе это другой,
новый тип должен быть). А выравнивание и размер -- это атрибуты,
свойства, типа. Поэтому если ты в упакованную структуру положишь
ранее определённый тип, то он сохранит свои свойства. Структура
останется с "дырками" для выравнивания, обычный int сохранится с
alignas(4). Что мы и fk0(263 знак., 24.07.2020 14:34, ссылка)
- В студии не хватает кода. Там запросто может быть два определения
структуры -- с packed и без. - SciFi(24.07.2020 09:59)
- Вот суть: Гyдвин(1541 знак., 24.07.2020 10:24)
- тут знаю одно - атрибуты packed и volatile при пропускании через
формальные параметры функции завсегда теряются, но по ходу успевают
цепляться яйцами:) Vit(147 знак., 23.07.2020 22:12)
- Да и ты сделал #pragma pack, но нихера не вернул обратно (через
pragma push/pop -- смотри у меня пример по ссылке). В итоге у тебя
вся программа "упакованная" и глючная. Хуже того, в зависимости от
порядка включения хедеров одни и те же структуры в разных модулях
могли оказаться упакованные или нет. Кровь, кешки, фарш! - fk0(23.07.2020 21:55)
- Нужно весь тип структуры смотреть - пакед, не пакед, что впереди,
размерность. - VLLV(23.07.2020 16:29)
- есть утилита для jlink, которая сохраняет принятые данные SWO в
файл? - Constantin24(21.07.2020 20:26, ARM, полностью)
- По поводу грабель компиляторов: il-2(453 знак., 24.07.2020 14:56, ARM, полностью)
- А может кто делал, реальную подстройку битрейда по sync в LINBUS??
поделитесь опытом ! - Aleksey_75(21.07.2020 19:18, ARM)
- Возможно ли на STM32 сделать так, чтобы один его ЦАП работал на
внутреннем Vref, а другой на внешнем? Kceния(93 знак., 18.07.2020 08:16, ARM, полностью)
- По моему там и АЦП обычно в куче. Работал с F1, F4, L4. - VLLV(18.07.2020 19:11)
- Имя, сестра! Имя! Они все заметно разные, указывайте конкретную
модель. - LightElf(18.07.2020 12:33)
- Мне любую назовите, которая это может. У меня же пока впечатление,
что не может ни одна. Kceния(463 знак., 18.07.2020 20:26)
- Задействовать встроенные (например в G4) операционники не вариант? - LightElf(19.07.2020 17:59)
- А в чём выигрыш по сравнению с "умножить в цифре и вывести на
единственный ЦАП" ? - Samx(19.07.2020 02:50)
- Если умножать, то пришлось бы по одной точке клевать - умножаешь,
выплевываешь в ЦАП, ждешь завершения операции. А у меня несущая
поступает на DAC1 непрерывно циклической передачей из буфера через
DMA (как у DDS). А огибающая, будучи низкочастотной, уже может
быть, не торопясь, вычислена (например, распаковкой MP3), т.к.
время здесь уже есть. Кроме того, мелкие нарушения периодичности
при изменении огибающей на слух незаметны, тогда как нарушения
периодичности несущей Kceния(110 знак., 19.07.2020 03:45)
- А что мешает умножить в цифре все значения несущей в буфере на
медленную огибающую, сохранить эти значения в новом (или в том же)
буфере, а уже потом "непрерывно циклической передачей из буфера
через DMA (как у DDS)" подать на DAC1 уже промодулированные
значения? - Xaoc(19.07.2020 18:18, )
- Ну против джиттера есть буферизация. Скажем, по таймеру выводим
предыдущее рассчитанное значение и Samx(57 знак., 19.07.2020 04:11)
- Если по таймеру выводить, то еще медленнее будет, т.к. придется
зарекаться на самый медленный случай. А вы вообще в курсе, какого
порядка радиочастоты? - Kceния(19.07.2020 04:32)
- RF band: 47 MHz to 6.0 GHz: Xaoc(6 знак., 19.07.2020 04:56, , ссылка)
- Это слишком жирно для меня. Моя задача скромнее: несущая 150 КГц,
представленная хотя бы 128-ю точками, итого 19.2 МГц на DAC (вроде
бы должен успевать). - Kceния(19.07.2020 05:19)
- вы можете сделать это ШИМом с входной частотой 19М а потом
отфильтровать этот ШИМ - General(19.07.2020 18:57)
- Хм. "Мелкие нарушения огибающей" (один сомножитель) не страшны, но
при этом несущая (второй сомножитель) зачем-то представляется 128
отсчетами на период. Samx(164 знак., 19.07.2020 14:37)
- Сотый раз спрошу, откуда такая "скромность" - 128 точек? - Kpoк(19.07.2020 11:18)
- Мы про эту задачу читали года два назад ещё. Сколько можно?
Некоторые за это время уже бы 500 проектов сделали! - fk0(19.07.2020 10:45)
- Задача может быть всегда одна, скажем, радиосвязь или телефония, но
иметь множество различных реализаций. Собственно и сам прогресс
идет в основанном за счет повышения эффективности решений, а не за
счет выдумывания новых задач. А ваше замечание того же рода, как
"Попов же уже изобрел радио, сколько можно этим заниматься?". - Kceния(19.07.2020 11:12)
- Вообще-то, ещё три года назад.. Увы и ах!.. Xaoc(20 знак., 19.07.2020 11:08, , ссылка)
- А может банальный ГУН/АМ модулятор и не тянуть сюда ЦОС? - VLLV(19.07.2020 09:00)
- Для этого есть сразу RF-микроконтроллеры. lloyd(96 знак., 18.07.2020 21:14)
- stm32f103 + usb - а где конфиг порта?... POV_(324 знак., 10.07.2020 11:33, , ARM, полностью)
- на какой реальной (а не теоретической) скорости можно затаскивать
данные по USB в одноплатник класса Orange PI One, ZeroPI, NanoPI и
пр. делаю приблуду, где первый какой-то старший STM32 снимет образ
специальной камерой и этот образ весом в 3 МБ надо максимально
быстро (не более 100...150мс есть на это) затащить в одноплатник
для последующего кручения-верчения. Sylvan(207 знак., 17.07.2020 11:06, ARM, полностью)
- [i.MX RT600] 300 МГц Cortex-M33, 4.5 МБайта SRAM, PowerQuad DSP, Cadence Xtensa HiFi4 Audio DSP 600 МГц, BGA 0.5 с прорежением,
-20 °C to +70 °C Evgeny_CD(906 знак., 16.07.2020 02:53 - 02:56, ARM, ссылка, ссылка, полностью)
- Есть ли в природе быстрая
арифметика конвертация данных 24->32 бит из массива для Cortex M7? BlackMorda(1321 знак., 07.07.2020 09:21, ARM, ссылка, ссылка, полностью)
- Не хочет USART2 в STM32L072 корректно работать на прием. BlackMorda(826 знак., 29.06.2020 19:39, ARM, ссылка, полностью)
- Как-то подобная проблема была, решилось переводом пинов в режим low
speed и включением внутренних подтяжек чипа. TX умудрялся насрать в
RX, несмотря на подключенный к ним ST232 - LightElf(03.07.2020 10:20)
- "Пауза одна секунда"??? А ничего, что от модема тут же обратно
данные попрут и их куда-то складывать нужно? - fk0(30.06.2020 10:49)
- а подробней можно про "все равно помехи"? У меня вот L476 тоже
связан с SIM800 но через USART3. Случайным образом на приеме
портились байты (абстрактные символы выскакивали). На любой
скорости от 9600 до 115200. Долго грешил на автоопределение
скорости. Выключил ее и в начале сразу задаю 115200. Стало реже, но
проскакивает. Вроде бы поигрался уровнями и вместо требуемых 2,8В
выставляю 2,6В. Стало вроде совсем хорошо. Но гарантии? - Лaгyнoв(30.06.2020 09:54)
- А если посылать единичный байт с интервалом сотню мс, есть сбои?
Два стопа на передачу в пакете, есть сбои? - VLLV(29.06.2020 22:15)
- "TXE устанавливается вместе с ошибками ORE NF FE" бррр, "ORE NF FE"
у вас данные как минимум не вычитаны из DR регистра. касаемо TXE
онтам всегда висит , смотрим на TCI флаг - Aleksey_75(29.06.2020 19:57)
- stm32, uart, борьба с эхом ))) Aleksey_75(640 знак., 02.07.2020 20:27, ARM, полностью)
- Если не склероз, эхо на LIN необходимо, чтобы определять коллизии.
Щетаю, что вам надо не подавлять его, а всячески пользовать. И
ориентироваться на RXNE/IDLE вместо TXE/TC. Ну и камень конкретный
указать, да еще и номера USART на нем, они часто разные. - LightElf(03.07.2020 10:12)
- Любое эхо можно отсечь. На то оно и эхо. il-2(635 знак., 03.07.2020 07:55)
- В общем случае от эха принципиально не избавиться. Такая же
проблема как с модемом (когда ATE1). Ты должен понимать протокол и
игноровать эхо. Трюки с запретом приёма сомнительные, т.к. требуют
исключительно точного соблюдения таймингов (на МК можно
извернуться, но и то с ньюансами), а если предположить "резиновый"
fifo-буфер на передачу и приём (как это происходит с типовой
операционкой), то никак. - fk0(02.07.2020 23:39)
- 1. Сталкивался еще на токовой петле. Нет красивого решения, эхо в
шлюзе может быть подавлено только для пакетного обмена, если
предусмотрен тайм-аут с запасом. 2. Сталкивался недавно в
оптическом канале см ссылку, но проект заглох, и хз как придется
выпутываться. - VLLV(02.07.2020 20:44)
- Что то не могу найти инфу - если я возьму stm32 , прошью его в
stm32duino - смогу ли я использовать arduino библиотеки для TFT
дисплея ili9341, или там нереальный гимор? Задача - вывести на
дисплей крупный текст, не парясь с попиксельныйм выводом, а юзая
вызов библиотеки. Что то под HAL и SPI не могу найти простого
решения для BluePill stm32f103c8t6 - Mty1(28.06.2020 01:02, ARM, полностью)