esaulenka

Завести свою собственную переменную, назвать её "предыдущее значение счётчика". По какому-то событию взять текущее значение счётчика DMA, вычислить их разницу (не забыть, что он бегает "по кругу"), прочитать новые данные. Сохранить "новый" счётчик в переменную "старый счётчик". Да, события - это не только IDLE, но и заполнение (или даже половина заполнения) буфера, если пакет длинный. Никак. В кольцевом режиме оно "само" прыгнет на начало, когда надо. PS никогда не пользовался прерыванием IDLE. Это действительно событие "пришёл старт-бит после длинной паузы", как описано в референсе ? А если у меня между пакетами полчаса будет, все полчаса ждать? Как же всё у них через задницу...

Кейлы, иары, 100500 разных эклипсов, MSVS, VSC, QtC, силайон, нетбинс, кодеблокс... Неужели поиск совсем-совсем не работает?..

BlueNRG (order code BLUENRGQTR) и BlueNRG-MS (order code BLUNRG-MSQTR) - это, фактически, одно и то же. Второй пришёл на смену первому (поддержка протокола 4.1, какие-то багфиксы). Первый, кажется, уже не производят (мы три года назад (!) уже закладывали MS). Внутри Cortex-M0 с радиоканалом и своей собственной прошивкой, снаружи SPI-slave. Верхняя часть стека должна выполняться на внешнем контроллере. BlueNRG-1 и BlueNRG-2 - попытка ST'шников догнать и перегнать NRF51/52 и CC13xx. Можно написать и загрузить свой собственный софт, т.е. для простых приложений второй контроллер не нужен. Как оно работает, не знаю, даже отладку запускать не пробовал.

Разговор, напомню, начался с фразы "либы для хост-контроллера бинарные". Весь софт для хост-контроллера открыт. Основное можно посмотреть здесь: x-cube-ble1.zip\X-CUBE-BLE1\Middlewares\ST\STM32_BlueNRG Как скачать x-cube-ble1.zip, думаю, разберётесь. Да, прошивка самого чипа закрытая. Но и у TI, и у NRF точно такой же закрытый бинарник именно ядра протокола. Silabs никогда не смотрел, не знаю. Ну и открытый стек именно на этих BlueNRG вряд-ли кто-то сделает. Документация внутренностей отсутствует напрочь.

Если ВЫ заметили, речь о том, что API BlueNRG и BlueNRG-MS полностью открыт.

Продажники уже сколько-то там тыщщ устройств с этим BlueNRG уже напродавали, а я так и не разобрался, что же именно скачал. Спасибо, что открыли мне глаза.

Правда, что-ли? А каким образом я скачал их библиотеку с API в исходниках? И вообще, там по SPI бегает вполне стандартный протокол, описанный в спецификации блютус (в документации ST так и написано: команды такие-то - в официальной спецификации). Говорить за всех - крайне вредная привычка. Если лишний процессор на плате не пугает (судя по BlueNRG-1, не пугает), рекомендую нордик. У них куча примеров, и с требованиями "мне всё равно что, лишь бы байты переслать" сделать что-нибудь готовое можно очень быстро.

dcs=8 - это корректно? TS 23.038 Alphabets and language-specific information в разделе Cell Broadcast Data Coding Scheme нам сообщает 0000 1111 - Language unspecified (т.е. похоже на значение по умолчанию, 15) 0000 1000 - Portuguese (фигня какая-то). При этом dcs=15 работает. Кодировка в модеме - UCS2. Почему на отправку не работает dcs=72 (0100 1000 - General Data Coding indication, UCS2, class 0), не понимаю. Принятые USSD приходят именно с таким dcs. Чёртов симком. Параметры этой команды в руководстве толком не расписаны. Извольте читать стандарты, о существовании которых вы можете узнать из интернетов или из чтения документации каких-то других производителей.

Рекомендую сначала задавать подобные вопросы в гугл. Очень много интересного вылезает. https://github.com/contiki-os/contiki/tree/master/core/net/ip

Прошу прощения. Читаю "сокет", пишу "сокет", думаю "порт".

Во-первых, там написано не "socket", а "connection". А во-вторых, браузер может одновременно скачивать несколько картинок, чтобы показать их пользователю побыстрее. И это именно одновременные соединения.

/** * The maximum number of simultaneously open TCP connections. * * Since the TCP connections are statically allocated, turning this * configuration knob down results in less RAM used. Each TCP * connection requires approximatly 30 bytes of memory. * * \hideinitializer */ #ifndef UIP_CONF_MAX_CONNECTIONS #define UIP_CONNS 10 #else /* UIP_CONF_MAX_CONNECTIONS */ #define UIP_CONNS UIP_CONF_MAX_CONNECTIONS #endif /* UIP_CONF_MAX_CONNECTIONS */ оно?

