Някой има ли идея до колко този ART е наистина полезен? В смисъл в един код писан със стандартно gcc, пълен с всичко - сметки, лупове ,прекъсвания, DMA трансфери и т.н, процесора се търкаля на 168Mhz (демек с 5WS към флеша) до колко бързодействието му е осезаемо?

Питам защото може да ми се наложи да го изключа (пречи на АЦП-то) и да знам за какво да съм подготвен като спад в производителността.

Ми пусни му някакъв бенчмарк, може и написан от тебе.

О дизайна на джаджата е на още на хария Чудя се дали да не му шибна едно външно АЦП. Ама пусто гони се цена до долар, че бройките са големи. И не ща да го слагам, ако няма изрична нужда.

Питам ако някой го е чоплил вече...

Аз че нямам опит нямам, ама и те май нямат документация ?!

Принципно има сериозен проблем с производителността както и да го направиш

Ако изпълняваш код от флаша без ускорител би трябвало да ти вкарва WS на всеки достъп. Тъй като е 128-битов флаш би трябвало да имаш един достъп на 4-6 инструкции, демек производителността ти може да падне до 50%. Аз не виждам голям смисъл да клочиш ядрото на 160MHz в тоя случай след като реално ще го ползваш на 80. Още повече, че проц над 100MHz си иска многослойка без значение дали ще ползваш кешове.
Друг е въпросът що ST не са сложили нормален кеш на ядрото, ами само за флаша. Щото ти ако решиш да изпълянваш код от RAM пак имаш проблеми с производителността, освен ако не се пръснеш в различни RAM-ве за код и данни. Ако си в един и същ РАМ имаш конфликт (wait states). Отделно ДМА-та и там конфликти....

Не знам... аз първо бих се помъчил да сваля честота колкото може, освен ако не правиш луди DSP алгоритми или търкаляш лайнукс

Проблема е, че свалянето на честотата едва ли ще помогне. Всъщност никой не знае, това си е проблем описан в ератата и единственото, което препръчват като работещо е изключването на акселератора. Другото което препоръчват е усреднаване и подобни алабалистики. Явно в силикона става някаква мешавица, щото всички контролери от 2 и 4 серия го имат това. на 42 серия явно са се усетили, какво са насрали, защото имат два бита в системните регистри, които магерят нещо и подобрявали видимо картинката, даже и с включен акселератор. Ама на моя ги няма тия битове.

Абе ще сложа външно АЦП най-вероятно. Проекта е сериозен и не ми се правят фокуси, още повече, че знам за проблема изначало, а не постфактум, както ми се случва обикновенно.

P.S. Иначе си прав, че документацията точно в тая си част е меко казана отвратителна. Все едно някаква секретна разработка мама му стара. Иначе има някакъв кеш на ядрото, ама нищо не е описано като хората. Щото точно в бъга за АЦП-то казват да изключиш префетчването, но да включиш инструкшън и дейта кеша (каквото и по дяволите да значи това). И действително в контролните регистри на флеша има:









Точно затова ми стана интересно, ако само префетчването се изключи какво се случва. Ама поне от документацията нищо не става ясно.

Те го препоръчват, но като им гледах измерванията в an4073 не виждам кой знае каква разлика? Да не би да пропускам нещо? Тъй де, имам предвид че отиването на истинско АЦП може да се окаже неизбежно.

Така е.

Аз нещо не го разбирам тоя app... разглеждат 3 случая - art on, art off и prefetch off.
В първите два си шуми яко, което поставя въпроса защо обвиняват art-a като и без него е зле. А третия случай е с включени D+I, което поставя въпроса каква е разликата между кеш (който по необяснима за мен причина кешира само флаша) и АРТ ускорител пак на флаша
И за да е пълна обърквацията шумовете намалят с изключване на префетча, който просто уплътнява времето на флаша. Може би шума не е следствие от конкретно нещо, а просто им са калпави опроводяванията на захранванията в чепа. Не виждам друга логика...

Аз тия вътрешни захранвания на STM съм ги нарочил отдавна.
Мисля, че акселератора точно това прави - дърпа много ток и клати всичко "наоколо"...а вероятно наоколо се взема или маса или захранване на ацп-то. Най вероятно по маса пречи -ама тука вече си е гадаене.
Проблема го има още на STM32F1 серията, ама чак сега пишат за него
старите документи няма кой да ги обновява явно...

аз бих препоръчал режима ADC off

колко реални бита гониш? и на каква скорост

ех... то ако ще е ADC off по-добре STM off

Все пак ако може да се разчита на документацията им има някакъв шанс... В последния им тест е прилично като резултати, още повече че теста им е на почти 2Msps. На тая скорост едва ли някой се надява на чисти 12 бита, 10 бита си е съвсем прилично... Въпросът е да не е 6-7 бита каккто е в първите 2 теста

F1 нямам оплаквания от АЦП-то. Аз както казах и на F4 се побъзиках, ама такива чудеса като описаните в ератата не видях да има. Но щом го пише, значи явно може и толкова зле да стане.

Слагам външно АЦП, нямам време да се занимавам с магьостничество. Наистина в третия случай изглежда прилично, но никога няма да съм спокоен и при всеки проблем с измерването, ще гледам в тая посока. И освен това не е ясно като се изключи префетча, какво аджеба се случва с производителността (след като кеша за данни и инструкции остава включен). Щото според мен трябва да се срине ама никой не го обяснява това като хората.

ми кеша и префеча са две различни неща...
ако циклиш наблизо, и всичко е в кеша, няма да загубиш скорост дори при изключен префеч.

флешовете са бавни за достъп поради спецификата им. и за да вдигнат горе-долу скоростта, правят широк, че да могат да тъпчат повече битове в кеша за сметка на по-голямото време за достъп. нормална тактика. но в АРМ ядрото има нещо гнило, и кешването се оказва нетривиална задача. и явно всеки производител я решава както може, или както си мисли, че е добре. затова и уж едно и също ядро има различни "фючъри" при различните производители... дори в дебелите ядра с DDR2/3 се налага инвалидиране на кеша в доста случаи, иначе се появяват фантомни данни. с този случай се сблъсках фронтално преди 2 месеца, когато се опитвах да компилирам по-сложни сорсове в нейтив линукс среда. докато не махнах кеша на файловата система, дори cofigure не минаваше на 95% от пакетите.

за да бръмчат обаче толкова яко при префеч, явно нещо със захранванията е обозено. при АЦП-то се вижда най-лесно, но това надали означава че няма да има и други трудни за диагностика "ефекти". за да загубиш 30% от битовете е нужно голямо геройство... и е особено неприятно да си го признаят след 3-4 години копане в тази архитектура.

не знам... едно време ми отнемаше по-малко време да навържа 6809 с памет, пром и серийна порта на платка, отколкото сега да разбера в шибания чаршаф къде се връзва термалния пад - на захранване, на земя или в ефир

Малее, 30% ?! . То демек това нещо не работи.

Какви са бозите с кеша им разбрал ли си? То може и чисто софтуерно породена
боза да е (в началото с моите power току забравях някй flush и т.н.). Любопитствам
защото ми чопли в главата идеята за 64 битовите им дали няма да ми влязат
в работа (не заради 64-те бита а заради вече 32-та регистъра) а очаквам да
има някаква заложена спирачка, нали е масовка, та си дебна .

Аз лично не съм виждал по-немърлив дизайн от тия на ST... отчасти Луминари, ама и те също си имаха ядове с консумацията.

Всичко им е мазало... Примерно сложили таймери, ми трябват си.. Те сложили 14 парчета, прекрасно. Обаче от тия 14 няма два еднакви. Добре айде за да бъда точен има 3 еднакви двойки и 8 уникални. Демек 11 типа таймери. Някой с 1 канал, някои с по 2, други по 4 канала. Едни са 16 битови, други 32 битови... Луда история, не виждам как някой ще запомни кой таймери какъв е. Поне една сравнителна таблица да бяха сложили, ама както и да е...
После някои прекъсванията за даден таймер са ги пръснали в различни вектори. Явно в началото идеята им е била да се диспатчват по-бързо. Хубаво, няма лошо, само че после са добавили още таймери и сега половината прекъсвания от един таймер са в общ вектор с прекъсвания с друг таймер, някои даже са шернати и с други периферии. Боза отвсякъде!
А за тоя АРТ ускорител има 2-3 изречения в дейташита, няма регистри, няма нищо, поне според дейташита. Но там всъщност и регистрите на флаша ги няма документирани трябва да ги търсиш в отделен app. А през флаш регистрите се управляват и кешовете, мазали... та мазали...

Но основният проблем е че са оплели перифериите. Едно и също ДМА ходи до няколко периферии, ама не просто през шина ами се разхождат сигнали. Изобщо най-различни сигнали се вземат от една периферия, вкарват се в друга и се оплитат като свински черва. Е няма после как да няма cross talk и един куп проблеми...