8L учебный курс. Часть 0. Вступление.

Вступление,
Это нулевая статья в «практическом учебном курсе по STM8L». Как вводная лекция — ничего полезного не скажу, можно было и не приходить.

Курс создается с целью показать возможности микроконтроллеров STM8L, некоторые варианты их практического применения и выйграть осциллограф :). Состоять он (не осциллограф, курс) будет из 13 статей, в каждой из которых рассматривается тот или иной периферийный модуль микроконтроллера. Некоторым довольно простым модулям или функциям отдельной статьи не достанется. Они будут рассмотрены в рамках других уроков. Количество теории в большинстве уроков будет сильно меньше, чем количество практики. Не пугайтесь — её достаточно для понимания того, что описывается в статье. Для особо любознательных я дам ссылки на соответствующие разделы документации и другие статьи.

В основном уроки будут строится по такой схеме:

— Общий обзор изучаемой темы
— Постановка задачи
— Более детальный разбор темы, но уже в направлении поставленной задачи.
— Практика

Иногда этот шаблон будет нарушаться, например уже в следующей статье :-)

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

Я постарался использовать как можно меньше редких или дорогих компонентов в своих примерах. Исключение, пожалуй, составляет пример к статье про SPI, где будет использоваться MMA7455L (акселерометр) и пример к статье про I2C, где нам встретится SHT21 (датчик температуры и влажности). Большую часть устройств можно будет собрать на базе STM8L-Discovery. Для тех у кого другая отладочная плата или просто много свободного времени, я буду выкладывать принципиальные схемы устройств.

Для кого это курс?
Для тех, кто хочет освоить микроконтроллеры STM8L, естественно. А если серьезно, то для понимания того, что будет описываться в курсе, от вас требуются:
— знания основ электроники,
— основ программирования. Желательно под МК, потому что java-кодер не знает, к примеру, что такое динамическая индикация. Я спрашивал.
— языка Си (никаких хитростей Си я здесь не использую, поэтому хватит и пары уроков, чтобы разобраться с языком),

Очень хорошо, если вы уже знакомы с какой-либо архитектурой МК. Например AVR или PIC. Это позволит вам не впадать в ступор от слов «EEPROM», «регистры», «I2C»… Я сам довольно хорошо знаю микроконтроллеры AVR, поэтому иногда буду указывать на отличия STM8L и AVR. Так-же не повредит знание английского языка, потому что если вы захотите узнать все подробности о том или ином периферийном модуле, вам придется читать материалы на английском. На русском языке материалов по STM8 мало — мы с вами, можно сказать, первопроходцы :-)

Знания о том, что из себя представляют STM8, приветствуются, но не обязательны. Если они есть, то вы должны знать о том, что STM8L — это серия микроконтроллеров, в которых сделан упор на низкое энергопотребление. Было-бы глупо не отразить этот момент в нашем курсе. Поэтому я довольно часто буду упоминать о потреблении того или иного модуля МК и о том, как снизить общее потребление устройства. Апогеем этой LowPower-мании и гонки за микроамперами станет статья про контроллер LCD, где в качестве примера будет создан экономичный измеритель влажности и температуры с SHT21 в качестве датчика.

Кроме STM8L, среди восьмиразрядных МК от STMicroelectronics есть серия STM8S. Отличаются другим диапазоном напряжений питания (2.9V — 5V), отсутствием некоторых периферийных устройств, и прочими мелочами. На самом деле, они очень похожи. Большинство тех вещей, которые я говорю о работе с STM8L справедливы и для -S серии. Но несмотря на это STM8S я в курсе описывать не буду, пусть будут вам домашним заданием :-)

Сама серия STM8L делится на две линейки. В первой контроллеры, названия которых начинаются на STM8L101 — их мы рассматривать тоже не будем ввиду того, что у них довольно скудный набор периферии и для них пришлось бы делать отдельную демоплату. Во второй STM8L151, 152 и 162. На плате STM8L-Discovery установлен МК STM8L152C6T6 — это так, для справки. Пусть вас не смущает, что мы рассматриваем такой узкий круг контроллеров: периферия в S и L сериях (а уж тем более в 8L101 и 8L152) очень похожа, и при необходимости перейти на другой МК будет не сложно.

Для тех, кто прочитав вышесказанное понял, что он чего-то не знает, советую почитать следующие вещи:

Основы на пальцах (1, 2, 3, 4), да и вообще весь раздел «Начинающим» на сайте easyelectronics — для тех кто путает диод с резистором.

Некоторые статьи из раздела «AVR. Учебный курс» помогут заполнить черные дыры в знаниях касательно МК и типовых конструкций в программировании

Статьи из цикла «AVR. Учебный курс. Программирование на Си» (1,2,3,4,5,6) помогут в изучении языка С.

Статья «Микроконтроллеры STM8 — Введение» расскажет о том, что такое восьмиразрядные МК от ST, и каково их место во вселенной.

Ниже приводится содержание курса с кратким описанием каждой статьи. ВНИМАНИЕ! Содержание может внезапно изменится, по ряду причин. Я могу придумать более интересный пример или сломать детальку необходимую для примера. Так-же некоторые пункты могут поменяться местами или появятся новые. Короче, мы находимся на начальном этапе зарождения вселенной — пока еще все очень нестабильно. Именно поэтому у вас есть возможность немного изменить курс нашего курса :-) Пишите пожелания в комментариях. Кстати, содержание да и вообще курс обсуждался вот тут.

Содержание курса:

0) Вступление
You are here…

1) Hello светодиод!
Установка IAR. Создание проекта. Мигание светодиодом.

2) GPIO
Подробный разбор GPIO. В качестве примера управление семисегментным индикатором. Работа с кнопками.

