Здравствуйте! Возникла такая потребность выводить множество переменных через юарт,последовательно,друг за другом. Вопрос : как наиболее рационально организовать хранение данных? Просто куча переменных,или структура,или массив? Но в дальнейшем все эти переменные будут меняться,и будет менятся их количество. Как все организовать правильно,что бы в дальнейшем можно было изменить как саму переменную,так и их количество, и весь блок разом отправить в юарт, независимо от его размера? Спасибо за советы
автор планирует изменять количество переменных. думаю, структура с известным размером не годится. если только создавать структуру с максимально возможным числом переменных...
_________________ Мудрость приходит вместе с импотенцией... Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Да это все понятно. Просто есть несколько переменных a b c...n которые отвечают за свои параметры. В процессе отладки их будут больше. Вот я и спрашиваю как их лучше упаковать,что бы удобно было их изменять,и по команде отправить в юарт
Просто есть несколько переменных a b c...n которые отвечают за свои параметры. В процессе отладки их будут больше.
Судя по ээээ "ушам" - речь идёт об изобретении очередной "трассировки для нищих", да? Если так - то само собой напрашивается первейший пункт-вопрос отчего-то не прозвучавший в вашем ТЗ - кто будет эти "твиты" читать? Если хуманоид-отладчик в терминалке - что может быть лучше CR-терминированных фреймов? <1/2/3-символьный префикс>:<значение>CR - и всё в шляпе, кроме траты ресурсов МК на форматирование. Если с приёмного конца програмка висит или другой МК - ещё проще - заводим массив структур { 1|2 -байта id; поле типа; union для всех возможных типов данных }. При отсылке берём начало массива и отстукиваем sizeof(массив) байтов наружу - и пусть писюшный программер со своими бесконечными гигагерцами парсится. Если повезёт и endiannes не совпадёт на устройстве и компе - прокачаем свои скилы в области байт-свапинга.
PS: Во втором случае, кстати, про #pragma pack не забудьте, или что там у вас заместо него. Причём на обоих коммуникационных "терминалах".
_________________ Одновременным нажатием LIGHT и POWER, РП Sangean ATS-909X (ver 1.29) превращается в ATS-909XR!
При таких аппетитах неплохо бы узнать что такое "сериализация" и "десереализация" (переменных/структур/объектов/...) и если охота расширяемое нечто - про протокол лучше все-таки подумать заранее. На правах идеи можно что-то типа TLV, например. Да, потребуется некая конверсия из формата в проводе в то что в структурах в программе лежит. Но это может быть достаточно просто и быстро, если об этом подумать. Заодно у компьютера, или кто там на другой стороне UART может быть своя идея насчет типов данных и их размеров и даже endianess, уповать что они совпадут 1 в 1 - моветон и чревато приколами.
Например посмотрите как IE (information elements) в Wi-Fi сделаны. В базовом виде все довольно просто. Но постепенно там весьма серьезно расширили возможный ассортимент сведений передаваемых в служебных пакетах. Смысловой аналог чего-то такого не сильно сложно накодить.
Я вам скажу больше, в планах обновлять прошивку мк,из управляющей программы на пк,через бутлоадер. Бут хочу взять готовый от ардуино.Проанализировать протокол обмена,и написать точно такой же обмен
Ничему не противоречит. Я себе тоже бут корябаю, правда для STM32. Изначально не планировалось, но я не смог удобно раскидать лапки под требования STшного бута, значит придется делать свой. Правда протокол я сделаю как удобнее мне и как лучше работает .
Про самодельный бутлоадер и транспортный протокол обычного примитив-терминала в ПК с загрузчиком INTELhex8 файла: viewtopic.php?p=3167597#p3167597 Модифицируем под требуемый МК и работаем.
Я за структуры), сам их использую, объявляю typedef struct любой сложности, потом объявляю указатель данного типа на буфере передачи и заполняю структуру... милое дело. В пределах одного компилятора до неприличия упрощает инкапсуляцию. Но... на С на ПК я на практике делаю десериализацию используя на С структуры того же типа, только с атрибутом packed. Канает, хотя и не совсем правильно так делать.
Но стоило поручить десериализацию программисту на Дельфи... вот ему не сладко... По команде через UDP прибор выплевывает свои настройки, и потом их назад отправляю. По сути без разницы через что - LAN или UART.
Месяц как облизывался на бутлоадер.. мне его жизненно не хватало для завершения концепции. и вот сегодня типа торжество, худо-бедно, но запустил. И хотя вопросы по ходу реализации были самые идиотские, и сейчас еще остались, но написал его сам полностью, чего и Вам желаю.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 10
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения