Здравейте, реших да отворя още един пост с цел да събера колкото е възможно повече мнения и съвети във връзка с конкретен режим на едно устройство с което се занимавам. Темата е дъфчена преди време, когато правих проучване за конкретният модул, но сега му изграждам поведението и ми интересува следният въпрос: пръво модулчето е на Texas Instruments- WiFi3200 и искам да му имплементирам един контрол, който се срещаше в едни не много стари устройва - модемите. Там имаше имплементирана команда "+++", която се пращаше сериино към модемът. Нейната цел в WiFi-ят е след като се отвори сокет към дадено IP (т нар Data режим в който можеш да изпращаш всичо с изключение на "+++"), чрез нея да се преминава към Command mode - в който може да изпращаш само АТ имплементирани команди, която цел е да променят поведението и конфигурацията на модулът. Една от препоръките ми е да се направи превключване от пин (хардуерно като се клати между Vdd и GND или между 1 и 0). Та въпросът ми е за реализацията на "+++" на самият пин, с интеръпт би ли могло да стане (по ниво или фронт) или има по разумен начин за това? Предложих и мнение да се разпознава стринг "+++", но колегите ми казаха че имали проблеми ако се имплементира програмно.
Благодаря предварително за отговорите !

Това с +++ е едно от най големите извращения правени някога. Може и да е било актуално преди 30-40 години, но в днешно време си е анахронизъм. Единствената разумна причина да се ползва сега е съвместимост с разни стари модеми, за нови разработки не виждам защо трябва човек да осакатява продукта. Хайде да го кажа по друг начин - нещо в заданието не е много наред, не би трябвало да се налага да ползваш data и command режими нито да превключваш между тях с +++. Изясни го това преди да правиш магарии. За повече информация виж тук:
http://en.wikibooks.org/wiki/Serial_Pro ... onnections
Също така явно в момента ти е каша в главата и почти не може да се разбере какво точно питаш, примерно:

Ами това с пинът го срещнахме като се занимавах с един подобен модул на WIzNet. Там освен софтуерното превключване беше реализирано и такова с GPIO. То не играе никва роля докато не отвориш сокет и докато непочнеш да комуникираш с отсрешното IP. Когато това стане с този пин един вид можеш да активираш "+++" без да има нужда да му пращаш тези символи по RS-а. За да съм по ясен ще се опитам да дам прост пример: отваряш сокет и почваш да пращаш 1234.... до 10, през това време GPIO-то е в ниско ниво (~GND лог.0). В един момент дигаш нивото на GPIOІ-то в 1-ца и изпращането на цифрите спира примерно на 5. Докато това ниво е в лог.1 единственото което може да се прави е да преконфигурираш модъл са речем да вкараш още едно IP към което искаш след това да се кънектнеш (работата се управлява само с AT команди). След като върнеш нивото в 0 на GPIO-то ипращането продължава то 5 и продължава до 10. Това е най-общо което мога да кажа във връзка с твоят цитат.....

Според мен с това GPIO нещата по скоро биха се усложнили в сравнение с пращане на +++. Проблема е, че не трябва да му сменаш нивото ако в момента изпращаш/получаваш някакви данни - иначе ще стане каша защото поне една от двете страни ще обърка данни с команди. А за да контролираш предаване/приемане ще трябва да ползваш някакъв flow control. Усещаш ли как нещата започват да стават сложни? Прочети линка който ти пратих - всичко идва от това, че по серийната линия нямаш frames т.е. пакети - от там се повличат всички неприятности и усложнения. За да си решиш проблема с едновременно предаване на данни и команди по един сериен канал е по добре да вкараш някакви пакети - в противен случай трябва да ползваш или допълнителни линии или +++ - а те пък си имат своите проблеми - и за двете трябва да слагаш разни изчаквания за да не се объркат команди и данни.

Хайде изчезна ми поста
А бях написал, че в китайските RS232 WIFI ползват стринг <<< или >>> за преминаване в команден режим.
Модел Bluetooth RS232 adapter BT-232B. Ама там следят и времената между тях - не е много гот!!!
моето адапторче го направих с 10 символа "<" за някакво време и без друг символ между тях.
За CNC програми си е перфектно - няма как да се сбърка

