[Reyden]

Задумал сборку настольного светильника, думаю этот драйвер хорошо подойдет за счет RGB подсветки и плавной регулировки. Из минусов немного сложное для обычного обывателя управление. Мощность светодиодов будет ограничена 2-3W, примерно 0.3А 12.3V. Хотел посоветоваться по компонентам, не так давно mag_vitaliy собирал маяк примерной той же мощности, я уже если честно подзабыл расчеты. Драйвер будет работать с нагрузкой 12V с текущей прошивкой?
https://forum.fonarevka.ru/...

Все по ГОСТу?
Rsense = 0.05Ohm/0.3А=166mOhm
Iout = 0.22A
Istrob = 0.3A
Linductor = 3.3uH*6A/0.3A = 66uH
Cin = 100uF
Cout = 4uF
Schottky хватит одного DB2W31900L c запасом If = 3A, Coutput capacitance = 70pF (10V)
FET CSD17303Q5 может сюда что то по бюджетней? Coutput capacitance = 1870pF
Осталось рассчитать snubber, не знаю нужен ли он для таких токов.
Coutput capacitance = 70pf + 1870pF = 1940pF
Csnub = 8nF
Rsnub = 108mOhm

Повезло, откапал свои старые записи, без них был бы полный мрак.
https://docs.google.com/spr...

[Reyden]

INFERION, будет драйвер работать с такими компонентами на 12V или я где то накосячил? Больше всего интересует подбор индуктора.

[INFERION]

Reyden, ты думаешь я помню?) Это нужно сидеть всё и вспоминать, код ковырять. Там же все переменные не в СИшном формате, а в попугаях и с ограничениями. А я давно на плавающую точку и физ. величины перешел, и тот целочисленный кошмар забыть хочу... Были же тут где-то посты с подробным описанием пересчёта компонентов?

В первом посте есть ключевые подкапотные формулы, и там есть sqrt2TL переменная. Я так понимаю, всё нужно подобрать таким образом, чтоб с точки зрения программы ничего не поменялось. Увеличили шунт в 2 раза - ток упал вдвое, реактивный ток на том же заполнении так же должен упасть вдвое, а резонансная частоте LC фильтра - остаться на прежнем уровне. При этом от номиналов зависимости могут быть вполне себе sqrt и/или квадратичные...

Что касается 12V - насколько я помню, защита там рассчитана на 3S, и на 4S она уже может ложно срабатывать. Я эту программу считаю морально устаревшей. Она и в Метеоре то устарела, хотя там было её дальнейшее развитие и много чего переработано.

[Reyden]

 Сообщение от INFERION :

ты думаешь я помню?)

Ахах, у меня по началу была такая же реакция

 Сообщение от INFERION :

Что касается 12V - насколько я помню, защита там рассчитана на 3S, и на 4S она уже может ложно срабатывать. Я эту программу считаю морально устаревшей. Она и в Метеоре то устарела, хотя там было её дальнейшее развитие и много чего переработано.

Формулы для расчетов у меня остались, советуюсь на всякий, чтобы не собрать непонятно что. Подумаю еще на счет драйвера Tamagotchi, тоже довольно устаревший, но будет легче в плане схемотехники. Тот же Caerus для 6V мне подойдет, раз Indigo не потянет 12V. Indigo будет нормально работать с 6V нагрузкой?

Вообще надо учиться пилить что то свое. Прикупил Arduino Nano 33 BLE Sense, хочу собрать драйвер, а в дальнейшем связать через bluetooth со смартфоном. На борту неплохой мк nRF52840 с множеством датчиков на Cortex-M4 32-bit. Создам тему, было бы неплохо набраться опыта в сфере построении преобразователей на микроконтроллерах.
https://store.arduino.cc/ar...
https://content.arduino.cc/...

[INFERION]

 Сообщение от Reyden :

Indigo будет нормально работать с 6V нагрузкой?

КПД ниже из-за потерь в выпрямителе и у повышалок с 6V общая проблема - утечки в светодиоды заметные (в прямом смысле). Я бы целился на 4S.

 Сообщение от Reyden :

хочу собрать драйвер... На борту неплохой мк nRF52840

У меня сомнения на счёт "не плохой" и на счёт "драйвер на нём". Что-то простое, для управления светом в комнате, или вентилятором вытяжки - ардуины тянут. И дело не только в железе. Я вот посматривал на ESP32 - тоже хвалят, а на деле "очень глючная штука, пригодная только если будешь использовать её HAL с микропитоном и делать что-то совсем стандартное, к чему есть готовые либы". Ладно там STM32, и то проблем куча с энергосбережением, эмуляцией EEPROM, но хотя бы можно пришить нормальный CMSIS, взять нормальную документацию, и общаться с камнем на достаточно низком уровне, а периферия и правда заточена под микроконтроллерное применение в силовухе.

 Сообщение от Reyden :

в сфере построении преобразователей на микроконтроллерах

