В целом, Коля, всё так и есть. И, по большому счёту, мне действительно это "пофигу". Но я всю жизнь старался помогать людям и мне сейчас обидно, что из-за глупости политиков нормальные люди лишаются технической поддержки в нужных им программных продуктах. Но это лучше, чем когда из-за той же глупости политиков люди лишаются жизни. По крайней мере, я практически уверен, что это решение гитхаба не лишило никого жизни, и я рад этому.
Который неюзабелен для международного сотрудничества в рамках опенсорс-проектов по причине хотя бы отсутствия языков, отличных от русского, в интерфейсе сайта. Не говоря уже про отсутствие интеграций и всяких там GitHub Actions / Workflows.
Хм, если читать это внимательно и вдумчиво с точки зрения формального русского языка, то получается, что о суммах ниже 600 000 не надо сообщать только если на другом конце операции был банк в ЕАЭС или в "автоматической" стране. А если в любой другой стране, то даже о копейке отчитываться надо. Или я неправильно прочитал?
Подождите-ка! Мы всё ещё о том, что Ядро якобы продаёт государству "то, что на железе ibm, с лицензией на софт ibm, лицензии за техподдержку от ibm" ? Тогда причём тут чьё-то производство чужих медленных процессоров, которые Ядро не использует?
Батарейка на RTC ставится не для того, чтобы часы не убегали «на пару секунд», а для того, чтобы настройки времени не терялись при отключении питания. Большинство известных мне чипов RTC не просто останавливаются при снятии питания, а именно что сбрасывают показания даты/времени в начальное значение. Батарейка нужна для того, чтобы этого не происходило. А чтобы не убегали или не отставали — это NTP или PTP надо.
И всё это было бы очень полезным, если бы информация была актуальной. К сожалению, все самые лучшие по моим критериям лампы (яркие, с низкой пульсацией, с неплохой цветопередачей, диммируемые) с цоколем E27 — сняты с производства и давно не выпускаются. А тестов по современным моделям тех же X-Flash — нет. Остаётся только надеяться, что они держат марку, и у них по-прежнему всё хорошо.
К сожалению, это правда. Код IPMI-серверов зачастую очень грязный, как и код клиентских утилит. Во многом причиной этому — то, что и сама спецификация IPMI не отличается стройностью и содержит достаточное количество противоречий и странностей.
Как мне кажется, Вы путаете IPMI и веб-интерфейс управления. Протокол IPMI ничего не знает про "remote console" за исключением Serial-over-LAN, и это встроенная в спецификацию IPMI 2.0 функциональность, поддерживаемая ipmitool и другими утилитами управления.
Та же remote console, которая KVM, — это функция WebUI. Этот интерфейс каждый производитель реализует по своему усмотрению, спецификации на это нет. Очень многие реализации основаны на стеке MegaRAC производства American Megatrends. Старые версии этого стека требовали java applet. Сейчас, насколько мне известно, они отошли от этой практики, но я давно не имел дела с MegaRAC.
Попыткой стандартизировать веб-доступ является стек протоколов DMTF (MCTP/PLDM/RedFish). Он, вероятно, в ближайшие лет 5-10 основательно потеснит IPMI.
Забота о чужой безопасности — вообще концепция многим непонятная.
А почему эта безопасность важна для РЖД — да потому, что завтра появится какой-нибудь «предприниматель», который сделает приложение, рисующее билетики вовсе даже не бесплатно, а просто «со скидкой». И при должной социальной инженерии большинство пользователей этого приложения даже не поймёт, что платит деньги не перевозчику, а не пойми кому. Возможно, существуют и иные сценарии, сильно не выгодные для РЖД.
В любом случае, на мой взгляд, по мотивам этой информации сильнее всех должно возбудиться именно РЖД и вздрючить этот Микротех. Да только вот, насколько я знаю РЖД, не будут они возбуждаться…
Помимо прочего, очень не рекомендую когда-либо писать в коде вот так:
P_c = ((11.5 * Vout + 2.25) / 4.5) + Pcorrection;
Тут сразу две проблемы:
Через пару лет, когда полезете разбираться в коде, будете долго вспоминать, что это за циферки такие и почему они именно такие
Если эту формулу вы используете более, чем в 1 месте, то потом есть риск поменять её в одном месте и забыть поменять в другом.
Решение состоит в том, чтобы никогда не использовать «магические числа», а заменять их макросами с понятными именами (и комментами в месте определения макросов). Ну а если формула используется в коде несколько раз, то лучше и её всю заменить на макро или инлайн функцию.
Ну так а сравниваете-то вы это сохранённое значение с чем? Правильно, с показаниями АЦП. В итоге, при каждом сравнении приходится переводить данные АЦП в человекочитаемый формат, сохранённый в EEPROM. А хранили бы в формате, выдаваемом АЦП, сэкономили бы на этой конверсии. В вашем случае, правда, это не критично, но в других системах может быть и важно.
Ну и верно тут ранее заметили, что эти 0-1023 легко можно поделить на 4 отбрасыванием двух младших битов и никто не заметит разницы.
Там даже разбивать ничего не надо. Пишите подряд и всё. Все I2C EEPROM имеют режим последовательной страничной записи. Один раз посылаем адрес микросхемы и бит записи, потом адрес стартовой ячейки, а потом данные без стопа. Стоп — только после последнего байта. Адрес инкрементируется в микросхеме сам.
Ну и что, что он «сейвит» байты. Это как-то до сих пор никому не мешало хранить там хоть 16, хоть 32, хоть 64 бита, хоть строки любой длины (лишь бы влезло). Процедура записи 4 байт мало отличается от таковой для 1 байта.
Кстати, вот совершенно справедливое было высказано тут предложение хранить данные в EEPROM в «сыром» виде, как выдаёт АЦП. И ничего отбрасывать или округлять не надо было бы. А всей этой арифметикой заниматься уже непосредственно перед выводом на экран.
было решено с моей стороны так: зная, что число x.x0 это давление float типа, его можно легко конвертировать в byte если умножить на 10 и записать в память
Поздравляю! Вы «изобрели» формат записи с фиксированной точкой. ;)
А вообще вы молодец. Спасибо. Интересно. Люблю малую автоматизацию.
Вот тут я не могу не поддержать. Потому что сил уже нет никаких. Но вообще странно, конечно. Половина депутатов и министров — представители той самой субкультуры из «лихих» 90х.
В целом, Коля, всё так и есть. И, по большому счёту, мне действительно это "пофигу". Но я всю жизнь старался помогать людям и мне сейчас обидно, что из-за глупости политиков нормальные люди лишаются технической поддержки в нужных им программных продуктах. Но это лучше, чем когда из-за той же глупости политиков люди лишаются жизни. По крайней мере, я практически уверен, что это решение гитхаба не лишило никого жизни, и я рад этому.
А как ваши иностранные коллеги им пользуются? Учат русский язык? Я, возможно, плохо смотрел, но других языков я там не увидел.
Который неюзабелен для международного сотрудничества в рамках опенсорс-проектов по причине хотя бы отсутствия языков, отличных от русского, в интерфейсе сайта. Не говоря уже про отсутствие интеграций и всяких там GitHub Actions / Workflows.
Хм, если читать это внимательно и вдумчиво с точки зрения формального русского языка, то получается, что о суммах ниже 600 000 не надо сообщать только если на другом конце операции был банк в ЕАЭС или в "автоматической" стране. А если в любой другой стране, то даже о копейке отчитываться надо. Или я неправильно прочитал?
Подождите-ка! Мы всё ещё о том, что Ядро якобы продаёт государству "то, что на железе ibm, с лицензией на софт ibm, лицензии за техподдержку от ibm" ? Тогда причём тут чьё-то производство чужих медленных процессоров, которые Ядро не использует?
Или вы просто ошиблись веткой комментариев?
ipmitool
ipmiutil
openipmi
Ещё есть утилита от SuperMicro под Windows. Называется SMCIPMITool, но к ipmitool отношения не имеет.
Или я вас не верно понял?
И всё это было бы очень полезным, если бы информация была актуальной. К сожалению, все самые лучшие по моим критериям лампы (яркие, с низкой пульсацией, с неплохой цветопередачей, диммируемые) с цоколем E27 — сняты с производства и давно не выпускаются. А тестов по современным моделям тех же X-Flash — нет. Остаётся только надеяться, что они держат марку, и у них по-прежнему всё хорошо.
К сожалению, это правда. Код IPMI-серверов зачастую очень грязный, как и код клиентских утилит. Во многом причиной этому — то, что и сама спецификация IPMI не отличается стройностью и содержит достаточное количество противоречий и странностей.
Как мне кажется, Вы путаете IPMI и веб-интерфейс управления. Протокол IPMI ничего не знает про "remote console" за исключением Serial-over-LAN, и это встроенная в спецификацию IPMI 2.0 функциональность, поддерживаемая
ipmitoolи другими утилитами управления.Та же remote console, которая KVM, — это функция WebUI. Этот интерфейс каждый производитель реализует по своему усмотрению, спецификации на это нет. Очень многие реализации основаны на стеке MegaRAC производства American Megatrends. Старые версии этого стека требовали java applet. Сейчас, насколько мне известно, они отошли от этой практики, но я давно не имел дела с MegaRAC.
Попыткой стандартизировать веб-доступ является стек протоколов DMTF (MCTP/PLDM/RedFish). Он, вероятно, в ближайшие лет 5-10 основательно потеснит IPMI.
А почему эта безопасность важна для РЖД — да потому, что завтра появится какой-нибудь «предприниматель», который сделает приложение, рисующее билетики вовсе даже не бесплатно, а просто «со скидкой». И при должной социальной инженерии большинство пользователей этого приложения даже не поймёт, что платит деньги не перевозчику, а не пойми кому. Возможно, существуют и иные сценарии, сильно не выгодные для РЖД.
В любом случае, на мой взгляд, по мотивам этой информации сильнее всех должно возбудиться именно РЖД и вздрючить этот Микротех. Да только вот, насколько я знаю РЖД, не будут они возбуждаться…
Тут сразу две проблемы:
Решение состоит в том, чтобы никогда не использовать «магические числа», а заменять их макросами с понятными именами (и комментами в месте определения макросов). Ну а если формула используется в коде несколько раз, то лучше и её всю заменить на макро или инлайн функцию.
Ну и верно тут ранее заметили, что эти 0-1023 легко можно поделить на 4 отбрасыванием двух младших битов и никто не заметит разницы.
Ну и раз уж у вас Ардуина с её библиотеками, то там это делается через EEPROM.put():
www.arduino.cc/en/Tutorial/EEPROMPut
Кстати, вот совершенно справедливое было высказано тут предложение хранить данные в EEPROM в «сыром» виде, как выдаёт АЦП. И ничего отбрасывать или округлять не надо было бы. А всей этой арифметикой заниматься уже непосредственно перед выводом на экран.
Поздравляю! Вы «изобрели» формат записи с фиксированной точкой. ;)
А вообще вы молодец. Спасибо. Интересно. Люблю малую автоматизацию.