-1
К сожалению, я не могу ничего сказать точно, т.к. на самом деле на создание подобного у меня уходит очень много жизненных (да и моральных) сил.
-1
Дык мой персонаж и есть «среднестатистический человек», посмотрите на название. Вы форумы, другие рунетовские ресурсы читаете? UT61E за $50 долгое время считался, да и до сих пор считается очень многими неоправданно дорогим прибором. А что говорить о безопасности, если цена безопасных брендовых DMM начинается в районе $80-100 и выше.
+1
Спасибо! Получил удовольствие!
Спасибо, хорошая подборка
Хороший, полезный материал.
удачный тематический обзор
статья, полезная
Спасибо всем!
-1
Недавно наткнулся случайно на вот такую «доску развития» с рассейским ARM Cortex-M4F из Воронежа K1921BK01T. Туда какой-то энтузиаст, видимо активно почитывающий EE, тоже запихал ST-Link v.2 на STM32F103C8T6 ЖDDD

Интересно, а кто им разрешил это делать, т.е. устанавливать набортный ST-Link, прошитый злодыйски пизженной прошивкой, без разрешения ST Micro?

Гы-ы, видимо следующая версия сей платки выйдет уже с последним писком моды на EE — пизженным J-Link OB :DDD
-2
evsi недавно высокопарно высказал мне что-то типа: Вы, своими сержантскими шуточками и солдафонским сленгом постоянно, даже уже не замечая этого за собой, каждый раз глубоко оскорбляете нас — ПРОГРАММИСТОВ! :DDD
0
Вот наблюдаю все, как ты все больше и больше разбухаешь здесь, и поэтому, вот все хочу у тебя, VGA, спросить: У тебя видимо амбициозные планы?

не тронь говно — оно не завоняет

Ладно, не буду уже тебя трогать здесь, в этой, так называемой, техн.теме :D
0
Конкретика — это «решите за меня, какие мне лучше библиотеки юзать»? С этим туда же, куда и с запросами «напишите мне код».

Тю-тю-тю, и кто это говорит? А говорит это главный выклянчиватель кода здесь: А покажи как ты это сделал, можно взглянуть на алгоритм, дай исходники посмотреть? И это все под видом — мы же все здесь (в инторнете) на ты и камрады/«коллеги» + open_source там.
-1
Я же в техн.темах — очень скромный и внимательно слушающий человек (ну твою вумную чушь и болтовню я обычно быстро пробегаю глазами и даже уже и не помню через 5 минут). Не зная более-менее техн.деталей чего-то — я обычно ничего не пишу и не спорю на эти темы — зачем толочь воду в ступе и сыпать банальностями. И я никогда себе не позволял сентенций, типа: «Могу только предложить подтянуть Вам программирование и не нести чушь», т.е. не раздувался на пустом месте :DDD

Ну special_topics (на свободные темы), конечно не в счет, там ты уже давно со мной стараешься не сталкиваться, Гы-ы ЖD

P/S Люди поговаривают, что ты тут на админке сидеть подрядился (вырос — забурел Ж). Так вот и скажи-ка мне: кто это минусует мои посты в этой теме?
-2
Техническая дискуссия? С тобой? Лол

Ну не с тобой же? :DDD

С тобой не о чем разговаривать, т.к. ты кроме банальностей больше ничего и не знаешь (о чем уже выше и написано). Ну еще клавы и мышки можно обсудить :DDD
0
Хуета какая-то минусанула — подленько так, мразь, — без объяснения причин. Но вот эти-то минусики в моих тех.постах меня взбесили люто.

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

Горсть ПЖ и «гуру» перетирают то, какие они вумные а-ля «Я прикладник в первую очередь, использовать и курить чужие библиотеки — дело привычное» (А в SPL/HAL ты хотя бы заглядывал? SPL уже больше 6 лет, а HAL больше 2-х — с такими-то «талантами», ты должен знать их наизусть, не говоря уже про пару дюжин проектов с их использованием) или «Могу только предложить подтянуть программирование и не нести чушь».

