Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Библиотеки для STM32
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2, 3, 4, 5, 6, 7, 8
juvf
Где можно подчерпнуть библиотеку для процессора stm32L030?

Раньше библиотеки можно было скачать с сайта st.com
сейчас их там нет. например библиотека stm32f10x standard peripheral library была тут, сейчас там "SORRY, PAGE NOT FOUND". Что то поменялось у ST? Теперь библиотек нет? Или они их в куб убрали?
arhiv6
SPL тут лежит. Но STM вместо SPL теперь HAL продвигает. Где его скачать отдельно - не знаю, но он есть в составе CUBE (+ pdf с документацией). + для этой серии МК есть сниппеты кода.
Эдди
Нет их. Пользуйтесь сниппетами. Я сам отказался уже для F0-серии от глюкавого opencm3 и пользуюсь только регистрами.
Вообще не вижу смысла на таких дохлых МК еще и калокубом пользоваться... Любителям калокуба нужно что-то жирное, с мегабайтом флеша и как минимум 96МГц.
juvf
Цитата(arhiv6 @ Mar 3 2017, 08:26) *
SPL тут лежит.
Спасибо. Но это для stm32F0**. А для stm32L0**?


Цитата(Эдди @ Mar 3 2017, 10:38) *
Я сам отказался уже для F0-серии от глюкавого opencm3 и пользуюсь только регистрами.
можно и регистрами напрямую... но нужен как минимум stm32l03***.h, ну и стартап не помешает.
MoskWin32
Цитата(juvf @ Mar 3 2017, 09:22) *
А для stm32L0**?


Цитата
STM32CubeL0 gathers together, in a single package, all the generic embedded software
components required to develop an application on STM32L0 microcontrollers.


http://www.st.com/content/st_com/en/produc...tm32cubel0.html
В самом низу на странице ссылка на библиотеку

arhiv6
Цитата(juvf @ Mar 3 2017, 13:22) *
Спасибо. Но это для stm32F0**. А для stm32L0**?

Ой, просмотрел. Для L0 есть HAL, есть сниппеты. А вот SPL для них на глаза ни разу не попадался.
demiurg_spb
Цитата(Эдди @ Mar 3 2017, 08:38) *
Я сам отказался уже для F0-серии от глюкавого opencm3

Чем не угодил libopencm3?
И почему бы не пофиксить багу и отправить патч?
PheeL
Кстати, просветите насчёт сниппетов, пожалуйста. Насколько я понял ST отказалась и от них тоже, заменив на HAL Low Level Drivers. Это макро-обёртки над регистрами периферии которыми пользуется верхний уровень самого HAL, но если для каких-то драйверов он избыточен и не применяется, то позволяется напрямую пользоваться этими макросами. Причём, поскольку это тоже относительно новое веяние, то например для F4 серии их я не заметил, хотя в HAL для других линеек они присутствуют.
jcxz
Цитата(juvf @ Mar 3 2017, 08:22) *
можно и регистрами напрямую... но нужен как минимум stm32l03***.h, ну и стартап не помешает.

Самостоятельное написание stm32l03***.h с описаниями регистров периферии занимает времени меньше чем Вы тут потратили на написание постов и поиски "библиотек". laughing.gif
Utyff
Цитата(juvf @ Mar 3 2017, 09:22) *
можно и регистрами напрямую... но нужен как минимум stm32l03***.h, ну и стартап не помешает.

Снипеты это и есть небоходимые sytem* и startup* файлы с макросами. И примеры/шаблоны их применения.
Похоже ST отказалась от SPL для L0 и F0 серий и сделала снипеты.
http://www.st.com/en/embedded-software/stm...roductId=LN1898
scifi
Цитата(Utyff @ Mar 3 2017, 18:21) *
Снипеты это и есть небоходимые sytem* и startup* файлы с макросами.

Интересно, чем так страшен стартап? Вот, к примеру, мой:
CODE
#include "stm32f0xx.h"
#include <string.h>

extern char __etext, __data_start__, __data_end__, __bss_start__, __bss_end__;
extern int main();

static void
trap(void)
{
for (;;) ;
}

static void (*vectab[])(void) __attribute((used, section(".vectab"))) =
{
trap, // NMI
trap, // HardFault
// [UART_IRQN + 16 - 2] = uart_handler,
// [TIM2_IRQn + 16 - 2] = tim2_handler,
};

void __attribute((used, noreturn))
Reset_Handler(void)
{
// copy-init variables
memcpy(&__data_start__, &__etext, &__data_end__ - &__data_start__);
// zero-init variables
memset(&__bss_start__, 0, &__bss_end__ - &__bss_start__);

(void)main();
for (;;) ;
}

Эдди
Цитата(demiurg_spb @ Mar 3 2017, 16:38) *
Чем не угодил libopencm3?

Когда после очередного обновления у меня ничего не собралось из-за того, что разрабы охрененно порезали API, мое терпение лопнуло!
Я решил, что только nolib может спасти ситуацию. А наиболее употребимые штуки можно в макросы или static inline запихнуть.

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

Ну и все, можно у меня на гитхабе глянуть, что получилось.
scifi
Цитата(Эдди @ Mar 3 2017, 18:27) *
Когда после очередного обновления у меня ничего не собралось из-за того, что разрабы охрененно порезали API, мое терпение лопнуло!

Для тех, кто в танке, они честно признаются заранее: "The API of the library is NOT yet considered stable! Please do not rely on it, yet! Changes to function names, macro names etc. can happen at any time without prior notice!"
Или вы любите ходить по граблям из любви к искусству? biggrin.gif
Эдди
Ну, я раньше на это не обратил внимания.
Иначе, если бы сразу перешел на регистры, а не метался между всякой дрянью (сначала даже SPL пробовал, но буквально на одном проекте понял, что то говно), намного меньше времени бы потерял!
juvf
Цитата(jcxz @ Mar 3 2017, 19:31) *
Самостоятельное написание stm32l03***.h с описаниями регистров периферии занимает времени меньше чем Вы тут потратили на написание постов и поиски "библиотек". laughing.gif

))) я потратил на написание постов суммарно минут 5. во вторых своя библа кроет кучу граблей и требует время на отладку. если нет выверенных путей, придется свой велосипед городить ))
Genadi Zawidowski
Цитата
страшен стартап? Вот, к примеру, мой

стек забыли
scifi
Цитата(Genadi Zawidowski @ Mar 3 2017, 22:22) *
стек забыли

