Och... Hoe die I/O zit, is nauwelijks relevant.
Als je uit je DUT een 'byte' wilt halen (en om misverstanden te voorkomen definiëren dat maar even als 8 bits), kost je 1 regel C code (die natuurlijk wel voor elk DUT anders is).
Feitelijk bepaal je 8x of een bit 0 of 1 is (dat is niet moeilijk; je weet waar het in de AVR I/O zit, je AND dat met de juiste mask en je shift dat zodat jouw bit de LSB is) en dat vermenigvuldig met de 'waarde' in je te wensen byte - of je shift het daarheen (dat doe de compiler waarschijnlijk wel voor je als je vermenigvuldigt en met een klein beetje mazzel worden de 2 shifts ook nog compile-time samen genomen). Je hele meuk douw je in 1 OR en zie daar: de byte die je had willen lezen. Wat je over houdt is worst-case een AND en een SHIFT per bit. En 7 ORs. Qua processing is dat doorgaans prima te overzien.
Een bitwise-read zal wat duurder zijn vanwege de overhead van function calls - en dat je de compiler waarschijnlijk wat 'optimize' mogelijkheden ontneemt.
ga je dat ook in Basic niet oplossen.
Nou is basic echt iets van ruim 40 jaar geleden (al snel overgestapt op assembly en later op C), maar met een beetje compiler zal zoiets in basic toch ook lukken??
Mijn maag keert dan weer van de gedachte dat de eerste de beste bug volstaat om Vss01 en Vdd01 beide te activeren. Met alle vuurwerk vandien.
Ach, de eerste de beste bug... Je moet maar net 2 outputs tegelijk aansturen. Ja, dat kan. Dat vuurwerk valt wel mee - het DUT zal er de meeste last van hebben. Waarschijnlijk is het niet. En als je zo onhandig met programmeren bent, dan maak je er een SET function voor die het voor je afhandelt. Dan hoef je er maar 1x langer dan 10 seconden over na te denken.
Het blijft een simpele vorm low-budget van meetinstrument. Prik je low-budget multimeter op het 2V bereik met de pennen in een WCD en dat zou ook wel eens verkeerd af kunnen lopen - voor de meter. Trek een primaire C uit een switcher en hang 'm direct op de meter zou ook zomaar fout kunnen gaan als je 'm niet tussendoor ontlaadt.
Er is zat meetapparatuur die niet 'monkey proof' is.
Voordeel is natuurlijk wel dat een AVR niet veel kost. Vervelend zou kunnen zijn dat er iets onbetrouwbaar wordt in plaats van het gewoon 'niet doen'...
[edit]Nog ff naar die Maximite zitten kijken. Conceptueel is het gewoon een home-computer in een modern jasje. Met een interpreter. Een iets ander concept dan eea. met een kale AVR doen. Afhankelijk van hoe goed de interpreter is (en hoe het hele video gebeuren in elkaar zit...) zou een 20MHz AVR wel eens net zo snel kunnen zijn als een 400MHz STM32 in deze context. Botweg omdat die AVR 'native' code draait - en veel zaken zijn single-clock aldaar en die STM32 een interpreter runt die het elke keer weer staat om te krikken naar iets waar de 'native' STM32 wat mee kan. Het zal in elk geval zeer zeker geen factor 20 sneller zijn - al zou dat zeker om rare glitches te tacklen wel handig zijn 
