КПК (Карманный Путевой Компьютер): Схемотехника GPS логгера

    Мой хобби проект — это GPS логгер. В комментариях даже предложили называть его “Путевой компьютер”, т.к. логгирование это только небольшая часть всех возможностей устройства. Многое уже реализовано, но бОльшую часть еще только предстоит сделать.

    В прошлых статьях я описывал переход с ардуино на STM32, STMCube/HAL, немного рассуждал про билд систему, бутлоадер, строил композитное USB устройство и прокачивал его скорость. Все это делалось на макетке на основе платы Blue Pill STM32F103CB и ежика из проводов. Пора устройству обрести форму, как электронную (схему), так и физическую (корпус).



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

    Прежде чем начать сразу хочу отметить, что это не финальный вариант устройства. Скорее всего в схеме найдутся ошибки, что-нибудь будет работать не так как задумано, в комментариях укажут на более правильные решения, какие-то подходы будут переосмыслены. Я думаю что второй или даже третьей версии устройства не избежать. Поэтому буду рад Вашим конструктивным комментариям.

    Под катом многабукав, но будет инженерненько.

    Что и зачем


    GPS логгер Holux M241 — мой верный спутник во всех поездках. Он со мной уже многие тысячи километров. Трек, который пишет логгер, в первую очередь я использую для геотегирования фотографий, но и сам маршрут также представляет интерес. Прикольно же узнать как быстро ты спускался на лыжах, каким маршрутом летел твой самолет, что за достопримечательность только что промелькнула за окном автобуса. Вот тут я делал небольшой обзор этого устройства.

    К сожалению возможности этого устройства уже давно перестали меня устраивать: надоело возиться с батарейками, которые вечно садятся в самый неподходящий момент. Также очень маленькая скорость USB, маленький объем внутреннего флеша, неудобный механизм сливания треков, мало информации доступно на дисплейчике, маленькая точность, очень примитивный одометр, нет информации о спутниках, и много чего еще по мелочи.

    Да, можно было бы поискать что предлагают современные трекеры — наверняка в продаже уже есть устройство отвечающее моим требованиям. Но ведь это хобби, хочется самому попробовать сделать что нибудь сложное, интересное, полезное и нужное. Пускай даже если этим буду только я и пользоваться.

    Цель проекта в целом — сделать в чем-то аналогичное устройство, только нафаршированное моими хотелками. В первой статье из цикла я детально описывал свои требования к устройству. Если вкратце, то хотелось бы сделать следующее:

    • переработать систему питания, перевести на литиевую батарейку
    • поставить более информативный дисплей
    • более точный GPS
    • расширить флеш с помощью SD карты
    • добавить компас и акселерометр
    • Также хочу переработать систему логгирования, чтобы выплевывало треки в нужном мне формате.

    Помимо технических требований и хотелок есть еще и нетехнические (нефункциональные). Так хотелось бы прокачаться в создании сложных устройств с нуля, разобраться как работают различные электронные компоненты, как их программировать, как разводить плату и проектировать корпус.

    Зачем вообще нужно отдельное устройство если во всех современных телефонах есть GPS, большой экран и много памяти? Ну в первую очередь я не уверен, что телефон со включеным GPS в режиме записи трека может выдержать целый день. Мне не очень хотелось бы остаться в незнакомой стране без телефона. Также лично мне пользоваться отдельным устройством попросту комфортнее.

    Возможно со временем концепция устройства поменяется. Так, например, сейчас все более и более логичной становится идея отказаться от экрана и подключаться к телефону по bluetooth, а всю навороченность логики делать уже в телефоне. Эта идея весьма здравая и заманчивая. Но на данном этапе я бы все таки хотел иметь дисплей — отказаться от него я всегда успею.

    Первые полтора года я разрабатывал устройство на различного рода отладочных платах (сначала arduino nano, потом STM32F103 blue pill, потом STM32F407VE). Подключать периферию приходилось на проводках и покупных модулях. В итоге на столе получался ежик из проводов, который не то чтобы вынести на улицу потестировать прием GPS не получалось — порой даже пошевелить провода нельзя было без того, чтобы нарушить где нибудь соединение. И потом happy debugging.

    Каждый раз садясь за написание полезного функционала я упирался в то, что какая-нибудь другая часть системы переставала нормально работать и приходилось тратить часы на дебаг чего-то совершенно несвязанного. Так, например, самый важный компонент системы — GPS приемник — в итоге оказался наименее проработанным, т.к. пришлось с головой уйти в дебаг USB, SD карты, настройкой библиотек и такого прочего.

    Наконец мне это надоело и я решил сделать свою отладочную плату — это и будет темой сегодняшней статьи. Цели, которые я себе ставил в этой части проекта были такими:

    • Сделать отладочную плату, у которой не будет проблем с неконтактом компонентов
    • Определиться с основными техническими и схематическими решениями
    • Примерно определиться с компонентами, которые я буду использовать дальше
    • Примерно определиться с компоновкой и корпусом
    • Схема должна быть достаточно общей, чтобы можно было экспериментировать с разными компонентами и их режимами

    И хотя конечная цель — компактное батареечное устройство, сегодня я не буду заниматься такими вещами как

    • тонкая настройка режимов электропитания
    • настройка потребления
    • режимы сна


    Настройкой потребления я займусь когда будет готова плата и основной код. Кстати, про код сегодня тоже не будет но я обязательно вернусь к этому вопросу как появится достаточно интересного материала.

    Компоненты


    Начнем, пожалуй, с компонентов и периферии. По пути заодно прикинем количество ног микроконтроллера, которые потребуются для подключения этого зоопарка, а также параметры питания. Т.к. это хобби проект, что компоненты я выбирал из того что реально купить в магазинах/ebay/ali, а также того что можно запаять в домашних условиях (ну и также из того, что уже было в личных запасах). Возможно какие-то специфические микросхемы могли бы решать задачу лучше, но вопрос доступности и цены для меня важен.

    • Основным компонентом GPS логгера, разумеется, будет GPS приемник. В моем случае это довольно навороченный Beitian BN-880 на базе микросхемы UBlox M8N. В модуле встроен также компас на микросхеме HMC5883L.

      Подключение: 2 контакта UART для GPS и 2 контакта I2C для компаса
      Питание: от 2.7В
      Потребление: 50мА

      • Также заказал модуль Beitial BN-220. В нем нет компаса, но зато антенна более компактная (20х20мм против 30х30). Правда пока неясно как это скажется на качестве приема. Нужно тестировать. Зато, судя по даташиту, этот модуль может работать от 1.4В, что должно позитивно сказаться на времени работы устройства.
      • Тут на самом деле все как-то мутно. Вроде бы BN-880 построен на базе UBlox M8N, тогда как BN-220 на базе U-blox M8030-KT. Но в некоторых источниках проскакивает что это, вроде бы, одно и тоже. Точнее M8N это модуль, а M8030-KT это чипсет внутри. Меня же в этой неразберихе волнует вопрос питания — M8N заявлен от 2.7В, тогда как M8030-KT от 1.4В.
      • В качестве альтернативы у меня также валяется модуль SIM868. в котором на борту помимо GPS есть ещё GSM/GPRS модуль и Bluetooth. Пока пугает своей навороченностью и сложностью подключения. Нужно будет сначала с отладочной платой поиграться.
    • Основным отличием устройства от “просто черного ящика” является наличие дисплея. В первых прототипах я подключал дисплей по I2C, но загрузка шины получалась около 25%. Но дело даже не в процентном соотношении, а в том, что пересылка экранного буфера занимает около 25мс, во время которых нельзя общаться с другими устройствами на шине. Это может быть проблемой, поэтому нужно либо выносить дисплей на отдельную шину I2C, или рассмотреть вариант подключения по SPI

      Подключение: 2 провода I2C или 3 провода SPI (дисплей write-only, поэтому линия MISO не используется, зато используется отдельный сигнал Data/Command)
      Питание: от 3В
      Потребление: 25мА
    • Для управления устройством у меня будут использоваться 2 кнопки, которые занимают 2 ноги процессора, соответственно
    • В оригинальном устройстве (Holux M241, с которого я изначально копировал функционал) нельзя было посмотреть трек в произвольный момент времени. Нужно было обязательно подключать устройство к компьютеру и сливать данные специальной программой. Как мне кажется, возможность посмотреть трек на мобильном телефоне или планшете в любой момент будет весьма востребована. Для этого я приобрел Bluetooth модуль HM-13. Этот модуль выбран потому, что он умеет SPP в добавок к BLE.

      Подключение: 2 провода UART, 1 провод статуса (подключено/не подключено)
      Питание: 2.5V — 3.9V
      Потребление: 50мА (хотя тут же рядом в даташите приводится цифра 13мА. Возможно это пиковое и среднее значение)
    • Как мне подсказали, нет смысла держать приемник включенным, если ты просто присел отдохнуть или зашел пообедать в кафе. Поэтому я решил добавить акселерометр MMA8452 и по нему определять находится ли устройство в состоянии покоя или мы куда-то движемся.

      Подключение: 2 провода I2C, 1 провод на прерывание
      Питание от 2В до 3.6В с каким-то микроскопическим потреблением
    • GPS трек будет записываться на SD карту. Я уже пробовал использовать карту в режиме SPI и это, мягко говоря, медленно. Особенно на запись. Правильный режим для SD карты — SDIO

      Подключение: 6 проводов
      Питание: от 1.8В
      Потребление неизвестно, но думаю не больше 20мА
    • Для экономии электроэнергии есть смысл отключать питание тех устройств, которые в данный момент не используются. Так возле каждого потребителя я поставлю по транзистору, которым буду управлять отдельным сигналом микроконтроллера

      Подключение: 5 сигналов, по одной ноге на потребителя (GPS, Bluetooth, акселерометр, SD карта, дисплей)

      UPD по мотивам комментариев. Отключать акселерометр не имеет смысла — у него и так копеечное потребление. Часть устройств скорее всего будут работать всегда (например SD карта) — в будущем я смогу убрать эти транзисторы. Часть устройств (например GPS) умеют сами отключаться по команде из интерфейса. Если по результатам тестов эта часть будет работать хорошо — я также откажусь от внешнего транзистора. Ну а пока я делаю максимально общую плату пускай эти все транзисторы будут. Тем более, что я до конца не определился с периферией.
    • Двухцветный светодиод для отображения статуса (как же без моргающего светодиода?). Можно было бы и трехцветный поставить, но пока не вижу необходимости.

      Подключение: 2 контакта
      Потребление: 10мА
    • Помимо Блютуса будет реализован более классический механизм сливания треков — через USB. Для этого будет задействовано 4 линии — дифференциальная пара для данных, 1 пин для детектирования, что устройство воткнули в USB, и еще один пин для логического подключения (зачем нужны эти 2 пина я расскажу ниже)
    • Аппетит приходит во время еды. Раз уж я начал в свое устройство мечты пихать все подряд, то почему бы не добавить пищалку? Ну или вибромотор. Пока не придумал юзкейс.

      Подключение: 1 провод
    • Устройство еще нужно будет запитать. Пока на меня смотрит микросхема PT1502 в качестве зарядника литиевой батареи и контроллера питания. Для связи с микросхемой нужно будет задействовать 2 провода: один для управления питанием, другой для сигнала о севшей батарее. Еще ради интереса можно будет измерять напряжение батареи с помощью еще одной линии.
    • Разумеется, заряд литиевого аккумулятора неправильно измерять исходя из напряжения. Поэтому я добавил специальную микросхему-измеритель мощности INA219

      Напряжение питания: 3-5В, рекомендуют 3.3В
      Подключение: 2 провода I2C

      Как будет видно ниже напряжение питания в 3В создает некоторый дискомфорт в подключении. Я бы предпочел, чтобы микросхема-счетчик питалась от 2.7В или ниже. Но перебрав несколько вариантов исходя из цены/корпуса/доступности я так и не нашел ничего на 2.7В. Буду благодарен за подсказку.
    • Осталось только предусмотреть отладочный интерфейс SWD (3 провода) и отладочный UART (еще 2 провода)

    Меня всегда интересовал вопрос а зачем нужны контроллеры с большим количеством портов, а сам с легкостью насчитал 39 лап, нужных для моего функционала. И это не считая кварцев, ресета, и питания. Причем есть идеи чем занять еще с десяток (например, дисплей можно было бы подключать через параллельный интерфейс Intel 8080 или Motorola 6800).

    Можно, конечно, I2C port externder’ы прикрутить, чтобы уменьшить количество используемых ног. Но во-первых это дополнительные компоненты на плате, во-вторых сильно усложняется программная часть, а в-третьих все равно в маленьких микроконтроллерах мало памяти, а там где памяти достаточно, там и портов тоже хватает. Так что не вижу смысла все усложнять — пусть будет 39 линий.

    Питание


    С напряжением питания пока не все так ясно. Можно, наверное, все устройства запитать от 3.3В и на этом успокоиться. Но мы же, все таки, мобильное устройство собрались делать, а значит нужно подумать об экономии электроэнергии. А значит нужно постараться выбрать напряжение питания поменьше. Чуть ниже я прикину какой именно экономии можно попробовать добиться.

    Вот данные по всем устройствам в табличке — в таком виде удобнее выбирать домен питания к которому подключать то или иное устройство.

    Устройство Диапазон питания Домен питания коммуникация
    CPU 2 — 3.6V 2V
    Accelerometer 2 — 3.6V 2V I2C
    SD Card 1.8V или 3.6V 2V SDIO
    Display 1.65 — 3.3V
    или 3 — 5V
    2V I2C или SPI
    GPS 2.7 — 5.5V
    или от 1.4V
    2.7V UART
    Bluetooth 2.5 — 3.9V 2.7V UART
    Power Meter (INA219) 3 — 5.5V 3V I2C
    Buzzer 3V — 5V VBat

    Из таблички легко видеть, что часть устройств могут работать от достаточно низких напряжений (от 1.8В). Другие могут комфортно работать от 2.7В. Наконец, оставшиеся устройства ниже 3В работать не могут. Пищалке, по хорошему, вообще 5В нужно, но у меня она будет питаться от самого большого напряжения — от батарейки, сколько бы на ней ни было.

    С питанием дисплея пока не до конца понятно. В описании дисплейных модулей с али указан диапазон 3 — 5В, тогда как в даташите на контроллер матрицы SSD1309 указан диапазон 1.65 — 3.3В. Я предполагаю, что 3В нужно чтобы раскачать повышающий преобразователь на плате дисплейного модуля, тогда как логике достаточно 1.65В. Как будет видно из рассуждений про компоновку есть смысл отказаться от дисплейного модуля и подключить дисплей напрямую, что позволит запитать дисплей от домена 2В.

    Примерно такие же рассуждения у меня и про GPS — в разных источниках указано разное напряжение питания. Пока у меня нет понимания какой модуль я буду использовать в итоге, потому пускай приемник поболтается в домене 2.7В.

    С SD картой вообще не ясно. Спецификация мутно говорит о том, что вообще-то карта должна питаться от 3.3В, но современные карты достаточно умны и могут понять, что их воткнули в низковольтное устройство и могут переключиться на питание от 1.8В. Но механизм выбора питания до конца не очень понятный. Запитаю я карту от 2В и посмотрим что выйдет. Не получится — будет работать от 3В.

    Итак, вырисовывается 4 шины питания — 2В, 2.7В, 3В и батарейка. Хотелось бы всех жрущих и постоянно работающих потребителей (а это контроллер и GPS) посадить на самую низковольтовую шину, но на данный момент я пока не определился с модулем GPS (а значит и с его питанием — 2 или 2.7В), а значит нужно будет некое универсальное решение. Попробую развести плату так, чтобы можно было легко либо одно, либо другое напряжение подать.

    Откуда же взять столько разных напряжений? Еще на ранних этапах проекта я присмотрел микросхемку PT1502 даже уже успел попробовать в другом проекте. Помимо заряднинка для литиевой батареи в этой микросхеме есть аж 3 источника питания — один импульсный и 2 линейных понижатора. Вот, правда, на одном из них не регулируется напряжение и составляет 3В — попробую от него запитать INA219. Оставшиеся 2 источника питания проблемы не составляет, т.к. там напряжение можно выбирать.

    Прикинуть потребление пока не очень получается. В даташитах указано пиковое потребление — этого достаточно, чтобы рассчитать мощность ключевых транзисторов, но недостаточно, чтобы прикинуть необходимую емкость батареи. Так что пока батарею буду подбирать исходя из доступного места в корпусе, а там уже измерю реальное потребление.

    Может возникнуть вопрос, а как согласовывать устройства с разным рабочим напряжением? Давайте разбираться.

    • Все коммуникационные ноги микроконтроллеры отмечены как Five Volt Tolerant (кроме UART2 на ножках PA2/PA3), а значит если там появится 3.3В от самого высоковольтного устройства ничего плохого не произойдет
    • Акселерометр хотя и запитывается от 2В, может быть потенциально подключен параллельно с высоковольтными устройствами на шине. Эта проблема легко решается — у микросхемы MMA8452Q можно отдельно запитать коммуникационные выводы от другого питания (по самому “высоковольтному” устройству на шине)
    • SD карту попробую запитать от того же напряжения, что и микроконтроллер, а значит ничего согласовывать не нужно.
    • GPS и Bluetooth должны без проблем скушать “низкое” напряжение от микроконтроллера. Тоже самое касается и других “высоковольтных” устройств

    Наконец, пару слов о том, зачем же я так борюсь за понижение напряжения питания. Фишка в импульсном DC-DC преобразователе, который может обменять вольты на амперы (если не брать во внимание потери самого преобразователя, разумеется). Если быть точнее, то обменять более высокое напряжение с низким током на низкое напряжение и более высоким током. Нас в данном случае больше интересует обратные рассуждения — если запитать низковольтную нагрузку через DC-DC, то потребляемый ток этой всей конструкции вместе с преобразователем будет ниже, чем потребляемый ток самой нагрузки. Ну а поскольку емкость батареи измеряется в мАч, то уменьшение потребляемого тока приведет увеличению времени автономной работы.

    Посчитаем?
    Один знакомый предположил, что поскольку КПД преобразователя как правило около 90%, то вполне возможно усложнение схемы в виде DC-DC себя не окупит и можно обойтись обычной КРЕНкой. Давайте прикинем. Я провел пару ооочень грубых рассчетов, чтобы понять а действительно ли DC-DC преобразователь тут уместен.

    Вот табличка с расчетами. Пускай батарейка 900мАч линейно разряжается с 4.1 до 3.5В (что в общем случае не соответствует истине). КПД DC-DC преобразователя я поставил 90% (среднее значение из даташита). Разряжать будем током 100мА. Я хотел сравнить время работы устройства от линейного источника питания с импульсным.

    Очевидно, что линейный источник разрядит батарею 900мАч током 100мА за 9 часов. А вот с импульсным источником устройство протянет гораздо дольше — 9.3 часа при целевом напряжении 3.3В, 11.4 часа при 2.7В, и целых 15 часов при напряжении 2В. Разумеется, расчеты ну оооочень грубые, но даже так видно, что с импульсным источником долгоживучесть аккумулятора существенно возрастает.

    Микроконтроллер


    К вопросу выбора микроконтроллера я подошел вдумчиво — долго игрался с конфигуратором, взвешивая все за и против каждого из вариантов. Мне очень понравились микроконтроллеры STM32, поэтому смотреть в сторону других контроллеров без особой необходимости не вижу смысла. Тем более что в линейке STM32 есть контроллеры на любой вкус и под любую периферию. Опыт полученный на предыдущих этапах моего проекта позволяет сузить выбор контроллера исходя из списка периферии, уже написанной программной обвязки, а также возможностей, которые я бы хотел реализовать в будущем.

    Так, совершенно очевидно, что 20кб памяти моего STM32F103CB однозначно мало — очень не хватает буферов приличного размера для общения SD картой и USB. Многое из задуманного функционала я еще даже не начинал реализовывать, а занято уже больше 19кб. А вот с мощи для обработки, как оказалось, особо то и не нужно. Если все общение с периферией затолкать в DMA, то на долю центрального процессора остается всего пару процентов.

    Прикинув список того, что мне нужно от контроллера я насчитал следующее:

    • >= 128кб флеша (сейчас занято около 50к)
    • >= 40 кб памяти (сейчас занято 19к)
    • >= 40 ног GPIO (см. рассуждения выше)
    • >= 40МГц (особо много не нужно, главное чтобы потребление было поменьше)
    • DMA (уж больно понравилось)
    • >= 2x I2C, >= 3x UART, >= 1 SPI
    • SDIO (флешка через SPI работает очень медленно)
    • Честный USB Full Speed, лучше High Speed
    • Доступность (возможность купить пару штук за адекватную цену)
    • Из пожеланий еще нативная поддержка параллельных LCD интерфейсов (обычно реализуется в виде модуля доступа к внешней памяти FSMC)

    Микроконтроллеров у STMicroelectornics просто пруд пруди — на любой вкус, цвет и кошелек. Сначала я пробовал при выборе контроллера исходить из серии. Линейки L0 и F0 слишком слабые и мало памяти, S7 и H7 наоборот слишком навороченные, в L4 нет SDIO (UPD: SDIO есть, просто они его не упомянули на титульной странице серии). Среди остальных серий можно подобрать что нибудь исходя из моих нужд, благо у меня нет особо специфичных требований.

    Серия STM32WB подкупает наличием Bluetooth, но корпус VFQFPN68 несколько охлаждает желание использовать его в хобби проектах. Да и в розничной продаже таких контроллеров не нашел.

    Я целился на корпус LQFP64 — достаточный по количеству ног, но при этом не очень большой и можно запаять в домашних условиях. Хорошо, что есть конфигуратор CubeMX в котором можно фильтрами выбрать то, что нужно.

    Остановил свой выбор на контроллере STM32F103RB по трем причинам. Во-первых я уже хорошо изучил серию F103 на примере платы Blue Pill. В целом контроллер STM32F103CB меня полностью устраивал, только памяти было маловато. Во-вторых у меня уже есть бутлоадер и низкоуровневый код по этот контроллер, тогда как под другие придется переделывать. Ну и в-третьих, примерно год назад я на радостях уже купил 3шт STM32F103RB. Тогда я не делал детальное исследование доступных контроллеров, а просто подобрал контроллер потолще из линейки F103. Не выкидывать же его теперь :)

    Как я уже отметил, у меня нет особо специфичных требований по периферии или производительности. Но если упрусь во что нибудь, то на примете у меня уже есть контроллеры из линейки F4 (если понадобится что нибудь помощнее), или L152RD, если нужно будет что нибудь с потреблением решать (UPD: еще L433RC присмотрел). Что радует, у STM32 почти все контроллеры pin-to-pin совместимы, и F4 и L1/L4 можно будет впаять практически без переделки платы. Можно даже несколько плат с разными МК собрать и сравнивать потребление.

    Пару слов про корпус и компоновку


    С деталюшками определились. Пора рисовать схему, потом трассировать плату, а потом пытаться уместить ее в корпус. Или нет? Признаться я сначала как раз и пошел этим путем, но потом пришел к выводу, что все нужно делать в обратном порядке. Ну или как минимум одновременно.

    Я бы хотел получить компактное устройство. А для этого нужно точно понимать размер доступного пространства, чтобы в свою очередь понимать где расположить плату и ее размер, батарею какого размера можно будет уместить, где расставлять кнопки, экран, разъем USB и другие внешние компоненты, а также прикинуть как крепить компоненты и можно ли удобно проложить провода между ними. Начинать разводить плату без понимания всех этих штук попросту бессмысленно. Вот и получается, что нужно сначала заняться корпусом и компоновкой, а потом уже переходить к схеме.

    Также в процессе рисования корпуса мне несколько раз пришлось пересматривать выбор компонентов. Так изначально я думал использовать дешевый дисплей 128х64 размером 0.96” (размер рабочей области 21.7 х 11.2мм), но этот дисплей выглядел совершенно микроскопическим на фоне корпуса гораздо большего размера. Далее был заказан дисплей 1.3” (рабочая область 29.4 х 14.7 мм), но существенно лучше не стало. Далее я обзавелся дисплеем 1.54” (35 х 17.5 мм) — с ним выглядит более-менее нормально. На данный момент это основной рабочий вариант.

    По прикидкам лучше смотрелся бы дисплей 1.8”-2”, но эти уже идут цветные и бОльшего разрешения, а соответственно экранный буфер будет достаточно большим для моего контроллера (35кб вместо 1кб). Ну и с впихиванием больших дисплеев в корпус также могут быть проблемы, т.к. посадочные крепления у таких модулей существенно больше чем активная область дисплея.

    Пока я писал эту статью на али появились монохромные дисплеи 2.42” с тем же разрешением (128х64) и точно такой же обвязкой как у 1.54”. Заказал себе на пробу такой — есть шанс воткнуть его в мой корпус без существенного увеличения устройства.

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

    Аналогичные размышления у меня и на тему GPS модуля. Он не то, чтобы большой, но как его ни поставь он или мешает, или антенна закрывается какой-нибудь батарейкой. Возможно будет хорошей идеей поместить начинку модуля к себе на плату, а антенну разместить где нибудь в другом месте.

    Работа над корпусом также позволила определиться с размером и емкостью батареи. В доступный объем как раз нашлась батарея на 900мАч — на нее и будем ориентироваться. Хотелось бы, чтобы мое устройство работало от батарейки часов 15-20, а значит потребление должно быть на уровне 45-60мА.

    На данный момент я не могу назвать работу над корпусом законченной. Во-первых по прежнему открыт вопрос выбора для некоторых компонентов (дисплей, GPS). Во-вторых не ясно заведется ли моя схема в принципе или нужно будет что нибудь кардинально менять. Ну и в-третьих, плата получается ну уж слишком компактной — я не уверен, что в силах такое развести, спаять и отладить. Потому в этой статье я все же сфокусируюсь на вопросах схемотехники, буду двигаться более простыми и понятными шагами, а про корпус расскажу в следующий раз. Вот вам для затравки парочка рендеров и фотографий.









    Схема


    Вот теперь уже можно заняться электроникой. Я буду достаточно детально описывать схемотехнические решения. В первую очередь для таких же новичков в электронике как и я, а также в качестве конспекта самому себе. Опытные электронщики могут бегло просмотреть схемы и перемотать к следующему разделу.

    Начнем с питания.

    Аппарат будет запитан от литиевой батареи, а значит нужен контроллер заряда. Также некоторые компоненты имеют верхний предел по напряжению порядка 3.6В, тогда как на батарее может запросто оказаться больше 4В. Значит нужен понижающий источник питания. Как мы уже выяснили нам понадобится несколько разных напряжений.

    Я уже упоминал что я буду использовать микросхему PT1502. Она удачно подходит, т.к. реализует контроллер заряда, 3 источника питания, а также схему включения устройства кнопкой. В микросхеме несколько функциональных блоков, которые на схеме для понятности я разделил. Сама схема представляет собой немного переработанную схему из даташита. Вот контроллер заряда литиевой батареи



    Резистор R3 задает ток заряда. По умолчанию это соответствует 470мА. Возможно по результатам тестов я уменьшу номинал этого резистора до 510 Ом, что будет давать ток заряда около 900мА (1C).

    О текущем режиме заряда контроллер может сообщать ногой CHG_STAT. Причем сигналов он умеет давать аж 3 — заряжается, не заряжается, и уже зарядилось, но еще подключено к розетке. В первом варианте внутренний транзистор прижимает ногу к земле и это легко можно опознать контроллером. Во втором варианте транзистор полностью закрывается и нога переходит в высокоимпедансное состояние. С помощью подтяжки к питанию такой сигнал также легко считать контроллером.

    А вот с третьим состоянием не все так просто. Там транзистор приоткрыт и через него течет ток 20мкА. Для того, чтобы считать такое состояние мне подсказали подобрать подтяжку таким образом, чтобы на ноге оказалось примерно половина питания. Тогда можно будет с помощью АЦП легко детектировать такое состояние. Пользуясь законом Ома получаем R5 = 1В/20мкА = 50к.

    Как я уже сказал микросхема PT1502 это не просто зарядник, но еще и хитрый контроллер всего питания. Микросхема следит за напряжениями на схеме и с помощью сигнала RESET может управлять главным процессором (мол, рано тебе еще запускаться, питание еще не стабилизировалось).



    Также микросхема может запустить прибор по нажатию кнопки (BTN1), а также по сигналу от микроконтроллера (PWR_HOLD) завершить работу и отключить питание. Ну а чтобы сигнализировать процессору о том, что батарея на исходе предусмотрен сигнал BAT_LOW.

    А это основной источник питания.



    Выходное напряжение задается напряжением на выводе BUCKFB и при батарейном питании настроено на 2В. Но с двухвольтовым питанием обнаружилась одна проблема — USB работать не будет. Т.е. батарейка заряжаться будет, а данные передавать не получится — микроконтроллер просто не сможет выдавать сигналы на шину USB достаточной амплитуды. Даташит рекомендует напряжение как минимум 2.7В, лучше 3.3В.

    Чтобы не городить еще один источник питания и думать как переключаться между ними, я решил просто корректировать соотношение делителя R1/R4+R7. При таком включении импульсник работает постоянно. Как только устройство втыкают в USB, транзистор открывается и шунтирует R7. Соотношение задающих резисторов меняется и на выходе получаем 3.16В (можно будет еще поиграться с номиналами и дотянуть до 3.3В).

    В микросхеме PT1502 имеются также 2 линейных регулятора.



    К этим регуляторам у меня будут подключены либо мало потребляющие компоненты (INA219), либо короткоживущие (bluetooth), так что КПД этих источников не будет проблемой. Напряжение питания LDO2 можно настроить с помощью сигналов LDO2_SETx.

    Поскольку по напряжениям питания у меня все еще есть открытые вопросы, я решил развести перемычки для выбора режима LDO2_SETx. Также чтобы иметь возможность измерять реальное потребление по соответствующей шине я также разведу перемычки JP1/JP2/JP3 на гребенку.

    Заканчивая тему источников питания нужно упомянуть о питании дисплея. Чуть выше я писал, что во имя компактности мне пришлось отказаться от покупного дисплейного модуля и забрать дисплей с обвязкой к себе на плату. Этот дисплей требует специального повышающего преобразователя на 7-16В. Удобно что этот источник можно включать и выключать с помощью сигнала EN. Сама схема скопирована с даташита повышатора, точно такая же используется и в дисплейных модулях с али.



    PT1505
    Перерывая интернет в поисках альтернатив на микросхему PT1502 я наткнулся на ее старшую сестру — микросхему PT1505. Это практически такой же контроллер питания, только с дополнительной повышайкой. С таким контроллером можно было бы сократить количество элементов на плате. К сожалению микросхемы PT1505 в продаже не нашел.

    Кстати, буду благодарен если Вы знаете аналогичные контроллеры питания от других производителей.

    Теперь немного о питании микроконтроллера. Микросхема большая и имеет 6 линий питания — 4 на цифровую часть, 1 аналоговое питания и одно для часов. Согласно даташиту на STM32F103 на всех линиях питания (может быть, кроме часовой) должно стоять по конденсатору 100нФ, и еще один общий на 4.7мкФ.

    А вот в даташите на STM32F4 сказано, что хотя микроконтроллеры практически совместимы по выводам, все же схемы питания у них несколько различаются. Так на двух выводах должны стоять конденсаторы по 2.2мкФ между выводом и землей (а не между землей и питанием, как у F1). Поэтому пришлось учесть оба варианта и для конкретного микроконтроллера запаивать только часть конденсаторов.



    Продолжая тему питания, нужно придумать как его измерять. Можно полагаться на сигнал BAT_LOW и попросить пользователя быстренько закруглиться если батарейка разряжена. Но это именно то, что мне не нравилось в оригинальном Holux M-241, т.к. этот сигнал появлялся слишком поздно и его легко было проворонить. Мне нужен какой нибудь более информативный показатель заряда батареи.



    На всякий случай я поставил самый обыкновенный делитель для измерения напряжения батареи. Но в случае литиевых аккумуляторов это только информативный показатель и полагаться на него не стОит. Для более честных показаний по батарее в интернете предлагают использовать “кулон”.



    Эта маленькая микросхемка считает количество энергии, которое через нее прошло в или из батареи. Измерения производятся на шунте R10. Показания микросхемы можно считать через I2C. Микросхема умеет измерять напряжение на батарее, ток проходящий через резистор, а также перемножать одно на другое. К сожалению накапливать значение пробежавших мимо Ватт*Часов она не умеет, потому придется делать постоянный опрос.

    Перейдем к цифровой части. Сердце всей системы — микроконтроллер STM32F103RB.



    Обвязка в виде двух кварцев взята с других схем, найденных в интернете (перепроверено в даташите). Мне не потребуется загрузка из оперативной памяти, а потому сигнал BOOT1 подтянут к земле. BOOT0 можно выбирать перемычкой для загрузки из основной флеш памяти или встроенного UART загрузчика (например для первичной прошивки устройства)

    Дальше светодиод.



    Поскольку основное напряжение питания будет меняться от 2 до 3.3В то светодиоды к нему подключать не стОит — будет сильно меняться яркость и потребляемый ток. Поэтому светодиоды у меня будут подключены к шине 2.7В, токоограничивающие резисторы рассчитаны соответственно. Поскольку микроконтроллер не сможет выдавать на своей ноге больше 2В при питании от батареи, то push-pull режим GPIO использовать нельзя. Только open-drain.

    Про кнопку ресета рассказывать особо нечего.



    Поскольку на шине I2C будет сидеть трехвольтовое устройство (INA219), то и подтяжки также нужно делать к трем вольтам



    Разъем SWD также стандартен. Диод нужен, чтобы переключать питание между батарейкой и внешним питанием от программатора.



    Предвосхищая возгласы что так не делают и что такое подключение на самом деле не отключит батарейку. Да не отключит, но диод тут не для этого. Эта штука нужна чтобы иметь возможность запитать устройство от программатора, если батарея не подключена. А если подключена, то пусть от нее и работает. Ну и если батарея подключена, то нужно защитить сам программатор от 4.2В на батарее.

    А вот на кнопках стОит остановиться подробнее.



    Дело в том, что первая кнопка будет не только кнопкой, но будет работать также и как включатель устройства — сигнал BTN1 подключен к микросхеме контроллера питания PT1502. Когда устройство выключено питание на микроконтроллер и другие потребители не подается. Именно по этому кнопка подключена не к питанию (VCC) а к батарее (BAT). По нажатии на эту кнопку PT1502 включит все источники питания и запустит микроконтроллер. После этого кнопка может работать как обычная кнопка. Для того, чтобы микроконтроллер не спалить высоким напряжением батареи я соорудил небольшой делитель напряжения, который загонит сигнал BTN1 в необходимые рамки (впрочем, можно и без этого — у микроконтроллера есть входы, толерантные к 5В)

    Вторая кнопка ничем не примечательна. Внутри процессора будет включена подтяжка к земле, а кнопка будет подавать на линию единицу…

    Плавно переходим к тяжелой периферии. USB



    Разъем USB будет торчать наружу устройства, а там может гулять статическое электричество. Оказывается есть специальные микросхемы (такие как STF202-22), которые охраняют микроконтроллеры от внешнего воздействия.

    Но интересно тут другое. Внутри микросхемы STF202 спрятан резистор на 1.5к, который подключен между ногой VBUS и линией D+. Этот резистор нужен по спецификации USB — по нему хост узнает, что в него что-то воткнули. Во многих схемах этот резистор включен между питанием и линией D+ всегда. Как только хост видит такой резистор на линии D+ он сразу начинает общение с устройством. Это не всегда уместно, т.к. некоторые устройства могут быть сразу не готовы к коммуникации.

    Это как раз мой случай. Для этого есть простая хитрость (подсмотренная тут). Можно включать и выключать этот резистор с помощью транзистора: хотим коммуникации — включаем резистор, хотим просто запитаться от USB — выключаем. Когда Вы втыкаете Ваш мобильник в USB он как правило спрашивает “что делать будем? Данные сливать или только заряжаться?” — в терминах электроники это как раз и идет речь о подключении подтягивающего резистора.

    Но как узнать, что устройство воткнули в USB? Для этого я предусмотрел сигнал USB_PLUGGED, который снимается с простейшего делителя.



    5В от USB можно было бы и напрямую на ногу микроконтроллера подавать — они же все таки толерантны к 5В. Но пусть уже будет через делитель.

    Теперь акселерометр



    Схема взята из даташита. Модуль подключен по I2C, но чтобы сигнализировать микроконтроллеру о том, что есть новости используется еще линия прерывания. Также, поскольку на той же шине I2C еще висит трехвольтовая INA219 то для согласования уровней коммуникационные ноги акселерометра также запитаны от шины 3В.

    Я уже упоминал, что я бы хотел экономить электроэнергию и отключать неиспользуемые приборы. Так питание акселерометра включается транзистором.

    Кстати, мне очень понравились т.н. цифровые транзисторы — транзистор в комплекте с двумя резисторами. Это позволяет сэкономить немного места на плате. Жаль только, что при двухвольтовом питании у меня не получилось подобрать цифровой транзистор с хоть сколько либо приличным током — 20-30 мА максимум. Так что более прожорливых потребителей пришлось подключать MOSFET’ами.

    Идем дальше, GPS



    GPS находится на отдельной плате и подключается через шлейфик. Поскольку я еще не определился с модулем GPS то предусмотрел 2 различных питания. Кроме транзистора питания на стороне процессорной платы больше ничего интересного нет.

    Скажу лишь пару слов про UART’ы. Изначально я планировал использовать все 3 — один для заливки прошивки и дебага, второй для GPS и третий для Bluetooth. Но оказалось UART3 находится на тех же пинах, что и I2C №2, который я изначально планировал использовать для дисплея. Пришлось выбирать. В итоге я пришел к мысли, что заливать прошивку и дебажиться я могу через тот же самый UART, что отведен для GPS (разумеется GPS придется отключить). Ну а если нужно будет дебажить сам GPS, то есть еще USB CDC (в который можно наливать логи) и SWD. Чуть позже я отказался от идеи использования I2C №2, так что UART3 высвободился, но во имя экономии батареи я решил остановится на двух UART’ах.

    Bluetooth



    Bluetooth подключается по схеме из даташита. Вывод PIO1 может работать в двух режимах. В первом к нему подключается светодиод и модуль этим светодиодом моргает. Разные перемигивания означают разный статус. В другом режиме этот вывод работает как цифровой — единица когда связь установлена, и 0 если нет. Режимы переключаются AT командами при инициализации модуля.

    SD карта

    Схема подключения SD карты хоть и стандартна, но почему-то далась мне очень нелегко. В интернете слишком много разных вариантов подключений и понять какое правильное оказалось не так просто.



    По большей части у меня были вопросы в проходных резисторах. Изредка встречаются схемы где ставят резисторы по 1к. Часть схем ставят резисторы по 22 Ома, видимо в качестве защиты от статики. Тем не менее бОльшая часть схем проходные резисторы не предлагают, и я, пожалуй, пойду тем же путем. Статики у меня также не будет т.к. флешка будет жить внутри корпуса.

    Транзистор по питанию, как мне кажется, тоже не будет востребован, я думаю карта будет работать всегда — это же логгер. Но раз это плата тестовая, то пускай будет. Тоже самое и про катушку — видимо это включение в оригинале делал параноик, или карта использовалась в среде с плохим питанием или помехами. Думаю запаять туда нулевой резистор и попробовать без катушки.

    Дисплей

    У меня была возможность подключить один из дисплейных модулей с али через SPI и сравнить с подключением через I2C. Особых сложностей не возникло и код потребовалось лишь слегка расточить. При этом скорость у SPI на порядок выше чем у I2C. Добавив к этому данные из даташита по потреблению (4 мА у SPI против 10мА у I2C), необходимость в подтягивающих резисторах для I2C, я решил подключать дисплей через SPI.



    К сожалению сигнал BS0 не выведен на шлейф дисплея, а потому нельзя выбрать режим 3-Wire SPI, можно только 4-Wire SPI. Разница в дополнительной линии D/C (данные/команда), которые в случае 3-Wire режима передаются девятым битом данных SPI. Впрочем, может 4-Wire режим это и к лучшему, т.к. SPI в STM32 может передавать только по 8 бит.

    В остальном схема соответствует даташиту.

    Ну и напоследок пищалка. Ничего особенного — просто включается через транзистор.



    На случай если вместо пищалки будет вибромотор, я предусмотрел защитный диод. Впрочем, слышал мнение, что пищалке защитный диод также не помешает.

    В железе


    Выше я описывал свои размышления на тему корпуса. На самом деле я даже пытался развести плату под этот корпус. К сожалению плата оказалась слишком тесной. Пришлось использовать двусторонний монтаж, перейти от компонентов 1206 на 0805, но все равно компоненты на плате были расположены очень плотно. Более того, каждое изменение в схеме было болью, т.к. приходилось переразводить чуть ли не полплаты.

    Так я с ней возился несколько недель, но плата меня победила и проект я забросил почти на год. Пинком стала вот эта статья. А ведь действительно, это же только прототип, причем первый из нескольких. Зачем мучиться со сверх компактной платой, куда не подлезть ни паяльником, ни осциллографом, если можно все отладить на большой плате?

    Ну такую огромную плату как у айфона делать не обязательно, а вот в акционные 100х100мм 2 слоя у JLCPCB влезть вполне реально. Можно себя практически не ограничивать. Так на плате разместился огромный дисплей 2.42”, джамперы измерения потребления по всем линиям питания, конденсаторы по питанию где нужно и не нужно, и вообще куча деталей, которые можно было бы и не устанавливать. Еще и место осталось.





    Оно же в Photo View




    По разводке особо рассказывать нечего. БОльшую часть сигнальных и силовых линий я разводил по верхнему слою, тогда как нижний практически полностью отдал под землю. К сожалению компоновка все равно получилась достаточно плотной и некоторые сигнальные линии пришлось тащить по нижнему слою через полплаты. Из-за этого земля местами “разрывается” на несколько слабо связанных островов. Надеюсь это не составит проблем.

    Под антенной bluetooth землю не делал, но все равно пришлось протащить одну из сигнальных линий через эту зону. Впрочем, это линия BT_ON, по которой сигналы часто не бегают (там либо включено, либо выключено), а значит особо сильно на сигнал влиять не должно.

    Близилось лето и я планировал взять плату с собой в отпуск. Чтобы горничные в отелях не пугались голой отладочной платы с веером проводов было бы неплохо спрятать это в корпус. Я не мог отказать себе в удовольствии и разрабатывал корпус и плату одновременно. Так появились крепления платы в корпус, крепления держателя дисплея.

    Модуль GPS это бутерброд из нескольких плат и антенны толщиной 12мм. Я решил его не цеплять сверху на плату, а расположить на одном уровне. Это уменьшило толщину корпуса, но откусило у платы один угол.

    Пару фотографий платы и финального (на этом этапе проекта) устройства.







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

    Пару слов по сборке платы. Спаял я все примерно за 3 вечера, и еще примерно неделю по вечерам ушло на неспешную отладку и проверку со стороны программной части. К моему удивлению фундаментальных сложностей с наладкой платы не возникло и практически все завелось как надо.

    Рассыпуху 0805 оказалось паять не намного сложнее чем 1206, вполне съедобно в домашних условиях при наличии увеличительного стекла. Можно даже на 0603 замахнуться. А вот с пайкой микроконтроллера и разъема дисплея (у них шаг выводов 0.5мм) пришлось повозиться. На ютубе у людей это как-то просто выглядит — провел раз паяльником и все, а у меня все выводы послипались мгновенно.

    Не обошлось и без мелких проблем. Кое-где был непропай, где-то была “сопля”. Футпринт под USB разъем оказался неправильным — у него шаг выводов был меньше чем нужно (вот и верь после этого футпринтам из интернета!). Пришлось немного подогнуть выводы, чтобы они стали на дорожки. FPC разъем дисплея купленный на али оказался с контактами снизу, тогда как мне нужен был с контактами сверху (я до этого и не подозревал о таком различии). Пришлось “сдуть” разъем со штатной платы дисплея.

    После запихивания платы в корпус оказалось, что отключать батарейку просто выдергиванием разъема не получится, а оставлять неотлаженную плату под напряжением не хотелось. Пришлось приколхозить выключатель.

    При настройке платы оказалось, что нигде нет земляного контакта, куда можно было бы прицепить щуп осциллографа. Пришлось цепляться крокодилом за USB разъем. Нужно будет предусмотреть тестовые площадки в следующей версии платы.

    По схемотехнике также обнаружились проблемы. Так совершенно неожиданным фактом оказалось, что микросхема PT1502 на выводе RESET генерирует напряжение в 3В (я был в полной уверенности что там что нибудь вроде открытого коллектора). В итоге эти 3В утекали на линию питания, даже при том, что я планировал там иметь всего 2В.

    Вот упрощенная схема того, что получилось


    Спасибо великому разуму и ребятам с easyelectronics.ru, этот косяк решился добавлением одного диода. После небольшого хирургического вмешательства эта часть заработала как надо.

    Далее, блютус модуль (питается от 2.5В) я нечаянно подключил к основному питанию (2В), вместо фиксированных 3В. Теперь блютус у меня может работать только при подключенном USB, когда напряжение основного питания поднимается до 3.3В.

    В принципе можно было бы взмахнуть скальпелем и припаять блютус к правильному питанию, но UART2 к которому подключен блютус не толерантен к 5В (сам же вычитал это в даташите на стадии анализа, сам же отметил это в тексте выше, и в итоге забыл при разводке платы). Потому подключение блютуса к питанию выше чем питание микроконтроллера чревато… В следующей версии платы просто подключу блютус к какому нибудь другому UART’у.

    DC-DC преобразователь с изменяемым напряжением также заработал как и планировалось — при питании от батареи исправно выдает 2В, а когда подключаешь USB поднимается до 3.16В (нужно бы поиграться с номиналами и дотянуть до 3.3В). Но тут вылезла еще одна недоработка схемы: нужно также уметь поднимать напряжение и при питании от программатора. Думаю это лечится добавлением еще одного диода. Попробую поиграться чуть позже.

    Наконец, за время работы над платой мне так и не стало понятнее как же правильно запитывать SD карту от пониженного напряжения. Непродолжительное гугление ни к чему не привело. По всей видимости нужно погружаться в чтение тесычестраничных спецификаций (которые, к тому же частично закрыты). Ну а пока я закоротил R7 и плата теперь питается от фиксированных 3.16В (3.3В). Оставлю пока так на ближайшие пару месяцев, пока я буду заниматься программной частью.

    Кстати о софте. Удивительно (хотя и вполне ожидаемо), но в целом все завелось без проблем. Поскольку я переходил между микроконтроллерами одной серии (с F103CB на F103RC), то переделки программной части не потребовалось. Только номера пинов поправил, да добавил включение транзисторов. Тем не менее было 2 нетривиальных момента с которыми пришлось повозиться.

    Первый — это питание от батарейки. Отладку платы я проводил при питании от USB и все в целом работало хорошо. Но вот от батареи плата включаться упорно не хотела. Т.е. работать может (если ее включить при подключенном USB, а потом выдернуть шнурок), но запуститься на холодную не получается.

    По дизайну микросхемы PT1502 стартовать плата должна примерно так. Пользователь нажимает кнопку BTN1 и через треть секунды микросхема включает все источники питания. Когда с питанием все хорошо PT1502 “отпускает” сигнал RESET, тем самым запуская микроконтроллер. Процессор в свою очередь выставляет сигнал PWR_HOLD в единицу, сигнализируя о том, что он запустился. После чего PT1502 исправно поставляет электричество в схему, пока микроконтроллер не опустит сигнал PWR_HOLD в ноль.

    Но это в теории. На деле же как только процессор выставлял сигнал PWR_HOLD плата мгновенно выключалась. Я перелопатил всю схему питания, смотрел осциллограммы основных сигналов, тасовал туда-сюда код в бутлоадере, но проблему осознать не получалось. Я также грешил на отсутствие pull-down резистора на линии PWR_HOLD, который я забыл установить, но он рекомендуется даташитом (и он скорее всего таки нужен). Но добавление его навесом проблему не решало. И только когда я одолжил четырехканальный осциллограф все стало ясно.



    Когда пользователь нажимает кнопку (оранжевая линия) микросхема PT1502 включает питание (фиолетовая линия). Все это происходит задолго (300мс) до событий на этой осциллограмме. А дальше происходит нечто интересное. PT1502 отпускает RESET (голубая линия), процессор запускается и зачем-то опускает линию кнопки в ноль. Даже несмотря на то, что микроконтроллер еще пытается поднять линию POWER_HOLD (зеленая линия) — уже поздно, PT1502 уже выключил все источники питания. Дальше происходит еще несколько конвульсий, но схема все равно тихо умирает.

    Вопрос в том откуда взялся ноль на кнопке? Все дело в неприметной ошибке в бутлоадаре, из-за которой на ноге BTN1 выставлялся режим вывода (возможно на других ногах также происходили чудеса в этот момент) и там появлялся низкий сигнал.

    С чем еще пришлось пободаться, так это с SD картой. В старом микроконтроллере модуля SDIO попросту не было, так что этот кусок пришлось изучать с нуля. Я провозился почти целый день в попытках завести карту, копируя куски кода из примеров в интернете, и того, что сгенерировал CubeMX. Хотя карта отлично читалась в компьютере, в моей схеме заводиться упорно не хотела. Я грешил на плохую пайку, неверно выбранные подтягивающие резисторы, корявую схему и неверно трактованный даташит. Но к моему удивлению другая карта с тем же кодом и на той же плате завелась без проблем. Нужно будет этот вопрос изучить более детально.

    С картой была связана еще одна проблема. Потыкав в разные линии осциллографом я увидел активность только на линии D0, тогда как на D1-D3 была тишина — карта работала в однобитном режиме. В HAL даже обнаружилась функция HAL_SD_ConfigWideBusOperation() которая может включить 4-битный режим передачи. К сожалению когда карта переводилась в 4 битный режим, то SDIO периферия уходила в глубокий RX FIFO Overrun и переставала работать.

    Проблема оказалось весьма интересной. Оказалось что внутри функции HAL_SD_ReadBlocks() есть некий цикл, который опрашивает флаги SDIO. По мере поступления новых данных от карты этот код перекладывает байтики из внутреннего FIFO буфера в пользовательскую память. Так вот карта передавала байты настолько быстро, что код в HAL_SD_ReadBlocks() попросту не успевал перекладывать данные. Пришлось временно понизить частоту тактирования карты. Ну а в будущем я буду использовать DMA и такой проблемы не должно возникать в принципе.

    Заключение и дальнейшие шаги


    Тех кто в этом месте ожидал увидеть законченное устройство мне придется огорчить — закончена только тестовая плата, да и то, только железячная часть. Теперь в нее нужно вдохнуть жизнь, заняться программной обвязкой, тонкой настройкой режимов и потребления. Ну и собственно написать код логгирования — то ради чего и затевался весь проект.

    Тем не менее, лично для меня этот этап это очень больше и важное достижение. Электроника это не моя специализация и я очень рад, что устройство вообще запустилось. Мне удалось достаточно сильно прокачаться в проектировании схем, согласовании нескольких устройств, разводке платы, выборе компонентов и много еще в чем другом.

    Про программную часть я расскажу в другой раз. Как и про нюансы настройки. Дело в том, что эту всю начинку нужно сначала оживить и протестировать. На данный момент удалось запустить все устройства на плате (ну кроме пищалки), но только в объеме “запустилось и как-то отвечает”. Никакой логики обработки еще не написано.

    Планы на ближайшее будущее:

    • Погонять электронику в разных режимах, проверить что схема таки работает. Исправить косяки во второй версии платы
    • Измерить потребление всей периферии и найти пути оптимизации потребления.
    • Собрать несколько вариантов платы на разных микроконтроллерах (например на L152 или L433)
    • Вдумчиво прочитать спецификацию SD и разобраться как правильно подключать карту в режиме Low Voltage Signaling (1.8В)
    • Попробовать разные GPS модули и, наконец, определиться с каким я пойду дальше
    • Заказать отдельную микросхему компаса (например HMC5883L или HSCDTD008A) и попробовать их как-то использовать
    • Сделать внутренний рефакторинг кода, проапгрейдить все основные библиотеки, начиная с HAL
    • Начать, наконец, писать фичи. Собственно реализовать то, ради чего задумывалось устройство

    На этом разрешите откланяться. Буду благодарен за конструктивные замечания, идеи и советы по схемотехнике и разводке платы.

    Исходники:

    Код
    Код бутлоадера
    Плата
    Корпус
    Поделиться публикацией

    Комментарии 82

      0
      Немного не понял — зачем экранный буфер, если дисплей имеет свою память и можно перерисовывать отдельные области, вместо всего экрана (Для скорости)

      Кстати, первый вариант компоновки (Платы и корпуса) мне както больше понравился — и выглядит красивее и держать удобнее.
        0
        Если брать монохромные экраны вроде SSD1306/SSD1309, то в интерфейсе нет никаких команд рисования. Есть только механизм заливания байтов сплошным потоком. Можно поиграться с оффсетами слева и справа, но по вертикали видео память контроллера разбита на странички по 8 пикселей (что соответствует одному байту), так что адресовать одну конкретную точку на экране все равно не получится. Кстати, возможности читать видео память тоже нет (во всяком случае по SPI).

        На цветных дисплеях вроде ST7735 также нет команд рисования, но там можно задать view port. Например задать вертикальную область на экране шириной в один пиксель, а потом залить ее байтиками одного цвета — в результате получим вертикальную линию. Горизонтальную линию можно нарисовать тем же способом, а вот наклонную уже придется рисовать в цикле попиксельно или коротенькими линиями. В итоге получаем огромнейший оверхед на посылку по несколько команд чуть ли не на каждый пиксель, и как результат отрисовка экрана чуть ли не целую секунду и стопроцентную загрузку процессора. Так, кстати, работают ардуиновские библиотеки для ST7735.

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

        Есть еще один вариант — подключить дисплей через параллельный интерфейс и попросить контроллер писать прямо в видеобуфер дисплея. Но в случае контроллеров STM32 нужен модуль FSMC, который появляется в корпусах на 100 и более ног. В моем 64-ногом корпусе его нет.

        Кстати, первый вариант компоновки (Платы и корпуса) мне както больше понравился — и выглядит красивее и держать удобнее.

        Согласен. Но я боялся не осилить такую плотную и маленькую плату.
          0
          Вместо FMC использую:
          inline void FMC_BANK1_WriteComand(uint8_t Data)
          {
          	uint32_t wdata = (((uint32_t)(uint8_t)(~Data))<<16)|((uint32_t)(uint8_t)(Data));
          	GPIOA->BSRR = wdata |  (LCD_CMD_Pin<<16) | (LCD_WR_Pin<<16);
          	GPIOA->BSRR = LCD_WR_Pin;
          }
          
          inline  void FMC_BANK1_WriteData(uint8_t Data)
          {
          	uint32_t wdata = (((uint32_t)(uint8_t)(~Data))<<16)|((uint32_t)(uint8_t)(Data));
          	GPIOA->BSRR = wdata |  LCD_CMD_Pin | (LCD_WR_Pin<<16);
          	GPIOA->BSRR = LCD_WR_Pin;
          }
          


          D0-D7 ->PA0-PA7
          Любые на том же порте А
          LCD_CMD ->PA12
          LCD_WR ->PA13
          Итого: 15-16 msec на экран 320x240…

          попросить контроллер писать прямо в видеобуфер дисплея

          Все равно один пиксель с большим оверхедом.

            +1
            Ну если 15-16 мс, то это норм. Просто на ардуинках это совсем уныло выглядит (например так).

            Но как по мне если есть возможность сделать двойную буферизацию и избежать мерцания экрана при перерисовке, то почему бы и не? В случае монохромного экрана это всего 1кб. С цветным, конечно, подумать нужно будет.

            Все равно один пиксель с большим оверхедом.

            Почему вы так думаете? Разве контроллер не возьмет на себя дергание всех управляющих сигналов?
              0
              Возьмет, но частично. У FMC будет чуть быстрее базовые команды:
              #define LCD_REG              (*((volatile unsigned short *) 0x60000000)) /* RS = 0 */
              #define LCD_RAM              (*((volatile unsigned short *) 0x60020000)) /* RS = 1 */
              
              void FMC_BANK1_WriteComand(uint16_t Reg)
              {
              LCD_REG  = (uint16_t)Reg;
              }
              void FMC_BANK1_WriteData(uint16_t data)
              {
              LCD_RAM  = (uint16_t)data;
              }
              


              Все равно отрисовать один пиксел это отрисовать регион в один пиксел то есть:
              send coord Xstart — 2 byte
              send coord Xend — 2 byte
              send coord Ystart — 2 byte
              send coord Yend — 2 byte
              send color 2 byte
              Так что лучше не рисовать отдельными пикселями.
              А вот для текста можно заранее приготовить буфер в памяти и перенести с помощью DMA.

                0
                Все равно приходим к тому, что где-то должны быть наперед подготовленные картинки.

                В текущем варианте я использую библиотеку Adafruit_GFX, она использует весьма упакованный вариант шрифтов и специальный код на лету распаковывает буковки и попиксельно их выводит в экранный буфер. И такой подход был весьма актуален для ардуинок, где флеша очень мало.

                Вариант держать буковки распакованными и копировать их через DMA весьма интересен, благо теперь у меня флеша завались.

                В общем сплошные компромисы — выигрываем в памяти, проигрываем во флеше.
                  +1
                  Можно распаковывать букву в RAM, оттуда DMA в дисплей, потом следующую букву в RAM и тд.
        0
        Делаю похожий девайс, только с немного иной целью — поиграться с GPS/MEMS сенсорами, и позже цеплять на шлем для трекинга экстремальных активностей (велосипед, горные лыжи, прыжки с парашютом). Экран в моем случае не релевантен, планируемый юзкейс — записать данные активности, спуститься на землю и спокойно слить лог на телефон для дальнейшего анализа.
        Микроконтроллер я выбрал NRF52, основные фишки — блютуз на борту, и мультиплексор между модулями периферии и ножками все-ко-всем, немного упрощает разводку. Ну и BLE+NFC на борту все же упрощает жизнь. Я вижу, вы еще планируете рассмотреть другие чипы — не хотите на этот посмотреть?
          0
          Не в ближайшее время точно. У меня и с STM32 список работ на ближайшее время просто огромный. А если потребуется изучать еще один контроллер, то это отбросит меня назад еще на год.

          Но в целом Ваш вариант бездисплейного устройства мне нравится. Не хотите статью написать? :)
          0
          Счетчик Гейгера не планируете использовать?
            +3
            Похоже, чьи-то религиозные чувства задел. Извините, я не знал, что счетчик Гейгера нельзя всуе упоминать.
              +1
              Можно, только зачем? Это классическое «не пришей сами-знаете-к-чему рукав».
                –1

                Тут все устройство так слеплено.

            +5
            Для экономии электроэнергии есть смысл отключать питание тех устройств, которые в данный момент не используются. Так возле каждого потребителя я поставлю по транзистору, которым буду управлять отдельным сигналом микроконтроллера


            Вы экономите этим 10-20 микроампер, но при этом используете один из самых энергонеэффективных микроконтроллеров из всего, что можно найти в продаже.
              0
              Ну как сказать 10-20 микроампер… GPS вон потребляет 65мА, дисплей во включенном состоянии 35мА. Так что не лишено смысла, на мой взгляд.

              С микроконтроллером согласен, в будущем нужно будет поменять. Просто такой уже был в наличии. Но на данный момент это не самая большая проблема (он сейчас потребляет не больше 30мА), да и вопросами энергоэффективности я еще не занимался. Там еще даже уход в сон не реализован.
                +7
                У любого GPS есть несколько режимов снижения энергопотребления, в младшем из которых — battery backup — потребление меньше 10 мкА. Если вы выбрали такой, у которого их нет, то возникает резонный вопрос — а зачем?

                У типового копеечного акселерометра активный режим с частотой обновления порядка 10 Гц — тоже единицы микроампер, зачем вообще его выключать?

                Более того, в данном случае с высочайшей вероятностью — я не смотрел, что вы там используете, но шансов, что оно отличается, крайне мало — вы акселерометр так не выключите, он у вас просто от I2C запитается через подтягивающие резисторы. С некоторой вероятностью ещё и подвесит шину, если у вас на ней кто-то ещё есть.

                Ну и системные требования к памяти у вас выглядят серьёзно завышенными — смотрите в elf, кто у вас там столько сожрал и что с этим делать.
                  0
                  У любого GPS есть несколько режимов снижения энергопотребления, в младшем из которых — battery backup — потребление меньше 10 мкА. Если вы выбрали такой, у которого их нет, то возникает резонный вопрос — а зачем?

                  Я пока еще не разобрался как его выключить, кроме как рубильником.
                  В текущем варианте подали питание — он наливает NMEA поток. Особо я им пока не управляю. Если у него действительно есть внутренний выключатель — это было бы здорово.

                  У типового копеечного акселерометра активный режим с частотой обновления порядка 10 Гц — тоже единицы микроампер, зачем вообще его выключать?

                  Согласен, переделаю

                  Более того, в данном случае с высочайшей вероятностью — я не смотрел, что вы там используете, но шансов, что оно отличается, крайне мало — вы акселерометр так не выключите, он у вас просто от I2C запитается через подтягивающие резисторы. С некоторой вероятностью ещё и подвесит шину, если у вас на ней кто-то ещё есть.

                  Вы заставили задуматься. С этой точки зрения я на вопрос не смотрел.

                  Ну и системные требования к памяти у вас выглядят серьёзно завышенными — смотрите в elf, кто у вас там столько сожрал и что с этим делать.

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

                  В какой-то момент времени я существенно уменьшил потребление памяти у USB (там код корявый жутко), но при этом добавил двойные буфера для общения USB MSC. И нужно бы их еще увеличить, а то по скорости проигрываю.

                  К тому же было бы неплохо иметь буфера под СД карту, хотя бы 4Кб.
                    +6
                    Если у него действительно есть внутренний выключатель — это было бы здорово.


                    У вас Neo-M8?



                    Вообще обычно помогает просто открыть даташит.

                    Более того, из этого же даташита прямо следует, что ваши пляски с напряжением питания не имеют никакого смысла, потому что в Neo-M8 стоит DC/DC — а значит, он всегда потребляет постоянную мощность. Своими понижайками вы только ухудшаете энергопотребление системы.

                    Более того, в дисплее на питание стоит тоже DC/DC, поэтому внешней понижайкой вы тоже только жрёте лишнюю мощность от батарейки.

                    Поэтому я добавил специальную микросхему-счетчик INA219


                    Это не счётчик.

                    Говоря короче, у вас дикий overengineering, проистекающий из того, что вы начали лепить что-то из кубиков, даже не пытаясь разобраться, как они работают.
                      0
                      У вас Neo-M8?

                      У меня не чистый Neo-M8, а некий китайский модуль, в котором вроде как стоит Neo-M8. Какие еще там внутри понижайки-повышайки стоят я не знаю — модуль закрыт экраном.

                      Своими понижайками вы только ухудшаете энергопотребление системы.

                      Что конкретно Вы предлагаете сделать?

                      Более того, в дисплее на питание стоит тоже DC/DC, поэтому внешней понижайкой вы тоже только жрёте лишнюю мощность от батарейки.

                      В самой стекляшке дисплея ничего не стоит. DC/DC стоит не на дисплее, а на моей плате. И это не понижайка, а повышайка. И подключена она не к предыдущей понижайке, а к батарейке. Что тут не так?

                      Это не счётчик.

                      Согласен, это вольтметр-амперметр. У Вас есть более удачное название такого устройства? Или лучше приведите пример какой нибудь микросхемы, которая действительно считает потребление.

                      Говоря короче, у вас дикий overengineering, проистекающий из того, что вы начали лепить что-то из кубиков, даже не пытаясь разобраться, как они работают.

                      За указание на конкретные недоработки или слабые места — спасибо.
                      Но заявления вроде «даже не пытаясь» на мой взгляд не очень конструктивны. Если бы не пытался, то и железку бы не делал, и статью бы не писал.
                        +4
                        Что конкретно Вы предлагаете сделать?


                        Выкинуть половину вашей схемы и питать всё от 3,3 В.

                        В самой стекляшке дисплея ничего не стоит


                        Даже в банальном 1602 внутри есть преобразователь. «Ничего не стоит» встречается только в совсем простых сегментных ЖК-экранах.

                        Согласен, это вольтметр-амперметр. У Вас есть более удачное название такого устройства?


                        Используемое самой TI «сurrent shunt monitor» чем конкретно не устраивает?

                        Или лучше приведите пример какой нибудь микросхемы, которая действительно считает потребление.


                        Пять тычков мышкой в сайт ti.com: www.ti.com/power-management/battery-management/fuel-gauges/overview.html

                        Но заявления вроде «даже не пытаясь» на мой взгляд не очень конструктивны. Если бы не пытался, то и железку бы не делал, и статью бы не писал.


                        Это констатация факта. Вам надо научиться читать документацию, сейчас вы этого не делаете.
                          +8
                          А вообще, я сформулирую в общем виде, потому что таких статей становится всё больше.

                          Под катом многабукав, но будет инженерненько.


                          Инженерная работа, тем временем, состоит из несколько чётко выделенных и понятных этапов:

                          1) составление ТЗ на устройство
                          2) осознанный выбор компонентов, должных оптимальным образом решить поставленные в ТЗ задачи
                          3) осознанный выбор режимов работы компонентов с целью оптимизации решения
                          4) создание прототипа устройства
                          5) экспериментальное доказательство решения поставленных задач и сделанных в ходе п.п. 2-4 предположений (например, если вы предположили, что GPS-модуль потребляет при питании 2,5 В меньше, чем при питании 3,3 В, то неплохо бы это проверить — а то вдруг наоборот).

                          У вас, собственно, из этого есть только п. 4. В остальном — вы взяли какие-то модули, которые у вас где-то валялись, ничего про них не читая, слепили их вместе, а доказательством решения задачи считаете то, что результат включился и что-то отобразил на экране.

                          Вообще ничего инженерного в этом нет.
                            –4
                            ок, проехали.
                            Вы статью не читали
                              +3
                              Господи, да что там читать.

                              «У меня GPS вроде как Neo-M8, но на самом деле я не знаю, M8 там или вообще что-то китайское, что у него внутри, я не знаю, какие у него команды и режимы, я не смотрел, что от пониженного напряжения он будет меньше жрать, я не проверял, смотрите, какую гигантскую инженерную работу я проделал».
                                0
                                Ок, убрал про инженерность. Надеюсь Вам теперь полегчает.
                                  0
                                  А вы вообще этой публикацией что хотите сказать — ну, то есть, зачем, с вашей точки зрения, её читать окружающим?

                                  Как жизнеописание «чем я занимался на выходных», без практической полезности?

                                  Или сугубо эгоистичное «вывалю всё, что на душе наболело, авось нахаляву помогут исправить баги»?
                                    +5

                                    Ну, вы знаете, хотя Олегу нельзя отказать в излишнем гневе не по делу, но вообще он прав. Нужно или писать "да я чихал на потребление" и делать как угодно (и это норм, вовсе не стоит заморачиваться на том, что для вас не важно), либо штоле как-то подумать чуть глубже, прежде чем сюда выкладывать статью. Вы же знаете, что тут можно услышать…


                                    И за INA219 в данном конкретном применении — отдельный незачет. Лучше было просто ничего не ставить.

                                      +1
                                      Олег и Вы абсолютно правы практически по всем пунктам, я даже не пытаюсь спорить. В статье действительно нет финала (ну знаете, типа «героически боролся и поборол! хеппи энд!»), а потому складывается впечатление «а зачем тут это?». Некоторые вещи действительно не достаточно проработаны, но это скорее не от раздолбайства, а от отсутствия опыта.

                                      Даташиты вещь, безусловно, полезная и я их активно читаю. Но к сожалению они не всегда дают четкого понимания а как же именно оно будет работать — нужны эксперименты. А поскольку не всегда есть возможность все собрать на макетке то пришлось делать плату. Для кого-то это развлечение на вечер, у меня же оно растянулось на год и превратилось в целую эпопею.

                                      Расценивайте эту статью как заметку из блога, некий промежуточный этап, а не описание чего-то законченного. Об этом я, кстати, честно предупредил в шапке, чего тогда читали-то? И да, я надеялся на конструктивную критику. И да, я ее получил (пришлось, правда, от говна немножко отмыть), за что вам всем огромное спасибо. Особенно Олегу.

                                      Возможно такой формат блога лучше бы смотрелся на каком-нибудь форуме по электронике. Пробовал — не то. Там каждый старается облить говном, только гораздо менее конструктивно чем даже у Олега :)

                                      Так что извините, если потратил Ваше время зря. Но я буду рад действительно ценным советам. И тогда я смогу довести этот проект до того самого финала в соответствии с п.5 плана имени Олега (пункты 1-3, кстати говоря, в каком-то виде были).

                                      И за INA219 в данном конкретном применении — отдельный незачет. Лучше было просто ничего не ставить.

                                      Выпаять не проблема. Что с ней еще не так, кроме как необходимость ручного подсчета миллиампер-часов?
                                        0
                                        В статье действительно нет финала


                                        В статье нет дажя завязки. Делаете вы это творение зачем вообще? Оно должно что и где?

                                        Но к сожалению они не всегда дают четкого понимания а как же именно оно будет работать — нужны эксперименты


                                        Вообще ни одного даже близко подходящего к этому момента в вашем опусе нет.

                                        То есть, даташиты вы либо таки не читаете, а нам врёте (наиболее вероятный вариант), либо ничего в них не понимаете.

                                        Расценивайте эту статью как заметку из блога


                                        А здесь-то она зачем? Это сервис личных блогов?

                                        Но я буду рад действительно ценным советам. И тогда я смогу довести этот проект до того самого финала


                                        То есть вы хотите, чтобы за вас кто-то перелопатил вашу конструкцию и привёл её в чувство, при этом даже не зная, что и зачем вы делаете?
                                          0
                                          Ну вот как раз в том и проблема, что ничего вы там нормально не насчитаете. Хотя зависит от усердия конечно )))

                                          Возможно такой формат блога лучше бы смотрелся на каком-нибудь форуме по электронике. Пробовал — не то. Там каждый старается облить говном


                                          Я даже хз, что это за форум такой злобный. Разве что electronix…
                                            0
                                            он самый :)
                    0
                    Чем вам не нравится STM32, какие предложите альтернативы? На 1МГц STM32 потребляет около 500uA, в совсем спящем режиме 1uA.
                    В подобных устройствах важно потреблять немного в режиме работы и совсем ничего в режиме выкл, т.к. такой трекер большую часть времени будет просто лежать в столе. И тогда 10-20uA (в реальности все 100-200) от неиспользуемых устройств, быстро высадят батарейку.
                      0
                      Олег намекал на то, что STM32F103 слишком жрущий и есть серии L0/L1/L4 в которых можно выжать меньше. Для меня это следующий этап.
                        0
                        На фоне десятков mA GPS или LCD — 1uA или 20uA от контроллера? Ну не знаю. У f103 ждущий режим с часами единицы микроампер.
                          0
                          У GPS десятки миллиампер, только если его использовать в типичном arduino style — «включил питание, жду NMEA».

                          В реальной жизни любой современный чип GPS позволяет настраивать своё энергопотребление в диапазоне 1-2 порядков и падать в единицы микроампер в простое.
                            0
                            Хмм. Все равно хоть раз в пару секунд придется придется его кормить пару сотен миллисекунд. В среднем вряд ли выйдет меньше 50-100 микро. Экран, даже самый экономичный еще 100uA.
                              +1
                              Все равно хоть раз в пару секунд придется придется его кормить


                              Вы им что отслеживать собрались, что вам какое-то значимое время в сутках нужен трек с разрешением по времени в 2 секунды?

                              Экран, даже самый экономичный еще 100uA


                              Самый экономичный из известных мне, хоть здесь он и не очень подойдёт, — это сильно меньше 1 мкА.
                                +1
                                Ммммм, кстати о ТЗ (которое, кстати говоря, было).

                                Мне нужен трек с разрешением по времени 1-5 секунд. С текущим трекером (Holux M241) я записываю одну точку раз в 5 сек и это, в принципе, нормально. Реже — уже не то. Лучше пусть будет порядка 1 секунды на точку.

                                Также мне не нужно годами работать от одной батарейки. Если устройство будет работать 15-20 часов от одного заряда — этого достаточно. Т.е. моя задача уложиться в 40-50мА. Я думаю при текущем потреблении в ~100мА это более чем реально.

                                Так что за совсем микроамперы я бы не боролся, а сначала победил самых прожорливых пацанов.

                                Потребление экрана, кстати, пофиг — он у меня включается по кнопке раз в пару часов.
                                  +1
                                  То есть в этом опусе вы описываете, как вы упорно решаете проблемы, которые в нужном вам устройстве решать вообще нет никакого смысла чисто по изначальной постановке задачи?

                                  И откуда вы при этом берёте 100 мА? Типовой GPS в режиме слежения жрёт около 22 мА, данные он раз в секунду выдаёт просто по умолчанию, от процессора больше нескольких миллиампер не требуется, на SD писать, очевидно, есть смысл весьма периодически, накапливая данные в памяти.
                                    0
                                    100 мА это я только что мультиметром намерял. Если GPS будет кушать меньше когда словит спутники — я только за.
                                      +1
                                      Neo-M8 требует 34 мА максимум при питании 3 В, о чём вы без труда могли бы узнать из его даташита, если бы потрудились его хотя бы раз открыть.



                                      При этом Neo-M8 — довольно прожорливая модель, современные дешёвые GPS на MT3333 жрут процентов на 10-20 меньше.
                        +1
                        Выбранный автором STM32F1 к экономичным не относится вообще ни разу.

                        И тогда 10-20uA (в реальности все 100-200)


                        А эта реальность — она откуда у вас берётся? Ну то есть, например, акселерометр MMA8452 в режиме сна потребляет 1,8 мкА, а в реальности он в режиме сна сколько потребляет?
                          0
                          Сколько потребляет экран в выкл. состоянии? А SD карта, GPS. Я их даташиты не читал, но знаю, что не всегда устройства потребляют 1uA. Например, ESP8266 — 20uA, неудачно выбранный LDO — до нескольких mA.
                          Альтернативы то какие, L-серия? Понятно, что они лучше, но так ли уж это важно. В этом девайсе нужно проснутся раз в пару сек, быстро распарсить NMEA и дальше спать. При этом фоновое потребление GPS будет гораздо больше, чем у процессора.
                            +1
                            Я их даташиты не читал, но знаю


                            Это многое объясняет.

                            GPS на MT3333 в battery backup mode потребляет, например, 8 мкА.

                            Альтернативы то какие, L-серия? Понятно, что они лучше, но так ли уж это важно


                            При чём тут вообще альтернативы? Автор лепит ручное управление питанием, чтобы сэкономить меньше 2 мкА потребление акселерометра, но при этом ставит F103, жрущий во сне в разы больше.

                            Зачем он это делает — спросите у него.
                              0
                              при этом ставит F103, жрущий во сне в разы больше

                              Он жрет 1uA в режиме RTC.
                              GPS на MT3333 в battery backup mode потребляет, например, 8 мкА

                              Hot start: 1 second typical. При 30mA. Потребление STM тут на порядки ниже, потому что он может в это время спать или работать с частотой в 128KHz.
                                +2
                                И? Вы мне доказать что хотите? Что автор опуса решил питание у акселерометра отключать, потому что тщательно просчитал потребление, а не потому, что, подобно вам, «я даташиты не читал, но знаю»?

                                P.S. F103 в Stop mode с RTC жрёт не 1 мкА, а около 3, что легко узнать из даташита. Использовать же его в Standby mode вы в общем случае не захотите.
                                  0
                                  Ок, давайте я уберу транзистор с акселерометра и покончим с этим бессмысленным спором. Я согласен, он там не нужен.
                                  Про отключение GPS вы мне тоже написали. Вот мой унитаз, жопу я вам вчера показывал, продайте мне, наконец, туалетную бумагу!.
                                  Что нибудь еще резануло Ваш опытный взгляд в этой схеме?

                                  Целевое потребление схемы — 40-50мА (не мкА).
                                    0
                                    Что нибудь еще резануло Ваш опытный взгляд в этой схеме?


                                    Меня резануло в вашем отношении к окружающим — вы вываливаете плохо переваренный и небрежно сляпанный материал, чтобы окружающие бесплатно помогли вам его поправить.
                                      0
                                      Это плохо просить совета у более опытных товарищей?
                                        +1
                                        Вы не спрашиваете совета.

                                        Вы вываливаете плохо переваренный и небрежно сляпанный материал, чтобы окружающие бесплатно помогли вам его поправить.
                                          0
                                          Ок, проехали.
                                          Совета я спрашивал как минимум раз 5 по тексту
                      0
                      Я наверно тупой, но что мешало взять отладочную плату за 4 килорубля, что-то вроде B-L475E-IOT01A2 со всей рассыпухой, питанием и процессором заточенным под сверхнизкое потребление тока?
                        0
                        Собственно, на отладочной плате я и разрабатывал проект первых полтора года. Честно говоря, я задолбался шаманить над этим ежиком проводов, где постоянно терялся какой нибудь контакт и что-нибудь переставало работать. К тому же это получалось совершенно нетранспортабельно.

                        Более того, как выяснилось в ходе работы над корпусом, на макетке это одно, а когда пытаешься втиснуть это в маленький корпус то вылазит столько нюансов о которых даже и не подозреваешь.

                        Вконце концов, а в готовом устройстве Вы тоже хотели бы отладочную плату видеть?
                          0
                          На той отладочной плате уже все что вы перечислили из периферии распаяно. Не надо там ничего паять, просто берешь и пишешь софт ))

                          STM32L4
                          64-Mbit Quad-SPI (Macronix) Flash memory
                          Bluetooth® V4.1 module (SPBTLE-RF)
                          Sub-GHz (868 MHz or 915 MHz) low-power-programmable RF module (SPSGRF-868 or SPSGRF-915)
                          802.11 b/g/n compliant Wi-Fi® module from Inventek Systems (ISM43362-M3G-L44)
                          Dynamic NFC tag based on M24SR with its printed NFC antenna
                          2 digital omnidirectional microphones (MP34DT01)
                          Capacitive digital sensor for relative humidity and temperature (HTS221)
                          High-performance 3-axis magnetometer (LIS3MDL)
                          3D accelerometer and 3D gyroscope (LSM6DSL)
                          260-1260 hPa absolute digital output barometer (LPS22HB)
                          Time-of-Flight and gesture-detection sensor (VL53L0X)
                          2 push-buttons (user and reset)
                          USB OTG FS with Micro-AB connector
                          Flexible power-supply options:
                          ST LINK USB VBUS or external sources

                          А в готовых устройствах стмовские платы готовые платы я на самом деле видал, отлично работают. Вопрос цены на самом деле, да и все.
                            0
                            Ну из того, что мне нужно тут есть только USB, акселерометр, и магнетометр и блютус. Причем последние 2 у меня в приоритетах довольно таки низко — хочу сначала все остальное запустить.

                            8Мб (64МБит) флеша мне мало, мне нужно как минимум раз в 8 больше. WiFi, NFC, барометр, гигрометр мне не нужны (надеюсь их можно не включать).

                            Тут как минимум нет SD (то, что глючило в первую очередь). Дисплей, GPS и вторую кнопку придется подключать отдельно на проводках. Системы питания нет в принципе. Так что все это придется размещать на какой нибудь второй плате. Но тогда возникает вопрос, а зачем брать отладочную плату и над ней что-то колхозить, если можно развести плату под себя? Собственно это я и сделал, заодно прокачался в электронике.
                              0
                              Ну если цель была прокачаться в электронике, тогда ОК.

                              Я же привык оценивать проекты с точки зрения ROI, поэтому т.к. все там выведено на жесткие коннекторы, то особо проводков не надо. Не нашел под рукой модуля дисплея с гнутыми контактами, но идея должна быть понятна. Так же под этот формфактор есть батарейная дочерняя плата за 800 рублей с липо на 800 ма + GPS модуль от майтек — около 2к. Вот скидал минут за 10:

                              drive.google.com/open?id=1kZWrZazvR7IqG6BPw0yLHwYk64ZnVQ3e
                              drive.google.com/open?id=1hTP9tM4OPNM8Z9g9s0gEfIuWAlF21fuf

                              Это в МСК, конечно. Оптом в закупе Китая можно процентов на 40 скинуть. В итоге была бы первая версия, на которой вылижется софт, а уже потом делать lean версию.

                              P.S. GPS логгер без барометра? У вас горок мало?
                                0
                                Это хобби проект. Тут нет никакого ROI.
                                Цель всего проекта — поковыряться с технологиями, электроникой и прошивкой.
                                Тут важен сам процесс. Ну и сделать устройство мечты тоже хочется.

                                P.S. GPS логгер без барометра? У вас горок мало?

                                Как-то раз в поездку взял Garmin Dakota. Так вот в трек он пишет высоту с барометра, а не GPS, и это никак не настраивается. В итоге судя по трекам все самолеты летают на высоте 2км, ни выше ни ниже.

                                Может быть барометр и появится в этом проекте, но он точно не будет основным в измерении высоты.
                        0
                        Секрет запайки деталей с шагом 0.5мм — использование хорошего флюса. Он увеличивает поверхностное натяжение припоя и припой стремится собираться в капельки, а не размазываться между выводами.
                          0
                          Посоветуйте марку, пожалуйста.

                          Сначала у меня был китайский RMA-223. С ним припой стремился собираться в капельки, только вот к металлу эти капельки прилипать не хотели :) Сейчас у меня какая-то зеленая паста местного производства — с ней паяется хорошо, но уж слишком припой растекается.
                            0
                            EFD 6-412-A Flux Plus
                              0
                              спасибо
                              +1
                              Зеленая паста местного производства это случаем не Харьковский F-2000? Нельзя этим паять электронику — в мусор.
                                0
                                Ухты, не думал, что такое может быть. Да, у меня именно F-2000, но выглядит чуток не так, как у этого мужика — чуток более темный, и без гранул. Продавали как самый супер-пупер для тонкой электроники.

                                Хорошо, что я не поленился и отмыл этот флюс (хотя наверняка под микросхемами осталось).
                                  0
                                  Рекомендую и с остальными (всеми) видушками у него ознакомиться — довольно интересно.
                            0
                            Все коммуникационные ноги микроконтроллеры отмечены как Five Volt Tolerant (кроме UART2 на ножках PA2/PA3), а значит если там появится 3.3В от самого высоковольтного устройства ничего плохого не произойдет

                            Также неплохо проверить условия и сноски — быть может это выполняется не для всех напряжений питания.

                            GPS и Bluetooth должны без проблем скушать “низкое” напряжение от микроконтроллера. Тоже самое касается и других “высоковольтных” устройств.

                            Проверяйте параметры «входное напряжение высокого уровня» (что-то вроде Vih) для периферийных устройств. Если оно сравнимо с напряжением питания контроллера — возможны пляски с бубном.

                            … светодиод.… Поскольку микроконтроллер не сможет выдавать на своей ноге больше 2В при питании от батареи, то push-pull режим GPIO использовать нельзя. Только open-drain.

                            См. замечание про 5V tolerant. Есть опасность словить утечку в питание контроллера через СИД.

                            Поскольку на шине I2C будет сидеть трехвольтовое устройство (INA219), то и подтяжки также нужно делать к трем вольтам.

                            Подтяжка I2C, возможно, тоже cможет питаться от меньшего напряжения (проверить периферию и контроллер по Vih и контроллер на действительность 5V tolerant). Ну и, как отметил olartamonov, — через неё будет паразитная запитка «железно» отключенной периферии. И через SDIO с UART — тоже возможно.

                            Вот табличка с расчетами.

                            ИМХО — ошибка есть. Должно получше получаться. 100 мА при 3.3 В с КПД 90% должны преобразовываться в 73 мА и 12 часов от 900 мА*ч.
                            О недостаточной проработке материала по энергосбережению — сказано достаточно.

                            Так на двух выводах должны стоять конденсаторы по 2.2мкФ между выводом и землей (а не между землей и питанием, как у F1).

                            Скачайте распоследний DS и Errata и перепроверьте 3 раза. Ересь какая-то.
                            Или дайте ссылку и номер страницы.
                            Обвязка в виде двух кварцев взята с других схем, найденных в интернете (перепроверено в даташите).

                            Перепроверьте необходимость C24 и C25. Попадалось уведомление об их вредности.

                            Разъем USB будет торчать наружу устройства, а там может гулять статическое электричество. Оказывается есть специальные микросхемы (такие как STF202-22),

                            Подключая и Vbus — можно, в некоторой степени, обезопаситься от «прилёта» непотребства по цепи питания. Ну и подобрать тогда ограничитель без встроенного резистора.

                            Или лучше приведите пример какой нибудь микросхемы, которая действительно считает потребление.

                            Также они могут называться «coulomb counter». Но тут вероятна вилка — ваттметр может обойтись дороже, чем вычисление «ток * напряжение».

                            Даже в банальном 1602 внутри есть преобразователь. «Ничего не стоит» встречается только в совсем простых сегментных ЖК-экранах.

                            Неправда Ваша. Сейчас — может и есть, но опционально (для него выделятся отдельная буква в part number). А лет 10..15 назад — были практически только с внешним питанием для коммутации сегментов (равным питанию логики или большим его по абсолютной величине).
                            Во многих COG «стекляшках» это напряжение, даже есть встроенный преобразователь на переключаемых конденсаторах, — можно подавать снаружи.
                              0
                              Скачайте распоследний DS и Errata и перепроверьте 3 раза. Ересь какая-то.
                              Или дайте ссылку и номер страницы.


                              У STM32F40x там выход встроенной LDO'шки, которая из-за радикально большей жручести ядра без внешнего конденсатора не может. Видимо, чтобы не уменьшать число GPIO, решили под конденсаторы отдать пару бывших земляных ног.
                                0
                                ИМХО — ошибка есть. Должно получше получаться. 100 мА при 3.3 В с КПД 90% должны преобразовываться в 73 мА и 12 часов от 900 мА*ч.

                                Это я погорячился. Вместо «среднепотолочных» для аккумулятора 3.6-3.7 В привёл к 5.
                                0
                                А какова цель всего этого «цельнодеревянного бицикла Бабского с квадратными колесами»? Чем не устроил старый дешевый телефон с eBay плюс powerbank плюс собственная программка?
                                  0
                                  Дописал целый раздел «Что и зачем», который призван осветить эти вопросы.

                                  А в целом, попрограммировать я и на работе могу, но мне бы хотелось поковыряться с железками.
                                    0
                                    В плане функциональности не убедительно (все равно телефон, как hardware base, выглядит намного интереснее; вдобавок, если чуть расширить бюджет, можно найти телефон с существующей Linux прошивкой), но как «повозиться с железками» покатит, хотя вам наверняка не удастся добиться оптимального энергопотребления и «товарного» вида.
                                  0
                                  Привет. Я в последнем проекте юзал bq24070 + TPS63000. Но ваш вариант организации питания мне преглянулся. Жаль что микросхему из вашего проекта я не нашел в магазине, где закупаюсь (((
                                    0
                                    Покупал на ali. Цена копеечная.
                                    Но даташит, мягко говоря, неполный.
                                    Использую эту микросхему уже в третьем проекте — каждый раз какая-то неожиданная фигня вылазила
                                      0
                                      Эта РТ1502 часто используется в телефонах и планшетах -> искать надо не в магазинах радиодеталей, а у ремонтников и их магазинах. Правда цена будет выше, встречал даже на порядок.
                                      0
                                      Делаю себе для лодки трекер на базе NEO-M8N и ESP32. От встроенного экрана в процессе эволюции отказался. Пока использую смартфон. Хочу подключить в качестве экрана читалку на e-ink, но пока не придумал как ее герметизировать.
                                        0
                                        Будет интересно посмотреть что у Вас получится.
                                        +2
                                        Вообще то меня просто испугали Ваши требования к памяти, конечно, современные МК имеют ее много на борту, но все таки…
                                          0
                                          Не так много как хотелось бы. Вот тут в конце я исследовал распределение памяти в проекте. Правда это было года полтора назад. Сейчас потребление еще возросло и составляет порядка 19кб.

                                          Из них очень много потребляется HAL'ом, практически на каждую периферию 200-500 байт, а под USB вообще больше 2кб. Это всевозможные хендлы, которые имеют указатели на другие хендлы более низкого уровня.

                                          Также берем во внимание 1кб экранного буфера, буферов USB, MSC, SD, UART'ов и I2C, данных моей программы и библиотек — вот и получается дофига. А некоторые буфера (SD и USB) хотелось бы увеличить для ускорения передачи (двойная буферизация, передача пакетов бОльшей длины)

                                          Да, там есть возможности для оптимизации, этим я занимаюсь регулярно. Но в целом раз я уже притащил контроллер потолще, то почему бы и не воспользоваться его возможностями?
                                            +1
                                            Решил все таки обновить свое понимание вопроса. Дизассемблировал и посмотрел на распределение памяти.

                                            Самый большой потребитель — FreeRTOS.
                                            Разумеется сам FreeRTOS потребляет мало (пара сотен байт), но текущая организация заставляет выделить довольно ощутимый кусок (в данный момент 10кб) на heap. Я еще детально не исследовал распределение памяти внутри этой кучи, но как минимум в ней нужно выделить место на каждый поток (сервисные данные + стек), а также все очереди сообщений и семафоры/мутексы (которые в сущности те же очереди). В данный момент у меня работает 7 потоков, но думаю со временем добавится еще 3-5.

                                            У вытесняющей многозадачности бесчисленное количество плюсов, но есть и минусы. Так, прерывание может возникнуть внезапно и совершенно непонятно какой именно поток в этот момент будет выполнятся. А потому у каждого потока стек должен быть достаточным, чтобы любое прерывание могло в этом стеке сохраниться.

                                            У меня в планах переделка кода под статическую аллокацию потоков и очередей. Тогда это все перейдет из неявного в явное. А пока видим просто голую цифру в 10кб.

                                            Оставшиеся 7кб (прогнал, текущее потребление 17кб, не 19) это всевозможные буфера — дисплея, USB, UART, I2C, SD карты, а также хендлы для периферии (которые, к сожалению, огромны до невозможности). Чего только USB стОит — почти 3кб (и есть планы по увеличению буферов еще на 3-4кб)
                                            0
                                            Самая неизящная реализация задуманного.
                                            Я не понимаю почему вдруг стало мало STM32F103CB, когда должно с головой хватить STM32F103C8!
                                            У меня проект легко влез в С8 имея на борту акселерометр, 4 АЦП высокого разрешения, блютус, жпс, барометр, термометр, прирометр, СД карточка с буфером записи, использованы все ГПИО, мощный парсер и преобразователь протоколов, всё это завернуто в РТос, частота обработки 100гц. И это всё сделано на стм32дуино.

                                            Встроенные логгеры имеют всякие жпс чипы МТК и скайтраки. А есть скайтраки со встроенным МК по типу ардуины.
                                              +1
                                              Ответил в соседнем коменте

                                              Возможно дело в дисплее и пользовательском интерфейсе. Без него, наверное, было бы проще — получил данные, записал на флешку, повторил. Ну и USB очень много за собой потянул.
                                                0
                                                Только сейчас одну вещь сообразил.

                                                F103C8 от F103CB отличается количеством флеша — в первом 64кб, во втором 128кб. По факту и тот и другой в 99% случаев это F103CB, просто маркированный по разному. Во всяком случае интернет пишет, что в blue pill платы (которые вроде как F103C8) на самом деле без проблем вливается 128кб.

                                                По флешу у меня потребление около 57кб. Даже если брать весь функционал, который я только планирую делать, то думаю 128кб все равно со свистом уложусь.

                                                Мне же в этом контроллере не хватало ОЗУ — и в том и в другом по 20кб. Ну а детали я уже написал выше
                                                0
                                                В каком редакторе нарисованы схемы.
                                                И в чем выполнялась разводка платы?

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое