Op 14 juli 2011 22:33:03 schreef SparkyGSX:
@FE: voor de TS lijkt het anders nog een flinke uitdaging.
Overigens zal dat stukje code met 7 variabelen best functioneel zijn, maar het is ook alles behalve efficiënt of elegant.
dat zijn 8 bytes ( 6 bytes voor de digits, 2 byte voor de tick ).
Laten we even rekenen... een getal zoals 235959 vereist meer dan 16 bit... 24 uur is 86000 seconden dus dat past weer al niet in 16 bit.
Het is dus volgens jouw efficienter om 32 bit arithmetic code te gaan kakken op een 8 bitter en daar allerhande complexe bewerkigen op te doen om dan via delingen dat te outputten naar een string en dat dan door een inthandler te jassen ?
je hebt dus 32 bit arithmetic aan je broek. en dat converteren naar ascii strings om die dan te passeren aan een output handler gaat je ook een berg intermediate ram , stack , code en cycli kosten.
't verwonder tme dat je er niet eerst linux op porteert met daarbovenop VMware en daarin dan Windows7 (liefst de 64 bit versie..). Dan kun je er python in cygwin op draaien en daar een scriptje in maken... wat 'print timedate' doet ... liefst naar een op usb geemuleerde rs232 poort zodat we nog wat kunnen sakkeren over driver compatibility en usb virtualisatie.
we rekenen verder :
Die if then is 1 machinetaalinstructie want de compare loopt tegen een rom constante. Elke 'digit' van de clock is 1 byte.
er zijn 6 testen nodig en zes instructies om de bytes op nul te zetten...
Dan zijn er hoop en al 30 instructies nodig om die bytes een voor een op te tellen bij ascii karakter '0' en dat naar de seriele poort te vlammen.
Gans die routine is bovendien volledige determinisisch. Voor elk codepad weet je exact hoe lang ze gaat lopen en je kan het langste codepad op voorhand bepalen. Je kan die code zo profilen. ideaal als je Realtime bezig bent.
Op een 8051 heb je met mijn aanpak hoop en al 8 van de 256 byte ram nodig en pakweg 100 byte van de 4K Rom...
Eendert welke andere aanpak zal veel meer ram en rom vreten omdat je nodeloos met conversies zit te dollen. bovendien verzeik je cpu tijd met moeilijke bewerkingen zoals delen en vermenigvuldigen.
We gaan verder met rekenen :
Die interrupt komt elke 200 microseconden. je hebt daar alleen een downcounter. dat kost dus niks qua processing tijd. Das 3 a 4 instructies elke 200 microseconden. kippeeitje voor die processor.
Als die overrolt heb je een 'tick' en dan heb je een 70 tal instructies extra aan je broek om je tellercascade te doorlopen en te staan wachten op de uart... : 9600 baud dat is 1200 karakters per seconde.. en je moet er maar 8 sturen . Je slijt daar 6 milliseconden met wachten op de uart... en dat om de 1 seconde....
De load van die ganse clock, uart en die flikkerdinges is nauwelijks 0.6% van de beschikbare cpu tijd... tijd zat om er nog een zelfbalancerende robot die een rode bal kan volgen bij te prammen. en die 0.6% komt dan nog van 8 keer te wachten tot de uart klaar is met een karakter... als je die uart op 1.4 megabaud zet gaat dat naar 0.000001 % cpu time zakken.
Niet alleen dat, mijn code is zelfs multithreaded. De output thread loopt onafhankelijk van de secondetick. Ik heb een volledige seconde om op mijn gemak die ascci prut door te sturen . Evenen rekenen. 8 karakters 8 bits .. 64 baud plus ene paar start en stop dinges ...
tzou moeten lukken op 75 baud ... 9 bits per karakter zou 72 baud geven en we gaan aan 75 ... no problemo.
En er is zelfs geen gevaar dat de ene thread de andere overrolt.
Ge gaat straffe kunsten moeten uithalen om iets te maken wat compacter ,sneller en efficienter draait met minder rom ,ram of stack en dan nog eens threaded en determinisitisch is.
Zelfs als je de tijd BCD zou encoden verspil je meer instructies...
Het sop is de kolen niet waard.
voor sommige zaken gaat het sneller vooruit om de digits gewoon los te stockeren dan er allerhande complexe meuk op los te laten.
het schrijft natuurlijk makkelijk
int32 x.
x = x + 1
maar je moet eens zien wat een berg code dat wordt op een 8 bitter..
en je hebt onvermijdelijk nog een hoop calls en rets aan je broek ook want ze gaan dat uit een voorgekauwde library gaan sleuren.
ik heb zelfs geen stack want er wordt niks aangeroepen.
enfin. das mijn gedacht.