Xenia

Тем не менее, HAL во всю использует LL-макросы внутри своего кода, не пытаясь их подменять своими. Поэтому вполне естественно использовать какие-то LL-макросы при программировании из-под HAL. Однако случаются и разночтения, когда LL- и HAL-функции имеют разные по формату параметры, но имеющие сходные названия и смысл, а потому смешивать оба эти жаргона следует с осторожностью.

Предлагаю дискуссию на тему "это мне нужно, а этим я не пользуюсь" отложить. У нас сейчас на FTP свободного места 14 ТБ (терабайт!). Это весьма много, учитывая, что за все годы FTP накопила только 7 ТБ. Т.е. и места для хранения у нас сейчас достаточно, и ссылки на Альтере преимущественно прямые (без хэша и без https), что позволяет заливать их прямо на сервер достаточно быстро (межсерверные каналы связи обычно более толстые, чем у провайдеров домашних сетей). По части контекста, требующего спасения, прошу держать связь с MaratZuev'ым - он в этом деле понимает больше меня. А я залить файлы ему помогу.

Присоединяюсь к вопросу MaratZuev'а. Информация, объявленная топикстартером: имеет прямое отношение не только к частным коллекциям, но и к местной FTP-библиотеке. А потому было бы желательно всем нам совместно решить, чего там еще не хватает, чтобы затариться тем, что вот-вот грозит исчезнуть навсегда. Я, как библиотекать этого FTP, тоже в этом крайне заинтересована. А со своей стороны могу оказать помощь в ускоренном скачивании файлов с сайта Altera.com в наше хранилище, посредством прямого межсерверного обмена - в этом случае файл по внешней ссылке закачивается СРАЗУ в нужный директорий нашей FTP-библиотеки, минуя необходимость промежуточного скачивания этого файла на персональный компьютер, что затем его залить на FTP. Так получается много быстрее, тем более что размеры файлов порой очень велики, а ftp-доступ сейчас работает с перебоями. Однако мне для этого нужна ваша помощь, поскольку на сайте Altera.com у меня аккаунта нет, и прямые ссылки мне недоступны. Отсюда и возможность взаимно-полезной кооперации: вы мне ссылки, а я вам файлы :). А точнее - я их вместо вас залью на FTP. Позитивный опыт у меня уже имеется - версию "Quartus 19.1" целиком (Standard+Pro+Lite+Drivers), общим объемом около 370 ГБ, удалось скачать за ночь, запустив скачивание вечером. Тем не менее, наиболее важно сейчас решить, что именно надо срочно спасать и на FTP складировать. Я же одна этот вопрос решить не могу, т.к. c Квартусом никогда не работала и этой кухни не знаю. Тем более что там еще и Linux.

Вы не поняли. Мы (я и kv_addr) НЕ хотим операционную систему, но я опрометчиво выразилась "HAL выглядит, как операционная система", из-за чего kv_addr немедленно забраковал HAL под предлогом "мои поделки не требуют операционной системы". И теперь у меня никак не получается забрать те слова назад.

Я зря вас испугала термином "операционная" система, поскольку никакой там многозадачности нет. Но системный таймер тикает :). А для меня этого уже достаточно, чтобы считать систему живой :) и называть ее операционной. Тем не менее, этот таймер нужен, т.к. для обслуживания периферии бывают нужные какие-то задержки, хотя чаще всего он применяется для организации таймаутов, когда функция слишком долго не отвечает. Т.е. по своей сути он и в самом деле HAL, представляющий фундамент для установки узкоспециализированных "кубиков". Причем, фундамент отнюдь не громоздкий. Более того, даже удобный тем, что берет на себя практически все обработчики прерываний, превращая их в функции пользователя, и зачатую автоматически выполняющий рутинные операции по выходу из них, "успокаивая" ту периферию, которая их вызвала. Так что если STM32 знаешь плохо, то HAL - весьма полезный инструмент, освоение которого со временем позволяет обходиться без него. Т.е. он не берет вас в рабство, как Delphi :). У меня примерно та же история. Прежде сидела на AVR и была всем довольна :), разве что только тактовую частоту хотелось поднять и плавающую арифметику получить. Но после того как Мирочип съел Атмела, надежды на прогресс по части AVR рассеялись. Но главным поводом изменить AVR явилось то, что китайцы стали продавать широкий ассортимент готовых плат на STM32 по предельно низким ценам. А именно по цене, примерно равной розничной цене голой микросхемы контроллера в российском магазине, на фоне того, как AVR-чипы продолжали дорожать. Это решило всё, т.к. я сама изготавливать платы не умею :), тогда как китайцы предлагают их уже готовыми по цене в несколько палочек мороженного :). Вот и пришлось CubeMX изучать, как самый быстрый способ въехать в ARM-архитектуру.

