tgi, като звъннеш на номер с "ATD=номер" и връзката се плаща на време, а не на трафик. Иначе сега гледам, че на модула на Н'бабане Гт'муан'га може да се укаже с ат команда, че ще се ползва вътрешния или пък външен стек. Тия, дето съм ползвал аз не мога да се сетя да са имали такава команда, ама може и да се бъркам де - гледам че може да се избира между IP и PPP и друго не можах да открия.

При модулите, които използвам "ATD=номер" си е войс.
За данни се използва: ATD*99***<cid>#<cr>

This operation corresponds to the dial and connect of a CSD GSM data call issued to an internet service provider, where:
<cid> - is the index number of the desired context to be used (up to 5 different context)

Естествено, че се плаща по време.

Ок, мерси, ще ги разгледам.

да, ей ти пример:



Първата команда АТ+COPS=3,1 и давам 50 секунди да сетне формата, втората команда има 180 секунди.

Той проблемът не е в картинката... Реално през gsm мрежата може да пускаш само протоколи дето се рутират. Демек само TCP & UDP, айде и ICMP Ping да сме точни. Но тия неща си ги имаш и от вградения стек.
Ограничение наистина има в броя на отворените сокети/портове. Само заради това си струва, по-точно може да се наложи да заобиколиш вътрешния стек. Но за да ти се налага пък такова нещо, значи или правиш хептен специфично приложение, или нещо в картинката на проекта ти куца. Колкото и на теория да е хубаво да имаш безброй връзки, толкова е безсмислено на практика. Ти ако тръгнеш да отваряш 100 сокета, докато стигнеш последния, от другия край ще почнат да се самозатварят... Файда йок. Единствено на сървърно приложение може би има смисъл, не знам... ти си знаеш, но аз от такива проекти бягам като дявол от тамян



ммм спорно е малко
Ако имаше начин да прескочиш историята с АТ-командите щеше да е наистина супер. Ама не би... Верно, повечето команди са стандартни и ако не ползваш вътрешни стекове и нотификации съм съгласен, че ще стане що-годе универсално. Но повечето бъгове не са стандартни, примерно сещам се Телит като правихме, първоначално за да го включиш беше да държиш ON 1 сек. за да форснеш изключване държиш 2 сек. Изведнъж обаче излиза нов фърмуер, който като задържиш повече от 1 сек. вместо shutdown прави restart. И честито на печелившите
Та мисълта ми е, че без АТ команди няма как да минеш. Няма как си го конфигурираш, няма как да вкараш ПИН кодове и т.н Демек за да ползваш външен TCP стек ТРЯБВА да имаш читав АТ стек. Демек не пестиш кой знае колко... На всичкото отгоре 90% от gsm приложенията ползват и SMS, щото е много удобно и готино, особено ако са безплатни. Ако искаш да ползваш подобни неща обаче ти или не трябва да държиш постоянно вдигната връзка (което пък хич не се връзва с изискването за много конекции). Или трябва вместо АТД да обменяш пакетите с АТ команди (което пък противоречи на универсалността ти).

А бе ясно, ей го нали Leo даде и точната команда - а и тия дето си ги гледал щом може
IP/ppp е все тая, аз бих се почесал малко кое да ползвам и навярно бих се спрял
на ppp щото е един слой по-надолу (и де/фрагментирането ще е при мене и под
контрол, както и рутенето). Казах за АТД като едно време с модемите по инерция,
то аз мобилен модем нали не съм ползвал.

Миро, след последните ти разяснения единственото предимство, което аз мога да видя в твоя подход е универсалността на сокетите на високо ниво, освен това другото, дето го виждам са почти все недостатъци .

нали... дюс мама, дюс! Туй семплото не е за нас