Код
SECTIONS
{
    .text :
    {
        __vtab_start__ = .;
        LONG(__StackTop)
        LONG(Reset_Handler | 1)
        KEEP(*(.vectab))
        *(.text*)
Genadi Zawidowski
"огласите весь список, ппожалуйста!" ©
Похожий шок я испытал, когда разбирался с тексасовским проектом, где адреса периферии назначались в линк-скрипте (а каждое устройство жило в своей секции). Это же надо так запутать...
dxp
QUOTE (scifi @ Mar 3 2017, 22:26) *
Интересно, чем так страшен стартап?

+1.

QUOTE (scifi @ Mar 3 2017, 22:26) *
Вот, к примеру, мой:
<...>

Или вот.
Эдди
Цитата(dxp @ Mar 4 2017, 07:59) *
Или вот.

Спасибо за ссылочку! Форкнул на всякий случай.
jcxz
Цитата(Genadi Zawidowski @ Mar 4 2017, 01:16) *
Похожий шок я испытал, когда разбирался с тексасовским проектом, где адреса периферии назначались в линк-скрипте (а каждое устройство жило в своей секции). Это же надо так запутать...

А что в этом неправильного? Это основная задача линкера - распределять адресное пространство.
Точно так же можно в icf-файле IAR определить адресные пространства периферии.
zltigo
Цитата(jcxz @ Mar 4 2017, 13:43) *
А что в этом неправильного? Это основная задача линкера - распределять адресное пространство.
Точно так же можно в icf-файле IAR определить адресные пространства периферии.

Неправильно, что то, что можно и НУЖНО делать преносимыми средствами языка, делается непереносимыми средствами инструмента. Появляется нахренненужная привязка и инструменту. Точнее, конечно, "нужная", но только тексасу пытающемуся таким образом подсадить недалеких потребителей и на свои инструменты, и свои контролеры. Такая же фигня в общем и у IAR - хидеры ваяют со своими "расширениями" с той же целью.
pitt
Цитата(zltigo @ Mar 4 2017, 09:27) *
Неправильно, что то, что можно и НУЖНО делать преносимыми средствами языка, делается непереносимыми средствами инструмента. Появляется нахренненужная привязка и инструменту. Точнее, конечно, "нужная", но только тексасу пытающемуся таким образом подсадить недалеких потребителей и на свои инструменты, и свои контролеры. Такая же фигня в общем и у IAR - хидеры ваяют со своими "расширениями" с той же целью.

Agreed 100%
SSerge
Цитата(pitt @ Mar 4 2017, 22:08) *
Agreed 100%

Так-то оно так, да вот беда - в С не предусмотрено стандартных средств для назначения объектам реальных адресов.
Впрочем для процессоров где периферия отображается в общее с памятью адресное пространство (типа ARM или MSP430) эти средства не особо нужны, можно обойтись указателями на регистры периферии.
Шаманъ
Что-то я не понял про привязку. У меня таблица векторов выглядит так:
Код
__attribute__ ((section(".isr_vectors"))) void (* const __vectors[])(void) =
{      
    &_estack,           /* The initial stack pointer */
    Reset_Handler,              /* Reset Handler */
    NMI_Handler,                /* NMI Handler */
    HardFault_Handler,          /* Hard Fault Handler */
   .........................


В скрипте линкера прописывается куда положить какую секцию и собственно все.
Genadi Zawidowski
А есть люди, кто этот массив частично описывают в программе, частично собирают в скрипте линкера. Вот я глядя в исходник и ошибся, считая сто там ошибка (неполная таблица).
jcxz
Цитата(Шаманъ @ Mar 5 2017, 09:04) *
Что-то я не понял про привязку. У меня таблица векторов выглядит так:
В скрипте линкера прописывается куда положить какую секцию и собственно все.

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

Цитата(Genadi Zawidowski @ Mar 5 2017, 12:12) *
А есть люди, кто этот массив частично описывают в программе, частично собирают в скрипте линкера. Вот я глядя в исходник и ошибся, считая сто там ошибка (неполная таблица).

Скорее такие люди просто надёргали кусков отовсюду, не разбираясь и не понимая.
Шаманъ
Цитата(jcxz @ Mar 5 2017, 23:34) *
Скорее такие люди просто надёргали кусков отовсюду, не разбираясь и не понимая.

Ну зачем же так сразу - некоторый смысл может быть если применяется загрузчик.
jcxz
Цитата(Шаманъ @ Mar 7 2017, 06:08) *
Ну зачем же так сразу - некоторый смысл может быть если применяется загрузчик.

И какой смысл? И при чём тут загрузчик?
Шаманъ
Цитата(jcxz @ Mar 7 2017, 12:57) *
И какой смысл? И при чём тут загрузчик?

Ну проявите фантазию wink.gif
yanvasiij
Для этого же проца не нашел в свое время SPL. Пришлось сделать HAL. Немного не привычно, но не страшно, разобраться можно.
Эдди
Цитата(yanvasiij @ Mar 10 2017, 20:46) *
не нашел в свое время SPL. Пришлось сделать HAL.

Ничего себе, это ж просто деление на нуль!
Ладно еще, когда народ по своей абдуринской привычке эти монструозные библиотеки на F4 или F7 пихает, но на F0 это просто жесть!
Неужто сложно прочесть тоненький RM?
yanvasiij
Это избитая холиварная тема, спорить на которую можно долго и нудно, самое главное бесполезно. Вы не обессудьте, что я выскажусь и на этом закончу, не вступая далее в полемику.
Смысл такой: что spl, что hal, что opencm3 дают очевидные, на мой взгляд, преимущества:
1) не нужно тратить время на написание драйверов с нуля, при том что когда пишешь драйвера с нуля точно также допускаешь ошибки (выше по теме Вы можете это наблюдать). От чтения RM это конечно не освобождает, без этого никак. Там есть ошибки - не страшно, они отлавливаются на раз-два, было бы терпение и потом многократно используются.
2) hal, opencm3, и даже spl в отличии от самописных библиотек поддерживаются разработчиками и сообществом. Они развиваются и их функционал расширяется, ошибки внутри устраняются. Самописную же либу, поддерживает только один разработчик.
3) Тот же hal тянет за собой массу дополнительных библиотек (стек tcp, файловую систему, стек usb и прочее). Вы скажете, что это можно поднять самому скачав отдельно? Но зачем делать работу второй раз и тратить на нее время? Не проще ли разобраться в том, что уже сделано?
4) Переносимость между сериями и проектами. Код написанный другим разработчиками под hal, spl, opencm3, легко перенести к себе другому разработчику, который тоже использует hal, spl, opencm3. Это какая-никакая унификация. А если каждый будет колхозить свои библиотеки, тот как обмениваться наработками? Можно но уже сложнее, ибо низкоуровневые вещи нужно переписывать.

