volatileuint8_tkey_state;// debounced and inverted key state:
2
// bit = 1: key pressed
3
volatileuint8_tkey_press;// key press detect
4
5
volatileuint8_tkey_rpt;// key long press and repeat
6
7
8
ISR(TIMER0_OVF_vect)// every 10ms
9
{
10
staticuint8_tct0=0xFF,ct1=0xFF,rpt;
11
uint8_ti;
12
13
TCNT0=(uint8_t)(int16_t)-(F_CPU/1024*10e-3+0.5);// preload for 10ms
14
15
i=key_state^~KEY_PIN;// key changed ?
16
ct0=~(ct0&i);// reset or count ct0
17
ct1=ct0^(ct1&i);// reset or count ct1
18
i&=ct0&ct1;// count until roll over ?
19
key_state^=i;// then toggle debounced state
20
key_press|=key_state&i;// 0->1: key press detect
21
22
if((key_state&REPEAT_MASK)==0)// check repeat function
23
rpt=REPEAT_START;// start delay
24
if(--rpt==0){
25
rpt=REPEAT_NEXT;// repeat delay
26
key_rpt|=key_state&REPEAT_MASK;
27
}
28
}
Was muss ich tun, um meinen im Screenshot zu sehenden Paste & Copy Code,
fehlerfrei zu compilieren ?
volatile hilft auch nicht.
Es ist ein GCC C Executable Project.
Bernd_Stein
Was hat der Code im Bild mit dem im Text zu tun?
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.
Oliver
Harald, -
lass stecken: Das ist sinnlos und frustierend (ich warte immer noch auf
den Essay ueber die state-Machine
[Beitrag "Re: Tasterverarbeitung mit ARDUINO-C"]).
In meinen Augen ein Troll.
Gruesse
Th.
Harald K. schrieb:> 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.
Oliver S. schrieb:> Was hat der Code im Bild mit dem im Text zu tun?>
Was für ein Text?
>> 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.
Bernd_Stein
Bernd S. schrieb:> 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.
Das „Ardiuno-Gedöns“ ist C++, dein Gedöns ist C. Das sind halt zwei
verschiedene Programmiersprachen. Einen der Unterschiede hast du gerade
gefunden.
Oliver
Oliver S. schrieb:> Bernd S. schrieb:>> 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 ).
Bernd_Stein
Hallo,
Bernd S. schrieb:> 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
Bernd S. schrieb:> KEY_PIN habe ich auf PINE umdeklariert
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.
Roland F. schrieb:> 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.
Roland F. schrieb:> Menue > Tools > Options > Text Editor > All Languages > Haken bei "Line> Numbers">> DAS müßtes du eigentlich auch alleine finden können.>
Danke, du Witzbold. Ich komm auch gerne schnell voran.
Ich verstehe den guten, alten Hannes Luxx, dass er bei AVR8ASM bis zum
Ende geblieben ist.
Harald K. schrieb:> Bernd S. schrieb:>> KEY_PIN habe ich auf PINE umdeklariert>> 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.
Bernd_Stein
Hallo,
Bernd S. schrieb:> Danke, du Witzbold.
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.
rhf
Bernd S. schrieb:> 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.
Hugo H. schrieb:> Bernd S. schrieb:>> 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).
Roland F. schrieb:> 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 )
Bernd_Stein
Hallo Bernd,
Bernd S. schrieb:> 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.
Reinhard
Hallo,
Bernd S. schrieb:> 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?
rhf
@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.
Bernd S. schrieb:> 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.
Arduino Code ist das bestimmt nicht.
Da sieht die main() anders aus und du müsstest setup() und loop() zur
Verfügung stellen.
Reinhard R. schrieb:> ...> 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.
Roland F. schrieb:> 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 ...
Roland F. schrieb:> Wäre es nicht besser erst mal das Programm zum Laufen zu bringen als> sich mit den Prozessorregistern zu beschäftigen?>
Aus deiner Sicht sicherlich.
Aber als AVR8ASM-Geschädigter sieht es halt anders aus ;-)
Roland F. schrieb:> 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.
Bernd S. schrieb:> 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?
Harald K. schrieb:> Bernd S. schrieb:>> 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...
C-hater schrieb:> Nachdem diese Seuche erstmal auf die Menschheit> losgelassen war, war sie nahezu unabänderlich bezüglich ihrer> Grundfesten...
Ach mein Gott, Hater, wer wird denn immer so radikal sein?
Leben und leben lassen ....
Bernd S. schrieb:> 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!
C-hater schrieb:>>> 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?
Das brauchen 99% der Anwender nicht und der OP schon gar nicht!
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.
Gruesse
Th.
Thomas W. schrieb:> 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.
Martin W. schrieb im Beitrag #7388907:
>> 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.
Hallo,
Bernd S. schrieb:> Reinhard R. schrieb:> 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.
rhf
Hallo,
Martin W. schrieb im Beitrag #7388907:
> 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.
rhf
Moin, -
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).
Gruesse
Th.
Frohe Ostern !
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 ;-)"
1. Threadüberschrift lesen
2. Evtl. Datum beachten
3. Posting verstehen
4. Falls nicht drittens, dann nachfragen oder Klappe halten.
5. 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.
Bernd_Stein
Thomas W. schrieb:> 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.
Hallo,
Martin W. schrieb im Beitrag #7389079:
> 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.
C-hater hat es treffgenau zusammengefasst:
C-hater schrieb:> 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.
rhf
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:
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 :
https://de.trustpilot.com/review/www.mikrocontroller.net
Und jetzt wieder zum Thema :
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 )
Ich denke es geht nur mit Inline-Assembler oder ?
Bernd_Stein
Bernd S. schrieb:> 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.
Du plenkst. Lass' das.
Harald K. schrieb:> Du plenkst. Lass' das.>
Nö, gefällt mir so.
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.
Bernd S. schrieb:> Ich denke es geht nur mit Inline-Assembler oder ?>
Bernd_Stein
Bernd S. schrieb:> 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 )
Generell natürlich nicht.
Allerdings ist der Compiler eigentlich ganz gut darin, unnötige
SRAM-Zugriffe zu vermeiden, wenn man ihn den lässt.
volatile und globale Variable sind dabei natürlich ziemlich
kontraproduktiv.
Oliver
Bernd S. schrieb:> Nö, gefällt mir so.
Ist 'ne Frage von Umgangsformen. Du hast halt keine.
> Würde aber halt gerne> in der ISR ein 1:1 Abbild vom ISR-AVR8ASM-Code haben, was der Compiler> jedoch nicht macht.
Dann schreib' die ISR doch in Assembler.
> Harald K. schrieb:>> Dann schreib' die ISR doch in Assembler.>
Wenn dass so einfach ginge hätte ich es einfach gemacht.
1
i=key_state^~KEY_PIN
AVR8ASM
1
in i,PINE
2
com i
3
eor i,key_state
>> Und hier wie man das mit dem C-Compiler kombiniert:>> https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Assembler_und_Inline-Assembler>> und>> https://ww1.microchip.com/downloads/en/appnotes/doc42055.pdf>> rhf>Bernd S. schrieb:> 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.
Bernd_Stein
Bernd S. schrieb:> 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?
Hallo,
Bernd S. schrieb:> 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.
rhf
Bernd S. schrieb:> Bernd S. schrieb:>> Kann ich den Compiler irgendwie mitteilen, dass er nur untere ( < r16 )>> Register verwenden soll und nicht dass SRAM ?> Warum gibt man keine konkreten Antworten auf konkrete Fragen ?Oliver S. schrieb:> Generell natürlich nicht.
Ich dacht, das wäre konkret genug. War es anscheinend nicht. Dann
nochmal, etwas klarer:
NEIN
Oliver
Bernd S. schrieb:> 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.
Oliver
Oliver S. schrieb:> 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 ....
Oliver S. schrieb:> 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.
Probleme über Probleme und kein Ende in Sicht.
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 ?
https://www.youtube.com/watch?v=rQej393TLgw
Bernd_Stein
Bernd S. schrieb:> Dass Hauptproblem ist, dass
du mit einer IDE, die du nicht verstehst, etwas versuchst, wofür die
eigentlich nicht gemacht ist. Das geht dann gleich doppelt schief.
Oliver
Windoofs 10 schafft es nicht seine eigenes Update ( Funktionsupdate für
Windows 10, Version 22H2 ) hinzukriegen und vielleicht liegt es ja schon
daran.
https://de.minitool.com/datentraegerverwaltung/windows-10-schliesst-programme-von-selbst.html
Hm - Was mache ich jetzt ? ( siehe Screenshot ).
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.
https://www.revouninstaller.com/de/
Bernd_Stein
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.
Hm - Pfad stimmt so weit, also mal gucken, was die mit " permission to
access " meinen.
Ach so, den Pfad habe ich mit Copy & Paste eingegeben und erweitert,
dann auf OK, damit die Meldung kommt.
Bernd_Stein
Bernd S. schrieb:> Hm - Pfad stimmt so weit
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.
C-hater schrieb:> 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.
Harald K. schrieb:> 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:
C:\Program Files
(x86)\Atmel\Studio\7.0\Packs\Atmel\AVR-Dx_DFP\1.8.95\include
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.
Bernd S. schrieb:> Hatte vorher das AS7 nicht deinstallieren können und dies dann mit der> Testversion im unteren Link erledigt.> …> https://www.revouninstaller.com/de/
Das war eine geniale Idee, aber irgendwie auch erwartbar.
Oliver
Bernd S. schrieb:> Hm - Pfad stimmt so weit, also mal gucken, was die mit " permission to> access " meinen.>
Laut DeepL :
Zugriffserlaubnis, Zugriffsberechtigung, Zugangsberechtigung,
Zugriffsrecht
Harald K. schrieb:> Leerzeichen im Pfad. Manche Software kommt damit nicht zurecht.>
Habe mal stattdessen einen Unterstrich verwendet - ohne Erfolg.
C-hater schrieb:> 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
...
Harald K. schrieb:> Windows virtualisiert/lokalisiert aber nur "C:\Users", "C:\Program> Files" und C:\Program Files (x86)".>
Schon vergessen ?
Dann guck dir hier noch mal den Screenshot " AS7_Arduino " an.
Beitrag "Re: Mit dem ATMEL STUDIO 7 klarkommen : Create project from Arduino sketch"
Weil mir aufgefallen war, dass ich nur mit Administratorrechten einen
Ordner einrichten konnte, habe ich halt zu D:\ gewechselt.
Wie bereits geschieben hatte ich mich an dieses Video gehalten.
Das konkrete Problem tritt ca. ab Minute 8:23 auf.
https://www.youtube.com/watch?v=rQej393TLgw
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.
Bernd_Stein
Bernd S. schrieb:> 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.
Harald K. schrieb:> 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.
Bernd_Stein
Üblich für Arduino-Projekte ist es, daß die *.ino-Datei in einem
gleichnamigen Verzeichnis liegt.
Dein blink.ino gehört also in ein Verzeichnis namens blink, genauer:
"D:\Arduino\ARDUINO IDE\Arduino\examples\blink"
Das musst Du anlegen und Deine Datei da 'reinschieben.
Bernd S. schrieb:> 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.
Harald K. schrieb:> Üblich für Arduino-Projekte ist es, daß die *.ino-Datei in einem> gleichnamigen Verzeichnis liegt.>
Vielen Dank.
Hoffentlich ist der Fluch der Dummheit bald vorbei ;-)
D:\Arduino\ARDUINO_IDE\Arduino\examples\01.Basics\Blink\Blink.ino
Bernd_Stein
C-hater schrieb:> 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.
http://www.uni-koeln.de/phil-fak/muwi/ag/praktikum/assembler_arduino.pdf
Nur habe ich jetzt ein Problem mit dem *A*tmel*S*tudio 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 ?
Als Anhang mal der kurze Sketch.
Bernd_Stein
Harald K. schrieb:> Für den Simulator auf C-Ebene, den Du verwendest, ist Dein> "asm"-Block> eine Anweisung. Du müsstest schon den Simulator auf Assemblerebene> verwenden.>
Ok, bleibt immer noch die Frage, warum der Simulator nicht vom
Breakpoint in Zeile 9, zur Zeile 10 springt ?
Bernd_Stein
Oliver S. schrieb:> 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.
Der kurze Sketch wieder als Anhang.
Bernd_Stein
Bernd S. schrieb:> 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.
Was läuft jetzt wieder falsch ?
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.
Progrämmchen ist im Anhang.
Bernd_Stein
Simon G. schrieb:> Hast du die Optimierung des Compilers deaktiviert?>
Jo, daran lag es. Danke.
Da ich ein C-Projekt daraus gemacht habe, muss ich halt anders wie im
verlinktem Video ab Minute 3:36, bei *AVR/GNU C Compiler* Optimization
auswählen.
https://www.youtube.com/watch?v=cOU0Ji3SdGk
Bernd_Stein
Bernd S. schrieb:> Simon G. schrieb:>> 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.
Gruß,
Michael
Michael F. schrieb:> Nein, daran liegt es nicht...
Doch, tut es.
> Wenn Änderungen an den Optimization-Settings einen Fehler in der> Applikation "beheben",
Haben Sie nicht. Es gab nur Unterschiede im Debug-Verhalten.
Oliver
Oliver S. schrieb:> 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.
Gruß,
Michael
Michael F. schrieb:> 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.
Oliver
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
5V Arduino-Board -> Vcc JTAG-Pin 4
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.
Bernd_Stein
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.
Bernd_Stein
Bernd S. schrieb:> 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:
Simon G. schrieb:> Um ehrlich zu sein, weiß ich nicht wie Serial.print(PORTB, BIN);> auf den Parameter PORTB reagiert.
Es tut einfach das, was es tun soll, und gibt den in PORTB stehenden
Wert im BIN-Format aus. Irgendwelche Verrenkungen drumherum braucht es
da nicht.
Oliver
Oliver S. schrieb:> 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 ?
Bernd_Stein
Bernd S. schrieb:> 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
Oliver S. schrieb:> Bernd S. schrieb:>> 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.
https://easyeda.com/modules/Arduino-Mega-2560-PCB_461b7c70cbbf444fb53ff601a3f1557a
Bernd_Stein
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 ) ?
Bernd_Stein
Bernd S. schrieb:> 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. ?
Na ja, vielleicht findet sich ja jemand.
Oliver
Oliver S. schrieb:> Na ja, vielleicht findet sich ja jemand.
Das ist so ein packendes Thema und so interessant und wichtig
für alle, da kann keiner nein sagen.
Moby A. schrieb im Beitrag #7416115:
> wenn man von Assembler auf Hochsprache umsteigt
Das tut man nicht ohne guten Grund. Einer davon ist, dass die
Hochsprachen mehr Mittel zur Strukturierung umfangreicher Quelltexte
anbieten.
Gibt es überhaupt Bibliotheken (libraries) in Assembler? Ich habe in 30
Jahren keine gesehen.
Stefan F. schrieb:> 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.
C-hater schrieb:> 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.
C-hater schrieb:> die heißt nicht *.lib und auch nicht *.a, ist aber wohl auch> sowas wie eine "library" nach deinem Verständnis.
Ja klar, auf bestimmte Dateiformate wollte ich mich bei der Frage nicht
festlegen.
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 ?
Bernd_Stein
Bernd S. schrieb:> Wie ich jetzt herausgefunden habe ist Serial.print() untauglich für eine> normale RS232 Übertragung.
Nein, deine Bildung und deine Vorgehensweise ist untauglich für
das was du machen willst. Lerne und verstehe!
Was ist schon eine "normale RS232 Übertragung"? Das was du dir
vorstellst oder das was definiert ist?
Nicht die Technik ist hier schuld, sondern der Anwender.
Bernd S. schrieb:> 1.Es werden keine führenden Nullen übertragen.
Mit der Funktion sprintf() kannst du Zahlen in Zeichenketten einfügen,
auch mit führenden Nullen.
Bernd S. schrieb:> 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.
3. 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.
Stefan F. schrieb:> 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.
Bernd_Stein
Ah, schon besser. Unglücklicherweise kann sprintf() alles Mögliche
formatieren, nur keine Binärzahlen ausgeben.
Das musst du wohl "zu Fuß" programmieren. Zum Beispiel:
1
for(inti=7;i>=0;i--)
2
{
3
if(wert&1<<i)
4
Serial.print("1");
5
else
6
Serial.print("0");
7
}
Das ergibt genau 8 Zeichen, eins pro Bit, einschließlich führender
Nullen.
> Auch wenn ich den Zusatz BIN weglasse, werden zwei Byte gesendet.
Weil dann die dezimale Darstellung verwendet wird, und 0b01000101 in
dezimaler Darstellung "69" ist, das sind zwei Zeichen.
Um Daten unformatiert auszugeben (so wie sie im Speicher stehen) kannst
du Serial.write() verwenden.
https://www.arduino.cc/reference/en/language/functions/communication/serial/write/
Stefan F. schrieb:> Um Daten unformatiert auszugeben (so wie sie im Speicher stehen) kannst> du Serial.write() verwenden.>
Jo, danke. Das wars. Die binäre Darstellung kann ich dann in HTerm
einstellen.
So eine Punkt zwischen den Nibbles wäre eine feine Sache nicht wahr ?
0100.0101
Werde mal den Autor von HTerm diesbezüglich anschreiben.
Um so mehr wir sind desto besser :
website-impressum(ät)der-hammer.info
ät natürlich durch @ ersetzen.
Bernd_Stein
Bernd S. schrieb:> 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.
C-hater schrieb:> jedenfalls 8Bit noch problemlos ohne diesen Nibble-Separator wahrnehmen.
Das gibt es einen Spezialmode der das kann. HEX-Darstellung! ;-)
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 ;-) ?
Bernd_Stein
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.
Bernd S. schrieb:> 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.
Bernd S. schrieb:> 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.
Adam P. schrieb:> 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.
Stefan F. schrieb:> Adam P. schrieb:>> 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.
Ja hast recht, grad getestet.
Bernd S. schrieb:> 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.
Adam P. schrieb:> 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.
Aber dass hatte ich ja bereits hier geklärt :
Beitrag "Mit dem ATMEL STUDIO 7 klarkommen : HTerm für die binäre Darstellung"
Bernd_Stein