Latence přerušení: kdo doopravdy zdržuje
Katalog uvádí dvanáct taktů. Na 168 MHz je to sedmdesát nanosekund a vypadá to jako vyřešená věc. V reálném zařízení bývá skutečná latence stokrát větší, a ten rozdíl nemá s čipem nic společného.
Šest sčítanců, z toho dva jsou tvoje
| úsek | typicky | čí to je |
|---|---|---|
| synchronizace vstupu | 1–2 takty | křemík |
| zakázaná přerušení | 0 až desítky µs | tvůj kód |
| běží vyšší priorita | 0 až desítky µs | tvůj návrh |
| uložení kontextu a skok | 12 taktů + čekací stavy | křemík |
| tělo obsluhy | desítky až tisíce taktů | tvůj kód |
| návrat | ~10 taktů | křemík |
Nález, který je vidět hned v obrázku: stačí jediná kritická sekce dlouhá deset mikrosekund a hardwarová část klesne pod dvě procenta celku. Zrychlit čip desetkrát pak zkrátí latenci o pár procent — protože se nezkrátí to, co ji tvoří. Rychlejší procesor nespraví návrh, který zakazuje přerušení.
Kde se přerušení zakazují, aniž by to bylo vidět
- V knihovnách. Zápis do flash, přepnutí kontextu v RTOS, alokace paměti, některé HAL funkce.
- V kritických sekcích, které tam patří. Čtení 32bitové proměnné, do které píše obsluha, na 8bitovém čipu.
- V ladicím výpisu. Blokující
printfpo UART na 115 kBd je osmdesát mikrosekund na znak — a je-li ve zbytku kódu, latence je v milisekundách.
Čekací stavy flash
Na rychlém čipu je flash pomalejší než jádro, takže se čte s čekacími stavy — u 168 MHz jich je pět. Skok do obsluhy je skok na adresu, která není v cache, takže se těch pět stavů zaplatí. Je to malé číslo, ale je to důvod, proč se kritické obsluhy někdy překládají do RAM.