Здравейте, бих искал да попитам дали някой се е занимавал конвертиране на информация от TCP в UART и обратно? Преди няколко дни бях отворил пост който засягаше т.нар. "прозрачен режим" на един WiFi модул на Тексас - СС3200. Този режим в англииските сайтове е по известен като Bridge или Transparent mode. Като в този режим устройството все едно е посредник между двете крайни точки. Конфигурацията е следната:
HOST -> CC3200 ---- wifi network----> AP->SERVER
като HOST комуникира с СС3200 чрез RS232(UART), връзката между СС3200 и АР(Access Point) е безжична, а тази между АР и SERVER е посредством ЛАН кабел. Целта е след като чрез СС3200 отворя TCP сокет към SERVER, да мога да предавам данни от HOST към SERVER и обратно.
Някой може ли да даде чисто практически съвет (идея или код) как може да се добута тази таргет? За момента имам Ring буфер (в СС3200), който ми се пълни от HOST посредством интеръпт на UART-а на CC3200 (при всеки получен символ). Освен това използвам и FreeRTOS, в която ми върви един единствен таск, в който се опитвам да имплементирам този т.нар. Bridge или Transparent mode. Благодаря предварително на всички отзовали се !

Ето тази библиотека ти трябва:

http://www.libstock.com/projects/view/356/network-wifi-library

Здравей, за бързият отговор! Искам дамо да те попитам още нещо - .mpkg библотеката мога ли да я заредя на uVision или CCS, или трябва да инсталирам компилаторът на mikroC за да мога да я заредя?

НЕ, не можеш да я заредиш, тя е компилирана. Трябва да инсталираш microC и Package Manager.
Ако имаш някакви трудности питай. За кой процесор иде реч?

Горе-долу стандартен вариант е да ползваш RFC2217:
http://en.wikipedia.org/wiki/COM_port_redirector
Там са мислени неща като конфигуриране и тем подобни. За повечето ОС-ове има реализация на виртуален COM който да "мап"-не твоето устройство.
Протоколът не е тежък и е добра алтернатива за такива приложения.

Здравей,
качих двете програмки и отворих библиотеката. Не съм я разучил изцяло, снощи само хвърлих един бегъл поглед какви функции има вътре. Колкото до процесорът, е на ARM - CORTEX M4. Като тук е моментът да спомена че този процесор, заедно с WiFi модулът са поместени в един чип - СС3200. Ето и линк за това което говоря, става въпрос за фиг.1-1 (Harware overview) на стр.3

http://www.ti.com/lit/ds/symlink/cc3200.pdf

Аз малко те обърках, мислел съм само за WIFI модула.
Иначе, в тоя процесор имаш библиотеки вътре. Така че, всичко би трябвало да се свежда до връзка с АР, пакета от RS-a на TCP, а този от TCP на RS.

Мисля, че това ще е достатъчно:

http://www.ti.com/tool/cc3200sdk

Мисля, че искаш това:

http://processors.wiki.ti.com/index.php/CC32xx_Serial_Wifi

Здравейте отново.
АЗ използвам точно това SDK и с него работя. Функциите за кънектване към АР, отваряне на ТСР сокет, изпращане и приемане на пакети съм ги разучил, и ги ползвам. Понеже чисто технически съм малко объркан как би трабвало да се подредят функциите. това което мога да кажа за въпросният режим съм започнал да го правя по следният начин:


IF_BUFF1_READY флагът го вдигам в интеръпт функцията на UART-ът като ми се напълни буферът за изпращане. Малко ще обясня: интеръпт функцията ми взима приетите данни и ги пъха в Ring буфер, веднага след това съответният приет байт(понеже интеръптът ми сработва при 1 приет байт) се пъха и в буферът за изпращане(нека го наречем - TcpFrame.buff1).

