Странно, однако. STM32F215/217 с такими модулями без проблем продают и даже в Имраде есть, а 415/417 уже нельзя?

http://www.imrad.kiev.ua/search.shtml?qs=S...1&query=any

Будем тогда без встроенной криптографии юзать. В STM32F405/407 ее нет и слава богу.

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

Я использую 144-ногий, но вроде бы в 100-ногом тоже можно.


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

Я точно не знаю, но мои предположения такие:

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

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

Зато в конечном счете у тебя будет библиотека-посредник, с помощью которой незаметно для потребителя ты сможешь рулить свое железо как тебе заблагорассудится. Типа развязать себе руки, а за одно торжественно объявить о какой-нибудь благородной цели -- например, об унификации. Многие программисты-от-Васика поймут твои цели и поддержат твои идеи.

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

Coding convention такой, попытка сокрытия реализации. Не очень удачная правда.
Ну и свою библиотеку для stm32 я писал ориентируясь на полноту и последовательность действий в ст-шных либах. Все-таки в некотором смысле документацию они дополняют, может даже заменяют.

Все эти споры бесполезны, у каждого свое мнение, но все же мои 5 копеек.
Железо все больше и больше усложняется, и честно говоря у меня нет энтузиазма писать под каждую новую платформу свой HAL. Под 8-бит одно, а вот что касается ARMов, то тут уже накручено всего куда больше. Согласен, что предоставляемые библиотеки не оптимальны, что от ST, что от того же Atmel и т.д. Но все же это хорошо, что производитель предоставляет такие ресурсы и мы должны им сказать спасибо, хотя такие тенденции диктует рынок.
У вас не возникало идей все писать на ассемблере? Или реализовать лично TCP/IP стек самому? Может вообще отказаться от Windows и жить в DOS?
Ну и что касается меня, то я предпочитаю использовать библиотеки, правда модифицирую в процессе их для себя. В идеале хотелось бы использовать общую RTOS под все платформы(те, которые использую я) и не читать даташиты по 2000 страниц, но пока это только в мечтах.
Ну и на последок - время разработки тоже нужно учитывать, иногда оно критично, и очень даже...

Потому что структура напрямую в регистры не ложится. Во многих случаях требуются промежуточные преобразования с нюансами. И вот чтобы а) не грузить голову этими нюансами; б) иметь более высокоуровненвую абстракцию; в) сократить время разработки; и пишут подобные либы.

P.S. IMHO. Либа от ST кончно не верх изящества, но говорить, что она такая/сякая/вся кривая - это просто не профессионально.

Да и вообще, фигня вида LPC-GPDMACH0->CR=0x12198219 куда менее нагляда и больше ошибок наделаешь, чем в нормальном понятном человеку описании с структурами и нормально и очевидно именованными ёё полями.

Да. Да. Да.
В программировании это носит свой термин -- "синтаксический сахар".
Библитека от ST -- это точно такой же тоже синтаксический сахар.

При всем уважении к ST я рассматриваю коды этой библиотеки только в "учебном" плане. Применять их на практике... не думаю. По крайней мере, я испытываю от этоого какой-то дискомфорт. Такое чувство, что из под ног выбили табуретку, не на что опереться. Или чувствуешь себя в каком-то статусе недо-программиста. Что там (в библиотеке) происходит -- да хрен его знает! Начинаешь залазить, изучать. Теряешь время. А изучив и поняв, приходишь к мысли -- да нафига оно, это универсальное-на-все-случаи-жизни решение нужно! Получается что написать нужный функционал для проекта своими средствами (не прибегая к использованию библиотеки) получается ни чуть не хуже.

Использование библиотеки -- это из области религии. Либо ты ей веришь (веруешь, доверяешь), либо нет. Если нет, то юзаешь свои наработки и опираешься на твердую _аппаратную_ почву, а не ватную библиотеку.

Для чего создана библиотека?

Первая мегацель библиотеки -- сэкономить время дорогого (по стоимости) программиста-разработчика.

Библиотека создана для тех программистов, которые не любят углубляться в специфику камня. Библиотека так же создана для тех, кто непрограммисты вообще: сбацал проект - продал. Сбацал - продал. Сбацал - продал. Я не могу назвать их профи. Извините. Это скорее не программисты, это скорее капусторубы какие-то. Их кредо -- толщина "котлеты", а не глубокие знания камней.

Ну есть еще один тип программистов, которым библиотека пойдет в пору. Это те, кто пишет очень большие проекты. Ну, о-о-очень большие! (с) Жванецкий. Таким проггерам, действительно, отвлекаться на регистры и биты -- мелко. Если они берут проц под свой проект, то как минимум с 256 килограммами флеша. Не мелочатся. Не когда. Ибо задачи у них реально -- космические. Но я как-то больше сталкиваюсь с программерами, которые пишут свои обычные проги, объем которых несколько единиц-десятков килобайт. И мне есть чему поучится у них.