Ами първо може да се спори доста кое е семплото и кое не и второ ако наистина стоиш вътре във функцията и чакаш 180 секунди модула да ти върне отговор само това в много голяма част от приложенията си е голям проблем. Отделно ти пак имаш всички ат команди и пак ги викаш по предварително фиксиран алгоритъм. Т.е. до тук не правиш нещата по-лесни, а почти същите. Там където ти идва предимството е високото ниво, където от гледна точка на ОС и приложенията гпрс връзката е същата като етернет, wi-fi и т.н. и приложението ти от високо ниво не го интерисува през къде точно минава комуникацията. Ама това може и да супер ако правиш касови апарати, пос терминали и разни други такива неща, но ако правиш тракери, аларми и други такива устройства няма никакъв смисъл, даже само ще пречи и ще раздуе кода и като можеш да минеш с малък контролер, защо ще трябва да слагаш голям, който да търкаля стековете ти от високо ниво. Та всяко нещо си има приложение и не можеш да генерализираш така, както го направи в тая тема.

Димитре, взе да се бъзикаш с мен.... как може изобщо да ти хрумне, че някой който пише ОС ще утрепе проца по такъв селски начин.
А колкото до "раздуването" на кода, дадох ти примерна функция... ако виждаш излишни неща, ОК - но ако не виждаш недей да правиш пак прибързани заключения за останалия код. Всъщност, прави си... твоя работа, аз не се засягам от такива неща

Ей така ми отговори ти, т.е. не ми остави аз да мисля какво може да направи човек, дето пише ОС-ве .

Тука ми вадиш думите от контекста и си ги тълкуваш както си искаш. Това което казах е не че в тая функция има излишни неща, а че за много апликейшъни надграждането с универсални сокети е излишно. Ама какво се чудя - ти през цялата тема вадиш думи от контекста, генерализираш си и си пишеш каквото си искаш после. Аз като говоря по принцип има предвид всички ситуации, а ти като говориш по принцип имаш предвид само твоите случаи. Обясни ми тогава къде е далаверата от твоя подход в един тракер или аларма дето модула е единствения комуникационен интерфейс и ти обещавам, че повече няма да се занимавам с теб . И да не забравяме все пак едно много важно нещо - ти беше тоя, дето почна да разправяш как подходите, различни от твоя не стрували и твоя бил единствено правия. Та не ми се прави сега на ощипана мома, като ти отвръщам със същото .

Не му е тук мястото, но последните "престрелки" между Миро и Димитър са интересни.
Миро, вярно че има ОС и нишки, но постнатия код е пример за лоша идеология, и е точно обратното на това, което прокламираше по-горе за конкретното и абстрактното. Абсолютно е неприложим за системи без ОС.
Казвам го не за да критикувам, всеки си решава как да си пише нещата, в някои случаи субективни фактори, дето нямат никаква техническа обосновка, могат да са решаващи и да доведат до качествен продукт. Ако този стил е удобен на колектива, супер, има си шедулъри за всеки процесор, няма проблем.
Но в конкретния случай (а и генерално за стейт машините) аз предпочитам и защитавам категорично идеята за event базирано програмиране, където всеки event е извикване на функция.

Аз бих го написал по друг начин.

Има примерно един "ATCMD_Server" - модул, който получава всички заявки от клиентите в системата. Той има грижата командите да се припокриват, да буферира заявки и всичко от това ниво.
Този модул експортира една примерна функция:



ST_ATCMD_OPNAMEREQ съдържа параметрите на заявката и полета за връщане на отговора:
- NameBuf - функцията ще попълни тук името (при успех)
- NameBufferSize - размер на буфера отгоре
- timeout
- pfOnReadyCallback - фунkционален пойнтър за уведомяване при приключване на работата (ОК или NotOK)
- pfOnReadyCallbackContext - контекст на викащия
- ResultCode - ОК, Error, XXX
- ActualNameSize - попълнено с реалната дължина на нещото в NameBuf
- pfOnResultProcessReadyCallback - известяване за приключване на обработката на отговора
- pfOnResultProcessReadyCallbackContext - контекст на ATCMD_Server (по-точно на една сесия на ATCMD_Server)
- ... и тъй нататък според вида на заявката
(Елементите на структурата могат да са отделни аргументи на функцията, но за мен вариантът със структура е по-добър)