А разговоры про избыточность, мне кажется надуманными.
Покажите мне сравнительные тесты, в которых наглядно показывается что по вине hal программа начинает работать в разы медленнее. В моей практике такого не было.
Большее потребление памяти? Сколько раз в жизни у вас было такое, что на cortex процах у вас кончалась память? Если такое и было, то держу пари это точно происходило не по вине hal.
Код громоздкий и непонятный? Это уже чистой воды субъективизм, найдется приличное количество народу, кто не согласится с этим. В добавок ко всему hal достаточно гибкий совсем не обязательно использовать все его конструкции.

Ну вот вообщем такое мое мнение. Извините за оффтоп.
juvf
Цитата(yanvasiij @ Mar 11 2017, 11:52) *
Смысл такой: что spl, что hal, что opencm3 дают очевидные, на мой взгляд, преимущества:
+1. ППКС


Цитата(Эдди @ Mar 11 2017, 10:01) *
но на F0 это просто жесть!
А мне бы SPL для L0 rolleyes.gif
Эдди
Когда я заводил 1-wire через таймер с ПДП, был первый раз, когда я столкнулся с невозможностью реализации задуманного по вине библиотеки. Opencm3 оказалась слишком медленной.
Во всех перечисленных библиотеках очень жирный код. Поражающая избыточность приводит к 1) тормозам, 2) увеличению объема прошивки. Оба этих момента в определенный момент могут подставить подлянку.

На мой взгляд единственным правильным вариантом будет нарабатывать сниппеты. А "обмениваться" быдлокодом смысла не вижу. Самый страшный пример — абдурина. Я тут намедни писал обработчик, работающий с термодатчиком TSYS01. Скачал код для абдурины — думал, шустрей будет. А там такое... Какой-то идиот мало того, что флоаты воткнул, так еще и температуру вычислял по формуле из даташита!!!
Я от такого идиотизма вообще в шоке.

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

И да, т.к. сами авторы опенцм3 говорят, что библиотека еще в стадии тестирования, лучше ею не пользоваться. После того, как они поменяли API, я решил от этой дряни отказаться. Пока ваяю под STM32F0, и очень даже хорошо все идет. Надо будет только USB откуда-нибудь выдрать (из той же opencm3, например), т.к. хочу посредника между USB и CAN на STM32F042 замутить. Да и просто на F103 я привык с CDC работать вместо подключения лишнего переходника на USART.
Baser
Цитата(Эдди @ Mar 11 2017, 15:10) *
... Пока ваяю под STM32F0, и очень даже хорошо все идет. Надо будет только USB откуда-нибудь выдрать (из той же opencm3, например), т.к. хочу посредника между USB и CAN на STM32F042 замутить. ...

Я когда перетаскивал проект с Меги128 на STM32F072 и нужно было в духе времени по-быстрому USB подцепить вдогонку к RS-232.
Так сгенерировал проект на HALе, и первое время, когда с ним разбирался, тоже диву давался тому, как там все понаписано.
Но идеология понятна: разработчики хотели добиться переносимости между ВСЕМИ stm32. Поэтому и эта жуткая многослойность различных макросов друг на друге, когда более сложные низкоуровневые постепенно, в несколько этапов, заменяются на применимые к конкретному процессору. И разделение процедур на несколько уровней для разграничения области видимости переменных и функций - тоже прозрачности не прибавляет. Разбираться в этом - пипец полный, но ведь работает sm.gif

Но глядя на то, сколько у меня суммарно ушло времени на то, чтобы с нуля начал работать проект с USB и прочей периферией, у меня никакого желания нет погружаться сильно в глубь и переписывать библиотеки. Тем более, что периферия у STM32 не такая и простая, как у предыдущих простеньких ПИКов, АВРок и т.д. Частенько разбираешься с HAL (я обычно верхний уровень, а часто и пониже, правлю, выкидывая уж слишком сложные навороты) и видишь манипуляции с флагами периферии, про которые сразу догадаться, что так нужно делать, при чтении документации невозможно.

