TC65 prenos dat a filesystem

[Ondřej Janovský]

Dobry vecer,

zkusim par postrehu:

1. filesystem -  nepouzivejte, pokud nemusit ... je velmi pomaly, hodi 
se jen pro data, ktera nechcete ztratit po vypnuti. Pokud s nim delate, 
udelejte si pomocne metody a ctete vzdy po vetsich blocich, ne byte po byte.

2. poskladat si data, nez je poslete pres OutputStream metoda 
write(byte[] b) do CSD spojeni - dobry napad. Udelejte si buffer z 
bytoveho pole, o nejake vetsi delce a ten pouzivejte na kompletaci dat. 
Nealokujte zbytecne nove buffery s kazdou novou zpravou, vyuzijte jeden 
stale existujici.

3. predpokladam ze pouzivate vice vlaken, takze si vlakno, ktere zrovna 
nemusi vykonavat nejakou cinnost na chvilku uspavejte   
Thread.sleep(50). Ostatni dostanou vice casu. Nebo si jej zastavte 
pomoci synchronizaci - napriklad: nemusim cist seriovy port, kdyz zrovna 
cpu data do GSM-CSD (seriak na TC65 ma interni buffer, takze se to da 
zvladat i bez ztraty dat nebo pouzijte CTS/RTS) ...
Nastavovani priorit u vlaken neni legrace, u mne nevedlo k dobrym vysledkum.

4. GarbageCollector - zjednodusene - pousti se automaticky, pokud 
dochazi volna pamet pro alokaci novych objektu/promennych, nebo kdyz je 
cas ... uspane thready atp. Kdyz chcete, aby se volal co nejmene v 
nevhodne chvile, pak si optimalizujte kod:

a) snazte se vytvaret objekty/promenne s dlouhou platnosti a znovu je 
pouzit, nez neustale tvorit nove.
b) nedelte kod do spousty metod - jejich volani je prace se zasobnikem, 
alokace lokalnich promennych, uvolnovani .... Musite si vybrat mezi 
citelnosti a vykonnosti kodu.
c) pokud vite, co delate (zrovna jste uvolnil nejake objekty), pak si 
zavolejte GC rucne. Vyplati se u objektu udelat  objekt=null; coz GC pomuze.

Pri vyse popsanem se vam pres CSD podari poslat data vcelku, aniz by se 
zadrhla.

Oja


nevrklap@volny.cz wrote:
> Diky za reakci,
>
> zkusim to napsat jeste jednou. Mam aplikaci v TC65 ktera ma pres GSM
> na vyzvani sypat data do programu na vzdalenem PC. Ta aplikace v PC
> je komercni produkt, nelze ji zmenit ani se podivat jak je napsana.
>
> Protokol prenosu je vcelku jednoduchy - hlavicka, data, ukonceni a checksum.
>
> Problem nastane kdyz jeden blok dat dojde do aplikace v PC rozdelen (v
> case) na vice casti. On ten PC program si tam "nejak" prida znak "konec
> bloku" ktery zapocte do checksumu. Ale ja netusim, ze data nedojdou
> vcelku a on si tam neco prida a tudiz mnou vygenerovany checksum mu
> nesedi...
> Asi to zni trochu divoce, ale dle pozorovani to tak zatim vypada.
>
> Zrejme to pujde vyresit tim, ze si data predpripravime v RAM a pak posleme
> (doted je jeste cteme z filesystemu), ale muze se stat, ze treba zasahne
> vyssi moc (garbage collector?) a data vcelku nedojdou...?
>
> P.
>
>
>
>   
> To nezalezi na priorite, ale na pouzitem protokolu a dalsich mnoha faktorech.
> Pokud to mate v TCP, tak ocekavat, ze data budou chodit v takovych blocich,
> jak jste si je tam z PC nasazel, je programatorska chyba. Naopak je
> treba v aplikaci zaridit, ze data BUDOU chodit po castech. Neni na tom
> nic tezkeho, proste napriklad poslete hlavicku 2 byte delka, pak vlastni
> data, pak 2 byte CRC a na druhe strane prijmete hlavicku a prijimate
> data tak dlouho, az mate vsechny data + CRC.
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list@list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>