Клиентът - например TCPIPStack, вика GetOperatorNameRequest() с попълнена заявка. Функцията е асинхронна, не блокира. Върната стойност (RESULT) от викането и показва дали заявката е приета или не (а не как е изпълнена). В смисъл при невалидна заявка (примерно NULL == pstReq), или друга проверка на входен параметър, RESULT e ERR и всичко свършва дотам, иначе е OK и значи "заявката приета, започва изпълнение, чакай известяване по дадения callback".
За сървъра е задължително да повика клиентския callback-а (ако е върнал ОК като RESULT на заявката).

TCPIPStack е подал една своя функция за callback, например:



Когато ATCMD_Server приключи обработката (а това е или при идване на прекъсване от UART-a, или при callback от TimeoutServer) той вика callback-а (TCPIPStack_Startup_OnGetOperatorNameCallback() ). В него стека подготвя следващата стъпка от работата си, примерно следващата AT команда.

Възможно е (и всъщност е най-изчистено) да има още един обратен callback - от callback-а обратно към АТ модула, който означава че е приключила работата с данните в отговора и може да се "почисти", например АТ модула да деалоцира междинни буфери. В края на TCPIPStack_Startup_OnGetOperatorNameCallback() (или по-късно, веригата може да се разпростира на много нива) се вика нещо като ATCMD_Server_OnResponseProcessingReady(). В него ATCMD_Server извършва почистването на ресурсите. Ако го няма втория callback, то ATCMD_Server няма друг избор освен да изчиства при return от callback-a ( TCPIPStack_Startup_OnGetOperatorNameCallback() ). Само че ако TCPIPStack ще трябва да копира името на оператора, ако иска да свърши нещо с него, като например да повика LogServer. Ако има втория callback, то ATCMD_Server ще бъде уведомен чак когато LogServer върне обратно callback за успешен запис в лог-а. Така няма нужда от междинни копирания - точно това е хитрото.
Това не значи че копирането е забранено, ако прецени TCPIPStack може да копира и да върне не ATCMD_Server да изчиства преди завършването на работата на LogServer.

Естествено е че в една по-голяма система ще има нужда от смяна на контекста на тасковете, което не пречи на идеята. Елементарно е във функцията си за callback TCPIPStack да сложи постване в мейлбокс, сетване на семафор или RPC call. Не е казано че извикването на callback-а трябва да стане директно, без смяна на контекст. Но тази смяна се прави само там, където има нужда. В другите случаи се правят безсмислени превключвания.

Идеята е приложима за платформи СЪС и БЕЗ операционна система. Дори да имаш един superloop с прекъсвания, можеш да впишеш същия код - защото е неблокиращ. Показаният от теб код по натура е блокиращ, което автоматично ограничава използването му.

От практически опит съм виждал че overhead-а от callback-ите е по-малък от някои други механизми. Иска си стек, но няма излишни действия - всичко се случва само когато е нужно да се случи, и нещата (ресурсите) живеят само когато има нужда от тях (например буфера за името по-горе, или пък един IP фрейм, или USB пакет). Организирането на паралелни сесии е лесно и рискът от грешки не е висок.

Колеги, петък е.... ден на майстора! И тъй като сме събрали само майстори да кажа един виц по темата:

Майстор водопроводчик си взема чирак да го обучава. Отиват на авария... запушен канал, шахтата пълна догоре с лайна. Майсторът влиза вътре, обаче не стига и иска шнорхел от чирака. Потапя се, след малко се подава и иска един ключ. Чиракът му го дава. Майсторът пак се потапя и след малко иска втори ключ. Накрая, каналът се отпушва, нивото пада и майсторът казва на чирака:
- Учи се как се правят нещата, че да не подаваш цял живот инструменти...

