Проведите. Только честно, с неподвижной бутылкой. Когда рассол при таянии собирается внизу, как в море, а лёд сверху начинает таять только при температуре выше нуля.
видимо мы друг друга не понимаем. Таяние при -6 градусах
Да, Вы явно меня не понимаете. Если соленая вода замерзла при -6 градусах, то таять она будет при температуре около нуля градусов. Можете проверить экспериментально )
А чуть южнее Арктики посыпают лёд на дорогах солью, и он начинает таять, хотя изначально не был солёным
Потому что при этом тает поверхностный слой, формируя рассол. А при замораживании солёной воды в бутылке, у Вас рассол будет внизу. А вся верхняя часть - пресный лёд, который благополучно начнет таять при температуре около нуля градусов.
У термоса есть теплопотери и есть продукты, которые надо охлаждать
И отсюда энергия, которую может поглотить лёд при плавлении и которая на два порядка превосходит его удельную теплоёмкость, имеет решающее значение и очень мало зависит от температуры льда.
200г соли на литр воды даёт -6,35
Эти 25 КДж/кг играют незначительную роль, по сравнению с 330 КДж/кг
Причем и лёд из пресной воды можно охладить хоть до -70. Или Вы решили вдруг, что если заморозить солёную воду, то концентрация соли во льду не снизится в несколько раз? При замораживании соленой воды или рассол стекает вниз, или соль кристаллизуется. Поэтому температура плавления льда из солёной воды будет весьма незначительно отличаться от температуры плавления пресного льда. Кстати, в Арктике нередко опресняют воду именно замораживанием.
Физику удалось обмануть? Удельная теплота плавления воды на два порядка больше её удельной теплоемкости. Поэтому энергетическую разницу при использовании замороженной солёной и пресной воды, если ничего на замораживается, можно заметить только при помощи точных приборов. Но уж никак не на глаз.
Вы забыли указать, для чего используете потом солёную воду. Пресную можно просто выпить, так что полезный объем она не сокращает. А что делать с солёной?
Мы начали разговор про экономию памяти на MCU, а закончили обсуждением SOAP и enterprise-схем, это уже про совсем другой уровень задач.
А это кто писал?
нужна интеграция с внешними сервисами
Причем одно другому не помеха. Например - АСКУЭ, который с одной стороны, интеграция MCU с внешними сервисами, а с другой стороны - или бинарный протокол до концентраторов (например, DLMS\COSEM), и уже SOAP или PB до серверов в ЦОД.
Или берем ПЛК, которые тоже с текстовым JSON не дружат, но дружат с бинарным Modbus-TCP
gRPC - это уже другой класс задач
Только, для примера, тот же PLCNext без проблем gRPC поддерживает. Ну или если ближе DIY, то при помощи nanopd+nghttp2 gRPC вполне доступен на ESP32.
как комфортно жить с JSON именно на контроллерах, где malloc/free превращаются в проблему, а разработчикам нужны удобные инструменты
Я дал на него ответ, но Вы почему-то хотите в бинарной прошивке и оперативке MCU видеть текстовый формат JSON, даже не взирая на то, что памяти на него нужно больше в разы, чем для PB. Осталось еще локальные переменные в текстовом формате хранить, гоняя их через sscanf()/sprintf() )))
Я понимаю, что Modbus или CAN не всегда подходят, но сразу от них прыгать на JSON, забив на расход памяти?
Предсказуемая? Если в PB int32 никогда не превратится в пять миллиардов или вообще в дробное число, то JSON это ну никак не гарантирует. С типизацией у JSON всё очень плохо.
JSON остаётся читаемым и легко отлаживаемым прямо в логах или редакторе
Так как логи не в оперативной памяти хранятся, то пишите туда хоть CSV. Экономить там особо нечего. И в редакторе тоже никто не запрещает использовать JSON, который при сборке превратится в PB, если такое требуется. Хотя такой потребности у меня ни разу не возникало. Всё же PB - это протокол для обмена данными, а JSON - формат исходных файлов, где часто удобней TOML или YAML, который при сборке проекта при необходимости конвертируется в статическую структуру данных в флеш или EEPROM памяти MCU.
автоматический маппинг в структуры на C даёт быстрый результат без тонны ручного кода
А в PB что-ли иначе?
как только нужна интеграция с внешними сервисами или читаемость на этапе отладки - JSON выигрывает
Вы так шутите? JSON Schema так и не взлетела и до сих пор заметно уступает XSD. Почти весь B2B в enterprise так и сидит на SOAP. Потому что там часто надо точно указывать, что вот этот вес округляется до трех знаков после запятой, а вот эта цена - до двух, это поле может принимать только такие значения, это поле обязательное, а это - опциональное. А уж для MCU делать интеграцию с внешними, а не внутренними сервисами, да еще и заниматься разбором JSON Schema - очень странное решение.
На поставщиков информации в JSON мне приходилось нарываться. И это большая боль, так как парсить такой JSON и сохранять его в РСУБД - постоянный геморрой. Причем 9 из 10 таких поставщиков о JSON Schema и не слышали, публикуя описание схемы в текстовом формате где-то на своём сайте и меняя его без предупреждения.
А вот на PB реализовать внешний обмен получается, хотя и приходится обвешивать proto уточнениями вида [(goole.type.options).sql_type = "decimal(12,3)"]. Но это уже другая история, так как потоковый gRPC позволяет пушить уведомления, когда принимающая сторона за NAT, что на SOAP сделать затруднительно.
Как раз сырые структуры передавать не лучшая идея. Мало того, что они занимают больше места, чем PB, так еще и не поддерживают совместимость снизу вверх
ручное копание в бинарных дампах
Есть множество инструментов, которые позволяют просматривать и редактировать бинарную информацию в удобном для человека виде. Не поверите, но даже в процессе вебсерфинга это и происходит, так как обмен между браузером и сервером происходит преимущественно в бинарном виде после сжатия bzip.
Так про экономию памяти и статья. PB, особенно для числовых данных, даёт очень существенную экономию памяти - в разы. А уж при отладке можно потерпеть и бинарный формат. Благо все инструменты для работы с ним имеются.
Для семейного и дружеского общения использую Jami. Сервера не надо, устанавливается из магазинов приложений, есть под Windows и Linux. Качество звука оставляет желать лучшего, но вполне терпимо. Видео требует хорошего канала, так что его использую с ограничениями.
Концепция в том, что голосовые звонки можно совершать и принимать за рулем, используя handsfree. А вот даже прочитать сообщение не отвлекаясь от дороги - уже проблематично.
Во-первых, не понятно, какая связь между потоками и PIO или DMA.
Во-вторых, во встраиваемых системах бесконечные циклы используются в тех случаях, когда выход из них не имеет никакого смысла. Поэтому пример из OS общего назначения тут совершенно не к месту.
На М4 около Воронежа, где разрешённая 130 км/ч. Шмяк! Жена: "Ворона!". Я: "Слышал...". Бампер, на удивление выдержал, а вот противотуманка слетела с креплений и провалилась внутрь бампера.
С первым абзацем понятно. Подобные обработчики по необходимости или формируют прерывание, или забрасывают сообщения в кольцевой буфер и ничего вызывать не должны.
А второй абзац вообще не понял. На обработку изменения состояния переходим или по прерыванию, размещающему сообщение в кольцевом буфере, или по сообщению в этом же кольцевом буфере, если его туда поместил цикл опроса. И везде бесконечные циклы, выход из которых вообще не имеет смысл.
Если по факту по моим наблюдениям, то большинству текущих пользователей Jira, бесплатного (за исключением некоторых расширений) Redline достаточно.
Я имел ввиду только процесс плавления. Замораживать можете в любом положении
Проведите. Только честно, с неподвижной бутылкой. Когда рассол при таянии собирается внизу, как в море, а лёд сверху начинает таять только при температуре выше нуля.
Да, Вы явно меня не понимаете. Если соленая вода замерзла при -6 градусах, то таять она будет при температуре около нуля градусов. Можете проверить экспериментально )
Потому что при этом тает поверхностный слой, формируя рассол. А при замораживании солёной воды в бутылке, у Вас рассол будет внизу. А вся верхняя часть - пресный лёд, который благополучно начнет таять при температуре около нуля градусов.
И отсюда энергия, которую может поглотить лёд при плавлении и которая на два порядка превосходит его удельную теплоёмкость, имеет решающее значение и очень мало зависит от температуры льда.
Эти 25 КДж/кг играют незначительную роль, по сравнению с 330 КДж/кг
Причем и лёд из пресной воды можно охладить хоть до -70. Или Вы решили вдруг, что если заморозить солёную воду, то концентрация соли во льду не снизится в несколько раз? При замораживании соленой воды или рассол стекает вниз, или соль кристаллизуется. Поэтому температура плавления льда из солёной воды будет весьма незначительно отличаться от температуры плавления пресного льда. Кстати, в Арктике нередко опресняют воду именно замораживанием.
Как раз если такое случится, то данное утверждение будет ложным:
А вот эффективность охлаждения зависит от удельной теплоты плавления на два порядка больше, чем от температуры льда.
Физику удалось обмануть? Удельная теплота плавления воды на два порядка больше её удельной теплоемкости. Поэтому энергетическую разницу при использовании замороженной солёной и пресной воды, если ничего на замораживается, можно заметить только при помощи точных приборов. Но уж никак не на глаз.
Вы забыли указать, для чего используете потом солёную воду. Пресную можно просто выпить, так что полезный объем она не сокращает. А что делать с солёной?
Ну а кто-то хочет в холодильнике хранить молочные продукты или вареные яйца. Которые замораживать ну никак не стоит )))
Ну а радикальный и общедоступный метод заморозки я уже выше указал.
Растаявшую воду использовать будет сложно. Совсем лучше, тогда уже "сухой лёд" самому изготавливать и туда засыпать )))
Добавил смайлики, так как если температура будет ниже нуля, что относится и к бутылкам с солёной водой, то получим не холодильник, а морозильник.
Так с этого надо было и начинать. В таком случае, честь и хвала Вам за полезный труд.
А это кто писал?
Причем одно другому не помеха. Например - АСКУЭ, который с одной стороны, интеграция MCU с внешними сервисами, а с другой стороны - или бинарный протокол до концентраторов (например, DLMS\COSEM), и уже SOAP или PB до серверов в ЦОД.
Или берем ПЛК, которые тоже с текстовым JSON не дружат, но дружат с бинарным Modbus-TCP
Только, для примера, тот же PLCNext без проблем gRPC поддерживает. Ну или если ближе DIY, то при помощи nanopd+nghttp2 gRPC вполне доступен на ESP32.
Я дал на него ответ, но Вы почему-то хотите в бинарной прошивке и оперативке MCU видеть текстовый формат JSON, даже не взирая на то, что памяти на него нужно больше в разы, чем для PB. Осталось еще локальные переменные в текстовом формате хранить, гоняя их через sscanf()/sprintf() )))
Я понимаю, что Modbus или CAN не всегда подходят, но сразу от них прыгать на JSON, забив на расход памяти?
Предсказуемая? Если в PB int32 никогда не превратится в пять миллиардов или вообще в дробное число, то JSON это ну никак не гарантирует. С типизацией у JSON всё очень плохо.
Так как логи не в оперативной памяти хранятся, то пишите туда хоть CSV. Экономить там особо нечего. И в редакторе тоже никто не запрещает использовать JSON, который при сборке превратится в PB, если такое требуется. Хотя такой потребности у меня ни разу не возникало. Всё же PB - это протокол для обмена данными, а JSON - формат исходных файлов, где часто удобней TOML или YAML, который при сборке проекта при необходимости конвертируется в статическую структуру данных в флеш или EEPROM памяти MCU.
А в PB что-ли иначе?
Вы так шутите? JSON Schema так и не взлетела и до сих пор заметно уступает XSD. Почти весь B2B в enterprise так и сидит на SOAP. Потому что там часто надо точно указывать, что вот этот вес округляется до трех знаков после запятой, а вот эта цена - до двух, это поле может принимать только такие значения, это поле обязательное, а это - опциональное. А уж для MCU делать интеграцию с внешними, а не внутренними сервисами, да еще и заниматься разбором JSON Schema - очень странное решение.
На поставщиков информации в JSON мне приходилось нарываться. И это большая боль, так как парсить такой JSON и сохранять его в РСУБД - постоянный геморрой. Причем 9 из 10 таких поставщиков о JSON Schema и не слышали, публикуя описание схемы в текстовом формате где-то на своём сайте и меняя его без предупреждения.
А вот на PB реализовать внешний обмен получается, хотя и приходится обвешивать proto уточнениями вида [(goole.type.options).sql_type = "decimal(12,3)"]. Но это уже другая история, так как потоковый gRPC позволяет пушить уведомления, когда принимающая сторона за NAT, что на SOAP сделать затруднительно.
Как раз сырые структуры передавать не лучшая идея. Мало того, что они занимают больше места, чем PB, так еще и не поддерживают совместимость снизу вверх
Есть множество инструментов, которые позволяют просматривать и редактировать бинарную информацию в удобном для человека виде. Не поверите, но даже в процессе вебсерфинга это и происходит, так как обмен между браузером и сервером происходит преимущественно в бинарном виде после сжатия bzip.
Так про экономию памяти и статья. PB, особенно для числовых данных, даёт очень существенную экономию памяти - в разы. А уж при отладке можно потерпеть и бинарный формат. Благо все инструменты для работы с ним имеются.
Если нужна экономия памяти, то не разумней ли использовать ProtocolBuffers и nanopd
Для семейного и дружеского общения использую Jami. Сервера не надо, устанавливается из магазинов приложений, есть под Windows и Linux. Качество звука оставляет желать лучшего, но вполне терпимо. Видео требует хорошего канала, так что его использую с ограничениями.
Концепция в том, что голосовые звонки можно совершать и принимать за рулем, используя handsfree. А вот даже прочитать сообщение не отвлекаясь от дороги - уже проблематично.
Во-первых, не понятно, какая связь между потоками и PIO или DMA.
Во-вторых, во встраиваемых системах бесконечные циклы используются в тех случаях, когда выход из них не имеет никакого смысла. Поэтому пример из OS общего назначения тут совершенно не к месту.
На М4 около Воронежа, где разрешённая 130 км/ч. Шмяк! Жена: "Ворона!". Я: "Слышал...". Бампер, на удивление выдержал, а вот противотуманка слетела с креплений и провалилась внутрь бампера.
С первым абзацем понятно. Подобные обработчики по необходимости или формируют прерывание, или забрасывают сообщения в кольцевой буфер и ничего вызывать не должны.
А второй абзац вообще не понял. На обработку изменения состояния переходим или по прерыванию, размещающему сообщение в кольцевом буфере, или по сообщению в этом же кольцевом буфере, если его туда поместил цикл опроса. И везде бесконечные циклы, выход из которых вообще не имеет смысл.