В отношении CubeMX я тоже начинающая, но зато у меня свежий взгляд на вещи :) С моей точки зрения HAL выглядит, как операционная система, предоставляющая программисту обширный API. В ней даже таймер тикает. Вот и CubeMX генерит свой код, активно используя этот API в качестве строительных кубиков. Причем, эти кубики работают достаточно автономно друг от друга, что радует тех, кто прежде использовал ASF на архитектуре AVR. Т.е. разобраться с HAL нетрудно, хотя и выучить все его функции невозможно :). И тут только один метод посоветую - читать код исходников. А кто чужой код патологически не воспринимает :), тому лучше HAL не использовать, т.к. объяснения к нему плохие (недостаточные). Тогда как LL - это просто макросы, хотя и построенные под одну гребенку (общие дефиниции). Этот LL с HAL даже не сравнить! Например, на HAL в один присест можно написать CDC- или HID-девайс для USB. Или АЦП, собирающий данные через DMA. Тогда как чтобы на одном LL такое написать, нужно быть большим гуру :).

Я там тоже уже смотрела, а про крышку потому и спросила, что фото с крышкой там нет. Хотя за 3500 руб могли бы и крышку сделать :). А вам не кажется, что цена у этого продавца даже за вариант с крышкой (а это 3000 руб) слишком велика для программатора китайского производства? Когда я себе китайский J-Link покупала (на вид такой же, только версия V8), он стоил 582 руб, хотя тогда курс у рубля был повыше (около 60 руб/$). Т.е. по цене порядка $10. А этот, что на картинке, - совсем полный грабеж.

А у того, что с дисплеем, крышка сверху есть? Или он не закрывается? А то на картинке у truevoxdei он голенький, а потому вопросов не вызывает, а у того, что с aliexprеss снизу видна черная корпусина (оба винта именно в нее закручены), из-за чего возникает резонный вопрос - имеет ли она ответную часть сверху?

Googlе находит только ту картинку, что находится в этой теме, сообщая "Изображения других размеров не найдены". А на Aliexpress у китайного JLink'а нет дисплея, и выглядит он иначе, чем здешний. Вы разве сами этого не замечаете?

Хоть бы ссылочку дали на место, где китайцы это продают. А то как искать по картинке?

Конечно же, я не против, если код станет короче или быстрее. Однако новичку для освоения HAL будет полезнее, если он будет придерживаться того же стиля, в котором CubeMX автоматически генерит свой код. Т.е. сейчас ситуация того рода, когда понимание авто-генерируемого кода куда важнее сэкономленных байт. Наибольшая опасность, когда пропадет желание разбираться с этим кодом, полагаясь на то, что CubeMX сделал все правильно. Главная проблема работы с HAL через CubeMX, как я ее вижу, состоит в том, что что свой код приходится пихать лишь в специально отведенные места (там, где в комментариях написано "USER CODE"). И если эти места оптимизировать так, как вы посоветовали, то в следующий раз CubeMX это место не узнает. Тогда как инициализация портов обычно погружена в файл stm32xxxx_hal_msp.c, где структуры инициализируется последовательным заполнением полей. Более того, структуры там намеренно не константные, а именно - заводится одна структура на всё про всё, заполняется и отправляется на инициализацию, потом она же заполняется по-иному, и отправляется на инициализацию другого пина и т.д. Короче говоря, искусству программирования следует учить в другом месте и в другое время, а не морочить человеку голову, когда его волнует совершено другой вопрос - понять, как работать с HAL.

