[ukpyr 0]

Почему сразу не инициализировать регистры?

если не лень каждый раз копаться в мануале, попутно вспоминая нюансы разных семейств - то почему нет ? Но намного быстрее навести мышку на макрос/функцию, и моментально получить описание и параметры. Если говорить о раздутости библиотеки, нужно с чем-то сравнивать - одно дело авр и несколько кил флеша, другое - десятки и сотни кил в армах. Даже с 32f100C4T6 с его жалкими 16К вполне можно работать даже через библиотеку - у меня простой сбор данных с RTOS на несколько задач занял всего 4К флеш и 0.5К ОЗУ. Если не хватит - элементарно заменяется на другой кристалл.

Изменено 4 октября, 2011 пользователем ukpyr

[dac 0]

Железо все больше и больше усложняется, и честно говоря у меня нет энтузиазма писать под каждую новую платформу свой HAL. Под 8-бит одно, а вот что касается ARMов, то тут уже накручено всего куда больше. В идеале хотелось бы использовать общую RTOS под все платформы(те, которые использую я) и не читать даташиты по 2000 страниц, но пока это только в мечтах.

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

полностью согласен :)

я тоже пошел по этому пути, активно использую библиотеки, и похоже М3 STM32 вытесняет у меня все остальное в проектах, т.к. при цене 40руб в розницу STM32F100C4T6B (TQFP48 7х7мм, 16kFlash, 4k RAM) даже 8-битникам очень сложно составить конкуренцию. Если нужна производительность - тоже конкурентов немного. Особенно с учетом STM32F4. Есть конечно исключения, но немного. Имхо единственная незакрытая ниша для STM32 - малоногие корпуса с большим шагом выводов.

 

насчет общей RTOS - посмотрите TNKernel, имхо вполне возможный вариант, только HAL согласовать :)

 

[zhevak 0]

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

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

 

Понято, что проекты нужно делать быстро. И не в ущерб качеству. Но обсуждаемая библиотека не позволяет ни существенно сократить сроки разработки, ни существенно повысить качество. Пока это есть "нечто". Невнятное и нестандартное. Может быть потом оно станет таким же явлением де-факто, как стандартная библиотека С. Но пока я (лично) не вижу преимуществ ее использования. Разве что поучиться как правильно инициализировать порты...

 

Но разве для этого нужно было создавать целую библиотеку? Мне кажется можно было поступить более просто -- опубликовать несколько статей (а точнее -- документов (datasheet, pdf)) на тему, как правильно работать с тем или иным периферийным устройством. Плюс, несколько примеров кода. Это значительно менее затратно. -- Нет! Решили выкатить понты -- подсадить всех на библиотеку. Ну может и сканает. Вон -- огромная масса сидит на Венде и "программирует мышкой". И ничего, живут! И никакой Линух им нафиг не нужен!

 

Потребителю не нужен качественный товар. Потребитель находится в состоянии перманентного шопинга. Ему постоянно нужно менять свой гардероб и мобильники. И если билиотека позволяет привлечь к разработке ПО домохозяек, то такая библиотека найдет спрос у новых-программистов, которые наводнят рынок своими быстро-созданными поделками. Не, нуачё? Копроэкономика же!

 

PS: Забавно, что из одного холивара (lpc vs. stm) тема перерастает в другой (пользоваться ли готовыми библиотеками).

Ага. Забавно. Но это и проявляется креативность природы человека -- обсуждать то, что интересно в данный момент, а не то что нужно по регламенту. Ну, не трамваи!

 

[MrYuran 29]

PS: Забавно, что из одного холивара (lpc vs. stm) тема перерастает в другой (пользоваться ли готовыми библиотеками).

Есть библиотеки - есть выбор - пользоваться или нет.

Ну и, соответственно, наоборот.

Я сейчас как раз приступил к изучению STM32 и наличие CMSIS и STD_PERIPH_DRIVER очень даже приветствую.

Можно сходу начинать пробовать, а не проводить на форумах недели с вопросами "вот я тут понаписал чего-то, а ничего не работает".

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

