Původní podoba příspěvku
Surová data tak, jak byla v roce 2013 stažena z Pandory (HTML zdroj bez úprav, osobní e-mailové adresy jsou maskované).
<!--------------------------------------------------------------> <table width="100%"><tr><td align="left" valign="middle"></td><td align=right valign="middle"></td></tr></table><BR><pre> Ahoj, odpovim postupne vsem v tomto mailu :) Co se tyka pameti, tak to neni zase az tak velika tragedie. Ten kdo do Unikarty osadil STM32F101 (asi vetsina), tak tam ma 16 kB. Pokud si nekdo krom mne a Vaska osadil STM32F103, tak ma 20 kB. Nicmene aby jsme meli kompatibilni firmware, tak je linker nastaven takovym zpusobem, aby se zasobnik umistil na adresu 0x4000 v RAM - tedy na hranici tech 16 kB. Soucasny kod po kompilaci zabira 9 288 bajtu BSS. To znamena, ze pro zasobnik tam ted mame stale jeste skoro 7 kB pameti. Kdysi jsem delal nejaky test toho kam az se mi dostal zasobnik a mam pocit, ze jsem mu tehdy nameril nejake 4 kB. Mam uz take jakousi predstavu jak by se ten stavajici kod mohl preorganizovat a tim by se asi usetrili i jakysi ten bajt. Co se tyka UDP protokolu, tak ten v unikarte samozrejme budeme podporovat. Unikarta vsak umi navazat UDP komunikaci s protistranou pouze za takovych podminek, ze uz dopredu vime kdo s nami chce timto protokolem mluvit a jaky je jeho odesilaci UDP port. Na zaklade stejnych informaci umime vytvorit samozrejme jak TCP, tak i UDP socket, nicmene u TCP mame jeste navic moznost naslouchat na nejakem konkretnim portu a vytvorit novy socket az v momente, kdy se kdokoliv v internetu rozhodne, ze nam do takto vystaveneho portu cvrnkne. Automaticky se nam vytvori socket a my se az v tuto chvili dozvime IP adresu a odesilaci port protistrany. Pokud si chcete vyzkouset stavajici firmware, tak jsem jej umistil sem http://duna.ordoz.com/ushell_tcp/ Najdete tam zdrojak programu pro komunikaci s Ushellem - je to uplne ten samy kod, ktery se pouziva pro praci pres RS232. Ovladani zustava stejne. V prvnim parametru je uvedena bud cesta k RS232 device, nebo tcp:ip_adresa:port. RS232: # ./ushell /dev/ttyUSB0 readdir /unicard TCP: # ./usell tcp:192.168.167.80:23 readdir /unicard Martine, pokud jej budes upravovat pro windows, tak jsem v tom kodu v podstate pouze pridal inicializaci TCP socketu. Pak jsem malinko upravil funkci ReadResult(), protoze v RS232 rezimu chodi z Unikarty na konci radku kod 0x0d, 0x0a, zatimco v TCP rezimu chodi uz jen 0x0a. A jako posledni jsem musel upravit funkci PrintBps(), protoze pres TCP je obcas end_time - start_time roven nule :) Jeste by to tam chtelo pridat i nejake timeouty, ale momentalne nevim jak se to dela :) ... v Unikarte uz jsem nejake timeouty udelal. Do adresare /unicard si nahrajte soubor network.cfg, ktery si upravte dle vlatnich potreb. Po resetu vam Unikarta posle na USART debug info o tom jake hodnoty precetla z konfiguraku, napr: cfg_hwaddr=02:00:00:00:00:01 cfg_ipaddr=192.168.167.80 cfg_netmask=255.255.255.0 cfg_gateway=192.168.167.254 Ushell PORT: 23 Unicard - USART Shell OK:RESET V tuto chvili uz by vam to melo odpovedet na ping a mel by vam fungovat telnet na tcp port Ushellu. Ve chvili, kdy se pripojite na TCP Ushell, tak se ukonci a zablokuje cokoliv co se pripadne prave vykonavalo v Ushellu na RS232 - ten TCP ma vyssi prioritu. Ushell podporuje jen jedno aktivni spojeni. Pokud prijde nejake dalsi v dobe, kdy je uz nekdo pripojen, tak dostane odpoved BUSY a info o tom, kdo momentalne tu sluzbu blokuje. Pokud na vstup Ushellu neprijde 60 sekund zadny packet, tak se spojeni prerusi s hlaskou TIMEOUTED. Pro efektivnejsi komunikaci mezi STM32 a ENC29J60 jsem pripojil z ENC signal /INT do pinu c.52 v STM32 (PC11). GPIO jsem nakonfiguroval tak, aby si STM na tomto vstupu pripojilo interni pull-down a tak pokud tam tuto propojku neudelate, tak by vse melo fungovat, akorat vam Unikarta bude travit zbytecne moc casu kontrolou prichozich packetu. (provoz bez teto propojky vsak nemam overeny - zkusite to nekdo?) Pokud nemate osazen ENC29J60, nebo pokud z nejakeho duvodu neni funkcni, tak se pri inicializaci na USART vypise debugovaci hlaska, ze ENC nereaguje a konfiguracni soubor se pak uz ani nezacne zpracovavat. (tohle jsem si overil jen tak, ze jsem si nasimuloval chybu v SPI komunikaci, zda se to bude chovat korektne s neosazenym ENC to vsak zatim neni overeno - zkusite?) Toz dejte vedet, zda vam to alespon pinga. Pokud se pres TCP prenasi z Ushellu nejake vetsi soubory do Linuxu, tak to chvili vypada, ze se nic nedeje (nevysypava se buffer terminalu a tak se na obrazovku nevypisuji tecky, ktere jsou viditelne pri RS232 komunikaci) nicmene spojeni zije a je aktivni, coz je videt na LAN_LED Puvodne jsem v Unikarte volal odesilaci rutiny kdykoliv, kdy Unikarta zrovna nemela nic jineho na praci, nicmene pri prenosu vetsich souboru z Unikarty do PC se mi obcas stalo, ze PC nestihalo ty packety prebirat a Unikarta pak zabalila spojeni z duvodu velkeho poctu zadosti o retransmit. Jeste jsem nezkoumal jake by mely byt doporucene mezery mezi odesilanymi packety. Ted jsem tam nastavil 100 ms a zatim mi zadne spojeni nespadlo. Michal </pre>