Supeeeeer.
UDP server je asi zbytečný luxus.
Jinak jak to čtu, je veliká škoda, že na uc není víc paměti, vždyť dnes
nic
nestojí....
JL
Dne So 19. října 2013 00:25:13 Michal Hučík (sharpemupandora.cz)
napsal(a):
Zobrazit citovaný text (74 řádků)
> Ahoj,
>
> po par mesicich jsem se opet dostal k Unikarte. Chvili jsem blbnul
> swebserverem, ve kterem mi bezela aplikace pro spravu Unikarty, ale v
> zapeti jsem jej zavrhnul, protoze pameti nemame nazbyt. Proto jsem
> akorat priohnul stavajici USARTshell tak, aby jej bylo mozne prepnout
> bud na RS232, nebo naTCP a prejmenoval jsem jej na Ushell :)
>
> Uz mam i jakousi ucelenejsi predstavu o tom jak by melo vypadat API.
>
> Fyzicka vrstva je na sharpu dle meho nazoru zbytecna. Omezil bych se asi
> jen na funkci, ktera precte z registru ENC29J60 stav linky up/down.
>
> Aplikacni vrstva - na tu tam nemame uz prilis mnoho pameti. Pokud nejaka
> bude nadbyvat, tak tam chci dat dns resolvera dhcp klient... Kdyz se mi
> podari carovat s volnym mistem, tak treba i http a smtp klient, atp...
>
> Samotne API pro praci se siti bude realizovano v duchu zjednodusenych
> BSD sockets. Bude mozne otevrit omezene mnozstvi UDP, nebo TCP socketu.
> Dale bude mozne otevrit anonymni socket, ktery bude naslouchat na
> urcenem TCP portu a umozni Sharpu zareagovat na prichozi TCP spojeni.
>
> ( U protokolu UDP neni v tuto chvili zadny anonymni listening mozny. Mam
> predstavu jak to tam dopsat, nicmene potrebujenekdo psat serverovou UDP
> aplikaci?)
>
> Sotevrenym socketem bude mozne pracovat jako se souborem. Pri zapisu
> (odesilani packetu) jsme vsak limitovani pameti - Unikarta se musi
> starat i o retransmit v pripade nedoruceni packetu. K tomuto ucelu bude
> zrejme potreba vymyslet vice odesilacich rezimu, ktere budou odesilat
> data jak automaticky po naplneni bufferu, tak i manualne - dle potreby.
> Nasledne si bude muset Sharp pockat na to az od protistrany prijde ACK -
> potvrzeni o prijeti packetu. Do te doby se nebude smet ze Sharpa na
> odesilaci buffer vubec sahat (pokud tedy pro konfort neobetujeme vice
> pametitak, aby velikost bufferu prevysovala max velikost odesilaneho
> packetu).
> Bude tam tedy muset existovat nejaky transportni semafor. K tomuto ucelu
> bude samozrejme fajn mit moznost naprogramovat si interrupt system v
> Unikarte tak, aby nas zatahal za rukav jakmile bude mit opet volno.
> Mam uz i jakousi predstavu o tom, ze by jsme tam mohli mit nejaky
> dynamicky buffer, jehoz rozlozeni by si kazdy mohl nastavit dle
> vlastnich preferenci a ovlivnovat tak potom cinnost jednotlivych
> periferii. Jen aby z toho pak nevzniknula pouze komplikovana
> programatorska hricka :)
>
> Dnes jsem tedy kroutil maticky a dotahoval sroubky na Ushellu. Zde je
> report z prenosu dat Unikarta (SD) -> PC :
>
> # ./a.out tcp:192.168.167.80:23 read sdmgr_cpm.DSK /tmp/sdmgr_cpm.DSK
> Unicard - TCP Shell
> Sending Reset...
> OK:RESET
> Sending Read...
> READ sdmgr_cpm.DSK
> OK:READ sdmgr_cpm.DSK
> Receiving FSIZE: 0x000bdf00
> Receiving Data.............
> OK:CLOSE 0x29a8fa20
>
> *************************
> * Size: 777984 B *
> * Speed: 29640.87 Bps *
> *************************
>
> Tedy cca 230 kbps ...
>
>
> Michal
>
>
>
> ---
> POZOR! Provoz systému Pandora.cz bude k 30. listopadu 2013 ukončen.
> Více informací: http://goo.gl/b99cI