"знать архитектуру досконально, вдоль и поперёк" тоже пока не вижу потребности, т.к. она, во-первых, меняется непрерывно со страшной скоростью, а во-вторых, имеет многократный запас по быстродействию и объёму памяти для моих задач.

[zhevak 0]

Ну, а я о чем говорю -- уменьшает порог вхождения в ST-технологии.

А это значит, что STM32 -- минируется на роль народного МК.

Ждем наплыва новых программистов.

 

[КонстантинТ 0]

Так ST контора европейская, и на нее гос деп США влияния оказывать не должен. Но и с нашей стороны есть ограничения на аппаратуру шифрования, которое устанавливает ФСБ и прочие, подобные структуры.

Там ограничения на продажу с американских складов. В фарнелле такой же геморрой. Вот подумываю вкусные вещи везти через Shipito.

 

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

 

Понято, что проекты нужно делать быстро. И не в ущерб качеству. Но обсуждаемая библиотека не позволяет ни существенно сократить сроки разработки, ни существенно повысить качество. Пока это есть "нечто". Невнятное и нестандартное. Может быть потом оно станет таким же явлением де-факто, как стандартная библиотека С. Но пока я (лично) не вижу преимуществ ее использования. Разве что поучиться как правильно инициализировать порты...

 

Но разве для этого нужно было создавать целую библиотеку? Мне кажется можно было поступить более просто -- опубликовать несколько статей (а точнее -- документов (datasheet, pdf)) на тему, как правильно работать с тем или иным периферийным устройством. Плюс, несколько примеров кода. Это значительно менее затратно. -- Нет! Решили выкатить понты -- подсадить всех на библиотеку. Ну может и сканает. Вон -- огромная масса сидит на Венде и "программирует мышкой". И ничего, живут! И никакой Линух им нафиг не нужен!

 

Потребителю не нужен качественный товар. Потребитель находится в состоянии перманентного шопинга. Ему постоянно нужно менять свой гардероб и мобильники. И если билиотека позволяет привлечь к разработке ПО домохозяек, то такая библиотека найдет спрос у новых-программистов, которые наводнят рынок своими быстро-созданными поделками. Не, нуачё? Копроэкономика же!

 

 

Ага. Забавно. Но это и проявляется креативность природы человека -- обсуждать то, что интересно в данный момент, а не то что нужно по регламенту. Ну, не трамваи!

Вы забываете такой момент, что срок жизни кристаллов сейчас гораздо меньше, чем раньше (когда на 51 можно было сидеть 10 лет, хотя я поражаюсь уникумам, которые закладывают AVR в новые разработки). И каждый раз переписывать код - это весьма накладно. Вроде бы несколько лет назад подсели на STR911, теперь его хрен сыщешь. Перешли на STM32F1xx. Сейчас перекочевали на STM32F2xx. Ну думаю все :-) На пару лет можно успокоиться и закупить их на склад. Хренасе, сейчас ждем STR32F4xx из-за VFP. Как говорил EvgenyCD dream-chip (он свой идеальный кристалл вместе c AlexandrY искал пару лет, и похоже так и не нашел).

[zhevak 0]

Вы забываете такой момент, что срок жизни кристаллов сейчас гораздо меньше, чем раньше...

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

 

И каждый раз переписывать код - это весьма накладно.

Код коду рознь!

Я про себя скажу. Я никогда тупо не переносил исходники с одного проца на другой. Мои задачи не подразумевают высокого программирования уровня Васика. мои задачи низкоуровневые -- в основном сбор и частичная обработка данных, отсылка их в комп, работа c кнопочками и LCD-экранчиком. Пишу я в основном на С. Очень-очень редко опускаюсь до ассемблера. И тем не менее при переносе проекта с одного проца (ставшего , допустим, по мере роста проекта слабым) на другой проц, я обычно вношу изменения в код.

 

Может быть где-нибудь на очень больших проектах, где флеши расходуется больше чем 32 кило, имеет смысл закрывать глаза и довериться библиотекам, но у меня не было таких больших проектов.

 

Не знаю. Не знаю. Кому-то нравится писать проги на Бейсике, а кому-то на асме. У людей разные требования.

 

