ssvSerge

Очень интересно. Раньше не сталкивался. Спасибо за наводку.

Могу сделать фото, как только увижу. Но это будет не скоро. Что необычного? Это должен быть спиральный нагреватель с парой на конце. Контакты под болты выведены через стенку тигля (не знаю как склоняется это слово). Ожидаемые температуры не велики, но этого я точно не знаю. Высокая точность измерений тоже не нужна. Задача технолога создать, а наша - выдержать температурный профиль. 30-40В входного напряжения и огромные пульсации - это ограничения источника, который уже стоит на объекте. Добавлю: обещают, что всё будет регулярно обслуживаться, но уже понятно, что этого не будет. Задача более или менее тривиальна (пугают только пульсации), но хочется выбрать хорошо себя зарекомендовавшие компоненты.

Частота - PWM, на 100 герцах. Что касается напряжения - то этот вопрос пока в обсуждении. Предварительно это 30-40В нестабилизированной постоянки. Но сильно выше не будет и сильно ниже тоже не ожидается. Есть вероятность, что потери приведут к 27-28 вольтам на входе контроллера (Если будет 30В, то 1-2В мы потеряем по дороге).

Привет всем. Вводные данные: есть удалённая термопара, последовательно соединённая с нагревателем. Напряжение разогрева 30 или 40 вольт (пока ещё не определено), ток до 30А. При поддержании температуры будет меньше. Заверяют, что у-во будет обслуживаемым, но в реальной жизни это будет очень сложно. Теперь собственно вопрос: Посоветуйте хорошо зарекомендовавший себя драйвер MOSFET. Можно как N, так и P транзисторы. Единственное что - нужно уметь отключать оба плеча на время измерения температуры. Спасибо.

Обратился по поводу SDK в личку, но что-то нет ответа.

смысл в том, что сеть - не ethernet, а внутренний протокол а-ля can.

Уже изучаю всю линейку Allwinner. Тем не менее, спасибо за очередную наводку. DSI не нужен, USB не нужен. Сеть не нужна (она отдельно реализована, на доп. процессоре).

Вопрос не в процессоре, а в ОС. Любой процессор (сейчас) ничего не потребляет пока спит. Из-за того, что обычный Linux много жрёт, и поставили андроид. Хотя он там, по уму, нафиг не нужен. Теперь такая же дилемма с этим вариантом. На голом железе можно всё сделать, но не сильно хочется. Это как крайний вариант будет.

Какую интересную тему Вы подкинули с этим Allwinner. Чем дольше смотрим на платформу, тем больше нравится. Вопрос сейчас стоит в потреблении. Если и с этим нормально, то Allwinner точно выиграл. P.S. Мы уже полезли в сторону STM32MP, но там огромные проблемы вылезают.

Очень приятные новости. Преобразователь - не вопрос! Их всё равно пять штук на плате. Чем дальше, тем больше интереса к этому процессору. Еще раз - спасибо.

Я уже не ожидал ответа и не заглядывал в ветку. Признаюсь честно - на allwinner даже не смотрел. Надо будет посмотреть что они там предлагают. Когда-то давно поддержка была на самом нуле. Интересно сейчас что-либо изменилось? Портирован ли "правильный" (sleep в idle) линукс? И, как я смотрю, аудиокодек и питание у него всё равно должны быть внешние. Или я ошибаюсь? Внешнее - не проблема. Проблема в QFP корпусе. Боюсь, что в целом не влезем по габаритам. Но, еще раз - спасибо за наводку.

Добрый день всем. Собственно, ситуация такова: в проектах успешно используется модуль DART-MX6. Сейчас неспешно (не дожидаясь состояния EOL), ищется адекватная ему замена. Кто что посоветует? В принципе, можно рассмотреть и частные проекты. В целом, модуль даже излишне производителен. На нем работает Android, но даже без подключенного дисплея. Наш дисплей подключен по SPI, не штатным MIPI интерфейсом. Устройству нужно: 1) Батарейное питание. Мы почти всё время спим и лишь изредка просыпаемся, по событиям. Из-за этого стоит Андроид. 2) Качественный аудио выход. 3) GPS. 4) Дисплей. Сейчас стоит 240*320 ili9341, подключенный по SPI. 5) Память 8-16МБ для обработки данных (пока уточняем сколько нужно). 6) I2C, SPI, GPIO для подключения рабочей периферии. Проблема в том, что в корпусе места нет. Поэтому чем больше из названного будет в модуле, тем лучше. Как я уже упоминал, можем рассмотреть и личные проекты.

Ну, для начала... Большое спасибо за быстрый и содержательный ответ. Говоря откровенно - это дорогого стоит. А вот что касается самого Microchp - не соглашусь. Ни со страницы процессора R34, ни со страницы модуля WLR089 нет ссылок на документацию. Ну или я не нашел. Это тоже вариант. Есть ссылки на GitHub. Но это вряд ли можно назвать дружелюбным подходом. В репозитории https://github.com/MicrochipTech/atsamr34_long_range_p2p вообще не содержится драйвера ADC. В https://github.com/riotnetwork/samr уже есть. Но на множество процессоров и надо бегать по дефайнам и проверять что у тебя есть, а чего нет. А питание? А тактовые генераторы? А прерывания от GPIO? Для человека, который раньше не сталкивался с ARM от Atmel это всё время.

Добрались мы наконец-то до разработки ПО под SAM 34R. Сказать, что я удивлён - это ничего не сказать. Документации ноль. Всё, что нашлось - набор примеров на GitHub. https://github.com/search?q=topic%3Aatsamr34+org%3AMicrochipTech+fork%3Atrue https://github.com/search?q=topic%3Awlr089u0+org%3AMicrochipTech+fork%3Atrue Вы брали информацию там же? Или есть где-то тайное место, где описаны ADC, прерывания по GPIO и питание? P.S. Процессор как украли. Похоже, что сами про него ничего не знают и не поддерживают.

Спасибо. ClassC может и не причем. Я только начинаю разбираться с темой. Насколько я понял, в модуле уже прошит (или предлагается) какой-то стек. Указав "класс" устройства я управляю графиком передачи и приёма (конечно помимо всего прочего). Опять же, насколько я понял, выбор ClassC позволяет слушать эфир постоянно. Реально будет до 254 датчиков + 1 концентратор. Соединение "звезда". В заголовке пакета находится идентификаторы источника и цели. Так что принимать могут многие, но обработает только тот, кому это адресовано. Если эту логику можно реализовать без всяких "классов", то никто против не будет.