KnightIgor

Я делал на DS2484 именно для общения с DS18B20. Делал упрощенно, в смысле, что исходил из единственного устройства на шине 1-Wire, и не на STM32 HAL, а на, скажем, собственном HAL.

От пиков нет панацеи.

Извините, что встреваю. Просто хочу поделиться граблями. Я неоднократно наблюдал, что (предположительно при пиках питания) может произойти рассинхронизация ADC и DMA, если их отпустить работать самих в циклическом режиме. То есть, может случиться, что в буфере данных произойдет циклический сдвиг: на месте ожидаемой первой выбоки будет вторая, вместо второй - третья, и так по циклу. Это заставляло меня отказаться от полной автономии связки ADC-DMA и пинать ее в прерывании от TC DMA, перезапуская ADC.

Гм, сомневаюсь, что пивом ограничивается, после чего выйдет код косяком

Надеюсь. NL - это Нидерланды имеются ввиду?!

Организационные причины. В какой-то степени. В настоящее время через PC (с использованием HID как туннеля) устройство конфигурируется и, возможно, тонко подстраивается по месту установки. После чего самостоятельно работает, подмигивая светодиодиками :). Устройство может также общаться с внешними датчиками по защищенному радиопротоколу на 868MHz. Задача RPI и вправду вначале заключается в замене PC для вышеуказанных задач, но далее для визуализации состояний, диагностики, перспективы поддержки коммуникации через Интернет и иных целей, которые могут быть раскрыты только после соответствующего соглашения. Попутно отвечу советчикам всё переделать: я вам благодарен за фонтан идей, но позволю себе остаться при своем мнении. Речь о скалируемости устройства: RPI может и не быть. Кроме того, устройство и ПО к нему имеют многолетнюю предысторию развития. Напомню анекдот о том, почему Богу удалось создать мир всего за 6 дней. Программистов, не знающих эту притчу, прошу не беспокоиться.

Я вообще не понял, как устройства по ссылке могут пригодиться. Устройство заказчика - это законченный продукт в корпусе, с разъемами, выведенными "куда надо", антеннами и пр. Оно, в принципе, самодостаточно для выполнения возложенных функций. Интегрировать еще одно устройство со своими разъемами и конструкцией весьма сложно. Например, как соединить по USB плату Raspberry с устройством заказчика? Кабелем с USB-A "Малины" на USB-B устройства внутри? Именно поэтому был выбран CM3 модуль Raspberry, а вся периферия расположена на новой основной плате. На ней же предусмотрено питание CM3 (на TPS65261R), схема для перевода CM3 в режим загрузчика и доступа к нему по USB. О LAN9512 и BCM43438 я уже говорил. Мне требуется помощь программиста, а не аппаратчика или дизайнера корпуса. Железо уже работает, Raspbian запускается, экран работает, touch - тоже. Возможность подключить USB клавиатуру и мышь имеется и функционирует, LAN работает, соответственно соединение с Internet тоже есть. Пока не взлетел WiFi. Таково состояние на сегодня.

Привет коллегам. Так случилось в карьере, что Линух вообще и "Малина" в частности прошли мимо меня: я обладаю общими представлениями, могу установить, запустить, но подточить под железо или сделать приложение под Qt не доводилось. Для заказчика разработано устройство на STM32F, которое выполняет свои функции как предусмотрено. Для конфигурирования устройства пока используется программа на PC под Win, которая общается с устройством через USB. Теперь заказчик решил развить устройство, дополнив его touch экраном, сетью, и т.п. Было решено использовать платформу RPI (так я назову Raspberry Pi) на основе модуля CM3 от Raspberry.org. Была тема Wandboard, но заказчик от этого предложения отказался. Я сделал новую версию платы, на которую устанавливается CM3. На плате я склонировал (в какой-то степени) периферию RPI 3B: за LAN|USB отвечает LAN9512, для WiFi используется модуль WSDB-104GNI, на котором стоит BCM43438, что и на Pi Zero. Raspberian взлетел. Правда, WiFi пока не распознается, т.к. возможно нужно доустановить/доконфигурировать. Задачей RPI будет конфигурирование устройства на STM32F вместо PC и отображение состояния устройства (через USB), коммуникация через LAN и WiFi с внешним миром (удаленная диагностика, управление режимом устройства, и т.п.). Я ищу специалиста-подрядчика, который возьмется за проект в части RPI. За оплату, конечно. Обо всем будем договариваться. Единственное условие: по орг. причинам подрядчик не должен проживать в РФ.

