Комментарии 46
Полезно.
Также работаю в последние лет 7 с STM, но сегодня с ними всё больше проблем. Дорого, сложно покупать в товарных количествах.Практически отрезали возможность работать с китайскими клонами да и нет гарантии что в один прекрасный момент отрежут доступ к CUBE-IDE вообще
Artery'шная Firmware library, это, конечно, намного лучше, чем STM32 HAL, но она абсолютно пустая. БОльшая часть кода - это синоним регистрового доступа. Я не сильно большой фанат таких библиотек (в самом деле, зачем вызывать функцию, если можно писать в периферию напрямую, все равно из TRM не вылезать)
Про многое из AT32 думаю, что "лучше бы они у ST этого не копировали бы", в частности ADC, модуль GPIO и прочие радости.
А почему именно этот мк, а например, не Gigadevice? Мы вот в своих устройствах успешно переехали на них с F4, причем остались на STшных библиотеках, подпилив их где надо и где они вообще использовались.
Это мне не ведомо. Сказали с Artery будем работать
Юристы из ST, кажется, очень не советуют использовать STшный код на GD чипах. Хотя... в некоторых странах это, наверное, уже не злободневно.
А есть какая-то ссылка на это?
Наверно стоит заглянуть в лицензию в файлах исходных текстов от ST. Обратить внимание на то, что програмные инструменты от ST не работают (или не должны работать) с чипами от других производителей. Наконец можно поискать в сетке людей уже наступивших на эти грабли: https://www.th3dstudio.com/2021/08/03/gd32-cpu-license-issues-attack-of-the-clones/
Сам вынужден был перетаскивать систему с STM32 на GD32 в прошлом году. К счастю, весь код опирался на регистры - заменяем один файл заголовков, подправляем чуточку код и наслаждаемся мелкими несвометимостями и особенностями GD32.
Ради интереса прошелся по тем файлам, которые мы используем...(мы не используем HAL, может там что-то и появилось)...и там есть только что-то типа:
* Redistribution and use in source and binary forms, with or without modification,
* are permitted provided that the following conditions are met:
* 1. Redistributions of source code must retain the above copyright notice,
* this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
* 3. Neither the name of STMicroelectronics nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Не увидел тут никаких явных запретов, но в любом случае, переписать на регистры недолго, если потребуется.
Окончательную ясность вносит содержимое первого пункта FAQ, находящееся в папке Documentation пакета STM32CubeF4 (для примера):
What is the license scheme for the STM32CubeF4 firmware?
The HAL is distributed under a non-restrictive BSD (Berkeley Software Distribution) license.
The middleware stacks made by ST (USB host and device libraries, STemWin, ST- TouchGFX) come with a licensing model allowing easy reuse, provided it runs on an ST device.
The middleware based on the well-known open-source solutions (FreeRTOS, FatFS, LwIP, and mbedTLS) has user-friendly license terms. For more details, refer to the license agreement of each middleware.
HAL пилить выходит можно. Ограничения начинаются на более сложных поделках от ST.
Мы просто с нуля пишем под гигадевайсы.
У юристов тут в первую очередь будет другой вопрос, который на скриншотах аккуратно обошли :)
Стоит попробовать поискать у ST прямой аналог этого Artery, эти не слишком оригинальничают. К примеру, у AT32F415 периферия содрана с STM32F10x, бинарник, собранный под ST (не использующий отсутствующий в АТ ADC2) работает и на том и на другом.
Кстати, у гигадевайса библиотеки под некоторые серии просто не собираются. В смысле не собирается пустой проект с одним мейном. Причём под соседний контроллер их той же серии всё собирается нормально.
Ещё один плюс, это очень много комментариев по всем функциям, что облегчает задачу.
А зачем комментариями засорять код?
Код итак уже есть документация на ПО. Зачем например вот это?
/* enable tmr1 tmr2 */ tmr_counter_enable(TMR1, TRUE); tmr_counter_enable(TMR2, TRUE);
// enable ledinit_led();
at32_led_on(LED3);
at32_led_on(LED2);
Ну и все в таком духе.
А ещё в прерывании, кроме флага ресет, хорошо бы ещё проверить, что само прерывание разрешено. А то может получиться так, что флаг ресет стоит, а прерывание пришло от другого источника и вы обработаете не существующее прерывание
Чем вам комментарии мешают? Для себя же полезно, через год вернуться и не ломать голову. Это же вам всё понятно,а есть те, кому нужно подробно
Тем что они замусоривают код и мешают пониманию кода. Если вы пишите комментарии, то, либо изначально код был плохой и непонятный, и его надо переделать, либо они не имеют смысла.
В вашем случае, никакой смысловой нагрузки у комментариев нет. Итак понятно, что там делается по названию метода. Вы просто замусорили код и его трудно читать. Язык программирования, это такой же язык общения, ведь вы не поясняете //описываете более детально смысл слов и не пишите //комментируете все по два раза в русском языке.
Комментарии должны пояснять, что не совсем может быть тривиально, например, сложный алгоритм, хотя лучше его описать отдельно в документе.
Следует придерживаться эвристического правила: если ощущается необходимость что-то прокомментировать, нужно написать метод. Даже одну строку имеет смысл выделить в метод, если она нуждается в разъяснениях[7].
https://ru.m.wikipedia.org/wiki/Код_с_запашком
Комментарии
Часто комментарии играют роль «дезодоранта» кода, который появляется в нём лишь потому, что код плохой. Почувствовав потребность написать комментарий, попробуйте изменить структуру кода так, чтобы любые комментарии стали излишними[17].
Если для объяснения действий блока всё же требуется комментарий, попробуйте применить «Выделение метода» (Extract Method);
Если метод уже выделен, но по-прежнему нужен комментарий для объяснения его действия, воспользуйтесь «Переименованием метода» (Rename Method);
Если требуется изложить некоторые правила, касающиеся необходимого состояния системы, примените «Введение утверждения» (Introduce Assertion)[17
Это лишь ваше мнение. И да, все комментарии из примеров, я их не писал. Вы можете у себя как угодно писать код. Я пишу как мне удобно, а не как кому-то хочется
Это же вам всё понятно,а есть те, кому нужно подробно
Я пишу как мне удобно, а не как кому-то хочется
Странно, противорячащие друг другу высказывания.
Но да ладно, я и не настаиваю, я лишь старался чтобы вы обратили внимание, на то, как можно улучшить читабельность кода и избавиться от дурного запаха. Но конечно, это ваше право.
И, кстати, это не моё мнение, это как бы общепринятое правило хорошего кода, как здороваться при встрече.
Можно же и не здороваться, но будет ли это способствовать эффективным коммуникациям, не думаю.
Это лишь ваше мнение
Это еще и моё мнение. @lamerok прав. В хорошем коде не нужны комментарии. Хороший код понятен и без комментариев за счет адекватных названий функций и переменных.
Кто нибудь разобрался как работает sram в artery? Я том плане что там у них написано 96 КБ + 128 КБ. И вот эти 128кБ они откуда берутся?
Есть "обычная" часть ОЗУ и есть часть ОЗУ, которая может использоваться как ОЗУ, а может как теневое ОЗУ, в которое при старте копируется часть FLASH и получается исполнеие кода zero-wait-state даже на 240МГц. А еще для части FLASH такое теневое ОЗУ есть аппаратно по умолчанию и при старте проц несколько миллисекунд еще до передачи управления на стартовый вектор копирует FLASH туда. Жрет при этом около 30 мА, что ставит крест на применении Artery F4 в устройствах, которые не способны обеспечить 30 мА. Вот такое вот ОЗУ
Благодарю, а то я сначала вообще понял, что есть быстрая flash на 240 МГц, и вот мы из нее эмулируем дополнительную SRAM
Проясните, пожалуйста, вот ещё какой момент. Помещается ли вся флеш полностью в это самое теневое ОЗУ и если нет, то как выполняется код из разных частей настоящего? Получается, что ему необходимо каждый раз подгружать нужный кусок или в случае чего происходит выборка прямо из настоящего флеша?
А мне показалось странным...
Задача : работа с КАН шиной на другом МК в серийном устройстве.
Кто будет делать? Может те кто делал и разрабатывал устройства на МК?
Нет! делать будет андроид разработчик!
ЗЫ: здорово если будет в серийных ладах сразу и без косяков работать
А вы знаете, работает. И неплохо. Думаете если человек разбирается в Java, он не сможет разобраться в программировании МК? Вы ошибаетесь, я разобрался
Нисколько не сомневаюсь и тем более не хотел вас обидеть - такие люди как раз спасают ситуацию.
Имел ввиду что "менеджеры" крупных предприятий доводят ситуацию иногда до абсурда.
Ничего страшного. Я тут один )
На самом деле — это ситуация довольно тревожная, причем как для Вас, так и для руководства. Сам в такой же ситуации, и лет 10 назад мне тоже казалось, что "Ничего страшного", а сейчас уже думаю по другому. Правда, и направлений не два, как у Вас (Java и эмбеддинг), а несколько больше. Все это со временем начинает очень выматывать, очень...
Я сам себе руководство) А прошивка для канбаса пишется один раз. Так что не страшно. Тем более приложение и канбас это единое целое.
Но я согласен, разрываться плохо
https://github.com/beefdeadbeef/libopencm3/tree/at32f4 -- форк libopencm3 для at32f40x, для любителей погорячее.
Если в ВАЗ такие работают, то нафиг этот ТАЗ нужен. Уровень детского сада, поморгать светодиодом.
В авиации делал CAN шину, свои протоколы и ARINC поверх наворачивал, stm32 серий с 1 по 4, сроки, месяц, до этого дел с stm и can не имел.
Итак, запускаем Keil. Нажимаем Pack installer. Далее Import Packs, находим расположение папки Keil5_AT32MCU_AddOn_V2.1.9. Выбираем наш МК и нажимаем "Открыть". итоге получаем такую картинку:
Написите лучше как собрать прошивку из ARM GCC и makefile. Keil-санкционка.
Как для любого ARM Cortex M4. Artery в этом плане ничем не отличается
А чем keil не нравится? Скачали и работаете
А чем keil не нравится?
ответ тут https://habr.com/ru/articles/723054/
Artery AT32F403A. Знакомство новичка