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

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

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

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

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

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

Согласен. Но я боялся не осилить такую плотную и маленькую плату.
Вместо 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…

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

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

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

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

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

Почему вы так думаете? Разве контроллер не возьмет на себя дергание всех управляющих сигналов?
Возьмет, но частично. У 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.

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

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

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

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

Но в целом Ваш вариант бездисплейного устройства мне нравится. Не хотите статью написать? :)
UFO landed and left these words here
UFO landed and left these words here
Можно, только зачем? Это классическое «не пришей сами-знаете-к-чему рукав».
UFO landed and left these words here
Для экономии электроэнергии есть смысл отключать питание тех устройств, которые в данный момент не используются. Так возле каждого потребителя я поставлю по транзистору, которым буду управлять отдельным сигналом микроконтроллера


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

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

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

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

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

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

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

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

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

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

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

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

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

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


У вас Neo-M8?



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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

Вообще ничего инженерного в этом нет.
Господи, да что там читать.

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

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

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

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


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

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

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

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

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

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

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

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


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

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


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

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

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


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

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


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

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


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

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


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

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


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

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

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

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

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

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



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

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


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


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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сначала у меня был китайский RMA-223. С ним припой стремился собираться в капельки, только вот к металлу эти капельки прилипать не хотели :) Сейчас у меня какая-то зеленая паста местного производства — с ней паяется хорошо, но уж слишком припой растекается.
Ухты, не думал, что такое может быть. Да, у меня именно F-2000, но выглядит чуток не так, как у этого мужика — чуток более темный, и без гранул. Продавали как самый супер-пупер для тонкой электроники.

Хорошо, что я не поленился и отмыл этот флюс (хотя наверняка под микросхемами осталось).
Рекомендую и с остальными (всеми) видушками у него ознакомиться — довольно интересно.
Все коммуникационные ноги микроконтроллеры отмечены как 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 «стекляшках» это напряжение, даже есть встроенный преобразователь на переключаемых конденсаторах, — можно подавать снаружи.
Скачайте распоследний DS и Errata и перепроверьте 3 раза. Ересь какая-то.
Или дайте ссылку и номер страницы.


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

Это я погорячился. Вместо «среднепотолочных» для аккумулятора 3.6-3.7 В привёл к 5.
UFO landed and left these words here
Дописал целый раздел «Что и зачем», который призван осветить эти вопросы.

А в целом, попрограммировать я и на работе могу, но мне бы хотелось поковыряться с железками.
UFO landed and left these words here
Привет. Я в последнем проекте юзал bq24070 + TPS63000. Но ваш вариант организации питания мне преглянулся. Жаль что микросхему из вашего проекта я не нашел в магазине, где закупаюсь (((
Покупал на ali. Цена копеечная.
Но даташит, мягко говоря, неполный.
Использую эту микросхему уже в третьем проекте — каждый раз какая-то неожиданная фигня вылазила
Эта РТ1502 часто используется в телефонах и планшетах -> искать надо не в магазинах радиодеталей, а у ремонтников и их магазинах. Правда цена будет выше, встречал даже на порядок.
Делаю себе для лодки трекер на базе NEO-M8N и ESP32. От встроенного экрана в процессе эволюции отказался. Пока использую смартфон. Хочу подключить в качестве экрана читалку на e-ink, но пока не придумал как ее герметизировать.
Вообще то меня просто испугали Ваши требования к памяти, конечно, современные МК имеют ее много на борту, но все таки…
Не так много как хотелось бы. Вот тут в конце я исследовал распределение памяти в проекте. Правда это было года полтора назад. Сейчас потребление еще возросло и составляет порядка 19кб.

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

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

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

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

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

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

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

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

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

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

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

Мне же в этом контроллере не хватало ОЗУ — и в том и в другом по 20кб. Ну а детали я уже написал выше
В каком редакторе нарисованы схемы.
И в чем выполнялась разводка платы?
Only those users with full accounts are able to leave comments. Log in, please.