Вторая мегацель -- привлечь к программированию камней как можно больше людей. (Блин, стихами заговорил!)

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

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

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

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

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

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

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

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

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

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


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

Есть библиотеки - есть выбор - пользоваться или нет.
Ну и, соответственно, наоборот.
Я сейчас как раз приступил к изучению STM32 и наличие CMSIS и STD_PERIPH_DRIVER очень даже приветствую.
Можно сходу начинать пробовать, а не проводить на форумах недели с вопросами "вот я тут понаписал чего-то, а ничего не работает".
Ну а если вдруг когда-нибудь (чем чёрт не шутит) придётся вникать конкретно и поглубже, то останется просто подробно прочесать соответствующий раздел мануала и исходник библиотеки.
"знать архитектуру досконально, вдоль и поперёк" тоже пока не вижу потребности, т.к. она, во-первых, меняется непрерывно со страшной скоростью, а во-вторых, имеет многократный запас по быстродействию и объёму памяти для моих задач.

Ну, а я о чем говорю -- уменьшает порог вхождения в ST-технологии.
А это значит, что STM32 -- минируется на роль народного МК.
Ждем наплыва новых программистов.

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


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

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


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

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

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


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

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

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

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


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



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

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

В рамках оффтопа сделаю вброс ещё одного метода программирования микроконтроллеров:
Embedded Coder от MATLAB.
Тут ещё меньше надо знать специфику аппаратной реализации.

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

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

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

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

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

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



??? Остается развести руками. Сказать нечего.
P.S. Если вы не любите кошек, скорее всего вы не умеете их готовить.

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

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



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


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

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

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

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

Из STM32 или LPC в последнее время всё чаще выбираю ПЛИС. Потому что и у STM32 и у LPC есть такая штука как ограничения на использование переферии, и там и там возникает такая ситуация что либо PWM не хватает критически или АЦП либо шумит либо имеет дурацкие ограничения, либо активируя одни блоки блокируешь другие блоки, например SSP и I2S перекрываются, аналогично в STM32. Из за специфики задач (цифра в режиме реального времени порой до 20-50мегагерц десятками каналов) всё проще использовать ПЛИС, даже если можно тоже самое применить на DMA v ARM. И ещё что у плис проще - как тебе надо так и разместил выводы и тем самым можно уместить на двухслойную плату в 0.2кв дм всё что нужно.

ПЛИС хорошая штука стоит только дорого... ну очень дорого. тем более ацп там внешний приходится вешать (внутреннего нету ). А выводы удобно конечно, но цена решает слишком многое

Без холиваров жизнь скучна.

Я года 3 назад выбрал LPC. Сначала на LPC2368 делал потом перементнулся на LPC1768.
Выбор был из-за разнице в цене в 2 раза для сопостовимых параметров.

Теперь встает вопрос с памятью, да и производительности мало не бывает. А сейчас похоже ST начал опережать LPC. При одинаковой цене заметно лучше параметры. У меня Ethernet и других задачь достаточно, что бы загрузить и по быстродействию и RAM и Flash. Что делать?

Надеюсь дождатся Zynq-7000, потому что все равно мне приходится с FPGA систему делать. Кстати на мой взгляд Zynq-7000 как раз и будет серебрянной пулей или dream-chip для меня. А для мелких проектов до сих пор 51 использую, потому что выгодно.

Как раз нужно было что-то наподобие. Долго сравнивал, остановился на STM. Почему? Потому что:
1) У LPC пинауты - это просто кошмар какой-то. Логику и разум разработчиков я не наблюдаю. Ну вот присмотришь себе камень, вроде все при нем. А тут вдруг бац - нужная периферия оказывается взаимоисключающая. Нет, все бы ничего, но альтернативные функции пинов отличаются не меньшей [CENSORED], поэтому некоторые комбинации периферии не получится использовать совсем, хотя казалось бы лапок более чем хватает и периферия есть. Но [CENSORED] разработчиков вносит свою лепту. У STM же напротив все более-менее культурно. Может конечно мне так везло с задачами, но впечатление осталось вот такое вот. Тем более что ST старается не сильно переколбашивать пинауты, что им лишний раз в плюс.
2) Запись флеша. У LPC там черт знает что. Я так понял что NXP вообще постеснялись опубликовать как это делать с их контроллером флеша и вместо этого сватают какое-то свое горбатое API. Вот была мне охота с их глюками разбираться и вообще, а какие гарантии что это их супер-апи всегда впишется в мои требования к тому как и когда я хочу флеш шить? Зачем мне заранее загонять себя в неудобные рамки?
3) Номенклатура у STM32 весьма симпатичная. Вплоть до минимального Cortex M3 за аж целый $1. Что-то NXP таким не может похвастать.

