Отговори на тема  [ 28 мнения ]  Отиди на страница Предишна  1, 2
Branch mode search string 
Автор Съобщение
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: Branch mode search string
я пасни 2, 3 линии команди...

_________________
main[-1u]={1};


Нед Окт 06, 2019 2:31 pm
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Branch mode search string
Това с ат командите що не го каза в началото... Както и да е - тука загатваш че ще има в бъдеще други - имаш предвид други модули, нови команди на есп-то и т.н.?
Мисля си че първо трябва да изградиш по-стройна стратегия как ще интегрираш твоя код (приложението) и разните външни модули - в случая esp-то. Самият протокол за него е достатъчно чоплен и най-просто ще е да огледаш някоя готова имплементация на такова нещо - библиотека дето предоставя достъп до есп с ат фирмуер. Такива има на много места - mbed, arduino че и доста други. Виж на github или просто гугълни. Като разгледаш някоя от тия библиотеки ще видиш какъв интерфейс са отворили като функции и (надяваме се) събития наобратно. Това ще ти подскаже доста за структурата.
Внимавай с посока "универсален парсер" - нЕма такова нещо и оптималния подход зависи както от граматиката (и кое кога излиза като "думички", тоест кой кога говори на тоя "език") така и от начина по който е мислен да се ползва.
Тия парсер генератори са прекалено сложни, но са правени точно с тая идея - да приложат някакъв pattern (или различни) и да ти изкарат удобен като api интерфейс за определена граматика. Само че едва ли ще са приложими при теб (освен ако си на микропитон примерно).
Когато аз правя такива неща използвам малко непопулярен начин на дизайн - api-то на този твой парсер да го наречен няма да има общо (няма да е направен по задание) от приложението. Т.е. за да направя тая библиотека ще искам само спецификация на esp at firmware, и не искам да знам как някой си мисли да ги ползва. Т.е. ако трябва да го дам като задание на някой програмист ще му сипя само спецификациите на есп частта.
Ама това е по-дълбока тема по отношение на дизайн на софтуера и не е за тук.


Нед Окт 06, 2019 6:22 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: Branch mode search string
добър мастър "парсер" за АТ команди ( стрингове разделени със запетая ), отваряш ГИТ и дириш at_tok от андроид РИЛ
като: https://github.com/Komodo-OS-Rom/hardwa ... l/at_tok.c

сложното на АТ са URC обработката... че идват когато не ги чакаш и си иска "мулти-таск"

_________________
main[-1u]={1};


Нед Окт 06, 2019 8:06 pm
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Яну 01, 2012 7:04 pm
Мнения: 2581
Местоположение: Велико Търново / София
Мнение Re: Branch mode search string
TheWizard написа:
я пасни 2, 3 линии команди...

примерно
0,CONNECT\r\n
1,CLOSED\r\n
+IPD,0,450:GET / HTTP1.1\r\n
.... // идващи данни от браузъра

SEND OK\r\n
OK\r\n

TheWizard написа:
сложното на АТ са URC обработката... че идват когато не ги чакаш и си иска "мулти-таск"

URC не зная какво е.
Сега данните си се пълнят на прекъсване във кръгов буфер.

Ако се прочитат по-бързо командите ще може буфера да е по-малък и скоростта на UART-a може да се увеличи.
Самото парсване го изпразва.
Дървовидната структура със switch-ове ще го парсва еднакво бързо според дължината на командата. Въпроса е, че ще падне голямо писане в MPLAB и ще стане страшна какаманга а и кода ще е неразбираем. Все ми се щеше някаква програма да състави карта/таблица на дървото и съответно да я заредя в кода, където някакъв алгоритъм ще я чете. Но май ще трябва да поработя над точно това което съм замислил.

Това с хеша не зная как ще се представи. Смятането ще отнема време, но пък няма да има излишни данни за таблицата.

_________________
https://github.com/slav4ocom/


