Harvester

В системе используется Таймер 0 в режиме автозагрузки. Таймерное прерывание (№4) разрешается по внешнему событию. Проблема: после разрешения таймерного прерывания оно начинает генерироваться не всегда (не при каждом запуске устройства). Может кто-нибудь с таким сталкивался? Понимаю, что вопрос дурацкий, но я всю голову уже сломал. (

А нужна ли здесь вообще гальваническая развязка? Я бы сделал так - в устройстве небольшой модуль (ту же ардуину), который принимает (СИД)/передает (кнопки) сигналы на устройство. К нему подключаться по UART. Если очень хочется - через гальванически развязанный приемопередатчик.

Вышел из строя БП на базе ШИМ-контроллера MP020-5 (сгорел сам контроллер и входной резистор "предохранитель"). После замены вроде бы заработал, но не до конца. На "холостом" ходу (нагрузка - вход линейного стабилизатора) все хорошо, а при увеличении нагрузки (обмотка реле) выходное напряжение падает до 0. Очевидно, не работает ОС, но что здесь еще может сломаться - не понимаю. Подскажите пожалуйста, в каком направлении смотреть.

Спасибо большое.

Добрый день. Подскажите, как называется аналог разъема BLD-20 (двухрядное гнездо на кабель под обжим), но с ключом, как у IDC? Используется в китайских ЛА Saleae Logic 16

Еще забыли 4-е состояние - обрыв шлейфа в результате неисправности.

И все равно непонятно. Пусть у меня переменная uint64_t. Почему же модификатор %u выводит 0, хотя значение, содержащееся в переменной, укладывается в диапазон uint32_t?

А слона-то я и не заметил )))) Замена модификатора на %llu решило проблему. Пункт б) вычеркиваем - сам дурак. Приношу извинения разработчикам компилятора и, на всякий случай, Петрову с Бошировым.

Да Получил ассемблерный листинг. addi 0,31,152 # tmp235,, lis 9,.LC22@ha # tmp236, la 3,.LC22@l(9) #,, tmp236 mr 4,0 #, tmp235 bl statfs64 # mr 0,3 # D.6778, cmpwi 7,0,0 #, tmp237, D.6778 bne 7,.L48 # .LBB9: .loc 2 382 0 lwz 9,160(31) # fs.f_blocks, D.6781 r9 <- fs.f_blocks.hi lwz 10,164(31) # fs.f_blocks, D.6781 r10 <- fs.f_blocks.lo li 3,10 #, r3 <- LOG_DEBUG lis 0,.LC23@ha # tmp238, addic 4,0,.LC23@l #, tmp238, r4 <- адрес строки mr 5,9 #, D.6781 r5 <- r9 (fs.f_blocks.hi) mr 6,10 # tmp5, D.6781 r6 <- r10 (fs.f_blocks.lo) crxor 6,6,6 r6 <- 0 bl msg # msg() .loc 2 385 0 lwz 9,160(31) # fs.f_blocks, D.6782 r9 <- fs.f_blocks.hi lwz 10,164(31) # fs.f_blocks, D.6782 r10 <- fs.f_blocks.lo stw 10,12(31) # blocks, D.6782 12(31) <- r10 (blocks = fs.f_blocks.lo) .loc 2 388 0 li 3,10 #, r3 <- LOG_DEBUG lis 0,.LC23@ha # tmp239, addic 4,0,.LC23@l #, tmp239, r4 <- адрес строки lwz 5,12(31) # blocks, r5 <- 12(31) (blocks) crxor 6,6,6 r6 <- 0 bl msg # msg() .L48: Получается, что а) поля структуры fs 64-битные и б) VA_ARGS некорректно работает с 64-битными значениями Чуда в очередной раз не произошло :D

Еще нет. Не могу понять, как сгенерировать листинг :( void msg(int log_level, const char* mes, ...) { va_list arg; struct timeval tv; struct tm* tm = NULL; if (log_level > logLevelMax) return; gettimeofday(&tv, NULL); tm = localtime(&tv.tv_sec); fprintf(_file4log, "%02u:%02u:%02u.%06lu ", tm->tm_hour, tm->tm_min, tm->tm_sec, tv.tv_usec); va_start(arg, mes); vfprintf(_file4log, mes, arg); va_end(arg); } Что тут может быть кривого? Просто структура. Обновил код.

Столкнулся с такой странностью. В результате выполнения кода struct statfs fs; if (statfs(DREC_STORAGE_DEF, &fs) == 0) { msg(LOG_DEBUG, "f_blocks=%u\n", fs.f_blocks); msg(LOG_DEBUG, "f_bfree=%u\n", fs.f_bfree); msg(LOG_DEBUG, "f_bavail=%u\n", fs.f_bavail); size_t blocks = fs.f_blocks; size_t bfree = fs.f_bfree; size_t bavail = fs.f_bavail; msg(LOG_DEBUG, "f_blocks=%u\n", blocks); msg(LOG_DEBUG, "f_bfree=%u\n", bfree); msg(LOG_DEBUG, "f_bavail=%u\n", bavail); } получаю такой вывод: 09:47:39.949371 f_blocks=0 09:47:39.950237 f_bfree=0 09:47:39.950361 f_bavail=0 09:47:39.950421 f_blocks=103705 09:47:39.950481 f_bfree=99962 09:47:39.950540 f_bavail=99962 Т.е. при выводе непосредственно полей структуры получаем нули. Как такое может быть? Если что, функция msg() - просто обертка над printf/fprintf: void msg(int log_level, const char* mes, ...)

riscv32-unknown-elf-gcc 7.1.1 И да, смена компилятора в планы не входит, по крайней мере, сейчас.

Похоже, Вы меня неправильно поняли. 1-е выражение (предложенное Вами) - я так и делаю в своей программе. 2-е - как я хочу сделать, но не понимаю, почему не работает. Я и не спорю, просто не могу понять. :( Получается, что инициализация static BusFrame *const pxTxBuffers[] = {busBufTx1, busBufTx2}; происходит в рантайме? Я считал, что константы известны уже на этапе компиляции.

Как это нет, если я уже объявил и проинициализировал массив pxTxBuffers? Я так и делаю, просто хочу понять, почему не работает сабж.

Просто указатель uint32_t *txbuf;