Можно. Но стоит ли экономить на спичках, когда весь HAL в таком стиле написан? Вы хоть смотрели на его исходники? А если да, то должны понимать, что черного кобеля не отмоешь добела :). На фоне того, как там написан код, экономия, которой вы предлагаете заняться, выглядит просто смешно, если не нелепо.

Сложно запомнить, в каком порядке следуют поля в этой структуре. Развернутое присваивание само служит подсказкой, а изменение порядка строк там безвредно. Тогда как в записи const GPIO_InitTypeDef GPIO_InitStruct = { GPIO_PIN_11|GPIO_PIN_9, GPIO_MODE_AF_PP, GPIO_PULLUP, GPIO_SPEED_FREQ_LOW, GPIO_AF1_TIM1 }; не мудрено ошибиться.

Можно, но забывается порядок перечисления. Кроме того, у STM32F1 и STM32F4 эти структуры разной длины - у последнего в этой структуре есть еще член GPIO_InitStruct.Alternate и сложно будет вспомнить, в какое место его добавлять, если структуру инициализировать целиком.

Только так: GPIO_InitStruct.Pin = GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3; GPIO_InitStruct.Mode = GPIO_MODE_INPUT; //GPIO_MODE_OUTPUT; GPIO_InitStruct.Pull = GPIO_PULLDOWN; // GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); т.е. заполнить структуру GPIO_InitTypeDef (целиком!) и скормить ее функции HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

Обычно так: HAL_GPIO_WritePin( GPIOC, GPIO_PIN_11 | GPIO_PIN_12, GPIO_PIN_RESET); - это пример того, как в порту GPIOC устанавливаются в низкий уровень пины GPIO_PIN_11 и GPIO_PIN_12 сразу. А если им надо высокий уровень установить, то так: HAL_GPIO_WritePin( GPIOC, GPIO_PIN_11 | GPIO_PIN_12, GPIO_PIN_SET); В том случае, если пин нужно перевести в противоположное состояние, то так: HAL_GPIO_TogglePin( GPIOC, GPIO_PIN_10);

Тогда еще разик и мой ответ послушайте: мне нужен пример, где SDRAM не используется, а если CubeMX сообщить о существовании платы STM32F429I-DISCO, то он сделает графику через SDRAM, да еще и FreeDOS туда загонит. Почитайте сами, что пишет CubeMX при попытке подключить графику:

Как это почему? Программку готовую хочу :). Я так и сказала - примерчик нужен, чтобы "Hello World!" на этот дисплей выводила. А я в даташит ILI9341 как заглянула, там мне сразу же поплохело :). Даташиты на МК с интересом читаю (вероятно потому, что много ранее известного там встречаю), а даташит на дисплей ну никак не идет. Я уже говорила - не любят меня дисплеи :) и я их взаимно не люблю.

Почему не хочу? Хочу! Вот только SDRAM не хочу использовать. Отсюда и мой вопрос о том, является ли обязательной жертва SDRAM, чтобы пользоваться этим дисплеем. Или в упрощенном/терминальном режиме есть возможность этой жертвы избежать? Вижу, что STemWin требует этой жертвы, потому и тот вопрос, есть ли ей замена под тем же CubeMX/HAL, если требования к графике снизить до минимума.

Вот я бы и хотела такую библиотеку, чтобы с ILI9341 не кодами разговаривать, а сразу функциями готовых примитивов. А то микроконтроллеры слушаются меня, а дисплеи нет :). Потому и в эту тему заглянула, что в ней моя плата STM32F429I-DISCO упоминается и графика для нее обсуждается. Да, именно режим терминала мне и нужен. Так есть для него что-то готовое или с нуля начинать - даташит на ILI9341 курить? :)

