psyhologic 0 9 февраля, 2019 Опубликовано 9 февраля, 2019 (изменено) · Жалоба С MBED у меня опыта не много, а вот с ООП высокоуровневых языках предостаточно. Позвольте вставить свои 5 копеек. SerialPort - инкапсулирует всю логику работы с портом, скрывая все потрошка работы с железом. Дальше дробить скорее вредно. AlexandrY подсказал про возможные проблемы. CycleBuffer - класс / структура представляющая результаты чтения / записи. Можно вдохновиться здесь - http://nginx.org/en/docs/dev/development_guide.html#buffer ProtocolParser - работает с SerialPort / CycleBuffer, реализует разбор и копирование данных на специализированные Packets. Прячет всю работу с SerialPort от остального приложения. Packet и наследники Packet - фрейм вашего протокола разложенный на структуры / классы. MyProtocol - логика разбора и обработки пакетов протокола. Содержит instance ProtocolParser. Может быть построен по разным шаблонам проектирования. P.S. ViKo вы забыли упомянуть какую событийную модель использует ваше приложение. Request - Response / Publisher - Subscriber / etc. Изменено 9 февраля, 2019 пользователем psyhologic Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 10 февраля, 2019 Опубликовано 10 февраля, 2019 · Жалоба Я описывал. Запрос от компа (команда) - ответ от прибора. По крайней мере, так представляю сейчас. Внутри прибора тоже что-то типа конечного автомата. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 10 февраля, 2019 Опубликовано 10 февраля, 2019 · Жалоба 6 hours ago, ViKo said: Я описывал. Запрос от компа (команда) - ответ от прибора. По крайней мере, так представляю сейчас. Если со стороны PC, то Вам не обязательно использовать кольцевой буфер и объект-класс порта. Системные ф-ии API ReadFile() ReadFileEx() изначально работают "блочно", и их "байтовое" использование как-бы сомнительно. Это старый "баян" на форуме. // выдать в компорт запрос PC --> device // RET кол-во реально переданных байт int CorrPC_Req::CorrPC_SendReq( void ) { memset(RxPacketArr, 0x00, sizeof(RxPacketArr) ); // подготовка для чтения Rsp WriteFile(SerialPort, TxPacketArr, PacketTxSize, &real_write, NULL); return real_write; } int CorrPC_Req::CorrPC_GetResp( void ) { real_read = 0; ReadFile(SerialPort, RxPacketArr, 50, &real_read, NULL); return real_read; } // проверка принятого пакета // RET - наличие ошибок. // (+1) - ошибок нет. (+2) - длина больше требуемой // (0) - ничего не принято // (-1)ошибки длины, (-2)шаблона, (-3)контр. суммы int CorrPC_Req::CorrPC_TestResp( void ) { // -- 0 -- if( real_read == 0 ) return( 0 ); // ничего не принято // -- 1 -- if( real_read < PacketRxSize ) return(-1); // длина пакета недостаточна // -- 2 -- for(int i=0; i<pktTemplateLen; i++) { int testIndex = pktTemplate[i][0]; if( RxPacketArr[testIndex] != pktTemplate[i][1] ) return(-2); // не соответствует шаблону } // -- 3 -- int i_crc16 = fast_crc16( 0xFFFF, RxPacketArr, PacketRxSize); // (всего пакета, включая CRC) if( i_crc16 != 0x00 ) return(-3); if( real_read == PacketRxSize ) return(1); else return(2); // некритичная ошибка - принято больше байт, чем размер пакета, но пакет корректен } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 10 февраля, 2019 Опубликовано 10 февраля, 2019 · Жалоба Речь идет, естественно, о программе в микроконтроллере. И не о том, какие функции и буферы использовать, а какие создавать классы, и создавать ли. По словам некоторых опытных специалистов они в данном случае не нужны. Ок. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 11 февраля, 2019 Опубликовано 11 февраля, 2019 · Жалоба 14 часов назад, ViKo сказал: По словам некоторых опытных специалистов они в данном случае не нужны. Ок. Почему-то я с самого начала топика не сомневался в таком выводе :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 24 11 февраля, 2019 Опубликовано 11 февраля, 2019 · Жалоба 14 hours ago, ViKo said: а какие создавать классы, и создавать ли. Если вся эта затея только лишь ради наличия слова class в коде, то безусловно это ни к чему зы. Потребность в слове class в коде возникает, когда возможностей struct уже не хватает. Если не хватает class, то на помощь придет template. Если же и этого мало, то пришло время слезать из морально устаревшего C++03 на что-то посвежее. Нынче подавляющее число стороннего кода требует компилятора от C++11 и выше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 11 февраля, 2019 Опубликовано 11 февраля, 2019 · Жалоба 1 час назад, AHTOXA сказал: Почему-то я с самого начала топика не сомневался в таком выводе :) Я знаю, вы в C++ собаку съели, и обратно деградировать не видите смысла. Я же, действительно, не понимаю, что мне дадут классы. С целью ограничить видимость переменных должны справляться namespace. А битами порта, к примеру, я и без шаблонов манипулирую легко. 56 минут назад, Forger сказал: Если же и этого мало, то пришло время слезать из морально устаревшего C++03 на что-то посвежее. Нынче подавляющее число стороннего кода требует компилятора от C++11 и выше. Вот на C++11 и лезу. Воспользуюсь мелкими интересными свойствами. Но без ООП. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 11 февраля, 2019 Опубликовано 11 февраля, 2019 · Жалоба 47 minutes ago, ViKo said: Я же, действительно, не понимаю, что мне дадут классы. Классы, конечно, всего лишь синтаксис. Чтобы разрабатывать аппаратный слой надо видеть его место в стеке. Сам по себе слой UART порта не интересен. Вот когда он одинаково легко встраивается в сетевой стек под PPP или в коммуникационный по MODBUS или в Bluetooth под HCI, вот тогда он приобретает ценность и силу. Но если порт используется на примитивном уровне, стеков нет, о RTOS только понаслышке, то тогда да, классы C++ и только они. Кстати сейчас в тренде ThreadX, так вот там никакого C++, просто жестко забанен. Зато самая быстрая RTOS на рынке и сертифицирована под SIL4! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
agregat 0 11 февраля, 2019 Опубликовано 11 февраля, 2019 · Жалоба 1 hour ago, ViKo said: Вот на C++11 и лезу. Воспользуюсь мелкими интересными свойствами. Но без ООП. Да правильно Вы все понимаете. Нет никакого смысла разворачивать классы ради двух объектов. Тем более на микроконтроллере. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 24 11 февраля, 2019 Опубликовано 11 февраля, 2019 · Жалоба 2 hours ago, ViKo said: Вот на C++11 и лезу. Воспользуюсь мелкими интересными свойствами. Но без ООП. А смысл использовать плюсы без ООП? Все равно, что на С писать объекто-подобный код, используя структуры. 49 minutes ago, agregat said: Тем более на микроконтроллере. Вот только не надо опять раздувать старый холивар ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 11 февраля, 2019 Опубликовано 11 февраля, 2019 · Жалоба 11 minutes ago, Forger said: Вот только не надо опять раздувать старый холивар ;) Эт не холивар, а честная конкуренция. Меряться тут никто не запрещал. И мы по прежнему ждет демонстрацию ваших скилов в виде той эпической библиотеки на С++ способной конкурировать с чем-нибудь скромненьким типа Renesas SSP. Докажите что с помощью C++ вы хоть на грамм эффективнее работаете чем "обычный" программист железа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 24 11 февраля, 2019 Опубликовано 11 февраля, 2019 · Жалоба 8 minutes ago, AlexandrY said: И мы по прежнему ждет Доказывать что-то этим МЫ я ничего не планирую, ибо под этим МЫ находится всего одна персона, которая мне ничего полезного дать уже не может. Я в этом неоднократно убедился. У меня и этого МЫ разные пути подхода к одним и тем же задачам. Менять точку зрения этой персоны у меня желания нет. Поэтому предлагаю на этом закончить. 8 minutes ago, AlexandrY said: Докажите что с помощью C++ вы хоть на грамм эффективнее работаете чем "обычный" программист железа. Вам я ничего доказывать не собираюсь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 11 февраля, 2019 Опубликовано 11 февраля, 2019 · Жалоба 5 minutes ago, Forger said: Вам я ничего доказывать не собираюсь. Ну так не надо тогда пенять на холивар. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nixon 4 11 февраля, 2019 Опубликовано 11 февраля, 2019 · Жалоба А я приведу. Несколько абстрактный пример, но sapienti sat struct FOO { int A; int B; }; struct BAR { const FOO* foo; const int sum; }; constexpr int sum (const FOO foo) { return foo.A + foo.B; } constexpr FOO foo1 {1,2}; constexpr FOO foo2 {2,4}; const BAR bar1 {&foo1, sum(foo1)}; const BAR bar2 {&foo2, sum(foo2)}; void main ( void ) { int X = bar1.sum + bar2.sum; while(1); } Чтоб было понятнее - скриншотик Или вы будет утверждать что никогда не возникало потребности выполнить кучу действий на этапе компиляции? P.S. Я кстати современный С++ и рассматриваю только в плане улучшения "препроцессинга". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 24 11 февраля, 2019 Опубликовано 11 февраля, 2019 · Жалоба 8 minutes ago, AlexandrY said: Ну так не надо тогда пенять на холивар. У вас, как я понял, панический страх перед наличием C++ кода с ООП внутри микроконтроллера. Этот страх - ваша проблема. Эта Ваша "проблема" не имеет отношения к этой теме. Но вы правы - не буду мешать раздувать меха в старом махровый баяне в стиле "плюсы внутри МК" :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться