a5021, Цена этой оптимизации - куча адрсного пространства занятая "битовой адресацией" портов ввода/вывода, что существенно ограничивает возможности по использованию адресного пространства в перспективе.
Какая ещё куча? Не надо ничего выдумывать <del>. Нет битбэндинга в Ф0хх!
Чем сеять национальную рознь, сделали бы лучше как этот дядя...Он пи, вроде, бы вычисляет на разных платформах. Все просто и понятно...даже мне, профану в программировании...и ни чья личность не затронута :)
Вычислительные задачи нетипичны в нашем черном деле. У автоматизации как правило вводвывод, логические операции, ветвление, а математика простая даже у самых цифровых фильтров и ПИД-ов.
И тем не менее, спасибки за приведенный кин. Жаль что не приведена ссылка на код в комментах, нет теста для Мега2560 БЕЗ вывода на экран (а он не по ДМА!), но тем не менее, что там видно?
1. 96Мгц проц MK20DX256 оказался быстрее 84Мгц DUE аж на 17.4% при выигрыше в тактовой в 14.3%, что может быть объяснено разницей в работе компилятора.
2. Посмотрев даташит, убеждемся что по набору периферии ДУЕ "делает" этот проц, что как правильно тут замечено - немаловажно. И это при несколько меньшей цене дуньки и значительно больших габаритах, что даже отражено в комментах к видео;
3. Мега2560 .. вах! ТАКОГО дифирамба этой машинке я конечно же не ожидал вот никак .. однако, имеем 34.7сек на расчет И вывод теста против 2.776сек чистого теста на 16Мгц против 96 .. даже если прикинуть что вывод на дисплей сожрал половину проца, то имеем: 96/16 = 6 * 2 = 12 раз. 34.7 / 12 = 2,89 .. то есть 8 битный проц провел рассчеты со временем .. упс, сопоставимым(!!!) с 32-х разрядными монстрами.
Собственно, что и отписал выше: "не порвет". Ибо STM32 - это худшее из 32-х битных АРМ при прочих равных (тактовой). ВАУ...
a5021, Цена этой оптимизации - куча адрсного пространства занятая "битовой адресацией" портов ввода/вывода, что существенно ограничивает возможности по использованию адресного пространства в перспективе.
И кто от этого может пострадать? В F03x из всего пространства, адресуемого 32-мя битами, хоть как-то расписана лишь примерно 1/6 часть. Остальные 5/6 значатся, как зарезервированные области, никак не используемые. На дефицитный ресурс, как-то не особо смахивает, чтобы лить крокодиловы слезы по этому поводу.
Цитата:
Как-бы "микроконтроллерам" стока не надо .. но, я хорошо помню времена, когда 16 метров оперативы х286 считалось "стока не бывает".. не так уж и давно оно було. :) То есть, в перспективе такие (ARM) процессоры - кандидаты на уход в прошлое аналогично х286, и только. Очередной "тупик" в который всех активно загоняют продаваны.. :)
Загоняют-загоняют. Чтобы сподручнее загонять было, придумали даже ARMv8, включающий, помимо прочего и 64-битную архитектуру. Беспринципные продаваны ни перед чем не останавливаются. У них хватит наглости и 128-и или 256-и битную выкатить, типа, чтобы уж точно никто в обход тупика не прорвался. В общем, не теряйте бдительности. Не дайте себя облапошить флагманам индустрии.
операции делаются тактами процессора. скорость выполнения в мкс будет зависит от частоты. любой вид платы с одной частотой скажем 16Мгц будет выполнятся за одно и тоже время и от типа платы не зависит.
как и скорость ваши липовый операций который вы видете в отладчике-редакторе.
все зависит от того сколько эта операция будет в машиином коде т.е. на сколько тактов ее интерптериуют
A5021, весь сермяжный смысел всех этих тестов в том, что 8-и битники полностью справляются со своими задачами и даже "более чем". Так что, чтобы 32-,64- или какие ишо камни их полностью выкинули с рынка, за пользование ими потребуется ДОПЛАЧИВАТЬ покупателю, да и то найдутся фанаты.
Каждый камень хорош в своей нише. И ниша 8-и битников - это задачи управления. Да, они могут и неплохо держать также нишу разного ввода-вывода при наличии ДМА. Счетные задачи им конечно же "не настолько по зубам" как процам с большей разрядностью, как за счет разрядности ТАК и за счет большей тактовой частоты, конвееризации, большего адресного пространства и т.д. Но! В задачах управления особо сложного счета нет и не предвидится.
Плохо то, что тест в кино показывает всю "ущербность" АРМ архитектуры просто воочию. Для счетных задач есть смысл присматриваться к иным вариантам, А для задач обработки видео-, и даже аудио- потоков - так и подавно.
Вот и получается "тупиковое" направление... нет ниши и достоинство АРМ только одно: унификация разработки на камнях от разных производителей. Только и всего. Это не удивительно ни разу: разработчик архитектуры = 1шт., а то что их дают производить "всем кому не лень" показывает всю "ненужность" архитектуры в целом. Хороший брульянт мало кто захочет делить с кем-то ещё. Дураков - нет. :)
1. 96Мгц проц MK20DX256 оказался быстрее 84Мгц DUE аж на 17.4% при выигрыше в тактовой в 14.3%, что может быть объяснено разницей в работе компилятора.
MK20DX256 - 72МГц М4 с ФПУ. DUE - 84МГц М3.
Цитата:
2. Посмотрев даташит, убеждемся что по набору периферии ДУЕ "делает" этот проц, что как правильно тут замечено - немаловажно. И это при несколько меньшей цене дуньки и значительно больших габаритах, что даже отражено в комментах к видео;
Да я видел в даташитах, что он на 72Мгц. Автор ролика утверждает что тест гонялся на 96Мгц, что я и взял за основу рассчета. Мне кажется автору лучше знать КАК он это делал .. написано в титрах несколько раз, так что на "ошибку" не похоже. Пересмотрите внимательнее.
Конечно же когда тестируют расчетную задачу, набор периферии не играет никакой роли. Но, мне кажется что вовсе не случайно автор ролика "запамятовал" выложить расчет БЕЗ вывода на экран для Мега2560. Что очень характерно для всех "тестовых роликов" от любителей АРМ. А когда идет сравнение с камнями заточенными под управление периферией, забывать о ней - моветон или по-просту глупость.
Как мы уже выдели ранее, ваш любимый STM32F103C8T6 так ваще обладает .. шестью дристунами на тактовой 72Мгц. Это ваще "ни в какие ворота" :) Впрочем, этот ролик подтверждает ту оценку чуть более чем полностью.
Но и AVR и АРМ - это одна и таже RISC-архитектура, не забывайте. И те и другие имеют развесистый пул регистров, и те и другие исполняют команду "за 1 такт" и те и другие имеют выделенный набор команд для доступа к памяти и те и другие (часто) имеют одну и ту же "гарвардскую" архитектуру (она не там конечно же изобретена, но пусть потешатся). Так что .. сравнение уместно - "более чем".
Конечно же когда тестируют расчетную задачу, набор периферии не играет никакой роли. Но, мне кажется что вовсе не случайно автор ролика "запамятовал" выложить расчет БЕЗ вывода на экран для Мега2560. Что очень характерно для всех "тестовых роликов" от любителей АРМ. А когда идет сравнение с камнями заточенными под управление периферией, забывать о ней - моветон или по-просту глупость.
Не надо выдавать свою глупость за чужую. )))))))))))
Цитата:
Как мы уже выдели ранее, ваш любимый STM32F103C8T6 так ваще обладает .. шестью дристунами на тактовой 72Мгц. Это ваще "ни в какие ворота" :) Впрочем, этот ролик подтверждает ту оценку чуть более чем полностью.
Может вы 28-й кадр там увидели? ))))))))))))))))
И STM32F103C8T6 ваще ни разу не мой любимый. Но если вас так рвёт от него, то завтра, если будет не лень, пойду и обязательно куплю его, дабы тыкать вас, этим неплохим в общем камнем, при каждом возможном случае и в каждой теме. ))))))))))
A5021, весь сермяжный смысел всех этих тестов в том,
Я вот, как услышал пакистанский акцент за кадром, так вера моя истовая, в необыкновенную сермяжность таких видеопроповедей, мгновенно оказалась под сильныейшим гнетом. Нет, я не то, чтобы националист какой или прочий ксенофоб, но вот к авторитету хайтек-просветителей с Ближнего Востока отношусь как-то подозрительно. Не очень им там с руки на острие науки балансировать. Местный колорит как-то не располагает, да и мешает постоянно что-то. За что ни возьмутся, все время какая-то чепуха получается.
Цитата:
что 8-и битники полностью справляются со своими задачами и даже "более чем".
Да то ли справляются, то ли не очень. Задачи-то ведь разные бывают, да и решения тоже. Часто от того, каими средствами решается та или иная задача, зависят, как комфорт разработчика, так и параметры конечного устройствам.
Краткий пример, с которым я имел дело не так давно: на вход некоего девайса поступают данные, с которыми нужно совершить некоторые действия. Данные имеют двухбайтовый формат знаковое целое, но порядок следования байтов является обратным тому, который является принятым для представления чисел на принимающей стороне (так называемая endianess). Пары байтов из входного потока надо поменять местами, а для принятого блока определенного размера посчитать контрольную сумму. Это, разумеется не весь функционал устройства, а только небольшая операция, но но чтобы не завязнуть в деталях, все прочие нюансы опускаю.
Решима подобная задача мегой? Да никаких проблем. Принимаем данные, либо сразу раскладывая в массив чередованием, либо сначала принимаем все, как есть, а потом пробегаем по всему массиву, меняя порядок для каждой пары. Закончив прием блока, скармливаем массив процедуре подсчета CRC32, и через какое-то время имеем все нужное в лучшем виде. Это один вариант.
Другое решение возможно с помощью армов, где все делается немного иначе. В наборе инструкций Thumb-2 есть специальные команды для изменения порядка следования байтов и для данной задачи имеет смысл именно их и использовать. Так инструкция REV16 "умеет" за один присест менять местами сразу четыре байта по схеме "меняем байты местами в двух 16-битных словах". Итого, там, где меге потребовалось бы выполнить пяток-другой инструкций в рамках описанной мной задачи, арму потребуется одна.
Следующая фишка -- это CRC engine, которой хоть и нет в ядре ARM, но которая часто встречается в процессорах на его основе в составе набора периферии. Правда, отношение у разных производителей к ее наличию в составе МК разное. У LPC и STM32 она обычно есть, а у SAM3X, например, нет. Работает этот движок так: в определенный регистр последовательно заталкиваем все данные, контрольную сумму которых надо посчитать, а после того, как запихнули последний байт (слово 16-бит или слово-32 бита) из этого же регистра считываем готовую контрольную сумму.
Итого, для каждых четырех байт, принимаемых устройством, в случае применения в нем процессора на базе арм, для выполнения основной части алгоритма требуется всего две инструкции -- инструкция изменения порядка следования байтов REV16 и "ходовая" инструкция STR для записи 32-битного значения в регистр CRC engine.
После настолько изящного выполнения задачи армом, на мегу можно смотреть только усиленно сдерживая скепсис. Ей потребуется не меньше десятка инструкций на изменения порядка байтов, а при софтовом вычислении контрольных сумм вообще придется говорить о сотнях. Работая на меньшей частоте, мега просто проваливается на этой задаче и никакими увещеваниями о том, что в пересчете произоводительности на мегагерц, мега чудо, как хороша, общей удручающей картины здесь не изменить.
Цитата:
Так что, чтобы 32-,64- или какие ишо камни их полностью выкинули с рынка, за пользование ими потребуется ДОПЛАЧИВАТЬ покупателю, да и то найдутся фанаты.
Тем временем, доплачивает именно покупатель, когда приобретает мегу. Мега заметно дороже при более скромных характеристиках. А вот с рынка никого выкидывать не нужно, да и вряд ли это возможно. Я уже как-то упоминал, что даже у 4-битных МК есть свой, пусть и небольшой, но устойчивый спрос.
Цитата:
Плохо то, что тест в кино показывает всю "ущербность" АРМ архитектуры просто воочию. Для счетных задач есть смысл присматриваться к иным вариантам, А для задач обработки видео-, и даже аудио- потоков - так и подавно.
Такая плАхая эта арма, что просто жить не хочется, -- утверждает пакистанский кинематограф. Только о том, что львиная часть мобильных телефонов и планшетов работают, как раз таки на армах, пакистанская киношкола что-то смолчала.
Надысь пришел с али мобильник. Средней руки китаец на процессоре Qualcomm Snapdragon 650. Так как зашла речь про армы в приложении к аудио-видео, то уместно вспомнить, что Snapdragon 650 -- это два ядра Cortex-A72 + четыре ядра Cortex-A53 + GPU в одном флаконе. Все о шестидесяти четырех битах и с частотами до 1.8ггц. Тем, что данный процессор крутит любое видео в любом разрешении, вроде, никого теперь и не удивить, но параметры видеозахвата лично меня впечатлили. Данная "ущербная ARM архитектура" умеет захватывать поток Full HD со скоростью 120FPS и 4k Ultra HD со скоростью 30FPS. После таких цифр я вообще плохо представляю, чего там еще нужно для этого аудио-видео и как можно отнестись к вашим заключениям.
Цитата:
Это не удивительно ни разу: разработчик архитектуры = 1шт., а то что их дают производить "всем кому не лень" показывает всю "ненужность" архитектуры в целом. Хороший брульянт мало кто захочет делить с кем-то ещё. Дураков - нет. :)
Это ж надо столь своеобразно понимать происходящее. Ни одному из крупных чипмейкеров никогда бы и в голову не пришло покупать лицензии у арма, т.к. почти у всех в портфолио свои микроконтроллеры. Но в какой-то момент потихоньку-потихоньку все потянулись к армам. Чего говорить, если даже японцы, которые вообще плохо принимают все иностранное и чужеродное, и те сдались. Сначала NEC объявил о переходе на армы, потом и другие посыпались. Не, какие-то у вас совсем неубедительные заключения стали получаться.
Следующая фишка -- это CRC engine...Работает этот движок так: в определенный регистр последовательно заталкиваем все данные, контрольную сумму которых надо посчитать, а после того, как запихнули последний байт (слово 16-бит или слово-32 бита) из этого же регистра считываем готовую контрольную сумму.
Всю сказку проверить нельзя, но на основе этой лажи можна можна просто игнорить.
CRC engine умеет The CRC (cyclic redundancy check) calculation unit is used to get a CRC code from a 32-bit data word and a fixed generator polynomial.
А полиномов этих одна виким знает 16-и и 32-х битных вот. А это далеко не все.
Название
Полином
Представления:[9]нормальное / реверсированное / реверсированное от обратного
Та́ктовая частота́ — частота синхронизирующих импульсов синхронной электронной схемы, то есть количество синхронизирующих тактов, поступающих извне на вход схемы за одну секунду. Обычно термин употребляется применительно к компонентам компьютерных систем. В самом первом приближении тактовая частота характеризует производительность подсистемы (процессора, памяти и пр.), то есть количество выполняемых операций в секунду. Однако системы с одной и той же тактовой частотой могут иметь различную производительность, так как на выполнение одной операции разным системам может требоваться различное количество тактов (обычно от долей такта до десятков тактов), а кроме того, системы, использующие конвейерную и параллельную обработку, могут на одних и тех же тактах выполнять одновременно несколько операций.
CRC engine умеет The CRC (cyclic redundancy check) calculation unit is used to get a CRC code from a 32-bit data word and a fixed generator polynomial.
А полиномов этих одна виким знает 16-и и 32-х битных вот. А это далеко не все.
5.2 CRC main features
• Uses CRC-32 (Ethernet) polynomial: 0x4C11DB7
X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 +X8 + X7 + X5 + X4 + X2+ X +1
• Alternatively uses a fully programmable polynomial with programmable size (7, 8, 16,
32 bits).
• Handles 8-,16-, 32-bit data size
• Programmable CRC initial value
• Single input/output 32-bit data register
• Input buffer to avoid bus stall during calculation
• CRC computation done in 4 AHB clock cycles (HCLK) for the 32-bit data size
• General-purpose 8-bit register (can be used for temporary storage)
• Reversibility option on I/O data
• Alternatively uses a fully programmable polynomial with programmable size (7, 8, 16,
Это типа в расчете что никто не поймет чего там написано, или само тупое укуреное непонимаеш чего постиш. Так я переведу. "В качестве альтернативы используется полностью программируемый многочлен с программируемым размером (7, 8, 16,32 бита)."
А "полностю програмируемый", это и без STM делается. Факт в том, что вы нихрена не в теме происходящего.
А вот те из той же доки список регистров модуля.
Там просто некуда совать "альтернативые" полиномы. Потому всю слезная история как у клиента вдруг полином случайно попал в тот единственный что есть у stm - на вокзале расказуйте, больше подадут.
Судя по всему вы оба тупо в принципе не понимаете что за полином, куда его совать и чего он разный бывает. И что вобще бывает разный.
Там просто некуда совать "альтернативые" полиномы.
Control register (CRC_CR)
Bits 4:3 POLYSIZE[1:0]: Polynomial size
These bits control the size of the polynomial.
00: 32 bit polynomial
01: 16 bit polynomial
10: 8 bit polynomial
11: 7 bit polynomial
CRC polynomial (CRC_POL)
Bits 31:0 POL[31:0]: Programmable polynomial
This register is used to write the coefficients of the polynomial to be used for CRC calculation.
If the polynomial size is less than 32-bits, the least significant bits have to be used to program the
correct value.
Я вот, как услышал пакистанский акцент за кадром, так ..
А я вообще звук не включал .. :) Да и почему Вы им отказываете в авторитете в хайтеке, когда сами же пользуетесь арабскими, а не русскими цифирьками .. да и сама "Алгебра" и математика в целом - изначальное изобретение арабов .. странно как-то. Не, я конечно понимаю, что так же как и все изобретения в компьютерной технике по большей части сделаны в СССР, как к примеру таже "гарвардская архитектура", и не удивлюсь если ваш пассаж какой-нить амер повторит. Но, это всё пиар и не больше, не ведитесь.
a5021 пишет:
Краткий пример, с которым я имел дело не так давно: ..
Почему предложено только 2 решения? Их больше .. гораздо. (Кнута на Вас нет!) :)
a5021 пишет:
Тем временем, доплачивает именно покупатель, когда приобретает мегу.
Сильно сомнительное утверждение, хотя возможно для каких-то задач и верное. В данном случае - несущественно, ибо разговор шел о "Мегу оно порвет" (ваша фраза, помните жеж) .. но тогда Вы конкретно ОТКАЗАЛИСЬ провести сравнительный тест .. и вот те на! НЕ РВЕТ ВОВСЕ, а ближе к "ОДИНАКОВО". :) Допускаю что попробовали и умолчали ..
a5021 пишет:
А вот с рынка никого выкидывать не нужно, да и вряд ли это возможно. Я уже как-то упоминал, что даже у 4-битных МК есть свой, пусть и небольшой, но устойчивый спрос.
Да, было, принято. Утверждение - снято.
a5021 пишет:
Цитата:
Плохо то, что тест в кино показывает всю "ущербность" АРМ архитектуры просто воочию. Для счетных задач есть смысл присматриваться к иным вариантам, А для задач обработки видео-, и даже аудио- потоков - так и подавно.
Такая плАхая эта арма, что просто жить не хочется, -- утверждает пакистанский кинематограф ...
О, я не слышал чего оно там утверждает, поэтому просто выложил свой анализ ролика. Плохая в том, что "худшее использование тактовой частоты" даже не в 2 раза, как утверждал Логик а во все 16 раз! Смотрите сами: (96Мгц * 4 байта/такт)/(16Мгц*1.5)=16, а имеем несущественный выигрыш при оценке занятости Меги отрисовкой в 50% .. и это ещё и не STM линейка, это "приличный" АРМ как-бы (я вам уже приводил сравнительную табличку некоторых АРМов с графиками оверклокинга в прошлый раз).
Ви правда считаете это "достижением" АРМов? :)
А то что разное дерьмо суют куда попало и не попадя .. так на то и демпинг и копроэкономика. Дерьмо как известно не тонет. Вот когда Вы мне приведете примеры применения в нормальном месте, где копроэкономика НЕ работает .. тогда и оценим. А пока, там летают и применяют совсем иные решения .. и как-то те решения подпадают под разные запреты "веников" до сих пор. Не находите "случайным"? :)
Не ведитесь на маркетинг. Хотя конечно же, и АРМам применение есть, и оно растет постепенно. Может когда-нибудь и сделают полноценный АРМ, а не копроэкономический. :) Но, сильно подозреваю что в нем от АРМ останется только "программная совместимость", а не авторы или архитектура ...
Ardubino, спор за тактовую частоту по большей части тут - бессмысленен. Это уже давно маркетинговый параметр, а не "реальный". Мы это уже разбирали в прошлом разе.
Краткие выводы: некоторые процы (ПИКи в частности) до сих пор под ним понимают "такт АЛУ", и поэтому употребляют в маркетинге "цикл", а не "такт". В АРМ архитектуре "такт" это квант внутреннего генератора после умножителя и для доступа к той же FLASH или SRAM используются такты ожидания. 1:1 оно работает на частотах НЕ выше 24Мгц., для STM32 в частности. Соответственно, маркетинговые частоты тактов надо делить на эту частоту.
Что собственно ролик и показал. Это примерно как "мегапиксели" в цифромыльницах - ни о чем.
ssss, я Вас слегка порадую. Ибо что ARM, что AVR .. это все тот же RISC, только в профиль. Поэтому одно дерьмо от другого отличается незначительно и весь этот спор - ниочем. Нет никакого смысла разбираться какой сорт дерьма лучше.
Потому что КАМЕНЬ НАДО ВЫБИРАТЬ ПОД ЗАДАЧУ, а не наоборот, тащиться от пиков, эстээмов или аврок с техассами и хитачами, и потом бегать по форумам и вопрошать "а как тут..".
RISC архитектура в целом "не айс", ибо является наследницей копроэкономики и упрощением/удешевлением всего того, что было придумано наукой как "эффективное" вычисление. Так что споры какой RISC лучше = ковыряться в сортах дерьма.
За сим, давайте закончим этот спор, ибо к теме топика он мало относится.
ssss, я Вас слегка порадую. Ибо что ARM, что AVR .. это все тот же RISC, только в профиль. Поэтому одно дерьмо от другого отличается незначительно и весь этот спор - ниочем. Нет никакого смысла разбираться какой сорт дерьма лучше.
Потому что КАМЕНЬ НАДО ВЫБИРАТЬ ПОД ЗАДАЧУ, а не наоборот, тащиться от пиков, эстээмов или аврок с техассами и хитачами, и потом бегать по форумам и вопрошать "а как тут..".
Тогда я вас огорчу, по полной. Назовите хоть одну задачу, которая чОтко под мегу. Не можете? Вот и я о том! Зато большинство современных приложений на меге уже ну ни как, даже любительских. У меня, например, вообще не стоит вопрос выбора камня под задачу, я и так знаю что и для чего, так зачем мне его выбирать, тем более что мегу я уж точно не выберу? Критерии выбора камня можете озвучить? Не можете! И никто толком не может! Есть у меги преимущества перед СТМ32? Аж никаких! Ну и какова цена вашего месседжа? Нулевая! Что вы хотели сказать? А ничего, просто хотели обозначиться с умным видом, а не получилось. Беда!
И зачем мне бегать по форумам с "а как тут.."? Я в состоянии переварить инфу от производителя самостоятельно. Так зачем мне слушать испорченный телефон от всякоразных пыонэров?
Всю сказку проверить нельзя, но на основе этой лажи можна можна просто игнорить.
Канэшн лажи! И чем меньше знаний о вопросе и ниже квалификация, тем бОльшие горы лажи повсюду мерещатся.
Цитата:
CRC engine умеет The CRC (cyclic redundancy check) calculation unit is used to get a CRC code from a 32-bit data word and a fixed generator polynomial.
А вы разуйте мозги и попробуйте смекнуть, какой бы полином заложили инженеры ST для произведения расчетов контрольных сумм, если бы у них был выбор? Неужели самый редко встречающийся и мало распространенный?
Если вы не в курсе, то для большой группы разновидностей алгоритмов подсчета CRC32 используется один и тот же полином (0x4C11DB7). Я имею ввиду ряд CRC32-ZLIB, CRC32-BZIP, CRC32-MPEG2, CRC32-IEEE, CRC32-POSIX и некоторые другие. Вам это может показаться невероятным, но разработчики в ST неожиданно логично подошли к выбору полинома -- они просто взяли тот, который "накрывает" самое большое количество вариантов возможного применения. Тем и обошлись.
Я бы вам советовал не корчить здесь из себя невпупенного эксперта по данному вопросу, а лучше подтянуть матчасть, на которой вы сходу завалились в самой простой ее части.
Цитата:
А полиномов этих одна виким знает 16-и и 32-х битных вот. А это далеко не все.
А кто-то говорил, что блок аппаратного вычисления контрольных сумм реализует все существующие и еще не придуманные алгоритмы? О чем вообще было это мощнейшее "доказательство" ?
Цитата:
Какой из них был? Как так совпало, что именно он единственный реализован в STM?
Совершенно не разбираясь в вопросе, вас ждут еще и не такие "неожиданные" отрытия.
Раз уж пошла такая тема, будто бы я по способу моего уважаемого оппонента вытаскиваю все аргументы прямо из носа вместе с козявками, могу показать ту часть алгоритма, которую я описывал, вместе с подтверждением ее работоспособности.
Вот фрагмент исходника, если кому будет интересно:
uint32_t s_crc32(uint32_t s[]) { // calculate checksum of data block
RCC->AHBENR |= RCC_AHBENR_CRCEN; // gate clock to CRC engine
CRC->CR = CRC_CR_RESET; // reset CRC engine state
for (uint32_t i = 0; i < S_CHUNK_SIZE; i++) { // for every byte of block
*(uint8_t*)&CRC->DR = s[i]; // put it to CRC engine
}
uint32_t res = CRC->DR; // get CRC32
RCC->AHBENR &= ~RCC_AHBENR_CRCEN; // disable clock to CRC engine
return res; // return CRC32
}
bool get_chunk(void) { // get & verify block of data
sDataTypeDef sBuf; // the buffer for incoming data
uint32_t sCRC32 = 0;
if (!fetch_block((uint8_t*)&sBuf)) { // get new block of data
return false; // break if error
}
sCRC32 = s_crc32((uint32_t*)&sBuf); // calc checksum of received block
if (sCRC32 != SDATA->CRC32) { // compare checksums
if (!write_flash((uint16_t *) &sBuf, sizeof(sBuf) / 2)) { // store data to flash
nvStatus &= ~S_CHUNK_AVAILABLE; // reset availability flag
return false; // break in case of error
}
}
nvStatus |= S_CHUNK_AVAILABLE; // set data availability flag
return true; // return success
}
Вот оно же в работе:
Готов представить все дополнительные доказательства, если этого кому-то покажется мало.
Отдельно отмечу для особо-догадливых на случай, если их внезапно "озарит", что это только-что придуманный код для отмазки. Положение слайдера прокрутки исходного текста стоит на середине некоторого файла, чей объем несколько больший, чем две простые процедуры, полностью помещающиеся на одном экране. Также в окне сборки присутствуют данные об объеме двоичного кода, полученного в результате компиляции. Разумеется, это не является полностью неотразимым доказательством, но как-бы намекает.
Так у вас и задач как таковых нет акромя "продать". Выясняли уже. :) Впрочем как и с критериями, преимуществами и классами задач тоже уже выясняли. У Вас память "короткая", видимо динамическая с недостаточным временем обновления.
Плохая в том, что "худшее использование тактовой частоты" даже не в 2 раза, как утверждал Логик а во все 16 раз! Смотрите сами: (96Мгц * 4 байта/такт)/(16Мгц*1.5)=16, а имеем несущественный выигрыш при оценке занятости Меги отрисовкой в 50% .. и это ещё и не STM линейка, это "приличный" АРМ как-бы (я вам уже приводил сравнительную табличку некоторых АРМов с графиками оверклокинга в прошлый раз).
Какова ценность абстрактного понятия "использования частоты" для конечного потребителя (вариант -- разработчика) ? Мне вот как-то абсолютно по барабану, что и как оно там внутри себя использует. Меня интересуют только удобство применения и показатели производительности. Если камень "А" работает на частоте 1мгц и показывает производительность только на 75% меньшую, чем камень "Б", работающий на одном террагерце, то при прочих равных я предпочту последнего, даже если большую часть тактов он тупо пропускает разинув рот, а только по каждому сотому или тысячному клоку выполняет какое-либо осмысленное действие. Кому могут быть интересны виртуальные характеристики, которые в конечные потребительские свойства не конвертируются?
Цитата:
Ви правда считаете это "достижением" АРМов? :)
Вряд ли кого-нибудь интересует, что считаю именно я. Однако тот факт, что какая-то невразумительная фирмешка, сидящая хрен пойми на каком острове, подмяла под себя флагманов индустрии во всем мире, заставляет задуматься, а так ли уж плохи ее решения, что не самые последние мозги хайтека толкаются в очереди для покупки лицензий.
Любому здравомыслящему человеку, разумеется, ясно, что лучше бы контроллеры делались на открытой архитектуре, по стандартам, не ограниенным авторским правом, но имеем, что имеем и горевать по этому поводу нет особого смысла.
Цитата:
А то что разное дерьмо суют куда попало и не попадя .. так на то и демпинг и копроэкономика. Дерьмо как известно не тонет. Вот когда Вы мне приведете примеры применения в нормальном месте, где копроэкономика НЕ работает .. тогда и оценим.
Мне нет никакого смысла изображать из себя адвоката армов, т.к. я никаким образом не афилирован с ними и ни в каких отношениях не состою с их продуцией, кроме потребительских. Даже захоти я поверить в искренность ваших доводов, мне исключительно сложно будет подтвердить их своим наблюдениями и/или опытом. Посему, уважая ваше мнение, позволю себе не согласиться и остаться при своем.
Так у вас и задач как таковых нет акромя "продать". Выясняли уже. :)
Давайте выясним. Или проясним, как вам будет угодно.
Простая задача - с десяток или больше ДС18Б20, дисплей, от простого семисегментника в режиме бегущей строки до ТФТ с хорошим разрешением, попутно ЮАРТ, кнопки, ИК-управление... ну сами ещё чего придумайте. Берём копеечный СТМ32Ф0, юзаем таймер и ДМА, получаем хардварный 1-вирэ. Хардварный, Карл! Пофигу работа другой периферии, она никак ни на что не влияет! Вытаскиваем данные каждого датчика и запихиваем всё скопом, вместе с байтом контрольной суммы, в модуль КРК на борту МК. Получили ноль? Данные верны. Нет? Считаем их неверными. Дальше. Завязываем другой таймер, получаем хардварное ИК-управление. Дальше. берём ещё таймер и привязываем ТФТ. Скорость при заливке одним цветом 24МГц даже при параллельной шине. Можно сделать и 48МГц, но не каждый дисплей такое выдержит. Что имеем в результате? Комплекс хардварных решений которые абсолютно прозрачны и не мешают друг-другу. Не надо вкл.-выкл. прерывания, думать "а успеет ли?" там что-то. Т.е. вся задача сведена к минимуму - перетаскивать данные по флагам из одного хардварного модуля в другой, т.е. тупо рулить потоками готовых данных. Что может предложить мега в подобном случае? А ничего! Слаба она и немощна!
Цитата:
Впрочем как и с критериями, преимуществами и классами задач тоже уже выясняли. У Вас память "короткая", видимо динамическая с недостаточным временем обновления.
У меня голова не мусорный ящик, чтобы запихивать туда всякое дерьмо от АВР и Микрочипа, чтобы переживать "а получится ли?", "а влезет ли?". Но если уж сильно надо будет - не вопрос! Запулим и на ПИК-АВР, это ж как на велике кататься. Только зачем мне велик, если есть автомобиль?
подумай своего головой что такое такт что такое частота.
Да нет у меня никакой особой нужды тут о чем-то усиленно раздумывать. Понятия простые, давно известные.
Цитата:
и как может процессор сделать больше одной операции за такт если такт и есть частота обработки одной операции .
Да очень просто. Концепция суперскалярной архитектуры предусматривает выполнение нескольких инструкций одновременно в течение единственного такта. Из тех, что на слуху, к суперскалярным процессорам относятся, x86, ARM и прочие MIPS-ы.
Простая задача - с десяток или больше ДС18Б20, дисплей, от простого семисегментника в режиме бегущей строки до ТФТ с хорошим разрешением, попутно ЮАРТ, кнопки, ИК-управление... ну сами ещё чего придумайте. Берём копеечный СТМ32Ф0, юзаем таймер и ДМА, получаем хардварный 1-вирэ. Хардварный, Карл! Пофигу работа другой периферии, она никак ни на что не влияет! Вытаскиваем данные каждого датчика и запихиваем всё скопом, вместе с байтом контрольной суммы, в модуль КРК на борту МК. Получили ноль? Данные верны. Нет? Считаем их неверными. Дальше. Завязываем другой таймер, получаем хардварное ИК-управление. Дальше. берём ещё таймер и привязываем ТФТ. Скорость при заливке одним цветом 24МГц даже при параллельной шине. Можно сделать и 48МГц, но не каждый дисплей такое выдержит. Что имеем в результате?
В результате ты описал мой контроллер аквариума, только забыл RTC, 8 расширения вывода на 595 с шимом (2 из них под сервы, 4 свет - шим понятно несколько разный), пару штук аналоговых датчиков на протечку. И попутал отдельных вместо кнопок - кнопки на тачскрине тачскрин на TFT 320x240 c GUI многооконыім. Температуру правда с 3-х ds снимаю, но то не существенно, в цикле и массиве индекс с 3 на 10 поменять. Фотки ищи в проектах. Давно сделано на минипро, т.е. 328p. Еще килобайта 3 памяти свободны на развитие.
[quote=ssss]
Что может предложить мега в подобном случае? А ничего! Слаба она и немощна!
[quote]
Наверно мега не хуже минипро. Так что слаба не она, а ты, причем головой.
И снова CRC... Даже уже не знаю как обяснять, последний раз пробую, на картинках и даташетов на STM и DS. Красненьким. Видиш - разные. Не сойдутся они. Заодно и структуру модуля, видиш - написано какой используется, где здесь другие.
В результате ты описал мой контроллер аквариума, только забыл RTC, 8 расширения вывода на 595 с шимом (2 из них под сервы, 4 свет - шим понятно несколько разный), пару штук аналоговых датчиков на протечку. И попутал отдельных вместо кнопок - кнопки на тачскрине тачскрин на TFT 320x240 c GUI многооконыім. Температуру правда с 3-х ds снимаю, но то не существенно, в цикле и массиве индекс с 3 на 10 поменять. Фотки ищи в проектах. Давно сделано на минипро, т.е. 328p. Еще килобайта 3 памяти свободны на развитие.
На какое развитие? Там и так всё на грани фола. )))))))))))))))))))))))
Цитата:
Наверно мега не хуже минипро.
Да куда уже хуже меги.
Цитата:
И снова CRC... Даже уже не знаю как обяснять, последний раз пробую, на картинках и даташетов на STM и DS. Красненьким. Видиш - разные. Не сойдутся они.
Не сойдутся где? В твоих мозгах? Это твои проблемы. Есть референс, есть апнота, есть примеры для КРК-8. Читай, не ленись, развивайся!
Можно я тоже про порванный. Uno и stm32f103c8. Одинаковая программа на Си. Uno - 4 такта STM-6 тактов. Всё как по даташиту. Реальный тест. Один канал UNO - Второй STM - Угадайте какой где.
На что вы там ещё надеетесь? У меги всё убогое - убогое ядро, убогая периферия, убогие команды. Если хотите просто быстро подрыгать ногами, ставьте ПИК, не ошибётесь
Охотно допускаю. Только не "уже", а "вообще" или "совсем". И раз уж не знаете, то и не лезьте. Для вас же лучше будет.
Цитата:
последний раз пробую, на картинках и даташетов на STM и DS. Красненьким. Видиш - разные.
Чёйта разные? Очень даже одинаковые. Кресты так вообще один в один. Циферок, конечно, где побольше, где поменьше, но так на то они и разные контрольные суммы, чтобы циферкам одинаковыми не быть.
Цитата:
Не сойдутся они.
А где-это им надо сходиться и почему именно не сойдутся? Мож наоборот, так сходиться-расходиться начнут, что и не остановить будет. Вобщем, загадками говорите.
Цитата:
Поведайте, что вы видите на этих картинках? У вас не возникает ощущение, что там вы наблюдаете новые ворота?
Тебе, уроду, я сколько раз писал, шоб со своими вопросами сразу нахер в гугол валил. Твои чмошные манеры игнорировать вопросы собеседников и постить простыни бреда иного не заслужывают. Если тебе с эсесовцем похер по какому полиному формирует CRC устройство, ответ от которого проверяется так и мне похер, про вас все ясно. Заниматся просвещением тупых - не мой профиль.
/**
* @brief Main program.
* @param None
* @retval None
*/
int main(void)
{
/*!< At this stage the microcontroller clock setting is already configured,
this is done through SystemInit() function which is called from startup
file (startup_stm32f0xx.s) before to branch to application main.
To reconfigure the default setting of SystemInit() function, refer to
system_stm32f0xx.c file
*/
/* Initialize LEDs available on STM32072B-EVAL board */
STM_EVAL_LEDInit(LED1);
STM_EVAL_LEDInit(LED3);
/* Configure the CRC peripheral to use the polynomial x8 + x7 + x6 + x4 + x2 + 1 */
CRC_Config(0xD5);
/* Compute the CRC value of the 8-bit buffer: CRCBuffer */
ComputedCRC = CRC_8BitsCompute(CRCBuffer, BUFFER_SIZE);
/* Check if the computed CRC matches the expected one */
if (ComputedCRC != ExpectedCRC)
{
/* Turn on LD3 */
STM_EVAL_LEDOn(LED3);
}
else
{
/* Turn on LD1 */
STM_EVAL_LEDOn(LED1);
}
/* Set the polynomial coefficients */
CRC_SetPolynomial(poly);
}
/**
* @brief Compute CRC value for input message
* @param data: pointer at uint8_t
* @param size: the size of the input message
* @retval The computed CRC value
*/
static uint8_t CRC_8BitsCompute(uint8_t* data, uint32_t size)
{
uint8_t* dataEnd = data+size;
/* Reset CRC data register to avoid overlap when computing new data stream */
CRC_ResetDR();
while(data < dataEnd)
{
/* Write the input data in the CRC data register */
CRC_CalcCRC8bits(*data++);
}
/* Return the CRC value */
return (uint8_t)CRC_GetCRC();
}
#ifdef USE_FULL_ASSERT
/**
* @brief Reports the name of the source file and the source line number
* where the assert_param error has occurred.
* @param file: pointer to the source file name
* @param line: assert_param error line source number
* @retval None
*/
void assert_failed(uint8_t* file, uint32_t line)
{
/* User can add his own implementation to report the file name and line number,
ex: printf("Wrong parameters value: file %s on line %d\r\n", file, line) */
/* Infinite loop */
while (1)
{
}
}
#endif
/**
* @}
*/
/**
* @}
*/
/************************ (C) COPYRIGHT STMicroelectronics *****END OF FILE****/
Тебе, уроду, я сколько раз писал, шоб со своими вопросами сразу нахер в гугол валил.
Вряд ли "гугол" мне ответит, какие видения вас посещают, когда вы наблюдаете техническую документацию. От того и вынужден к вам обращаться.
Цитата:
Если тебе с эсесовцем похер по какому полиному формирует CRC устройство, ответ от которого проверяется так и мне похер, про вас все ясно.
Это с чего вы заключили, что "похер по какому полиному" ? Мне вот точно не похер. Я этим пользуюсь. Как оно работает я вам вроде уже рассказывал. Выдержками из референса вас вроде тоже снабдили. Вместо того, чтобы поблагодарить, в ответ вы начали какую-то мазню выкладывать, с причитаниями, что где-то у вас там что-то не сходится. Потому и не сходится, что не понимаете ни пол-байта во всем этом. Теперь вот истерику вперемешку с оскорблениями закатили, будто это чем-то вам помочь может.
Цитата:
Заниматся просвещением тупых - не мой профиль.
Как-то я не заметил, чтобы вы кого-то здесь просвещали. Только выкатываете какие-то дикие обвинения, да жалуетесь, что у вас ничего не сходится. Удивительное здесь в том, что вы похоже свято верите, что раз у вас не сходится, то и ни у кого не сходится. Ну не сходится, так пусть не сходится. Видимо у вас карма такая.
ssss пишет:
* @file CRC/CRC_8BitsCRCMessage/main.c
Ну и нахрена сюда всякую бурду постить, да еще и с CRC8-DVBS2, а не с CRC8-DALLAS? Че, он по этой портянке разберется, как полином формируется? Так и будет вопить бред всякий, что у него строка с крестами плашмя в регистр не пролезает, сам себя убеждая, будто тупых просвещает.
Я не модератор .. но знаю что сюда заходят детишки и мне несколько стыдно как за свое прошлое, так и за некоторых местных "активистов".
P.S. Уже подумываю, не накатать ли бота, который прошерстит форум (а он мне - нравится) и прочистит его сам ..
a5021, Цена этой оптимизации - куча адрсного пространства занятая "битовой адресацией" портов ввода/вывода, что существенно ограничивает возможности по использованию адресного пространства в перспективе.
Какая ещё куча? Не надо ничего выдумывать <del>. Нет битбэндинга в Ф0хх!
Чем сеять национальную рознь, сделали бы лучше как этот дядя...Он пи, вроде, бы вычисляет на разных платформах. Все просто и понятно...даже мне, профану в программировании...и ни чья личность не затронута :)
https://www.youtube.com/watch?v=rkIfsYRshRQ
<del>
Он пи, вроде, бы вычисляет на разных платформах.
Вычислительные задачи нетипичны в нашем черном деле. У автоматизации как правило вводвывод, логические операции, ветвление, а математика простая даже у самых цифровых фильтров и ПИД-ов.
<del>
И тем не менее, спасибки за приведенный кин. Жаль что не приведена ссылка на код в комментах, нет теста для Мега2560 БЕЗ вывода на экран (а он не по ДМА!), но тем не менее, что там видно?
1. 96Мгц проц MK20DX256 оказался быстрее 84Мгц DUE аж на 17.4% при выигрыше в тактовой в 14.3%, что может быть объяснено разницей в работе компилятора.
2. Посмотрев даташит, убеждемся что по набору периферии ДУЕ "делает" этот проц, что как правильно тут замечено - немаловажно. И это при несколько меньшей цене дуньки и значительно больших габаритах, что даже отражено в комментах к видео;
3. Мега2560 .. вах! ТАКОГО дифирамба этой машинке я конечно же не ожидал вот никак .. однако, имеем 34.7сек на расчет И вывод теста против 2.776сек чистого теста на 16Мгц против 96 .. даже если прикинуть что вывод на дисплей сожрал половину проца, то имеем: 96/16 = 6 * 2 = 12 раз. 34.7 / 12 = 2,89 .. то есть 8 битный проц провел рассчеты со временем .. упс, сопоставимым(!!!) с 32-х разрядными монстрами.
Собственно, что и отписал выше: "не порвет". Ибо STM32 - это худшее из 32-х битных АРМ при прочих равных (тактовой). ВАУ...
Та да! ПИК16Ф84 ваще их всех уделает! )
<del>
И кто от этого может пострадать? В F03x из всего пространства, адресуемого 32-мя битами, хоть как-то расписана лишь примерно 1/6 часть. Остальные 5/6 значатся, как зарезервированные области, никак не используемые. На дефицитный ресурс, как-то не особо смахивает, чтобы лить крокодиловы слезы по этому поводу.
Загоняют-загоняют. Чтобы сподручнее загонять было, придумали даже ARMv8, включающий, помимо прочего и 64-битную архитектуру. Беспринципные продаваны ни перед чем не останавливаются. У них хватит наглости и 128-и или 256-и битную выкатить, типа, чтобы уж точно никто в обход тупика не прорвался. В общем, не теряйте бдительности. Не дайте себя облапошить флагманам индустрии.
че вы диспут развели на пустом месте а :)
операции делаются тактами процессора. скорость выполнения в мкс будет зависит от частоты. любой вид платы с одной частотой скажем 16Мгц будет выполнятся за одно и тоже время и от типа платы не зависит.
как и скорость ваши липовый операций который вы видете в отладчике-редакторе.
все зависит от того сколько эта операция будет в машиином коде т.е. на сколько тактов ее интерптериуют
<del>
A5021, весь сермяжный смысел всех этих тестов в том, что 8-и битники полностью справляются со своими задачами и даже "более чем". Так что, чтобы 32-,64- или какие ишо камни их полностью выкинули с рынка, за пользование ими потребуется ДОПЛАЧИВАТЬ покупателю, да и то найдутся фанаты.
Каждый камень хорош в своей нише. И ниша 8-и битников - это задачи управления. Да, они могут и неплохо держать также нишу разного ввода-вывода при наличии ДМА. Счетные задачи им конечно же "не настолько по зубам" как процам с большей разрядностью, как за счет разрядности ТАК и за счет большей тактовой частоты, конвееризации, большего адресного пространства и т.д. Но! В задачах управления особо сложного счета нет и не предвидится.
Плохо то, что тест в кино показывает всю "ущербность" АРМ архитектуры просто воочию. Для счетных задач есть смысл присматриваться к иным вариантам, А для задач обработки видео-, и даже аудио- потоков - так и подавно.
Вот и получается "тупиковое" направление... нет ниши и достоинство АРМ только одно: унификация разработки на камнях от разных производителей. Только и всего. Это не удивительно ни разу: разработчик архитектуры = 1шт., а то что их дают производить "всем кому не лень" показывает всю "ненужность" архитектуры в целом. Хороший брульянт мало кто захочет делить с кем-то ещё. Дураков - нет. :)
arDubino, о.. это "диспут" уже годовой давности .. :)
1. 96Мгц проц MK20DX256 оказался быстрее 84Мгц DUE аж на 17.4% при выигрыше в тактовой в 14.3%, что может быть объяснено разницей в работе компилятора.
MK20DX256 - 72МГц М4 с ФПУ. DUE - 84МГц М3.
2. Посмотрев даташит, убеждемся что по набору периферии ДУЕ "делает" этот проц, что как правильно тут замечено - немаловажно. И это при несколько меньшей цене дуньки и значительно больших габаритах, что даже отражено в комментах к видео;
Когда считают число 3,14, набор периферии ...
Да я видел в даташитах, что он на 72Мгц. Автор ролика утверждает что тест гонялся на 96Мгц, что я и взял за основу рассчета. Мне кажется автору лучше знать КАК он это делал .. написано в титрах несколько раз, так что на "ошибку" не похоже. Пересмотрите внимательнее.
Конечно же когда тестируют расчетную задачу, набор периферии не играет никакой роли. Но, мне кажется что вовсе не случайно автор ролика "запамятовал" выложить расчет БЕЗ вывода на экран для Мега2560. Что очень характерно для всех "тестовых роликов" от любителей АРМ. А когда идет сравнение с камнями заточенными под управление периферией, забывать о ней - моветон или по-просту глупость.
Как мы уже выдели ранее, ваш любимый STM32F103C8T6 так ваще обладает .. шестью дристунами на тактовой 72Мгц. Это ваще "ни в какие ворота" :) Впрочем, этот ролик подтверждает ту оценку чуть более чем полностью.
еще один кипятильщик.
скорость работы будет от многих факторов
скорость частота процессора
скорость обмена с памятью и частота работы памяти, есть ли буфер обмена
шина биты и частота
и какой ввод вывод сколько бит параллельно или последовательно и т.п.
Конечно так.
Но и AVR и АРМ - это одна и таже RISC-архитектура, не забывайте. И те и другие имеют развесистый пул регистров, и те и другие исполняют команду "за 1 такт" и те и другие имеют выделенный набор команд для доступа к памяти и те и другие (часто) имеют одну и ту же "гарвардскую" архитектуру (она не там конечно же изобретена, но пусть потешатся). Так что .. сравнение уместно - "более чем".
Интеловскому Core i7-6950Х, с его 106 инструкциями за такт, это расскажите. Скажите, чтобы не выпендривался и выполнял, как все, не более одной.
Конечно же когда тестируют расчетную задачу, набор периферии не играет никакой роли. Но, мне кажется что вовсе не случайно автор ролика "запамятовал" выложить расчет БЕЗ вывода на экран для Мега2560. Что очень характерно для всех "тестовых роликов" от любителей АРМ. А когда идет сравнение с камнями заточенными под управление периферией, забывать о ней - моветон или по-просту глупость.
Не надо выдавать свою глупость за чужую. )))))))))))
Как мы уже выдели ранее, ваш любимый STM32F103C8T6 так ваще обладает .. шестью дристунами на тактовой 72Мгц. Это ваще "ни в какие ворота" :) Впрочем, этот ролик подтверждает ту оценку чуть более чем полностью.
Может вы 28-й кадр там увидели? ))))))))))))))))
И STM32F103C8T6 ваще ни разу не мой любимый. Но если вас так рвёт от него, то завтра, если будет не лень, пойду и обязательно куплю его, дабы тыкать вас, этим неплохим в общем камнем, при каждом возможном случае и в каждой теме. ))))))))))
Запасайтесь валидолом! )))))))))))
Интеловскому Core i7-6950Х, с его 106 инструкциями за такт, это расскажите. Скажите, чтобы не выпендривался и выполнял, как все, не более одной.
зачем так бредить то а.
читай про то сколько там в нем ядер. процессор это уже не процессор надо смотреть архитектуру.
Я вот, как услышал пакистанский акцент за кадром, так вера моя истовая, в необыкновенную сермяжность таких видеопроповедей, мгновенно оказалась под сильныейшим гнетом. Нет, я не то, чтобы националист какой или прочий ксенофоб, но вот к авторитету хайтек-просветителей с Ближнего Востока отношусь как-то подозрительно. Не очень им там с руки на острие науки балансировать. Местный колорит как-то не располагает, да и мешает постоянно что-то. За что ни возьмутся, все время какая-то чепуха получается.
Да то ли справляются, то ли не очень. Задачи-то ведь разные бывают, да и решения тоже. Часто от того, каими средствами решается та или иная задача, зависят, как комфорт разработчика, так и параметры конечного устройствам.
Краткий пример, с которым я имел дело не так давно: на вход некоего девайса поступают данные, с которыми нужно совершить некоторые действия. Данные имеют двухбайтовый формат знаковое целое, но порядок следования байтов является обратным тому, который является принятым для представления чисел на принимающей стороне (так называемая endianess). Пары байтов из входного потока надо поменять местами, а для принятого блока определенного размера посчитать контрольную сумму. Это, разумеется не весь функционал устройства, а только небольшая операция, но но чтобы не завязнуть в деталях, все прочие нюансы опускаю.
Решима подобная задача мегой? Да никаких проблем. Принимаем данные, либо сразу раскладывая в массив чередованием, либо сначала принимаем все, как есть, а потом пробегаем по всему массиву, меняя порядок для каждой пары. Закончив прием блока, скармливаем массив процедуре подсчета CRC32, и через какое-то время имеем все нужное в лучшем виде. Это один вариант.
Другое решение возможно с помощью армов, где все делается немного иначе. В наборе инструкций Thumb-2 есть специальные команды для изменения порядка следования байтов и для данной задачи имеет смысл именно их и использовать. Так инструкция REV16 "умеет" за один присест менять местами сразу четыре байта по схеме "меняем байты местами в двух 16-битных словах". Итого, там, где меге потребовалось бы выполнить пяток-другой инструкций в рамках описанной мной задачи, арму потребуется одна.
Следующая фишка -- это CRC engine, которой хоть и нет в ядре ARM, но которая часто встречается в процессорах на его основе в составе набора периферии. Правда, отношение у разных производителей к ее наличию в составе МК разное. У LPC и STM32 она обычно есть, а у SAM3X, например, нет. Работает этот движок так: в определенный регистр последовательно заталкиваем все данные, контрольную сумму которых надо посчитать, а после того, как запихнули последний байт (слово 16-бит или слово-32 бита) из этого же регистра считываем готовую контрольную сумму.
Итого, для каждых четырех байт, принимаемых устройством, в случае применения в нем процессора на базе арм, для выполнения основной части алгоритма требуется всего две инструкции -- инструкция изменения порядка следования байтов REV16 и "ходовая" инструкция STR для записи 32-битного значения в регистр CRC engine.
После настолько изящного выполнения задачи армом, на мегу можно смотреть только усиленно сдерживая скепсис. Ей потребуется не меньше десятка инструкций на изменения порядка байтов, а при софтовом вычислении контрольных сумм вообще придется говорить о сотнях. Работая на меньшей частоте, мега просто проваливается на этой задаче и никакими увещеваниями о том, что в пересчете произоводительности на мегагерц, мега чудо, как хороша, общей удручающей картины здесь не изменить.
Тем временем, доплачивает именно покупатель, когда приобретает мегу. Мега заметно дороже при более скромных характеристиках. А вот с рынка никого выкидывать не нужно, да и вряд ли это возможно. Я уже как-то упоминал, что даже у 4-битных МК есть свой, пусть и небольшой, но устойчивый спрос.
Такая плАхая эта арма, что просто жить не хочется, -- утверждает пакистанский кинематограф. Только о том, что львиная часть мобильных телефонов и планшетов работают, как раз таки на армах, пакистанская киношкола что-то смолчала.
Надысь пришел с али мобильник. Средней руки китаец на процессоре Qualcomm Snapdragon 650. Так как зашла речь про армы в приложении к аудио-видео, то уместно вспомнить, что Snapdragon 650 -- это два ядра Cortex-A72 + четыре ядра Cortex-A53 + GPU в одном флаконе. Все о шестидесяти четырех битах и с частотами до 1.8ггц. Тем, что данный процессор крутит любое видео в любом разрешении, вроде, никого теперь и не удивить, но параметры видеозахвата лично меня впечатлили. Данная "ущербная ARM архитектура" умеет захватывать поток Full HD со скоростью 120FPS и 4k Ultra HD со скоростью 30FPS. После таких цифр я вообще плохо представляю, чего там еще нужно для этого аудио-видео и как можно отнестись к вашим заключениям.
Это ж надо столь своеобразно понимать происходящее. Ни одному из крупных чипмейкеров никогда бы и в голову не пришло покупать лицензии у арма, т.к. почти у всех в портфолио свои микроконтроллеры. Но в какой-то момент потихоньку-потихоньку все потянулись к армам. Чего говорить, если даже японцы, которые вообще плохо принимают все иностранное и чужеродное, и те сдались. Сначала NEC объявил о переходе на армы, потом и другие посыпались. Не, какие-то у вас совсем неубедительные заключения стали получаться.
Неушта 106 ядер?
Про "процессор это уже не процессор" -- мысль, конечно, глубокая, но что-то вы про архитектуру раньше ничего не говорили и куда смотреть не указывали.
<del>
Неушта 106 ядер?
Про "процессор это уже не процессор" -- мысль, конечно, глубокая, но что-то вы про архитектуру раньше ничего не говорили и куда смотреть не указывали.
:))) ты просто жжешь.
подумай своего головой что такое такт что такое частота.
и как может процессор сделать больше одной операции за такт если такт и есть частота обработки одной операции .
она так и называется ТАКТОВАЯ ЧАСТОТА процессора
Следующая фишка -- это CRC engine...Работает этот движок так: в определенный регистр последовательно заталкиваем все данные, контрольную сумму которых надо посчитать, а после того, как запихнули последний байт (слово 16-бит или слово-32 бита) из этого же регистра считываем готовую контрольную сумму.
Всю сказку проверить нельзя, но на основе этой лажи можна можна просто игнорить.
CRC engine умеет The CRC (cyclic redundancy check) calculation unit is used to get a CRC code from a 32-bit data word and a fixed generator polynomial.
А полиномов этих одна виким знает 16-и и 32-х битных вот. А это далеко не все.
Какой из них был? Как так совпало, что именно он единственный реализован в STM?
<del>
Та́ктовая частота́ — частота синхронизирующих импульсов синхронной электронной схемы, то есть количество синхронизирующих тактов, поступающих извне на вход схемы за одну секунду. Обычно термин употребляется применительно к компонентам компьютерных систем. В самом первом приближении тактовая частота характеризует производительность подсистемы (процессора, памяти и пр.), то есть количество выполняемых операций в секунду. Однако системы с одной и той же тактовой частотой могут иметь различную производительность, так как на выполнение одной операции разным системам может требоваться различное количество тактов (обычно от долей такта до десятков тактов), а кроме того, системы, использующие конвейерную и параллельную обработку, могут на одних и тех же тактах выполнять одновременно несколько операций.
CRC engine умеет The CRC (cyclic redundancy check) calculation unit is used to get a CRC code from a 32-bit data word and a fixed generator polynomial.
А полиномов этих одна виким знает 16-и и 32-х битных вот. А это далеко не все.
5.2 CRC main features
• Uses CRC-32 (Ethernet) polynomial: 0x4C11DB7
X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 +X8 + X7 + X5 + X4 + X2+ X +1
• Alternatively uses a fully programmable polynomial with programmable size (7, 8, 16,
32 bits).
• Handles 8-,16-, 32-bit data size
• Programmable CRC initial value
• Single input/output 32-bit data register
• Input buffer to avoid bus stall during calculation
• CRC computation done in 4 AHB clock cycles (HCLK) for the 32-bit data size
• General-purpose 8-bit register (can be used for temporary storage)
• Reversibility option on I/O data
• Alternatively uses a fully programmable polynomial with programmable size (7, 8, 16,
Это типа в расчете что никто не поймет чего там написано, или само тупое укуреное непонимаеш чего постиш. Так я переведу. "В качестве альтернативы используется полностью программируемый многочлен с программируемым размером (7, 8, 16,32 бита)."
А "полностю програмируемый", это и без STM делается. Факт в том, что вы нихрена не в теме происходящего.
А вот те из той же доки список регистров модуля.
Там просто некуда совать "альтернативые" полиномы. Потому всю слезная история как у клиента вдруг полином случайно попал в тот единственный что есть у stm - на вокзале расказуйте, больше подадут.
Судя по всему вы оба тупо в принципе не понимаете что за полином, куда его совать и чего он разный бывает. И что вобще бывает разный.
Там просто некуда совать "альтернативые" полиномы.
Control register (CRC_CR)
Bits 4:3 POLYSIZE[1:0]: Polynomial size
These bits control the size of the polynomial.
00: 32 bit polynomial
01: 16 bit polynomial
10: 8 bit polynomial
11: 7 bit polynomial
CRC polynomial (CRC_POL)
Bits 31:0 POL[31:0]: Programmable polynomial
This register is used to write the coefficients of the polynomial to be used for CRC calculation.
If the polynomial size is less than 32-bits, the least significant bits have to be used to program the
correct value.
А я вообще звук не включал .. :) Да и почему Вы им отказываете в авторитете в хайтеке, когда сами же пользуетесь арабскими, а не русскими цифирьками .. да и сама "Алгебра" и математика в целом - изначальное изобретение арабов .. странно как-то. Не, я конечно понимаю, что так же как и все изобретения в компьютерной технике по большей части сделаны в СССР, как к примеру таже "гарвардская архитектура", и не удивлюсь если ваш пассаж какой-нить амер повторит. Но, это всё пиар и не больше, не ведитесь.
Почему предложено только 2 решения? Их больше .. гораздо. (Кнута на Вас нет!) :)
Сильно сомнительное утверждение, хотя возможно для каких-то задач и верное. В данном случае - несущественно, ибо разговор шел о "Мегу оно порвет" (ваша фраза, помните жеж) .. но тогда Вы конкретно ОТКАЗАЛИСЬ провести сравнительный тест .. и вот те на! НЕ РВЕТ ВОВСЕ, а ближе к "ОДИНАКОВО". :) Допускаю что попробовали и умолчали ..
Да, было, принято. Утверждение - снято.
О, я не слышал чего оно там утверждает, поэтому просто выложил свой анализ ролика. Плохая в том, что "худшее использование тактовой частоты" даже не в 2 раза, как утверждал Логик а во все 16 раз! Смотрите сами: (96Мгц * 4 байта/такт)/(16Мгц*1.5)=16, а имеем несущественный выигрыш при оценке занятости Меги отрисовкой в 50% .. и это ещё и не STM линейка, это "приличный" АРМ как-бы (я вам уже приводил сравнительную табличку некоторых АРМов с графиками оверклокинга в прошлый раз).
Ви правда считаете это "достижением" АРМов? :)
А то что разное дерьмо суют куда попало и не попадя .. так на то и демпинг и копроэкономика. Дерьмо как известно не тонет. Вот когда Вы мне приведете примеры применения в нормальном месте, где копроэкономика НЕ работает .. тогда и оценим. А пока, там летают и применяют совсем иные решения .. и как-то те решения подпадают под разные запреты "веников" до сих пор. Не находите "случайным"? :)
Не ведитесь на маркетинг. Хотя конечно же, и АРМам применение есть, и оно растет постепенно. Может когда-нибудь и сделают полноценный АРМ, а не копроэкономический. :) Но, сильно подозреваю что в нем от АРМ останется только "программная совместимость", а не авторы или архитектура ...
Ardubino, спор за тактовую частоту по большей части тут - бессмысленен. Это уже давно маркетинговый параметр, а не "реальный". Мы это уже разбирали в прошлом разе.
Краткие выводы: некоторые процы (ПИКи в частности) до сих пор под ним понимают "такт АЛУ", и поэтому употребляют в маркетинге "цикл", а не "такт". В АРМ архитектуре "такт" это квант внутреннего генератора после умножителя и для доступа к той же FLASH или SRAM используются такты ожидания. 1:1 оно работает на частотах НЕ выше 24Мгц., для STM32 в частности. Соответственно, маркетинговые частоты тактов надо делить на эту частоту.
Что собственно ролик и показал. Это примерно как "мегапиксели" в цифромыльницах - ни о чем.
ssss, я Вас слегка порадую. Ибо что ARM, что AVR .. это все тот же RISC, только в профиль. Поэтому одно дерьмо от другого отличается незначительно и весь этот спор - ниочем. Нет никакого смысла разбираться какой сорт дерьма лучше.
Потому что КАМЕНЬ НАДО ВЫБИРАТЬ ПОД ЗАДАЧУ, а не наоборот, тащиться от пиков, эстээмов или аврок с техассами и хитачами, и потом бегать по форумам и вопрошать "а как тут..".
RISC архитектура в целом "не айс", ибо является наследницей копроэкономики и упрощением/удешевлением всего того, что было придумано наукой как "эффективное" вычисление. Так что споры какой RISC лучше = ковыряться в сортах дерьма.
За сим, давайте закончим этот спор, ибо к теме топика он мало относится.
ssss, я Вас слегка порадую. Ибо что ARM, что AVR .. это все тот же RISC, только в профиль. Поэтому одно дерьмо от другого отличается незначительно и весь этот спор - ниочем. Нет никакого смысла разбираться какой сорт дерьма лучше.
Потому что КАМЕНЬ НАДО ВЫБИРАТЬ ПОД ЗАДАЧУ, а не наоборот, тащиться от пиков, эстээмов или аврок с техассами и хитачами, и потом бегать по форумам и вопрошать "а как тут..".
Тогда я вас огорчу, по полной. Назовите хоть одну задачу, которая чОтко под мегу. Не можете? Вот и я о том! Зато большинство современных приложений на меге уже ну ни как, даже любительских. У меня, например, вообще не стоит вопрос выбора камня под задачу, я и так знаю что и для чего, так зачем мне его выбирать, тем более что мегу я уж точно не выберу? Критерии выбора камня можете озвучить? Не можете! И никто толком не может! Есть у меги преимущества перед СТМ32? Аж никаких! Ну и какова цена вашего месседжа? Нулевая! Что вы хотели сказать? А ничего, просто хотели обозначиться с умным видом, а не получилось. Беда!
И зачем мне бегать по форумам с "а как тут.."? Я в состоянии переварить инфу от производителя самостоятельно. Так зачем мне слушать испорченный телефон от всякоразных пыонэров?
Канэшн лажи! И чем меньше знаний о вопросе и ниже квалификация, тем бОльшие горы лажи повсюду мерещатся.
А вы разуйте мозги и попробуйте смекнуть, какой бы полином заложили инженеры ST для произведения расчетов контрольных сумм, если бы у них был выбор? Неужели самый редко встречающийся и мало распространенный?
Если вы не в курсе, то для большой группы разновидностей алгоритмов подсчета CRC32 используется один и тот же полином (0x4C11DB7). Я имею ввиду ряд CRC32-ZLIB, CRC32-BZIP, CRC32-MPEG2, CRC32-IEEE, CRC32-POSIX и некоторые другие. Вам это может показаться невероятным, но разработчики в ST неожиданно логично подошли к выбору полинома -- они просто взяли тот, который "накрывает" самое большое количество вариантов возможного применения. Тем и обошлись.
Я бы вам советовал не корчить здесь из себя невпупенного эксперта по данному вопросу, а лучше подтянуть матчасть, на которой вы сходу завалились в самой простой ее части.
А кто-то говорил, что блок аппаратного вычисления контрольных сумм реализует все существующие и еще не придуманные алгоритмы? О чем вообще было это мощнейшее "доказательство" ?
Совершенно не разбираясь в вопросе, вас ждут еще и не такие "неожиданные" отрытия.
Раз уж пошла такая тема, будто бы я по способу моего уважаемого оппонента вытаскиваю все аргументы прямо из носа вместе с козявками, могу показать ту часть алгоритма, которую я описывал, вместе с подтверждением ее работоспособности.
Вот фрагмент исходника, если кому будет интересно:
uint32_t s_crc32(uint32_t s[]) { // calculate checksum of data block RCC->AHBENR |= RCC_AHBENR_CRCEN; // gate clock to CRC engine CRC->CR = CRC_CR_RESET; // reset CRC engine state for (uint32_t i = 0; i < S_CHUNK_SIZE; i++) { // for every byte of block *(uint8_t*)&CRC->DR = s[i]; // put it to CRC engine } uint32_t res = CRC->DR; // get CRC32 RCC->AHBENR &= ~RCC_AHBENR_CRCEN; // disable clock to CRC engine return res; // return CRC32 } bool get_chunk(void) { // get & verify block of data sDataTypeDef sBuf; // the buffer for incoming data uint32_t sCRC32 = 0; if (!fetch_block((uint8_t*)&sBuf)) { // get new block of data return false; // break if error } sCRC32 = s_crc32((uint32_t*)&sBuf); // calc checksum of received block if (sCRC32 != SDATA->CRC32) { // compare checksums if (!write_flash((uint16_t *) &sBuf, sizeof(sBuf) / 2)) { // store data to flash nvStatus &= ~S_CHUNK_AVAILABLE; // reset availability flag return false; // break in case of error } } nvStatus |= S_CHUNK_AVAILABLE; // set data availability flag return true; // return success }Вот оно же в работе:
Готов представить все дополнительные доказательства, если этого кому-то покажется мало.
Отдельно отмечу для особо-догадливых на случай, если их внезапно "озарит", что это только-что придуманный код для отмазки. Положение слайдера прокрутки исходного текста стоит на середине некоторого файла, чей объем несколько больший, чем две простые процедуры, полностью помещающиеся на одном экране. Также в окне сборки присутствуют данные об объеме двоичного кода, полученного в результате компиляции. Разумеется, это не является полностью неотразимым доказательством, но как-бы намекает.
Так у вас и задач как таковых нет акромя "продать". Выясняли уже. :) Впрочем как и с критериями, преимуществами и классами задач тоже уже выясняли. У Вас память "короткая", видимо динамическая с недостаточным временем обновления.
Какова ценность абстрактного понятия "использования частоты" для конечного потребителя (вариант -- разработчика) ? Мне вот как-то абсолютно по барабану, что и как оно там внутри себя использует. Меня интересуют только удобство применения и показатели производительности. Если камень "А" работает на частоте 1мгц и показывает производительность только на 75% меньшую, чем камень "Б", работающий на одном террагерце, то при прочих равных я предпочту последнего, даже если большую часть тактов он тупо пропускает разинув рот, а только по каждому сотому или тысячному клоку выполняет какое-либо осмысленное действие. Кому могут быть интересны виртуальные характеристики, которые в конечные потребительские свойства не конвертируются?
Вряд ли кого-нибудь интересует, что считаю именно я. Однако тот факт, что какая-то невразумительная фирмешка, сидящая хрен пойми на каком острове, подмяла под себя флагманов индустрии во всем мире, заставляет задуматься, а так ли уж плохи ее решения, что не самые последние мозги хайтека толкаются в очереди для покупки лицензий.
Любому здравомыслящему человеку, разумеется, ясно, что лучше бы контроллеры делались на открытой архитектуре, по стандартам, не ограниенным авторским правом, но имеем, что имеем и горевать по этому поводу нет особого смысла.
Мне нет никакого смысла изображать из себя адвоката армов, т.к. я никаким образом не афилирован с ними и ни в каких отношениях не состою с их продуцией, кроме потребительских. Даже захоти я поверить в искренность ваших доводов, мне исключительно сложно будет подтвердить их своим наблюдениями и/или опытом. Посему, уважая ваше мнение, позволю себе не согласиться и остаться при своем.
Да, ещё раз предлагаю закрыть холиварный вопрос.
Так у вас и задач как таковых нет акромя "продать". Выясняли уже. :)
Давайте выясним. Или проясним, как вам будет угодно.
Простая задача - с десяток или больше ДС18Б20, дисплей, от простого семисегментника в режиме бегущей строки до ТФТ с хорошим разрешением, попутно ЮАРТ, кнопки, ИК-управление... ну сами ещё чего придумайте. Берём копеечный СТМ32Ф0, юзаем таймер и ДМА, получаем хардварный 1-вирэ. Хардварный, Карл! Пофигу работа другой периферии, она никак ни на что не влияет! Вытаскиваем данные каждого датчика и запихиваем всё скопом, вместе с байтом контрольной суммы, в модуль КРК на борту МК. Получили ноль? Данные верны. Нет? Считаем их неверными. Дальше. Завязываем другой таймер, получаем хардварное ИК-управление. Дальше. берём ещё таймер и привязываем ТФТ. Скорость при заливке одним цветом 24МГц даже при параллельной шине. Можно сделать и 48МГц, но не каждый дисплей такое выдержит. Что имеем в результате? Комплекс хардварных решений которые абсолютно прозрачны и не мешают друг-другу. Не надо вкл.-выкл. прерывания, думать "а успеет ли?" там что-то. Т.е. вся задача сведена к минимуму - перетаскивать данные по флагам из одного хардварного модуля в другой, т.е. тупо рулить потоками готовых данных. Что может предложить мега в подобном случае? А ничего! Слаба она и немощна!
Впрочем как и с критериями, преимуществами и классами задач тоже уже выясняли. У Вас память "короткая", видимо динамическая с недостаточным временем обновления.
У меня голова не мусорный ящик, чтобы запихивать туда всякое дерьмо от АВР и Микрочипа, чтобы переживать "а получится ли?", "а влезет ли?". Но если уж сильно надо будет - не вопрос! Запулим и на ПИК-АВР, это ж как на велике кататься. Только зачем мне велик, если есть автомобиль?
Да, ещё раз предлагаю закрыть холиварный вопрос.
Так вы же сами его постоянно и поднимаете!
Да нет у меня никакой особой нужды тут о чем-то усиленно раздумывать. Понятия простые, давно известные.
Да очень просто. Концепция суперскалярной архитектуры предусматривает выполнение нескольких инструкций одновременно в течение единственного такта. Из тех, что на слуху, к суперскалярным процессорам относятся, x86, ARM и прочие MIPS-ы.
Простая задача - с десяток или больше ДС18Б20, дисплей, от простого семисегментника в режиме бегущей строки до ТФТ с хорошим разрешением, попутно ЮАРТ, кнопки, ИК-управление... ну сами ещё чего придумайте. Берём копеечный СТМ32Ф0, юзаем таймер и ДМА, получаем хардварный 1-вирэ. Хардварный, Карл! Пофигу работа другой периферии, она никак ни на что не влияет! Вытаскиваем данные каждого датчика и запихиваем всё скопом, вместе с байтом контрольной суммы, в модуль КРК на борту МК. Получили ноль? Данные верны. Нет? Считаем их неверными. Дальше. Завязываем другой таймер, получаем хардварное ИК-управление. Дальше. берём ещё таймер и привязываем ТФТ. Скорость при заливке одним цветом 24МГц даже при параллельной шине. Можно сделать и 48МГц, но не каждый дисплей такое выдержит. Что имеем в результате?
В результате ты описал мой контроллер аквариума, только забыл RTC, 8 расширения вывода на 595 с шимом (2 из них под сервы, 4 свет - шим понятно несколько разный), пару штук аналоговых датчиков на протечку. И попутал отдельных вместо кнопок - кнопки на тачскрине тачскрин на TFT 320x240 c GUI многооконыім. Температуру правда с 3-х ds снимаю, но то не существенно, в цикле и массиве индекс с 3 на 10 поменять. Фотки ищи в проектах. Давно сделано на минипро, т.е. 328p. Еще килобайта 3 памяти свободны на развитие.
[quote=ssss]
Что может предложить мега в подобном случае? А ничего! Слаба она и немощна!
[quote]
Наверно мега не хуже минипро. Так что слаба не она, а ты, причем головой.
И снова CRC... Даже уже не знаю как обяснять, последний раз пробую, на картинках и даташетов на STM и DS. Красненьким. Видиш - разные. Не сойдутся они. Заодно и структуру модуля, видиш - написано какой используется, где здесь другие.
НУ И НАХРЕНА ТУТ ПОСТИТЬ 32бит систему. любой дурак и так может посчитать сколько там адресов может быть.
В результате ты описал мой контроллер аквариума, только забыл RTC, 8 расширения вывода на 595 с шимом (2 из них под сервы, 4 свет - шим понятно несколько разный), пару штук аналоговых датчиков на протечку. И попутал отдельных вместо кнопок - кнопки на тачскрине тачскрин на TFT 320x240 c GUI многооконыім. Температуру правда с 3-х ds снимаю, но то не существенно, в цикле и массиве индекс с 3 на 10 поменять. Фотки ищи в проектах. Давно сделано на минипро, т.е. 328p. Еще килобайта 3 памяти свободны на развитие.
На какое развитие? Там и так всё на грани фола. )))))))))))))))))))))))
Наверно мега не хуже минипро.
Да куда уже хуже меги.
И снова CRC... Даже уже не знаю как обяснять, последний раз пробую, на картинках и даташетов на STM и DS. Красненьким. Видиш - разные. Не сойдутся они.
Не сойдутся где? В твоих мозгах? Это твои проблемы. Есть референс, есть апнота, есть примеры для КРК-8. Читай, не ленись, развивайся!
Можно я тоже про порванный. Uno и stm32f103c8. Одинаковая программа на Си. Uno - 4 такта STM-6 тактов. Всё как по даташиту. Реальный тест. Один канал UNO - Второй STM - Угадайте какой где.
Один канал UNO - Второй STM - Угадайте какой где.
Угу! "Но я вам её не покажу!"(с). )))))))))))
Дэцэльский сад! )))))))))))))))
На что вы там ещё надеетесь? У меги всё убогое - убогое ядро, убогая периферия, убогие команды. Если хотите просто быстро подрыгать ногами, ставьте ПИК, не ошибётесь
У меги всё убогое - убогое ядро, убогая периферия, убогие команды. Если хотите просто быстро подрыгать ногами, ставьте ПИК, не ошибётесь
если у меги всё убогое, то объясни, каким образом это всё убогое разорвало тебе задницу на свастику?
Охотно допускаю. Только не "уже", а "вообще" или "совсем". И раз уж не знаете, то и не лезьте. Для вас же лучше будет.
Чёйта разные? Очень даже одинаковые. Кресты так вообще один в один. Циферок, конечно, где побольше, где поменьше, но так на то они и разные контрольные суммы, чтобы циферкам одинаковыми не быть.
А где-это им надо сходиться и почему именно не сойдутся? Мож наоборот, так сходиться-расходиться начнут, что и не остановить будет. Вобщем, загадками говорите.
Поведайте, что вы видите на этих картинках? У вас не возникает ощущение, что там вы наблюдаете новые ворота?
Тебе, уроду, я сколько раз писал, шоб со своими вопросами сразу нахер в гугол валил. Твои чмошные манеры игнорировать вопросы собеседников и постить простыни бреда иного не заслужывают. Если тебе с эсесовцем похер по какому полиному формирует CRC устройство, ответ от которого проверяется так и мне похер, про вас все ясно. Заниматся просвещением тупых - не мой профиль.
Ой-ой-ой, какие мы нежные и сопливые! Не знаю чего ты на a5021 взъелся, но я же тебе отписал где рыть-копать. Не веришь? Любуйся!
/**
******************************************************************************
* @file CRC/CRC_8BitsCRCMessage/main.c
* @author MCD Application Team
* @version V1.4.0
* @date 24-July-2014
* @brief Main program body
******************************************************************************
* @attention
*
* <h2><center>© COPYRIGHT 2014 STMicroelectronics</center></h2>
*
* Licensed under MCD-ST Liberty SW License Agreement V2, (the "License");
* You may not use this file except in compliance with the License.
* You may obtain a copy of the License at:
*
* http://www.st.com/software_license_agreement_liberty_v2
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
******************************************************************************
*/
/* Includes ------------------------------------------------------------------*/
#include "main.h"
/** @addtogroup STM32F0xx_StdPeriph_Examples
* @{
*/
/** @addtogroup CRC_8BitsCRCMessage
* @{
*/
/* Private typedef -----------------------------------------------------------*/
/* Private define ------------------------------------------------------------*/
#define countof(a) (uint8_t)(sizeof(a) / sizeof(*(a)))
#define BUFFER_SIZE (countof(CRCBuffer) - 1)
/* Private macro -------------------------------------------------------------*/
/* Private variables ---------------------------------------------------------*/
uint8_t CRCBuffer[] = "STM32F0xx CortexM0 Device running on STM32072B-EVAL";
uint8_t ComputedCRC = 0;
uint8_t ExpectedCRC = 0xAF; /* The expected CRC value of CRCBuffer using the
polynomial x8 + x7 + x6 + x4 + x2 + 1.
This value is already computed using on-line CRC tool */
/* Private function prototypes -----------------------------------------------*/
static void CRC_Config(uint8_t poly);
static uint8_t CRC_8BitsCompute(uint8_t* data, uint32_t size);
/* Private functions ---------------------------------------------------------*/
/**
* @brief Main program.
* @param None
* @retval None
*/
int main(void)
{
/*!< At this stage the microcontroller clock setting is already configured,
this is done through SystemInit() function which is called from startup
file (startup_stm32f0xx.s) before to branch to application main.
To reconfigure the default setting of SystemInit() function, refer to
system_stm32f0xx.c file
*/
/* Initialize LEDs available on STM32072B-EVAL board */
STM_EVAL_LEDInit(LED1);
STM_EVAL_LEDInit(LED3);
/* Configure the CRC peripheral to use the polynomial x8 + x7 + x6 + x4 + x2 + 1 */
CRC_Config(0xD5);
/* Compute the CRC value of the 8-bit buffer: CRCBuffer */
ComputedCRC = CRC_8BitsCompute(CRCBuffer, BUFFER_SIZE);
/* Check if the computed CRC matches the expected one */
if (ComputedCRC != ExpectedCRC)
{
/* Turn on LD3 */
STM_EVAL_LEDOn(LED3);
}
else
{
/* Turn on LD1 */
STM_EVAL_LEDOn(LED1);
}
/* Infinite loop */
while(1)
{
}
}
/**
* @brief Configure CRC peripheral to use 8-bit polynomials
* @param poly: the CRC polynomial
* @retval None
*/
static void CRC_Config(uint8_t poly)
{
/* Enable CRC AHB clock interface */
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_CRC, ENABLE);
/* DeInit CRC peripheral */
CRC_DeInit();
/* Init the INIT register */
CRC_SetInitRegister(0);
/* Select 8-bit polynomial size */
CRC_PolynomialSizeSelect(CRC_PolSize_8);
/* Set the polynomial coefficients */
CRC_SetPolynomial(poly);
}
/**
* @brief Compute CRC value for input message
* @param data: pointer at uint8_t
* @param size: the size of the input message
* @retval The computed CRC value
*/
static uint8_t CRC_8BitsCompute(uint8_t* data, uint32_t size)
{
uint8_t* dataEnd = data+size;
/* Reset CRC data register to avoid overlap when computing new data stream */
CRC_ResetDR();
while(data < dataEnd)
{
/* Write the input data in the CRC data register */
CRC_CalcCRC8bits(*data++);
}
/* Return the CRC value */
return (uint8_t)CRC_GetCRC();
}
#ifdef USE_FULL_ASSERT
/**
* @brief Reports the name of the source file and the source line number
* where the assert_param error has occurred.
* @param file: pointer to the source file name
* @param line: assert_param error line source number
* @retval None
*/
void assert_failed(uint8_t* file, uint32_t line)
{
/* User can add his own implementation to report the file name and line number,
ex: printf("Wrong parameters value: file %s on line %d\r\n", file, line) */
/* Infinite loop */
while (1)
{
}
}
#endif
/**
* @}
*/
/**
* @}
*/
/************************ (C) COPYRIGHT STMicroelectronics *****END OF FILE****/
Что опять не так?
Вряд ли "гугол" мне ответит, какие видения вас посещают, когда вы наблюдаете техническую документацию. От того и вынужден к вам обращаться.
Это с чего вы заключили, что "похер по какому полиному" ? Мне вот точно не похер. Я этим пользуюсь. Как оно работает я вам вроде уже рассказывал. Выдержками из референса вас вроде тоже снабдили. Вместо того, чтобы поблагодарить, в ответ вы начали какую-то мазню выкладывать, с причитаниями, что где-то у вас там что-то не сходится. Потому и не сходится, что не понимаете ни пол-байта во всем этом. Теперь вот истерику вперемешку с оскорблениями закатили, будто это чем-то вам помочь может.
Как-то я не заметил, чтобы вы кого-то здесь просвещали. Только выкатываете какие-то дикие обвинения, да жалуетесь, что у вас ничего не сходится. Удивительное здесь в том, что вы похоже свято верите, что раз у вас не сходится, то и ни у кого не сходится. Ну не сходится, так пусть не сходится. Видимо у вас карма такая.
Ну и нахрена сюда всякую бурду постить, да еще и с CRC8-DVBS2, а не с CRC8-DALLAS? Че, он по этой портянке разберется, как полином формируется? Так и будет вопить бред всякий, что у него строка с крестами плашмя в регистр не пролезает, сам себя убеждая, будто тупых просвещает.