Нед Окт 06, 2019 9:13 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: Branch mode search string
slav4o.com написа:
...
Процесора ми е 8 битов PIC на 32 MHz т.е. честота на инструкции 8 MHz . 8 000 000 / 115 200 = 69,4 инструкции време.

Дай първо малко да оправим сметките - 115200 е битове, не байтове, а ти приемаш байтове т.е. при максимално уплътняване на трафика ще имаш 10 бита за предаден байт (старт бит, 8 бита данни, стоп бит) затова смело умножаваш по 10 и получаваш 690 инструкции т.е. имаш достатъчно процесорно време за какво ли не. Спокойно можеш да използваш, че командите имат някаква структура (или граматика ако ще го правиш с парсер) което позволява да се правят всякакви врътки. Но все пак имай в предвид, че каквото и да правиш за да решиш този проблем на практика ще местиш натоварването между четирите ресурса с които разполагаш - процесроно време, рам, флаш за код и данни, твоето време да си играеш с проблема - според това което ти е скъпо/евтино трябва да избереш с кое ще направиш компромис - но няма начин да стане безплатно ако оптимизираш за едно от тях ще е за сметка на останалите.

Това което ти се предложи за няколко вложени switch-а за всяки символ от командите е всъщност дървовидна структура направена с цената на много код - можеш да я направиш и с малко код но пък с много данни ако опишеш командите които очакваш в някаква дървовидна структура от данни примерно масив с указатели за цялата азбука към друг подобен масив за следваща буква и т.н. Всички тези варианти ще ти струват и много от твоето време и ако си сметнеш колко време ще се спести при работа после на системата ще установиш, че е с порядъци по малко отколкото твоето време да оптимизираш.

Това което може би също изпускаш е, че всички оптимизирани решения са и доста сложни което първо ще отнеме доста повече време при първоначалната разработак но по лошото - ще струва още повече време ако след година две се опиташ да промениш или оправиш нещо - колкото е по сложен кода толкова по трудно се поддържа. Т.е. хубаво е винаги да се опитваш да пишеш максимално прост и лесен за четене код който да не се нуждае от допълнителни обяснения как и защо работи. Оптимизации се правят когато някой от горните ресурси е ограничен и има бюджет от останалите за да можеш да компенсираш с тях. А от тях може би най важният ресурс е твоето лично време. Затова KISS - keep it simple, stupid ...

Edit: Писането на прост и четим код никак не е лесна работа ... като го четеш си мислиш, еми да - така трябва да се прави - но докато го правиш винаги се изкушаваш да "оптимизираш" т.е. да усложниш - и някои хора просто не могат да се спрат и накрая става една ...

_________________
Мразя да мразя ...


Нед Окт 06, 2019 9:45 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: Branch mode search string
Unsolicited Result Code ... изпраща ги slave device когато му "скимне"
ти с тоя ПИК какво си master или slave

_________________
main[-1u]={1};