3) GPIO, часть 2
Матричная клавиатура. Прерывания — пробуждение МК из halt по нажатию кнопки. Эмуляция 1-wire. Кодовый замок c iButton. Здесь-же затронута работа с EEPROM.

4) Таймеры: начало
Общие сведения о таймерах в STM8L. Создание собственной функции задержки с блекджеком и WFE. Прерывания таймера. Динамическая индикация (7seg) на таймере. Секундомер. Т

5) Таймеры: продолжение
Работа с навороченым таймером 1. Генераця ШИМ сигналов (делаем moodlamp). Режим подсчета количества импульсов (частотомер).

6) Сенсорные кнопки
Обзор библиотеки от ST для создания сенсорных кнопочек. Делаем светодиодный светильничек с сенсорным управлением.

7) АЦП
Быстрый старт с АЦП. Использование таймера в качестве триггера для АЦП. Вывод напряжения на дисплей. Вольтметер и амперметер.

8) Интерфейсы: USART
Обмен данными с компом (передача данных из АЦП в комп — осциллограф же!).
Работа USART в синхронном режиме, подключение дисплейчика от Nokia.

9) ЦАП
Общее описание DAC. Ликбез по DMA. Работа совместно с DMA и таймером качестве триггера. Простенький генератор сигналов управляемый по UART.

10) Интерфейсы: I2C
Работа с i2c в режиме мастера. Термометр/термостат на lm75a. Тут-же работа со сторожевым таймером. Обзор slave режима.

11) Интерфейсы: SPI
Работа с акселерометром MMA7455LT. Передача данных с акселерометра через UART. Обзор slave режима в SPI.

12) RTC
Обзор возможностей RTC. Делаем простенькие по функциональности, но неординарные по виду, часы.
13) Контроллер LCD
Сверхэкономичный измеритель температуры и влажности на sht21 + часы. Тут-же ликбез по энергосбережению и работа с PVD.

Вот так. Получилось немного сумбурно, но сойдет. Хальт, не переноси в тематический блог — пусть тут лежит.
  • 0
  • 18 октября 2011, 07:37
  • dcoder

Комментарии (84)

RSS свернуть / развернуть
Ок, только ты потом ссылки на мои статьи воткни уже в курс, где нибудь вначале сноской.
0
Должно шикарно получиться. Dcoder, у меня просьба, в первай статье после установки IAR, напиши создание по шагам проекта c использованием stdperiph_lib.
0
Вообще уже описано PRC но я наверное повторюсь
0
У меня мои/стмовские шаблоны. Как в пустой проект подключить библиотеки я не писал.
0
Ну в общем-то я и собирался эти шаблоны использовать. Удобно же
0
На счет статей — очень хорошее дело. Мне как раз хотелось бы освоить их.

Можно попутно глупый вопрос?
STM8 — это их собственное ядро, а STM32 — уже ARM? А то запутался в них…
Хочу попробовать и то, и другое, а для начала приобрести отладчик. Так вот, лучше взять STM8S-DISCOVERY + STM32VL-DISCOVERY, или какую-то одну + отдельно камень (программатор то там есть)?
Просто цены на них радуют глаз…
0
  • avatar
  • ploop
  • 18 октября 2011, 11:23
про ядра всё верно. насчёт отладчика: в STM8 используется SWIM- интерфейс, а в STM32 — SWD. но на STM8S-Discovery ещё имеется JTAG, но про него в интернете я ненашёл никакой инфы… пробывал на днях подключить его к плате STM32VL-DISCOVERY, но безуспешно…
0
Ну ладно, если оставить восьмибитки, на других ARMах (например LPC) тот же SWD? А то говорят, что программаторы DISCOVERY залочены только на STM, и других фирм не хотят видеть.

Или проще спаять самому, и купить голые камни, как в случае с AVR-ками? Просто не хочется зря деньги выкидывать, хоть и небольшие…
0
Перешивают програматор на STM32VL-DISCOVERY на управленую версию VERSALON. И я так понял потом оно работает как полноценый SWD и JTAG.
0
Ups :) Versaloon
0
Это теоретически. А практически последние версии прошивок версалуна у меня категорически не хотят работать. Более того, с какого-то момента фирмварь и собираться перестала (может уже починили, надо будет проверить). А к старым надо старый OpenOCD. Вобщем, не все так радужно :(
0
Для STM8 и STM32 хватит FT232 в качестве программатора.
Правда не все камни.
0
Это бутлоадер — только прошивка без отладки, что неудобно
0
Ну да. Зато не будет таких проблем как у большинства МК.
Программатор для программатора.
0
Я бы даже сказал CP2102 :)
Где-то в доках я даже встречал рекомендации по подключению сигналов RS232 к BOOT0 и NRST. Тогда можно прямо сигналами из компорта загонять МК в режим системного бутлоадера.

А вообще, конечно, встроенный программатор в STM-ках меня весьма радует. Он часто работает даже если схема собрана не до конца, с багами и даже при отсутствии части питания. В новых сериях процов он, к тому же, умеет не только по двум USART-ам работать, но еще и по USB, правда эту возможность я не проверял.
0
потому что java-кодер не знает, к примеру, что такое динамическая индикация. Я спрашивал.
И правильно, ибо это не программирование, а схемотехника. Программисту это неоткуда знать, если он не электронщик.

Алсо чем для SPI что подешевле не устроило, вроде памяти или SD?
0
  • avatar
  • Vga
  • 18 октября 2011, 20:24
Таки схемотихника? Там больше программирования имхо.

Насчет SPI думаю. Может и правда что по-проще. Простохочется чтобы в результате получилось что-то полезное и по возможности прикольно-забавное. Аксель это весело, а вот память…