С ОС и микропитоном, ага ). Загружающиеся 4 секунды (или сколько там ядро линукса грузится?) и требующие мегабайты ОЗУ и флеша. Я утрирую, конечно, но это не далеко от истины. Сейчас такие тренды - все начинающие начинают сразу с верхнего уровня с лютым уровнем абстрагирования (Arduino тому в пример), и процесс компиляции включает сборку ОС и занимает минуты-десятки минут. Потом это всё жрёт прорву памяти и... мигает светодиодиком!

Начинал бы лучше с AVR - простой уютный камень, которого хватает и для преобразователей, и для понимания проблем в их программных реализациях. Си он не потянет. Можно начать с него, но при понимании проблем - всё равно захочется или тактов досыпать, или оптимизировать на ассемблере. Досыпать - это STM32, но взамен резкий скачок уровня сложности и количества проблем.

P.S.

[Reyden]

 Сообщение от INFERION :

P.S.

Интересно что там, но текста не видно

 Сообщение от INFERION :

У меня сомнения на счёт "не плохой" и на счёт "драйвер на нём". Что-то простое, для управления светом в комнате, или вентилятором вытяжки - ардуины тянут.

Топовые версии Arduino тянут модели Tensor Flow lite, это никак не уровень контроллера для вытяжки. В чем заключаются изъяны micro Python при написании кода для работы преобразователей?

Разные модели Arduino могут работать на C++ так и micro Python. Здесь идет разделение на две категории языков: интерпретированные и скомпилированные. Требования к размеру RAM у micro Python больше т.к интерпретация происходит непосредственно на мк, необходимо место для хранения библиотек. С++ более низкоуровневый язык, чем micro Python. При наличии библиотек и подходящем железе (nRF52) я не вижу особых проблем в использовании micro Python. Как всегда все кроется в деталях. Вопрос в том как это отразится на быстродействии/энергопотреблении особенно когда речь идет о проектах в реальном времени. Если все так плохо с задержкой, всегда можно написать на С++.

 Сообщение от INFERION :

Начинал бы лучше с AVR - простой уютный камень, которого хватает и для преобразователей, и для понимания проблем в их программных реализациях.

Многие критикуют AVR, ей уже лет и лет, в том время как ARM архитектура становятся популярнее. Думал что более новая платформа будет удобнее для изучения и даст реализовать больше функционала в том числе и передачу по bluetooth.

 Сообщение от INFERION :

Я вот посматривал на ESP32

Находил его, эта серия мк популярна в первую очередь из-за сверх низкой цены и наличием беспроводных интерфейсов. Но имеет мало что общего с nRF52840. Тот же STM32 есть на ARM Cortex M4.

[INFERION]

 Сообщение от Reyden :

С++ более низкоуровневый язык, чем micro Python.

При этом пишут всё равно на C и ASM.

 Сообщение от Reyden :

Если все так плохо с задержкой, всегда можно написать на С++.

Который тоже слишком высокоуровневый для таких задач? Хотя, иногда часть его инструментов - используют в С коде, да. С осторожностью и пониманием. А иногда - даже RTOS поднимают, но это не от хорошей жизни, а иногда и от неспособности придумать что по лучше (например, поднять аппаратный планировщик на NVIC).

Я не буду что-то доказывать, просто думаю, что с таким настроем лучше на программные преобразователи пока забить и делать полуаппаратные. Не такие критичные к ошибкам и тормозам.

 Сообщение от Reyden :

Многие критикуют AVR, ей уже лет и лет

Что не делает эти чипы хуже, и на рынке они до сих пор есть и в ряде задач их до сих пор подвинуть не могут. И не подвинут, т.к. все развивают ARM - МК не настолько красивые в этих задачах. Я как бы работаю и с AVR и с ARM. Совать в драйверы ARM - это только если они достаточно жирные, дорогие и крупные, чтоб в них можно было наогородить необходимых ARM костылей, таких как преобразователи на питание МК (TPS63031 обычно), придумать что-то с хранением данных между выключениями (отдельные EEPROM или костыльная проблемная эмуляция в Flash), обвес с усилителями шунтов (в сами МК не завозят даже инструментальные усилители) и мириться с невозможностью так легко и просто уходить в сон и выходить из него. И не нужно говорить что просто подходящий чип нужно поискать, в котором всё есть - это не AVR... Такую тяжелую схемотехнику можно оправдать, если ты строишь бортовой комп с кучей жирного функционала вроде Wi-Fi, дисплея с тачем и т.п., и/или если там используются жирные датчики вроде дельта-сигма модуляторов, требующих аппаратного интерфейса и фильтра в МК, тот же SAI для многокальных аудиокодеков и т.д. Это всё не про фонарики на парочку каналов. И не про программные преобразователи. Как минимум - это уже контроллеры двигателей, т.н. "частотники" и т.п., где действительно есть что считать и молотить, а мелкие неудобства не ощутимы на фоне остального огорода компонентов и стоимости.

 Сообщение от Reyden :