Проблема с тези escape последователности е, че ако да ги има в данните, за да не се приемат като смяна на режима трябва да се вкара някаква пауза без комуникация. Което пък бави смяната на режим и си е проблем ако трябва да се прави често. А винаги ще се намерят някакви данни които да съдържат в себе си тези стрингове - примерно при преточване на нов фирмуер ... абе ...

Е, поне при GSM ескейп символа може да се сменя. Стенд бай таймаута и той...

Здравей, искам да се консултирам и за още нещо с теб, понеже днес темата я дробихме с част от началството.... Това което казваш го разбирам за какво става въпрос, но неразбирам следният случай, който според висшестоящите органи трябва да работи: ста авъпрос за следното, WiFi модулът би трябвало а и ще трябва да се използва в т.нар. "прозрачен режим", т.е от едната страна имаме хост първоначално комуникиращ си с WiFi-я, а от другата страна имаме сървър. Хостът си комуникира с WiFI-то до момента когато се върже през AP към сървърът и се отвори сокет за комуникация към сървърът. Идеята е от този прозрачен режим да се излиза с въпросното GPIO за което споменах. Това е едно на ръка, другото за което се даде преложение е приемането на данните от UART-а на WiFi да се реализира като "кръгов буфер", извинявам се ако терминът не е точен. Целта на това е да приеме изпратените данни от хоста, и да ги обработи докато има такива. А идеята за тази реализация да стане нещо подобно като "опашка", един указател сочещ края на опашката и втори "разхождащ" се по символите докато достигне първият. Когато това стане, значи повече комнди за обработа няма. Това като цяло беше дискусията свързана с този проблем и незнам в случаят идеята реализируема ли е или не ?

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

не знам дали ще ти е полезно, или вече си го чел.......
http://elearn.uni-sofia.bg/pluginfile.p ... -6_DLL.pdf

успех!

Добре явно нещата немога да ги обясня, което може би е мой проблем. Но едва ли подходът трябва да е да дам кодове по които да говоря, затова се опитвам да ги обясня по прост начин, което всъщност не се получава. Добре дайте съвет какъв трябва да бъде подходът втакъв случай ...... принципно имам резултати върху които съм стъпил и от тях се опитвам да вървя напред, разбира се незнам цялата прежарска терминология, нещата си ги обяснявам по-простичко(без въпросните термини). То и самият аз не съм учил за мрежи , нито пък съм карал CISCO курсове .... Прикачам една картинка която направих с цел да се разбере основната концепция, но като работа и поведение съм описал по-горе какво трябва да стане. От мен ми искат устройството да влезе в прозрачен режим и след това да мога да го вадя от този прозрачен режим, и същевременно пращайки команди по RS-а, аз да имам възможност да ги обработвам всичките, понеже за момента ако изпратя:
AT&V\n\r
командата ще ми се обработи, но ако пратя
AT&V\n\rAT+WS\n\r
втората АТ команда няма да се обработи понеже, имплементираният механизъм (който ползвам наготово) изчита командите до първият CR и трие всичко останало. Може да прикача и части от кодът ако са необходими за разбиране на идеята .....

Благодаря Wise, не не съм попадал на този документ.....

първо малко по терминологията:
при модемите има два режима на работа:
- команден (command mode) - когато модема изпълнява AT команди
- data mode (това не се сещам в момента как точно да го преведа на български) - когато модема прехвърля данни (ти му казваш на това "прозрачен" режим)

От command -> data се превключва с някаква AT команда
От data -> command се превключва с +++ изпратено към модема или пък с някакво гпио и т.н.

Разбира се, че щом всички производители на модеми (в частност гсм модеми) го поддържат значи може да се направи. Това е отговора на въпроса ти от по предния пост. Т.е. идеята е реализируема. Просто не знам дали толкова лаконичен отговор е това което търсиш

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

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

Миро, недей, че точно в момента ме карат да преправям команден режим с даннов и точно това им разправям, че е проблем ама ми се обясняват, че така сме щели да спестим незнам си колко кб рам за буфери като така и така в модема ги имало ... пълна боза ... да допълня още един проблем - като пращаш, не знаеш колко от данните са получили ACK, съответно ако продължиш да пращаш в един момент на модема буферите преливат и затваря конекцията изплювайки NO CARRIER по серийния да му се чудиш данни ли е, URC ли е ... на телит съпорта в този случай мъдро съветва - ми сложете си един филтър, и като видите този текст, излезте в комаден режим да питате дали сокета е затворен ... ми ко не е, кво правим ... тъпня ...