Hallo, ich habe ein Problem mit AVR-Studio 6 ... egal welches Projekt ich von mir nehme, seit ich die Version 6 installiert habe, kompiliert mir das Studio nur noch Mist zusammen. Programme die mal gingen, ASM oder C ... egal es kommt nur noch bedingt was brauchbares bei rum. Starte ich das 4er Studio funkt alles wie es soll. Einige Beispiele: - Interrupts werden nicht ausgelöst (ASM) - in C ignoriert er meine Variablen - ... Kennt jemand vielleicht das Problem und kann mir einen Tip geben? Danke mfG Net_Hans
Ja, dann sind deine Programme nicht sauber programmiert! Zeig doch mal eins deiner nicht funktionierenden Programme!
Das hier war nur ein Testprojekt worauf später ein Programm mit einem ADC aufbauen sollte und wo erst mal nur eine LED blinken sollte ... macht sie aber nicht ... In der Simulation rennt er über alles drüber was mit Variablen zu tun hat. einen Breakpoint kann ich an der Stelle auch nicht setzten. Die Schleifen werden einfach übergangen ...
1 | #define F_CPU 8000000
|
2 | |
3 | #include <avr/io.h> |
4 | #include <stdint.h> |
5 | #include <util/delay.h> |
6 | |
7 | |
8 | #define LED_PORT PORTB
|
9 | #define LED_DDR DDRB
|
10 | #define LED_PIN PB1
|
11 | |
12 | int main(void){ |
13 | int16_t t,i; |
14 | int8_t j; |
15 | |
16 | t = 5600; |
17 | LED_DDR |= 1 << LED_PIN; |
18 | LED_PORT ^= 1 << LED_PIN; |
19 | while (1) |
20 | {
|
21 | for(i=0; i< t;i++){ |
22 | j=0; |
23 | for(j=0;j<10;j++){ |
24 | _delay_ms(10); |
25 | }
|
26 | }
|
27 | LED_PORT ^= 1 << LED_PIN; |
28 | }
|
29 | return 0; |
30 | }
|
:
Bearbeitet durch User
> sollte und wo erst mal nur eine LED blinken sollte ..alle gut 9 Minuten.. > macht sie aber nicht wie lange hast Du denn auf eine Reatkion gewartet? Brav knapp eineinhalb Stunden? Mach mal die Warterei kürzer. Und packs auf einen richtigen µC.
Japp alle 9,33 Minuten ... eigentlich sollten es 10 Min sein, ich war aber irgendwie in Gedanken und so sind es dann 9,33 geworden ... Das Programm lief auf einem STK500 ca. 4 Stunden ohne das sich was sichtbares getan hatte ... es stand so neben mir rum als ich noch was anderes gemacht hatte ...
Net_Hans schrieb: > Japp alle 9,33 Minuten ... eigentlich sollten es 10 Min sein, ich > war > aber irgendwie in Gedanken und so sind es dann 9,33 geworden ... > Das Programm lief auf einem STK500 ca. 4 Stunden ohne das sich was > sichtbares getan hatte ... es stand so neben mir rum als ich noch was > anderes gemacht hatte ... Du hast eine merkwürdige Art und Weise etwas zu testen...
Ich wollte es einfach mit realen Zahlen machen ... hat mich in dem Moment nicht gestört ,da ich ja eh noch was anderes nebenbei machen musste ...
Bei den Delay Funktionen muss man aufpassen, dass die Optimierung eingeschaltet ist - sonst gibt das viel zu lange Wartezeiten. Mit Optimierung kann es passieren das einige variablen ganz wegoptimiert werden und mit den Debug Funktionen schwer zu fassen sind. So ähnlich kann es passieren, dass Teile ganz wegoptimiert werden und daher da auch kein Berakpoint gesetzt werden kann. Bei einem so einfachen Programm könnte man sich noch das erzeugte ASM File anzeigen und sehen was da etwa bei raus kommt.
beim Debuggen immer Optimierungen ausschalten! Und wenn ein Breakpoint nicht greift, dann hat GCC ganz einfach die Zeile wegoptimiert. Wenn Du in ein Projekt reinschreibst: unsigned char counter; counter = 1; counter = 2; counter = 3; und versuchst einen Breakpoint auf die Zeile counter=2 zu sezten,dann stoppt der Debugger auch nicht an dieser Zeile da diese im Assembler gar nicht existiert! Will man alle "Raw" Daten beibehalten, muß man die Optimierung komplett abschalten.
Gibt einen Zielkonflikt. Um beim Debuggen nicht über Optimierungseffekte wie wegoptimierte Zeilen und völlig verkorkste Reihenfolge zu stolpern, sollte man eigentlich das Debugging ausschalten. Nur funktionieren die Delays dann nicht wirklich gut.
:
Bearbeitet durch User
A. K. schrieb: > Um beim Debuggen nicht über Optimierungseffekte > wie wegoptimierte Zeilen und völlig verkorkste Reihenfolge zu stolpern, > sollte man eigentlich das Debugging ausschalten. Nur funktionieren die > Delays dann nicht wirklich gut. Deswegen gibt es extra Timer mit Interruptfähigkeit. Das Prozessorleistung verbratende delay() ist dann überflüssig ;-)
Hallo, danke für eure Erklärungen. Das Ausschalten der Optimierung würde ich jetzt mal probieren. Hoffen wir mal, das es funkt ... wenn nicht, lesen wir uns hier wieder ;-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.