в том время как ARM архитектура становятся популярнее.

В большинстве попсовых задач она удобнее. Правда, если хочешь что-то серьёзное сделать - копать придётся очень глубоко, и это не проще изучения AVR, который уже даст базовые представления о работе всей этой подкапотки. А ещё будет потом сравнительная база. Ну а пилить ардуиноподобные проекты на готовых либах - это и без тебя есть кому делать. Если тебе хочется именно этого - тогда программные преобразователи просто не для тебя (как и для остального большинства). Прозвучало не очень, поэтому сразу уточню - это большинство лучше и быстрее решает более высокоуровневые задачи, чем, к примеру, я. Например, сайтец там запилить, картинку сгенерировать, красивую приложеньку на андроид состряпать. При этом они с ужасом смотрят на написание драйвера, да ещё и который что-то взорвать может! Реалтаймовость? Такие ребята часто не знают даже что такое мультимедийный таймер в винде, а вопрос "как вывести с компа в UART поток пакетами раз в 5мс" их ставит в тупик. Зато они легко юзают систему Git, мгновенно понимают где найти и как прикрутить "вон ту библиотеку", быстро осваивают новые среды. Разные области - разные навыки. И МК для них сейчас стали доступнее, со всеми вытекающими, о которых я написал сообщением выше...

 Сообщение от Reyden :

Думал что более новая платформа будет удобнее для изучения и даст реализовать больше функционала в том числе и передачу по bluetooth.

Современный инжектор удобнее для изучения за карбюратор, ага... Более новая платформа для изучения то как раз более сложная, если мы говорим об изучении платформы, а не инструментов к ней, призванных упростить жизнь программисту (тот же HAL и Cube в STM32, к примеру) в ущерб функционалу и качеству кода, разумеется. Более сложная, но и более интересная. Тут уже не проблема прикрутить красивую свистелку вроде дисплея, подцепить аудиокодек и MicroSD, а архитектура и инструменты лучше переваривают более высокоуровневый язык (C), с которым быстрее писать код, и который проще портировать. Но насколько я помню - голова хорошо болела и у меня и у остальных, а что б я делал без опыта с более простыми МК?
Передачу по BT придётся ставить самоцелью и в ущерб всему остальному, если хочется это реализовать прямо в своём камне. Там один только стек вынудит израсходовать под мегабайт флеша, хз сколько ОЗУ, и поднять RTOS). В такой среде обрабатывать критичные ко времени процессы? Ну не знаю. Я в ОС стараюсь не залазить и пока получается. Не то что бы я спец по BT и в чём-то могу ошибаться, но говорю из собственных наблюдений за теми, кто с ним работал. Обычно берут отдельный модуль со своим камнем и готовой прошивкой, не требующий гробить всё остальное в собственном камне. Или поднимают его в камне, на котором не висят критичные задачи.
Теперь мы подошли к этому:

 Сообщение от Reyden :

В чем заключаются изъяны micro Python при написании кода для работы преобразователей?

В том, что он не будет работать на голом камне без ОС и выполнять сложные прерывания достаточно быстро и часто? Но я свечку не держал - можешь попробовать . У меня обычно 50% ресурсов уходит на одно прерывание, каждый период ШИМ, частоту которого вечно хочется поднять, а ресурсов и так на всё не хватает. И это с оптимизациями кода в ущерб качеству вычислений. В этом прерывании сидят все PIDы, мат. модели регулируемого контура, модуляторы, расширяющие разрядность ШИМ (очень жирные и медленные на С, по сравнению с ассемблерным вариантом) и т.п. И на всё (включая всю остальную программу) - сотни тактов. Из которых 2/3 - дрочка памяти (чего нет у AVR)... Я на 60МГц тактовой частоты в ARM смотрю как на 1-4МГц в AVR - это мало... Вот начиная с 160 уже что-то ощущается, а на 400МГц пока что вообще почти хорошо. И я уже не удивляюсь так многоядерности и аппаратному ускорению тригонометрии в МК на сотни мегагерц для... управления какими-то сраными моторами...

А ведь когда-то я считал, что простейшего Cortex-M0 на 48МГц мне хватит - больше я так на эти мегагерцы не смотрю. Минимально рабочий камень для всяких преобразователей и контроллеров двигателей - STM32F301/303 (M4, 64MHz от встроенного RC). Пробовал делать УЗ сенсор на F103 - не понравилось. Пробовал делать спектроанализатор на F100 - пришлось перепаять на F303 и то его впритык хватает... Хорошо себя показали F407 и H743, а у последнего даже завезли нормальную систему тактирования, человеческий DMA, и аппаратную передискретизацию АЦП (хотя пока ещё ущербную - ждём). Без аппаратных ускорялок ресурсы таят мгновенно - там конские потоки данных, поэтому В ПЕРВУЮ очередь нужно смотреть не на мегагерцы, а на периферию и её возможности. Сейчас на очереди L433 - посмотрим что за зверь, пока нравится.

 Сообщение от Reyden :