Хотя подождите… можно же запилить плеер звуков с SD карты :) Да будет так
+1
Схемотехника как она есть. И появилась куда раньше, чем программируемые микросхемки. Только реализовалась через счетчики, дешифраторы и мультиплексоры.
0
Кстати, обрати внимание, куда автор засунул этот топик :)
0
полностью согласен. курс должен быть максимально доступным, насколько это возможно, и практичным. SD оптимально будет.
0
Как раз таки одна из лабораторок по программированию — динамическая индикация. А вот в «модных» универах ограничиваются ВБ и выдают диплом «программист». Так что незнающий выпускник такого универа, либо не настоящий программист.
0
По эмбеддед программированию, надо полагать. Сама задачка динамической индикации:
1) Имеет практически нулевую ценность для изучения программирования. Так что программера этому обучать явно не будут.
2) Неприменима где-либо, кроме эмбеда.
3) Растет ногами из схемотехники — таким макаром сокращали количество дешифраторов и проводов еще во времена 155 серии, а скорее всего и раньше. Позже она нашла свое место и в микросхемах для часов, калькуляторов и пречего. А с появлением МК переехала в софт (т.к. туда же переехали и дешифраторы, и то, что кормило их данными — в общем, все, кроде индикаторов).

Так что никто кроме выпускника радиофака этого знать не может. Впрочем, стоит отметить, в нашем институте ДИ не упоминали, либо этого не помню. А отучился я именно на радиофаке.
0
А где собственно продолжение? Я уже сам начал ковыряться такими темпами :)
0
Отсутствие свободного времени у аффтара приводит к отсутствию учебного курса. Sad, but true.

Но его никто не отменял, просто переношу в светлое будущее, попутно допиливая содержание.
0
GCC уже поддерживает STM8?
0
— основ программирования. Желательно под МК, потому что java-кодер не знает, к примеру, что такое динамическая индикация. Я спрашивал.
Зато джава-кодер знает, например, что такое garbage collector, JIT и много других умных слов, от которых у железячников на лице появляется выражение «куда я попал?». Я проверял.
Это не упрек и не подколка, просто к программированию на жабе динамическая индикация никакого отношения не имеет, да и к программированию вообще.

P.S. Обратил внимание, что у многих ембеддеров считается хорошим тоном пинать жабу и жаба-программеров. Что характерно, среди жаба-программеров такого отношения к ембеддерам не наблюдается. Я, в некотором смысле, по обе стороны этих баррикад и, честно говоря, не понимаю такого отношения. И там и там нужен изрядный запас знаний и навыков. Жаба сильно упрощает жизнь программеру, спору нет. Позволяет игнорировать многие вещи, которые ембеддерам важны (то же потребление памяти или, скажем, количество тактов), но ровно так же многие важные для жаба-програмеров проблемы просто за пределами понимания многих ембеддеров. Те же транзакции, например, многие вопросы синхронизации при многопоточной обработке, кластеризация, клауды и прочая дребедень, не говоря уже о современных технологиях программирования вообще. Современный жаба софт без тестов и представить-то тяжело, а для ембеддед софта это, скорее, исключение, чем правило. Народ от рисовалки блок-схем прется, хотя это каменный век с точки зрения программиста (не только на жабе). Но все эти отличия вовсе не повод для кидания какашками друг в друга.
0
  • avatar
  • evsi
  • 07 февраля 2012, 10:40
Что характерно, ява нужна и простому эмбеддеру — например программы под андроид писать. Я вот недавно понял, что жабу не знаю совсем и это печально :(
0
Угу. Хуже всего, что жаба (впрочем, как и многе другие прикладные языки) сильно ушла вперед в плане технологий программирования. Полное юнит-тестирование, TDD, рефакторинг и так далее. Кроме того, не смотря на свою похожесть на С/С++, в жабе здорово отличаются даже подходы к объектно-ориентированному дизайну. Многим знакомым сишникам/плюсовикам (да и мне самому) приходится здорово ломать устоявшиеся навыки и привычки. К слову, многие чисто жабовские подходы (например, полное развязывание интерфейса и реализации, минимум наследования) я считаю более правильными, но, увы, в лоб на ++ они не переносятся, тем более в ембеддед программирование.
0
Кроме того, не смотря на свою похожесть на С/С++, в жабе здорово отличаются даже подходы к объектно-ориентированному дизайну.
Это потому, что от плюсов там только синтаксис. Все остальное взято у семейства Виртовских языков.
Забавно что и С# больше взял из Java и Delphi, чем из С)

Ну и технологии программирования эти даже не жабе свойственны, тот же С++ имеет хотя и неканоничную, но весьма мощную объектную модель. Это скорее общие тенденции в мире прикладного софта. TDD — вообще методология разработки, юнит-тестирование, AFAIK, один из ее инструментов (реализованный для многих языков, включая AFAIK и С++), рефакторинг и вовсе применим даже к эмбеду, т.к. это по сути причесывание кода.
Вот паттерны программирования в прикладной части совершенно другие. Нету жесткого ограничения на потребление ресурсов, зато жесткие требования к расширяемости и поддерживаемости кода, не говоря уже просто о его количестве.
0
Я не имел в виду, что все эти технологии специфичны конкретно для жабы. Скорее я имел в виду, что они не характерны для эмбеддед. И это печально.

По поводу рефакторинга: это не только причесывание кода, это переделка без изменения поведения. У меня не редко случаются ситуации, когда внутренняя реализация существенно изменяется (включая алгоритмы), но при этом тесты проверяющие видимое снаружи поведение все проходят и ни один внешний пользователь этих изменений не замечает. Это рефакторинг в чистом виде, однако причесыванием это назвать не получится при всем желании.

По поводу жесткости требований к потреблению ресурсов. Они, на самом деле есть (и весьма жесткие), особенно в части долговременного поведенияы. Отличие только в том объемы отличаются на порядки, что часто только усложняет задачу, поскольку проблема может обнаруживаться только после многих дней (а то и недель) работы.
0
По поводу рефакторинга: это не только причесывание кода, это переделка без изменения поведения.
Ну «причесывание» довольно растяжимый фактор) В целом рефакторинг, как я его понимаю — это изменение (как правило улучшение) структуры кода. ЕМНИП, замена где-то внутри библиотеки ДПФ на БПФ — не рафакторинг, хотя снаружи поведение библиотеки не изменилось. А вот перевод внутренней структуры с процедурной на объектную — уже рефакторинг как он есть.
По поводу жесткости требований к потреблению ресурсов. Они, на самом деле есть (и весьма жесткие), особенно в части долговременного поведенияы
Ну это утечки, они строго говоря к системным требованиям не относятся, это ошибки как они есть. Зато выделить полгига памяти под какой-нить кэш — не проблема, а уж накладные расходы памяти на поддержку ООП и вовсе никого не волнуют. Тогда как на МК иной раз буфер под сетевой пакет разместить негде. Ну и опять же нередко применим принцип «дешевле памяти добавить, чем программиста напрягать» (особенно когда разработка своя под единичную задачу и килобакс на память — дешевле, чем месяц работы программиста).
0
Ну «причесывание» довольно растяжимый фактор) В целом рефакторинг, как я его понимаю — это изменение (как правило улучшение) структуры кода.
Улучшение это понятие растяжимое и может преследовать разные цели (с разными, часто противоположными, для текста программы последствиями). Но по определению рефакторинг это именно изменение кода при сохранении внешнего поведения.