Так что можно "все взять под свой контроль" - но с годами лучше начинаешь понимать, что это мало где нужно. Время уплотняется, все нужно быстрее, быстрее. Сидишь так, вылизываешь код, а год-два проходит (а часто и меньше) - и никому это уже не нужно - давай гони что-то новое.
Как то так...
jcxz
Цитата(Baser @ Mar 11 2017, 23:49) *
Тем более, что периферия у STM32 не такая и простая, как у предыдущих простеньких ПИКов, АВРок и т.д.

Из всех прочих ARM, с которыми я имел дело, у STM32 самая простая периферия.
А имел дело я и с NXP (LPC17xx и LPC43xx) и TI (Tiva, Concerto, OMAP) и Infineon.
Видна цель производителя: сделать наиболее простую периферию для снижения порога входа для новичков, пускай даже в ущерб функциональности.
Осваивать периферию STM32 не в пример легче, хотя бы потому что приходится читать описания на гораздо меньшее число регистров периферии чем в других МК.
Сужу по собственному опыту.
Например: в том же USART у STM32F4x всего 7 регистров, в то время как у Infineon например - около полусотни в его USIC. И это не считая связанных регистров.
Эдди
Вот если бы STMщики вместо идиотизма с SPL/калокубом сразу написали побольше сниппетов под все серии своих МК, было бы намного лучше!
Ладно, под STM8 не надо — там даташит тоненький и регистров немного, но вот некоторые вещи у STM32 требуют реально много времени. Скажем, с тактированием I2C я часа на три завис, пока разобрался, что к чему. Непонятно, зачем вообще на простецкий и2це столько регистров. Ведь 99.9% устройств никакого "тюнинга" не требуют. Можно было по тактированию один-единственный регистр с предделителем тактовой частоты завести.
jcxz
Цитата(Эдди @ Mar 12 2017, 15:39) *
Непонятно, зачем вообще на простецкий и2це столько регистров.

Жалких 10 регистров - это много????? laughing.gif
В LPC17 их 16, в Tiva - 27, в Infineon - полсотни. STM32 - самый простой из всех.
Если самый простейший МК Вам сложен, то что будете делать на более серьёзном? rolleyes.gif
Alechek
Цитата(Baser @ Mar 12 2017, 02:49) *
Но идеология понятна: разработчики хотели добиться переносимости между ВСЕМИ stm32.

Вот только переносимости ЧЕГО - они, видать, так и не придумали....
"HelloWorld" переносить? Потому как при переносе чего существенного все равно возникают проблемы: то тактирование не то, то DMA не совместимы, и вообще, оказывается, одинаковая периферия на самом деле то разная, возможности не те...
Поэтому в любом случае, придется немного дорабатывать. И коим образом тут поможет кубохал?
juvf
наброс говна на вентилятор продолжаем разговор.... ну не нравиться хал где-то в узких местах.... хотя я бы не сказал, что HAL_GPIO_WritePin() прям уж такая тяжелая... в критичных местах можно использовать от туда же LL_GPIO_WriteOutputPort() из набра Low Layer (LL) drivers. LL - это тоже зло от st?
Эдди
Для set/clear/toggle функции не нужны, делается это элементарно на макросах!
Alechek
Цитата(juvf @ Mar 13 2017, 10:51) *
LL - это тоже зло от st?

Все в жизни относительно. Для ST - SPL\HAL\LL - это очень большое добро. Привязывает пользователей к продукции ST.
Для остальных - кому как. Если нравится кому быть привязаным к одному производителю - пожалуйста.

У меня свой лунапарк в части интерфейса к GPIO и основой периферии (SPI, I2C, UART). Поэтому не не составляет труда переносить код между используемыми камнями.
Если использовать HAL - то это будет просто лишней прослойкой, которая в конкретном случае ни от чего не спасет.
jcxz
Цитата(Alechek @ Mar 13 2017, 11:39) *
У меня свой лунапарк в части интерфейса к GPIO и основой периферии (SPI, I2C, UART). Поэтому не не составляет труда переносить код между используемыми камнями.

Во-во - у меня тоже. С (насколько возможно) одинаковым интерфейсом для разных МК
Velund
QUOTE (jcxz @ Mar 13 2017, 13:41) *
Во-во - у меня тоже. С (насколько возможно) одинаковым интерфейсом для разных МК