Тот же STM32 есть на ARM Cortex M4

Вот STM32 я б рядом с этими поделиями действительно не ставил... И если уж ARM, да ещё и низкий ценник не требуется - STM32 удобны своей экосистемой. Это как AVR, только ARM). Хотя, они даже дальше ушли - у них ещё и pin-to-pin совместимость между МК в одинаковых корпусах. По надёжности - их находят в автомобильных ЭБУ, да и народ доволен (кроме одного знакомого, у которого только AVR не горят). У меня они пробиваются по питанию нахер, если на любой пин случайно 12V попало - у AVR только пин глючить начинает. Но мне говорят что у других прям кусок корпуса до красна раскаляется в этом месте, а STM продолжает работать...

[Reyden]

 Сообщение от INFERION :

Реалтаймовость? Такие ребята часто не знают даже что такое мультимедийный таймер в винде, а вопрос "как вывести с компа в UART поток пакетами раз в 5мс" их ставит в тупик. Зато они легко юзают систему Git, мгновенно понимают где найти и как прикрутить "вон ту библиотеку", быстро осваивают новые среды. Разные области - разные навыки.

Думаю конкретный подход очень сильно зависит от ситуации. Многие просто не хотят изучать что то новое и пилят на одном языке в то время как есть более оптимальные подходы к решению задачи. Arduino позиционирует себя как платформа для IoT (Internet of Things), организовать на ней bt модуль и вывести инфу на дисплей с последующей подключением к основной схеме которой управляет другой мк это скорее самый оптимальный случай использования. Если еще хватит памяти для преобразователя тогда вообще отлично, но там видно будет.

Встречал комментарии от разработчиков электроники по поводу правильности программирования мк. Скорее всего тот кто привык к высокоуровневым языкам вряд ли будет понимать все тонкости низкоуровнего программирования на мк. Может оно и будет работать, но не факт что эти костыли сгодятся для серьезных проектов или хотя бы решат задачу красиво.

"Arduino low level programing IDE? Flashing LED with 20MHz CPU clock and sending data via uart at low speeds Arduino may do the job. But try running multiple processes in parallel with out "do nothing"(delay) getting in your way when your design reaches real word applications. Try squeezing your design into something like attiny series mcu, where you do not have 20k byte ram or 64-256k flash. Microcontrollers are not microprocessors and they should not be treated as such. My skills as an electronics design engineer ware development in parallel with all of the Arduino hype, but thank God I was shown the difference between a proper design and Arduino shield - include project stuff. Arduino is good for getting attention and getting comfortable with handling electronics, but in my opinion a hobbyist, a maker should know how to use interrupts, how to run multiple processes in parallel, how to design a basic schematic. P.S. delay beyond 20 NOP commands should be frowned upon."

Выходит ядро ARM еще не делает мк достойным, есть еще куча нюансов со структурой мк. Может тогда сразу переходить на STM? Поискать аналоги Аttiny раз экосистема лучше.

 Сообщение от INFERION :

AVR, который уже даст базовые представления о работе всей этой подкапотки. А ещё будет потом сравнительная база.

Сложно не согласиться, AVR для старта подойдет как нельзя лучше. У меня стоит Atmel Studio, какой софт лучше всего юзать для работы с AVR? Так же актуален вопрос о моделировании схемы с прошивкой мк. В свое время юзал Proteus, когда был студентом, сейчас выбор софта куда больше.

[INFERION]

 Сообщение от Reyden :

Скорее всего тот кто привык к высокоуровневым языкам вряд ли будет понимать все тонкости низкоуровнего программирования на мк.

Так поэтому я и предлагаю начинать с AVR, чтоб получить сравнительную базу. AVR очень уютны для низкоуровневого программирования. Нужно запустить таймер? -Записал в его предделитель тактовой частоты не ноль - он и пошел тикать. Нужно с него ШИМ получить? Поставил битик "нужен ШИМ" - всё... Нужно заснуть? Блин, элементарно! Выбрал режим и заснул - проснётся по нужному тебе чиху (все прерывания работают, любой пин может разбудить, сторожевой пёс и т.п.) ровно за 6 тактов и продолжит работать ровно с этого места, будто ничего не происходило. Он может сидеть в датчике, например, хронографа, который успеет зафиксировать пролёт пули даже если МК спал крепким сном. ARM потребует отдельного датчика, который успеет разбудить его, пока снаряд долетит до следующего датчика. И время пробуждения - известно только приблизительно и оно большое.