Пон Окт 07, 2019 7:51 am
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Branch mode search string
Да, URC-тата са ония "събития/евент-и" за които споменах да внимаващ. Ако отношенията са стриктно мастър-слейв/клиент-сървър нещата са по-лесни. Но това на практика никога не е валидно (освен ако някой умник по средата не е направил блокаж и това да ти е оправданието - например модбъс).
Като се наложи да реагираш на събития от типа установяване/прекъсване на конекция, получаване на конфигурация, ... става по-дебело.
Моят подход е да водя тотално разделени receive и transmit страната. Т.е. приемането по нищо не зависи от предаването. Върви си на своето събитие/тред/колбек за данни и си ги обработва, генерирайки от своя страна събития. Т.е. на входа му влизат данни (приетите символи) в смисъл на поинтър и размер (10 байта на един кой си адрес) и се очаква парсера (функцията) да ги вземе, обработи според стейта си и да извади (или не, може да се междинна част, протоколен хедър, ...) събитие "OnResetMCU()" примерно щото последния байт е бил ентъра след текста "mcu_reset".
Сигурно си е ясно това де, но да спомена че всеки опит да се мисли какво се предава, или какъв би бил отговорът, няма място при писането на парсера на приеманите команди. Да, може да си сигурен че след "reset_mcu\r" трябва да отговориш с "OK\r", но тая част отговора не влиза по никакъв начин в приемащия ти парсер. В логиката на приложението ще има имплементация на нещо което приема reset събитието, т.е. MyOnResetMCU() и там, в тоя слой, т.е. в приложението (а не в парсер библиотеката/ C файла) ако решиш ще сложиш викане на функция от друга библиотека, или част на твоята, която ще сериализира отговора - примерно "PositiveAckResp()". Приложението ти ще знае събитието (абстрактно) и ще прилага логиката да вика Ack в края. Какво се крие отзад трябва да не е интересно за него.
За "упражнение" като си ги дизайнвам тия неща слагам следните допълнителни изисквания към библиотеката:
- заявките/URC-тата трябва да могат да идват по различен интерфейс от този, на който се отговаря - примерно приемането от ЕСП влиза на RX-пина на UART1, а предаването към ЕСП е от UART2
- протоколите в двете посоки трябва да могат се сменят/комбинират произволно - може да примем по сериен, а да трябва да връщам по TCP сокет; или да приемам на 115200 а да отговарям на 19200
- трябва да мога лесно да добавя "копие" на стрийма/данните към 2-ри/N-ти дестинейшън - примерно да мога да лог-вам всичко което предавам като отговори към друг уарт, или дебъг канал, или сокет - при това без да ми се налага да копирам или да правя специални парсери, в които да има вградена опцията за логване (т.е. оригиналния код на парсер/сериализатор библиотеката дето не е логвал не се пипа, не се слагат ifdef DEBUG и подобни)
- тестването трябва да не изисква mock на специфичен вид транспорт - в смисъл че за да си направя тест на парсера (за които имам вече кода, да кажем фиксиран и с изричната забрана да слагам "тестов", логващ и т.н. код и да прекомпилирам) трябва да ми е достатъчно да опиша последователност от "пакети" или фрагменти от данни - примерно:
Код:
t1={'r','e'}
t2={'s','e','t','\r'}

и това да мога да го подам на парсера на две повиквания:
Код:
res = Parser_OnData(&t1, sizeof(t1));
res = Parser_OnData(&t2, sizeof(t2));

Т.е. библиотеката трябва да има като апи функция, която е тотално независима от транспорта (както Parser_OnData()), а не да е нещо от типа на OnReceiveData(MY_TRANSPORT_HANDLE* h, ...). С други думи в оня тест отгоре не допускам да ми натикват хедъри от други слоеве, например "Transport.h", което бил нечий супер универсален абстрактен транспорт с имплементации за всичко като уарт, спи, и2ц, тцп, кан, ... Тия работи с транспорт си остават извън парсера.


Пон Окт 07, 2019 10:22 am
Профил
Ранг: Минаващ
Ранг: Минаващ

Регистриран на: Пон Апр 07, 2014 10:16 pm
Мнения: 13
Мнение Re: Branch mode search string
Леле..много писано...виж първото мнение...


Пон Окт 07, 2019 12:48 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Вто Дек 14, 2004 12:31 pm
Мнения: 3282
Мнение Re: Branch mode search string
Ако трябва да е мноого бързо си правиш собствен goto encoder - хeш функция с хешове биващи адреси в IRAM-a. Ама това малко овъркил :)


Пон Окт 07, 2019 6:01 pm
Профил WWW
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Яну 01, 2012 7:04 pm
Мнения: 2581
Местоположение: Велико Търново / София
Мнение Re: Branch mode search string
palavrov написа:
Дай първо малко да оправим сметките - 115200 е битове, не байтове, а ти приемаш байтове т.е. при максимално уплътняване на трафика ще имаш 10 бита за предаден байт (старт бит, 8 бита данни, стоп бит) затова смело умножаваш по 10 и получаваш 690 инструкции т.е. имаш достатъчно процесорно време за какво ли не.