Вроде бы несколько лет назад подсели на STR911, теперь его хрен сыщешь. Перешли на STM32F1xx. Сейчас перекочевали на STM32F2xx. Ну думаю все :-) На пару лет можно успокоиться и закупить их на склад. Хренасе, сейчас ждем STR32F4xx из-за VFP. Как говорил EvgenyCD dream-chip (он свой идеальный кристалл вместе c AlexandrY искал пару лет, и похоже так и не нашел).

А почему Вы считаете, что библиотеки будут жить дольше, чем кристаллы? У кристалла меняется индекс (номер), а у библиотек меняется версия. И то и другое не постоянно. Есть несколько уже много лет существующих библиотек, так сказать -- составляющих основной костяк, их ведь никто не отменяет. Появится новый Кортекс, у которого совершенно другая периферия, другая архитектура (например, чем отличаются Атмеловские процы Мега и Х-Мега), и тогда все структуры инициализации периферии "поплывут".

 

Если библиотека не поднимает уровень абстракции, а заменяет одну сущность на другую, то особого смысла в этом не много. Типа давайте изучать библиотеку, чтобы не изучать железо. Ну, наверно, где-то это и сканает... А изучать и то и другое, мне кажется не очень разумно. Знания железа делают знания библиотеки ненужными. Зачем изучать какую-то библиотеку, если нормально можешь работать с периферией проца? А вот знания библиотеки все равно потребуют погружения в железо. Хотя, опять же, много людей программирует на Васикие и ничего, программируют же! Но Васик дает другой уровень абстракции (по сравнению с С/С++), а библиотека ST только подменяет аппаратные сущности камня программными вызовами и структурами. Т.е. уровень-то остается примерно тот же. Так в чем тайный смысл библиотеки?

 

Про полезность библиотеки можно говорить только через какое-то время. Может она будет новым мощным стандартом , а может канет шуме других многочисленных библиотек. Как знать!

[777777 0]

Потому что структура напрямую в регистры не ложится.

Может я чего-то упустил, но все, что я видел - ложатся. И в функциях помимо простого копирования из структуры в регистры были разве что какие-то ассерты.

 

И вот чтобы а) не грузить голову этими нюансами; б) иметь более высокоуровненвую абстракцию; в) сократить время разработки;

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

 

 

Железо все больше и больше усложняется, и честно говоря у меня нет энтузиазма писать под каждую новую платформу свой HAL.<...>

В идеале хотелось бы использовать общую RTOS под все платформы(те, которые использую я) и не читать даташиты по 2000 страниц

Вот я только что организовал выдачу сигнала слложной формы - там DMA записывает в ЦАП значения из массива, а по окончании он подает запрос другому контроллеру DMA и он записывает в первый DMA адрес следующего массива, который тот должен передавать в ЦАП. Диаграмма формируется только периферией (2 таймера, 2 DMA, ЦАП), без участия процессора. Как вы себе представляете RTOS, которая бы предоставляла такую возможность? Боюсь, что без чтения 2000 страниц даташитов это невозможно.

 

И вообще, любое универсальное (кроссплатформенное) средство будет непременно упрощенным, чтобы использовать только те возможности, которые есть во всех контроллерах, которые оно поддерживает. Следовательно самые интересные фичи, в которых изощряются производители и которыми контроллеры отличчаются друг от друга, не будут поддерживаться. И чтобы ими воспользоваться, придется прочитать даташит.

Изменено 4 октября, 2011 пользователем 777777

[sysel 0]

В рамках оффтопа сделаю вброс ещё одного метода программирования микроконтроллеров:

Embedded Coder от MATLAB.

Тут ещё меньше надо знать специфику аппаратной реализации.

 

Видел демо-проект на семинаре: В Симулинке делают генератор импульсов прямоугольной формы -> Embedded Coder -> микроконтроллер (TMS320F28xxx) -> получаем ногодрыголку (светодиодом моргает).

В симулинке видем это ногодрыганье в реал-тайм.

 

Смотрим код (Сишный) : для дрыганья задействован таймер, никакого лишнего кода (сам был удивлён).

 

Embedded Coder так и для Cortex-ов может, и для FPGA тоже.

 

