Комментарии 85
PS Фото форм фактора Raspbery PI 3 для примера
Я в самом начале работы думал над этим и с Вами согласен, но только частично. Например, RPi3 имеет на борту аж 4 USB разъёма. Лично я не уверен, что 4 разъёма действительно нужны на подобной плате. Проводная сеть нужна, наверное. Но тут нужно иметь ввиду, что придётся тянуть в код весь TCP/IP стек, чтобы его использовать. Но, как бонус, можно сделать PoE. Сдвоенная гребёнка GPIO на 40 контактов тоже не совсем практична, так как у контроллера в корпусе LQFP64 40 свободных пинов для неё наберётся с трудом. В будущем я думаю сделать вариант с LQFP100, тогда можно будет сделать GPIO, как на RPi3.
Вы предлагаете уже высший пилотаж — LQFP-176. Мне хотя бы на LQFP-100 перейти, уже будет большим достижением для меня.
Разница? Развести это всё богатсво на двухслойной плате. Я не уверен, что у меня LQFP100 получится на этой площади развести. По уму, так нужно бы на четырёхслойную топологию переходить...
Я тоже на эту серию (F476) уже поглядываю. Если переходить на 100-ножечный вариант, то этот контроллер, действительно, неплохой выбор.
Я буквально неделю назад документацию на H7 изучал. Весьма достойный контроллер, только вот цена кусается — в среднем в два раза дороже, чем F405.
inline void setHandler (EventHandler * _handler)
Насколько я помню, inline при реализации метода внутри объявления класса не нужно писать — эти методы и так inline.
А опыт конкретного применения будет?
Надеюсь, что да. У меня в доме установлены Zwave датчики на окнах, красивые, но не работают совершенно в силу большого расстояния до базы. Промежеточные усилители тоже не помогают. Хочу протянуть провода, корпуса датчиков оставить, начинку поменять, и на каждом этаже сделать свой блок на базе этой платы. Уже отлажено всё: сама плата, датчики, прошивка, серверная часть, клиент для Андроида. Осталось только провода по всему дому протянуть. То есть как всю систему запущу и настрою, так и напишу.
Может быть вы и ОС на Форт переведете?
…Я пришёл к выводу, что *действительно* предпочту выгнать любого, кто предпочтёт вести разработку проекта на C++, нежели на Си, чтобы этот человек не загубил проект, в который я вовлечён.
C++ приводит к очень, очень плохим проектным решениям. Неизбежно начинают применяться «замечательные» библиотечные возможности вроде STL, и Boost, и прочего мусора, которые могут «помочь» программированию, но порождают:
— невыносимую боль, когда они не работают (и всякий, кто утверждает, что STL и особенно Boost стабильны и портируемы, настолько погряз во лжи, что это даже не смешно)
— неэффективно абстрагированные программные модели, когда спустя два года обнаруживается, что какая-то абстракция была недостаточно эффективна, но теперь весь код зависит ото всех окружающих её замечательных объектных моделей, и её нельзя исправить, не переписав всё приложение.
Другими словами, единственный способ иметь хороший, эффективный, низкоуровневый и портируемый C++ сводится к тому, чтобы ограничиться всеми теми вещами, которые элементарно доступны в Си. А ограничение проекта рамками Си будет означать, что люди его не выкинут, и что будет доступно множество программистов, действительно хорошо понимающих низкоуровневые особенности и не отказывающихся от них из-за идиотской ерунды про «объектные модели».
… когда эффективность является первостепенным требованием, «преимущества» C++ будут огромной ошибкой.(с) Линус Торвальдс,
Ну и ссылка.
Программирование — это же не только язык. Это и среда разработки, библиотеки, отладчики, документация, сообщество. В какой IDE лучше всего программировать на Форте? Под какие конкретно модели контроллеров уже есть библиотеки, где реалирована поддержка SD карт, файловая система, USB и прочие высокоуровневые протоколы и интерфейсы? Может, действительно напишите туториал, как начать программировать STM32 на Форте?
Для отсчёта времени здесь используется не HAL_GetTick, который в силу своего типа (uint32_t) сбрасывается по переполнению каждые 2^32 миллисекунд (каждые 49 дней). Я реализовал собственный класс RealTimeClock, который отсчитывает миллисекунды со старта программы, или включения контроллера, как uint64_t, что даёт примерно 5^8 лет.
Какой в этом смысл? Получается, что у вас два счетчика аптайма, ваш и системный? Хорошо когда памяти много!
Если устройство работает гарантированно меньше 49 дней, то смысла нет. Если это что-то, что должно работать в режиме 365/7/24, то Вам точно нужно периодическое переполнение системного таймера и целый спектр проблем, с этим переполением связанный?
О каком "спектре проблем" идёт речь?
Любые алгоритмы, где нужно считать длительности каких-либо сигналов либо делать асинхронные задержки фиксированной длительности. Например, сталкивался сам с такой проблемой. Дешифровка сигнала DCF77 в часах: если она происходит достаточно часто, то есть большая вероятность, что это переполнение произойдёт в момент дешифровки, что даст неверный результат.
Именно. В этой статье есть ключевая фраза: "если работа с HAL_GetTick реализована корректно". Пока мы только вычитанием, как в этой статье, то всё в порядке. Но я, например, иногда испытываю непреодолимое желание использовать значения таймеров в условных операторах, и вот там и есть засада.
В этой "ключевой" фразе как раз и кроется причина моего вопроса: почему вместо корректной работы с системным таймером нужно городить огород с оверхедом по памяти. И, кстати, за сколько тактов инкрементится двухбайтное число? Я всё ещё не вижу никаких плюсов. Если дешифровка у вас там происходит давольно часто, а переполнение происходит раз в 49 дней… чорт, я всё ещё не вижу проблемы, которую вы решаете.
Наверное, Вы правы. Похоже, я решил надуманную проблему. Ресурсы этого контроллера (частота и память) позволяют не задумываться о таких мелочах, вот я и сделал, так как мне казалось это удобным.
Ну, я думаю, что всё это решится, как только вы совершите переход от работы со значением таймера к работе с временными интервалами.
Кстати, почему у вас везде интерфейс I2C называется I2S?
Ну, это разные интерфейсы. I2S (Inter-IC Sound) — это программно-аппаратная надстройка над SPI, которая сама, например, осуществляет подбор тактовой частоты и управление каналами в зависимости от аудио-протокола и битрейта. I2C — это более универсальная штука.
А, понятно.
Кстати, многие звуковые двоично-аналоговые преобразователи (например, тот, что стоит на Discovery) используют I2C как камандную шину и отдельно шину данных. Тот, что использую я, требует только шины данных, а общая настройка осуществляется несколькими двоичными пинами. То есть со стороны контроллера данные уходят через I2S, и командная I2C не нужна.
Ваш вопрос, к сожалению, выходит за рамки моей квалификации. И по образованию, и по сфере деятельности я математик, а данный проект — это хобби. Я примерно понимаю, о чем речь в этом вопросе, но ответить на него не могу. Вот здесь лежит файл правил для EagleCad, может быть, он поможет это сказать. Если есть желание, милости прошу переработать разводку платы и закинуть merge-request. Буду только рад такому сотрудничеству!
По другому: какова минимальная толщина линии? 0.3мм?
Расположение трёхцветного светодиода также неудачное. Хочу заменить его на SMD светодиод, вынести на край платы.
Если собираетесь делать следующую ревизию то стоит убрать R6 и добавить 3 резистора на каждый из анодов светодиода отдельно. В вашем же случае при включении нескольких цветов одновременно их яркость будет падать так как R6 ограничивает общий ток.
Для расширения функционала «голубой таблетки» была разработана плата
Gerber файлы прилагаются, можете повторить.
Исправлены ошибки: слабый стабилизатор, 1.5К на USB,…
Для изготовления прототипов, макетирования придумано это
Добавляем в проект то, что интересно, например модули ардуины, коих хватает.
Можно впаять STM32F100, STM32F103 ( Cortex M3 ), STM32F303 ( Cortex M4 )
В том же кубике можно подобрать совместимые по ногам 48-ми ножечные.
Я и сам такое делал. В github репозитории, о котором я пишу в статье, есть набор и таких плат.
Я предлагаю несколько иной взгляд. Уж коль скоро максимально распространенная это «голубая таблетка», то обеспечиваем максимальную совместимость по ногам именно с ней.
Используя макетные паячно-беспаячные платы ( ссылку дал ), можно собирать прототипы из набора «микрокубиков». Вставляя / припаивая всё на макетные платы. Не нужно напрягаться рассудком, как и куда потом всё это «затолкать», в какой корпус.
Нужно поменять/попробовать как будет работать с другим МК — просто поменяли «таблетку», оставив периферию на месте.
После разработки ПО и тестирования прототипа можно «нарисовать» свою плату законченного устройства. Детали прототипа используем далее для разработки чего-то следующего. Если лень, или не целесообразно — используем как есть. Внешний вид промышленного устройства уже есть. Да и провода, в случае беспаячного монтажа хорошо прижимаются крышками корпуса.
Лично мне такой подход тоже нравится. Я даже писал о чём-то похожем на Хабре, с той только разницей, что использовал беспаячную макетную плату. Как-то та статья не зашла. Наверное, не смог хорошо объяснить. Отчасти поэтому, отчасти из-за желания нового я пошёл по пути наращивания и усложнения функционала контроллерной платы, вместо декомпозиции на макетной.
(2×12-bit D/A converters)
2) Усилители и схемы можно подсмотреть у STM, но мне нравится LM4863. Дело вкуса :-)
3) Если у вас линия питания зашумлена, то я бы советовал последовательно после регулятора 3.3В поставить индуктивность (дроссель подавления ЭМ помех). Получится LC-фильтр и всё будет ровно. Схемы и компоненты можно подсмотреть в любых радиомодулях. Там качественное питание критично.
4) У вас линия SD_DET идёт сразу в контроллер. Я бы её к питанию подтянул 100к. Тогда она не будет плавать (z-state).
5) Линия NRST разве не должна быть к питанию подтянута через резистор?
Удачи вам. Буду ждать от вас LQFP100 с памятью DRAM.
Хотелось качественного звука. Внешний ЦАП UDA1334 — это специализированный аудио-ЦАП с разрешением до 24 бит и частотой дискретизации до 100 кГц. Кстати, на STM-Discovery также используется внешний ЦАП, но более навороченный. Спасибо за наводку на LM4863 — интересная штука, поизучаю. Хотя он выходит почти в 3 раза дороже того, что использовал я. За совет с индуктивностью спасибо — обязательно посмотрю. SD_DET я не подтянул внешним резистором, так как при инициализации контроллера я гарантированно успеваю подтянуть его внутренним резистором перед первым использованием. То есть при старте системы напряжение конечно плавает, но это не критично. По поводу NRST: задумался и проверил документ Getting started with STM32F4xxxx MCU hardware development. Вроде нет, резистора там нет, см. Figure 26. JTAG connector implementation на странице 37.
Ну, зачем же Вы так категорично? И "голубая таблетка", и Discovery, и пара Nucleo, и пара плат от Olimex у меня есть. Все они достаточно хороши. В каждой есть изюминка. Мне, например, очень нравятся Nucleo. Как старт работы с STM32 разумно использовать любую из них. Только ведь я не совсем об этом писал. Смысл проекта: нечто, что имеет WiFi, звук, SD карточку и подходит к очень распространённым корпусам от RPi. Ну и на уровне софта несколько больше, чем просто светодиодом помигать.
Для «железа»:
— TAPR Open Hardware License
— CERN Open Hardware Licence
— …
Это сужает спектр возможных применений.
Выше о USB тоже уже писали. Я тоже за то, чтобы его добавить. Предлагаю объединить усилия и поработать над этим совместно. Если есть желание скооперироваться, пишите в личку.
Я сам, честно говоря, внешнюю память ещё не использовал. Можно Вас попросить вкратце написать, какие есть сценарии использования внешней памяти, как это решается на уровне софта (поддержка HAL, поддержка компилятора, обращение для хранения своих данных) и, исходя из этих сценариев, конкретную модель (или модели) микросхем. На какую периферию самого контроллера нужно обратить внимание, чтобы использовать память наиболее эффективно?
2. Решается очень просто. В скрипте линкера заводится область, с началом в нужном банке и нужного размера. Потом всем переменным, которые во внешней памяти лежать должны, прописываете __attribute__ ((section(«секциянейм»))). В скрипте линкера дописывается что-то вроде:
.секциянейм:
{
} > областьнейм
Это в случае с GCC, но для IAR с Keil очень похоже должно быть, думаю.
Обращаться, соответственно, можете как и к обычным переменным.
3. У самого контроллера смотрите на FSMC, если надо только статику. За динамикой — только к FMC.
4. Конкретные модели по памяти и не назову, увы. Это надо гуглить.
Отладочная плата STM32F4 в форм-факторе Raspberry Pi