Объясните на предмет АЦП из портов

Satyr

[uquote="linuxdude",url="/forum/viewtopic.php?p=3308486#p3308486"]Кстати вроде в каких-то китайских клонах STM32 флеха оформленная отдельным кристаллом быстрее работает. На уровне физики флеха - массив полевиков с изолированным затвором, где заряд "пойман", при чтении определяется открыт полевик из-за заряда пойманного в затворе или нет.[/uquote]
Это может иметь экономический эффект при очень большом флеше. Иначе на корпусировке проиграешь.
Если есть флеш - пластины идут по другому тех процессу с дополнительным слоем. если флеша не присутвует - он не нужен. Наличие флеша - сразу плюс деньги на всю пластину.
А больше всего по площади в современных MPU занимает кеш.

Поэтому много кеша и флеш одновременно на одном кристалле практически не увидишь. Если делаются какие то гибриды где и ядро с кешом, и флеш есть - всегда бутерброд чип над чипом.

Реклама

linuxdude

Это может иметь экономический эффект при очень большом флеше. Иначе на корпусировке проиграешь.

Это китайский парадокс - продают multi-chip package клоны даже дешевле оригинала. Это они так F103 клонировали, кто-то вскрывал, оказался отдельный чип флеша. У китайцев судя по всему нет доступных техпроцессов позволяющих флеш с процом паковать в 1 кристалл. Вот они и склонировали как умели, с дискретной флехой в том же корпусе.

А что до кэша - обычно это SRAM, место на кристалле жрет. Зато ускоряет хорошо. Чем больше кэш тем больше кода в него уместится и тем чаще он будет срабатывать. Что может дать очень сильный эффект. Гонял как-то сжатие на скорость и сдуру распаковывал 1 блок 20 раз в одно назначение. Случился cache hit, я получил космические скорости. Ускорение относительно крейсерской скорости - раз в пять! В моем случае это обманка, но есть много случаев когда это хорошо работает. Что до флеша - флеш на сильно быстрые чипы не любят ставить может быть еще и потому что они довольно горячие. При нагреве флеш начинает утекать намного быстрее. Если флеш хорошенько прожарить - он вообще сотрется. Я пару раз случайно проверял, не понравилось :\.

А что до разрядности - упс, я тупанул и подумал что на порту будут все состояния меняться. А как бы не так, не будут.

Реклама

Satyr

[uquote="linuxdude",url="/forum/viewtopic.php?p=3308644#p3308644"]Это китайский парадокс - продают multi-chip package клоны даже дешевле оригинала. Это они так F103 клонировали, кто-то вскрывал, оказался отдельный чип флеша. У китайцев судя по всему нет доступных техпроцессов позволяющих флеш с процом паковать в 1 кристалл. Вот они и склонировали как умели, с дискретной флехой в том же корпусе.[/uquote]
Не забывай, что у китайцев всякие ручные и нестандартные этапы в производстве стоят намного меньше, чем у именитых производителей.
Там, где какому нибудь интелу всю систему менять, эти посадят пару сотен китайцев с микроскопами и приспособами -))
А конкретно с F103 - может у них просто есть поставщик готовых совершенно копеечных флешовых кристаллов.

[uquote="linuxdude",url="/forum/viewtopic.php?p=3308644#p3308644"]А что до кэша - обычно это SRAM, место на кристалле жрет.[/uquote]
Ячейки те же самые. А всякая разводка, топология, обвызяки - выборка там площадь в разы от регулярного СРАМа раздвувают.

[uquote="linuxdude",url="/forum/viewtopic.php?p=3308644#p3308644"]Зато ускоряет хорошо. Чем больше кэш тем больше кода в него уместится и тем чаще он будет срабатывать.[/uquote]
SDRAM без кеша совсем бесполезен. Там в 10 раз падение скорости - не рекорд. Сдрам по сути пакетный и латентность дикая. Ессно без кеша MPU уж десяток-другой лет просто не найдешь.

linuxdude

