Solonovatiy

Ок. Я решил, ошибка была на моей стороне. Очень краткий гайд, если кому понадобиться: - Судя по тому, что F003 серия работает с ST-LINK (версию в логах поищите), наверно и остальные будут, т.к. эта -- наиболее уникальная. - OpenOCD от гихи надо либо билдить самому, либо скачать с гита гихи (не гуглиться, ищите руками) - Там будут спец конфиги для APM микроконтроллеров, в исходниках есть какие-то правки, возможно они важны, возможно, можно просто перетащить конфиги в обычную. - Дальше все по умолчанию.

Работаю через Clion, с STM и GD и клонами F103 все ок. Но вот тут пришелся APM32F003 который какая-то помесь STM8 по периферии и ARM ядром, питание 5В. Интерфейс SWD. С ним ничто напрямую через stlink заработать не захотело. В итоге нарыл инфу, что для него нужен спецовый билд OpenOCD от Geehy. Я ее нашел и начал пробовать запуститься через нее. Итог, я застопорился на ошибке "openocd.exe: unknown option -- interpreter=mi2" Мой конфиг выглядит как: source [find interface/stlink.cfg] transport select hla_swd set WORKAREASIZE 0x2000 set CPUTAPID 0x0bc11477 source [find target/apm32f003.cfg] reset_config srst_only Причем, есть еще "apm32f00x.cfg" и аутпут ошибки у последнего больше. Оба аутпута под спойлерами ниже. У них есть GEEHY-LINK, который суть тот же ST-LINK, только GEEHY-LINK, ну вы поняли. Я его конечно заказал, но я прям совсем не смыслю в OpenOCD, поколение IDE вся фигня, для меня вот все эти интерпретеры=MI2, hla_swd и прочие штуки вообще не понятны. Вопросы следующие: - У кого нибудь есть точная инфа о возможности и не возможности отладки через ST-Link? - Кто нибудь может пояснить ошибку in-depth, мне честно говоря проще забить и сменить контроллер, чем лезть в пучины OpenOCD, но вот некую абстрактную картину бы послушал. - Может кто поможет с конкретным решением? apm32f003.cfg apm32f00x.cfg

Ну это в DNS куплена была. Ща отдупил ее, у меня хост машина что-то затупила, разучилась писать в SD, перегрузил - увидела.

Ошибся, имел ввиду блоки по 512. Сколько он их читает не возможно определить ввиду протокола СД карты. Ну вообще это свежекупленная SP. Короче, проблема решилась так: 1. Я психанул и решил разобраться с IRC суньдзышным. Не отвечали мне там т.к. я не был регнут и сообщения не отправлялись = ) 2. Там мне ответили следующие вещи: - На вики не смотри, там херня написана. - Странная у тебя фигня. У нас тут бага была до пятницы. Весь аутпут в UART сжирала в никуда. Ты репу когда склонил? Я склонил репу в пятницу, за час до фикса. Сбилдил, залил и ... ничего. У меня сдохла SD карта, не хотела новый билд записывать, так и грузилась с предыдущего (2 часа назад судя по билд тайму). Нашел новую - завелось. Веселые у меня выходные короче были = )