ЕМНИП, замена где-то внутри библиотеки ДПФ на БПФ — не рафакторинг, хотя снаружи поведение библиотеки не изменилось.

Если результат одинаковый при любых входных данных, то это таки рефакторинг. Но тут нужно учесть такой фактор как «что именно считается поведением». В данном случае, если поведением считается именно результат преобразования и результаты совпадают, то это рефакторинг. А если к списку требований к ожидаемому поведению добавить время работы на разных входных данных, то это уже не рефакторинг, поскольку алгоритмы отличаются по скорости.
0
Code refactoring is «disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior»,[1] undertaken in order to improve some of the nonfunctional attributes of the software.
Т.е. именно реорганизация структуры кода, без изменения принципа его работы. И цели у рефакторинга сугубо внутренние — облегчение разработки и поддержки кода.
Потому как иначе можно сказать, что гугл хром рефакторят — уже 12-я версия (или мои данные устарели?), а на вид — все то же самое.
«Улучшение» понятие хоть и растяжимое, но более определенное — повышение некоторых характеристик кода. Как правило — расширяемости и сопровождаемости.
0
Применительно к хрому есть изменения во внешне видимой функциональности, так что пример не удачный.

Касательно «изменения принципов работы». Замена, например, в классе самодельного кеша на готовый библиотечный не влияет на принципы работы, хотя алгоритмы внутри кешей могут существенно различаться.
0
Применительно к хрому есть изменения во внешне видимой функциональности, так что пример не удачный.
За 12 версий — да, а вот в районе версий 1-4 видимые изменения практически отсутствовали.
Замена, например, в классе самодельного кеша на готовый библиотечный не влияет на принципы работы, хотя алгоритмы внутри кешей могут существенно различаться.
Это, в общем-то, не рефакторинг.
Собственно, вот. Т.е. ключевой вопрос рефакторинга — улучшение читабельности и понимаемости кода. Кстати, библиотека после рефакторинга может измениться снаружи — если рефакторинг затронет ее интерфейс.
0
За 12 версий — да, а вот в районе версий 1-4 видимые изменения практически отсутствовали.

Это и был бы рефакторинг, если бы не исправленные ошибки :)

Тут, видимо, следует различать две стадии рефакторинга. Первая: после того как код написан, его «причесывают» что бы упростить понимание и читаемость. Вторая: в код собираются вносить существенные изменения и рефакторят его с целью упростить внесение этих изменений. Из книжек GoF я вынес четкое ощущение, что рефакторинг изначально появился именно для второй стадии, первая стала распространяться только с появлением поддержки автоматического рефакторинга в средствах разработки. Но тут важно отметить, что в виду разных задач у этих этапов разные цели и последствия для кода. На первом этапе вполне допустимо внесение изменений даже в интерфейс библиотеки, а в фокусе именно читаемость и понимаемость. На втором фиксация внешне наблюдаемого поведения куда как важнее, а код в процессе рефакторинга может даже усложниться. Судя по всему, мы спорим, в основном, потому, что имеем в виду просто разные этапы рефакторинга.
0
В общем-то, эти две стадии особо не различаются. И кстати, именно во втором случае, на мой взглад, будут резко перекраивать интерфейсы, т.к. необходимость рефакторинга перед изменениями связана именно с «Да как с этой кашей вообще работать!? Надо сперва причесать, мух от котлет оторвать, интерфейсы проработать! А вооон то перенести с функций на объекты!». Т.е. как раз на этом этапе интерфейсы будут основательно переработаны с тем, чтобы при последущих изменениях их уже не трогать.
В любом случае, рефакторинг — это не «изменение внутренностей без изменения внешности», а «реструктуризация кода без изменения функционала». Так что, все-таки, это «причесывание кода», т.е. улучшение его структуры.
Так что если ты выкинул на мороз свой кеш и поставил готовый — это не рефакторинг. А вот если ты вынес повторенный несколько раз копипастом кусок в отдельную функцию — это уже чистой воды рефакторинг.
0
Эти две стадии отличаются, причем сильно. И интерфейсы перекраиваются, как раз, на первой стадии. Перекраивание интерфейсов на второй стадии это уже не рефакторинг, а то, что должно идти за ним. И в любом случае, «реструктуризация без изменения функционала» это, как раз, и есть «изменение внутренностей без изменения внешности», поскольку функционал определяется именно «внешностью», что и как там внутри — дело двадцатьпятое. И когда я выношу повторенный несколько раз копипастом кусок в отдельную функцию — это рефакторинг первой стадии (иначе этот код просто не пройдет кодревю и вернется мне риопеном). Когда я выкашиваю свой кеш и ставлю другой, это может быть и первая и вторая стадия. Когда я переписываю алгоритм так, что бы нужные моменты внутренней обработки стали доступны с целью потом вынести почти все в абстрактный класс и добавить еще одну реализацию — это вторая стадия, когда код вполне может усложниться, но по итогу получится все равно проще, чем копипаст двух похожих реализаций.
0
Перекраивание интерфейсов на второй стадии это уже не рефакторинг, а то, что должно идти за ним
Ну почему же, это перекраивание — как раз то, о чем ты же и говоришь:
Когда я переписываю алгоритм так, что бы нужные моменты внутренней обработки стали доступны с целью потом вынести почти все в абстрактный класс и добавить еще одну реализацию
Впрочем, на сей раз я более-менее согласен. Разве что, быть может несколько уже понимаю рефакторинг.
0
Ну почему же, это перекраивание — как раз то, о чем ты же и говоришь:
Не совсем. Когда я переделываю класс готовясь к вынесению абстрактного базового класса, это не затрагивает его публичный интерфейс (то есть «видимое снаружи поведение»), защищенные методы в публичный интерфейс, понятное дело, не входят.
0
Гм. Да, ладно, понял о чем ты. Ты имеешь в виду, что при рефакторинге второго рода нужно подготовить платформу для нового кода, при этом не ломая (и не переписывая/не рефакторя) старый.
Да, это уже не сильно подходит под определение «причесывание кода».
0
Ну это утечки, они строго говоря к системным требованиям не относятся, это ошибки как они есть.

