Eddy_Em (10.11.2023 20:15, просмотров: 130) ответил evgeniy1294 на На линухе есть проблемы с тулчейнами под RISC-V, пока всё не
настолько хорошо, как под ARM. Вообще достаточно
JLINK+openOCD+GDB+GCC+любимый редактор. Будущего у win нет, поэтому
всё равно придется всем переезжать на линух, IAR туда уже вроде
портировали, если вы привыкли к этому компилятору.eddy-em.livejournal.com github.com/eddyem
-
- Моя памятка по openOCD и его интеграции в различные среды
разработки evgeniy1294(1 знак., 11.11.2023 22:29, ссылка)
- Спасибо - RxTx(13.11.2023 12:43)
- Есть Jlink за 250к, а есть отечественный Jet-link flasher pro за
20к с эзернетами и прошивкой по кнопке. Он ещё и обновляется как
оригинал. Есть Black magic опенсорсный из blue pill, но не пробовал
под RISC-V. evgeniy1294(378 знак., 11.11.2023 20:50)
- Никогда про xmake не слышал, в линуксе оно однозначно не
используется. Весь софт собирается исключительно посредством make.
А вот его можно руками писать (для ембеддеда - самое оно) или
генерить автомейком, симейком, ниндзей и т.п. - Eddy_Em(13.11.2023 08:16)
- Ваша эрудиция не эквивалентна таковой у окружающих. И мне
непонятно, что считать "линуксом"? Ядро? Так там с99, а сборочные
make-портянки хоть как-то возможны из-за отсутствия зависимостей у
ядра и терпения Торвальдса, который работает на mac. И то там куча
скриптов сборочные помимо make, в том числе питонячьи. evgeniy1294(856 знак., 13.11.2023 09:24)
- Линукс - это ОС с окружением, естественно. Eddy_Em(630 знак., 13.11.2023 09:52)
- Выражение "нет ничего невозможного" выдаёт не очень опытного
программиста. Люди не хотят делать невозможное, люди хотят
зарабатывать деньги, а потеря двух-трёх рабочих дней для решения
вроде бы тривиальной задачи через cmake не вызывает ничего, кроме
досадного удивления. evgeniy1294(1241 знак., 13.11.2023 10:40)
- Если кому-то потеря двух-трех дней на составление Makefile (бред
само по себе: он пишется за пару-тройку часов), который потом будет
в 100500 проектах использоваться — непозволительная роскошь, то он
- мягко говоря, [censored]! Освоение никому неизвестного
инструмента сборки (или несуществующего - как упомянутый xmake)
займет больше времени. И зачем??? Eddy_Em(593 знак., 13.11.2023 11:31)
- Фраза "...который потом будет в 100500 проектах использоваться"
выдает тепличного человека, не знающего ничего о коммерческих разработках :) Cкpипaч(68 знак., 13.11.2023 12:09)
- Да ладно: всем нам свойственна лень. И я уверен, что ты и сам свои
наработки суешь во все проекты… Не будешь же каждый раз с нуля
что-то делать? Это как минимум нецелесообразно. Eddy_Em(168 знак., 13.11.2023 12:13)
- наброшу. этот ваш make не просто говно, а табулированное. а-ля
whitespace Vit(1 знак., 13.11.2023 12:37, ссылка)
- Да, из-за табов прямо беда! В qtcreator нельзя их редактировать,
т.к. табы весело меняются на пробелы, и приплыли... - Eddy_Em(13.11.2023 13:01)
- За использование табуляции вместо пробелов нужно бить по рукам. - evgeniy1294(13.11.2023 13:04)
- Поздняк метаться: синтаксис мейкфайлов прибили гвоздями! Eddy_Em(185 знак., 13.11.2023 13:07)
- Типы данных уже давно используем. - Cкpипaч(13.11.2023 13:45)
- Четвёртый питон ещё не скоро будет, к тому же так он будет не
совместим с 3-кой. evgeniy1294(101 знак., 13.11.2023 13:41)
- Действительно нужное быстренько перепишут. Все равно там основа - С
или С++, а бидон в этих "библиотеках" лишь как обертка
используется. - Eddy_Em(13.11.2023 13:54)
- Numpy переписывались несколько лет с 2ки на 3ку. - evgeniy1294(13.11.2023 14:04)
- Действительно нужное быстренько перепишут. Все равно там основа - С
или С++, а бидон в этих "библиотеках" лишь как обертка
используется. - Eddy_Em(13.11.2023 13:54)
- Поздняк метаться: синтаксис мейкфайлов прибили гвоздями! Eddy_Em(185 знак., 13.11.2023 13:07)
- За использование табуляции вместо пробелов нужно бить по рукам. - evgeniy1294(13.11.2023 13:04)
- Да, из-за табов прямо беда! В qtcreator нельзя их редактировать,
т.к. табы весело меняются на пробелы, и приплыли... - Eddy_Em(13.11.2023 13:01)
- А причем тут лень? На рынке ПРОСТО НЕТ "100500 проектов". Более
того, пока вы всерьёз сделаете хотя бы пять, потребности заказчиков
изменятся и все ваши наработки придется срочно переписывать. Cкpипaч(641 знак., 13.11.2023 12:20 - 12:27)
- Зачем же наработки переписывать? Eddy_Em(638 знак., 13.11.2023 12:20)
- Чтобы бекпорт сделать. - Cкpипaч(13.11.2023 12:21)
- Зачем же наработки переписывать? Eddy_Em(638 знак., 13.11.2023 12:20)
- наброшу. этот ваш make не просто говно, а табулированное. а-ля
whitespace Vit(1 знак., 13.11.2023 12:37, ссылка)
- Да ладно: всем нам свойственна лень. И я уверен, что ты и сам свои
наработки суешь во все проекты… Не будешь же каждый раз с нуля
что-то делать? Это как минимум нецелесообразно. Eddy_Em(168 знак., 13.11.2023 12:13)
- Фраза "...который потом будет в 100500 проектах использоваться"
выдает тепличного человека, не знающего ничего о коммерческих разработках :) Cкpипaч(68 знак., 13.11.2023 12:09)
- Если кому-то потеря двух-трех дней на составление Makefile (бред
само по себе: он пишется за пару-тройку часов), который потом будет
в 100500 проектах использоваться — непозволительная роскошь, то он
- мягко говоря, [censored]! Освоение никому неизвестного
инструмента сборки (или несуществующего - как упомянутый xmake)
займет больше времени. И зачем??? Eddy_Em(593 знак., 13.11.2023 11:31)
- Выражение "нет ничего невозможного" выдаёт не очень опытного
программиста. Люди не хотят делать невозможное, люди хотят
зарабатывать деньги, а потеря двух-трёх рабочих дней для решения
вроде бы тривиальной задачи через cmake не вызывает ничего, кроме
досадного удивления. evgeniy1294(1241 знак., 13.11.2023 10:40)
- Линукс - это ОС с окружением, естественно. Eddy_Em(630 знак., 13.11.2023 09:52)
- Ваша эрудиция не эквивалентна таковой у окружающих. И мне
непонятно, что считать "линуксом"? Ядро? Так там с99, а сборочные
make-портянки хоть как-то возможны из-за отсутствия зависимостей у
ядра и терпения Торвальдса, который работает на mac. И то там куча
скриптов сборочные помимо make, в том числе питонячьи. evgeniy1294(856 знак., 13.11.2023 09:24)
- Можно линку на QtCreator? Хочу сравнить в реальной работе над
реальным проектом вижуал студию, вижуал код и криэйтор. - ig_z(13.11.2023 04:10)
- Прямо в этой теме выкладывал, продублирую. evgeniy1294(1 знак., 13.11.2023 09:39, ссылка)
- А почему такой вердикт о cmake? Я им активно не пользовался пока,
прослушал на юдеми курс, у меня сложилось впечатление, что связка
cmake, conan | vcpackage вполне себе современная молодежная
свистоперделка. - ig_z(13.11.2023 04:05)
- По пользуешься, узнаешь. Половина базового функционала или не
описана, или работает не так как описано, или вообще не работает.
Птичий язык, работает криво, сам собрать ничего не может и
генерирует make-портянку. evgeniy1294(336 знак., 13.11.2023 09:32 - 09:37)
- А главное - непонятно нафига. Мейк же примитивен, он только
разрешает зависимости да смотрит время изменения файлов. А что ещё
нужно то? Если для сборки этого не хватает - всегда можно дописать
скрипты или вспомогательные утилиты на любом удобном языке. Причём
собирать их можно тем же мейком прямо в процессе. - =AlexD=(13.11.2023 09:38)
- Допиши и удивить, сборочные утилиты бывают сложнее проекта. Make
умер, ещё в 90х не справлялся с задачей. evgeniy1294(51 знак., 13.11.2023 09:41)
- Кернел Линуха собирается обычным мейком и не жужжит. Некоторые
вспомогательные утилиты собираются в процессе прямо из сишечки. - =AlexD=(13.11.2023 10:34)
- >>> SciFi(1 знак., 13.11.2023 10:36, ссылка)
- И? Проблема большинства языков в том что они плохо в исполнение до
компиляции умеют. А Сишечка и вовсе не умеет. И это никакими
костылями не исправить. make по крайней мере прост и есть всегда.
Все остальные костыли - не читаемы в принципе. Поэтому без разницы
чем подпереть. - =AlexD=(13.11.2023 10:43)
- Что тут нечитаемого? Тоже самое придется указать и в make, ни на
строчку короче не будет: evgeniy1294(3050 знак., 13.11.2023 10:52)
- Когда я говорю про нечитаемось, я говорю про исполнение неких программ в процессе сборки. Которые должны что-то создать исходя из контекста среды компиляции. И эти программы будут по любому нечитаемы, потому что требуют к себе понимание исходников самой программы. Что ей там нужно для сборки. Честнее тупо создать некую build_utilites и собрать/вызвать её из make, но не тянуть весь этот трешовый код в некий птичий язык сборки проекта. - =AlexD=(13.11.2023 11:01)
- Всё тоже самое делается в make , только короче. Спрашивается,
нафига ещё одна дублирующая сучность? Изучать ещё одну утилиту
что-бы что? Может потратить это время на углубление понимания make? - =AlexD=(13.11.2023 10:56)
- На make оно может быть короче только при условии предварительного
задания переменных окружения. Вот тебе ссылка, перепиши на make: evgeniy1294(1 знак., 13.11.2023 12:30, ссылка)
- Переменные среды - это как просто переменные, но которые можно
передать в BASH, что очень удобно во многих случаях, в отличии от
ваше б-гмерзской луа. - =AlexD=(13.11.2023 13:10)
- Нет, это не просто переменные. Это платформозависимая часть системы
сборки, которую мне придётся делать самостоятельно, если мой
дистрибутив отличается или я хочу использовать другой тулчейн для
сборки. Особенно плохо с этим на Windows, где для сборки софта под
платформу приходится делать целую отдельную песочницу. И никакую
сборочную утилиту тут не сделать. evgeniy1294(235 знак., 13.11.2023 13:34)
- Никто не заставляет использовать тебя именно системные переменные и
даже пути. Всё можно описать вручную. В общем, надуманные
трудности. В кроссплатформенности свои проблемы, более существенные
чем утилита сборки проекта. - =AlexD=(13.11.2023 14:25)
- Изначально вы мне пытались показать, что на make "будет короче", я
указал, что короче не будет и объяснил почему - вам нужно
предоставить одну и ту же информацию одной и той же программе
(gcc). И нет, это не надуманные трудности, приводящие в конце
концов к виртуальной машине/контейнеру, в которой строго
определённое окружение для разработки софта, не меняющееся годами в
целях длительной поддержки продукта. И это не плохой вариант,
бизнесу плевать как сделано, пока это evgeniy1294(28 знак., 13.11.2023 15:52)
- Короче - это меньше буков, а не строчек. А так да, всё то же самое
только другим йезыком, ну и нахуа? Вот вы уже и оправдываетесь, что
оно "то же работает". Ну собственно я и не сомневался. Одно и то же
можно сделать 100500 разными способами. Никто вам не запрещает
написать сборочный скрипт на Питоне, к примеру. И у этого будут
определённые свои достоинства, даже и поболее вашего xmake. - =AlexD=(13.11.2023 15:59)
- Вы плохо себе представляете, что такое сложный продукт и его
длительная поддержка, иначе про make даже не думали бы. А смысл в
экономии времени и удобстве, причём очень серьёзном. Когда у вас
будет комплекс с десятком сложных устройств, в каждом из которых на
линухе крутится своё ПО, собранное с кучей зависимостей начиная от
cuda и заканчивая libre-office-dev, а поддерживать это нужно 10 лет
- вы взвоете. - evgeniy1294(13.11.2023 16:17)
- Видел такое. Собирается строго в среде конкретного дистрибутива Линуха с точностью до второй цифры. Куча скриптов в которых чего только нет. Куча make, куча питоновских скриптов. xmake - нет, не видел. Проще было бы распространять образ виртуального диска либо Докер контейнера. - =AlexD=(14.11.2023 10:25)
- Вы плохо себе представляете, что такое сложный продукт и его
длительная поддержка, иначе про make даже не думали бы. А смысл в
экономии времени и удобстве, причём очень серьёзном. Когда у вас
будет комплекс с десятком сложных устройств, в каждом из которых на
линухе крутится своё ПО, собранное с кучей зависимостей начиная от
cuda и заканчивая libre-office-dev, а поддерживать это нужно 10 лет
- вы взвоете. - evgeniy1294(13.11.2023 16:17)
- Короче - это меньше буков, а не строчек. А так да, всё то же самое
только другим йезыком, ну и нахуа? Вот вы уже и оправдываетесь, что
оно "то же работает". Ну собственно я и не сомневался. Одно и то же
можно сделать 100500 разными способами. Никто вам не запрещает
написать сборочный скрипт на Питоне, к примеру. И у этого будут
определённые свои достоинства, даже и поболее вашего xmake. - =AlexD=(13.11.2023 15:59)
- Изначально вы мне пытались показать, что на make "будет короче", я
указал, что короче не будет и объяснил почему - вам нужно
предоставить одну и ту же информацию одной и той же программе
(gcc). И нет, это не надуманные трудности, приводящие в конце
концов к виртуальной машине/контейнеру, в которой строго
определённое окружение для разработки софта, не меняющееся годами в
целях длительной поддержки продукта. И это не плохой вариант,
бизнесу плевать как сделано, пока это evgeniy1294(28 знак., 13.11.2023 15:52)
- Никто не заставляет использовать тебя именно системные переменные и
даже пути. Всё можно описать вручную. В общем, надуманные
трудности. В кроссплатформенности свои проблемы, более существенные
чем утилита сборки проекта. - =AlexD=(13.11.2023 14:25)
- Нет, это не просто переменные. Это платформозависимая часть системы
сборки, которую мне придётся делать самостоятельно, если мой
дистрибутив отличается или я хочу использовать другой тулчейн для
сборки. Особенно плохо с этим на Windows, где для сборки софта под
платформу приходится делать целую отдельную песочницу. И никакую
сборочную утилиту тут не сделать. evgeniy1294(235 знак., 13.11.2023 13:34)
- Переменные среды - это как просто переменные, но которые можно
передать в BASH, что очень удобно во многих случаях, в отличии от
ваше б-гмерзской луа. - =AlexD=(13.11.2023 13:10)
- Логика китайцев вообще не поддается никакой логике ☺ Eddy_Em(313 знак., 13.11.2023 11:34)
- Ну я осилил cmake, и что? Да, это отраслевой стандарт, поэтому все мои проекты сделаны на нём ради преемственности кода, но не более. Он требует гораздо больше усилий, как следствие денег. В следующем году напишу плагин для QtCreator и буду дублировать сборочные скрипты на xmake, буду популяризировать систему и привлекать людей. В первую очередь нужна инфраструктура. evgeniy1294(172 знак., 13.11.2023 12:40)
- На make оно может быть короче только при условии предварительного
задания переменных окружения. Вот тебе ссылка, перепиши на make: evgeniy1294(1 знак., 13.11.2023 12:30, ссылка)
- Что тут нечитаемого? Тоже самое придется указать и в make, ни на
строчку короче не будет: evgeniy1294(3050 знак., 13.11.2023 10:52)
- И? Проблема большинства языков в том что они плохо в исполнение до
компиляции умеют. А Сишечка и вовсе не умеет. И это никакими
костылями не исправить. make по крайней мере прост и есть всегда.
Все остальные костыли - не читаемы в принципе. Поэтому без разницы
чем подпереть. - =AlexD=(13.11.2023 10:43)
- >>> SciFi(1 знак., 13.11.2023 10:36, ссылка)
- У нас тут МК и мигающие лампочки. Достижения 90-х вполне
справляются с задачей. Некоторые ещё и до сей не дошли, застряли в
60-х :-) - SciFi(13.11.2023 09:45)
- Увы, нет. У нас уже давно ТCP, файфай, тачскрины, веб-интерфейсы и
даже кое-где SQL. Cкpипaч(33 знак., 13.11.2023 09:59)
- У меня есть TCP и вебморды. Мейк легко справляется. Впрочем, я не настаиваю. - SciFi(13.11.2023 10:02)
- Увы, нет. У нас уже давно ТCP, файфай, тачскрины, веб-интерфейсы и
даже кое-где SQL. Cкpипaч(33 знак., 13.11.2023 09:59)
- +1. При этом в других языках, в которых модульность не является побочным эффектом макроподстановки, уже в начале 90х собирались проекты любого уровня сложности. - Cкpипaч(13.11.2023 09:43)
- Кернел Линуха собирается обычным мейком и не жужжит. Некоторые
вспомогательные утилиты собираются в процессе прямо из сишечки. - =AlexD=(13.11.2023 10:34)
- Допиши и удивить, сборочные утилиты бывают сложнее проекта. Make
умер, ещё в 90х не справлялся с задачей. evgeniy1294(51 знак., 13.11.2023 09:41)
- Что касается пакетный менеджеров, то есть только один - системный. И вам всё равно придётся писать свой пакет под выбранный дистрибутив. evgeniy1294(143 знак., 13.11.2023 09:35)
- А главное - непонятно нафига. Мейк же примитивен, он только
разрешает зависимости да смотрит время изменения файлов. А что ещё
нужно то? Если для сборки этого не хватает - всегда можно дописать
скрипты или вспомогательные утилиты на любом удобном языке. Причём
собирать их можно тем же мейком прямо в процессе. - =AlexD=(13.11.2023 09:38)
- По пользуешься, узнаешь. Половина базового функционала или не
описана, или работает не так как описано, или вообще не работает.
Птичий язык, работает криво, сам собрать ничего не может и
генерирует make-портянку. evgeniy1294(336 знак., 13.11.2023 09:32 - 09:37)
- С Jet Link flasher pro точно шьешь RISC-V? RxTx(88 знак., 11.11.2023 21:56, ссылка, ссылка)
- Да неоткуда ей там взяться. Это он так, для кругозора написал - proglyk(11.11.2023 22:03)
- Неделю назад мой шил. Даже не поленился и картинку сделал, дальше
сам разберешься: evgeniy1294(1 знак., 11.11.2023 22:45, картинка)
- OpenOCD? Ага, бум знать. - RxTx(11.11.2023 23:27)
- Причём штатный из ванильной ветки. Не нужно качать сборку от вендора. - evgeniy1294(11.11.2023 23:28)
- Ладно, поверил. А если взять, например, отечественный CloudBear
BR-351? У них на сайте о Флешере не упоминается proglyk(1 знак., 11.11.2023 23:13, ссылка)
- На сайте указано: "Сторонние средства разработки... SEGGER Embedded
Studio для RISC-V/ Совместимые JTAG отладчики... Segger J-Link" ".
То есть скорее всего работает, но заморачиваться смысла нет.
Производство было на TSMC, если не переехали в Китай, то с
доступностью будет жопа, пара сотен камней в год. - evgeniy1294(11.11.2023 23:19)
- А, например, в списке поддерживаемого жилеза J-Link V11 не вижу
GigaDevicов. Почему тогда работает?) proglyk(1 знак., 11.11.2023 23:20, ссылка)
- Индусы тут не причем. Потому что это ARM. И потому что JLink считывая ID продолжает работать. Чем отличается от ST-Link'а. - RxTx(11.11.2023 23:32)
- Потому что ответственный за вики индус забил на работу. - evgeniy1294(11.11.2023 23:22)
- Спасибо за инфо.) - proglyk(11.11.2023 23:23)
- Нужно на сайте смотреть, там более ответственный индус (возможно из
высшей касты) evgeniy1294(1 знак., 11.11.2023 23:26, ссылка)
- Облачные медведи там тоже есть, но всего два камня. Так как IP-ядро
TAP у них скорее всего одинаковое, то в целом должны все работать. - evgeniy1294(11.11.2023 23:30)
- Да, скорее всего. Их две модели только потому что отличаются разрядностью 32 и 64 бита - proglyk(11.11.2023 23:39)
- Облачные медведи там тоже есть, но всего два камня. Так как IP-ядро
TAP у них скорее всего одинаковое, то в целом должны все работать. - evgeniy1294(11.11.2023 23:30)
- Нужно на сайте смотреть, там более ответственный индус (возможно из
высшей касты) evgeniy1294(1 знак., 11.11.2023 23:26, ссылка)
- Спасибо за инфо.) - proglyk(11.11.2023 23:23)
- А, например, в списке поддерживаемого жилеза J-Link V11 не вижу
GigaDevicов. Почему тогда работает?) proglyk(1 знак., 11.11.2023 23:20, ссылка)
- На сайте указано: "Сторонние средства разработки... SEGGER Embedded
Studio для RISC-V/ Совместимые JTAG отладчики... Segger J-Link" ".
То есть скорее всего работает, но заморачиваться смысла нет.
Производство было на TSMC, если не переехали в Китай, то с
доступностью будет жопа, пара сотен камней в год. - evgeniy1294(11.11.2023 23:19)
- OpenOCD? Ага, бум знать. - RxTx(11.11.2023 23:27)
- Неделю назад мой шил. Даже не поленился и картинку сделал, дальше
сам разберешься: evgeniy1294(1 знак., 11.11.2023 22:45, картинка)
- Да неоткуда ей там взяться. Это он так, для кругозора написал - proglyk(11.11.2023 22:03)
- Никогда про xmake не слышал, в линуксе оно однозначно не
используется. Весь софт собирается исключительно посредством make.
А вот его можно руками писать (для ембеддеда - самое оно) или
генерить автомейком, симейком, ниндзей и т.п. - Eddy_Em(13.11.2023 08:16)
- Если бы всё это ещё и подкреплялось успешными проектами. А то ведь
v003 не побеждён. И это как раз из-за неправильного инструментария
- тыкаться во тьме вместо нормальной отладки... - VladislavS.(11.11.2023 01:10)
- Если брать готовый (очень жирный и написанный под С++, что мне
нафиг не надо) линкер-скрипт и стартап на ассемблере (что меня
вообще выворачивает наизнанку), то вполне можно компилять и
собирать. Сам пробовал - получилось со своим Makefile'ом. Но
нормально кастомизировать - время нужно. В принципе, под те же
STM32 у меня нормальный базис года три (если не больше)
формировался! На один только USB я полгода потратил (понятно, не
полноценного времени, а наплывами, сидя по Eddy_Em(802 знак., 11.11.2023 01:26)
- "А на инструментарий плевать"- это just for fun only. аналогичным
стайлом, кстати, выделяется адурино - там тупо нет средств отладки,
кроме printf (во 2-й версии что-то нагадили, но оно выглядит
грустно) - Vit(11.11.2023 22:19)
- Что там в абдурине отлаживать-то, периферии почти ноль, все
ногодрыгом реализуется? Да и сами абдуринщики терминала как огня
боятся, куда уж им до отладки! - Eddy_Em(12.11.2023 10:52)
- периферии почти ноль это у AVR-а? Бггг. - enc(12.11.2023 16:22)
- Да даже STM8 рвет 8-битный АВР! А 32-битные аврки изначально
убогими были. - Eddy_Em(13.11.2023 08:18)
- да-да... Одноаккумуляторное поделие рвёт 32 аккумулятора.
3-стадийным конвейером. Как Тузик
грелкусковородку. Не, если АВР будет на 8 против 20-30МГц СТМки, то можэт быть. И то... - mse homjak(13.11.2023 20:22)- Да при чем здесь это? Сколько абдуринщиков пользуются аппаратными
возможностями тех же "мег"? Они даже уарт софтовый используют, не
ведая об аппаратных!!! - Eddy_Em(13.11.2023 20:29)
- А при чом тут абдуринщики? Речь про АВР-СТМ8. По вычислительной
моще, СТМ влёхкую отсосёт у классического АВРа. По частоте, да, ужэ
АВР отсосёт. Так его не абгрейтили ужэ лет 10-15. Ну, развечто
Хмеги. Но они каг-то мимо меня прошли. - mse homjak(13.11.2023 20:41)
- Что мы называем "классическим АВР"? Хрень, у которой даже четырех
таймеров нет? - Eddy_Em(13.11.2023 20:55)
- Мне хватает одного-двух, приборы в Госреестре, "что ещо нужно чтобы встретить старость?" - mse homjak(13.11.2023 23:46)
- Ну у вас-то точно все задачи требуют четырех аппаратных
таймеров, программный делитель частоты - вааще никак :) - Cкpипaч(13.11.2023 21:03)
- Те, что не требуют, хотят CAN или USB. А в некоторых случаях мне и 7 таймеров мало... - Eddy_Em(13.11.2023 21:03)
- Что мы называем "классическим АВР"? Хрень, у которой даже четырех
таймеров нет? - Eddy_Em(13.11.2023 20:55)
- А при чом тут абдуринщики? Речь про АВР-СТМ8. По вычислительной
моще, СТМ влёхкую отсосёт у классического АВРа. По частоте, да, ужэ
АВР отсосёт. Так его не абгрейтили ужэ лет 10-15. Ну, развечто
Хмеги. Но они каг-то мимо меня прошли. - mse homjak(13.11.2023 20:41)
- Да при чем здесь это? Сколько абдуринщиков пользуются аппаратными
возможностями тех же "мег"? Они даже уарт софтовый используют, не
ведая об аппаратных!!! - Eddy_Em(13.11.2023 20:29)
- 8-битные АВР это, в том числе, ATXmega256A3BU, ATXmega128A1U,
AT94K40, M3000, YU006. На этом ядре не только ATtiny и AT90S делали - AlexG(13.11.2023 17:49)
- Ну так я могу и "жирные" STM8 вспомнить… - Eddy_Em(13.11.2023 17:56)
- да-да... Одноаккумуляторное поделие рвёт 32 аккумулятора.
3-стадийным конвейером. Как Тузик
- Да даже STM8 рвет 8-битный АВР! А 32-битные аврки изначально
убогими были. - Eddy_Em(13.11.2023 08:18)
- периферии почти ноль это у AVR-а? Бггг. - enc(12.11.2023 16:22)
- Что там в абдурине отлаживать-то, периферии почти ноль, все
ногодрыгом реализуется? Да и сами абдуринщики терминала как огня
боятся, куда уж им до отладки! - Eddy_Em(12.11.2023 10:52)
- Эмбеддед правильнее отлаживать как синтетических порт. Логика
прошивки пишется как библиотека, а платформозависимые функции
эмулируются на пк. Когда все начинает работать, просто запихивается
в МК, работает обычно с первого раза, если драйверы для периферии
нормальные. - evgeniy1294(11.11.2023 20:57)
- Эмбеддед он очень разный. У меня 75% кода и есть драйвера, отладить
которые на синтетическом порте неособо возможно. Бизнес-логика -
тривиальна. - Cкpипaч(11.11.2023 21:23)
- У меня наоборот, сложная логика и большое количество примитивной периферии. - evgeniy1294(11.11.2023 21:25)
- Эмбеддед он очень разный. У меня 75% кода и есть драйвера, отладить
которые на синтетическом порте неособо возможно. Бизнес-логика -
тривиальна. - Cкpипaч(11.11.2023 21:23)
- "А на инструментарий плевать"- это just for fun only. аналогичным
стайлом, кстати, выделяется адурино - там тупо нет средств отладки,
кроме printf (во 2-й версии что-то нагадили, но оно выглядит
грустно) - Vit(11.11.2023 22:19)
- Если брать готовый (очень жирный и написанный под С++, что мне
нафиг не надо) линкер-скрипт и стартап на ассемблере (что меня
вообще выворачивает наизнанку), то вполне можно компилять и
собирать. Сам пробовал - получилось со своим Makefile'ом. Но
нормально кастомизировать - время нужно. В принципе, под те же
STM32 у меня нормальный базис года три (если не больше)
формировался! На один только USB я полгода потратил (понятно, не
полноценного времени, а наплывами, сидя по Eddy_Em(802 знак., 11.11.2023 01:26)
- Конечно, jlink за 250 тыс.руб в ЧипиДип, а j-trace так еще дороже.
Ну тут, наверно, имеется ввиду китайский последних версий. Мой
9.6-ый, очевидно, для этого не годится. Все это надо изучать, а
времени мало. Тут еще момент - изначально в EWRISCV полноценно
поддерживается I-Jet (новый под V) и никаких продуктов Segger - еще
одна палка в колёса. Правда, есть функция внешней библиотеки
отладчика, но опять же надо разбираться. :( - proglyk(10.11.2023 22:57)
- Ну, удачи! Eddy_Em(544 знак., 11.11.2023 00:46)
- Моя памятка по openOCD и его интеграции в различные среды
разработки evgeniy1294(1 знак., 11.11.2023 22:29, ссылка)