[uquote="Satyr",url="/forum/viewtopic.php?p=3308680#p3308680"]Не забывай, что у китайцев всякие ручные и нестандартные этапы в производстве стоят намного меньше, чем у именитых производителей.[/uquote]
Представил себе картину - китайцы вручную multi-chip делают

. На самом деле западные производители местами подзажрались и встряска им не повредит. Ti например вдарился в откровенный overengineering. Наворачивая какие-то нафигнужности которые систему и bring-up усложнают в разы а ценных качеств, например, проиводительности - не добавляют. В результате геморроя много, толку мало. Наверное так делать чипы все-же не надо и поделом что вынесло из кучи сегментов. Ну вот честно, какой-нибудь IOMMU в таком чипе лучше всего справляется с задачей вытрахивания мозга системщикам. А так по жизни он нафиг не нужен в подобных чипах. Ну то-есть при переклине на DRM конечно можно бояться что контент сопрут не только с экрана но и откуда там еще сдампят. Но столько траха ради столь незначительной цели - себя не очень оправдывает. Юзер за 2 минуты наставит фотоаппарат и положит на все эти IOMMU... свой объектив.

Там, где какому нибудь интелу всю систему менять, эти посадят пару сотен китайцев с микроскопами и приспособами -))

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

А конкретно с F103 - может у них просто есть поставщик готовых совершенно копеечных флешовых кристаллов.

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

Ячейки те же самые. А всякая разводка, топология, обвызяки - выборка там площадь в разы от регулярного СРАМа раздвувают.

Ну да, поэтому влезает несколько мегов как максимум а кристалла расходуется огого.

SDRAM без кеша совсем бесполезен. Там в 10 раз падение скорости - не рекорд. Сдрам по сути пакетный и латентность дикая. Ессно без кеша MPU уж десяток-другой лет просто не найдешь.

Я выключал кэш на старых компьютерах. Так пентиум становился примерно 286. И программы от борланда переставали валиться с runtime error 200...

Реклама

Satyr

Многоуровневый кеш - это от безысходности, как компромисс. С SRAMом не сравниться.
Могу показать интересную статистику. Алгоритм один и тот же (ГОСТ ессно -)) ), далее показатель в попугаях приведенных на Мгц

кортексы разные:
M3 - 42
M4 - 44.5
M7 - 139 !!!
A5 - 111
A8 - 116

M7 кроме того что ядро офигенное (там и по ТТХ АРМовскому DMIPS/Mhz круче любый 32битных 'A'), код в флеше за нормальным L1 кешем, в качестве оперативки SRAM.
Последние 2 с L1/L2 кешом и DDR2 на 1/2 и 1/3 частотах ядра соотв.

Реклама

Ivanoff-iv писал(а):8 ног - 9 состояний

да будет тебе известно, что у 8 ног 256 состояний...

Реклама

linuxdude

[uquote="Satyr",url="/forum/viewtopic.php?p=3309063#p3309063"]Многоуровневый кеш - это от безысходности, как компромисс. С SRAMом не сравниться.[/uquote]
Увы, прогресс в скорости работы процессоров обогнал прогресс в улучшении памяти. Это уже давно так и в ближайшем времени кажется так и останется. Поэтому извращаются с кэшами, программисты греют мозги неочевидными вещами, которые явно или не контролируются или если все же контролируются, оказывается что это большая дыра в безопасности.

Могу показать интересную статистику. Алгоритм один и тот же (ГОСТ ессно -)) ), далее показатель в попугаях приведенных на Мгц

И правда, интересная статистика. Жаль что по алгоритму который мне никогда не понадобится. Насколько эти соотношения зависят от конкретного алгоритма? А также компилера и оптимизаций. Ну и подборка ядер у вас специфичная все-таки.

Я поприкалывался с чем-то таким но только на M3, с кодом ReedSolomon (сперт с порта известной либы RS на DSPic), кодируя пакет (223,255) и посмотрел на дефолтном 8MHz везде 0WS, из флеша
- Что будет с -O0, -O2, -O3 и -Os. На предмет размер кода vs скорость.
- Все то же самое но набор команд m0
- Два варианта компилеров - arm-eabi-none и armhf (как ни странно он оказался ок для m3, хоть там и нет никакой плавучки, было интересно прокатит ли, прокатило). Конечно же оба gcc.

