psL

у вас в стеке создается копия статической или глобальной структуры. Лучше использовать указатель void make_TA(RTN* train){ train->NoPt = ...; или ссылку, если это С++

u-boot нужно собрать с поддержкой nand, справка по командам u-boot для nand: help nand запись командой: nand write [addr_from] [addr_to] [length]

можно попробовать вот такое использовать https://github.com/nanopb/nanopb

использовать kobs-ng? вообще, здесь http://otladka.com.ua/wiki/doku.php?id=ev-imx287-micro много про ваш процессор, при чем на русском.

это вопрос реализации агента. Можно агента(сервер) реализовать на сервере, а менеджер(клиента) - на железке. Тогда железка будет оповещать о своем состоянии pdu set, а забирать команды get. При этом ПО мониторинга должно опрашивать агента на сервере, а не на железе.

а разработчики пишут: "протокол" )) https://docs.influxdata.com/influxdb/v0.9/write_protocols/ С точки зрения записи в базу - все очень просто. С точки зрения чтения и анализа - сложнее, но для этого есть графические средства. То что поверх HTTP это скорее преимущество, чем недостаток - не порежут в случае чего. А для 3g модемов со встроенным tcp/ip стеком вообще д.б. очень удобно. И главное, в отличие от облака, полностью контролируется владельцем объекта. При этом не нужно путано объяснять, что часть системы находится непонятно где и ее работоспособность гарантируется только хорошим настроением непонятно кого. Ну и не все клиенты настолько богатые люди, чтобы использовать бесплатные вещи;)

Да, grafana только выводит графики. Для сбора информации используется Influxdb, у нее протокол очень простой: https://github.com/influxdb/influxdb

А почему не нравится? Можно использовать, например, NMS типа Nagios, Zabbix, OpenNMS и тп с RRD базой данных. Или вообще использовать InfluxDB+Grafana.

https://ez.analog.com/message/13824#13824 странно, что не в форуме по dsp http://electronix.ru/forum/index.php?showforum=3. это чтобы никто не заметил?

По идее xmodem не обладает какой-то сверхизбыточностью. Пропускная способность канала при 9600 это ~1 кБайт в секунду. Т.е. 256кБ передадутся не менее чем за 4,5 минуты. При 15 минутах эффективная скорость 30% от максимальной. Это м.б. связано с серьезными потерями или искажениями данных в канале, но также м.б. что скорость передачи в радиоканале bluetooth меньше 9600 Нужно смотреть на стороне передатчика время между началом передачи кадра и ответом от приемника, вести подсчет ack и nak. Это должно помочь определить узкое место.

к содержимому указателя видимо д.б. (*FileCount)++;

Raspberry совместимый порт - уже стандарт дефакто) Модуль отладочный Салют-ЭЛ24Д1

найдите в меню программ программу терминала. или войдите через Ctrl+Alt+F2, (3,4,5,6 и тд) или какого-нибудь линуксоида наймите на фриланс

1) можно использовать существующий rxString 2) можно использовать автомат состояния в приемнике. т.е. должны быть состояния приема soh, проверки номера кадра, проверки инверсии номера, и только после корректного прохода автоматом состояний должна быть фаза "сложить в буфер" 3) можно складывать в буфер в прерывании, а разбирать в отдельном потоке и тд Как уже писал ранее смещение кадра м.б. из-за принятого в паузе мусора, при этом голова кадра сместиться от начала буфера. При превышении длины буфера crc не совпадет, т.к. конец кадра определился неправильно. После чего остаток кадра (crc и т.д.) запишется в начало буфера. как-то так.

http://stackoverflow.com/questions/1489932...macro-as-in-arg

можно вообще использовать livecd или liveusb

uart имеет особенность принимать мусор, поэтому принимать решение о начале или конце кадра нужно не по превышению ожидаемого размера, а по признаку начала или конца кадра в данных кадра. т.е. в вашем случае необходимо добавить условие старта кадра при приеме soh от передатчика и только после этого начинать складывать данные в буфер. UINT* bw; f_write(&fil, &rxString[3], SIZE, (UINT*)&bw); звездочка в объявлении лишняя

...и ходить в разноцветном колпаке

вот проект. решает аналогичную задачу. может пригодится. lwshell.zip

C++ 11 разве не умеет?

uart вообще может мусор с линии принимать, тем более на больших скоростях. Как минимум нужна синхронизация по началу кадра и crc данных кадра

видимо Интернет за пределами МО деградирует или работает по другим законам.

Интересно, а buildroot отсюда https://github.com/hi35xx не подойдет?

у новых пользователей ЛС отключены http://electronix.ru/forum/index.php?showt...%E8%F7%ED%FB%E5

Спасибо!