Итого: STM показался мне в целом более осмысленным выводком чипов и в целом как-то более приятное впечатление от них сложилось.

угу, особенно USB+CAN

Ребят, а если посмотреть за горизонт LPC и STM32? TI сейчас готовит некислую линейку с Cortex-M4 на борту. Через месяц обещают кит. Извините, что не в рамках темы... Но сам сижу на LPC и зажат в некоторые рамки из которых хотелось бы вырваться.

еще freescale обещают контроллер DRAM в старших чипах, а energymicro - микропотребление. а ти пусть пока с багами разбираются
но на мой взгляд у STM32 самая сбалансированная линейка М3, М4 причем сквозная совместимость, за исключением нескольких выводов, если это учесть при проектировании, можно ставить от STM32F100 до STM32F417

А я после нехилого пролета с TI перешел на LPC... Пролет был с LM3S9В9х - кит появился, начал делать на нем, даже несколько сэмплов удалось достать. А потом у них резко начала расти Errata (кстати, один Workaround я им подарил, они мне за это киты меняли:-)) и чипов стало не достать... Не выдержал, перетащил все на LPC. Да и подешевле они оказались.

Работали с SAM7S/SE/X, LPC21/23/17, сейчас делаем проект на STM32F1xx,есть такие замечания:
- 16-битные таймеры (у LPC17 - 32-битные, используются в программах)
- 17 штук разных таймеров, в разных моделях, 6 разных подтипов ("тут играть, тут не играть, тут рыбу заворачивали (с)")
- разбитая на кусочки область хранения данных под батарейкой (два набора 16-битных backup регистров "несплошняком")
- два разных контроллера USB в семействе
- неважная документация - излишне раздутая, сделана копи-пастом, без акцента на различиях однотипных блоков
- "сваренная из топора" периферийная библиотека, к тому же не всегда полезная даже как пример
- нет документации по замещению встроенного заводского загрузчика
- мутное описание ремапиннга пинов между периферийными блоками
А так - само по себе семейство STM32 неплохое, основные претензии у меня пока к документации.

Добавлю еще 5 копеек - у STM очень странный роутинг запросов на DMA - каждый канал жестко привязан к своему набору периферии. И получается что каналов-то DMA много - аж 12, но например SPI1 и UART3 одновременно использовать DMA не могут, такой вот туповатый дизайн.

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

Даташит не поможет. Тут "Reference Manual" читать нужно, качество сего документа - так себе, "индийское".
И я всегда конструкторам давал некоторую свободу - вот мне нужен SPI, берите любой из имеющихся, тасуйте ножки исходя из топологии конкретной платы. Соответственно программные модули написаны так что работают с любым аналогичным блоком. И LPC тут позволял не особо задумываться - все блоки равноценны. А теперь надо вот для STM выполнять перекрестный анализ. Причем убогость архитектуры просто необъяснима - кто мешал ST матрицу/мультиплексор запросов DMA сделать? А OR всех запросов от источников - это сказка просто, биты управления получаются размазаны по нескольким периферийным модулям. Да у меня еще и тактирование модулей отключается - код шерстения этих всех регистров просто тупо раздувается.

Что в сочетании с однобайтным буфером UARTа делает жизнь особенно приятной. У LPC никогда и не думал UART c DMA юзать, а в STM без этого никак...

Господа, вы уточняйте в каком из семейств STM32 вас не устраивает DMA контроллер. Все же DMA в семействах STM32F1xx, в STM32Lxx и особенно в STM32F2xx имеют довольно сильные различия. В последних семействах он стал куда более гибче и сложнее, я еще сам пока до конца не разобрался Проблемы с буфером не вижу в STM32F1x, контроллер позволяет организовывать кольцевые буферы глубиной до 65535

Очередные 5 копеек.
ИМХО, DMA у STM32F1xx реально убог. Там что, про gather-scattering буферов не слышали? Дескрипторы и цепочки из них, спрашивается, где? Вот же ж, мне сейчас прийдется писать программную эмуляцию. Или я чего-то таки недопонял в "индийском" документе?

хмм, собирался на "супердешевые" киты с STM32 поглядеть... и призадумался, однако не погонюсь за журавлем в небе а да приступлю к киту на LPC2368 тем более, что он на столе %-). Возможно UART c DMA одновременно мне и не понадобится но MAC ethernet и/или USB с наличием встроенного DAC, как раз подойдут.