Это вовсе не обязательно ошибки (и вовсе не обязательно утечки). Скажем, неправильно установленное время жизни кеша это не утечка, память потом все равно возвращается и размер ограничен. Но это может существенно влиять на производительность.

Зато выделить полгига памяти под какой-нить кэш — не проблема, а уж накладные расходы памяти на поддержку ООП и вовсе никого не волнуют.

Хмм. На поддержку ООП дополнительной памяти не требуется. Если аналогичную функциональность реализовать на необъектном языке, расход памяти связанный с дополнительными структурами данных будет ровно таким же. Другой вопрос, что сам язык предполагает существование некоторой внутренней инфраструктуры (а ОО она или нет — не важно). Вот на ее поддержку и нужна память.
0
И тем не менее, памяти настолько больше, что требования к ее расходу качественно другие.

ООП требуется память на поддержку его инфраструктуры. Это память под экземпляры объектов, под таблицы виртуальных функций, необходимость динамической памяти и эффективного ее менеджера (были случаи, когда Borland C++ Builder запинывал Intel C++ Compiler по скорости работы в разы именно за счет менеджера памяти, тогда как оптимизация кода у ICC просто несравнима с BCC) и так далее. Из-за этого на МК приходится ООП сильно ограничивать — на AVR например как правило статические объекты, никаких фокусов вроде полиморфизма и т.д. Структурная же парадигма (по крайней мере в С-варианте) требует только стек, а иногда и без него обходится.

В результате приоритеты в эмбеде и прикладном программировании существенно различаются. Если в эмбеде (пока еще) главенствуют аппаратные ограничения (особенно объем памяти), то в прикладном на первое место выходят вопросы снижения сложности разработки. А отсюда — серьезные различия в паттернах и подходах.

А так, вообще-то, методология TDD вполне применима и в эмбеде. Рефакторинг — и подавно.
0
ООП требуется память на поддержку его инфраструктуры.

Нет, конечно.
Это память под экземпляры объектов,

Ровно так же как и под структуры данных в не-ООП языках.
под таблицы виртуальных функций,

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

Это не является необходимостью. Вполне можно писать ембеддед (и не только ембеддед, но и просто low level) программы с ООП и без динамического выделения памяти вообще.

С++ не даром сначала назывался «C with classes» и представлял собой препроцессор. Новой функциональности он не давал, всего лишь оборачивал в более удобный синтаксис типовые приемы программирования.
0
Это все зависит от объектной модели и паттернов.
С++ имеет довольно-таки неканоничную модель (вплоть до того, что некоторые утверждают «С++ — не ОО язык»), и если не использовать определенные возможности (вроде тех же виртуальных методов) — то да, можно обойтись без накладных расходов, но и от ООП мало что остается (собственно, отваливается полиморфизм, а без него становится бессмысленным наследование, и из трех основ ООП остается только инкапсуляция).
А вот Delphi, например, сильно зависит от всего перечисленного (если, конечно, рассматривать объектную модель Delphi, а не оставленную для обратной совместимости модель из турбо паскаля).

Суть остается та же — в ограниченных условиях эмбеда приходится отказываться от столь привычных в прикладном программировании подходов из-за нехватки памяти. В прикладном же програмировании память определяет выбор структур данных и алгоритмов (и то только если они требуют много памяти — разрабатывая какую-нибудь утилитку, о памяти можно даже не вспоминать), а не средств языка.