Здравствуйте. Пытаюсь в кач-ве обучения собрать свежий Mainline U-Boot\Linux под Allwinner A20 (Cubieboard 2). Сам я тот еще хреновый пользователь линукса. (т.е. примерно на уровне лезу в гугл для копирования файлов). Абстрактно: Сейчас я пытаюсь собрать ТОЛЬКО ML U-Boot, запустить его и посидеть в его консоли. Само ML Kernel я не беру во внимание. Дополнительно: Cubieboard2 имели несколько вариаций железа, NAND\SDС0\SDС2 в разных комбинациях. У меня NAND\SDC2, uboot имеет только один вариант Cubieboard2_defconfig и судя по всему он грузиться с SDC0. В менюконфиг я установил "Card detect pin for mmc2" в PH0 (пин подведенный к SDC2_CD) и "mmc extra slot number" установил в 2. Что я делаю: Следуя гайду сундзы, я: 1. Собрал uboot. 2. Выполнил dd if=/dev/zero of=/dev/sda bs=1M count=1 sleep 1 dd if=u-boot/u-boot-sunxi-with-spl.bin of=/dev/sda bs=1024 seek=8 sleep 1 sync 3. Всунул карту, перезагрузился. Получаю следующий Output: U-Boot SPL 2023.01-00626-g1a0a172e1a-dirty (Jan 22 2023 - 23:24:03 +0300) DRAM: 1024 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 (ниже когда включил какой то из дебагов) Быстрая расшифровка: Карта обнаружена и инициализирована, успешное чтение 512 блоков с адреса 0xA000 (40 960). Но может посчитал не верно. После чего закрытие коннекта. Что в нем смущает? Ну во первых, то что после этого ничего не происходит. Во вторых, сундзы пишет https://linux-sunxi.org/EGON#eGON.BRM Что читать будет из 38192 (хотя, пишет же ЧТО-ТО, возможно это что-то как раз оттуда и считалось и хочет читать дальше). В третьих почему MMC1? У меня SDC0 интерфейс не распаян. SDC1 хрен пойми куда подключен, должен был быть SDC2 (схема есть и это таки он). Ну и вопрос, че мне дальше делать и куда залезть, что бы проверить что не нравится? Я реально немного в тупике.

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

Ой я чет решил сходить по хардкору в гугл. И понял, что правды не завезли. Кто-то говорит как вы, кто то разделяет HAL как содержащий в т.ч. BSP, кто то говорит как я - BSP содержит HAL. Привет OSI-проблемки. Вот например как эмбеддед раст это дело делят. Хз предлагаю не сраться за терминологию, привести строчки стандарта с определением сейчас, либо молчать вечно. А я вот про это кстати не подумал. Посчитал, что TrafficLight у вас в прикладном и в своем примере вынес его туда. Если считать, что TrafficLight сидит в BSP - то да, в том примере все хорошо. Ну просто это тогда ровно тоже самое, что я накостыливаю.

А я хз, почему все это упорно пытаются замешать с халом =\. Это же считай обертка под проект, просто четко проводящая границу между железом, хал если он есть - ниже. Это не про то, как написать очередной универсальную и гибкую оболчку очередного уарта, а скорее строго наоборот, написать максимально заточенную под проект, но при этом выжать по максимуму из этого. Хз, в принципе заключения из темы я сделал, не в том объеме, что ожидал, но хоть какие то.

ПЛК конфигурируется софтом, частотник - на объекте жмаканьем клавиш. Он не подобие ПЛК, пусть и часто с ними вместе сидит.

Наверное любой ЧП, у которого 5 входов и пара выходов, на которые может быть назначена одна из 999 функций. Практически любое оборудование-полуфабрикат. Не понимаю изначально отрицательное отношение к абстракциям. Наоборот же стоит резать, когда приходиться. Нужды городить ДЛЯ функционала - никогда нет и не будет. Абстракции всегда для поддержки и кач-ва.

Возможно. Для обсуждения этого тема и поднята. Насчет HAL оберток - это не утверждение и не необходимость. Просто так легче было пояснить че там происходит. Там вполне можно и регистры ковырнуть. Насчет BoardLeds - хз, у него вероятно дурноватый API, но это ввиду вырожденного примера скорее. С другой стороны, вот если представить более реальную историю с BoardRelays в кол-ве штук так 8 и требованием их динамически назначать в рантайме, оно выглядит вполне себе ничего. Есть класс Motor жрущий релейный выход, есть BoardRelays и есть некий диспетчер, который в зависимости от ран-тайм настроек определенное реле сует в определенный класс, то уже вполне появляется цель, API ток поменять на принимающий энумератор. Хотя это тоже вырожденный пример с другим знаком. Вот эта штука (раннее связывание) меня как раз сильно раздражает в С. Ввиду глобальности методов, в сложном приложении, без CTRL+F по проекту черт ногу сломит понимать где это ЕЩЕ может использоваться. С этим можно бороться только разве что стилем кода в проекте и самодисциплиной жесткой. Компилятор не запретит подключить "my_super_gpio.h" в любом месте и начать там дергать регистры. А меня уж очень прельщает идея перекладывать на компилятор столько, сколько в него влезет. С ООП, если применять позднее связывание - намного легче, т.к. сворачивая\разворачивая вложенности можно отследить где это появилось и куда ушло. (хотя если дать волю рукам, можно тоже дичь понаписать).