Нет. Проверял следующее: подключаемся отладчиком, отключаемся, выдёргиваем разъем отладчика (физически), без сброса устройства ставим RDP. Всё виснет. Достаточно ли дёрнуть ногу резет, или надо делать сброс питания, не проверял - мне проще было щёлкнуть кнопкой на источнике питания.

В порядке эксперимента предлагаю добавить во все (!) обработчики прерываний код "на входе установили ножку в единичку, на выходе в ноль" и посмотреть анализатором. Ну и в критическую секцию аналогично. Ещё одной ножкой хорошо б отображать вход-выход в обработчик EXTI. Чудес не бывает. Сталкивался с "чудом", что сброс флага прерывания непосредственно в самом конце обработчика работает плохо (до NVIC'а это доходит медленно, и прерывание вызывается ещё раз), но это не Ваш случай.

В частном случае (отладить свой собственный радиоканал) - подойдёт. Возможность посмотреть на чужие протоколы - приятный бонус, но если нет, то нет. Но мне казалось, что должно быть готовое. Нашёл некое GNU Radio - собери из кубиков свой собственный приёмник. Там даже кубик TI CC11xx есть :-) Надо будет поиграться...

Для отладки радиоканала хочется видеть трафик в нём с привязкой ко времени. Радио - 868 МГц, FSK. Железная часть сниффера, насколько я понимаю - это китайский DVB-приёмник (см. RTL2832 на алиэкспрессе). Кстати, кто-нибудь разбирался, чем они отличаются? Есть просто приёмники DVB, а есть "типа SDR receiver" (полоса снизу пошире, что-ли...) ? А вот с программной частью кто подскажет? Что-то я видел только всякие приёмники радиостанций и анализаторы спектров. Софт желательно под винду.

USB-host, я надеюсь, на "большом" железе (т.е. с windows/linux) сделан, или тоже какой-нибудь кортекс-м ? А сам PPP в минимальной конфигурации не сильно отличается от любого другого протокола. То же самое разделение на фреймы + контрольная сумма. Ну, избыточно чуток... Вот всякие CHAP'ы уже выглядят ну совсем ненужными.

Да, тут многие так живут, используя описание регистров ядра + периферии и свои велосипеды. Это модный подход, который STM последние лет 5 активно продвигает. Проблема в том, что в нестандартных случаях (шаг в сторону от примера) этот HAL может сломаться. Чинить его (попутно полностью разобравшись, как он устроен) или выкинуть целиком - личное дело каждого, на форуме холивары ежемесячно поднимаются. И HAL построен на описании регистров из CMSIS, они не стали делать точно такое же, но с перламутровыми пуговицами. Соответственно, внутри HAL'а есть CMSIS, и он периодически "торчит" наружу. Насколько я понимаю, у ARM'а когда-то была благая идея "мы сделали одинаковое ядро, а вы, производителе чипов, сделайте универсально-одинаковые драйвера периферии". Идея не взлетела, рекламный слоган "у нас точно такое же, как у всех" работает плохо :-)

Кажется, Сергей Борщ вполне однозначно попросил упражняться в остроумии в другом месте. Спасибо за Ваши бесценные комментарии.

Нету. И фриртоса нету. Есть огроменный бесконечный цикл, прерывание по TIM3, которое дрыгает ножкой, и два DMA, которые перекладывают данные из двух АЦП в память. Ещё UART есть (только на передачу). Ноль. Либо я плохо искал. А эти закладки - вовсе не закладки, а, подозреваю, с++ конструкторы глобальных объектов. Компилятору так удобнее - сделать список и итерироваться по нему. Каких-то других особенностей с++ в коде не обнаружено - никаких перегрузок и прочей динамической памяти. Вероятно, автору интересней всего получить содержимое тех функций, которые пережёвывают вход с АЦП и выдают его в ЦАП. Я ЦОС не умею, поэтому сходу никаких знакомых паттернов там не увидел. Возможно, более грамотный специалист после тщательного допроса автора сразу скажет "здесь делаем преобразование А, потом по этому условию делаем Б и подставляем туда значение из таблицы В". Если автор адекватный (пока обратное не доказано), идеальный вариант - юнит тесты, показывающие одинаковое поведение оригинала и переписанных функций (для каждой функции по пачке тестов). Их всё равно писать надо в обязательном порядке. Железка при этом не особо нужна - проще даже на эмуляторе. Это я пол-дня потратил, мозг размять. Потратить ещё месяц на переписывание мне что-то не хочется...