Имхо лучше не бороться с недостатками в описаниях при том что цель устройства будет замена AVR USB с некоторым потенциалом для расширения, и времени на его реализацию ровно столько, сколько останется от основного проекта. Собственно и к AVR USB претензий никаких, но тащить USB длиннее 5м не дешевле интегрированного Ethernet разъема + ETH PHY, а RS232 тяжко стало найти на непромышленных компах (спасибо Интел )

А вот Ethernet MAC, судя по документации, у STM32 лучше чем у LPC17 (скорее он ближе по возможностям к новому EMAC LPC18) - он сам может IP/TCP/UDP суммы считать, но практического опыта с EMAC STM32 у меня пока нету. А из LPC лучше уже смотреть на LPC17 - как более новые архитектурно, менее жрущие и более быстрые, мне 17-ые нравятся намного больше чем 21/23/24-ые. По ножкам на 99.9% совместимы с LPC23 - есть вероятность, что можно просто чип в ките заменить, если будет такое желание.

Сейчас разбираюсь с Low-Power Modes у STM32F100. Мне надо чтобы устройство спало все время в Stop Mode, просыпалось раз в секунду от RTC, выполняло ряд несложных проверок и снова засыпало. Обнаружены такие факты:

- для пробуждения надо дополнительно шаманить с контроллером внешних прерываний EXTI
- выход из Stop Mode по события от RTC _ТОЛЬКО_ по прерыванию/событию ALARM - то есть секундное событие не пробуждает
- значит регистры RTC_ALARM надо перенастраивать после каждого секундного пробуждения - на значение следующей секунды
- настраиваются эти регистры несколько тактов LSE (32768) - то есть относительно долго, и проц все это время в Run Mode , то есть жрет энергию

Таким образом, обычная тонзилэктомия на STM32 превращается в сложную проктологическую операцию.

P.S. ИМХО, библиотечка от ST содержит ошибку в RTC_GetCounter() - что будет если 32-битный RT-счетчик тикнет между моментами считывания его 16-разрядных половинок и будет перенос в его старшие 16 разрядов?

Контроллеры Kinetis от Freescale пробовали? Рекомендую, STM и NXP курят в стороне. Kinetis и по цене дешевле, характеристики и функционал впечатляет.

Не подойдет ли пробуждение мк от сторожевого таймера?

IWDG пробуждение не поддерживает - только сброс, что не очень хорошо, так как хочется состояние программы и внешних портов сохранять таки. А WWDG он тактируется от PCLK1, значит все время PCLK1 должно быть активно. И уже реализован вариант на RTC_ALARM. Но все равно - спасибо за идею!


Да, кинетиксы впечатляют, но, по моей информации, в младших/средних моделях они не дешевле. По цене К30/40 против STM32F100 не играют.

Дык Kinetis это Cortex-M4, а тут все же ветка про Cortex-M3.
А что с доступностью? При быстром поиске нескольких позиций в efind ничего толком нет

KWIKSTIK-K40 можно заказать в efo.ru, цена: 52,50$ + доставка 4-5 недели; в elitan.ru тоже есть, но чуть подороже.
Но, имхо, для изучения Cortex-M4 лучше подождать отладочную плату - STM32F4DISCOVERY, во-первых, дешевле и доступнее, во-вторых, есть модуль FPU.

Разве есть выход из STOP по RTC alarm? Судя по RM0041 (таблица 11), выход из STOP только по прерыванию/событию от EXTI. Кроме того, я не понял, при чём тут LSE (32768), когда

Это я что-то не так прочитал, или вы открыли недокументированные возможности? (Мне бы просыпание из STOP по аларму RTC очччень бы пригодилось!)

Правильно - выход по EXTI. Если посмотрите на трассировку входов EXTI, то увидите что EXTI17 подключена именно к RTC ALARM и генерируется по вектору "position 41 at 0x000000E4". А вот секундное прерывание RTC к EXTI не подключено и поэтому по ALARM выходить из стопа можно, а по секундному - нет.


ИМХО, тут есть два разных тактовых домена - один это тактирование прескайлера и счетчика времени - туда же подвязаны регистры компаратора аларма, и второй домен - это PCLK - тактирование схем доступа с регистрам RTC со стороны периферийной шины. Вот и введена специальная схема синхронизации и настройки регистров. И длится эта настройка, в лучшем случае, два такта частоты тактирования регистров времени, а не PCLK. А тактирование регистров времени осуществляется от LSE (часовой кварц там висит) - с периодом порядка 30мкс. Вот и получается, что работая на 8MГц HSI надо все равно ждать 60мкс, пока регистры аларма синхронизируются и настроятся.


Все с алармом получилось, просыпается каждую секунду, проц жрет в сумме около 30мкА - но у меня там еще АЦП активизируется/калибруется каждый просып. Так что - нет никаких реальных препятствий (индийская документация, конечно, не фонтан, но ведь у нас форум есть ) к выходу из стопа по аларму.