А так же выдают, как КО, разного рода вумные напутствия и банальности а-ля «Бороться со сложностью можно (и нужно) повышением уровня абстракции» или «Описанное скорее относится к событийно-ориентированному программированию, которое к ООП довольно мало отношения имеет» и т.п. потоки словесной воды. Без всякой привязки к конкретике: к конкретным либам (в которые они уже давно и не заглядывали), коду и т.д.
0
микроконтроллер имеет аппаратную поддержку RS485

Вроде бы RS-485 (как и RS-232) — это просто стандарт физического уровня для USART: какой приемопередатчик будет на выходе стандартного USART порта — такой и будет физ.интерфейс.

Я же уже давал ссылку на описание USART драйвера в стандарте CMSIS-Driver. У кого нет KEIL MDK 5, software_packs для него можно скачать здесь. Например, «STMicroelectronics STM32F1 Series Device Support, Drivers and Examples» (Keil.STM32F1xx_DFP.2.1.0.pack) — это обычный zip-архив, и посмотреть там конкретную реализацию USART драйвера в папке RTE_Driver.

Реализован он только поверх CMSIS:
#include "stm32f10x.h"

Т.е. все закодировано на_ручнике, а-ля Snippets.

Гы-ы :D, хотя тот же драйвер в pack'е для STM32F4, реализован через прослойку пресловутой новой либы HAL от ST:
#include "stm32f4xx_hal.h"

Ну вот и надо дать свое КОНКРЕТНОЕ заключение по этому КОНКРЕТНОМУ софту и стандарту: чего он такого не выполняет, чего якобы бывает нужно, чего там не хватает и что там якобы не застандартизировано и не реализовано.

P/S Советую посмотреть там же и драйвер GPIO — мне лично очень понравилось: всего по страничке чистого кода в каждом файле, горсть заинлайненных коротеньких:
GPIO_PinWrite
GPIO_PinRead
GPIO_PortWrite
GPIO_PortRead

+ горсть небольших функций для инициализации порта:
GPIO_PortClock
GPIO_GetPortClockState
GPIO_PinConfigure
GPIO_AFConfigure

Опять же, весь это регистровый Snippet код сделан только поверх CMSIS:
#include "stm32f10x.h"
0
Это все мелочи, там по ссылке просто examples. Более важны мнения об реализации самого интерфейса API, предложенного ARM, о его элементах и механизмах абстракции.

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

Создание таких абстракций для сферической и более-менее универсальной периферии MCU — это не дело каких-то кодеров с завышенным энтузиазмом или ЧСВ и каких-то дней или недель. Это достаточно капитальный и сложный труд, достойный кандидатского диссера для отдельного человека или же непростая аналитическая работа, выполненная неким коллективом настоящих профи.

Мне, как ремесленнику и человеку среднего ума, просто некогда велосипедировать, да и не охото этим заниматься, и хочется все же положиться на готовое решение этой проблемы от кого-то более-менее солидного и знающего, т.е., например, от ARM. Но окончательное заключение будет все же от мирового сообщества MCU-кодеров и всей индустрии. Т.е. будут юзать это API, станет оно популярным, как FATFs или FreeRTOS, или нет? Но какие-то предварительные заключения все же хотелось бы узнать. Т.к. давно уже хочется иметь какую-то более-менее твердую почву под ногами, и не забивать каждый раз башку очередными Periph Libs от очередного производителя или каждый раз ползать по новому очередному мегахедеру и кодировать на_ручнике.

ARM, по сути, предлагает только готовый и продуманный его спецами стандартный name_space и структуры (т.е. хедеры) + пустые шаблоны файлов.с с прототипами функций API. То, что внутри этих функций, должны уже реализовывать для конкретных семейств MCU эти самые кодеры-регистрщики, юзая name_space CMSIS и свои Snippets.

Вот и произошло совершенно мирное разделение двух непримиримых группировок — «дебилы» библиотечники будут ваять реализацию Application, а регистрщики-даташисты с удовольствием будут работать со своими любимыми битами и ваять конкретную железную реализацию драйверов. Что, кстати, не мешает никому соединить эти две ипостаси в одном лице.
0
Ну и для F7.
0
Для L0 не делали SPL.
0
Под F0 есть SPL v.1.5.0
Её CMSIS точно поддерживает следующие чипы:
#if !defined (STM32F030) && !defined (STM32F031) && !defined (STM32F051) && \
    !defined (STM32F072) && !defined (STM32F042) && !defined (STM32F091) && \
    !defined (STM32F070xB) && !defined (STM32F070x6) && !defined (STM32F030xC)
  /* #define STM32F030 */   
  /* #define STM32F031 */   
  /* #define STM32F051 */   
  /* #define STM32F072 */
  /* #define STM32F070xB */   
  /* #define STM32F042 */
  /* #define STM32F070x6 */   
  /* #define STM32F091 */
  /* #define STM32F030xC */  