Впрочем, с нынешними тенденциями актульность экономии памяти и в эмбеде начинает уступать необходимости контролировать мегабайты кода. Достаточно вспомнить хотя бы про .net MF.
0
Разница в подходах и паттернах очевидна, задачи-то разные, тут и спорить не о чем. Я имел в виду ситуацию одинаковых программ в ОО и не-ОО стиле.
0
Ну, действительно одинаковыми они не будут. Все же, в качестве примера ты привел имитацию ООП на С, а это скорее ООП-стиль. Даже на ассемблере давно уже пишут в структурном стиле, хотя его родная парадигма совсем другая. Но в ней уж очень сложно контролировать код, поэтому приходится использовать структурный подход и накладывать на себя ограничения.
0
ООП-стилем это стало называться потом, до этого это был типичный С-шный стиль, в чем-то даже хакерский (пуристов коробило от вызова функций по указателю).
И да, я согласен, что с подачи комитета плюсы превратились из удобного языка системного программирования в многотонный мультитул со скелетной рукояткой, с которым каждое неосторожное движение приводит к немедленной ампутации всех конечностей (а хотелось-то, всего-навсего выстрелить себе в ногу), а внутренности хотя и весьма заметны, добраться до них часто невозможно. Даже не знаю, какой тут смайлик больше к месту, такой :) или такой :(.
0
И да, я согласен, что с подачи комитета плюсы превратились из удобного языка системного программирования в многотонный мультитул со скелетной рукояткой, с которым каждое неосторожное движение приводит к немедленной ампутации всех конечностей (а хотелось-то, всего-навсего выстрелить себе в ногу)
Гм, насчет «согласен» — лишнее, т.к. как раз я так не считаю. На мой взгляд, из-за особенностей идеологии принцип немедленной ампутации конечностей берет начало как минимум еще в С — он оптимизировался под скорость работы, простоту компилятора и лаконичность, а не устойчивость к ошибкам, которая в результате и пострадала. А нынче внезапно последняя стала важнее, чем первые две.

Хотя насчет «многотонного мультитула» — в яблочко. Но нынче все прикладные языки такие, для полноценного освоения любого из них нужны годы практики.
0
С свято блюдет принцип «если я хочу выстрелить в ногу, я просто делаю это». Касательно простоты компилятора это, явно, не о С, там грамматика отнюдь не самая удобная для этого (особенно K&R), да и голову заморочить оптимизатору на нем достаточно просто. Да и скорость работы С-шных программ изначально определялась тем, что он чуть-ли не 1:1 перегонялся в PDP-шные инструкции (именно оттуда ростут пред-, пост-инкременты и богатая адресная арифметика). Да и создавался он именно как язык системного программирования, устойчивость к ошибкам явно не из этой оперы. Минимизация ограничений (или максимизация доступа к железу, как угодно). Отсюда, кстати, все торчащие наружу кишки типа указатель = массив. Изначально С++ продолжил эту славную традицию, добавив новых кишок и (достаточно) удобный синтаксис сдобреный фишками вроде перегрузки операторов. Целиться и стрелять себе в ногу стало легко и удобно. Ну а потом страус в чисто акедемическом стиле сделал чисто академический прикладной язык для абстрактных задач. В итоге пользоваться для системных целей перестало быть удобно, а для прикладных так и не стало удобно. Ни туда, ни сюда, вобщем…

P.S. я в свое время по этому поводу переписывался со Строустраппом, но мнение людей использующих язык в реальной жизни его явно не интересовало…
0
С свято блюдет принцип «если я хочу выстрелить в ногу, я просто делаю это»
Да, про этот принцип я забыл упомянуть. Вот только, все же, если уж про оружие… То там всячески стараются предотвратить вариант «я не хочу выстрелить себе в ногу, но делаю это».
Касательно простоты компилятора это, явно, не о С, там грамматика отнюдь не самая удобная для этого (особенно K&R), да и голову заморочить оптимизатору на нем достаточно просто.
Насчет неудобства грамматики не знаю, но что С оптимизировался под компиляцию простым и однопроходным компилятором — об этом говорят все источники по его истории. А оптимизаторов тогда особо не было.
Да и скорость работы С-шных программ изначально определялась тем, что он чуть-ли не 1:1 перегонялся в PDP-шные инструкции
Далеко не только, далеко. Там есть менее очевидные фокусы — например, контрольные точки. Они куда реже, чем думает большинство сишных программистов (по крайней мере согласно PDF-ке о наиболее распространенных ошибках и наименее понимаемых большинством программистов особенностях языка С), что и порождает многие из случаев Undefined Behavior. Нужно это для увеличения пространства маневра для оптимизатора (по крайней мере в новых стандартах). Опять же, очень много UB растет из соображений «избавление от этого снизит эффективность оптимизации, пусть программист сам разруливает». Так что скорость результирующего кода — тоже один из краеугольных камней идеологии С.
В итоге пользоваться для системных целей перестало быть удобно, а для прикладных так и не стало удобно. Ни туда, ни сюда, вобщем…
Как бы то ни было, в мейнстрим он вышел. Не на пустом месте, надо полагать. Но на эту тему спорить не хочу и даже выпилил уже написанные было аргументы :)

P.S. Лаконичность видимо не вызвала возражений. А ведь if(a=b) растет в том числе и из этого принципа.
0
Вот именно, что оптимизаторов было мало, поэтому-то язык максимально приближенный к машине и давал преимущество. Вот когда его стали переносить на другие архитектуры, вот тогда писатели компиляторов наплакались.

Контрольные точки и прочие детализации это уже последствия работы комитета, который, вобщем-то, просто узаконил тот бардак, который существовал на момент начала его работы. Понятно, что подобная свобода давала максимум простора для продавцов компиляторов. Но тут важно помнить, что сугубо исторически сначала появился бардак, а только потом его узаконили. Язык-то не «комитетский».