Потом переход на ARM вызовет вопросы в стиле "зачем они тут так всё переусложнили?", "Блин, а обязательно чтоб запустить таймер - я должен свиснуть тут, пёрднуть тут, потом всосать обратно очком что выперднул, и только после этого дёрнуть вот тут?". Архитектура - "насрали, нассали, смешали"... Без отладки там делать нечего - даже в документации и заголовочных файлах встречаются ошибки, да и часто пропускаешь какие-то моменты, ибо их там дофига. Конструктор лего. Хочешь включить таймер - а ты сперва подай на него питание, разреши в шине его тактирование, сбрось его, потом отмени сброс, настрой кучу всего на пине, чтоб подключить его к этому таймеру и в правильном режиме (режим альтернативной функции, вариант альтернативной функции, с нужными подтяжками, скоростью, и конечно же не забыть тоже подать питание, сбросить и затактировать модуль I/O, в котором находится этот пин), и затем у тебя ещё есть десятка два 32-х битных регистров в самом таймере... И да, для этого всего у тебя несколько разных даташитов с тысячами страниц А4...
Спящий режим?.. Ну... Как бы это сказать. Проще, наверное, физически отрубать питание - результат тот же, но добиться его проще. Всё равно при нормальном сне все данные теряются, вся периферия отключается и нуждается в повторной.. по сути загрузке МК с нуля. Это тебе не AVR, который как КМОП логика - просто перестаёт потреблять при отсутствии тактирования и спокойно зависает в текущем состоянии с полной готовностью принять следующий такт.

Но у STM таки удобная периферия. Да, нужно поковыряться, поматериться, но затем она кучу ресурсов экономит. АЦП может шпарить на единицах мегасемплов автоматом перебирая рандомно настроенные каналы в нужном тебе порядке, ещё и измеряя их разное время, в зависимости от сопротивления цепей, делать аппаратно передискретизацию, вычитать смещение, проверять пороги компараторами (защиты от КЗ, снижения напряжения питания и т.п.), складывать данные в ОЗУ, и всё это без участия ядра... Возможно, в каких-то ситуациях получится даже сразу в ШИМ аппаратно вывести результат, проинвертировав его, и получить простой П-регулятор. Или, например, вывести триггер с АЦП на таймер, который аварийно отрубит все каналы ШИМ при срабатывании компаратора в АЦП. Да, периферия там умеет в триггеры, которые можно настраивать и коммутировать между собою.
Контроллер прерываний там крут! Задаёшь приоритеты каждому прерыванию, можешь генерировать программные прерывания, и он сам следит за контектстом, суёт всё в стек, и позволяет перебивать одни прерывания другими в зависимости от приоритетов. Почти ядро ОС, только аппаратное. А, да, ещё можно ремапить таблицы прерываний, стек, и выполнять код из ОЗУ (привет подгружаемые приложеньки). Только все эти возможности С не раскрывает и приходится костылить. Например, как узнать размер функции для её загрузки в ОЗУ? Зачем это нужно, если она уже есть в Flash? А дело в том, что Flash останавливается на время записи в него, подвешивая весь МК. А EEPROM в нём нет, так что приходится перегружать код в ОЗУ и выполнять его оттуда. Но в ОЗУ он медленнее и место занимает, поэтому постоянно крутить его там - так себе идея. Кстати, в H743 завезли два модуля флеш, и один можно юзать как EEPROM, не блокируя второй с исполняемым кодом. Сколько тонкостей, ага?..

 Сообщение от Reyden :

Поискать аналоги Аttiny раз экосистема лучше.

Да нету там такого. Разные это МК. AVR самодостаточные, но слабые, а STM32 мощные, но требуют кучу обвеса для работы и гораздо сложнее в понимании. Если хватает производительности AVR - он будет удобнее. А её хватает в фонариках... STM32 я вот пока рискнул сунуть только в квадрофонарь, но там же и дисплей с тачем, и USB, и повербанк с QC и PD.

 Сообщение от Reyden :

У меня стоит Atmel Studio, какой софт лучше всего юзать для работы с AVR?

Хз. Я сижу на AVR Studio 4, но свежие МК, которые уже при Микрочипе были разработаны (типа ATtiny841) им не поддерживаются. Но и юзать пока не приходилось.
Кстати, ещё у AVR документация "всё в одном pdf файле", и помещается на сотне страницах. Это уже с инструкциями, с протоколами программирования и вообще всем, что может понадобиться на войне для программирования нулями и единицами с тетрадки, вводимыми проводочками в руках. К STM32 ты качаешь минимум три даташита (на сам чип, reference, errata), и ещё пачку апнотов по интересующей тебя периферии. И один только Reference имеет 1000-2000 страниц A4...

 Сообщение от Reyden :

Так же актуален вопрос о моделировании схемы с прошивкой мк.

Я натыкался на мнения "мне и своих глюков хватает, чтоб ещё и глюки симулятора ловить". Сам никогда симуляторами не пользовался - у меня для этого есть Visual Studio и навыки писать модели на С. Они потом же и копипастятся в код МК (жирный плюс С, по сравнению с ассемблером), после отладки в виртуальной среде на компе. Например, вот я моделировал работу усилителя:

