Идеята на ike е добра.
Буферът го направи поне 2-3 пъти по голям от размера на пакета, за да не стават грешки.
Времето го мери с таймера, да не те мързи да пуснеш един.
Нещата в комуникациите трябва да се изпипват....
Един преподавател в университета казваше така: "Те онея програмистите ги оставете. К'вото и да забъркат, накрая пак ние трябва да предадем информацията коректно по средата за връзка."

Абе хора, вие за receive timeout не сте ли чували?

Доколкото си спомням rtout-a на каубойците беше фиксиран на 32 бита и имаше някаква особеност дето вече не я помня, ама със сигурност работеше!

При бриджване или каквато и да е друга обработка се пуска четене с размер колкото е пакета и или идва цял пакет и се обработва. Или идват по-малко данни и 32 бита след последния стоп бит идва receive timeout и тогава обработвате колкото е получено...

relsys не ме мързи да пусна каквото и да е (макар и да е нещо което е съм пускал досега), просто споделям мнение за да тръгна по път който що-годе е правилен. Както казваше един колега тук от форумите -"да се види дали наистина има смисъл да се вдигат тези гири" .
В SDK-то намирам информация за една от функциите която ползвам за въпросният Bridge mode, става въпрос за sl_Send(). Тя има за цел да изпрати, вече оформен и напълнет масив(буфер) с данни като ТСР фрейм. Та информацията която намирам за тази функция е за ограничение на броя байтове които могат да се пратят чрез нея. Казва се че "не би могло да се прати фрейм с над 1472 байта и под и такъв с под 14 байта". Това нещо го соделям понеже за този случай се поразрових в Интернет и намерих различни мнения по въпроса, като генералното беше че наведнъж би могло да се пратят 65Кбайта в зависимост от иплементацията. Разбира се в случая ако искам да пратя файл, който е с подобни размери ще имам в предвид прочетеното в SDK-то. Другото което се получи малко тъпо е че нямам конкретна информация, колко големи файлове ще трансферирам. Единствената информация с която разполагам е това което съм прочел в нет-а и SDK-то.

Няма такова нещо като 65К наведнъж. Максималния размер на ETH пакет е 1500 байта. MAC, IP addresses, PORTs, CRC са 28 байта и затова остават 1472. Ако примерно ползваш и да речем PPOE, размера на пакета с полезни данни ще намалее още. От друга страна, минималният размер е за да не се получава Late Collision.

Споменал си нещо, че ще се прехвърлят файлове, ако кажеш точната постановка, може би по-лесно ще намерим правилното решение.

Само пакети които не минават реално по Ethernet могат да бъдат по-големи от 1500 байта. Пример за това е комуникация между две програми по localhost интрефейса.

Jumbo frames ?

Здравей, пак казвам че и при мен съществуват някой въпросителни на които съм се опитвал да изкопча някакъв отговор. Не случайно използвам думата "изкопча", защото въпросната информация съм се опитвал да я получа от колеги които са от повече време тук, където аз работя - говори се за отчети, заявки към сървъри, респонси на хост-сървър и обратно, и.т.н.т. Сега може би нещата ще ги насоча към някаква насока (поне ще опитам, ако съм неясен моля да ми кажете)- преди известно време се занимавах в един подобен WiFi модул, при които всичките AT команди(които в момента аз имплементирам в СС3200) бяха налети, и човек трябваше да разучи горе-долу какво прави всяка една от тях. Последното като занятие което направих с въпросният модул, преди да се реши че ще ни свърши работа, беше да установя връзка с киптиран https web сървър и да изчета по RS-а съответната web страница, напримерно https://twitter.com/. Процедурата небеше сложна, викаше се команда която да направи сокет към сървърът, след това се викаше друга такава която да влашне SSL сертификатът в WiFi модулчето, и трета такава окято да изтегли садаржаниета на web страницата и да го пусне по RS-а ком хостът. В случая незнам и немога да дам конкетна информация въпросният уеб към който ще се кънектвам колко голям ще бъде. Освен това незнам и въпросните отчети, закоито споменах, какво представляват и колко са големи. Предполагам че са файлове които се създават от фалова система, интегрирана в устроиствата към които ще прикача след време WiFi модулът. Поне като не съм поучил адекватен и ясен отговор когато съм питал, съм слушал разговори на колегите, които си говорят че тези отчети се записват посредством интергираната файлова система във външна флаш памет или SD карта. Това мога да кажа за сега, ако изкопча нещо, ще пиша....