Лаконичность и не могла вызвать возражений. Разве что, я склонен думать, что лаконичность это не причина, а следствие. Следствие как раз изначальной ориентации на PDP-шную архитектуру, где подобные вещи натурально заложены в систему команд.
0
Это работа комитета, да. Но тем не менее, они продолжили в том же духе, в котором начали Деннис и Ритчи — быстрый, лаконичный, простой для компилятора язык. Собственно, иначе комитет вполне мог бы стандартизовать все эти UB и прочие белые пятна. Хотя это плюсы, но они больше соответствовали нуждам того времени. Сейчас требования изменились и С отошел в относительно узкую нишу.
Лаконичность и не могла вызвать возражений. Разве что, я склонен думать, что лаконичность это не причина, а следствие.
Лаконичность не только в этом проявляется. Авторы явно минимизировали писанину (и, вероятно, размер исходника — памяти-то, чтобы его хранить, было маловато). Полагаю, фигурные скобки вместо begin..end, ^ вместо xor и т.д. — тоже из этой оперы. И опять же, этот принцип сохраняется при развитии языка. Так что он тоже относится к основополагающим.

Страуструп, кстати, большинство этих принципов сохранил, и в С++ их отрицательные стороны проявились еще ярче.
0
Возможно. Поскольку мне на паскале писать не доводилось (лабораторки в институте явно не в счет) и я, вобщем, бОльшую часть времени писал и пишу на С-подобных языках, лаконичность в этой части синтаксиса меня вполне устраивает.
0
Ну по нынешним меркам особой разницы нет. Памяти хватает, писанина и так не особо влияет на производительность (программисту не столько текст набивать приходится, сколько мозгами шевелить), да еще и автокомплитеры разницу нивелируют. Так что дело вкуса и привычки. Мне больше нравится паскаль, а серьезным промахом синтаксиса С я считаю только = и ==. Стоило их всего лишь поменять местами — и этой грабли бы просто не было. Ни разу в паскале if a:=b вместо if a=b не набирал)
0
Все-таки, мы привыкаем выделять текст на фоне любого мусора, так что синтаксические рамки в виде текста образуют лишний фон «в области сигнала» (то есть в самом тексте программы). Хотя, конечно, это дело привычки.
0
Синтаксические рамки сами по себе сигнал. Все же, сперва интересуют общие «очертания» кода — управляющие конструкции и блоки, а уже затем — их содержимое. Длинные и жирные (в дефолтной подсветке) begin/end хорошо заметны.
0
Вот в том-то и дело, что хорошо заметны. Мне они мешают.
0
ООП-стилем это стало называться потом, до этого это был типичный С-шный стиль, в чем-то даже хакерский (пуристов коробило от вызова функций по указателю).
Тащемта, при программировании совсем не обязательно работать строго в парадигме языка. Так что ничего не мешало применять ООП-подобную парадигму в структурном языке. В принципе, примерно так она и развивалась, я думаю — в виде методологии на структурных языках. Потом уже выделили общее и собрали в стройную парадигму, под которую затем уже начали затачивать языки.
-1
Конечно. Можно и на паскале писать как на фортране.

По поводу ООП-парадигмы: первый классический ООП язык — Симула-67 — появился в 67-м году, как не сложно догадаться из названия. Теорема о структурном программировании была сформулирована и доказана всего лишь годом ранее, а основные положения структурного программирования были сформулированы только в 70-х. С учетом этого я бы не торопился делать вывод о том, что «так оно и развивалось».
-1
Хе-хе. Я думал, оно появилось чуть позже) Да и это предположение, в общем-то, как ни странно, противоречило даже моему мнению о том, как языки развиваются)
Но это все равно, имитация ООП средствами С не делает соответствующий код структурным. Идеологически он остается объектным. И пусть накладные расходы на инфраструктуру здесь обеспечиваются явно самим программистом — они никуда не деваются.
0
Да, они никуда не деваются. Причем они не деваются даже если не использовать ООП, а писать в чистом структурном виде. Ну разве что, возможно, вместо таблиц виртуальных методов будут гроздья свичей в каждой функции. И не факт, что последний вариант будет короче.
0
Нуу, зато он возможно не будет висеть в ОЗУ.
Как бы то ни было, а любимый вопль противников ООП в МК — «оно же тяжелое, а памяти и так мало!».
И, опять же, нехватка памяти препятствует дизайну «как в прикладном программировании». Там я бы связал приличную такую гроздь из отдельных блоков, а тут нету места на накладные расходы на эти блоки и приходится все смешивать в монолит. А раз оно монолитно — то и в ООП смысл отпадает. В общем, связь ООП и памяти несколько косвенная, но все же есть. На то, чтобы полноценно его плюсами воспользоваться — ресурсов не хватает.
0
«Оно тяжелое» это последствия того, как оно написано само по себе, ООП тут, разве что, не мешает писать тяжелый софт. В бытность свою сишником, я писал драйверы под полуось на плюсах. По тем временам (это почти 15 лет тому назад) подобное вообще считалось чем-то вроде плевания в иконы. Однако драйверы не только быстро работали, но и размером скорее напоминали написанное на асме. Понятное дело, что там не было виртуальных методов, громоздкой иерархии и объекты создавались статически. Но там и потребности в этом не было. А вот инкапсуляция и разделение на мелкие функциональные модули были.

Я согласен, что дизайн делается иначе, но это вовсе не потому, что ресурсов мало, а потому, что задача требует других подходов. Какой-нибудь биос на типичном писюке ресурсов имеет вагон и маленькую тележку, но задачи у него такие, что там дизайн в том же стиле, что и для прикладных задач просто не подходит. Впрочем, для ембеддед задач даже инкапсуляция (и, как следствие, разделение ответственностей) это уже немало. Будь она повсеместно распространена (хоть в самом простом виде типа «С с классами»), писать было бы значительно проще, а итоговый код был бы куда читабельнее.
0
К слову, есть у меня мысль на досуге поколупаться с темплейтами… Возможно многие вещи можно будет написать так, что внешне это будут плюсы во всей их красе, а на выходе код будет легче, чем, скажем, писаный с применением SPL. Но это пока только задумка, прежде чем за нее браться надо в потрохах стм32 разобраться досконально.
0
ООП тут, разве что, не мешает писать тяжелый софт.
Не совсем. Тащемта, писать тяжелый софт мешает только ассемблер — ручки отвалятся столько текста набивать. Просто традиционный ООП подход более тяжеловесен, он, в основном, рассчитан на мегастрочные прикладные проекты. На килострочных эмбед-проектах он не так уж нужен (хотя и в определенной степени привлекателен), но расходы на этот подход просто не укладываются в лимиты МК.