Потом я задолбался из-за комбинаторики. Если будет не лень - посмотрю RAM vs ROM vs wait states на предмет скоростей, потому что соотношения более-менее уловил

. Запуск кода m0 на m3 не совсем репрезентативен, но настоящего m0 у меня под рукой не было, только m3 всех мастей и направлений.

Общие идеи - даже злой уровень O3 не так уж сильно раздувает код, зато работает на 30-40% быстрее чем size-optimized. Сборка без оптимизации не рулит. O2 хороший компромисс по скорости (почти как O3) при том что код распуает меньше.

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

M7 кроме того что ядро офигенное (там и по ТТХ АРМовскому DMIPS/Mhz круче любый 32битных 'A'), код в флеше за нормальным L1 кешем, в качестве оперативки SRAM. Последние 2 с L1/L2 кешом и DDR2 на 1/2 и 1/3 частотах ядра соотв.

Говоря за себя - мне его такой просто некуда девать. От микроконтроллера мне столько не надо, а для линукса у меня и покруче штуки есть. Где вся система в сборе чего доброго стоит меньше чем один такой микроконтроль.

Satyr

у меня все одним компилятором с одинаковыми настройками.
ну кроме A8 - там под линуксом, а не на голом железе. и компилер не IAR, а GNU
На голом и IARе поди было бы повеселей чем
A5 - 111
A8 - 116

GNU мутный. я даже забивал ему реальную длину строки кеша, там и такое есть. видимо для выравнивания данных. но лучший вариант достигался при вдвое меньшем значении, чем длина на самом деле. Так же как автовекторизация под NEON давала резкое торможение. Ну и еще ряд похожих фокусов -)

Добавлено after 1 minute 29 seconds:
[uquote="linuxdude",url="/forum/viewtopic.php?p=3309520#p3309520"]И правда, интересная статистика. Жаль что по алгоритму который мне никогда не понадобится. Насколько эти соотношения зависят от конкретного алгоритма?[/uquote]
Это уже было не шифрование, а ЭЦП. Считай целочисленная математика с длинными числами. Восновном умножения и сложения, средней интенсивности работа с таблицам

linuxdude

у меня все одним компилятором с одинаковыми настройками.

А набор команд при этом какой? Наилучший для конкретного процессора?

На голом и IARе поди было бы повеселей чем

Вилами по воде писано. Если gcc уделять столько же внимания сколько другим - в скоростной либе сжатия LZ4 gcc возьми и сделай вьюжлстудию, фаны которой годами рассказывали про оптимизации. Там автор играл честно и уперся выжать максимум из всех. В таких условиях gcc студию сделал и никто так и не придумал как студией его побить. Зато потом народ придумал как еще от 0 до 15% отыграть можно на вообще всем, автор и сделал. Коллективный разум штука крутая.

GNU мутный. я даже забивал ему реальную длину строки кеша, там и такое есть. видимо для выравнивания данных. но лучший вариант достигался при вдвое меньшем значении, чем длина на самом деле. Так же как автовекторизация под NEON давала резкое торможение. Ну и еще ряд похожих фокусов -)

Да обычный он. Насчет автовекторизации ничего не скажу, кому neon нужен обычно фигачат simd intrinsics в явном виде, выглядит более удачной идеей. Это не gcc-специфично даже, их понимают несколько компилеров (за IAR не скажу). Скорее процессоро-специфично: код соберется только если у target есть из чего изобразить запрошенные simd операции. Это весьма явное указание, компилер не может сильно дурить. Так сейчас наворачивают оптимизации в видеокодеках и прочем. Еще у GCC кроме safe оптимизациий есть unsafe. Они могут довольно весело все разогнать, если програмер готов к некоторым ограничениям и более параноидальной проверке работы кода. Это опасная бритва, можно порезаться. Но я себе несколько программ критичных к скорости так билдую. Да, приходится проверять. У культурных людей бывают тесты, с ними задача упрощается.