може ли само да те питам нещо-като пусна таймерът, да му пускам ли интеръпт, или да го нулирам в интеръптът на УАРТ-а а да го икрементирм в луп-а (while(1)) на bridge mode-а?

Много е забавно, как всички са прави, само че на ралично ниво(layer).

Пускаш му прекъсване. Нулираш го в прекъсването на UART. Ако се стигне до прекъсване от таймера - пращаш каквото има в буфера и го пускаш после при първото прекъсване от UART_RX_BYTE. Е, може и да си го държиш пуснато прекъсването и да гледаш head/tail....

Разбрах те, благодаря relsys !

Пак да кажа, че CC3xxx си има receive timеout !!!

Няма нужда да пускате и спирате нищо, то си има таймер и си го пуска и спира автоматично...

Здравей, видях го този receive timеout още в първият ти пост. В SDK-то има дескрипшън който казва че се отнася за "входяща, чакаща функция" каквато е например sl_Recv.


Само че, аз sl_Recv я използвам в NonBlocking режим. Казано с прости думи като влезна в луп-а по-горе и скриптът ми влезне в тази функция, той не чака да настъпи ивент че е настъпило нещо (наприперно е дошъл ТСР пакет) а връща -1 (ако нищо не се е случило) или брой прочетени байтове. Мисля че някъде видях таймаут transmission mode (не transparent mode), който в документацията им описва трансферът и в двете посоки, но ще видя в кой файл беше.

Може ли един страничен въпрос свързан със същият проект (ако не му е тук мястото ще отворя друг пост). Налага ми се да истествам един hard flow control (UART-RTS/CTS), като ми казаха за целта да пусна файл от PC-то към контролера по сериината комуникация и да изчисля MD5 чексумата и от двете страни и да ги сравня (ако бъдат равни -> контролът работи). Както вече споменах имам Ring буфер който го пълня от прекъсването на UART-а, и имам отделна функция която ми чете байтове от този буфер и ги пълни във втори (да го наречем Data буфер). Дадоха ми един хедър и един С файл от който мога да използвам наличните функции за да сметна MD5 от страна на контролера и да я запиша в променлива, в която след това да я изчета. Проблемът е че Data буферът ми е с размер 80 байта, а в задачата се иска да пъсна от PC-то файл с размер 1МБайт-> че Data буферът ще се напълни до 80-я байт и ако го пусна през функцията за изчисляване на MD5, тя ще ми го изчисли на тези 80 байта, а не на пълното съдържание от 1Мбайт. В опасенията ми има ли нещо вярно или бъркам? Понеже мога да дигна размерът на Data буферът, но 1Мбайт не бих могъл да го направя.

Чакай малко, аз ти говоря за receive timeout на UART-a, а не за TCP-то. Аз ли не мога да те разбера или ти смесваш различни проблеми?

Принципно, когато получаваш от UART не се знае кога и колко байта ще дойдат. Дори и да имаш някакви "предчувствия" винаги могат да те изненадат.

От една страна не винаги е разумно да обработваш байт по байт. Доколкото разбрах, ти ще ги пращаш по TCP и ще се получи голям овърхед. От друга страна както казах не знаеш дали и кога и колко байта ще дойдат и може да се получи голямо закъснение, ако чакаш да се натрупа цял пакет. Точно затова се ползва receive timeout на UART-a. Toва си е дефакто стандарт. Не знам как е във въпросното SDK, но принципно когато пуснеш заявка за получаване от UART, без значение дали е блокираща или неблокираща, тя трябва да се сигнализира като изпълнена когато получиш указания брой байтове (като за 1 пакет примерно) ИЛИ когато се получат няколко байта и пауза (таймоут).