Сможете на меге сделать частотомер с reciprocal counter
Товарищ, вы не утомились уже несколько лет к ряду (я не утрирую) ходить по разным форумам и повсюду потрясать двумя одними и теми же предметами -- reciprocal counter и динамической индикацией, красоты неописуемой?
Вопрос в другом, на некоторых МК широкий круг задач решается проще и быстрее, и только. И по сегодняшним меркам это не мега, увы. Остаётся только сила привычки.
Вопрос в другом, на некоторых МК широкий круг задач решается проще и быстрее, и только. И по сегодняшним меркам это не мега, увы.
Пальцем в небо. Широкий круг задач решается быстрее именно на меге, по той причине, что на данный момент уже существует масса однотипных решений на ней же.
Прелести STM32 на этой задаче немного потускнели из-за необходимости трехвольтового питания и преобразования уровней. Шансы у STM8S и атмеги, напротив, возросли.
У СТМ32 многие выводы толерантны к 5 Вольтам. Да и большинство нынешних девайсов работают с 3 Вольтами. Так что проблема и не настолько велика.
Цитата:
В отличие от STM32 и амтеги, STM8, неизвестно с какого перепугу, имеет иной порядок представления последовательности байтов. Атмега и STM32 оперируют порядком от младшего к младшему (little-endian), а STM8, наоборот, от старшего к младшему (big-endian). Это может и не было бы проблемой, если бы не одно "но": данные в эфире у меня передаются в виде упакованных записей и границы битовых полей не совпадают с границами байтов. Просто поменять местами байты на приемной стороне не выйдет -- ломается структура битовых полей.
Неприятно, но не смертельно. На СТМ32 это всё вообще можно крутить как цыган солнце, на СТМ8 стоит заглянуть в референс по ИАР, там есть варианты по упаковке структур. Как ИМХО, проблема слегка преувеличена. Конечно, сделать тупо в лоб проще, чем с чем-то разбираться, но оно неизбежно догонит где-то в другом месте.
A5021, писал: "Поймите простую вещь -- не нужно противпоставлять эти МК "в лоб"."
Золотые слова, что я и попытался продемонстрировать автору под ником ssss, так сказать "его же салом по его сусалам", то бишь применив теже самые "маркетинговые заморочки" ... и ещё не факт, что не смогу его переубедить в том, что "stm32 - полный отстой и AVR рулит" :) Хотя это и не так, ибо ещё раз:
КАЖДОМУ ОВОЩУ - СВОЕ ПРИМЕНЕНИЕ.
Это то, что он категорически не понимает в погоне за модой и копроэкономикой.
STM32 - имеет большую разрядность, и как следствие НЕИЗБЕЖНО: большие затраты на размер кода, данных, объемы пересылок (загрузка шин ЦПУ) и это БЕЗОТНОСИТЕЛЬНО к его архиитектуре, это общая плата за разрядность. И это та самая причина почему апологеты сливаются как только их попросишь привести примерчик.
Но. У каждой медальки завсегда 2 стороны .. и за эту плату он имеет большую мощу в вычислительной сфере - и тоже безотносительно к его архитектуре.
А вот далее, начинаются "нюансы" .. и они НЕ в пользу конкретно STM32:
а) рыхлый и неэффективный код .. авторы даже пошли на разработку "урезанного" набора команд, дабы хоть как-то сократить этот провал. И это - ПРОВАЛ и безусловный. И компенсируется это только ростом объемов памяти на кристале и ростом тактовой частоты. Больше никак. И "сколько вешать в граммах" .. апологетами тщательно СКРЫВАЕТСЯ, ибо МНОГО (около 3.5 РАЗА).
б) плохо спроектированная периферия, требующая больших и сложных инициализаций. И тут, тоже всё очень характерно и уже писал иным авторам .. но, апологеты потому и сравнивают 32 битный проц с 8/16 .. что с собратом оно проиграет вчистую. Даже наши скопировав и лицензировав ядро .. тем не менее воткнули СВОЮ периферию .. ибо "кому она такая нужна?" :)
в) "цена" .. низкая цена на СТМ как раз не есть "достоинство" в условиях тотальной копроэкономики. Это первый и верный признак того, что архитектура УПРОЩЕНА и за это ПРИДЕТСЯ ПЛАТИТЬ программисту своим трудом. .. что и видим "сплошь и рядом" в виде "мне проще" ... ктоб спорил. :)
И тем не менее, у этого камня есть и свои достоинства .. они на самом деле там же, в тех же самых пунктах и сидят. Ибо у каждой медальки 2 стороны. ВСЕГДА.
Широкий круг задач решается быстрее именно на меге, по той причине, что на данный момент уже существует масса однотипных решений на ней же.
Вот именно, однотипных, вариантов нет никаких, что само по себе уже убого. Варианты дают свободу действий и наилучший результат даже в сложных задачах и ситуациях.
Не подтверждается. Код определяется ядром от АРМа. Не может плохое ядро быть настолько популярным, это нонсенс.
Цитата:
б) плохо спроектированная периферия, требующая больших и сложных инициализаций.
Не подтверждается. Периферия просто чудесна, СТМ тут просто молодцы. А кажущаяся сложность компенсируется широкими возможностями периферии. Другое дело, что некоторым это тяжело осознать.
Цитата:
в) "цена" .. низкая цена на СТМ как раз не есть "достоинство" в условиях тотальной копроэкономики. Это первый и верный признак того, что архитектура УПРОЩЕНА
Архитектура чего упрощена? Ядра? Ядро чисто АРМовское! Периферии? Так вы же пару строк назад жаловались, что она сложна? В новых камнях, хотя они и дешевле, периферия более развита чем в старых. Удивлены? ))))))
У СТМ32 многие выводы толерантны к 5 Вольтам. Да и большинство нынешних девайсов работают с 3 Вольтами. Так что проблема и не настолько велика.
Она становится особенно ничтожной, если это не твоя проблема, правда? Т.е. я должен был лепить дополнительный стабилизатор, уповать, что оно будет правильно дергать пятивольтовые уровни, чтобы какие дполнительные плюшки получить? Как никакие? А нахрена ж тогда все это? Лишние усилия и риски, они зачем?
Цитата:
Неприятно, но не смертельно. На СТМ32 это всё вообще можно крутить как цыган солнце,
В волшебных снах. Все, о чем вы пишете, существует главным образом там. А с другой стороны, зачем мне надо что-то там крутить? Каков положительный выхлоп ожидается? Опять никакого? Да что же это за советы у вас такие, когда каждый раз надо напрягаться, но ничего с этого не получать?
Цитата:
на СТМ8 стоит заглянуть в референс по ИАР, там есть варианты по упаковке структур.
Мож лучше вам самому туда заглянуть? А то "нахватались верхушечек" и несете лажу всякую. Нет у иара для стм8 ни модификатора, ни директивы для паковки структур. Для армов есть, а для стм8 нет. Вот так, язык тот же, разработчик тот же, но в одном случае есть, а в другом нет.
Цитата:
Конечно, сделать тупо в лоб проще, чем с чем-то разбираться, но оно неизбежно догонит где-то в другом месте.
Вы прорицателем что-ли подрабатываете? Того, кто в курсе, догонит вряд ли, а членов секты пусть догоняет. Туда им и дорога.
У вас маниакальное стремление быть правым любой ценой, но мне пофигу. Вы не умеете слушать и понять что вам говорят, но мне пофигу. Отсюда и все ваши мелочные трудности, но мне пофигу. Всё это можно списать на вашу молодость и отсутствие опыта, но мне пофигу.
И чтобы вам было более понятно, я не пользуюсь ИАРом под СТМ32, только под СТМ8, потому что мне пофигу.
Ну вот, заплакал и пошли какие-то обидки. Вы со своей сектой не можете понять элементарнейшие вещи -- не нужно делать сложно то, что можно сделать просто. Не нужно избретать велосипед, если он изобретен несчетное число раз до вас. Если есть возможность не делать лишнюю работу, ее не нужно делать. Это не просто бессмысленно, это вредно.
Опять твои слова никчемные. А факты? Со структурами ты не разобрался, с софтовым ЮАРТом тоже. Ну и кто из нас плаксивее и обидчивее?
Еще, кто логичнее спросите.
Со структурами вручную пусть разбирается тот, кому заняться нечем. Я эту работу спихнул на компилятор. Вон они, структуры. Прошлой ночью на ThingSpeak повесил. Теперь, если будут еще посещать грустные мысли о том, как там у меня со структурами, можете сразу туда идти, там все в реальном времени отображается.
Цитата:
Твоя лень и есть корень зла. Не стать тебе повелителем халявы, потому что даже для этого нужно приложить какие-то усилия.
Что-то я не понял. Эта ветка обо мне или вам просто сказать нечего?
А у нас, чего, только истовая вера во что-то одно рулит? Нельзя так, что туда, где лучше отработает СТМ, ставить СТМ, а где мега, там мегу? И с выбором чего-то одного на всю жизнь терзаться не придется.
А вот не надо ничего выдумывать. Надо будет поставить мегу или ПИК - не вопрос, опыт имеется! И даже не скривлюсь! Только вот за последние годы ну не разу такого не понадобилось.
Полистал примеры и даташит (больше 1500 страниц!!!) на STM32F103 .. н-да. Это не "куча периферии", это .. бардак в стремлении сделать "все можно" .. в общем, остаюсь при своем мнении поста №155: каждому овощу свое место.
И место для STM32 теперь в моем понимании выглядит достаточно просто: применимо, но только там где ресурсов/периферии иных МК гарантированно не достаточно. Ибо плата за весь этот "поперечнонезависимыйбардак" - ТРУД ПРОГРАММИСТА. А он - пока ещё дорог.
Когда я несколько лет назад упомнул при сектантах, дескать, хороший камень стм32, но уж больно писанины много, так они меня чуть не покусали. :) Потом, когда я увидел их программистские каракули, я понял, что они-то себя писаниной не особо затрудняют. Пишут, как бог на душу положит. А по уму, чтобы не запутаться, не опечататься и не пропусить что-то важное, каждый регистр инициализации приходится расписывать полностью. Что-то наподобие такого:
Пока лазил в исходники, обратил внимание, что размер файла, расписывающие одни только ноги 20-пинового чипа, у меня составляет 18 килобайт. Если отбросить всякие питательные ноги и прочие резеты, то выходит больше килобайта на пин. :)
Ибо плата за весь этот "поперечнонезависимыйбардак" - ТРУД ПРОГРАММИСТА. А он - пока ещё дорог.
Чушь! На эмбедде можно заработать если сами что-то и продаёте или пишете под заказ. Для домашних поделок это вообще неприменимо. Никто а5021 за его дамашнюю поделку платить не будет, просто убийство времени, при любом МК. И не факт, что на меге это будет быстрее.
А по уму, чтобы не запутаться, не опечататься и не пропусить что-то важное, каждый регистр инициализации приходится расписывать полностью.
Чушь притянутая за уши. Пишется один раз, если надо, потом только тупо копируется.
Цитата:
Пока лазил в исходники, обратил внимание, что размер файла, расписывающие одни только ноги 20-пинового чипа, у меня составляет 18 килобайт. Если отбросить всякие питательные ноги и прочие резеты, то выходит больше килобайта на пин. :)
Опять чушь. Без разницы что инклюдить, своё или чужое в либах. В либах поболее будет, там много лишнего.
Калаш, пишет: "Блин, я так и не понял, что лучше STM32 или Ардуинка?.."
Блин, смотря ДЛЯ ЧЕГО .. :)
Если сделать что-то простое, быстро и на коленке, да чтоб ещё и работало .. то Ардуинка.
Если простое или не очень сложное, но надо сделать чтобы ХОРОШО РАБОТАЛА (шустро, надежно, компактно и т.д. выберите 2 из 7 пунктов :) .. то берем Ардуино и пользуем нормальное ПО (Atmel студию к примеру) с применением "знающих людей"
Если надо что-то "этакое", что Ардуинка НЕ МОЖЕТ (ну там float посчитать и много, гимны исполнить или отрисовать чего на хорошем экране или видео принять и обработать онлайн) .. тогда пляшем вокруг STM32 с применением "особо знающих людей за тридорога". .. а то вовсе ищем узкозаточенный под задачу камень ну и соответственно "узкозаточенных специальных людей".
Как тут правильно высказался ssss, нет никаких причин изучать STM32 для домашних поделок "на коленке"... в чем я с ним полностью согласен.
После краткого анализа по статьям в инете, мне показалось что MSP430 это что то среднее между AVR и STM32. В общем ни рыба ни мясо. На сегодня вообще не актуально. И IDE Arduino не поддерживается, что говорит само за себя.
И IDE Arduino не поддерживается, что говорит само за себя.
IDE для MSP430 отличается от Arduino IDE главным образом цветом. Ардуина -- сине-зеленая, Энергия (IDE для MSP430) -- красная. Есть, конечно, и другие отличия, но они менее существенны.
ssss пишет:
От ардуины инфаркт головного мозга случится.
Вы 1 июля с.г. зарегистрировались на этом форуме сугубо в членовредительских целях?
Там выше я писал об интересных свойствах функций inline. Немного дополню. Применение inline в общем то для компилятора имеет рекомендательное значение. Чтоб заставить GCC не выпендриватся а точно делать inline пишем обявление вместо
inline int Fn()
так
__attribute__((always_inline)) int Fn()
Сегодня напоролся, что компилятор два вызова inline сделал как просили, а после добавления еще двух вызовов стал игнорить inline и делать обычный вызов.
Че за бред ssss? Разговор про две ассемблерные команды subs и bhi. Как жеж торгашу обяснить что такое ассемблер.. ну это для проца как для вас ssss родной язык шоле. Единственное что проц на самом деле может понять, и к DELAY_US, ИДЕ, Ардуине и даже Си не относящееся.
Это ваш бред! С какой целью - непонятно. Что вы вообще хотите доказать? Нафик АСМ? Что вы сравниваете? Какие из этого выводы? И что это даёт в практическом применении?
Ещё раз - никому ваш DELAY_US и даром не нужен. Это авр-задротство. На СТМ8 и СТМ32 это всё решается по другому.
Спрашиваю без подкола: а как там это решается? Дело в том, что надумал поизучать STM8, заказал STM8L-Discovery, вот теперь малёха информации собираю.
На СТМ8Л вообще всё решается как на СТМ32. Там опэн драйн по выходу таймера можно установить, для 1-вирэ самое оно. В таймерах есть прелоад, можно простейшие протоколы легко ваять без задержек. Есть ДМА, правда полноценный канал только один. Есть нэстэд для прерываний, т.е. можно спокойно рулить двумя-тремя софтовыми протоколами одновременно. Например - 1-вирэ, софт ЮАРТ и ИР- датчик.
Да. Я ж и пишу, что на АВР решается за 4 такта проца, а на СТМ по другому - аж за 6 тактов.
Из-за аппаратной специфики, на STM32 проблематично исчислять точное время выполнения последовательности команд. На x86 та же проблема, если чо.
Цитата:
Сегодня напоролся, что компилятор два вызова inline сделал как просили, а после добавления еще двух вызовов стал игнорить inline и делать обычный вызов.
Вообще-то я уже писал об этом, но в то время вы были увлечены обвинениями меня в полном незнании Си, отчего, видимо, не заметили.
Да. Я ж и пишу, что на АВР решается за 4 такта проца, а на СТМ по другому - аж за 6 тактов.
Из-за аппаратной специфики, на STM32 проблематично исчислять точное время выполнения последовательности команд. На x86 та же проблема, если чо.
У STM32 конвеер с спекулятивными вычеслениями? Не думаю что там такая же как на х86 проблема, да и у 086 и 186 все было четко. Просто дольше у STM да и все. А учитывая что банальный for(;i;i--) раскрутится именно в такой ассемблер то неприятно. И Arhat109-2 не далек от истины что хотя STM и быстрей но не во столько как относятся тактовые частоты (72/16=4.5), а раза в полтора-два ниже, т.е быстрей в 2-3 раза.
a5021 пишет:
Цитата:
Сегодня напоролся, что компилятор два вызова inline сделал как просили, а после добавления еще двух вызовов стал игнорить inline и делать обычный вызов.
Вообще-то я уже писал об этом.
Дак вот я какраз и показал как боротся. И Вам это тоже полезно надеюсь окажется.
Просто дольше у STM да и все. А учитывая что банальный for(;i;i--) раскрутится именно в такой ассемблер то неприятно. И Arhat109-2 не далек от истины что хотя STM и быстрей но не во столько как относятся тактовые частоты (72/16=4.5), а раза в полтора-два ниже, т.е быстрей в 2-3 раза.
А откуда вообще возникло "гениальное" предположение, что производительность обязана линейно масштабироваться с частотой? Там одной скорости чтения с флеша хватит, чтобы этого не случилось никогда. Если для атмеги флеш не является тормозом, т.к. ядро у атмеги "медленное", то у STM32 ядро может работать быстрее, чем выбираться данные из флеша из-за "задумчивости" последней.
Цитата:
Дак вот я какраз и показал как боротся. И Вам это тоже полезно надеюсь окажется.
Это прописано в отдельной главе референса GCC. Я кусок оттуда уже цитировал.
И Arhat109-2 не далек от истины что хотя STM и быстрей но не во столько как относятся тактовые частоты (72/16=4.5), а раза в полтора-два ниже, т.е быстрей в 2-3 раза.
Товарищ, вы не утомились уже несколько лет к ряду (я не утрирую) ходить по разным форумам и повсюду потрясать двумя одними и теми же предметами -- reciprocal counter и динамической индикацией, красоты неописуемой?
Под каждую задачу - свой МК
Вопрос в другом, на некоторых МК широкий круг задач решается проще и быстрее, и только. И по сегодняшним меркам это не мега, увы. Остаётся только сила привычки.
Вопрос в другом, на некоторых МК широкий круг задач решается проще и быстрее, и только. И по сегодняшним меркам это не мега, увы.
Пальцем в небо. Широкий круг задач решается быстрее именно на меге, по той причине, что на данный момент уже существует масса однотипных решений на ней же.
Прелести STM32 на этой задаче немного потускнели из-за необходимости трехвольтового питания и преобразования уровней. Шансы у STM8S и атмеги, напротив, возросли.
У СТМ32 многие выводы толерантны к 5 Вольтам. Да и большинство нынешних девайсов работают с 3 Вольтами. Так что проблема и не настолько велика.
В отличие от STM32 и амтеги, STM8, неизвестно с какого перепугу, имеет иной порядок представления последовательности байтов. Атмега и STM32 оперируют порядком от младшего к младшему (little-endian), а STM8, наоборот, от старшего к младшему (big-endian). Это может и не было бы проблемой, если бы не одно "но": данные в эфире у меня передаются в виде упакованных записей и границы битовых полей не совпадают с границами байтов. Просто поменять местами байты на приемной стороне не выйдет -- ломается структура битовых полей.
Неприятно, но не смертельно. На СТМ32 это всё вообще можно крутить как цыган солнце, на СТМ8 стоит заглянуть в референс по ИАР, там есть варианты по упаковке структур. Как ИМХО, проблема слегка преувеличена. Конечно, сделать тупо в лоб проще, чем с чем-то разбираться, но оно неизбежно догонит где-то в другом месте.
A5021, писал: "Поймите простую вещь -- не нужно противпоставлять эти МК "в лоб"."
Золотые слова, что я и попытался продемонстрировать автору под ником ssss, так сказать "его же салом по его сусалам", то бишь применив теже самые "маркетинговые заморочки" ... и ещё не факт, что не смогу его переубедить в том, что "stm32 - полный отстой и AVR рулит" :) Хотя это и не так, ибо ещё раз:
КАЖДОМУ ОВОЩУ - СВОЕ ПРИМЕНЕНИЕ.
Это то, что он категорически не понимает в погоне за модой и копроэкономикой.
STM32 - имеет большую разрядность, и как следствие НЕИЗБЕЖНО: большие затраты на размер кода, данных, объемы пересылок (загрузка шин ЦПУ) и это БЕЗОТНОСИТЕЛЬНО к его архиитектуре, это общая плата за разрядность. И это та самая причина почему апологеты сливаются как только их попросишь привести примерчик.
Но. У каждой медальки завсегда 2 стороны .. и за эту плату он имеет большую мощу в вычислительной сфере - и тоже безотносительно к его архитектуре.
А вот далее, начинаются "нюансы" .. и они НЕ в пользу конкретно STM32:
а) рыхлый и неэффективный код .. авторы даже пошли на разработку "урезанного" набора команд, дабы хоть как-то сократить этот провал. И это - ПРОВАЛ и безусловный. И компенсируется это только ростом объемов памяти на кристале и ростом тактовой частоты. Больше никак. И "сколько вешать в граммах" .. апологетами тщательно СКРЫВАЕТСЯ, ибо МНОГО (около 3.5 РАЗА).
б) плохо спроектированная периферия, требующая больших и сложных инициализаций. И тут, тоже всё очень характерно и уже писал иным авторам .. но, апологеты потому и сравнивают 32 битный проц с 8/16 .. что с собратом оно проиграет вчистую. Даже наши скопировав и лицензировав ядро .. тем не менее воткнули СВОЮ периферию .. ибо "кому она такая нужна?" :)
в) "цена" .. низкая цена на СТМ как раз не есть "достоинство" в условиях тотальной копроэкономики. Это первый и верный признак того, что архитектура УПРОЩЕНА и за это ПРИДЕТСЯ ПЛАТИТЬ программисту своим трудом. .. что и видим "сплошь и рядом" в виде "мне проще" ... ктоб спорил. :)
И тем не менее, у этого камня есть и свои достоинства .. они на самом деле там же, в тех же самых пунктах и сидят. Ибо у каждой медальки 2 стороны. ВСЕГДА.
А выбирать надо по задаче .. только и всего. :)
Широкий круг задач решается быстрее именно на меге, по той причине, что на данный момент уже существует масса однотипных решений на ней же.
Вот именно, однотипных, вариантов нет никаких, что само по себе уже убого. Варианты дают свободу действий и наилучший результат даже в сложных задачах и ситуациях.
вариантов как раз мало на СТМ, а у мег по сути конструктор камней "сделаем ровно такой, какой вам нужен" - один из девизов Атмела, ваще-то. :)
а) рыхлый и неэффективный код ..
Не подтверждается. Код определяется ядром от АРМа. Не может плохое ядро быть настолько популярным, это нонсенс.
б) плохо спроектированная периферия, требующая больших и сложных инициализаций.
Не подтверждается. Периферия просто чудесна, СТМ тут просто молодцы. А кажущаяся сложность компенсируется широкими возможностями периферии. Другое дело, что некоторым это тяжело осознать.
в) "цена" .. низкая цена на СТМ как раз не есть "достоинство" в условиях тотальной копроэкономики. Это первый и верный признак того, что архитектура УПРОЩЕНА
Архитектура чего упрощена? Ядра? Ядро чисто АРМовское! Периферии? Так вы же пару строк назад жаловались, что она сложна? В новых камнях, хотя они и дешевле, периферия более развита чем в старых. Удивлены? ))))))
вариантов как раз мало на СТМ, а у мег по сути конструктор камней "сделаем ровно такой, какой вам нужен" - один из девизов Атмела, ваще-то. :)
Не надо выдумывать того чего нет. На СТМ32 можно многие вещи сделать в нескольких вариантах. Мега такое не может, стара она для этого.
Вы так и не поняли, что уже давно не интересны со своим, чисто маркетинговым подходом .. удачи, в смысле надоели совсем. :)
Всё? Аргументы закончились, даже надуманные? Ну так и в чём премущество меги на сегодняшний день?
Только одно - мегу вы знаете, хоть как-то, а СТМ32 нет, типа совсем.
Она становится особенно ничтожной, если это не твоя проблема, правда? Т.е. я должен был лепить дополнительный стабилизатор, уповать, что оно будет правильно дергать пятивольтовые уровни, чтобы какие дполнительные плюшки получить? Как никакие? А нахрена ж тогда все это? Лишние усилия и риски, они зачем?
В волшебных снах. Все, о чем вы пишете, существует главным образом там. А с другой стороны, зачем мне надо что-то там крутить? Каков положительный выхлоп ожидается? Опять никакого? Да что же это за советы у вас такие, когда каждый раз надо напрягаться, но ничего с этого не получать?
Мож лучше вам самому туда заглянуть? А то "нахватались верхушечек" и несете лажу всякую. Нет у иара для стм8 ни модификатора, ни директивы для паковки структур. Для армов есть, а для стм8 нет. Вот так, язык тот же, разработчик тот же, но в одном случае есть, а в другом нет.
Вы прорицателем что-ли подрабатываете? Того, кто в курсе, догонит вряд ли, а членов секты пусть догоняет. Туда им и дорога.
Извиняюсь, дубль.
У вас маниакальное стремление быть правым любой ценой, но мне пофигу. Вы не умеете слушать и понять что вам говорят, но мне пофигу. Отсюда и все ваши мелочные трудности, но мне пофигу. Всё это можно списать на вашу молодость и отсутствие опыта, но мне пофигу.
И чтобы вам было более понятно, я не пользуюсь ИАРом под СТМ32, только под СТМ8, потому что мне пофигу.
Ну вот, заплакал и пошли какие-то обидки. Вы со своей сектой не можете понять элементарнейшие вещи -- не нужно делать сложно то, что можно сделать просто. Не нужно избретать велосипед, если он изобретен несчетное число раз до вас. Если есть возможность не делать лишнюю работу, ее не нужно делать. Это не просто бессмысленно, это вредно.
Опять твои слова никчемные. А факты? Со структурами ты не разобрался, с софтовым ЮАРТом тоже. Ну и кто из нас плаксивее и обидчивее? )))))))))))
Если есть возможность не делать лишнюю работу, ее не нужно делать. Это не просто бессмысленно, это вредно.
Твоя лень и есть корень зла. Не стать тебе повелителем халявы, потому что даже для этого нужно приложить какие-то усилия.
Еще, кто логичнее спросите.
Со структурами вручную пусть разбирается тот, кому заняться нечем. Я эту работу спихнул на компилятор. Вон они, структуры. Прошлой ночью на ThingSpeak повесил. Теперь, если будут еще посещать грустные мысли о том, как там у меня со структурами, можете сразу туда идти, там все в реальном времени отображается.
Что-то я не понял. Эта ветка обо мне или вам просто сказать нечего?
Что-то я не понял. Эта ветка обо мне или вам просто сказать нечего?
Это лучше у вас спросить, с первой страницы рисуетесь. То у вас СТМ32 лучше, то мега. Вы уж определитесь, если ещё в состоянии.
А у нас, чего, только истовая вера во что-то одно рулит? Нельзя так, что туда, где лучше отработает СТМ, ставить СТМ, а где мега, там мегу? И с выбором чего-то одного на всю жизнь терзаться не придется.
А вот не надо ничего выдумывать. Надо будет поставить мегу или ПИК - не вопрос, опыт имеется! И даже не скривлюсь! Только вот за последние годы ну не разу такого не понадобилось.
Так вы же, наверное, ничего не делаете, а только по форумам бегаете. Вот и не поднадобилось. Да и секта не одобрит, вы же знаете.
Полистал примеры и даташит (больше 1500 страниц!!!) на STM32F103 .. н-да. Это не "куча периферии", это .. бардак в стремлении сделать "все можно" .. в общем, остаюсь при своем мнении поста №155: каждому овощу свое место.
И место для STM32 теперь в моем понимании выглядит достаточно просто: применимо, но только там где ресурсов/периферии иных МК гарантированно не достаточно. Ибо плата за весь этот "поперечнонезависимыйбардак" - ТРУД ПРОГРАММИСТА. А он - пока ещё дорог.
Когда я несколько лет назад упомнул при сектантах, дескать, хороший камень стм32, но уж больно писанины много, так они меня чуть не покусали. :) Потом, когда я увидел их программистские каракули, я понял, что они-то себя писаниной не особо затрудняют. Пишут, как бог на душу положит. А по уму, чтобы не запутаться, не опечататься и не пропусить что-то важное, каждый регистр инициализации приходится расписывать полностью. Что-то наподобие такого:
Пока лазил в исходники, обратил внимание, что размер файла, расписывающие одни только ноги 20-пинового чипа, у меня составляет 18 килобайт. Если отбросить всякие питательные ноги и прочие резеты, то выходит больше килобайта на пин. :)
Ибо плата за весь этот "поперечнонезависимыйбардак" - ТРУД ПРОГРАММИСТА. А он - пока ещё дорог.
Чушь! На эмбедде можно заработать если сами что-то и продаёте или пишете под заказ. Для домашних поделок это вообще неприменимо. Никто а5021 за его дамашнюю поделку платить не будет, просто убийство времени, при любом МК. И не факт, что на меге это будет быстрее.
А по уму, чтобы не запутаться, не опечататься и не пропусить что-то важное, каждый регистр инициализации приходится расписывать полностью.
Чушь притянутая за уши. Пишется один раз, если надо, потом только тупо копируется.
Пока лазил в исходники, обратил внимание, что размер файла, расписывающие одни только ноги 20-пинового чипа, у меня составляет 18 килобайт. Если отбросить всякие питательные ноги и прочие резеты, то выходит больше килобайта на пин. :)
Опять чушь. Без разницы что инклюдить, своё или чужое в либах. В либах поболее будет, там много лишнего.
Это если процессор этот же. А если другой, то пишется еще раз.
То-то вы в последний раз и наинклюдили. Десять строк кода всего, половина из них не совершает никаких осмысленных действий.
Факт. На меге можно сделать "на коленке" и как раз этот форум для таких деятелей. Вы не туда попали .. :)
Факт. На меге можно сделать "на коленке"
И на ПИК можно сделать на коленке, и на СТМ8 и СТМ32, там вообще загрузчик встроенный. ))))))))
и как раз этот форум для таких деятелей. Вы не туда попали .. :)
Я в курсе.
+5 баллов! Вы уж оперделитесь или "Для домашних поделок это вообще неприменимо." или "Я в курсе" .. :)
Блин, я так и не понял, что лучше STM32 или Ардуинка?..
ардуинка. в смысле на авр. все же расписали подробно. продавцы STM понятно несогласны, но кому интересно мнение продавана.
Калаш, пишет: "Блин, я так и не понял, что лучше STM32 или Ардуинка?.."
Блин, смотря ДЛЯ ЧЕГО .. :)
Если сделать что-то простое, быстро и на коленке, да чтоб ещё и работало .. то Ардуинка.
Если простое или не очень сложное, но надо сделать чтобы ХОРОШО РАБОТАЛА (шустро, надежно, компактно и т.д. выберите 2 из 7 пунктов :) .. то берем Ардуино и пользуем нормальное ПО (Atmel студию к примеру) с применением "знающих людей"
Если надо что-то "этакое", что Ардуинка НЕ МОЖЕТ (ну там float посчитать и много, гимны исполнить или отрисовать чего на хорошем экране или видео принять и обработать онлайн) .. тогда пляшем вокруг STM32 с применением "особо знающих людей за тридорога". .. а то вовсе ищем узкозаточенный под задачу камень ну и соответственно "узкозаточенных специальных людей".
Как тут правильно высказался ssss, нет никаких причин изучать STM32 для домашних поделок "на коленке"... в чем я с ним полностью согласен.
.. ну вот так, как-то. :)
Блин, я так и не понял, что лучше STM32 или Ардуинка?..
MSP430 :-P
После краткого анализа по статьям в инете, мне показалось что MSP430 это что то среднее между AVR и STM32. В общем ни рыба ни мясо. На сегодня вообще не актуально. И IDE Arduino не поддерживается, что говорит само за себя.
Блин, я так и не понял, что лучше STM32 или Ардуинка?..
LPC4370
От ардуины инфаркт головного мозга случится.
И IDE Arduino не поддерживается, что говорит само за себя.
Да, это, конечно, веская причина, ничего не скажешь. Мотоблок IDE ардуино тоже не поддерживается, однако, люди пользуются.
IDE для MSP430 отличается от Arduino IDE главным образом цветом. Ардуина -- сине-зеленая, Энергия (IDE для MSP430) -- красная. Есть, конечно, и другие отличия, но они менее существенны.
От ардуины инфаркт головного мозга случится.
Вы 1 июля с.г. зарегистрировались на этом форуме сугубо в членовредительских целях?
Там выше я писал об интересных свойствах функций inline. Немного дополню. Применение inline в общем то для компилятора имеет рекомендательное значение. Чтоб заставить GCC не выпендриватся а точно делать inline пишем обявление вместо
inline int Fn()
так
__attribute__((always_inline)) int Fn()
Сегодня напоролся, что компилятор два вызова inline сделал как просили, а после добавления еще двух вызовов стал игнорить inline и делать обычный вызов.
Еще любопытное о подопытном. К разговору о скорости.
Захотелось мне delay_us. Ну глянул на неё - вот она
В общем все крутится командами subs и bhi. И STM32_DELAY_US_MULT - количество проходов этого цикла на 1 мксек. Смотрим на его:
# define STM32_DELAY_US_MULT (F_CPU / 6000000L)
Т.е. при F_CPU 72МГц получим STM32_DELAY_US_MULT=12 а сама команды subs+bhi выполнится за 6 тактов проца.
Не быстро, аналог для 328-го, понятно байтовый, за 4 такта.
Да никому ваш DELAY_US и даром не нужен. Это авр-задротство.
Че за бред ssss? Разговор про две ассемблерные команды subs и bhi. Как жеж торгашу обяснить что такое ассемблер.. ну это для проца как для вас ssss родной язык шоле. Единственное что проц на самом деле может понять, и к DELAY_US, ИДЕ, Ардуине и даже Си не относящееся.
Это ваш бред! С какой целью - непонятно. Что вы вообще хотите доказать? Нафик АСМ? Что вы сравниваете? Какие из этого выводы? И что это даёт в практическом применении?
Ещё раз - никому ваш DELAY_US и даром не нужен. Это авр-задротство. На СТМ8 и СТМ32 это всё решается по другому.
На СТМ8 и СТМ32 это всё решается по другому.
Спрашиваю без подкола: а как там это решается? Дело в том, что надумал поизучать STM8, заказал STM8L-Discovery, вот теперь малёха информации собираю.
Подозреваю, что любой delay можно заменить на конечный автомат на таймерах - вы об этом?
На СТМ8 и СТМ32 это всё решается по другому.
Да. Я ж и пишу, что на АВР решается за 4 такта проца, а на СТМ по другому - аж за 6 тактов.
Да. Я ж и пишу, что на АВР решается за 4 такта проца, а на СТМ по другому - аж за 6 тактов.
Ну и во сколько раз на СТМ32 это решается быстрее?
Спрашиваю без подкола: а как там это решается? Дело в том, что надумал поизучать STM8, заказал STM8L-Discovery, вот теперь малёха информации собираю.
На СТМ8Л вообще всё решается как на СТМ32. Там опэн драйн по выходу таймера можно установить, для 1-вирэ самое оно. В таймерах есть прелоад, можно простейшие протоколы легко ваять без задержек. Есть ДМА, правда полноценный канал только один. Есть нэстэд для прерываний, т.е. можно спокойно рулить двумя-тремя софтовыми протоколами одновременно. Например - 1-вирэ, софт ЮАРТ и ИР- датчик.
Из-за аппаратной специфики, на STM32 проблематично исчислять точное время выполнения последовательности команд. На x86 та же проблема, если чо.
Вообще-то я уже писал об этом, но в то время вы были увлечены обвинениями меня в полном незнании Си, отчего, видимо, не заметили.
Из-за аппаратной специфики, на STM32 проблематично исчислять точное время выполнения последовательности команд. На x86 та же проблема, если чо.
У STM32 конвеер с спекулятивными вычеслениями? Не думаю что там такая же как на х86 проблема, да и у 086 и 186 все было четко. Просто дольше у STM да и все. А учитывая что банальный for(;i;i--) раскрутится именно в такой ассемблер то неприятно. И Arhat109-2 не далек от истины что хотя STM и быстрей но не во столько как относятся тактовые частоты (72/16=4.5), а раза в полтора-два ниже, т.е быстрей в 2-3 раза.
Вообще-то я уже писал об этом.
Угу.
А откуда вообще возникло "гениальное" предположение, что производительность обязана линейно масштабироваться с частотой? Там одной скорости чтения с флеша хватит, чтобы этого не случилось никогда. Если для атмеги флеш не является тормозом, т.к. ядро у атмеги "медленное", то у STM32 ядро может работать быстрее, чем выбираться данные из флеша из-за "задумчивости" последней.
Это прописано в отдельной главе референса GCC. Я кусок оттуда уже цитировал.
И Arhat109-2 не далек от истины что хотя STM и быстрей но не во столько как относятся тактовые частоты (72/16=4.5), а раза в полтора-два ниже, т.е быстрей в 2-3 раза.
Хватит нести чушь! Есть тесты типа
http://www.eembc.org/coremark/index.php
там и смотрите,
Atmel ATmega2560 - 0.5 CoreMark/MHz ,
STM32F051C8 - 2.33 CoreMark/MHz
У меги унылое ядро и унылые команды, у СТМ32 развитое ядро и развитые команды. Всё остальное от лукавого.