Hallo, ich versuche einen IO-Port zu schalten, brauche dafür ein auf 1-Clock-Zyklus genaues Timing und genau da liegt das Problem. Leider kann ich noch kein Assembler, deshalb versuche ich es in C. Damit es so unkompliziert wie möglich ist, sieht mein Code (gekürzt) so aus: uint8_t off = PORTB; uint8_t on = PORTB | (1<<PORTB4); if (bla) PORTB = on; else PORTB = off; if (bla) PORTB = on; else PORTB = off; if (bla) PORTB = on; else PORTB = off; if (bla) PORTB = on; else PORTB = off; if (bla) PORTB = on; else PORTB = off; if (bla) PORTB = on; else PORTB = off; if (bla) PORTB = on; else PORTB = off; if (bla) PORTB = on; else PORTB = off; Das funktioniert auch alles soweit, solange ich 01010101 setze. Setze ich allerdings 00001111 fällt mir auf, dass er anscheinend so "klug" ist, bei den sich wiederholenden Bits weniger Zyklen zu brauchen als bei dauernd wechselnden Bits, als ob es intern so nach "IF(differentStatus)Switch" ablaufen würde. Das ist natürlich prinzipiell sehr intelligent, aber in meinem Fall müssen die Timings halt genau stimmen. Laut ASM macht er es so: sbrs r24, 1 rjmp .+4 out 0x18, r25 rjmp .+2 out 0x18, r18 Sieht doch für mich als Laie eigentlich genau richtig aus. Dennoch brauchen die outs je nach Bitmuster verschieden lange....
Gast
#4092505
Christian S. schrieb: > Das funktioniert auch alles soweit, solange ich 01010101 setze. Setze > ich allerdings 00001111 fällt mir auf, dass er anscheinend so "klug" > ist, bei den sich wiederholenden Bits weniger Zyklen zu brauchen als bei > dauernd wechselnden Bits, als ob es intern so nach > "IF(differentStatus)Switch" ablaufen würde. zeige dafür bitte brauchbaren code - wo wird denn 01010101 gesetzt? > Dennoch brauchen die outs je nach Bitmuster verschieden lange.... nein, ein out brauch immer gleich lange. Die Frage ist ob ein out immer das richtige ist. Zeige eine komplette Funktion und den Aufruf dafür.
Gast
#4092515
>Sieht doch für mich als Laie eigentlich genau richtig aus. Dennoch >brauchen die outs je nach Bitmuster verschieden lange... Out ist out! Ob jetzt 8-mal nix 0x00 oder 8-mal was 0xff rausgeschaufelt wird, ist dem Befehl gleich.
Christian S. schrieb: > uint8_t off = PORTB; > uint8_t on = PORTB | (1<<PORTB4); > > if (bla) PORTB = on; else PORTB = off; > if (bla) PORTB = on; else PORTB = off; Dieser Code ist Schwachsinn. Die Variable off enthält den aktuellen Zustand von PORTB, die Variable on enthält den aktuellen Zustand, wobei zusätzlich PB4 gesetzt ist. Wenn aber das Bit einmal gesetzt wurde, ist es auch beim nächsten mal in der Variablen off gesetzt. Wenn, dann muss das so heißen:
1 | |
2 | |
3 | |
Aber zurück zur eigentlichen Frage, nämlich zu den verschieden langen Abarbeitungszeiten: Es liegt nicht an der Portzuweisung, sondern an der Abarbeitung der if-Statements. Je nachdem, welche Bedingung TRUE ist, sind verschieden viele ifs durchlaufen worden. Das braucht unterschiedlich lange Zeiten. Abhilfe: Eine Tabelle. Vielleicht auch ein switch.
Gast
#4092535
1 | |
2 | |
3 | |
4 | |
Im else-Zweig ergibt sich immer PORTB = PORTB; Soll das so sein?
Gast
#4092545
Noch besser: Verwendung von Timer-Output-Compare. Das geht zwar nur mit dezidierten Timer-Pins, dafür kannst Du Dir aber auch sicher sein, daß da Timing passt. Bei Deiner Software-Lösung darfst Du entweder keine Interrupts verwenden oder Du musst sie für die Dauer des Pulses ausschalten. Gruß, Stefan
Gast
#4092562
Es gibt die Möglichkeit den Versatz durch die unterschiedlichen Laufzeiten durch das auffüllen mit NOPs auszugleichen. In der Praxis artet das aber schnell in einen Job für den guten, alten Sisyphos aus. Soweit mir bekannt benötigen die einfachen out-Befehle 1 Tackt Zyklus, ein bedingter Sprung ohne Verzweigung ebenfalls einen Tackt und bei Verzweigung 2 Tackte.
Mittlerweile habe ich das Problem gefunden. Hier nochmal der Code, auf den es ankommt: sbrs r24, 1 rjmp .+4 out 0x18, r25 rjmp .+2 out 0x18, r18 Das Problem ist, dass die rjmps manchmal vor und manchmal nach dem out ausgeführt werden, was das Timing zerstört. Ich habe es jetzt durch nops gelöst, aber das kostet mich insgesamt 3 Takte. Kann man sich diesen Iftest irgendwie sparen? Irgendwie sowas wäre schön: PORTB = Bit 0 von byte X an Stelle PORTB4 packen PORTB = Bit 1 von byte X an Stelle PORTB4 packen PORTB = Bit 2 von byte X an Stelle PORTB4 packen PORTB = Bit 3 von byte X an Stelle PORTB4 packen PORTB = Bit 4 von byte X an Stelle PORTB4 packen PORTB = Bit 5 von byte X an Stelle PORTB4 packen PORTB = Bit 6 von byte X an Stelle PORTB4 packen PORTB = Bit 7 von byte X an Stelle PORTB4 packen Es geht einfach darum, einen UART Sender in Software zu implementieren. Dient für mich als Übung.
Christian S. schrieb: > Es geht einfach darum, einen UART Sender in Software zu implementieren. Benutze doch einen Timer dafür. Oder willst Du gar 115200 Baud oder mehr in Software hinbekommen?
Gast
#4092618
> PORTB = Bit 4 von byte X an Stelle PORTB4 packen
Sollte dir diese Zeile nicht zu denken geben?!
Gast
#4092626
mich wunder das es überhaupt ein out gibt. Du willst doch nur ein bit setzen. Mit out blockierst du den ganzen Port für andere dinge. Und bei einen Soft-Uart brauchst du eh pausen. Damit spielt das Timing gar keine so grosse rolle.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
damit sollte es schon funktionieren, die schleife könnte man auch noch aufdröseln aber da man eh warten muss sehen ich kaum sinn drin. In diesem code sollte auch kein OUT mehr vorhanden sein. Wie schnell willst du denn übertragen?
Gast
#4092627
Christian S. schrieb: > Mittlerweile habe ich das Problem gefunden. Das Problem ist klar erkennbar. Wenn ich Dir ungebeten einen Rat geben darf, fange erst mal an C zu lernen, eine LED zu toggeln und das Datenblatt zu lesen. So in einem halben Jahr vielleicht schreibst Du mal eine Software UART. Das bisher gezeigt ist, mit Verlaub, grosser Murks. :-)
Christian S. schrieb: > Es geht einfach darum, einen UART Sender in Software zu implementieren. > Dient für mich als Übung. Hmmm... und warum schiebst du die Bits nicht einfach direkt raus? BST BLD OUT ... usw, insgesamt 8 Mal Dauert immer genau gleich lang, es sind keine Abfragen und keine Sprünge drin.
Ich bin jetzt erfolgreich bei 1 MBit mit dem internen 8 MHz Resonator und will mal sehen ob 2 möglich sind. Dazu muss jedoch der IF-Test weg. Ich denke, aufgrund mancher Äusserungen kann ich auf diesem hohen Niveau keine Hilfe erwarten. Kein Problem, hab bisher alle meine Problem auch selbst lösen können. Dauert nur etwas länger ^^ Das mit BST und BLD könnte echt mal eine Möglichkeit sein. Habe mich immer gefragt, was dieser blöde 1 Bit Speicher soll. Danke :)
Christian S. schrieb: > Ich bin jetzt erfolgreich bei 1 MBit mit dem internen 8 MHz Resonator > und will mal sehen ob 2 möglich sind. Sollte mit BST,BLD,OUT locker klappen bis 2,666 Mbps.
Wenn Du solche Geschwindigkeiten anstrebst (1 Bitlänge = 4 Taktzyklen), solltest Du dich mit (Inline-)Assembler beschäftigen. Die von Markus Weber vorgeschlagene BST / BLD -Lösung schafft die Geschwindigkeit. Der Empfang wird noch lustig, da Du die fallende Flanke des Startbits auf einen Taktzyklus genau erkennen must, und nur 6 Takte bis zum Abtasten des ersten Datenbits hast. Mit freundlichen Grüßen - Martin
Gast
#4092648
Christian S. schrieb:
Das wirst Du sicher schaffen. Scheinst genügend hartnäckig zu sein. Du
gehst halt einen langen, steinigen Umweg. Schneller kämst Du zum Ziel,
wenn Du von vorne anfangen würdest.
Aber gut. Jedem seine Herausforderung. Viel Erfolg.
Es geht übrigens auch noch schneller: LSR OUT ... 8 Mal. -> 4 Mbps Aber dann wirds etwas schmutzig, weil du vom betreffenden Port nur Bit 0 für die Ausgabe benutzen kannst. Die übrigen Pins tragen nur Bitabfälle nach draußen. :-) Was natürlich nichts macht, wenn die übrigen Pins des Ports als Eingänge verwendet werden. Dann schaltet man nur die Pullups – wenn überhaupt, denn bei manchen neueren AVR gibts dafür ja ein eigenes Pullup-Register. Ach so: Manche AVR können auch mit 16 MHz internem Takt betrieben werden (z.B. ATtiny85, ATtiny861A). Vielleicht hilft dir das, die Geschwindigkeit noch weiter zu erhöhen...
Christian S. schrieb: > Ich bin jetzt erfolgreich bei 1 MBit mit dem internen 8 MHz Resonator Ist das eine Art Wettbewerb? Ansonsten ist es eher unverständlich, warum man für derartige Geschwindigkeiten nicht auf die vorhandene Hardware zurückgreift.
Jörg Wunsch schrieb: > Ansonsten ist es eher unverständlich, warum man für derartige > Geschwindigkeiten nicht auf die vorhandene Hardware zurückgreift. Öhm, ja, seh ich genauso. :-) Christian schreibt oben ja: "Dient für mich als Übung". Vielleicht plant er auch irgendwas Seltsames und will Worte mit 4 oder 10 bit Länge senden, dann wirds mit der Standard-Hardware auch wieder kompliziert.
Gast
#4092957
Christian S. schrieb: > Irgendwie sowas wäre schön: > > PORTB = Bit 0 von byte X an Stelle PORTB4 packen > PORTB = Bit 1 von byte X an Stelle PORTB4 packen > PORTB = Bit 2 von byte X an Stelle PORTB4 packen > PORTB = Bit 3 von byte X an Stelle PORTB4 packen > PORTB = Bit 4 von byte X an Stelle PORTB4 packen > PORTB = Bit 5 von byte X an Stelle PORTB4 packen > PORTB = Bit 6 von byte X an Stelle PORTB4 packen > PORTB = Bit 7 von byte X an Stelle PORTB4 packen > > Es geht einfach darum, einen UART Sender in Software zu implementieren. > Dient für mich als Übung. Dann übe es bitte in einer Sprache, mit der du volle Kontrolle über das Timing hast. C ist keine solche Sprache, Assembler schon. Übrigens hast du einen Assembler, ein C-Compiler ist schließlich auch nur ein aufgebohrter Assembler, kann aber immer noch native Assembler-Instruktionen verstehen. Was nun dein Problem betrifft, geht die schnellste Lösung so (Byte x sei in Register R24, R16 sei unbenutzt/gesichert): cli ; 1 in R16,PORTB ; 1 cbr R16,1<<PORTB4 ; 1 Startbit out PORTB,R16 ; 1 bst R24,0 ; 1 bld R16,4 ; 1 out PORTB,R16 ; 1 bst R24,1 ;... bld R16,4 out PORTB,R16 bst R24,2 bld R16,4 out PORTB,R16 bst R24,3 bld R16,4 out PORTB,R16 bst R24,4 bld R16,4 out PORTB,R16 bst R24,5 bld R16,4 out PORTB,R16 bst R24,6 bld R16,4 out PORTB,R16 bst R24,7 bld R16,4 out PORTB,R16 sbr R16,1<<PORTB4 ; 1 Stopbit sei ; 1 out PORTB,R16 ; 1 Jedes Bit dauert drei Takte, die gesamte Routine 31 Takte. Die Bitrate entspricht einem Drittel des Systemtakts. Und, bevor du fragst: langsamer geht immer, das ist leicht. Schwierig wäre bloß noch schneller. Das geht, zumindest beim AVR8, nichtmal über die eingebaute UART-Hardware. Naja, bei den neueren kann man sie im SPI-Mode betreiben und erreicht dann bei der Bitrate sogar die Hälfte des Systemtaktes und das sogar ohne jegliche Interuptsperre.
Gast
#4092981
c-hater schrieb: > Und, bevor du fragst: langsamer geht immer, das ist leicht. Schwierig > wäre bloß noch schneller. auch kein Problem. Wenn genug Flash vorhanden ist.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
Gast
#4093031
Peter II schrieb: > [c] Da lach ich drüber... > switch( data ) { OMG. Switch mit 256 Zweigen. Selbst intelligente Compiler können das bestenfalls auf 8 Verzweigungen eindampfen (binärer Baum). Verzweigungen sind der Tod jeglichen getimeten Codes, wenn man sie einen C-Compiler machen läßt. Abgesehen davon kosten sie auch immer überproportional viel Rechenzeit. > PORTB |= (1<<pb4); //start > PORTB &= ~(1<<pb4); //bit0 > PORTB &= ~(1<<pb4); //bit1 > PORTB &= ~(1<<pb4); //bit2 > PORTB &= ~(1<<pb4); //bit3 > PORTB &= ~(1<<pb4); //bit4 > PORTB &= ~(1<<pb4); //bit5 > PORTB &= ~(1<<pb4); //bit6 > PORTB &= ~(1<<pb4); //bit7 > PORTB |= (1<<pb4); //stop Gute Compiler werden das als sbi/cbi übersetzen, also zwei Takte pro Bit brauchen. Schlechte Compiler oder auch gute Compiler mit "ungünstig" eingestellter Optimierung können da leicht auch mal 3 oder sogar 5 Takte pro bit draus machen... Abgesehen von diesen Betrachtungen ist der Code aber auch noch falsch. Das Startbit muß natürlich Low sein, aber das würde ich hier gern als Flüchtigkeitsfehler verbuchen wollen und nicht weiter diskutieren. Worüber ich eher diskutieren würde: der Ansatz mit dem präparierten Code natürlich auch in Assembler möglich. Bloß würde ein gelernter Asm-Programmierer natürlich keinen binären Baum verwenden, sondern einen berechneten Sprung. Das wäre natürlich auch in C möglich. Aber der Vergleich der beiden Routinen zeigt dann ganz deutlich, was ich an C so sehr hasse, den Bombast an Syntax, den man benötigt, um einfachste Sachverhalte auszudrücken, ohne dass man in der Compilerausgabe vor lauter Warnungen die Fehler nicht mehr sehen kann...
Gast
#4093043
c-hater schrieb: > OMG. Switch mit 256 Zweigen. Selbst intelligente Compiler können das > bestenfalls auf 8 Verzweigungen eindampfen (binärer Baum). sie machen einfach eine Sprungtabelle draus, habe ich schon beim GCC gesehen. Sind dann bloss 2 oder 4 takte. > Gute Compiler werden das als sbi/cbi übersetzen, also zwei Takte pro Bit sbi/cbi brauchen doch nur 1 Takt? > Schlechte Compiler oder auch gute Compiler mit "ungünstig" Compiler die nicht mal cbi/sbi hinbekommen, kann man eh nicht ernsthaft einsetzten, damit würde ein Großteil der Programme nicht mehr laufen. Man kann sich schon darauf verlassen sie es können. > Abgesehen von diesen Betrachtungen ist der Code aber auch noch falsch. > Das Startbit muß natürlich Low sein, aber das würde ich hier gern als > Flüchtigkeitsfehler verbuchen wollen und nicht weiter diskutieren. ich war mir auch wegen der Reihenfolge der bits nichts sicher. Es ging ja nur ums Prinzip.
Peter II schrieb: > sbi/cbi brauchen doch nur 1 Takt? Hier liegst Du falsch, es sind 2 Takte. Hast es vermutlich mit SBR / CBR verwechselt, die brauchen tatsächlich nur einen Takt, arbeiten aber nur mit den CPU-Registern, könnten aber auch verwendet werden, ohne daß es langsamer wird:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
-> 2 Takte pro ausgegebenem Bit Wer's richtig schnell will, berechnet die auszugebenden Bitmuster im Vorraus, und schreibt sie nur noch hintereinander raus:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
-> 1 Takt pro ausgegebenem Bit Mit freundlichen Grüßen - Martin
Gast
#4093072
Martin Schlüter schrieb: > Hier liegst Du falsch, es sind 2 Takte. Hast es vermutlich mit SBR / CBR > verwechselt, http://www.atmel.com/images/doc0856.pdf seite 123 Cycles : 2 Cycles XMEGA: 1 Cycles Reduced Core tinyAVR:1 naja, wir hatte beide recht.
Gast
#4093077
Peter II schrieb: > sie machen einfach eine Sprungtabelle draus, habe ich schon beim GCC > gesehen. Sind dann bloss 2 oder 4 takte. Vier mag ich vielleicht noch glauben, zwei nimmer. Bis zum Beweis des Gegenteils würde ich das als offensichtliche Schutzbehauptung eines C-Gäubigen einstufen. Bitte Code vorlegen, der diese Behauptung beweisen kann. Bitte mit exakter Angabe von Compilerversion und verwendeten Optimierungsoptionen. Womit wir gleich beim nächsten Problem wären, der C-Kompatibilitätslüge... > sbi/cbi brauchen doch nur 1 Takt? Nein, zwei. Ziehe bitte die Lektüre des AVR "instruction set reference manual" in Betracht, bevor du Aussagen über das Timing von Instruktionen triffst. Es ist ja wirklich nicht schwer, die Instruktion des Interesses im Inhaltsverzeichnis anzuklicken und dann bis ganz unten runterzuscrollen, wo Atmel schamhaft die wichtigsten Infos hinschreibt...
Gast
#4093085
c-hater schrieb: >> sbi/cbi brauchen doch nur 1 Takt? > > Nein, zwei. Ziehe bitte die Lektüre des AVR "instruction set reference > manual" in Betracht, bevor du Aussagen über das Timing von Instruktionen > triffst. Es ist ja wirklich nicht schwer, die Instruktion des Interesses > im Inhaltsverzeichnis anzuklicken und dann bis ganz unten > runterzuscrollen, wo Atmel schamhaft die wichtigsten Infos > hinschreibt... habe ich gemacht und geschrieben, das wir beide recht haben!
@Peter II (Gast): Da muß ich Dir Recht geben. Hatte es selber nicht nachgesehen, mache am meisten mit den ATmegas, und da sind es halt 2 Takte. Beim Xmega ist da wohl Einiges gemacht worden, da gibt es recht viele Unterschiede, z.B. auch bei den SRAM-Zugriffen. Mit freundlichen Grüßen - Martin
Gast
#4093113
c-hater schrieb: > OMG. Switch mit 256 Zweigen. Selbst intelligente Compiler können das > bestenfalls auf 8 Verzweigungen eindampfen (binärer Baum). Sprungtabelle mit Funktionspointers ist eine andere Variante.
Gast
#4093114
Peter II schrieb: > habe ich gemacht und geschrieben, das wir beide recht haben! Ja, ich wiederum habe das geschrieben, bevor ich deine diesbezüglich Antwort gelesen hatte.->Typisches Problem asynchroner Kommunikation, kein böser Wille. Übrigens: Ich wußte tatsächlich nicht, daß die XMegas die Sache in einem Takt abfackeln können, bei den Dingern stellt sich ja dank reichlich verfügbarer und potenter Hardware nur äußerst selten das Problem, etwas derartiges in Software abhandeln zu müssen, bei mir bisher halt noch nie. Trotzdem eine schöne Sache, denn ich habe wirklich etwas neues in diesem Thread gelernt, was ich vielleicht irgendwann mal brauchen kann. Und sei es nur zur Herstellung der Kompatibilität für Stücken gebrauchter Software...
c-hater schrieb: > Vier mag ich vielleicht noch glauben, zwei nimmer. Bis zum Beweis des > Gegenteils würde ich das als offensichtliche Schutzbehauptung eines > C-Gäubigen einstufen. Gell, das einzig Gute an C ist der Inline-Assembler. ;-) Ich geb zu, es gibt Momente, da seh ich das genauso wie du. Anscheinend klappt es tatsächlich 1:1 mit dem CPU-Takt. Allerdings sind dann die Stoppbits jeweils mehr als 10 Takte lang, was natürlich die DÜ-Geschwindigkeit in den Keller zieht. Oder gibt es eine bessere/schnellere Lösung?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
Gast
#4093222
Markus Weber schrieb: > Gell, das einzig Gute an C ist der Inline-Assembler. ;-) wobei die Frage ist warum nicht dafür C verwenden, habe jetzt nichts da zu testen was da rauskommt.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
Besten Dank für die vielen umfangreichen Antworten. Das sind ca. 10 mal mehr Informationen, als ich erhofft habe. Damit kann ich mich jetzt sehr gut auseinandersetzen :)
Gast
#4093246
könnte das schneller sein?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
Peter II schrieb: > könnte das schneller sein? Ich glaube, du hast Recht! Quasi zweifach indirekt (indirekt mit anschließender Sprungtabelle) ist da wahrscheinlich schneller. Macht dann eine Stoppbitlänge von mehr als 7 Takten. Immer noch nicht gut, aber deutlich besser.
Warum hoffe ich bei solchen Diskussionen immer, dass der Programmierer des Flugzeugs, in dem ich gerade sitze, etwas mehr Erfahrung hatte? Jörg Wunsch hatte es mal kurz angesprochen, wie es Profis machen: sie lesen das Datenblatt ihres Controllers und nehmen eine Hardwarekomponente, die so eine Übertragung ohne Prozessorlast abhandeln kann... Mit dem SPI Interface kann ich z.B. ganz problemlos 4MBit/s bei 8MHz Takt erreichen. Und habe nebenher Zeit, das nächste Byte vorzubereiten.
Gast
#4093263
Lothar Miller schrieb: > Warum hoffe ich bei solchen Diskussionen immer, dass der Programmierer > des Flugzeugs, in dem ich gerade sitze, etwas mehr Erfahrung hatte? > > Jörg Wunsch hatte es mal kurz angesprochen, wie es Profis machen: sie > lesen dad Datenblatt ihres Controllers und nehmen eine > Hardwarekomponente, die so eine Übertragung ohne Prozessorlast abhandeln > kann... > Mit dem SPI Interface kann ich z.bB. ganz problemlos 4MBit/s bei 8MHz > Takt erreichen. Und habe nebenher Zeit, das nächste Byte vorzubereiten. wenn es danach geht, hätte wir für die ersten PC spiele auch 10Jahre länger warten müssen. Zum glück gab es damals schon "kreative" Entwickler die alles aus der Hardware geholt haben.
Peter II schrieb: > wenn es danach geht, hätte wir für die ersten PC spiele auch 10Jahre > länger warten müssen. Zum glück gab es damals schon "kreative" > Entwickler die alles aus der Hardware geholt haben. Ich denke, da liegst du aber gewaltig daneben. Nicht die Geschwindigkeit war damals das Problem, sondern mangelnder RAM, sowohl bei den uC als auch bei der Videokarten. Ich glaube mein Vater hat sein Tandy damals 2000 DM bezahlt, die Umrüstung von 4KB(!) auf 16KB RAM hat so um die 500DM gekostet.
Gast
#4093498
Marc Vesely schrieb: > Ich denke, da liegst du aber gewaltig daneben. > Nicht die Geschwindigkeit war damals das Problem, sondern mangelnder > RAM, sowohl bei den uC als auch bei der Videokarten. > Ich glaube mein Vater hat sein Tandy damals 2000 DM bezahlt, die > Umrüstung von 4KB(!) auf 16KB RAM hat so um die 500DM gekostet. wenn ich das lesen, klingt es aber nicht nach ram: http://de.wikipedia.org/wiki/Duff%E2%80%99s_Device
Peter II schrieb: > wenn ich das lesen, klingt es aber nicht nach ram: > > http://de.wikipedia.org/wiki/Duff%E2%80%99s_Device ??? Nix aus der Hardware rausgeholt, einen einfachen loop ausgerollt. Und funktioniert auch nur in C, normale Sprachen fallen nicht von einem Switch zum nächsten... Ihr seid alle so schnell wenns heisst c-hater anzuspucken, aber C ist ganz einfach ein Witz von einer Sprache.
Peter II schrieb: > wenn ich das lesen, klingt es aber nicht nach ram: Hat aber nichts mit normalem PC zu tun, sondern mit früher Videobearbeitung. https://de.wikipedia.org/wiki/Lucasfilm Zurück zum Thema des Threads: ich bin gewiss ein großer Verfechter davon, auch bei Controllern möglichst portable Software in einer höheren Programmiersprache zu zimmern. Aber wenn man wirklich auf den Takt genau etwas machen will, und keinerlei Hardware dafür abstellen kann (nichtmal einen Timer), dann bleibt in der Tat nur das händische Auszählen der Takte in einem Stück Assemblercode – egal, ob man das nun zum eigenen Zeitvertreib oder aus echter Notwendigkeit heraus tun möchte.
Gast
#4093566
Marc Vesely schrieb: > Nix aus der Hardware rausgeholt, einen einfachen loop ausgerollt. damit konnte mehr Daten als sonst mit der gleichen CPU verarbeitet werden. Das verstehe ich schon unter, mehr als der gleichen Hardware rausgeholt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.