#endif
0
Да, использование имен из stm32f10x_gpio.h — это просто чисто эстетический недостаток для перфекционистов. Но использование функций из stm32f10x_gpio.c — это уже ЩАС проблема для него. Он был уверен в незыблемости SPL, и что она будет просто расти горизонтально по мере появления новых семейств.
0
На самом деле — все еще даже хуже.

Щас посмотрел внимательнее stm32plus, конкретно GPIO. Как уже сказал, в \lib\fwlib\fx\stdperiph\ находится SPL, как прослойка. Но дело в том, что использован готовый name_space не только из хедеров в \lib\fwlib\fx\stdperiph\inc\, например, из хедера stm32f10x_gpio.h заюзаны:
enum GPIOSpeed_TypeDef
struct GPIGPIO_Pin_X
struct GPIO_InitTypeDef // Wow! Даже эта старая знакомая!
// ну и продефайненный константы:
GPIO_Remap_XXX
GPIO_PortSourceGPIOX
GPIO_PinSourceX

Но и функции, да, КАРЛ!, ФУНКЦИИ!
// конкретно вот эти функции:
GPIO_PinAFConfig
GPIO_WriteBit
GPIO_Write
GPIO_ResetBits
GPIO_SetBits
GPIO_ReadInputData
GPIO_ReadInputDataBit
GPIO_StructInit
GPIO_Init

Не поливая совершенно грязью саму библиотеку stm32plus, можно сказать: она была сделана как надстройка над SPL, которую (как показала жизнь) нельзя считать твердым фундаментом или даже некой устойчивой и постоянной прослойкой (под коей, я лично, вижу щас только CMSIS-Driver + свой Snippets код внутре него).

По хорошему, stm32plus надо переписывать под HAL или лучше просто сразу над CMSIS для STM32, а еще лучше — над CMSIS-Driver, что даст еще и переносимость между MCU разных производителей, но тогда это будет уже не stm32plus, а CortexMplus.

Или же просто юзать CMSIS-Driver, ну и писать(копи-пастить) самому его драйвера для конкретного MCU.
0
Посмотрел я всё это. Ну и оно как-то не очень.

Ответ так себе в квадрате.

Что Вы там посмотрели? Что Вам не понравилось конкретно и в каких драйверах? Не понравилась реализация функционала самого API, предложенного ARM, его уровень абстракций (как любит говаривать evsi), конкретная реализация KEIL'ом функций этого API для конкретного MCU? Ну вот почему не взять допустим LPC1700 и STM32F1 в MDK software_packs и сказать, что конкретно не понравилось в драйверах USART, например (в функциях USART_Initialize, USART_Receive, USART_Send, USART_Transfer и т.д.)?

P/S
Ваша самопальная прослойка (подобного в СЕТИ много энтузиасты наваяли) НЕ НУЖНА никому (хотя бы потому что другие или тоже считает себя умнее остальных и будут юзать свой велосипед, или же они к нему уже привыкли и он им удобнее), тем паче над SPL, которая в свою очередь УЖЕ никому не нужна (кроме поддержки old projects), получается: все это НЕ НУЖНО никому В КВАДРАТЕ.
0
Создатель же либы libopencm3, так же упоминавшейся кем-то, решил ваще героически попилить якоря напильником и совершил марафонские забеги — попереписал портянки мега-хедеры из состава CMSIS в виде кучи своих файлов, см. например, в каталоге \include\libopencm3\stm32\fx. Как и файлы CMSIS для ядра, см. \include\libopencm3\cm3.

Т.е., грубо говоря, libopencm3, ваще, NO CMSIS Compliant.
0
Т.е. stm32plus вроде бы 100% CMSIS Compiant, но через прослойку от SPL, которая уже obsolete и NRND.