А да това го забравих. Да влучая го приемам през UART модула и си прав.
palavrov написа:
KISS - keep it simple, stupid
Търсих я песента, ама я няма в ютубата...

@gicho ами да всъщност мога да го направя да предаването и по друг канал да е. Ако използвам В случая няма смисъл.
Отношенята са модем ESP web server PIC .
Реално си има нещо като стейт машина според това какво пращам като команди и данни към ЕSP си зависи от това какво е дошло като команди преди това от там. Библотека не съм писъл.

Просто с две думи цялата ми идея беше вместо да проверявам всеки символ за всяка команда, да го проверявам от кои/коя команда може да е. Така например ако командата започва с буквата А да не я проверявам за всяка команда, а да се насоча в кои команди я има примерно команда 1,2,5,8,12,13,15,20. После ако втората буква е В то AB има само в команди 1,5,15. И ако третата буква е C то остава само команда номер 5. Т.е. постепенно отсяване а не пълен разбор на командите.
Така както ми е системата сега ако имам за валидни командите { AB0 AB1 AB2 AB3 AB4 AB5 AB6 AB7 АB8 AB9 ABA ABB ABC ABD } Ако дойде ABC трябва да направя почти пълен разбор на 12 команди по 2 символа докато установя че те всъщност не съвпадат със ABC . Грубо казано около 24 стъпки. А така със дървовидното отсяване на 3тата стъпка ще стигна до определяне на точната команда.

HCL написа:
Ако трябва да е мноого бързо си правиш собствен goto encoder - хeш функция с хешове биващи адреси в IRAM-a. Ама това малко овъркил :)

Мисля да напиша някаква програмка да ми смята дървовидната структура.

_________________
https://github.com/slav4ocom/


Пон Окт 07, 2019 8:01 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: Branch mode search string
+команда-1,пар-1,пар2, ......\n ти е линията, има начало има и край
първата дума е +команда-1
HASH на ("+команда-1") = 12345678

намери HASH от масива[] със всички { hash_1, handler_1 }, { hash_2, handler_2 }, ..... { hash_N, handler_N },
ако намриш HASH-а - call handler

пример Mediatek GSM-и стек

#define BASIC_CMD(AT_NAME, AT_HASH, FUNC, ENUM)
#define EXTEND_CMD(AT_NAME, HASH1, HASH2, TEST_STRING, ENUM, FUNC)

команда ATI инфо
BASIC_CMD("i", 9, rmmi_ati_hdlr, RMMI_CMD_ATI)

команда AT+CGSN имеи
EXTEND_CMD("cgsn", 175460, 0, "", RMMI_CMD_ATCGSN, rmmi_cgsn_hdlr)

_________________
main[-1u]={1};


Пон Окт 07, 2019 8:15 pm
Профил ICQ
Ранг: Новодошъл
Ранг: Новодошъл
Аватар

Регистриран на: Съб Фев 06, 2016 7:29 pm
Мнения: 167
Мнение Re: Branch mode search string
off-topic
slav4o.com написа:
palavrov написа:
KISS - keep it simple, stupid

Търсих я песента, ама я няма в ютубата...

Това беше добро! :twisted:


Пон Окт 07, 2019 8:36 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: Branch mode search string
Ами не си търсил както трябва - те ти ... https://www.youtube.com/watch?v=SgH0RAJ ... P1uEFVb3xz

_________________
Мразя да мразя ...


Пон Окт 07, 2019 9:36 pm
Профил
Покажи мненията от миналия:  Сортирай по  
Отговори на тема   [ 28 мнения ]  Отиди на страница Предишна  1, 2

Кой е на линия

Потребители разглеждащи този форум: 0 регистрирани и 2 госта


Вие не можете да пускате нови теми
Вие не можете да отговаряте на теми
Вие не можете да променяте собственото си мнение
Вие не можете да изтривате собствените си мнения
Вие не можете да прикачвате файл

Търсене:
Иди на:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.
Хостинг и Домейни