Тут только НЧ канал выводился в график. Смотрел как проседает питание, что требует динамик и как он греется. А там ещё и механика отслеживается, ну и усилитель в себя включает кроссовер, здорово нагружающий МК, HPF, отрезающий ИНЧ, блок питания со своей ёмкостью, пульсациями выпрямителя и внутренним сопротивлением (это симулятор просимулирует, да), и ещё кучу всего, влияющего на выходной сигнал в этом вот канале. При этом на входе реальный сигнал - обычный музыкальный файл. И всё это - учитывается. Я не думаю что электросимуляторы дадут такую гибкость в описании физической системы и её тестировании, тем более когда этот код всё равно нужен самому МК и его всё равно писать. Ну и сколько симулятор будет эти 5 минут гонять? На Си я подождал секунд 20...

Думаю, нормальной симуляции просто не существует. В студии AVRки можно симулировать, но только в плане теста алгоритмов. Ядро нормально симулируется, а вот периферия глючит. STMки отлаживаются прямо внутри готовой схемы через SWD (но только в плане проверки где он завис, какой бит не установился и т.п.). Кстати, к ним имеются самые дешевые и хотя бы работающие программаторы (ST-Link). Берёшь китайца за 2 бакса и всё отлично. В отличии от всяких J-Link, стоящих десятки баксов и со слетающими через неделю прошивками (и хрен восстановишь). Это просто боль, одни только STM с их ST-Link и вытащили. И их вроде как можно перепрошить под J-Link (у которого софт круче и он уже универсальный).

Опять кучу текста настрочил...

[Reyden]

 Сообщение от INFERION :

Опять кучу текста настрочил...

Нормально, я осилил

Пытаюсь понять в чем разница между использованием Arduino IDE и Atmel/AVR Studio в работе с Attiny. Получается оболочка Arduino со своими библиотеками и компилятором имеет косяки и не использует все преимущества мк. Если делать в AVR то время на выполнение программы и прерывание значительно меньше. По сути упрощение программирования в среде разработки приводит к негативным последствиям. Казалось бы обе среды используют один и тот же язык программирования с последующим компилированием кода для мк, но результат разный. Не встречал чтобы прописывали Fuse на Arduino, явное отсутствие низкоуровнего функционала.

 Сообщение от INFERION :

"Блин, а обязательно чтоб запустить таймер - я должен свиснуть тут, пёрднуть тут, потом всосать обратно очком что выперднул, и только после этого дёрнуть вот тут?". Архитектура - "насрали, нассали, смешали"... Без отладки там делать нечего - даже в документации и заголовочных файлах встречаются ошибки, да и часто пропускаешь какие-то моменты, ибо их там дофига. Конструктор лего. Хочешь включить таймер - а ты сперва подай на него питание, разреши в шине его тактирование, сбрось его, потом отмени сброс, настрой кучу всего на пине, чтоб подключить его к этому таймеру и в правильном режиме (режим альтернативной функции, вариант альтернативной функции, с нужными подтяжками, скоростью, и конечно же не забыть тоже подать питание, сбросить и затактировать модуль I/O, в котором находится этот пин), и затем у тебя ещё есть десятка два 32-х битных регистров в самом таймере... И да, для этого всего у тебя несколько разных даташитов с тысячами страниц А4...
Спящий режим?.. Ну... Как бы это сказать. Проще, наверное, физически отрубать питание - результат тот же, но добиться его проще. Всё равно при нормальном сне все данные теряются, вся периферия отключается и нуждается в повторной.. по сути загрузке МК с нуля. Это тебе не AVR, который как КМОП логика - просто перестаёт потреблять при отсутствии тактирования и спокойно зависает в текущем состоянии с полной готовностью принять следующий такт.

Да ну нахрен 100% не для начального уровня, войти и не выйти

 Сообщение от INFERION :

Сам никогда симуляторами не пользовался - у меня для этого есть Visual Studio и навыки писать модели на С. Они потом же и копипастятся в код МК (жирный плюс С, по сравнению с ассемблером), после отладки в виртуальной среде на компе. Например, вот я моделировал работу усилителя:

Посмотрю что есть у Microchip, вроде они предлагают бесплатные инструменты для разработки.

[INFERION]

 Сообщение от Reyden :

Пытаюсь понять в чем разница между использованием Arduino IDE и Atmel/AVR Studio в работе с Attiny.

Хз. Главное, чтоб среда поддерживала ассемблер, а дальше пофиг, что у неё там за библиотеки - они всё равно тупо не используются... Можно и в блокноте писать - я так раньше и делал, пока не научился ковырять формат файла, чтоб студия показывала кириллицу (использую русский в комментариях).

 Сообщение от Reyden :

Если делать в AVR то время на выполнение программы и прерывание значительно меньше.

