AM
ННннада?
Size: a a a
2021 July 21
E
ED
Тогда я вообще не вижу смысла в протоколе. Не стоит делать сложно то, что можно сделать просто. :)
ED
Передавайте структуру, и все.
E
посмотрю спасибо
E
и просто разбирать структуру в соответствии с тем, как заложил?
и не выдумывать трамвай?
и не выдумывать трамвай?
ED
typedef struct {
uint8_t param1;
uint16_t param2;
...
} my_struct_t;
...
my_struct_t params;
...
RF_send((uint8_t *)(¶ms),sizeof(params));ED
Да. Зачем в описанном случае еще какие-то заголовки?
A
E
думал для простоты
но на самом деле, когда у меня количество параметров ограничено и я точно знаю, что это будут за параметры проще всего использовать структуру и не выдумывать. Хотел упростить, но структура пакета известная и так упрощает работу
но на самом деле, когда у меня количество параметров ограничено и я точно знаю, что это будут за параметры проще всего использовать структуру и не выдумывать. Хотел упростить, но структура пакета известная и так упрощает работу
ED
Ну и на приемной стороне
if (RF_Receive(&data) != 0)
{
x = ((my_struct_t *)(&data))->param1;
...
}ED
Именно. :)
ED
Протокол нужен тогда, когда хочется, например, отчеты о приеме, или автоматическую повторную передачу, или временнОе разделение каналов.
ED
Всякие алгоритмы доступа к среде и прочее.
E
это из коробки есть, плюс автоподтверждение, что посылка доставлена
ED
Ну так собственно значит протокол у вас уже есть. :)
ED
Кладите в него данные и не заморачивайтесь.
аᶘ
(или чтобы не писать заново с нуля каждый раз сниффер и все остальные тулзы для формирования и разбора пакетов)
E
да я думал просто, как лучше данные в payload засунуть и потом забрать, и самый простой способ зачем-то выкинул