Ansonsten ist’s halt ein Fehler in Zeile 16, von der keiner weiß, wo sie ist.
Die markierte Zeile im Bild enthält allerdings so viele Fehler, da weiß man gar nicht, wo man anfangen soll. Das fängt damit an, daß Code in C nur innerhalb von Funktionen stehen darf.
lass stecken: Das ist sinnlos und frustierend (ich warte immer noch auf den Essay ueber die state-Machine [https://www.mikrocontroller.net/topic/552487#7378833]).
KEY_PIN" scheint PINB zu sein; kennt der ungenannte Microcontroller
dieses Register?
Warum siehst Du Dir nicht auch die Warnungen an?
Oh, hatte so ein Tunnelblick und hab mich nur auf die Errors gestürtzt.
Kann aber leider nichts mit den Warnmeldungen anfangen - ist mir zu Hoch.
Bin vom AVR8ASM üben, zu neuerdings, Arduino gewechselt.
Es ist ein ATmega2560, dachte es würde auffallen, dass ich dies in der obersten Zeile der IDE-Screenschots mit ausgeschnitten habe.
KEY_PIN habe ich auf PINE umdeklariert und nutze E0, E1 und E2, auf einem Arduino-Mega-2560-Klone-Board. PINB7 bis B4 hätte auch zur Verfügung gestanden, wobei B7 schon mit der Build-In-LED belegt ist.
Ansonsten ist’s halt ein Fehler in Zeile 16, von der keiner weiß, wo sie
ist.
Da wo der weiße Rahmen im Code-Bild drumm ist. Kann man es einstellen, dass die Zeilennummern mit angezeigt werden und wenn ja, dann am besten zeigen wie.
Die markierte Zeile im Bild enthält allerdings so viele Fehler, da weiß
man gar nicht, wo man anfangen soll. Das fängt damit an, daß Code in C
nur innerhalb von Funktionen stehen darf.
1
//uint8_t i;
2
3
i=key_state^~KEY_PIN;
4
5
//key_press |= key_state & i;
Ich dachte dies wäre wie beim Arduino-Gedöns eine Initialisierung ?
Hab dass Andere ja schon auskommentiert, damit zunächst nur dieser Fehler auftritt.
Will mir anschauen, wie der Assemblercode nach der Compilierung dieser Zeile aussieht.
Ich dachte dies wäre wie beim Arduino-Gedöns eine Initialisierung ?
Ist es für den Compiler auch, was dann zur gezeigten Fehlermeldung
führt.
Danke, war der entscheidene Hinweis :
" Das fängt damit an, daß Code in C nur innerhalb von Funktionen stehen darf."
So, jetzt also mal gucken, wie man sich den AVR8ASM-Code ansehen kann.
Ach, geht das jetzt, dass man die Zeilennummern einblenden kann ?
Und noch was, was für eine Platzverschwendung, da könnte man besser die Textlänge nutzen, damit es nicht zu solchen vorzeitigen Zeilenumbrüchen kommt ( sieh Screenshot ).
Kann man es einstellen, dass die Zeilennummern mit angezeigt werden...
Ja.
...und wenn ja, dann am besten zeigen wie.
Menue > Tools > Options > Text Editor > All Languages > Haken bei "Line Numbers"
DAS müßtes du eigentlich auch alleine finden können.
rhf
P.S.
Ich gebe dir den gleichen Rat, der dir schon von vielen anderen gegeben worden ist:
LERNE C UND BESCHÄFTIGE DICH MIT DER BEDIENUNG DEINER WERKZEUGE
P.S.
Ich gebe dir den gleichen Rat, der dir schon von vielen anderen gegeben
worden ist:
LERNE C UND BESCHÄFTIGE DICH MIT DER BEDIENUNG DEINER WERKZEUGE
Ganz offensichtlich ist er nur am generierten Asm-Code interessiert.
Dazu ist alles andere nur notwendiges Übel.
Und wie exakt sieht das aus, was Du da gemacht hast?
Zeige nicht Schnipsel von Screenshots, zeige den vollständigen(!) und
exakten Code, den Du nutzt.
Als Dateianhang, nicht in den Text reinkopiert.
Es ist nicht einfach an alles zu denken, was Andere evtl. brauchen.
Aber eigentlich kein Problem, man kann ja nachliefern, falls es nötig ist und Sinn macht.
So, so, Leute die dir helfen sind also Witzbolde... Gut zu Wissen.
Ich komm auch gerne schnell voran.
Im Übrigen gibt es in jedem grafischen Texteditor unter "Einstellungen", "Optionen" oder ähnlichen Begriffen die Möglichkeit der Konfiguration. Und genau da schaut man als erstes rein wenn man Anpassungen vornehmen möchte. Hättest du das getan, hättest du die obige Einstellung in spätestens einer Minute gefunden, anstatt darauf zu warten das dir jemand hilft. So viel zu Thema "schnell voran kommen".
Ich verstehe den guten, alten Hannes Luxx, dass er bei AVR8ASM bis zum
Ende geblieben ist.
Ja, stimmt früher war alles besser...
Es wäre für dich alles viel einfacher, wenn du die dir gegebenen Ratschläge ernst nehmen und befolgen würdest. Stattdessen versuchst du immer wieder deine alten Assembler-Arbeitsweisen auch unter C b.z.w. (Arduino)-C++ beizubehalten. Und obwohl das immer wieder in die Hose geht, lässt du nicht davon ab, unbegreiflich.
Du solltest dir mal die Frage stellen wo das eigentliche Problem liegt.
was mache ich falsch beim einfachen Paste & Copy von diesem Code ?
Das Du nicht mal "copy & paste" (und damit meine ich den vollständigen Code) einfach richtig machen kannst?
Man legt das Projekt für den ATMega2560 an, kopiert ALLES in das Edit-Fenster (was drin ist kann weg) und passt - nachdem man das Datenblatt studiert hat - genau 2 Zeilen an, die als Fehler ausgewiesen werden:
1
TCCR0A=(1<<CS02)|(1<<CS00);// divide by 1024
2
...
3
TIMSK0|=1<<TOIE0;// enable timer interrupt
Dann wird maximal noch
Warning #warning kein F_CPU definiert [-Wcpp]
angemeckert, was man im Code anpassen kann oder in den Projekt-Einstellungen einstellt.
was mache ich falsch beim einfachen Paste & Copy von diesem Code ?
Das Du nicht mal "copy & paste" (und damit meine ich den vollständigen
Code) einfach richtig machen kannst?
Man legt das Projekt für den ATMega2560 an, kopiert ALLES in das
Edit-Fenster (was drin ist kann weg) und passt - nachdem man das
Datenblatt studiert hat - genau 2 Zeilen an, die als Fehler ausgewiesen
werden:
Lesen ist SO retro und Wissenuebertragung ist ueberbewertet.
Th.
P.S.: Leider auch bei Studenten (oder Studierenden).
So, so, Leute die dir helfen sind also Witzbolde... Gut zu Wissen.
In diesem Fall schon.
Dir ist wohl nicht klar, wie komplex diese IDE mit all ihren Einstellungen für einen Hobbyisten ist. Da gibt es für mich tausende Möglichkeiten.
Als Beispiel in der xyz.lss-Datei, ist mir erst beim Markieren aufgefallen, dass da noch etwas steht.
Dann aus versehen oder wie auch immer, ein Klick oder was weiß ich, und schon erkennt man nichts mehr. Zack, dass nächste Problem.
So, jetzt ein anderes Problem.
Kann ich den Compiler irgendwie mitteilen, dass er nur untere ( < r16 ) Register verwenden soll und nicht dass SRAM ?
Siehe den vom Compiler erzeugten AVR8ASM-Code im Anhang ( xyz.txt )
Dir ist wohl nicht klar, wie komplex diese IDE mit all ihren
Einstellungen für einen Hobbyisten ist. Da gibt es für mich tausende
Möglichkeiten.
Als Beispiel in der xyz.lss-Datei, ist mir erst beim Markieren
aufgefallen, dass da noch etwas steht.
Mein Atmel-Studio 7 bzw. der Nachfolger Microchip-Studio 7 hat nach der Installation eine andere Erscheinungsform, nämlich einen Weißen Hintergrund. Ich vermute nun, dass du eine dir angenehmere Form eingestellt hast. Dadurch kann es -wenn nicht alles andere auch angepasst wird- zu solchen "weißer Adler auf weißem Grund"-Effekten kommen. Vielleicht versuchst du mal den eingekreisten Button zu betätigen? Wie gesagt, (m)/(r)eine Vermutung.
Dir ist wohl nicht klar, wie komplex diese IDE mit all ihren
Einstellungen für einen Hobbyisten ist.
Um ein Programm zu schreiben, zu übersetzen und auf den Prozessor zu laden braucht man nur 10% des Atmel-Studios. Und das sind genau die gleichen 10% wie in allen anderen IDEs auch. Außerdem gibt es unzählige Tutorials wie man das Atmel-Studio benutzt. Warum beschäftigst du dich nicht damit?
Als Beispiel in der xyz.lss-Datei, ist mir erst beim Markieren
aufgefallen, dass da noch etwas steht.
Dann aus versehen oder wie auch immer, ein Klick oder was weiß ich, und
schon erkennt man nichts mehr. Zack, dass nächste Problem.
Unter einem frisch installierten Atmel-Studio tritt dieser "Fehler" nicht auf. Ich vermute mal das du da was verstellt hast.
Klicke mal im Menue auf "VAssistX" und deaktiviere mit Klick auf "Enable/Disable Visual Assist" selbigen, vielleicht funktioniert es dann besser.
Kann ich den Compiler irgendwie mitteilen, dass er nur untere ( < r16 )
Register verwenden soll und nicht dass SRAM ?
Wäre es nicht besser erst mal das Programm zum Laufen zu bringen als sich mit den Prozessorregistern zu beschäftigen? Und was glaubst du in der lst-Datei zu finden das dir bei deinen Problemen mit dem C-Programm hilft?
@Bernd:
Lösungen zu Deinem Problem gibts hier nur wenn Du hier feierlich Asm abschwörst :)
Hochsprache hat einfach ihren Preis, so einfach wie bei Assembler und seinen simplen Tools ist die Welt dann nicht mehr. Wenns nicht unbedingt sein muß und Spaß macht bleib dabei. Für kleine 8Bitter langts locker und bewahrt alle Freiheiten.
...
Vielleicht versuchst du mal den eingekreisten Button zu
betätigen? Wie gesagt, (m)/(r)eine Vermutung.
Lieber nicht, denn so wie Roland F. (rhf) mir hier schnell mal auf die Sprünge geholfen hat, hatte es damals jemand Anderes getan, damit ich eben diesen
schwarzen Hintergrund habe.
Aber dein Screenshot zeigt sehr schön, wieviele Einstellungen man vornehmen kann, denn jedes Menü hat wieder ein Menü, mit zig Einträgen usw. usf.
Klicke mal im Menue auf "VAssistX" und deaktiviere mit Klick auf
"Enable/Disable Visual Assist" selbigen, vielleicht funktioniert es dann
besser.
Danke, dieser Highlight-Effekt ist weg und noch Andere, was aber jetzt erstmal egal ist. " Schwarzer Adler auf schwarzem Untergrund " ist immer noch, aber stört erstmal nicht.
Ok, letzter Versuch es zu erklären.
Als Anfänger bzw. Hobbyist, weiß man nicht, dass man sich "nur" auf 10% konzentrieren muss, man stochert wohl eher in den gesamten 100% herum und dies kostet Zeit - Verdammt viel Zeit. War zwischendurch mit PlatformIO auch schon zu Gange ...
Und was glaubst du in der lst-Datei zu finden das dir bei deinen
Problemen mit dem C-Programm hilft?
Sagen wir es mal so.
Da ich keine Ahnung von C habe, mir AVR8ASM zu unübersichtlich war/ist, habe ich gedacht, ich versuchs mal mit der " Künstlersprache ", die dieses Arduino-Gedöns verwendet ( C++ ), was man allerdings auch mit C mischen kann bzw. auf C aufgebaut ist, um mal etwas schneller voran zu kommen.
Mich interessiert halt, was der ATMEL STUDIO 7 C-Compiler für ein AVR8ASM-Code erzeugt. Und nun wieder zu den Fragen die mich interessieren. Ich wiederhole es noch mal, jetzt jedoch ein anderes Beispiel.
So, jetzt ein anderes Problem.
Kann ich den Compiler irgendwie mitteilen, dass er nur untere ( < r16 )
Register verwenden soll und nicht dass SRAM ?
Siehe den vom Compiler erzeugten AVR8ASM-Code im Anhang ( xyz.txt )
Es ist schön zu sehen, dass in C eine Zeile, praktisch, drei Zeilen ASM ersetzt und der Compiler dies fast 1:1 umsetzt, aber eben nicht immer.
Aber dies will ich erst später zeigen, falls man es dem AVR-GCC-Compiler überhaupt beibringen kann Arbeitsregister ( GPR r0 bis r31 ) anstelle von SRAM zu verwenden.
Kann ich den Compiler irgendwie mitteilen, dass er nur untere ( < r16 )
Register verwenden soll und nicht dass SRAM ?
Warum nur sollte man so etwas wollen?
Weil man möchte, das der Code mit maximaler Geschwindigkeit läuft?
Aber dafür ist C definitiv der falsche Ansatz, ganz sicher jedenfalls auf ALLEM was nativ mit weniger als 16Bit hantiert.
Das kann diese Scheiße einfach nicht richtig, weil es ihrem Grundkonzept widerspricht. OK, bei vielen Architekturen wurde nachträglich was drangestrickt, was den negativen Impakt dieser Scheiß-Sprache verringert. Aber das ist halt weder umfassend (für alle 8Bit-Architekturen) noch perfekt passiert.
Für ersteres hätte man nämlich vieles am Sprachstandard ändern müssen. Ist aber nicht passiert. Nachdem diese Seuche erstmal auf die Menschheit losgelassen war, war sie nahezu unabänderlich bezüglich ihrer Grundfesten...
Mich interessiert halt, was der ATMEL STUDIO 7 C-Compiler für ein
AVR8ASM-Code erzeugt. Und nun wieder zu den Fragen die mich
interessieren.
Das einzige was dich interessiert ist Chaos und Aufmerksamkeit!
Du hast keine Ahnung von ASM, C und logischem, strukturiertem Denken und damit Programmieren. Aber viel Interessen an Plappern und Probleme erfinden, die der Rest der Welt nicht hat. Bravo!
Ich hatte den TO auch mal ernst genommen (ich warte immer noch auf einen Essay wg. State Machines Beitrag "Re: Tasterverarbeitung mit ARDUINO-C"), aber seit 2009 angemeldet und 2k7 Beitraege mit wenig Erkenntnisgewinn -> Troll.
Wenn der TO mit etwas Substanz ankommt koennen wir diskutieren.
angemeldet und 2k7 Beitraege mit wenig Erkenntnisgewinn -> Troll.
Nicht ganz. Er ist ein kleiner, nerviger Narzist, der nur Theater macht, um Aufmerksamkeit zu bekommen. Sonst nix. Naja, eine der vielen Spielarten des Internet-Trolls.
Du hast keine Ahnung von ASM, C und logischem, strukturiertem Denken und
damit Programmieren.
Was soll das?
Das ist eine Diagnose.
Die Leute die sich noch mit Details auseinandersetzen und so lange dabei
sind sollen keine Ahnung haben???
In der Tat.
Man muß doch in dieser verblödenden Gesellschaft über jeden
Interessenten froh sein!
Nö.
Das brauchen 99% der Anwender nicht und der OP schon gar nicht!
Das wirst sicher nicht Du festlegen.
Hab ich auch nicht, sondern auch das ist eine Diagnose.
Aber das lernst du vielleicht noch. Mit deinen angemeldeten 3 Wochen hier bist du ein Greenhorn.
Reinhard R. schrieb im Beitrag #7388219:
Als Anfänger bzw. Hobbyist, weiß man nicht, dass man sich "nur" auf 10%
konzentrieren muss, man stochert wohl eher in den gesamten 100% herum
und dies kostet Zeit - Verdammt viel Zeit. War zwischendurch mit
PlatformIO auch schon zu Gange ...
Bleib doch mal bei einer Sache und spring nicht immer hin und her. Ich habe es die schon mal gesagt, gerade zu Atmel-Studio gibt es diverse Tutorials und Anleitungen. Wenn du mal ein paar davon durcharbeitest hast du verstanden wie man damit arbeitet.
Die Leute die sich noch mit Details auseinandersetzen und so lange dabei
sind sollen keine Ahnung haben???
Er setzt sich zwar mit Details auseinander, aber mit den Falschen.
Das Problem bei Bernd ist, das er weder mit der Bedienung seiner Programmierwerkzeuge zurecht kommt, noch mit der verwendeten Programmiersprache, deshalb seine Programme nicht laufen und er dann die Gründe dafür im Assemblerlisting des Compilers sucht. Und das Ganze weil er nicht bereit ist sich mal 2-3 Tage mit Tool und Sprache zu beschäftigen.
Sein Vorgehen ist maximal ineffizient.
ich erwarte eigentlich gepflegte technische Diskussionen die auch ein gewisses Niveau haben. Wenn jemand das Niveau nicht halten kann, antwortet man nicht.
Bei Bernd vermisse ich das Niveau und die Verbesserung seiner Faehigkeiten (nach +10a sollte schon Fortschritt zu sehen sein). Es wird jetzt besser werden weil er ja das Essay ueber die FSM liefert (Kein Essay -> keine Antworten von mir).
Oder er ist ein Troll (das ist aber meine Meinung).
Dachte ich guck mal, ob sich was sinnvolles ergeben hat. Und nein, ich werde dass Denken nicht aufgeben ;-)
Leute die noch auf den Schulhof gehören, kann ich irgendwie nicht in meinen Threads gebrauchen. Ich denke erwachsene Menschen mit gesundem Menschenverstand sind schon gut in der Lage sich eine eigene Meinung zu bilden und lassen sich auch nicht durch irgendwelche Beurteilungen am Rand davon abhalten, etwas zu lesen oder auch nicht. Wer an solchen DSDS-Berurteilungsklamotten Spaß hat, hat meistens mehr oder weniger gerade auch erst den Schulhof verlassen. Andere gehen halt lieber nach The Voice of Germany.
Wie wärs mit den fünf universellen Forumsregeln ?
Beitrag "Die fünf universellen Forenregeln ;-)"
Threadüberschrift lesen
Evtl. Datum beachten
Posting verstehen
Falls nicht drittens, dann nachfragen oder Klappe halten.
Auf die Fragen eingehen und / oder Alternativen bzw. Verbesserungen
nennen.
Die Punkte kann man an einer Hand abzählen, sollte also in der Lage sein, bis fünf zählen zu können.
Deshalb evtl. gut merken, wenn nicht dann nur Punkt 3 und Punkt 4 merken.
Bei Bernd vermisse ich das Niveau und die Verbesserung seiner
Faehigkeiten (nach +10a sollte schon Fortschritt zu sehen sein).
Da ist definitiv was dran. Das erscheint einem wirklich so, als wenn es da in all den Jahren fast keinen Fortschritt gab.
Er hat irgendwann mal gewisse Grundkonzepte (Instruktionen/Adressierungsarten) des AVR8-Assembler kapiert und gewisse Teile der Bedienung der frühen (4er) Studios, aber sich niemals aktiv die Mühe gemacht, mehr zu lernen, sondern seine Bestrebungen bei Lösungen immer nur daran ausgerichtet, möglichst mit dem auszukommen, was er bereits konnte.
Das kann man sehr schön verfolgen, wenn man sich anschaut, was er so veröffentlicht hat.
Dann frag ich mal zurück: Wozu gibts dieses Forum?
Um deine rhetorische Frage zu beantworten: es soll Hilfestellung geben um Probleme zu lösen.
Nun ist es aber bei Bernd so, das er die zielführenden Ratschläge nicht beachtet während er sich gleichzeitig intensiv mit Dingen beschäftigt, die nichts zur Lösung seines Problems beitragen.
Er hat irgendwann mal gewisse Grundkonzepte
(Instruktionen/Adressierungsarten) des AVR8-Assembler kapiert und
gewisse Teile der Bedienung der frühen (4er) Studios, aber sich niemals
aktiv die Mühe gemacht, mehr zu lernen, sondern seine Bestrebungen bei
Lösungen immer nur daran ausgerichtet, möglichst mit dem auszukommen,
was er bereits konnte.
Ich hab mich mal hiermit genauer beschäftigt. Wäre es nicht besser >= zu verwenden, da man doch in der main irgendwo sein kann, während die ISR eins weiter gezählt hat ( 201 ) ?
@Falk
hab dich von früher gar nicht so in Erinnerung. Scheinst private Probleme zu haben. Lass dir helfen.
Bernd S. schrieb im Beitrag #7377326:
Re: Tasterverarbeitung mit ARDUINO-C
Falk, lass es doch besser mir helfen zu wollen, jetzt mischt du dich
schon in Angelegenheiten von Anderen und mir ein, die evtl. besser
verstehen was ich meine.
Tut mir leid für meine klaren Worte an dich, aber besser ist es wohl für
uns beide, wenn du dich ab jetzt hier raushälst.
@Thomas W. (dbstw)
Es ist gut, dass man wohl offensichtlich jetzt in jedem Unterforum nicht mehr als Gast auftauchen kann.
Dich kenn ich praktisch nicht, muss aber zum jetzigen Zeitpunkt sagen : " Beherzige den zweiten Abschnitt, der an Falk B. gerichtet ist ".
Und weil ich so gerne Copy & Paste mache und µC.net eine riesige Party ist ;-)
... dann würdest du auch erkennen, dass es in der virtuellen Welt sehr
schwierig ist, ein paar sich angepinkelt fühlende Leute, wieder los zu
werden. Dafür ist es zu einfach, bei jeder Party dabei zu sein, und an
den dortigen Gesprächen teilzunehmen. Diese Leute haben einfach zu viel
Zeit, da sie sich in Probleme einmischen, die es in ihren Augen gar nicht gibt und dementsprechend werden diese Leute natürlich auch gar nichts zur
Problembehebung beitragen, sondern nur irgendwelches Zeugs schreiben,
was meistens zeigen soll, was sie alles wissen und können.
Es wird Zeit dass die Mods hier mal aufräumen, damit sich der Ruf wieder bessert :
Kann ich den Compiler irgendwie mitteilen, dass er nur untere ( < r16 )
Register verwenden soll und nicht dass SRAM ?
Der Compiler wird nicht auf die Nutzung von RAM verzichten können. Irgendwo muss der Stack hin, der für Funktionsaufrufe, Interrupts und auch automatische Variablen benötigt wird.
Dass das SRAM für die Rücksprungadressen bei Interrupts und Unterprogrammen usw. gebraucht wird, ist mir klar. Würde aber halt gerne in der ISR ein 1:1 Abbild vom ISR-AVR8ASM-Code haben, was der Compiler jedoch nicht macht.
Untere Frage, weil die Einarbeitung verdammt schwierig für mich ist, da es total abstrakt ist, was man da tippen muss und ich keine Lust habe, mich in etwas einzuarbeiten, was evtl. auch anders bzw. einfacher gelöst werden kann.
Kann ich den Compiler irgendwie mitteilen, dass er nur untere ( < r16 )
Register verwenden soll und nicht dass SRAM ?
...
Ich denke es geht nur mit Inline-Assembler oder ?
Warum gibt man keine konkreten Antworten auf konkrete Fragen ?
Die Antworten kommen mir so vor wie : " So könnte es funktionieren, probiers mal, ich hab da nicht so die Ahnung. "
Wenn ich mich dann in diese Materie einarbeite, heißt es evtl. : " Das geht doch viel einfacher ! ".
Die GNU-Toolchain bietet dazu zwei Möglichkeiten:
Inline-Assembler
Assembler-Dateien
Ich denke ich arbeite mich in diese kryptische Inline-Assembler sch... ein.
Wenn dass so einfach ginge hätte ich es einfach gemacht.
Wenn Du das (mit einem s) nicht hinbekommst, dann frage ich mich, was Deine Anforderung (nur bestimmte Register und kein RAM verwenden) überhaupt soll.
Du beißt dich mit beeindruckender Intensität an einem überhaupt nicht bestehenden Problem fest.
Erklär' doch mal, was Deine spezielle Anforderung überhaupt bringen soll. Meinst Du, damit ein Performanceproblem lösen zu können?
Wie kommst Du auf die Idee, daß das Performanceproblem a) überhaupt existiert und b) mit dem Nichteinhalten Deiner spezifischen Anforderung zu tun haben soll?
Warum gibt man keine konkreten Antworten auf konkrete Fragen ?
Das könnte vielleicht damit zusammenhängen das keiner die Antwort weiß.
Die Antworten kommen mir so vor wie : " So könnte es funktionieren,
probiers mal, ich hab da nicht so die Ahnung. "
Ja, das kann gut sein. Da keiner dein Problem hat, hat auch keiner eine Lösung dafür. Immerhin gibt man dir Tipps wie es gehen könnte, aber dir reicht das offensichtlich nicht.
Wenn ich mich dann in diese Materie einarbeite, heißt es evtl. : " Das
geht doch viel einfacher ! ".
Ja und?
Ich denke ich arbeite mich in diese kryptische Inline-Assembler sch...
ein.
Warum erstaunt mich das nicht?
Ich verstehe dich nicht.
Kann ich den Compiler irgendwie mitteilen, dass er nur untere ( < r16 )
Register verwenden soll und nicht dass SRAM ?
Nein.
Der Vorteil eines Compilers ist ja gerade, daß man nicht mehr mit dem ganzen low-Level Schrunz (register, sram, push, pop usw.) seine Zeit vergeuden muß. Man kann sich voll auf das eigentliche Problem konzentrieren.
Selbst für echte Koniferen dürfte es aber unmöglich sein, ein sinnvolles Programm oder auch nur eine sinnvolle ISR für einen AVR zu schreiben, das nur die unteren Register <r16 benutzt.
Selbst für echte Koniferen dürfte es aber unmöglich sein
Ich habe Hugo sicherlich richtig verstanden, nachdem du aber
seine Verballhornung wiederholst habe ich meine Zweifel ob
du ihn richtig verstanden hast ....
Selbst für echte Koniferen dürfte es aber unmöglich sein, ein sinnvolles
Programm oder auch nur eine sinnvolle ISR für einen AVR zu schreiben,
das nur die unteren Register <r16 benutzt.
Würde ich so verallgemeinert nicht stehen lassen. Klar, in aller Regel braucht man für eine effiziente ISR wenigstens ein Immediate-fähiges Register, sehr oft auch zwei (für Indirektionen).
Aber das schließt nicht aus, dass es auch ISRs geben kann, die mit allein den "dummen" Registern, ggf. ergänzt durch (entsprechend vorgeladene) GPIO-Register klarkommen. Ist aber wirklich eher selten.
Versuche per AS7 ein Projekt mittels Arduino-Sketch nach dem unteren Video zu erstellen ( Ab Minute 8:23 ).
Als erstes muss ich, anders als im Video, den Pfad erst suchen ( Arduino IDE path ), wenn ich dass Board auswähle wird es Rot umrandet, was hoffentlich nicht schlimm ist.
Die RS232 bzw. USB-Verbindung ist i.O. Ich kann grundsätzlich Programme runterladen.
Dass Hauptproblem ist, dass wenn ich das Sketchfile raussuchen möchte, die Fehlermeldung auftritt und beim zweiten Versuch sich AS7 nach dem die Windows-Ladeanzeige eine paar Sekunden angezeigt wird, schließt.
Kann bitte jemand mal nach dem Video verfahren und mir schreiben, ob er auch diesen Fehler hat oder woran es liegen könnte ?
Windoofs 10 schafft es nicht seine eigenes Update ( Funktionsupdate für Windows 10, Version 22H2 ) hinzukriegen und vielleicht liegt es ja schon daran.
Hatte vorher das AS7 nicht deinstallieren können und dies dann mit der Testversion im unteren Link erledigt. Jetzt kann ich AS7 auch nicht neu installieren, weil kurz nach den Bildchen auftauchen und wieder verschwinden nichts weiter passiert.
Deine Windows-Installation ist halt kaputt. Vermutlich hast Du irgendwo im Internet einen Tipp aufgeschnappt, wie man irgendwas völlig irrelevantes durch wüstes Gefrickel "optimieren" kann. Das ist bei Leuten, die meinen, alles besser zu wissen, nicht ungewöhnlich. Die machen oft in ihrer Ahnungslosigkeit irgendwas, was sie nicht verstehen, aber glauben zu verstehen. Sei es, daß sie durch ungeschicktes Herumklicken einen kaputten "Dark Mode" selbstbasteln, der dann halt Informationen unsichtbar werden lässt, oder daß sie irgendwelche Assembleroptimierungen vornehmen wollen, an Stellen, wo sie völlig überflüssig sind, oder eben, daß sie meinen besser als Windows zu wissen, welche Systemdienste und -Einstellungen wirklich nötig sind.
Du kannst nach unzähligen Jahren nichtmal mit dem Windows-GUI korrekt umgehen...
Tip: einfach mal irgendwo außerhalb des angezeigten Textes im Adressfenster klicken, dann ändert sich die Anzeige vom Pfad im virtuellen Filesystem auf den realen Pfad. Erst damit kann man überprüfen, ob er stimmt. Compiler (und auch IDEs) habe nämlich von diesem virtuellen Pfad keinerlei Ahnung.
Der existiert nur, um DAUs nicht unnötig zu verwirren. Also Leute, die nach dem Willen von Microsoft möglichst niemals mit den tatsächlichen Filesystemen und ihren Inhalten zu tun haben sollen.
dann ändert sich die Anzeige vom Pfad im
virtuellen Filesystem auf den realen Pfad.
Dürfte in diesem Fall /nicht/ das Problem sein, denn offensichtlich ist die Arduino-Umgebung /nicht/ in einem der Verzeichnisse installiert, das standardmäßig virtualisiert/lokalisiert angezeigt wird.
Da steht nämlich nicht "C:\Programme", sondern "D:\Arduino\ARDUINO IDE\Arduino\examples"
Das ist noch nicht mal auf der Systemplatte/-Partition.
Windows virtualisiert/lokalisiert aber nur "C:\Users", "C:\Program Files" und C:\Program Files (x86)".
Nein, wie ich schon schrieb, dürfte das Problem am Leerzeichen im Pfad liegen, was im übrigen nicht für Atmel Studio spricht.
Nein, wie ich schon schrieb, dürfte das Problem am Leerzeichen im Pfad
liegen, was im übrigen nicht für Atmel Studio spricht.
Das Studio selber kommt wunderbar mit Leerzeichen in Pfaden klar. Muss es wohl, weil der Standard-Installationsort für die ganzen Includes unter einem 64Bit-Windows etwa so aussieht:
Was offensichtlich bereits in der zweiten Ebene des Baums ein Leerzeichen enthält und somit alles betrifft, was da je nach Target included wird (im konkreten Fall hier halt ein AVRxDy).
Wenn also irgendwas ein Problem damit hat, dann höchstens das angeflanschte Arduino-Gedöhns. Da ich diese Gülle weder brauche noch nutze, kann ich dazu nichts weiter sagen.
Dann spricht es halt nicht für das "Arduino-Gedöhns". Jemand mit auch nur einem Hauch von Eigeninitiative hätte das schon längst in ein anders benanntes Verzeichnis umkopiert, um das einzugrenzen.
Aber Eigeninitiative scheint in diesem Thread sehr, sehr rar zu sein.
Tip: einfach mal irgendwo außerhalb des angezeigten Textes im
Adressfenster klicken, dann ändert sich die Anzeige vom Pfad im
virtuellen Filesystem auf den realen Pfad. Erst damit kann man
überprüfen, ob er stimmt. Compiler (und auch IDEs) habe nämlich von
diesem virtuellen Pfad keinerlei Ahnung.
Dies dürften wirklich die wenigsten Windoofs-User wissen.
Vielleicht solltest du dich in " DAU & C-hater " umbenennen, aber trotzdem danke für den Tipp, der mir zwar im Moment nichts nutzt aber ...
Ach, die rote Umrandung beim Board-Feld scheint irrelevant zu sein.
Man darf eben nicht gleich rot, bei Rot sehen ;-)
AS7 muss doch dass Problem haben, denn es gibt ja eigentlich den Pfad automatisch vor.
Auf diesen Rechner hier, will ich aber auf keinem Fall, AS7 deinstallieren,
da ich es ja auf dem Anderen nicht installiert bekomme.
Hoffe nicht, dass das Problem nur daran liegt, dass ich damals (2019), AS7 auf D:\ installiert hatte.
Schon vergessen ?
Dann guck dir hier noch mal den Screenshot " AS7_Arduino " an.
Das einzige, was dort zu erkennen ist, ist, daß Du an einer Stelle, wo nach einer Datei gefragt wird ("Sketch file") etwas angibst, was ein Verzeichnis ist.
Da aber "Sketch File" gefragt wird, solltest Du auch Dein "blink.ino" dort angeben.
Das einzige, was dort zu erkennen ist, ist, daß Du an einer Stelle, wo
nach einer Datei gefragt wird ("Sketch file") etwas angibst, was ein
Verzeichnis ist.
Da aber "Sketch File" gefragt wird, solltest Du auch Dein "blink.ino"
dort angeben.
Danke, vielen Dank an Alle, die hier konstruktiv was beigetragen haben.
Typisch für mich, habe wieder einmal den Wald vor lauter Bäumen nicht mehr gesehen, da ja im Video auch zum Schluß .ino steht.
Aber bloß nicht dieses Symbol für Pfad suchen klicken, denn dann schließt sich AS7 wieder. Ist zwar alles umständlich aber so geht es.
Zu früh gefreut.
Auf mir lastet ein Fluch.
Wenn ich auf Build klicke, dann siehe Screenshot
Was ist jetzt schon wieder los ?
Bernd_Stein
Wenn du eine Datei "new.h" includieren willst, dann musst du auch
#include "new.h"
hinschreiben und nicht
#include "new"
Eine Datei mit dem Namen "new" gibt's nicht und dementsprechend ist es auch kein Wunder, das sich der Kram mit der Fehlermeldung "no such file or directory" meldet. Würde ich auch tun, wenn ich ein dummer Compiler wäre, der halt lt. Spezifikation einen im Pfad existierenden Dateinamen an dieser Stelle erwartet.
kein Wunder, das sich der Kram mit der Fehlermeldung "no such file
or directory" meldet.
Sehr oft hilft es, die Meldungen verstehend zu lesen. Sie sind ja nicht in Swahili.
Filename und Zeilennummer einer Meldung legen dann genau den Finger auf die Wunde. Sie können manchmal aber auch etwas dahinter zeigen.
So - habe anscheinend doch etwas gefunden, wo man nicht so verdammt kryptisch sein Inline-AVR8-Assembler-Codestück, in einem Arduino-Sketch einbinden kann.
Nur habe ich jetzt ein Problem mit dem AtmelStudio 7 Simulator.
Wenn ich wie im Screeshot zu sehen, beim Breakpoint ankomme und dann Step Into klicke, lande ich seltsamerweise nicht in Zeile 10, sondern in Zeile 32.
Es wird also auch mein ganzes Inline-AVR8ASM-Codestück übersprungen.
Ist der Bug in meinem Kopf oder im Simulator von AS7 ?
Weil weder in Zeile 9 noch in Zeile 10 irgend ein ausführbarer Code
steht.
Oliver
Hm - was ist ausführbarer Code ?
Immerhin wird weinigstens im Watch-Fenster der Wert für r2 mit 0xFF, nach abarbeiten der Breakpointzeile 40, übernommen.
Aber die Zeile 41 wird nicht abgearbeitet, da direkt zur Zeile 47 gesprungen wird.
In den Zeilen 9 & 10 hatten die Anweisungen keinen Sinn gemacht, da hierdurch z.B. der 2-Bit Abwärtszähler, bestehend aus r3 & r4, gar nicht hätte zählen können, deshalb jetzt in der Set Up Funktion.
Ok, bleibt immer noch die Frage, warum der Simulator nicht vom
Breakpoint in Zeile 9, zur Zeile 10 springt ?
Die Antwort von Oliver ist korrekt. Zeile 9 enthält eine Definition und Initialisierung einer als /volatile/ gekennzeichneten Variablen, das ist also Code, der auf jeden Fall zu Beginn der Funktion aufgerufen werden muss. Das ist die Initialisierung, die genau dann stattfindet.
Zeile 10 aber enthält die Definition und Initialisierung einer als /static/ gekennzeichneten Variable - die wird nur einmal vor dem Aufruf der Funktion initialisiert.
Damit hat diese Zeile keinen ausführbaren Code zur Folge.
Hättest Du auch diese Variable als /volatile/ (zusätzlich zu /static/) definiert, sähe es anders aus.
Will mir im Simulator einfach nur angucken, wie diese beiden Variablen den vertikal Zähler erzeugen, aber der Progammcounter bzw. Zeiger bleibt immer
in Zeile 10. Das heißt der Breakpoint in Zeile 14 wird auch nie angesprungen.
Hast du die Optimierung des Compilers deaktiviert?
Jo, daran lag es. Danke.
Nein, daran liegt es nicht...
Wenn Änderungen an den Optimization-Settings einen Fehler in der Applikation "beheben", dann liegt es fast immer an unsauberem (oder unsinnigem) Code und nur in Ausnahmefällen am Compiler, bzw. der Optimierung.
Was soll Deiner Meinung nach in den Zeilen 12 - 15 passieren, dass den Compiler dazu veranlasst, das Code-Schnipsel in der Applikation zu belassen und nicht einfach eine leere Endlosschleife zu formen?
Kleiner Tipp:
Für den Compiler zählt, was Du in C oder C++ beschrieben hast und wie dessen Auswirkungen auf den Rest des Programms aussehen - nicht, was Du gerne sehen möchtest.
Haben Sie nicht. Es gab nur Unterschiede im Debug-Verhalten.
Der Debugger kann nur mit dem arbeiten, was im Executable vorhanden ist. Und wenn sich das Verhalten der Applikation beim Debugging ändert, dann hat sich auch das Executable geändert...
Das Abschalten der Optimierung führt nur dazu, dass der Compiler den C-Code (weitestgehend) Zeile für Zeile übersetzt, egal wie kaputt oder sinnfrei der C-Code ist.
Laut Screenshot "Debug_vZaehler_Dissassembly.jpg" wurde der Inhalt der main() Funktion auf ein
1
RJMP PC-0x0000
reduziert, was bedeutet, dass der Compiler keinen Grund gesehen hat, die Zeilen 12 - 15 zu übersetzen. Also wäre es sinnvoller, sich Gedanken zu machen was man eigentlich in main() erreichen will und das dann entsprechend in C zu implementieren.
Der Debugger kann nur mit dem arbeiten, was im Executable vorhanden ist.
Und wenn sich das Verhalten der Applikation beim Debugging ändert, dann
hat sich auch das Executable geändert...
Ansonsten wäre der Optimierer ja auch völlig witzlos.
Dein Geschreibsel geht halt völlig am Thema vorbei. Der TO hat keine Probleme mit Fehlern durch Optimierung, der ist blutiger Anfänger und rätselt hier öffentlich über alles und jedes, was da so beim Programmieren in C vor sich geht.
Debuggen auf dem Arduino-Mega2560-Board geht mit dem ATMEL-ICE per JTAG.
Zuerst sind per ISP die FUSE-Bits zu ändern.
Bei mir war zu Beginn : EXTENDED = $FD, HIGH = $D0, LOW = $FF.
Einzustellen ist : EXTENDED = $FD, HIGH = $11, LOW = $FF.
Dies bedeutet es sind Häkchen bei OCD_enable und JTAG_enable zu setzen,
bei BOOTRST_enable jedoch, ist das Häkchen zu deaktivieren.
Der Bootloader ist dann erstmal futsch und muss bei Bedarf wieder neu geflasht werden. Vorher sind natürlich wieder per ISP, die FUSE-Bits zurück zu ändern.
Nach dem die geänderte FUSE-Bits-Konfiguration geflasht wurde, kann man sich der JTAG-Einstellung und Verkabelung zuwenden.
Wenn man oben, in der unteren Icon-Leiste, neben dem Icon für den eingestellten µC ( ATmega2560 ) klickt, erscheint dass Fenster im Anhang ( JTAG ATMEL-ICE ). Die dortigen Einstellungen einfach vornehmen.
Die 10-Polige Buchsenleiste auf der Adapterplatine ist zu verwenden, wobei oben Links der PIN 1 ist, was durch die quadratische Markierung, anstelle der runden, beim Platinenaufdruck zu erkennen ist.
Es werden für die JTAG-Verbindung die PORT F Pins 7 bis 4 benötigt und zusätzlich Vcc & GND.
PF7 bzw. A7 auf dem Arduino-Board -> TDI JTAG-Pin 9
6 6 -> TDO JTAG-Pin 3
5 5 -> TMS JTAG-Pin 5
4 4 -> TCK JTAG-Pin 1
1
5V Arduino-Board -> Vcc JTAG-Pin 4
2
GND Arduino-Board -> GND JTAG Pin 2 oder/und 10
Jetzt ist noch über die Spannungsversorgungsbuchse 9V oder 12V anzuschließen.
Ein kleines Testprogramm im Anhang, sowie die Bootloader-HEX-Datei.
Da beim Debuging per ATMEL-ICE und JTAG, die serielle Ausgabe mit dem Data Visualizer unleserlich war, bin ich auf Hterm umgestiegen, habe dort aber auch weiterhin Probleme.
Gut an Hterm ist, unter anderem, dass man sehr schön formatieren kann.
Hatte erst mit com1 gearbeitet, aber com3 macht die gleichen Probleme.
Es werden regelmäßig, 3x hintereinander, einfach das Bit0 gesetzt, obwohl es im Code gar nicht so programmiert ist ( siehe Anhang ).
Könnte mal jemand den Sketch auch auf dem Arduino-Mega2560-Board testen,
ob die virtuelle RS232 hier auch diesen Fehler macht ?
Ach jetzt fällt mir auf, dass nicht nur Bit0 spinnt, sondern eigentlich in der Mitte, die drei Einsen nicht korrekt angezeigt werden, denn Bit3 ist fälschlicher Weise mit 0 angegeben.
Ach jetzt fällt mir auf, dass nicht nur Bit0 spinnt, sondern eigentlich
in der Mitte, die drei Einsen nicht korrekt angezeigt werden, denn Bit3
ist fälschlicher Weise mit 0 angegeben.
Um ehrlich zu sein, weiß ich nicht wie
1
Serial.print(PORTB,BIN);
auf den Parameter PORTB reagiert.
versuche bitte folgendes:
ps: Wobei ich auch nicht ganz verstehe, was du erreichen möchtest.
durch
1
DDRB=0b11111000;
2
PORTB=0b00111000;
arbeiten PB7 bis PB3 als Ausgänge, und PB2 bis PB0 als Eingänge.
Zusätzlich wird bei PB5 bis PB3 ein High-Pegel ausgegeben.
Um aber auch die Werte der Eingänge zu erfassen sollte man das Register PINB einlesen.
Um den Fehler auf die Übetragung oder die UART einzugrenzen solltest du vielleicht einfach eine Konstante ausgeben:
Es tut einfach das, was es tun soll, und gibt den in PORTB stehenden
Wert im BIN-Format aus.
Genau darum geht es.
Ist nur die Frage wo der Fehler beim Empfangen liegt.
Klapt es denn bei euch mit HTerm mit meinen Einstellungen und dem Programm ?
Klapt es denn bei euch mit HTerm mit meinen Einstellungen und dem
Programm ?
Du hoffst doch nicht ernsthaft, daß das jetzt irgend jemand ausprobiert?
Oliver
Warum nicht ?
Okay, meistens wird einem nur geholfen, wenn es einfach ist.
Dafür muss man wahrscheinlich selbst vor dem PC sitzen und die Programme haben und nicht am Handy rummdaddeln.
Nun ja, es scheint mit dem Arduinogedöns zusammen zu hängen.
Es geht ja im Detail um PORT B3 & B0, welche bei mir zur Zeit die ungenutzten Anschlussleisten, ICSP ( 6pol. ISP-Stiftleiste ) und XIO ( doppelreihige Buchsesnleiste ) sind. Es geht also um Serial Peripheral Interface ( SPI ) und Pin Change Interuppt ( PCINT ), welche wohl vom Arduinogedöns auch genutzt werden, wenn ich dass Programm laufen lasse.
Also für mich ein unlösbares Problem oder anders ausgedrückt: " Ein nicht im Detail erklärbares ". Vielmehr eine Vermutung.
PORT B3 => MISO / PCINT3
PORT B0 => SS / PCINT0
Das Layout entspricht nicht zu 100% meiner Platine, aber die beiden Anschlussleisten, auf die es jetzt ankommt müssten stimmen.
Ach noch was. Vielleicht ist ja die Darstellung meiner Texte für Verwirrungen mit schuld.
Die Vorschauansicht sieht bei mir sehr komprimiert aus.
Zum Beispiel habe ich ja PORT B3 und PORT B0 untereinandergeschrieben, aber in der Vorschau ist es einfach hintereinander geschrieben, so wie auch andere Dinge auch.
Welche Ansicht bekommt ihr zu sehen ( µCnet oder Vorschau ) ?
Warum nicht ?
Okay, meistens wird einem nur geholfen, wenn es einfach ist.
Dafür muss man wahrscheinlich selbst vor dem PC sitzen und die Programme
haben und nicht am Handy rummdaddeln.
Ach so. Nur mal eben den Atmel ICE rauskramen, dazu den Arduino, dann deinen Versuchsaufbau nachstellen, die Software laden, usw. ?
Gibt es überhaupt Bibliotheken (libraries) in Assembler? Ich habe in 30
Jahren keine gesehen.
Das liegt dann wohl daran, dass du selber keine produziert hast, sondern eher der typische "lib-gluer" bist.
Natürlich benutzt man auch in Assembler das Äquivalent zu "libraries". Die sind allerdings naturgemäß auf eine Target-Architektur beschränkt.
Ich habe da z.B. ein Flash-Filesystem mit wear-leveling und Transaktionssicherheit für AVR8. Das läuft auf absolut jedem AVR8, der überhaupt in der Lage zum "self-programming" ist und über genügend Flash-Speicher verfügt.
Das kommt dann in Form einer einzigen Datei namens flashdisk.asm, die man einfach nur am Ende des Hauptprogramms includen muss. Ja, die heißt nicht *.lib und auch nicht *.a, ist aber wohl auch sowas wie eine "library" nach deinem Verständnis.
Darüber hinaus habe ich auch viele Includes (also Sachen, die selber nix produzieren, nur Support-Macros bereitstellen). Besagte flashdisk.asm z.B. benutzt unzählige der dieser Support-Macros. Dabei geht es in einem wesentlichen Teil darum, Unterschiede innerhalb der Architektur zu "begradigen". Letztlich also dasselbe #ifdef-Gebastel, wie man es von dem ach so "hochportablen" C/C++ kennt...
Der Rest der Includes verhilft Asm zu Features wie Strukturen, Callbacks, Interruptvektoren und ähnlichen Sachen, die es in Hochsprachen (selbst Pseudo-Hochsprachen wie C) gibt, in Asm aber eben von Hause aus nicht.
Das liegt dann wohl daran, dass du selber keine produziert hast, sondern
eher der typische "lib-gluer" bist.
Ich meine nicht selbst gebaute Bibliotheken, sondern welche die irgendwo veröffentlicht wurden. Ich muss dazu sagen, dass ich nicht aktiv danach gesucht habe, weil ich nur wenige Zeilen in Assembler programmiert habe. Zum Beispiel habe ich mal in einem Wettbewerb für einen DOS Bildschirmschoner den 3. Preis abgeräumt. Lang ist's her.
Wie ich jetzt herausgefunden habe ist Serial.print() untauglich für eine normale RS232 Übertragung.
1.Es werden keine führenden Nullen übertragen.
2.Es werden immer zwei Byte als ASCII-Code gesendet, wobei bei einstelligen Werten nur 1 Byte gesendet wird, da führende Nullen ja nicht gesendet werden.
3. Der Zusatz BIN " Serial.print( wert, BIN ) ", vereint praktisch Punkt 1 & 2.
Dann kommt so ein Mist wie im unteren Screenshot zu sehen ist heraus.
Oben im Beispiel ( 0xC5 ) passt alles, da es keine führenden Nullen gibt.
Da dass MSB eine Null ist ( 0x45 bzw. 0b0100 0101 ), wird diese nicht gesendet, aber halt die nächsten zwei. Da ein Byte 8 Bits hat, muss man vier mal senden, d.h. beim vierten mal wird dass erste Bit wieder mit angehangen, da ja immer zwei Zeichen gesendet werden, aber eben wieder keine führenden Nullen.
Welchen Befehl verwendet man denn ansonsten für eine Übertragung an ein Terminalprogramm wie z.B. HTerm ?
2.Es werden immer zwei Byte als ASCII-Code gesendet, wobei bei
einstelligen Werten nur 1 Byte gesendet wird, da führende Nullen ja
nicht gesendet werden.
Sorry, den Satz verstehe ich nicht.
Der Zusatz BIN " Serial.print( wert, BIN ) ", vereint praktisch
Punkt 1 & 2.
Verstehe ich nicht, wohl weil ich 2. nicht verstehe.
Dann kommt so ein Mist wie im unteren Screenshot zu sehen ist heraus.
Ohne Quelltext ist da nicht einmal erkennbar, was du vor hattest, geschweige denn, wie du es umgesetzt hast. Zeige doch wenigstens mal den gut kommentierten Quelltext!
Weil es nicht mehr ums Atmel Studio 7 geht, würde ich dafür einen neuen Thread empfehlen.
Ohne Quelltext ist da nicht einmal erkennbar, was du vor hattest,
geschweige denn, wie du es umgesetzt hast. Zeige doch wenigstens mal den
gut kommentierten Quelltext!
1
#include<Arduino.h>
2
3
bytewert=0b01000101;
4
5
voidsetup()
6
{
7
Serial.begin(9600);
8
}
9
10
voidloop()
11
{
12
while(1){
13
Serial.print(wert,BIN);
14
}
15
}
Wie macht man es denn jetzt, wenn man wie z.B. in diesem Code, einfach nur ein einzelnes Byte an ein Terminalprogramm senden will.
Auch wenn ich den Zusatz BIN weglasse, werden zwei Byte gesendet.
So eine Punkt zwischen den Nibbles wäre eine feine Sache nicht wahr ?
Wenn du's brauchst, um rein rekognitiv mit deinen offensichtlich sehr begrenzten Möglichkeiten klar zu kommen... Normalbegabte können jedenfalls 8Bit noch problemlos ohne diesen Nibble-Separator wahrnehmen.
Wenn der Simulator und dass Debugging versagt, hat man zum Glück noch die RS232.
Im Screenshot ging es darum, ob start in der else-if-Abfrage überhaupt auf false gesetzt wird. Da der Breakpoint bei ASM("NOP"); nie angesprungen wurde konnte ich start nicht beobachten.
Die RS232 und HTerm brachten die Erkenntnis.
Da fragt man sich natürlich, ob der ganze ATMEL-ICE per JTAG-Debugging-Kram überhaupt Sinn macht.
Was nutzt ihr zur Fehlersuche, außer natürlich euer Gehirn ;-) ?
Also grundsätzlich, haben 99% deiner Probleme mal überhaupt nichts mit AtmelStudio zu tun.
Anhand des letzten Problems mit deinen fehlden Nullen, muss ich ganz klar sagen: Grundlagen lernen und das Arduino Framework verstehen, falls du es nutzen möchtest.
Da fragt man sich natürlich, ob der ganze ATMEL-ICE per
JTAG-Debugging-Kram überhaupt Sinn macht.
Klar, im Moment reicht die Serial Debug Ausgabe für deine kleinen Problemchen. Aber damit bist du ganz schnell an den Grenzen des Möglich.
Kleines Bsp.:
Du hast in deinem (größerem) Projekt einen Buffer und dahinter im Flash liegt eine Variable (zu sehen im map-file).
Wenn dein Buffer nun durch einen Fehler über seine Grenze beschrieben wird und du den Grund nicht siehst, dann bist du froh wenn du einen "Data Breakpoint" auf die Variable setzen kannst um zu sehen wann ein Schreibvorgang auf diese stattfindet.
Also für mich ein unlösbares Problem oder anders ausgedrückt: " Ein
nicht im Detail erklärbares ". Vielmehr eine Vermutung.
PORT B3 => MISO / PCINT3
PORT B0 => SS / PCINT0
Falls du dein Arduino über den Atmel-ICE flasht und der am ICSP hängt, dann wundert mich nicht, das dein PB3 nicht tut.
Immerhin hängt da der ICE dran.
Gibt im Internet auch Schaltpläne von den Boards, da kannst du ganz genau sehen, was wo dran hängt und diese Pins dann meiden, falls bereits anders verwendet.
Falls du dein Arduino über den Atmel-ICE flasht und der am ICSP hängt,
dann wundert mich nicht, das dein PB3 nicht tut.
Immerhin hängt da der ICE dran.
Aber der schaltet sich doch weg (hochohmig) wenn er inaktiv ist.
Falls du dein Arduino über den Atmel-ICE flasht und der am ICSP hängt,
dann wundert mich nicht, das dein PB3 nicht tut.
Immerhin hängt da der ICE dran.
Aber der schaltet sich doch weg (hochohmig) wenn er inaktiv ist.
Könnte mal jemand den Sketch auch auf dem Arduino-Mega2560-Board testen,
ob die virtuelle RS232 hier auch diesen Fehler macht ?
Ach jetzt fällt mir auf, dass nicht nur Bit0 spinnt, sondern eigentlich
in der Mitte, die drei Einsen nicht korrekt angezeigt werden, denn Bit3
ist fälschlicher Weise mit 0 angegeben.
Somit ist dieses Problem nicht nachvollziehbar,
bei mir tut der Port sowie die Ausgabe was sie soll.
Somit ist dieses Problem nicht nachvollziehbar,
bei mir tut der Port sowie die Ausgabe was sie soll.
Tja, ist schon seltsam, aber ich will es nicht zerreden, es gibt bestimmt ein Verständnisproblem, dass wir jetzt nicht mehr lösen brauchen, da ich Serial.write() benutze.
C_Code_CompilerfehlerII.jpg
(91 KB)
C_Code_MakefileII_Error.jpg
(110 KB)
C_Code_Main_Error_DetailII.jpg
(35 KB)
