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