BOB51 писал(а):
Я уже начал подобное разбирательство между четырьмя семействами (MCS51, ATmega (AVR), PIC16 &PIC18) с максимально возможными одинаковыми стартовыми условиями (схемотехника, задача, выполняемая устройством) под ассемблером. Это и есть момент истины как с каким семейством удобнее работать, да и народу вроде доступно изложено.
Ваша тема припоздала лет так... на 10. Именно по тому, что ваша тема так неактуальна, можете сделать вывод и о неактуальности этих семейств.
Всё просто. Новички и ардуинщики не владеют этой темой, а те кто смог бы что-то подсказать ушли на STM и им это просто уже неинтересно.
Тратить своё время, на что, ради чего?
nahimovv писал(а):
..Проблем общения с STM32 как-то не испытываю...
Тогда разрешите спросить, ради этого тему создавать не хочется. Имею такого зверька. Кстати насчет SPL, есть этапы когда совершенно не интересна как работает (оптимизирована) часть кода - инициализация дисплея и все что с ним связано, например - все SPL. Кроме одной мелочи... Мучал я тут недавно интерлив + пдп (с разбором битиков) и захотелось мне картинку вывести на экран, а ля осциллограф. Первая же непонятка была как справится с мерцанием. Вроде контроллер дисплея два лайота имеет, а как сделать swap непонятно. Из даташита видно, что слои смешиваются в блендере, свой коэффициент для каждого. В итоге сделал так - выставляю в 0 один слой, пишу в него, затем в 0xff, затем сразу 0 в другой (коэфф. для блендера). И тут начало происходить странное - после записи в регистр блендера коэффициента, буфер ацп переставал обновляться. Разбор полетов привел к битам overrun статусных регистров АЦП. Они были в единице... Это происходит если запись новых идет раньше считывания результатов старых преобразований. Что общего у настроечного регистра блендера дисплея и АЦП непонятно, кроме единого клокового домена APB2.
Любой, заслуживающий внимания, опыт приобретается себе в убыток...
a5021 писал(а):немедленно реагируйте на все мои возмутительные действия.
Да вы вообще в фаворе! Прям звезда балета!
Ну вы это, не отвлекайтесь, продолжайте нести бред, кармодрочеры вам ещё спасибо скажут!
"Кукушка хвалит петушка, а петушок - кукушку."(С)
Чудесно, у меня такого нет и пока он мне не нужен.
Мучал я тут недавно интерлив + пдп (с разбором битиков) и захотелось мне картинку вывести на экран, а ля осциллограф.
Предлагаете мне угадать глюк с одной буквы?
Да и странно как-то всё это выглядит. Все ратуют за безошибочность и надёжность SPL и тут же начинают сыпать вопросами.
Ведь судя по постам этой темы всё у вас должно работать с полпинка, ан нет! Как же так?
nahimovv писал(а):
Да и странно как-то всё это выглядит. Все ратуют за безошибочность и надёжность SPL и тут же начинают сыпать вопросами.
Ведь судя по постам этой темы всё у вас должно работать с полпинка, ан нет! Как же так?
Вы не поняли, с блендером я работаю без SPL. И проблема решается элементарно, вопрос был конкретно про блендер и его влияние на АЦП к вам как специалисту по STM32
Любой, заслуживающий внимания, опыт приобретается себе в убыток...
Goodefine писал(а):И проблема решается элементарно
Чудесно! Тогда что вы от меня хотите услышать? Что у меня нет вашего блендера-миксера? Что вы что-то не дочитали в референсе?
Или что я проникнусь вашей затеей синус-показалки? Не интересно мне это!
BOB51 писал(а):
Я уже начал подобное разбирательство между четырьмя семействами (MCS51, ATmega (AVR), PIC16 &PIC18) с максимально возможными одинаковыми стартовыми условиями (схемотехника, задача, выполняемая устройством) под ассемблером. Это и есть момент истины как с каким семейством удобнее работать, да и народу вроде доступно изложено.
Ваша тема припоздала лет так... на 10. Именно по тому, что ваша тема так неактуальна, можете сделать вывод и о неактуальности этих семейств.
Всё просто. Новички и ардуинщики не владеют этой темой, а те кто смог бы что-то подсказать ушли на STM и им это просто уже неинтересно.
Тратить своё время, на что, ради чего?
Хотя бы показать преимущество решений под тот же STM, специалистом по которому Вы являетесь - дайте схемку, печатку и аналогичную по функционалу программу на ассемблере (или на Си).
Только устройство в самостоятельном исполнении (не "отладочный модуль"). И чтоб любой пользователь мог собрать, залить прошивку и удостовериться в работоспособности Вашей конструкции и программы (а также сравнить затраты и трудоемкость полученнго образца в сравнении с уже выложенными аналогами). Мне оно тоже ведь вроде как "не интересно" заниматься "виртуальными играми" на симуляторах.
А насчет припоздалости... дак и STM ныне не последнее слово вражьей техники.
Лучше в совершенстве владеть минимумом, чем хватать "по верхам" и вечно "догонять". Но... это мое личное мнение.
Goodefine писал(а):
Все что мне надо, я уже услышал )))
Не важно что услышали вы, важно то что вы сказали! А сказали вы следующее:
1. SPL не решает всех проблем, вам пришлось уйти от SPL чтобы решить свою задачу.
2. SPL не несёт никакой информации о работе периферии, знание референса и работы модулей является первостепенной.
3. SPL даёт заведомо тормозной и избыточный код.
nahimovv писал(а):
1. SPL не решает всех проблем, вам пришлось уйти от SPL чтобы решить свою задачу.
2. SPL не несёт никакой информации о работе периферии, знание референса и работы модулей является первостепенной.
3. SPL даёт заведомо тормозной и избыточный код.
Начнем с того, что я не ратую за использование SPL. Я за принцип разумной необходимости. SPL пусть занимается инициализацией контроллера дисплея, внешней памяти, ножки выставляет в нужные конфиги при старте и т.д. Это выполняется один раз и по.. все равно как оно написано, главное чтоб работало. Дисплей мне не особо интересен, а вот инит ацп, пдп я рассматриваю более пристально, смотря в даташит и в SPL. На ините долбаться ради 0.01% объема? Увольте. А вот работу с памятью и АЦП я делаю руками, например я никогда не доверю SPL читать индекс буфера ПДП после прерывания, а делаю это руками, еще и не ленюсь в ассемблер залезть и посмотреть как легло. Теперь по пунктам:
1. Не поверите, но функция в SPL делает ровно то же самое, что сделал я (запись только одного регистра), только с лишней проверкой и в проблеме она не виновата, ибо проблема возникает в любом случае.
2. Заблуждение. Информация есть, достаточно залезть в ту самую SPL и почитать код. Некоторые места в даташите можно прояснить.
3. Есть два момента - избыточность от параноидального подхода, что пользователь библиотеки даун, либо от не оптимального решения задачи. В некоторых местах от этого тормозной. Но тут все по классике - и мега быстрый оптимальный кусок кода может завесить систему если более высокоуровневый алгоритм неправильно его использует. Надо искать узкие места, а это целая наука и по ней книжки написаны. На тех задачах, для которых эти камни предназначены, первостепенная роль возлагаются на системные подходы и правильную архитектуру проекта
Любой, заслуживающий внимания, опыт приобретается себе в убыток...
Goodefine писал(а):На тех задачах, для которых эти камни предназначены, первостепенная роль возлагаются на системные подходы и правильную архитектуру проекта
Совершенно верно. Только, боюсь, сейчас пойдет следующая волна от хейтеров)))
BOB51 писал(а):А насчет припоздалости... дак и STM ныне не последнее слово вражьей техники.
Припоздалость тут вообще очень размытое понятие. Я с удовольствием использую 74 серию там, где точность конечных состояний является самым важным критерием. Вместо нескольких 74-х чипов можно и маленький МК запилить, даже лучше по площади выйдет, но скорость реакции у него получится хуже, плюс опасность возникновения неопределенностей. А в мире nahimovv-а даже в динамические индикации арм обязателен, ибо всякое другое -- SUXX по определению.
Да, вроде, вам уже ответили, нет ?
Такой юношестско-максималистский подход "я двумя скетчами сделаю то, что вы тут годами делаете" - святая простота.
Часто сижу на робофоруме. Там местные "юноши" на ардуинах пытаются и боевых роботов собирать, и сумоистов, и много еще чО... Да вот только каждый раз тема превращается в очередное "помогите, ОНО не хочет ходить/ездить по прямой!", ну или еще к какой безделице... В конце концов тема тихо сливается, поскольку никто из тамошних спецов просто не хочет вязнуть в этих поделках.
В одном я могу с вами согласиться : поскольку форум здесь - радиоЛЮБИТЕЛЬСКИЙ, то ардуина вроде как в само понятие "любительщины" попадает. Остальное - не ее, и никогда не будет.
Goodefine писал(а):
2. Заблуждение. Информация есть, достаточно залезть в ту самую SPL и почитать код. Некоторые места в даташите можно прояснить.
Бред! SPL писалась по референсу... или наоборот?
SPL не даёт понятия о возможностях модуля МК, это даёт только референс. А применять фукции SPL, не понимая работы самого модуля, просто маразм. Особенно когда присутствует взаимодействие нескольких модулей между собой.
3. Есть два момента - избыточность от параноидального подхода, что пользователь библиотеки даун, либо от не оптимального решения задачи.
Это уже три момента.
На тех задачах, для которых эти камни предназначены, первостепенная роль возлагаются на системные подходы и правильную архитектуру проекта
Правильная архитектура проекта никак не определяет использование SPL, она здесь притянута за уши.
Кстати, да, тема-то называется "кто сам...", а не "XXX vs. YYY", поэтому мой опыт :
Начал "изучение" в 1999г, когда до нас докатилась мода на пиратские радиотрубки Sanyo. В сети ходил только hex-файл, скомпилированный под PIC16F84. Было просто интересно, как же оно работает, поэтому декомпилировал прошивку, распечатал (!) даташит и все заверте...
a5021 писал(а):А в мире nahimovv-а даже в динамические индикации арм обязателен, ибо всякое другое -- SUXX по определению.
Зачотный высер! Зачем мне "SUXX по определению" если я юзаю АРМ и всё хорошо и чудесно? Или мне обязательно нужно для динамической индикации юзать православный "SUXX", патамушта так сказали хомячки-ардуинщики?
a5021 писал(а): Вместо нескольких 74-х чипов можно и маленький МК запилить, даже лучше по площади выйдет, но скорость реакции у него получится хуже, плюс опасность возникновения неопределенностей. А в мире nahimovv-а даже в динамические индикации арм обязателен, ибо всякое другое -- SUXX по определению.
Не скажите, есть вполне достаточное количество применений, где МК вполне к месту, да и современные МК весьма "шустрые" попадаются, даже среди простейших. Чего касательно "неопределенностей" - грамотно составленная программа и продуманная схемка+топология монтажа таких "погрешностей" лишена. Ну а после макетных испытаний и доводки всего вышеуказанного сбои вообще отсутствуют (иначе какой ты любитель?).
Касательно хлесткой задачки по динамические индикации от nahimovv - я ему в "личку" старый проэктик на АВРке скинул... только там выносное табло для пункта обмена (3строки*8позиций+вся обвязка-связь,запись данных все софтовое...) байт на 100-200 больше его кода...
nahimovv писал(а):
1. SPL не решает всех проблем, вам пришлось уйти от SPL чтобы решить свою задачу.
2. SPL не несёт никакой информации о работе периферии, знание референса и работы модулей является первостепенной.
3. SPL даёт заведомо тормозной и избыточный код.