И я тоже со времен ARM7 держу единый "стандарт" вызовов для основой периферии (SPI, USART, I2C и т.д.) на которые "верхом" встают драйвера периферии (EEPROM, ADC/DAC, цифровые потенциометры, синтезаторы частоты и прочие мелочи). Под куб написал "обертку", которая приводит форматы вызовов к привычному мне. "Подрываться" и переписывать свои отлаженные и обкатанные на тысячах серийных изделий наработки под каждый "взбрык" индусов, нанятых писать кубы и подобное им - много чести будет.
Genadi Zawidowski
Оооо! Я тоже на таком же велосипеде езжу!
Этажом ниже ATMega, ATXMega (кроме USB), Renesas RZ/A1L, AT91SAM9S, ATSAM3/4S, STM32Fxxxx

Код
// +++ dsp
// Интерфейс к НЧ кодеку
void hardware_audiocodec_enable(void);        // Интерфейс к НЧ кодеку
void hardware_audiocodec_initialize(void);    // Интерфейс к НЧ кодеку

// Интерфейс к ПЧ кодеку или FPGA
void hardware_fpgacodec_enable(void);        // Интерфейс к ВЧ кодеку
void hardware_fpgacodec_initialize(void);    // Интерфейс к ВЧ кодеку
void hardware_fpgaspectrum_enable(void);    // Интерфейс к источнику данных о спектре
void hardware_fpgaspectrum_initialize(void);    // Интерфейс к источнику данных о спектре

void hardware_dac_initialize(void);        /* инициализация DAC на STM32F4xx */
void hardware_dac_ch1_setvalue(uint_fast16_t v);    // вывод 12-битного значения на ЦАП - канал 1
void hardware_dac_ch2_setvalue(uint_fast16_t v);    // вывод 12-битного значения на ЦАП - канал 2


void hardware_spi_io_delay(void);

void cat2_parsechar(uint_fast8_t c);                /* вызывается из обработчика прерываний */
void cat2_rxoverflow(void);                            /* вызывается из обработчика прерываний */
void cat2_disconnect(void);                            /* вызывается из обработчика прерываний произошёл разрыв связи при работе по USB CDC */
void cat2_sendchar(void * ctx);                            /* вызывается из обработчика прерываний */

// Функции тестирования работы компорта по прерываниям
void cat3_parsechar(uint_fast8_t c);                /* вызывается из обработчика прерываний */
void cat3_rxoverflow(void);                            /* вызывается из обработчика прерываний */
void cat3_disconnect(void);                            /* вызывается из обработчика прерываний */
void cat3_sendchar(void * ctx);                            /* вызывается из обработчика прерываний */

void modem_parsechar(uint_fast8_t c);                /* вызывается из обработчика прерываний */
void modem_rxoverflow(void);                        /* вызывается из обработчика прерываний */
void modem_disconnect(void);                        /* вызывается из обработчика прерываний */
void modem_sendchar(void * ctx);                            /* вызывается из обработчика прерываний */

void nmea_parsechar(uint_fast8_t c);                /* вызывается из обработчика прерываний */
void nmea_rxoverflow(void);                            /* вызывается из обработчика прерываний */
void nmea_sendchar(void * ctx);                            /* вызывается из обработчика прерываний */

void hardware_uart1_initialize(void);
void hardware_uart1_set_speed(uint_fast32_t baudrate);
void hardware_uart1_tx(void * ctx, uint_fast8_t c);    /* передача символа после прерывания о готовности передатчика */
void hardware_uart1_enabletx(uint_fast8_t state);    /* вызывается из обработчика прерываний */
void hardware_uart1_enablerx(uint_fast8_t state);    /* вызывается из обработчика прерываний */
uint_fast8_t hardware_usart1_putchar(uint_fast8_t c);/* передача символа если готов порт */
uint_fast8_t hardware_usart1_getchar(char * cp); /* приём символа, если готов порт */

void hardware_uart2_initialize(void);
void hardware_uart2_set_speed(uint_fast32_t baudrate);
void hardware_uart2_tx(void * ctx, uint_fast8_t c);    /* передача символа после прерывания о готовности передатчика */
void hardware_uart2_enabletx(uint_fast8_t state);    /* вызывается из обработчика прерываний */
void hardware_uart2_enablerx(uint_fast8_t state);    /* вызывается из обработчика прерываний */
uint_fast8_t hardware_usart2_putchar(uint_fast8_t c);/* передача символа если готов порт */
uint_fast8_t hardware_usart2_getchar(char * cp); /* приём символа, если готов порт */

