Hallo zusammen, ich benutze AVR Studio 4 und habe ein Problem mit der Simulation. Ich habe in meinem Programm einen TWI Bus. In der Simulation bleibt das Programm immer beim Initialisieren des TWI hängen weil sich der Status nicht ändert (weil ja garkein physikalischer Bus vorhanden ist). Kann ich irgendwie abfragen im Programm abfragen, ob das Programm in der Simulation läuft oder in realen Microprozessor?
Du könntest durch Soft-TWI antesten, ob ein bekanntes Gerät am TWI Bus antwortet. Im Emulator wird das nicht der Fall sein.
Ja das könnte ich vielleicht. Dachte es gäbe eine einfache Variante das herauszufinden.
Hi Schon mal die Known Issues (Simulator Hilfe) gelesen? Unsupported modules Simulation of TWI, USI and analog peripheral is not yet implemented. All instructions, interrupts and other peripherals are supported. See the Simulator Modules for more information. MfG Spess
Keine Ahnung ob das noch funktioniert. Mit den älteren Versionen vom AVR Studio (nicht Atmel Studio) konnte man mit dem HAPSIM dem Simulator prima nicht vorhandene Hardware vortäuschen. http://www.helmix.at/hapsim/
spess53 schrieb: > Hi > > Schon mal die Known Issues (Simulator Hilfe) gelesen? > > Unsupported modules > > Simulation of TWI, USI and analog peripheral is not yet implemented. All > instructions, interrupts and other peripherals are supported. See the > Simulator Modules for more information. Ich will ja garnicht TWI simulieren. ich will nur im Programmcode eine Unterscheidung machen, ob das Programm in der realen hardware oder im Simulator läuft. Dann kann ich im Simulationsbetrieb die Aufrufe der nicht simulierbaren Module abschalten.
Gad Zinkler schrieb: > Dachte es gäbe eine einfache Variante das herauszufinden. Man definiert einfach ein entsprechendes Symbol, ähnlich wie das verbreitet verwendete DEBUG-Symbol. Das kann man dann überall im Programm problemlos abfragen und entsprechenden Code erzeugen. Natürlich gibt es dann letztlich zusätzlich zu den üblichen Debug- und Releasebuilds noch ein drittes Build. Blöderweise wird das von den üblichen IDEs nicht so einfach unterstützt, dafür ist schon ein wenig mehr Handarbeit erforderlich. Aber von den Build-Problemen mal ganz abgesehen: Man muß natürlich sehr genau wissen, was man da im Detail tut, damit der erfolgreiche Lauf eines SimDebug-Builds im Simulator noch irgendeine Aussagekraft für die Lauffähigkeit des Releasebuilds auf bare metal besitzt... In C, besonders wenn "C" eigentlich nur deshalb benutzt wird, um zusammengeklauten, nicht verstandenen Code fremder Leute benutzen zu können, wird das meistens eher nix werden... Ich rechne dich zu dieser Kategorie, denn Leute die wirklich C können, wären sicher auch ohne ein Posting in einem Forum von ganz allein auf diese sehr naheliegende Idee gekommen...
Karl Heinz schrieb: > Keine Ahnung ob das noch funktioniert. > Mit den älteren Versionen vom AVR Studio (nicht Atmel Studio) konnte man > mit dem HAPSIM dem Simulator prima nicht vorhandene Hardware > vortäuschen. > > http://www.helmix.at/hapsim/ Danke für den Tip. Zum Glück benutze ich noch AVR Studio 4.18 und der Simulator unterstützt bis V4.19 :-) Habe den hapsim installiert und gestartet. Allerdings kann ich kein Device auswählen weil die Liste leer ist. Woran kann das liegen?
c-hater schrieb: > Gad Zinkler schrieb: > >> Dachte es gäbe eine einfache Variante das herauszufinden. > > Man definiert einfach ein entsprechendes Symbol, ähnlich wie das > verbreitet verwendete DEBUG-Symbol. Das kann man dann überall im > Programm problemlos abfragen und entsprechenden Code erzeugen. > > Natürlich gibt es dann letztlich zusätzlich zu den üblichen Debug- und > Releasebuilds noch ein drittes Build. Blöderweise wird das von den > üblichen IDEs nicht so einfach unterstützt, dafür ist schon ein wenig > mehr Handarbeit erforderlich. > > Aber von den Build-Problemen mal ganz abgesehen: Man muß natürlich sehr > genau wissen, was man da im Detail tut, damit der erfolgreiche Lauf > eines SimDebug-Builds im Simulator noch irgendeine Aussagekraft für die > Lauffähigkeit des Releasebuilds auf bare metal besitzt... > > In C, besonders wenn "C" eigentlich nur deshalb benutzt wird, um > zusammengeklauten, nicht verstandenen Code fremder Leute benutzen zu > können, wird das meistens eher nix werden... > > Ich rechne dich zu dieser Kategorie, denn Leute die wirklich C können, > wären sicher auch ohne ein Posting in einem Forum von ganz allein auf > diese sehr naheliegende Idee gekommen... da muss ich dich leider enttäuschen, ich gehöre nicht zu dieser Kategorie. Habe allerdings ganz vergessen das es hier viele gibt die nur in C programmieren und das mit geklauten Programmcodes. ich programmiere alles selbst und zwar in Assembler! Von daher weiss ich ganz genau, welche Stellen meines Codes beim Simulator ausgelassen werden sollen. Dann werde ich mir halt eine Hilfsvariable machen und compiliere dann das Programm einmal zum simulieren und einmal für die richtige Hardware. So eine Hilfsvariable habe ich ohnehin schon um zu unterscheiden, ob ich Bootloader oder Firmware oder beides compilieren will. Also ansich nichts neues für mich, ich wollte es nur hier umgehen...
Gad Zinkler schrieb: > da muss ich dich leider enttäuschen, ich gehöre nicht zu dieser > Kategorie. Da hast du was falsch verstanden. Das wäre für mich keinesfalls eine Enttäuschung, sondern eher ein Licht am Ende eines Tunnels... > ich programmiere alles selbst und zwar in Assembler! > Von daher weiss ich ganz genau, welche Stellen meines Codes beim > Simulator ausgelassen werden sollen. Sehr gut. > Dann werde ich mir halt eine Hilfsvariable machen Hier befallen mich allerdings schon wieder die ersten Zweifel. Was um alles in der Welt ist in Asm eine "Variable"??? Sicher nicht das, was ich meine (und was man sinnvollerweise benutzen würde). Also sowas: .equ SIMDEBUG=1 oder für's Release .equ SIMDEBUG=0 Und das ist dann eben nicht variabel, weder zur Compilezeit und schon garnicht zur Laufzeit. Zur Laufzeit ist es idealerweise nichtmal mehr vorhanden... Wenn man z.B. will, daß im Simulator die Meßwerte einer ADC von PINA kommen (um diesen mit Stimulidaten füttern zu können), im Release aber von ADCH, dann schreibt man: .IF SIMDEBUG in reg,PINA .ELSE in reg,ADCH .ENDIF Da ist nix variabel. Am ehesten entspricht das Symbol SIMDEBUG noch einer Konstanten, denn man kann es im Code auch als solche verwenden. Es ist aber keine echte Konstante, denn im fertigen Code kommt sie u.U. (z.B. bei obigem Beispiel) überhaupt nicht mehr vor. Sie ist also nur während des Übersetzens des Codes existent. Sowas nennt man eine "Entwurfszeitkonstante". Und die stellt bezüglich aller ihrer Eigenschaften so ziemlich das genaue Gegenteil zu einer Variablen dar...
c-hater schrieb: > Hier befallen mich allerdings schon wieder die ersten Zweifel. Was um > alles in der Welt ist in Asm eine "Variable"??? Sicher nicht das, was > ich meine (und was man sinnvollerweise benutzen würde). > > Also sowas: > > .equ SIMDEBUG=1 > oder für's Release > .equ SIMDEBUG=0 > > Und das ist dann eben nicht variabel, weder zur Compilezeit und schon > garnicht zur Laufzeit. Zur Laufzeit ist es idealerweise nichtmal mehr > vorhanden... > > Wenn man z.B. will, daß im Simulator die Meßwerte einer ADC von PINA > kommen (um diesen mit Stimulidaten füttern zu können), im Release aber > von ADCH, dann schreibt man: > > .IF SIMDEBUG > in reg,PINA > .ELSE > in reg,ADCH > .ENDIF > > Da ist nix variabel. Am ehesten entspricht das Symbol SIMDEBUG noch > einer Konstanten, denn man kann es im Code auch als solche verwenden. > > Es ist aber keine echte Konstante, denn im fertigen Code kommt sie u.U. > (z.B. bei obigem Beispiel) überhaupt nicht mehr vor. Sie ist also nur > während des Übersetzens des Codes existent. Sowas nennt man eine > "Entwurfszeitkonstante". Und die stellt bezüglich aller ihrer > Eigenschaften so ziemlich das genaue Gegenteil zu einer Variablen dar... Oh man du bist ja so schlau... Entschuldigung das ich fälschlicherweise eine "Entwurfszeitkonstante" als Variable bezeichnet habe. Trotzdem weiss ich sehr wohl mit solchen Konstanten umzugehen. Habe ja nicht erst seit heute folgenden Code in meinem Program .IF EN_FIRMWARE == 1 ;boot loader into boot section .org NRWW_START_ADDR .include "Boot.asm" .ENDIF
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.