Як визначити, скільки флеш / оперативної пам’яті потрібно для мікроконтролера?

Скажімо, ви починаєте вбудований проект з деякою відомою функціональністю. Коли ви вибираєте мікроконтролер, як вибираєте, скільки оперативної пам’яті вам потрібно?

Ви спочатку використовуєте дошку розробника та кодуєте свій проект, а потім подивіться, скільки пам'яті ви використали, а потім виберіть відповідний мікроконтролер, який відповідає цій пам'яті?

Ви просто вибираєте приємний мікроконтролер для прототипу, а потім зменшуєте масштаб після того, як у вас є робочий продукт?

Ви просто вибираєте те, чого ви впевнені, що вам буде достатньо, і якщо у вас не вистачає місця, просто перейдіть на більш високу щільність пам’яті, інакше ви просто збережете існуючий мікроконтролер?

Що вважається хорошою практикою?

Особисто для хобі-проектів я, як правило, використовую найпотужніший мікроконтролер у сім'ї з правильним слідом. Потім я розробляю друковану плату, записую якийсь код і виробляю прототип.

Це має перевагу в тому, що я знаю невелику кількість мікроконтролерів досить добре, тому я можу швидко прототипувати без того, щоб прочитати цілий аркуш даних. У мене також є розбивні дошки та шаблони коду для них.

Якщо це працює, і я заробляю більше, ніж тоді, я купую найдешевший мікроконтролер, у якого є правильна периферія та достатньо пам’яті для того, що я кодував раніше. Це може дратувати, якщо внутрішні регістри змінюються (трапляються на PIC) або якщо в будь-якому мікроконтролері є додаткові периферійні пристрої, які потрібно відключити для роботи коду.

Однак для виробничих цілей це дозволить збрити неабияку суму з кожної одиниці.

Звичайно, для єдиного домашнього прототипу може бути корисною рекомендацією починати з найпотужнішого з усіх сумісних мікросхем і зменшувати масштаб згодом.

Однак якщо ви хочете виграти ціну, вам доведеться повідомити клієнту ціну, перш ніж у вас є гроші на те, щоб щось реалізувати.

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

Це "як" включає також роздуми про розробку програмного забезпечення, відповіді на такі питання:

• Вам потрібна операційна система? Який? Які ресурси для цього потрібні?
• Ви хочете мати шарувату архітектуру? Для цього потрібні інтерфейси, які можуть споживати ОЗУ
• Які бібліотеки вже доступні та корисні / потрібні для вашої мети, і скільки пам’яті їм потрібно (хороша документація про бібліотеку відповідає цьому на основі принаймні однієї збірки посилань)?
• Які структури та змінні вам доведеться реалізувати для власних драйверів та вашої програми?

Підсумовування всіх цих значень дає вам приблизну оцінку. Наскільки ви можете довіряти, що залежить від того, наскільки детальний ваш аналіз, і це залежить від вашого досвіду :-)
Додавання запасу принаймні 30..50% від вашої оцінки, безумовно, хороша ідея.

Як тільки ваш продукт буде готовий, і ви будете використовувати близько 80..90% оперативної пам’яті, ви можете бути впевнені, що ваш вибір був правильним - принаймні, щодо оперативної пам’яті.

Якби тільки можна було спочатку кодувати вбудовану систему, а потім створити апаратне забезпечення. Це полегшило б життя кожному. На жаль, це також означає, що ваші терміни є у вікні. Зазвичай апаратне забезпечення повинно бути розроблене задовго до того, як програмне забезпечення буде виконано, оскільки частини апаратних засобів часто мають тривалий час.

Таким чином, вбудованим розробникам SW зазвичай потрібно буде оцінити пам'ять програми та потреби процесора. Вашим першим кроком має бути спробувати переконати хлопців з обладнання, щоб вони дали вам найпотужніший мікроконтролер / процесор з максимально можливою оперативною пам’яттю. Це рідко працює, оскільки вони мають власні вимоги, але раз у раз вам пощастить.

Якщо це не працює, наступне, що ви зробите - це розробка програмного забезпечення високого рівня та розбиття модулів на функціональність. Потім ви оціните рядки коду для кожної функції для кожного модуля в системі. Потім ви можете використовувати формулу для перетворення рядків коду в бальну оцінку пам'яті коду. Ви також досліджуєте будь-які незвичні вимоги до пам'яті (наприклад, великі масиви) і додаєте якусь оцінку для її задоволення. Потім додайте деякий відсоток поверх цієї суми, щоб покрити все, що ви пропустили. Потім подвійно, щоб задовольнити типову вимогу використання на 50%.

Так, на це потрібен час. Так, потрібно перестрибувати всі обручі, оскільки змінити обладнання дуже важко після його вбудування.

Як правило, виробники мікроконтролерів вкладають у свої пристрої діапазон пам'яті, який підходить для типових програм. Отже, якщо вам знадобиться лише кілька штифтів вводу / виводу та один SPI у невеликому пристрої, слід навряд чи ви знайдете що-небудь, що постачається з 500 кбайт флеш-пам'яті та 64 кбайт оперативної пам’яті. Що стосується великих пристроїв, які ближче до пакетів SoC, навіть найменший майже напевно є досить великим, якщо ви не плануєте робити якісь серйозні скорочення, такі як обробка зображень.

У професійному середовищі головним вибором правильного мікроконтролера є використання історичних даних. Ви матимете запис про інші розроблені вами проекти та будете знати, яка пам'ять та інші ресурси кремнію потрібні для реалізації кожної функції. Ви дізнаєтеся, чим очікується виріб, і тому матимете хороший список функцій, і зможете швидко та точно обчислити ресурси, які мікроконтролеру потрібно буде забезпечити. Намагання відгадати вимоги до ресурсів із попередньої специфікації проекту (розробленої на початку проекту, коли є найменша інформація про систему) є ненадійною в кращі часи і лише дуже досвідчені інженери, які створили комплексний База даних історичних даних у власних головах матиме будь-який успіх у використанні цього методу.

Багато компаній застосували "Agile" підхід як до програмного забезпечення, так і до електронного дизайну, який передбачає створення "бібліотеки" невеликих функціональних плат (наприклад, дошки RS-485, плати АЦП тощо), а також загальних платформних плат, на яких розміщуються мікроконтролери. , аналогічно використанню комплекту розробників та плагінів. Потім виріб може бути прототипно швидко (протягом декількох годин) шляхом вибору та підключення набору дощок, необхідних для функцій. Програмне забезпечення аналогічно зібране з бібліотечних модулів і може швидко переноситися та тестуватися. Як тільки розмір частин коду, відомий для обладнання, відомий, зазвичай достатньо вибрати найменшу частину, яка буде містити його. Винятком є ​​той, що згаданий вище, коли функціональність пристрою включає великі дані або дуже складні алгоритми. Цей спосіб забезпечує точний,

(Ще однією перевагою підходу Agile є те, що він дозволяє розробляти програмне забезпечення та електронну розробку паралельно, при цьому дизайн elctronics є вправою інтегрувати набір плат функцій та виконувати відповідні ЕМС та інші складні речі одночасно з на складах прототипу розробляється прикладне програмне забезпечення. Деякі перенос і інтеграція все ще потрібні, але це робиться, коли функціонують програмне забезпечення та електроніка.)