Приблизительно одинаково с ARM, на самом деле:
- Что там ~256 тактов на прерывание, что там.
- Там 8-ми битные переменные, позволяющие экономить ресурсы, а там 32-х битные - тоже позволяющие их экономить, но иначе.
- AVR позволяет не дрочить память (дохера РОН + ассемблер), а ARM позволяет не дрочить переменные (сдвиг на любое число бит за 1 операцию, условные команды и т.п.).
Единственная разница - AVR ты кодишь на ассемблере, а ARM - на Си. И у AVR медленный АЦП и в целом всё на более низких частотах происходит. На десятках килогерц вместо сотен. Это отражается на качестве регулирования, но фонарику хватает (пока пишешь на ассемблере, на Си он ТК пишет - результат не очень).

 Сообщение от Reyden :

Казалось бы обе среды используют один и тот же язык программирования с последующим компилированием кода для мк, но результат разный.

Ты про разные компиляторы? Если под AVR писать на Си, то обычно используют GCC компилятор. Он есть в AVR Studio. Юзать его на ARM - ну он считается более стандартным и каноничным, но проигрывает тому же компилятору IAR, плюс ты намучаешься с опенсорсными IDE под него, вроде Eclipse. Что касается Keil - я так смотрю, он для совсем начинающих (готовые либы, минимальная гибкость и максимальная простота), потом с него сбегают в IAR, а самые бородатые начинают юзать гибкий и "собери собаку из чебуреков сам" глючный Eclipse. Но это уже когда тебе не хватает функционала линкера и всяких хитрых штук для хитрой сборки проектов - я пока до этого не дорос.

 Сообщение от Reyden :

Не встречал чтобы прописывали Fuse на Arduino

А там же загрузчик свой зашит в платки, и всегда конкретная тактовая частота (16МГц вроде) и 5V питание. Всё прошивают на заводе для нубов. Это ж платки для стационарного питания и работы во всяких там автоматах, раздающих кофе, поливалках цветов и т.п. И на них распаянная физ. кнопка, которая всегда висит на RESET. Прям педаль, как на передней панели ПК под виндой.

 Сообщение от Reyden :

Да ну нахрен 100% не для начального уровня, войти и не выйти

Вполне начинают с HAL и CubeMX. Там просто галочки ставишь что тебе надо - оно код само генерит и проект создаёт под нужную тебе среду (Keil, IAR, Eclipse). Конечно, та ещё срань, и гибкости никакой. Потом или застряют в этом, или если раньше кодили AVRки, то сразу плюются на этот высер говнокода и отказываются от HAL (в пользу CMSIS, поверх которого он написан)... При этом сам CubeMX мегаудобная прога. В нём сразу можно выбрать подходящий МК из списка по параметрам (корпус, память, периферия, стоимость), тут же мышкой повключать нужную периферию и раскидать пины по корпусу (вместо чтения таблиц функций этих пинов на много страниц в даташите) - всё, для схемы уже всё необходимое есть. Там же потыкать мышкой в карту тактирования и наглядно увидеть что как тактируется и где какие коэффициенты стоят - потом в коде проще будет повбивать в регистры что нужно. Просто смотришь на картинки и "ага, вот в этот регистр пишем 16, в этот 2, в этом оставляем ноль, вот этот пин у нас на выход, этот аналоговый, а у этого альтернативная функция - 1-й канал таймера 1":

Потом ты генерируешь проект (естественно, с HAL), вытягиваешь из него либу CMSIS в свой проект, и удаляешь оставшийся высер нафиг... При этом он всё подгружает из инета. Новые МК, свежие библиотеки и т.п. У тебя об этом голова вообще не болит. Если б он ещё и нужные даташиты сам выкачивал...

[Behram]

 Сообщение от INFERION :

Потом ты генерируешь проект (естественно, с HAL),

Не обязательно. В настройках можно переключить используемые либы с ХАЛа на ЛЛ и с последним сгенерированные проекты получаются весьма компактными и наглядными. По сути, ЛЛ это старые StdPeriph, но на новый лад.
Удобно еще прямо в коде посмотреть что и как конфигурируется для получения нужного функционала, благо в ЛЛ не нужно закапываться в дебри инклудов, там сразу дефайнами вызываются CMSISные маски.

 Сообщение от INFERION :

Если б он ещё и нужные даташиты сам выкачивал...

Выкачивает
В проге, при выборе проца, есть вкладка Docs & Resources и там по нему все документация.
Зачастую, из документации нужен лишь один референс мануал

[Behram]

 Сообщение от INFERION :

Что касается Keil - я так смотрю, он для совсем начинающих (готовые либы, минимальная гибкость и максимальная простота), потом с него сбегают в IAR, а самые бородатые начинают юзать гибкий и "собери собаку из чебуреков сам" глючный Eclipse.