А возможен ли компромиссный вариант: буфер завести, но маленький - только на одну строку текста. И не в SDRAM , а в оперативной памяти (на одну строку текста в ней место найдется). А дальше выводить текст построчно, как раньше DOS в консольном режиме делала :). А если бы этот дисплей умел бы и ранее напечатанный текст вверх сдвигать (чтобы освободить на странице нижнюю строку), то вообще было бы полное счастье :).

Я только за тем в эту тему пришла, чтобы выяснить, способен ли этот хваленый "TouchGFX Designer" работать без SDRAM. Ведь не на всех же платах микросхема SDRAM припаяна. Об этом я интересовалась, как в своем первом сообщении: Так и в последующем: И на счет фабричной демо-программы уже несколько раз говорила - не надо мне ее, не надо! Неужели вы думаете , что я дура такая тупая, что в демо-программе мне могу их текст на свой "Hello, world" заменить? Тем не менее, несмотря на мои протесты, именно ее мне в нос настойчиво пихают. А про тестовый вывод я вынуждена повторять по другой причине. Потому, что если я этого не скажу, то сразу же заработаю ответ: "Как же вы без буфера на экране будете мультики показывать? Вам без буфера не обойтись! Иначе движения будут прерывистыми". Потому я подчеркиваю, что динамика мне не нужна - если потребуется, то буду хоть целую минуту ждать, пока дисплей мою строку теста выведет, только чтобы только не строить графический образ этой строки (или вместе с ней всего экрана) в SDRAM. Соответственно этому, я и от графических библиотек ожидаю примитивов, которые бы именно на дисплее могли что-то рисовать, а не в памяти SDRAM. Ну, а если дисплей собственных шрифтов не имеет, то хотя бы примитив, позволяющий вывести иконку 8х8 с изображением символа в любое заданное место экрана.

Слово "перерисовка" следует конкретизировать. Если мигает периодически из-за того, что механизм отображения не ведает о том, произошли изменения в буфере или нет, а потому долбит его на экран непрерывно, то это беда. Но если мигает только в тот момент, когда на экране меняется изображение, то это вполне терпимо, а порой даже целесообразно, т.к. этим своим миганием привлекает внимание пользователя к тому, что изображение изменилось. Лично меня мигание в момент изменения текстовой страницы вполне устраивает, т.к. я ее обновляю редко и всю целиком. Но если один и тот же текст периодически мигает из-за того, что дисплею заняться больше нечем, то это уже никуда не годится.

Именно поэтому я сразу заявила, что демо-программу обсуждать не хочу. И вообще всё, где торчит хедер "stm32f429i_discovery.h" Потому что он что ни попадя переопределяет на свой лад. Я же говорила, что эту программу видела (в кодах разбиралась), а потому и видеть ее больше не желаю. Тогда как вы, вероятно, дальше main() не заглядывали, а потому LCD_Init(); LCD_LayerInit(); кажется вам легким и простым, т.к. вы не видели всего того дерьма, которое за этой простотой стоит. Так я же не видеофильмы на этом дисплее собралась крутить, а время от времени (не чаще 1 раз в секунду) обновлять на экране текст. Типа измерялка у меня на этом МК работает, а человеческий глаз все равно цифирь, меняющуюся чаще, чем 1 Гц, не воспринимает. Типичный пример - напольные весы :). У меня хоть и не весы, но ситуация похожая - надо каждую секунду число на экране обновлять, если оно изменилось. Отсюда и мое желание вывести на экран текст (число у меня 7-значное), а не показывать мультики, непрерывно гоняя содержимое SDRAM на экран. Причем SDRAM мне нужна для иных целей - для накопления данных. Я понимаю, что такой дисплей, какой установлен на этой плате, для моих целей не нужен (избыточен). Но не вырывать же мне его с корнем, раз уж он там уже стоит?

И как это у вас реализовано? Внешная SRDAM используется или нет?