БИОС, вообще-то, штука весьма старая и вынуждена сохранять обратную совместимость, естественно, что внешне он не изменится. А вот что там внутри — боюсь только AWARD знает. А вот идущий ему на смену EFI уже посложнее.
0
Смотря что считать традиционным ООП подходом. Если нечто в стиле Буча, то да, там тяжеловесность легко образуется. Если нечто в стиле принятом в той же жабе (короткие иерархии, классы как компоненты), то нет. Собственно, я еще когда писал на плюсах вышел на похожий подход и он аж никак не более тяжеловесен, чем чистый С. Собственно, там неоткуда взятся тяжеловесности. К слову, то, как задуманы библиотеки в ардуине — сделано именно в таком — компонентном — стиле. И к тяжеловесности там приводит, разве что, неумеренное употребление наследования (то есть, как раз, отступление от исходной задумки). Даже если просто описать всю периферию той же STM-ки в виде классов и сделать статические экземпляры для каждого инстанса, и то это заметно упростит жизнь программисту, при этом тяжеловесности там просто неоткуда взятся, результат будет ничем не хуже (а то и лучше) SPL по накладным расходам (а если часть самых коротких методов описать в виде инлайнов, то будет точно лучше).

P.S. есть мысль что-то подобное сделать на основе F4 порта libmaple, но планов и так на месяцы вперед, когда руки дойдут поглядеть глубже — не знаю…
0
Наследование и полиморфизм все же основа ООП, если от них отказываться и использовать только инкапсуляцию — это уже не ООП подход, а компонентный. В некоторых случаях он и больше подходит. А в некоторых нет.
0
Отчасти так оно и есть. Но, во-первых, в разумных пределах вполне можно использовать и наследование (ну там базовый таймер, таймер общего назначения, адвансд таймер вполне должны вписываться). Оверхеда тут нет и, по сравнению с чистым С, многие ошибки можно отловить на этапе компиляции (например, попытку использовать возможности таймера общего назначения у базового). Полиморфизм штука такая, он может быть (если он к месту), а может и не быть. В «большой» системе полиморфизм в сочетании с интерфейсами весьма удобен для «сборки» или перенастройки системы, но в ембиддед системе это не нужно в силу значительно меньшего размера системы вцелом. Ну и, наконец, я не пурист, и руководствуюсь, в первую очередь, удобством, а настоящий это ООП или не совсем — мне плевать. Хоть горшком назови…
0
С P.S. я пожалуй не соглашусь. многое из «не нужного» ембедеру является крайне ему же обязательным. И уж тем более тестирование.
А по сути: ну началось, пошли в оффтоп холливар устраивать.
0
Я не говорил, что это ему не нужно. Скорее наоборот, печально, что это не есть нормой.
0
Насколько я понимаю, под тестами здесь не тестирование на отлов ошибок понимается, все же, а методология Test Driven Development. Она и в прикладном-то программировании, AFAIK, далеко не везде применяется, а уж в эмбеде и подавно «обязательной» не является.
0
Кстати, пока платы без маски делал, тоже на TDD перешел: припаял несколько компонентов — проверил на залипухи. Если все в порядке — паяю дальше, если нет — ищу где накосячил (благо припаял мало, локализовать легко). В итоге времени на поиск и устранение ошибок монтажа уходило на порядок меньше :)
0
Андрей,

а про портирование V-USB под STM8 услышим рассказ?… обещал ) ждемсъ!
0
  • avatar
  • valio
  • 07 февраля 2012, 22:04
Во первых, у автора отпала необходимость в сабже.
Во вторых, есть некоторые проблемы технического плана.
0
… не стал встревать в ту вялую препалку, там ZiB вроде все ясно объяснил. Сама статья очень не объективная, мягко выражаясь, и аффтар не очень-то стремился быть изобретательным, имхо.

Но есть слух, что в ST будет рассматривать вопрос про юсб для старших 8-ок, но это случится не раньше этой зимы. К лету же готовится другой приятный сюрприз для разработчиков и поклонников данного семейства.
0
Гм. По моему объяснил скорее angel5a. Но легче от того не стало — из флеша малопредсказуемое время выборки, а из ОЗУ медленно. А V-USB вся построена на циклах ожидания и высчитанных тактах.
Но есть слух, что в ST будет рассматривать вопрос про юсб для старших 8-ок, но это случится не раньше этой зимы.
Прогресс. Но зима же уже кончается вроде? Или это к следущей?
К лету же готовится другой приятный сюрприз для разработчиков и поклонников данного семейства.
А именно? Или пока неизвестно?
0
8L учебный курс. Часть 1
Стоит ли ожидать ближайшее время? :)
0
  • avatar
  • Onic
  • 15 февраля 2012, 17:50
Раньше чем через пару месяцев от меня не стоит ждать ничего кроме мелких заметочек :)
0
Гляди, такими темпами я раньше навояю, недождавшись тебя :)
0
Да можем вообще совместно запилить :) Только на конкурс его тогда не подашь
0
Ты пость на конкурс, а у меня и так лпц-шный курс отпостен.
0
Я думаю напишу пару статеек про переферию, но кастомное её использование, а не перевод даташита. т.е. «Требуется такой режим — настроили его так. Остальное нам до фонаря».
0
Я тоже об этом думал — взять самые популярные задачи и описать их решение. Но все равно хоть немного о других возможностях сказать стоит
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.