esaulenka

Из гугла, очевидно. Первая ссылка по запросу "удельная расчетная электрическая нагрузка электроприемников квартир жилых зданий" (половину запроса не я вбил, а гугловское автодополнение). От какого фонаря эта таблица составлялась в не таком уж далёком 2003 году - вопрос интересный, конечно... PS нафлудили знатно... Началось с вопроса "хочу на кухне из подножных материалов что-нибудь соорудить", закончилось какими-то промышленными частотниками на 100500 киловатт...

Насколько я понимаю (посмотреть внимательно RTX руки так и не дошли), эта osMutexNew() использует heap. Размер хипа какой? Увеличить пробовали?

Для надёжности надо провода перерезать, чтоб уж точно ничего не засиралось. Нормально функционирующий CAN-передатчик с установленным флажком auto retransmit передаёт в шину ровно ОДНО сообщение, получает подтверждение и замолкает, пока его не попросят передать что-то ещё. Пока нет этого банального понимания функционирования шины (и механизма разрешения коллизий в этой самой шине), разговаривать дальше смысла немного...

Зная остальные темы jenya7, необходимо предполагать наиболее дурацкую ошибку. И, кончено же, она есть: CAN_InitStructure.CAN_NART = ENABLE; //ENABLE DISABLE NO AUTOMATIC RETRANSMITTION

Посмотрел asm. Что-то мне не нравится флажок LCCNENSE_NO. Во-первых, название плохое, а во-вторых, какие-то при его выставлении манипуляции странные происходят. Где он проверяется, правда, я не нашёл. И какой-то FL_LCCN непонятный встречается... Ну и я правильно понял, что начальная калибровка выполняется с помощью какой-то программы с ПК? Такое подозрение, что она в EEPROM пишет какую-то константу в этот момент (специфичную для данной конкретной версии прошивки). PS плотно с 51-ми никогда не работал, бог миловал...

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

Дурацкая идея - автор исходного прибора сделал какую-то самопальную защиту. Если не сходится контрольная сумма, иногда оно что-то где-то будет портить. Для проверки - поменять ОДНУ букву (или даже цифру), проверить, что в бинарнике поменялся только один байт, и включать...

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

Ого! Круто! Мы пока что возимся с оригинальным стеком, большого желания писать полностью своё пока нет. Тем более, планов громадьё, хочется почти полный набор "фишек" протокола. Но на определённые грабли уже наступили, разбираемся...

Коллега, внимательнее! Там вся структура из 8-битных переменных, паддинга между ними нет. А вот то, что гражданин "гуру" взял значения из uint8_t flimsw_state; uint8_t rlimsw_state; и двух последующих байт (которые случайно опять оказались нулевыми) и опять не понял, что произошло - ну, увы, тут половина тем таких...

Это означает, что они внедрили супер-интеллектуальную схему зарядки в виде резистора между Vdd и Vbat. Подключением резистора, вроде б, можно программно управлять. Можно ли на этот ваш аккумулятор подавать 3.3 вольта (пусть и через резистор) - надо думать. Кажется, нельзя.

Вот он, голос разума! :-) https://en.cppreference.com/w/cpp/numeric/math/NAN https://en.cppreference.com/w/cpp/numeric/math/INFINITY

Потому что он знает, что этот int никогда не может быть отрицательным, и нет никакой разницы, применять ASRS или LSRS.

У меня дурацкий вопрос (раз уж тема для начинающих). Как это читать? То есть одну строку я могу прочитать, вторую могу. Две сразу - не могу :-) Хотя, кажется, никому из отвечающих затруднений это не составило...

Вот у одного меня возникает вопрос "что хотел сказать автор" ? Как мне кажется, if (! (ind & 0x01)) куда более читаемо (и компилируется сразу без ошибок). О том, что, например, ind & 0x04 понятнее, чем ind | 0xFB, вообще молчу...