To máš asi pravdu. Čistě teoreticky je při 9600 Bd reálná rychlost přijímání max. 960 zn./s, Picaxe na 16MHz vykoná max. 4.000.000 instrukcí za sekundu, čili na zpracování jednoho bajtu má nejvýše lehce nad 4000 instrukcí. Jenže když to je softwarový seriák, tak zřejmě dost velkou porci z toho sežere vlastní čtení.AlesH píše: ↑30 říj 2017, 08:49 obávám se, že obecný "serin" v PICAXE je jen softwarové řešení sériové linky, bez hardwarového bufferu přicházejících znaků, takže je možné, že posloupnost "serinů" nestihne správně zpracovat bezprostředně po sobě jdoucí znaky v jedné sekvenci.
V návrhu programu je sice mezi "seriny" jen velmi málo příkazů, ale podle mých zkušeností může zpracování i jen jediného řádku PICAXE programu trvat klidně i milisekundu, a to by pro softwarové zpracování posloupnosti na sérové lince při rychlosti 9600 bd už asi bylo moc dlouhé. S jistotou to ale nevím, muselo by se to prakticky vyzkoušet.
V takovém případě bych to tedy spíš řešil buď nepoužitím Picaxe (napsal bych si to sám v C nebo ASM s bufferováním a přerušením) anebo přečtením rovnou víc znaků najednou
serin C.4,N9600_16,("pt"),znak_A, znak_B, znak_C, znak_D
(pokud přicházejí max. tříciferná čísla, pro víc cifer by se přidala další proměnná) a následným zpracováním. Ovšem musel bych to udělat při vědomí že a) pokud pt bude poslední příkaz a zároveň to nebude záporné trojciferné číslo, tak se to zasekne, b) bude to vždy umět zpracovávat právě a jen příkazy 'pt', protože to z následujícího příkazu může ukousnout nějaká písmena na začátku (o tolik, kolik mělo číslo méně než 3 cifry a znamínko), c) pokud půjdou dva pt příkazy za sebou a první nebude záporné trojciferné číslo, tak to ten druhý bude ignorovat (přímý důsledek b)).