На сегодняшний день за последние 10 лет ничего не изменилось, и на вопрос нельзя дать однозначный ответ: в разных stm32f* - разные I2C. Все начиналось с F1xx, где I2C такой, словно французы его запилили на пикнике, нажравшись бордо и закусив самым заплесневелым сыром. Вроде и F4xx унаследовали этот пьяный бред. Протрезвев лишь через несколько лет, на последующих моделях M0 и M0+ ребята радикально сменили спецификацию, и стало возможным работать, но и этот I2C все еще требует достаточно ручных усилий в отличие, например, от I2C на Кортексах от Atmel (ныне - часть Microchip), где I2C называлась TWI и обеспечивала полные транзакции почти полностью аппаратно. Если под "stm32f*" имеется ввиду действительно F1xx (и, возможно, F4xx), то по нему я высказывался и предлагал решения здесь неоднократно. Основные заморочки: не любит I2C, когда его прерывают, поэтому обработчик прерываний I2C должен иметь наивысший приоритет в системе. транзакции чтения с 1 или 2 байтами (или поведение обработчика, когда осталось принять 1 или 2 байта) требуют особого алгоритма обработки. замечено, что можно влететь в прерывание с набором флагов, не описанных в документации, и если не прореагировать на такую смесь, транзакция рушится. На F0xx все выглядит иначе, гораздо стабильней и проще.

Вопрос, а нужно ли бороть. DWT показывает абсолютное время, ибо щелкает четко с тактом процессора. Разве не это нужно? - измерить время от и до. Делать задержки, исходя из предположения, что NOPы однозначно отражают такт процессора, - путь явно ошибочный ввиду строения процессоров (кэши, prefetch, предсказательное ветвление, хотя это уже не NOP). А еще есть прерывания. Они могут прервать линейку NOP, и все будет насмарку. Хотите точное время - используйте таймеры. Не получается и так? Используйте внешнюю времязадающую периферию.

В сети я не могу найти полную схему RPI Zero W, чтобы подсмотреть. Моя задача: разрабатываемому устройству, которое должно использовать Raspberry CM3 (такой DRAM-подобный модуль), добавить Wifi/BT как у RPI Zero W. У последней в качестве WiFi/BT используется BCM43438, подключенный к процессору по SDIO и UART, а также к еще некоторым GPIO. Вопрос: к каким именно линиям порта? Из-за возможностей ремаппинга в процессоре в качестве кандидатов выступают различные выводы, а мне бы хотелось сделать полный аналог подключения в Zero W, чтобы прошивка взлетала без допиливания. TIA.

0x00200652 - это же RAM? Похоже, проблемы в алгоритме записи во флэш: JLINK грузит сервисную программу (алгоритм) в RAM, с которой общается и заставляет писать во флэш.

Может, пока flash доступна по записи (флаг FLASH_CR_PG установлен), сравнение не срабатывает? Даже если, как пишет Сергей Борщ, у Вашего процессора нет кэш, есть таки какой-то регистровый кэш для операций записи во флэш? Идеи: 1. Изменить алгоритм и вынести верификацию "за скобки" флага. 2. Попробовать __DMB() и иже с ними перед верификацией.

Я не спец в протоколе. Вот нашел https://github.com/fetisov/lrndis

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