artemkad

C учетом того, что по территории европейской части СССР дважды прокатилась война оставившая 25 млн. человек без крыши над головой в климате который способен убивать, они весьма хорошо справились. США в таких условиях до сих пор бы были в руинах. Нет, капиталисты умеют считать только деньги в своем кармане. А заработают они на шпалах или на страховках грузов катающихся по этим шпалам или на липовых сертификатах безопасности- им без особой разницы. Не фантазируй. Такого как-то не наблюдается. Многие литиевые АКБ не допускают зарядку ниже 0 градусов. Так что - много.

Да, да - блэкаут 2003 это ярко показал. Иначе говоря - наиболее безмозглым способом результат которого то самое "исторически сложившееся" положение. К оборудованию из Штатов как раз особо претензий нет, но вот исторически сложившаяся система электроснабжения США во многом уступает единой энергосистеме СССР наследием которой до сих пор пользуются его бывшие территории. Причина - в СССР система строилась по единому плану, а в США безмозглым диким рынком.

У тебя есть факты подобного или только фантазии? Особенно с учетом прозрачного электронного бюджета Москвы... Обычно это и есть основная причина.

Думают и потому электробусов в Москве валом. Проблема решаемая далеко не одним способом. Банальное - терморегулирование батареи в процессе заряда. Ну или чуть сложнее - использование LTO-батарей на одну+ поездку допускающих заряд на глубоком минусе.

Больше похоже на проводимость остатков флюса. Наблюдал когда-то такое с водосмываемым - с тех пор никогда такой гадостью не пользуюсь. Не обязательно - в Tiny была потому и идиотская, потому как утечка была скорее всего через цепи мультиплексора АЦП и потому проявлялась весьма избирательно.

Проверь нет ли на других ногах напряжения выше питания. Когда-то на AtTiny26 была идиотская зависимость превышения на одних плюс коммутация на других приводила к утечке на входах АЦП.

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

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

Китайцы точно так-же как STM покупают лицензию у ARM-а. А дальше на что они будут больше похожи - дело самих китайцев...

Дык потому и "и даже чуть больше". Ему ведь не SLIP надо, а данные передавать Если не рассматривать DMA - по скорости без особой разницы. Самая медленная там скорость это скорость прихода символов.

Есть такое. Но там все есть и даже чуть больше (CRC), достаточно прозрачно, а потому начинающему есть от чего оттолкнуться. ЗЫ. Кстати, пересмотрел еще раз - не так уж и громоздко. Всего лишь использовали switch вместо if и байт-состояния(что как по мне перспективнее) вместо oldChar.

Думаю, вот это тут будет самое оно: https://ru.wikipedia.org/wiki/SLIP https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol https://github.com/marcinbor85/slip/blob/master/slip.c

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

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

Наглядно, универсально, передавать текст уже умеешь, символы не являющиеся текстом используются для управления потоком. В общем, то что я нарисовал это а-ля JSON https://ru.wikipedia.org/wiki/JSON .

Вообще-то спор как раз в тему - один из рабочих вариантов превратить твою структуру typedef struct { unsigned int TimePosition; unsigned char WORK_STATE; unsigned char POWER_REGULATION_MODE; } tINFO_VAR; tINFO_VAR INFO_VAR; в текст вида "INFO_VAR": { "TimePosition": 12345; "WORK_STATE": 5; "POWER_REGULATION_MODE": 10;}; передать его через канал связи, а на приемном конце после разбора снова собрать его в структуру. Я так понимаю, ты предпочитаешь вариант "читай что на заборе написано - там все есть". Понимаешь, у меня все больше закрадывается подозрение, что ты сам их не читал, а лишь слышал что у классиков это есть. А то, что у них есть совсем не то что мы тут обсуждаем тебе даже в голову не приходит.

Есть поток: "abrakadabrapin:0000in1+10" и есть лексемы "pin:", "in", "+", цифры ну а теперь попробуй сперва найти границы, а потом лексемы...

Тебе сюда все оглавление Вирта привести что-бы показать что в оглавлении нет примеров или таки уточнишь?

Конкретнее пли-и-из. Приведи место в книгах Вирта и Страуструпа вместо тупых ничего не означающих намеков на авторитет. Если ты не понял, я телепатом не являюсь что-бы знать чего там ты имел ввиду.

Как вариант; typedef union { unsigned char buffer[BUFFER_SIZE]; struct { unsigned int TimePosition; unsigned char WORK_STATE; unsigned char POWER_REGULATION_MODE; } ; }tINFO_VAR; Впрочем, от копирования там особо смысла мало

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

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

Гайды для начинающих с Ютуба. Мы ведь в разделе для начинающих или как? Забавный код... Забавно использование аппаратного таймера в виде костыля который каждую миллисекунду обновляет текущую позицию в очереди. Меня-бы жаба задавила тратить на это помимо DMA еще и таймер...

Точно? Попробуй, к примеру, его обнаружить в stm32f030f4 ? наверно потому "все доступные" обзоры примеров использования DMA с UART заканчиваются использованием DMA для передачи посылок. Задача как-бы не для этого раздела... Сами лексемы известны - неизвестны которые из них и где располагаются в принятой строке.

Про любое и любую платформу. На STM32 свет клином не сошелся. Там нет жестких условий. Жесткими они становятся только от того, что парсинг пытаешься засунуть в прерывание. Что считать если неизвестна длина лексемы, неизвестно их число в строке, неизвестно длина строки и неизвестно их положение? Отсюда хеш в потоке не посчитаешь.