Та сега по темата с лайната... Още в началото обясних, че стек е термин в софтуера за нещо структурирано на нива.
Обеснявам:
В примера който дадох, се ползват функции за изпълнение на една АТ команда. Тези функции са на ниво транзакция. А показаната функция дето взема името на оператора е по-горно ниво. Над него има друго ниво за ос нещата, а най-отгоре са приложенията.
Къде е ключа за бараката? Ми няма мешане, в транзакшън нивото не се интересуваме какви АТ команди се пращат. В горното ниво пък не се интересуваме как се пращат. Както казах ако има нотификации или други глупости, те се вадят от транзакшъна. Демек не се интересувам как стават нещата по-долу, не се интересуваме и за по-горното, т.е. не ни пука защо и дали някой ще иска името на оператора.
Това е СТЕК!!!

Защо се прави стек?
Много причини, но една от тях е ДА НЯМА РАЗДУВАНЕ НА КОДА. Проблемите на транзакшъна се обработват САМО НА ЕДНО място. Функцията за името прави само това - взема името, а не мисли за нотификации, състояния или други глупости. НИТО една част от стека не прави същото нещо като друга част. НЯМА дублиране. НЯМА излишни части, има функции които може да не се използват, но те ще се разкарат от линкера или конфигурирането. Въпросът е, че каквото се прави без стек се прави и със стек. Разликата е КАК се прави, а не КАКВО. Примерно, ако транзакшъна не се грижеше да изчисти всички проблеми покрай транзакцията, то тия проблеми ще се разнесат на хиляда места. Ще се получи БОЗА.

@ Димитре, когато пишеш дадено ниво в един стек, НИКОГА не ползваш функции от по-високо ниво, камо ли да мислиш какво е приложението...
Иначе, както много пъти вече казах, че ако правиш един единствен продукт критериите какво ще ползваш са различни. Но ако ще правиш много продукти е важно да имаш някаква сходимост. Няма значение дали касови апарати или тракери. Даже няма чак такова значение дали ще е стек или проста библиотека. Но винаги е добре да ползваш малко на брой инструменти, освен ако не искаш да се потапяш по-често в лайната... Пример - след като всичките ти продукти имат gsm, защо да нямат remote firmware upgrade. Нима има някакво значение какво прави фърмуера? Нима при всеки нов продукт ще почваш всичко от нула? Или ще поддържаш 100 версии на едно и също нещо.... не знам, не го разбирам това аз

@ Гичо, то стана късно пък и от толкова кратко описание едва ли ще мога да направя сериозни заключения. Само принципно:

1) Вариантите без ОС абсолютно не ме вълнуват. И да нямах собствен, щях да ползвам чужд. По-скоро ще се застрелям, отколкото да направя нещо без ос. Фанатик съм на тая тема и не се пробвай да ме убеждаваш

2) няма значение дали ще е евент, стейт машина или нишково. Важното е да си го капсулираш по нива правилно. Аз в момента няма как да преценя направил ли си го или не...

3) дано да греша, ама сякаш следваш логиката "защо да е просто като може да е сложно" Какви са тия калбаци, какви са тия структури.... че ти докато ги попълнеш връзката ще дропне бе

И кой е казал, че продуктите са ми нямали фърмуер ъпдейт през гсм-а и как пък стигна до извода, че винаги съм почвал нещата от нула и са имали 100 версии? Ти четеш ли въобще какво си пишем тука или просто си приказваш ей така и слушаш/четеш само себе си ?


А ей това горното (за което имах подозрения през цялото време) просто изчерпва тотално и смисъла и качеството и нивото и още каквото се сетиш на цялата дискусия, т.е. аз лично не виждам абсолютно никакъв смисъл повече да дискутираме каквото и да било с теб на тая тема .

миро, това буквално избива рибата
добро упражнение ще е да хванеш някое контролерче с 1-2к памет (постоянна, не рам!!! рама ти е обикновено няколко десетки байта) и да се опиташ да направиш нещо с ос на тая основа
ей, да не си помислиш че те подтиквам към самоубийство