Toto je však už cílený DoS útok, a takový se dá realizovat na jakékoliv zařízení - pokud by měly být pakety omezovány v softwarové části zařízení, pak by je stejně bylo potřeba přijmou, analyzovat - určit cíl, službu, porovnat stupeň zatížení služby...

Takto to zahodí přímo HW, když systém nestíhá, a následně se TCP protokol sám postará o obnovení komunikace.

Co se týká spouštění instrukcí SDS-C co 1 msec... je tam ještě jeden historický důvod, totiž existovaly programy, které s tímto počítali, a pak pomocí smyčky realizovali zpoždění (lidé jsou kreativní, co už).
Dnes už k tomu důvod není, existuje funkce wait() nebo odpočítávač vteřin v sys[], ale to jsme v začátcích neměli.

Aktuální verze firmware má jednu z položek v sys[], která toto omezení (krok co 1 msec) vypne, a program provádí instrukce bez zdržování ihned za sebou.

Části kódu, který závisí na časování bude výhodnější ovládat funkčními bloky časovačů (viz námět na funkční bloky) nebo nyní navázáním na nyní dostupné čítače času.

Rozumím potřebě rozdělit čas CPU pro všechny potřeby nějakým mechanizmem, který zaručí přidělení přiměřeného času všem funkčním blokům. O to se pravděpodobně stará scheduler operačního systému. Strategie garantovat určité % času (s možností využít čas nevyužitý jinými bloky) mi přijde výhodnější než při přidělit v každé 1 ms prostor na vykonání jednoho řádku. Tím lze využít i čas CPU, který nyní využít nelze.

Doporučuji zavést systémovou proměnnou, která bude měřit buď čas potřebný na jeden průchod funkce main nebo počet provedení main za čas - pokud možno jako průměr za nějakou dobu. Doporučuji také zaznamenávat v další systémové proměnné buď maximální čas potřebný na provedení jednoho cyklu main nebo minimum provedení main za čas (např. 1s).
Pokud chcete napsat, že to lze i nyní v SDS-C programu, tak souhlasím, nicméně se domnívám že by to mělo být podporováno přímo systémem.

Na základě testování komunikace po Ethernetu se mi zdá, že nejsou omezeny zdroje CPU při obsluze komunikace - jinými slovy že lze SDS přetížit z venku a ovlivnit tak i vykonávání SDS-C programu. Doporučuji implementovat alespoň jednodudché omezení packet rate nebo sofistikovanější omezení komunikace pro jednotlivé klienty. Podobně pro komunikaci odcházející z SDS. Statistika z těchto omezovačů by opět mohla být někde v sys[] dostupná.

Při odstranění této vlastnosti (krok co 1 msec) by program mohl bežet i mnohem rychleji, ale různé části programu by byly provedeny různě rychle. Navíc je zde potřeba obsloužit další funkční bloky, ne jen SDS-C program, a to někdy vyžaduje více času, někdy méně - o to se stará operační systém, a proto nelze tyto časy jen tak určit.
Takže tím že je dán pevný krok - jeden instrukční řádek za 1 msec - tak to je něco co už lze určitým způsobem garantovat.

Samozřejmě, mohou být případy, kdy je tento pevný krok i na škodu, záleží na konkrétní aplikaci.
Možná se v některém z nových firmware objeví konfigurační volba, umožňující spustit program s okamžitým navazováním vykonávání instrukcí, bez synchronizace na 1 msec...

Jestli je potřeba, tak není problém to zpomalit, je to jen otázkou úpravy firmware.

na http://wiki.merenienergie.cz/index.php/ … .C4.8F_.3F uvádíte:
"Každou 1 msec je proveden jeden celý příkaz"

Proč je prosím rychlost vykonávání "celých příkazů" omezena na 1000 za 1s ?