Čekáním na naplnění celého bufferu by si zbytečně snížil přenososvou rychlost (díky úvodním nedatovým bajtům i2c).
Někde jsi tam psal o rychlosti 115kb a vyšší. Požiju-li tvůj výpočet rychlosti zápisu 64b dat do eeprom 1,5ms a k tomu přidám 5ms interního zápisu, hodí to řekněme 7ms ať je rezerva. 7e-3/64/9 = 1.22e-5 s na 1 bit po uartu, tzn. maximálka asi 82kbit.
Zde předpokládám, že zápis začal dříve než po naplnění bufferu aby odpadlo to počáteční i2c zdržení.
Nemam ani ponatie, o ktorej zo styroch variant teraz hovorite… A neviem na ake cakanie na naplnenie buffera myslite… ved predsa na strane USART-u je buffer na to, aby sa naplnil.
Ale kazdopadne - su tieto styri varianty, kazda ma svoje vyhody aj nevyhody.
Kolegovi, ktory sa pytal, som navrhol riesenie 1 s dvomi buffermi. Myslim, ze na jeho poziadavky je viac ako dostatocne.
Pri 32 B bufferoch je to jednoducho 7ms/zapis plus par mikrosekund na prenos medzi buffermi, teda stale 7ms. Za 7ms teda moze prijat 32B, co je 4571 bajtov za sekundu, pri 10 bitoch na jeden bajt u RS232 je to 45,7kbaud. Prostym zvacsenim bufferu na 64B sa prenosova rychlost zdvojnasobi na 91,4kbaud.
Ak by sa pouzila SPI EEPROM, bolo by to lepsie - asi 110kbaud, lebo odpada pomale IIC rozhranie.
Samozrejme, dalo by sa to robit aj inak, napriklad rozpinpongovat na viac EEPROM, pouzit vhodnejsie pamate atd… Nie je problem dostat sa na rychlosti zapisu o jeden rad vyssie, ale to som tu nechcel riesit, pretoze kolegovi, ktory povodne dal otazku, islo o zapis na 9600 baud, ak si dobre spominam.
Samozrejme, kto ma lepsi napad ako na to, rad si ho vypocujem.
administrator: příspěvek byl upraven
Předchozí příspěvky se necitují.
Děkuji všem za vyčerpávající odpovědi. Pro mě bude asi nejsnazší a přitom dostatečně vyhovující varianta od Jaromíra a to použít 2x buffer. Vyzkouším jak variantu 1, tak variantu 2 – ping-pong při rychlosti 9600 baud která je pro tento účel dostatečná.
Jinak eeprom bude hned vedle PIC, takže vzdálenost minimální.
Měl jsem na mysli tu 1. variantu, bufferem jsem myslel ten sw 64B. Šlo mi jen o to, že není ideální čekat, až bude plnej, protože inicializace přenosu i2c chvíli trvá a při využití maximální rychlosti by mohl o nějaký bajt přijít.
Petr: zavedením 2 polovičních bufferů si zbytečně zvýšíš režiji a zpomalíš maximálku (zápis trvá 5ms ať zapisuješ 32 nebo 64B). Pokud ovšem použiješ 9600bd, tak je to jedno. Záleží, co se ti bude dělat snáz.
Aha tak - ale tato moznost bola len teoreticka, z ktorej vychadzali ostatne moznosti, na porovnanie dosiahnutelnej rychlosti.
Ale samozrejme Vasa poznamka je spravna, ale moznosti na vylepsenie je vela - napriklad ta, ze sa pouzije ina metoda 
Dovolim si odpovedat za kolegu - ten 32B buffer som navrhl preto, ze dva buffery sa zmestia do jednej banky PIC16, takze programovanie bude jednoduchsie.
A tych 32B je dost na 9k6, netreba pouzivat zbytocne velky buffer… vlastne by stacilo aj 16B na jeden buffer, ale to zas neprinesie nejake extra velke vyhody, ale teoreticky sa aj to moze hodit.
Vyzkouším i 2x 64B buffer, přepínání bank i stránky paměti řeší překladač.
Tento modul bude mít na starost jen na jedné straně z PC přijmout data, uložit je a po přenesení modulu na jiné vzdálené místo je předat jinému zařízení. To bude jeho veškerá činnost, něco jako USB Flash, ale menší a pomalejší.
Tak jsem nakonec sehnal 25LC1024, je to sice o trochu víc místa, ale do budoucna se může hodit.