Ik wil voordeel halen uit recent advies van dit forum door mijn project opnieuw te doen met behulp van de 'state machine'-logica, in een poging om verspilling van processortijd en het gebruik van variabelen te verminderen.
Ik start met de state-machine van Nick Gammons om de invoer van de seriële poort te verwerken 'voorbeeld http://www.gammon.com.au/statemachine , die alle verschillende mogelijke combinaties voor alle speciale besturingstekens 'gebeurtenissen' tegen alle mogelijke machinetoestanden toont - in wezen een tweedimensionaal raster.
Ik heb mijn doel verfijnd met het verwerken van seriële invoer in een indeling van " opdracht [parameters] [opties] ", vergelijkbaar met een DOS-opdrachtregelindeling, bijvoorbeeld: DIR "c : \ programmabestanden "/ w/s . Dit zou me bevrijden van het nodig hebben van een grote buffer [] en kop [] string, en vermijdt elke paring,
Daarom zijn mijn besturingselementen voor gebeurtenissen: spatie, komma, enkel aanhalingsteken, dubbele aanhalingstekens, forward-slash, Carraige Return en mijn 'statussen' zijn NULL, COMMAND, PARAMETER, OPTIONS
De status OPTIONS voegt tekens toe aan een tijdelijke tekenreeks [] totdat een komma of spatie-scheidingsteken of Carraige Return ervoor zorgt dat die optie naar behoren wordt verwerkt, waardoor de waarde mogelijk wordt opgeslagen in een herkende variabele.
De COMMAND- en PARAMETER 'toestanden' voegen tekens toe aan hun corresponderende commando [] en parameters [] strings, inclusief de speciale controle karakters als ze zijn opgenomen in enkele of dubbele aanhalingstekens (waardoor citaten deel uitmaken van een string indien gebruikt binnen een paar van het andere type).
Er lijkt dus een tweede toestandsmachine nodig te zijn voor NoQuotes, SingleQuotes en DoubleQuotes om de werking van de COMMAND-, PARAMETER- en OPTIONS-staten te wijzigen.
Hier heb ik geen neuronen meer, want het enige dat ik zie is een onmogelijk complex 2-machine-toestand driedimensionaal raster met te veel mogelijke permutaties.
Maar ik vermoed dat er een zeer praktische manier moet zijn om dit te implementeren, omdat het de kern vormt van bijna alle commandoregelhulpmiddelen die dateren uit een tijd dat processorkracht en geheugenbeschikbaarheid zeldzamer waren dan die van kippen, en die oude DOS-opdracht lijnhulpprogramma's moesten zo klein mogelijk zijn als mogelijk was, inclusief het parseren van de opdrachtregel.
Dus kan iemand een haalbaar model (machine-staat of anderszins) voorstellen voor het verkrijgen van het commandoregel-type-formaat uit de invoer?
BIJWERKEN
Oh lieverd ... ik heb zojuist een andere complicatie gezien die ik nog niet eerder had gezien, namelijk dat '/' opties niet altijd aan het einde zijn, wat betekent dat behalve als de opties staat verandert door carraige-return, optietoestand verandering door scheidingsteken moet terugkeren naar de staat voorafgaand aan de wijziging van de optiestatus (pfff, ik hoop dat dat enigszins logisch is). Hoe dan ook, ik denk dat het terug aan de tekentafel is, omdat deze benadering waarschijnlijk te gecompliceerd lijkt, zoals de 2 antwoorden al suggereren.