Использую TrueStudio, который сделан на базе того же Эклипса, ничего плохого сказать не могу.
У Кейла есть еще один не маловажный плюс - при отладке с использованием ST-Link, он умеет непрерывно выводить значения регистров и переменных на экран, а не только при остановке программы. ИАР и Трустудио это тоже умеют, но только если перешить ст-линк в J-Link. Может можно как-то еще, но я не нашел. Конечно, "боевые" быстрые системы управления так не отладить, но для понимание того, что происходит в системе это очень удобно.

[INFERION]

 Сообщение от Behram :

В настройках можно переключить используемые либы с ХАЛа на ЛЛ

Действительно, есть такое. Нагуглил это: http://mypractic.ru/urok-9-...
Звучит как драйверы, которые некоторые сами пишут.

 Сообщение от Behram :

В проге, при выборе проца, есть вкладка Docs & Resources и там по нему все документация.

А, на этом этапе. Так я же МК сперва оценить должен, создав проект, и где мне потом искать эту вкладку? Заранее мусор качать на целый список вариантов, пока вкладка доступна?

 Сообщение от Behram :

Зачастую, из документации нужен лишь один референс мануал

Это если юзать готовые драйверы, которые у меня обычно глючат и не делают что мне нужно? В референсе нет, например, таблицы альтернативных функций и электрических параметров всяких там ADC. А ещё ошибки в Errata полезно глянуть, иначе сюрпризы гарантированы.

Behram, кстати, может ты подскажешь:
Я не могу нормально записать большой массив в Flash - спустя порядка килобайта записей начинают сыпаться ошибки верификации, при чём повторная запись проблему решает. Таймауты никак на это не влияют, разбиение процедуры записи на блоки по 512 байт с жирными паузами между ними - тоже. Ошибки сыпятся в разных местах, но в определённой области на странице - не все единички в записываемых данных сбрасываются в ноль с первого раза. Попытки записать только в эту область - дают тот же результат. Чё за фигня? МК новый. У модуля Flash не хватает напряжения записать ячейки за 1 заход в дефектной области? Гугл молчит. Такое хоть пиши всё по два раза, на всякий случай, чтоб надёжнее и долговечнее...

[Behram]

 Сообщение от INFERION :

Behram, кстати, может ты подскажешь:

С встроенным флешем, к сожалению, не работал.
Может есть смысл попробовать увеличить тайминги латентности флеша? Или перед записью понизить частоту проца.

[scsichnik]

 Сообщение от INFERION :

не могу нормально записать большой массив в Flash - спустя порядка килобайта записей начинают сыпаться ошибки верификации, при чём повторная запись проблему решает

Была когда-то похожая проблема с флэшем. При записи, когда потребление возростало, банально перегревалась. И вроде, нагрев не фатальный, но параметры начинали плыть.

[AEDe]

INFERION, коли тут такие высокие материи обсуждали, давно хотел спросить, а ПЛИС для драйверов чем не подходит? Вроде и мелкие есть и жрут мало и как раз для систем реального времени...

[INFERION]

 Сообщение от Behram :

Может есть смысл попробовать увеличить тайминги латентности флеша?

Там максимум и так, а крутить тактирование на лету с кучей работающей периферии тем более не стану.

 Сообщение от scsichnik :

При записи, когда потребление возростало, банально перегревалась.

Тут не успевает, и длительность записи ДО этого места - не влияет на характер ошибок.

Короче, пишу в цикле до посинения, пока не запишется. Некоторые ячейки так требуют несколько тысяч попыток. Я бы это назвал бракованной памятью. Надо бы туда записать константы, посмотреть что программатор скажет...

 Сообщение от AEDe :

а ПЛИС для драйверов чем не подходит?

Не юзал, но они и не выглядят привлекательно для этой задачи. В них тоже такая богатая аналоговая периферия? Или синтезированное в них ядро будет экономичнее и занимать меньше вентилей, чем то же ядро, сразу выращенное на кристалле под видом МК? А Flash туда тоже завезли, или ещё и искать экзотику среди ПЛИС? Их проще программировать? В чём их преимущества то перед чипами, специально разработанными для этих задач?

[AEDe]

 Сообщение от INFERION :

В них тоже такая богатая аналоговая периферия?

Я не сильно в теме какие они бывают, флешем точно есть, какая-то периферия там тоже есть.

 Сообщение от INFERION :

В чём их преимущества то перед чипами, специально разработанными для этих задач?

Чипы не для конкретно этих задач делались, они универсальные, а плис можно прошить под конкретную задачу.

 Сообщение от INFERION :

Их проще программировать?

В каком то смысле т.к. программы для них написанные более-менее универсальны.
Но это так у меня вопрос для общего понимания , в стиле, "есть ли жизнь на Марсе", если не пользовались значит не по адресу))

[greenled]

 Сообщение от AEDe :

ПЛИС для драйверов

А смысл? Плис хороши там, где требуется решение множества параллельных задач, потому и применяют в большинстве случаев в обработке сигналов. Для фонарного драйвера на кристалле все равно придётся реализовывать процессорное ядро, так не лучше ли сразу взять микроконтроллер?