void usbd_cdc_tx(void * ctx, uint_fast8_t c);            /* передача символа после прерывания о готовности передатчика - вызывается из HARDWARE_CDC_ONTXCHAR */
void usbd_cdc_enabletx(uint_fast8_t state);    /* вызывается из обработчика прерываний */
void usbd_cdc_enablerx(uint_fast8_t state);    /* вызывается из обработчика прерываний */

/* отладочная выдача через USB CDC */
void debugusb_initialize(void);                /* Вызывается из user-mode программы при запрещённых прерываниях. */
uint_fast8_t debugusb_putchar(uint_fast8_t c);/* передача символа если готов порт */
uint_fast8_t debugusb_getchar(char * cp); /* приём символа, если готов порт */
void debugusb_parsechar(uint_fast8_t c);    /* вызывается из обработчика прерываний */
void debugusb_sendchar(void * ctx);            /* вызывается из обработчика прерываний */



И далее в том же духе:
Код
uint_fast8_t board_getadc_filtered_u8(uint_fast8_t i, uint_fast8_t lower, uint_fast8_t upper);    /* получить значение от АЦП в диапазоне lower..upper (включая границы) */
uint_fast16_t board_getadc_filtered_u16(uint_fast8_t i, uint_fast16_t lower, uint_fast16_t upper);    /* получить значение от АЦП в диапазоне lower..upper (включая границы) */
uint_fast8_t board_getadc_smoothed_u8(uint_fast8_t i, uint_fast8_t lower, uint_fast8_t upper);    /* при изменении отфильтрованного значения этого АЦП возвращаемое значение на каждом вызове приближается к нему на 1 */
uint_fast8_t board_getadc_unfiltered_u8(uint_fast8_t i, uint_fast8_t lower, uint_fast8_t upper);    /* получить значение от АЦП в диапазоне lower..upper (включая границы) */
uint_fast16_t board_getadc_unfiltered_u16(uint_fast8_t i, uint_fast16_t lower, uint_fast16_t upper);    /* получить значение от АЦП в диапазоне lower..upper (включая границы) */
uint_fast32_t board_getadc_unfiltered_u32(uint_fast8_t i, uint_fast32_t lower, uint_fast32_t upper);    /* получить значение от АЦП в диапазоне 0..255 */
adcvalholder_t board_getadc_filtered_truevalue(uint_fast8_t i);    /* получить значение от АЦП */
adcvalholder_t board_getadc_unfiltered_truevalue(uint_fast8_t i);    /* получить значение от АЦП */
adcvalholder_t board_getadc_fsval(void);    /* получить максимальное значение значение от АЦП */
void hardware_set_adc_filter(uint_fast8_t i, uint_fast8_t v);    /* установить способ фильтрации данных (в момент выборки их регистра АЦП */

void hardware_set_adc_filterLPF(uint_fast8_t i, uint_fast8_t k);    /* Установить способ фильтрации LPF и частоту среза - параметр 1.0..0.0, умноженное на HARDWARE_ADCFILTER_LPF_DENOM */
#define HARDWARE_ADCFILTER_LPF_DENOM    128        /* положение фиксированной точки при фильтрации HARDWARE_ADCFILTER_LPF */
Эдди
На русском комментарии делать некультурно, между прочим! Как китайцы читать будут?
ViKo
Цитата(Эдди @ Mar 14 2017, 20:48) *
На русском комментарии делать некультурно, между прочим! Как китайцы читать будут?

Намного культурнее, чем на ломаном английском, от которого англичанина наизнанку вывернет.
Эдди
По крайней мере, он хотя бы поймет, о чем речь!
Вот я смотрю два кЕтайских исходника. У одного комментарии на кетаглийском, у другого — на китайском. Какой исходник я в /dev/null сразу же отправил?
Genadi Zawidowski
Между прочим, на pudn кто-то залил архив моего проекта, переведя readme.txt с русского на китайский.
А началось с того, что я не один раз пытался своего друга, который делает гигантские платы на x51 и Atmega с внешней памятью (компилируя с -O0, потому что иначе проект обваливается) на ARM перетащить. И писал для него примеры кода с русскими комментариями... Не удалось, но к русскому привык.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.