Какой чип?

ща, найду в ящике

возможно у тебя плата для пауербанка, надо немного другую

Я помню что долго ебся с китаеардуинкой на каком-то сраном чипе, который был говно и надо было перепрошить

А я еще и на маке

Это был ад

> мак > китаеговно Нет-нет, а иногда тянет на говно, да?

> мак > китаеговно Нет-нет, а иногда тянет на говно, да?

я музыкант

к моему сожалению, на маке реализация музыкозапилов достаточно хорошая

во всем остальном гори он синим пламенем

Какой чип?

на плате маркировка MT3608

хотя это не то,наверное

dc-dc?

да, это дцдц стопудов

блин, сколько говна-то лежит, ищу дальше

кстати говоря про вот это все

вот есть малинка, а есть банан

TC4056A

он вроде грят помощнее и дешевле

никто не щупал?

TC4056A

это банка?

http://caxapa.ru/thumbs/888618/TC4056A-AMS.zh-CN.en.pdf

вроде бы банка

03962a

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

есть пятивольтовые комбо сразу с usb-out https://www.aliexpress.com/item/5pcs-5V-Step-Up-Power-Module-Lithium-Battery-Charging-Protection-Board-Boost-Converter-LED-Display-USB/32732400277.html у меня валяется таких десяток

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

А в 2032 защита есть?

А в 2032 защита есть?

по-моему нету там, там и так места нет. но я не уверен

ну писец. кто их проектировал такие, без переключения питания

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

Так вот, насчет протоколов. Речь шла о том, что банальный FSM вида "[длина пакета] [пакет]" рассинхронизируется, если потерян любой из байтов. И, ЧСХ, никогда не синхронизируется обратно.

ссылка есть на этот IP5603? я нифига не могу найти

он вроде грят помощнее и дешевле

и поддержки ещё меньше

и поддержки ещё меньше

ну вот тоже про это задумался

если готов пердолиться с декомпилом блобов и накатыванием тонны дров - вперед

трешка малиновая +-3к

если готов пердолиться с декомпилом блобов и накатыванием тонны дров - вперед

нет нет нет нет

TC4056A

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

есть пятивольтовые комбо сразу с usb-out https://www.aliexpress.com/item/5pcs-5V-Step-Up-Power-Module-Lithium-Battery-Charging-Protection-Board-Boost-Converter-LED-Display-USB/32732400277.html у меня валяется таких десяток

удобно, спасибо

а вот это плохо

блин, неужто нет нормального пятивольтового ИБП, лол?

а что у нас уарт позволяет читать по полбайта?

Не позволяет, но го в анархию

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

С практической точки зрения просто разделение по меджик и все, какая вероятность что в конфиге твоего устройства будет строка MG7986431START MG7986431END ? Изобретать протокол для произвольных данных вовсе не нужно

Изобретать протокол для произвольных данных можно и нужно, это было бы ололо вселенского масштаба, если бы TCP ломался при попытке передать строку а-ля "TCPMAGICSTRING", которая там м.б. была захардкожена. Напротив, вероятностные протоколы, которые может быть работают, но не всегда - это зло

Для заливки десятка конфигурационных переменных в девайс по уарту? универсальный протокол? Вот зачем он там нужен, кроме перфекционизма разработчика? У tcp задача другая совсем и требования

Если человек хочет protobuf - очевидно, он хочет, чтобы и другие части были достаточно универсальные и переиспользуемые

Ну так можно и тцп стек впихнуть, универсально, переиспользуемо, даже реализации небольшие есть

протобаф — удобно

я не уверен, что следует изобретать свои протоколы под каждое устройство

https://ru.aliexpress.com/item/5-V-2-1a-UPS-Diy/32920638389.html

Очищенные ссылки от @kostett: * https://aliexpress.com/item/5-V-2-1a-UPS-Diy/32920638389.html

Так вот, насчет протоколов. Речь шла о том, что банальный FSM вида "[длина пакета] [пакет]" рассинхронизируется, если потерян любой из байтов. И, ЧСХ, никогда не синхронизируется обратно.

Так для этого и добавляется меджик сигнатура заголовка, в случаее ошибки ждешь ее

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

Посоветую посмотреть протокол промышленных устройств.

Те же диспенсеры и купюроприемники

Там всё очень просто и надежно

Сейчас, я к ним драйвера писал, корябну

старт - размер - данные - конец - crc

каждый пакет подтверждается

то есть запрос - ack ответ - ack

правда с размером редкость, обычно у них у каждой команды захардкоден в протоколе размер данных

при этом может быть nck вместо ack если не сошлась сумма

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

И да, определен таймаут в протоколе

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

Мне кажется, на небольших пакетах идея с управляющим 8 битом куда менее оверхедная, чем с магическими последовательностями

по сути любые енкоды например base128 будет добавляение бита THIS IS NOT MAGIC в каждый байт. вот мне интересно решается ли задача на 100% с добавляением менее чем одного бита к каждому байту

ack ack ack

и без ack ов

имхо - не решается.

по сути любые енкоды например base128 будет добавляение бита THIS IS NOT MAGIC в каждый байт. вот мне интересно решается ли задача на 100% с добавляением менее чем одного бита к каждому байту

Мне вот что-то кажется, что нет

Хотя вариант с escape символом м.б. зайдет

У меня вроде сломать не получается. Но там оверхед переменный. Если такого символа в данных нет - нулевой, если только из них и состоит - x2

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

У тебя снова всплывает проблема синхронизации начала передачи этого пакета

не всплывает, в данном случае пакет уже будет структурой из этих 10битных "подпакетов-байтов"

Как ты защищаешься от того, что контроллер начнет твои 10-байтовые "символы" с середины интерпретировать?

base64 лучше, чем base128 — оно более-менее однозначно читается и для текстовой среды, коим, по логике является юарт, идейно подходит плюс имеется маркер = того, что это base64 единственное, что нет CRC. но это уже перестраховка