Ние кода си го имаме вече... Идеята е да се смени само проца, т.е. вместо с STM платките да се насищат с GD. Или обратно, в зависимост какво е налично в момента.
Проблемът е, че проектът е към 800К, а при тия гадове само първите 512К от флаша са бързи. Целият може да се ползва за код, обаче казват:
Ние това го видяхме още в началото, обаче никъде няма документирано какво точно се разбира под "long delay". И тъй като досега не сме имали ядове с бързодействието на проца, решихме че някой друг wait state от време на време изобщо няма да се усети. Да, обаче се оказа че се усеща и се усеща зверски. На практика cpu usage-a се умножи по 10.
В idle режим това не е фатално. Вместо 0.1 - 0.2% става 1-2% CPU usage, голям праз. При някои операции с ST имаме 1-5% cpu usage, при GD отива на 10-50%. И това да кажем се търпи. Обаче когато при ST имаме 10% или повече при GD става страшно... Работи, но се влачи като народна песен.
Демек очаквахме бавният флаш да има някакъв ефект, но не сме предполагали че ще е чак толкова драматичен. То като няма точна спецификация кое как се случва не знаеш какво да очакваш. Даже първоначално си мислехме да не би нещо да не сме подкарали както трябва, да сме го пуснали на по-ниска честота, нещо някоя периферия да прави мизерии и т.н. Затова почнахме да правим различни тестове. Което още повече ни обърка, защото примерно правиш цикъл само с един NOP и той работи без забележки както в бързия, така и в бавния флаш. Разгъваш цикъла, т.е. слагам 1000 NOP-a последователно и бум. В бавния флаш изпълнението става пълна трагедия. По 10-12 клока на NOP. Та почваш да се чудиш дали има някакъв кеш, щото краткия цикъл си работи. Или просто работи на парчета и като минеш границата на две парчета увисва докато презареди и т.н. Другото объркващо е, че като се ползва за данни "бавната" половина се държи сякаш има само 1WS, докато бързата е с 2WS. От една страна е логично - бързата половина е оптимизирана за код, пък другата е за данни. Но пък не се вързва с теорията за малкия кеш, освен ако кеша не е само за инструкции. Не се вързва и с теорията за парчетата, щото за 1 клок нищо не може да се презареди.
Изобщо пълна магия е какво са направили и как са го направили. По-скоро въпросът беше дали ние можем да направим нещо, евентуално да разместваме код или нещо друго, така че да замажем някак си положението. Но след всички тестове решихме да не се занимаваме с глупости. Просто тия гадове очевидно могат да се ползват, но само ако кода се събира в рамките на бързата част. Всичко друго е лотария. Освен ако не се намери точна информация как работи флаша. Но според ако имаше начин тоя флаш да се използва за код те щяха да го кажат в документацията. Фактът, че не дават никаква информация и се измъкват с лафа "long delay", според мен означава, че няма смисъл да си губим времето.