Подробно в теме не разбирался, но впечатлило.

[ukpyr 0]

В идеале хотелось бы использовать общую RTOS под все платформы

угу, есть такая - называется Protothreads. всего 2 .h файла, без всяких низкоуровневых наворотов - то есть усилий по портированию на любую архитектуру - ровно 0. Добавил несколько макросов для обработки таймеров, задержек, переписал работу с 1-wire, LCD, и USART в многозадачном режиме - теперь это просто пестня... Небольшой проектик спортировал за 1 вечер на AVR, STM8, STM32, и 8051 с минимальными изменениями (несколько макросов работы с портами и UART). Вся основная логика совпадает на 100%.

Изменено 4 октября, 2011 пользователем ukpyr

[ashr 0]

Может я чего-то упустил, но все, что я видел - ложатся. И в функциях помимо простого копирования из структуры в регистры были разве что какие-то ассерты.

Вот кусок функции инициализации АЦП, первое, что под руку попалось. Как видим, поля структуры ложатся в регистры совсем не напрямую.

void ADC_Init(ADC_TypeDef* ADCx, ADC_InitTypeDef* ADC_InitStruct)
{
  uint32_t tmpreg1 = 0;
  uint8_t tmpreg2 = 0;
  ...
  /*---------------------------- ADCx CR1 Configuration -----------------*/
  tmpreg1 = ADCx->CR1;
  tmpreg1 &= CR1_CLEAR_Mask;
  tmpreg1 |= (uint32_t)(ADC_InitStruct->ADC_Mode | ((uint32_t)ADC_InitStruct->ADC_ScanConvMode << 8));
  ADCx->CR1 = tmpreg1;
  ...
}

 

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

??? Остается развести руками. Сказать нечего.

P.S. Если вы не любите кошек, скорее всего вы не умеете их готовить. ;)

 

[777777 0]

В рамках оффтопа сделаю вброс ещё одного метода программирования микроконтроллеров:

Embedded Coder от MATLAB.

Тут ещё меньше надо знать специфику аппаратной реализации.

 

Видел демо-проект на семинаре: В Симулинке делают генератор импульсов прямоугольной формы -> Embedded Coder -> микроконтроллер (TMS320F28xxx) -> получаем ногодрыголку (светодиодом моргает).

В симулинке видем это ногодрыганье в реал-тайм.

 

Смотрим код (Сишный) : для дрыганья задействован таймер, никакого лишнего кода (сам был удивлён).

 

Embedded Coder так и для Cortex-ов может, и для FPGA тоже.

 

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

 

Так и здесь - те возможности, которые отличают один контроллер от другого, эта программа использовать не будет - просто потому, что их нет в других контроллерах и если ты портируешь проект на другой, то она не сможет "скомпилировать" твой проект.

 

 

Вот кусок функции инициализации АЦП, первое, что под руку попалось. Как видим, поля структуры ложатся в регистры совсем не напрямую.

Понятно. Значит придется изучать не только регистры АЦП, но и структуру ADC_InitTypeDef, а также саму функцию инициализации.

 

P.S. Если вы не любите кошек, скорее всего вы не умеете их готовить. ;)

А я ничего и не утверждаю. Я всего лишь спрашиваю, чтобы понять: какие преимущества дает использование этих функций? Вам меня пока убедить не удалось.

Изменено 5 октября, 2011 пользователем 777777

[Flexz 0]

Понятно. Значит придется изучать не только регистры АЦП, но и структуру ADC_InitTypeDef, а также саму функцию инициализации.

Можно поинтересоваться - зачем?

Программа минимум - скопипастить инициализацию из семпла, вообще ничего изучать не надо. А если знать регистры - зачем вам структура и функция?

[topkin 0]

Народ, уже ушли в холивар чистый. Все равно все останутся при своих мнениях, флуд да и только

Просьба к модератором прекратить этот спор или перенести его в новую ветку. Реально интересующиеся выбором между STM32 и LPC придется читать всю эту муть про библиотеки.

[IgorKossak 0]

На этом давайте закончим обсуждать библиотеки, тем более, что они уже неоднократно обсуждались, и вернёмся к теме.

Модератор.