Нашёл у себя следующие записи: STM library: 0. IRQ 00 00 00 10 – FIFO Level 1. IRQ 00 00 00 10 – FIFO Level 1 IRQ 00 08 00 00 – Out Endpoint 2. IRQ 00 00 00 10 – FIFO Level 2. IRQ 00 00 00 10 – FIFO Level 2 IRQ 00 08 00 00 – Out Endpoint 3. IRQ 00 04 00 00 – In Endpoint opencm3 0 IRQ 00 00 00 10 – FIFO Level 1 IRQ 00 00 00 10 – FIFO Level 1 IRQ 00 00 00 10 – FIFO Level 1 IRQ 00 00 00 10 – FIFO Level 2 IRQ 00 04 00 00 – In Endpoint Цифры - значение USB_OTG->GINTSTS. Отсюда видно, что в ST'шной библиотеке добавляется ещё один источник прерывания, и оно случается немгновенно. Загрузка проца что в одном случае, что в другом была единицы процентов. Как интерпретировать столь многочисленные посылки, сейчас не вспомню. По ощущениям - всё корректно, просто особенность HID'а такая, что там всё через 0-й endpoint работает и перед отправкой собственно данных идёт какой-то служебный обмен. Код не сохранился, ибо тестовый, но, насколько я помню, я просто из винды делал SetReport размером 64+1 байт (т.е. ровно в один эндпоинт). Уж извините за отсутствие конкретики, слишком давно занимался, и сейчас оно в состоянии "работает - не трогай" :-) Так у ST'шек только два варианта USB (device only и OTG), и оба они там представлены. Есть небольшие изменения (типа OTG_FS / OTG_HS, есть/нет собственный DMA), но после небольшого подпиливания всё запускается. Собственно, готовые драйвера на основе libopencm3 со 105-го на 446 процессор перенёс с минимальными изменениями. (а если бы у USB HS не было косяков в спящем режиме - так вообще б за пару часов справился, а не за неделю...).

Да, разумеется, каждый уважающий себя эмбеддер хранит в начале свопа характернейшую таблицу векторов. Угадать по выложенному файлу модель контроллера - пальцем в небо (кто-нибудь помнит наизусть адреса периферийных регистров?), но кортекс узнаётся безошибочно. Ага, конечно. ROM:08005AAE word_8005AAE DCW 1500, 250, 1680, 90, 70, 500 ROM:08005AAE DCW 1502, 262, 1680, 90, 70, 525 ROM:08005AAE DCW 1504, 274, 1680, 90, 70, 550 ROM:08005AAE DCW 1506, 286, 1680, 90, 70, 575 ROM:08005AAE DCW 1508, 298, 1680, 90, 70, 600 ROM:08005AAE DCW 1510, 310, 1680, 90, 70, 625 1500 - это "Юстас", "250" - Алекс. Именно так и никак иначе. Там действительно 25 кило кода (работа с АЦП, ЦАП, ногодрыг несколькими ножками + какая-то непонятная математика в развесистых свичах) и 200 с фигом килобайт таблиц. Переписать десяток килобайт этой математики - задача решаемая, но явно не "студентом за неделю".

Нет, там ровно 64 байта (максимум для HID'а). Но вычитывание данных в той библиотеке - какой-то пинг-понг с прерываниями. Выглядит так, что оно писалось с прицелом на DMA, которого (отдельного для USB) в том камне нету. И да, возможно в более новых библиотеках стало лучше. К сожалению, по памяти детали не расскажу, а подробный отчёт я тогда не составил. Но как заметка на будущее - надо б попрофилировать вызовы из прерываний хотя б банальной записью пары "регистр статуса прерываний + значение микросекундного таймера"...

Когда я смотрел в ту сторону (года 3 назад, HID на STM32F105), там как-то по-дурацки прерывания были организованы. Один-единственный set report растягивался на 4 фрейма (т.е. 4 миллисекунды). Переезд на libopencm3 ускорил обмен вдвое.

Ну так ведь ответ "никакой разницы" - он тоже конкретный и вдобавок ПРАВИЛЬНЫЙ. Почему бы не сказать об этом сразу?.. Я, правда, изначально спрашивал в надежде узнать какие-то тонкости типа "так помехоустойчивость выше, потому что...", про которые в формуле про два слагаемых не упоминается. Ну ладно...