TcpFrame.buff1 ми е с размер 255, а THERE_IS_DATA флагът мисля да го използвам ако остане нещо в TcpFrame.buff1 и ringBuff.usCmdCount не е достигнал 255(колкото е неговият размер). Освен това се предвижда и поскането на Hard flow control (RTS/CTS) на Уартът, за което немога да прогнозирам какво може да се влоши и какво да се подобри. Просто незнам дали идеята ми е правилна в случая, и ако не е какво и къде може да се пипнат и пооправят нещата?

То по принцип общото между двата интерфейса е само, че са серийни.
Единия битово ориентиран, другия - комплексен, пакетно ориентиран, седем нива.

Като цяло, аз виждам няколко варианта:

1. Всеки байт като RS-a се мята на Ethernet(Wifi) - това само по себе си е ясно, че е безумие - ще се предават
огромни пакети заради един байт, ще се генерира огромен излишен трафик и заемане на канала;
2. По твоя метод - тогава изниква въпроса колко да е голям буфера за данни преди да се предаде пакет;
Какво правим ако са 256 байта? - Чакаме да се напълни пак или след определен тайм аут предаваме този 1 байт.
3. Според мен, такъв тип конвертор трябва да е според конкретното му приложение. Или иначе казано, през
RS232 интерфейса трябва данните пак да са пакетно организирани. След като се приеме надеждно пакета се махат
хедъра и контролната сума и се мята на ETH. Наобратно е по-просто щото там пакета ще си дойде в чист вид в буфера.
4. Ако обаче е пък за терминал... ще трябва да е по метод 1...

Иначе, преди време имах досег с един такъв конвертор, марков и .... не работеше

Така че, според мен най-правилният вариант е според конкретната задача/машина/датчик или каквото е там, не универсално.

Какво ще рече не работеше? Аз съм ползвал такъв конвертор - марков и си бачка безгрижно. Принципно му ползвам само бридж функцията ама той може доста повече. Самия конвертор си е една RJ букса (малко по-дълга от нормалното) с 8 пина отдолу - даже като футпринт е като RJ букса. Мисля че е организиран като точка 2 - чака таймаут и праща. Но по принцип организацията на контролера, който интерфейсвам с него е пакет заявка - пакет отговор и не си товаря мрежата с пакети за по 1 байт. Поддържа 1Мбит на уарт-а си. Самия модул има сървър на него и уеб интерфейс за настройка. Има и възможност да търкаля http през уарт-а ама до там не съм стигнал.

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

Относно точка 2, мислил съм го с таймаут но това което пак ме раздвоява е дали да го пусна през таймерът или софтуерно да си направя луп които софтоерно да ми върши тази работа. Освен това съм го мислил и съм се опитвал да го изпълня и по един друг начин - да вкарам една поменлива която ще се нулира от прекъсването и ще се инкрементира в while(1). След като дойде и последният байт по УАРТЪТ, променливата ще почне да се инкрементира поседователно в while(1), и като се достигне определена нейна стойност пускам съдържанието на буферът, нищо че е достигнат неговият лимит. Но това наподобява малко по-дървен вариант на таймаутът. Казвам че е дървен защото ту сработи, ту не и препрати още един път част от вече изпратената информация в последният пакет.

т.е. този буфер от 32 байта, да го прехвърлям в ТСР пакетът и да го пращам като такъв, това ли имаш в предвид? С една дума моят буфер както съм го направил да 255 байта да го сваля на 32.....? Може ли само малко пояснение защо да не е 255 байта а 32?

Може буфера да го направиш и 255 мегабайта така оврърхеда ще е още по-малък. Докато се чакат тези 255 байта да се напълнят, някой устройства ще почнат да дават timeout.
Веднага се сещам за най-евтините блутут модули, дето искат след AT командата веднага(или почти веднага) да изпратиш \n\r. Ако АТ-то ти се падне в предния пакет, а \n\r в следващия, ще си имаш проблеми. А това за 32 байта идва от 16 байтовото FIFO на 16550A http://en.wikipedia.org/wiki/16550_UART#The_16550_FIFO, ако с 16 става и с 32 ще стане, иначе 255 байта са си друга бира.