Так ну для начала, что значит притянут за уши. Императивщина лучше ООП только когда надо все крохи производительности урвать. Иначе - хз. Но это вкусовщина, да. Если 20 лет долбишь С, возможно уже так приедаеться, что пофигу, я подолбил 3 года и мне на столько не хватало ООП, что я разводил это ООП в С. (и самое ужасное - мне нравилось). BoardLEDs - агрегатор светодиодов железа. Он не только их собирает, он еще отвечает за развязку прикладного слоя от слоя железа и описывает их конфигурацию. TrafficLight - всего лишь пользователь этих светодиодов. Увеличьте число светодиодов до 6 и добавьте 2ой TrafficLight. BoardLEDs останется один. Так же BoardLEDs может выступить Mock объектом в тестах и легко симулировать работу железа для этого. Тут недопонимание в том, что по хорошему конечно класс LED должен быть интерфейсом iLED, а BoardLEDs конструировать какие LED реализующие интерфейс iLED, тут же по факту из-за рудиментарности примера ссылка на объект. Ну и я действительно стараюсь от такого воздерживаться пока не припрет. А это уже оффтоп. По феншую-то ДА. Но это дело как раз уже прикладного ПО. Сигнал - понятие прикладное, BSP предоставляет конкретное железо. Тут защита от того, что дергаться будут именно светодиоды платы, а не какое-нибудь реле. Дублирование ввиду рудиментарности. Вот предположим, что у нас задача сложнее: - 2 независимых трехцветных светофора - 1 двуцветный - 1 светодиод на heartbeat - 2 светодиода на юзер интерфейс И вот уже все светодиоды разнесены по туче прикладных классов. А класс TrafficLight имеет 6 аргументов в конструкторе, т.к. захардкодить их уже нельзя, надо передавать при конструировании.

1. А чего там тяжеловестного? Тут нет наследования, нет дин. аллокации, ну да, будет оверхед от ООП, но он и в вашем примере будет. Меньшее кол-во текста обрубает все те плюсы, о которых я написал выше. Вернее как, попытка их достижения другим известным мне способом вызовет еще большее кол-во текста. Про С и говорить нечего, там для подобного придется городить тот же самый псевдо-ооп с киданием структурками, который скорее всего будет чуть компактнее и чуть быстрее, но в 10 раз менее читаймее. А возможно и не меньше\быстрее даже. Ну жесче только на шаблонах это сделать, там наверно реально приблизиться уже к zero-cost. Но для такой простой задачи как раз - нафига и я не особо сторонник разводить шаблоны без реальной на то нужды. (Насколько мне известно, сейчас многие ультра-про С++ уже считают ошибкой шаблонизацию всего и вся). 2. Простая задача всегда пример. ИРЛ подобное никто не будет покрывать тестами и собирать под несколько платформ. Представьте, что у вас несколько вариантов железа, которые управляют какими релехами, хз ЛИФТА НА АРДУИНО лол. И уже станет понятнее нафига.

Ну смотрите, у вас захардкожены пины в прикладном классе и инициализация их привинчена намертво к некому API. Это не переносимо без изменений прикладных классов, не тестируемо и грязновато. Причем грязновато наверно краеугольный камень, я хз, может тут все столманы, что начисто пишут идеальные модуля и потом не переписывают\вставляют костыли, когда вспоминают, что нужно еще и (некое действие) производить. Я предполагаю, что-то вроде: А что это даст, кроме выполнения минимальных норм всяких клинкодов (ну на самом деле с натяжкой, но никто же не предлагает обмазываться интерфейсами)? Но основное для меня это таки форсирование самодисциплины, когда у тебя железо попросту не сможет без 10 костылей залезть в код приложения. Даже не потому, что это сложно, а потому, что сразу будет ясно, что что-то делается не так.

BSP термин появившийся намного раньше чем сам куб и использующийся далеко не только в нем.