RN-Control und AVR STudio/GCC probleme

ich habe anscheinend ein Problem mit meinem avr-gcc compiler
ich versuche das mitgelieferte testprogramm in das RN-Control (1.4) zu laden, aber als quittung bekomme ich nur ein "stotteriges" Piepen

habe schon versucht mit MFile ein Makefile hin zu bekommen aber auch das hat mir nichts gebracht, natürlich habe ich auch das mitgelieferte Makefile getestet...ohne erfolg

Ich habe mal versucht das Bascom Testproject in den Controller zu laden, das klappt, aber ich würde lieber in C schreiben

Hat jemand einen Vorschlag woran es sonst liegen könnte?

Danke und Gruß
Lineage

Wenn man annimmt das das Programm selbst OK ist, dann könnten es falsche Fusebits sein oder Quarzfrequenz nicht richtig angegeben.

ich gehe davon aus das das programm selbst in ordnung ist, da es das vom roboternetz als demo vorgestellte programm ist und daher sicherlich schon genug tests durchlaufen hat.

mit den fusebits/Quarzfrequenz da muss ich nachher mal nach gucken

also anscheinend funktioniert das programm richtig....nur viel zu langsam
...für einen 16MHz quarz habe ich in der configuration eine frequenz von 16000000 (16Millionen) Hz eingetragen und die CKSEL Bits auf Ex. Crystal High Freq. und Startup 16K CK + 64 ms eingestellt.
hoffe das ist so richtig...wenn nicht wäre ich für eine korrektur dankbar

Fuses sollten so richtig sein.
Wenn ich das jetzt richtig lese, dann funktioniert das BASCOM Demo?
Wenn das so ist, dann müsste doch das C-File eine Make haben. Das kenne ich allerdings nicht.

ja die Bascom Demo läuft
und ja zu dem C-File gibt es eine Make....aber mit der läufts auch nicht
ich habe das gefühl das ich probleme mit dem Takt habe oder das der controller irgendwo immerwieder festhängt und das dadurch alles stark ausgebremst wird (die Töne die aus dem Piepser kommen sind sehr lang und haben dafür eine etwas zu niedrige frequenz (hab ich nicht gemessen) auch alles andere ist sehr langsam (lauflicht etc.)
deshalb kann ich mir nicht so richtig erklären wo das problem zu suchen ist

Wenn das BASCOM-Demo läuft, müssen die Fuses OK sein.
Kannst du das C-File hier mal herein stellen.
Womit kompilierst du? AVR-Studio?

ja avr studio (winavr gcc plugin)

Code:

/* ################################################### RNControl-Test.c Aufgabe: Dieses Testprogramm testet gleich mehrere Eigenschaften auf dem Board Den verschiedenen Tasten sind bestimmte Funktionen zugeordnet Taste 1: Zeigt Batteriespannung über RS232 an Taste 2: Angeschlossene Motoren beschleunigen und abbremsen Taste 3: Einige Male Lauflicht über LED´s anzeigen. Am I2C-Bus darf in diesem Moment nichts angeschlossen sein Taste 4: Zeigt analoge Messwerte an allen Port A PIN´s über RS232 an Taste 5: Zeigt digitalen I/O Zustand von PA0 bis PA5 an Sehr gut kann man aus dem Demo auch entnehmen wie Sound ausgegeben wird, wie Tasten abgefragt werden und wie Subroutinen und Funktionen angelegt werden Autor: Georg Richter ####################################################### */ #include <stdlib.h> #include <avr/io.h> #include "rncontrol.h" /*### Variablen ###*/ const float referenzspannung = 0.0048828125; //Referenzwert zur Multiplikation mit den Werten der Analogports (0...1023), um auf die Voltzahl zu kommen (0...5). Ergibt sich aus 5/1024. uint16_t analog; //Variable für jeweils an einem Analogport gemessenen Wert, um nicht für eine Ausgabe mehrere Messungen durchführen zu müssen. char wort[5]; //Zahlen (Integer und Float) müssen vor der Ausgabe per RS232 in ASCII-Zeichen konvertiert werden, für die ein Speicher benötigt wird. /*### Batteriespannung ###*/ void Batteriespannung(void) { sendUSART("Analog6 = "); analog = adcwert(6); utoa(analog, wort, 10); sendUSART(wort); sendUSART(" = "); dtostrf(analog*referenzspannung, 11, 8, wort); sendUSART(wort); sendUSART(" Volt\r\n"); dtostrf(adcwert(6)*referenzspannung*5.66804, 11, 8, wort); sendUSART("Batteriespannung = "); sendUSART(wort); sendUSART(" Volt\r\n\n\n\n"); waitms(300); } /*### Motortest ###*/ void Motortest(void) { Mlinksvor(); Mrechtsvor(); setPWMlinks(0); setPWMrechts(0); waitms(40); for(uint8_t i=0; i<255; i=i+5) { setPWMlinks(i); setPWMrechts(i); waitms(40); } setPWMlinks(255); setPWMrechts(255); waitms(40); for(uint8_t i=255; i>0; i=i-5) { setPWMlinks(i); setPWMrechts(i); waitms(40); } setPWMlinks(0); setPWMrechts(0); Mlinksstop(); Mrechtsstop(); waitms(300); } /*### LED-Lauflicht ###*/ void Lauflicht(void) { for(uint8_t i=0; i<10; i++) { setportcoff(0); waitms(150); setportcon(0); setportcoff(1); waitms(150); setportcon(1); setportcoff(2); waitms(150); setportcon(2); setportcoff(3); waitms(150); setportcon(3); setportcoff(4); waitms(150); setportcon(4); setportcoff(5); waitms(150); setportcon(5); waitms(300); } } /*### Analogwerte ###*/ void Analogwerte(void) { //Alle internen Pullups an, ausgenommen Port A3 und Batteriespannung/Taster (A6 und A7). Da A3 aber nun auch nicht auf GND liegt, ergibt sich ein "Rauschen", der Wert variiert mit jeder Messung mehr oder weniger stark. setportaon(0); setportaon(1); setportaon(2); setportaoff(3); setportaon(4); setportaon(5); for(uint8_t i=0; i<8; i++) { analog = adcwert(i); //Messung Analogport [i] utoa(i, wort, 10); sendUSART("Analog"); sendUSART(wort); sendUSART(" = "); //Ausgabe: "Analog[i] = " utoa(analog, wort, 10); sendUSART(wort); sendUSART(" = "); //Ausgabe: "[Analogwert] = " dtostrf(analog*referenzspannung, 11, 8, wort); sendUSART(wort); sendUSART(" Volt\r\n"); //AUsgabe: "[Reale Voltzahl] Volt[Umbruch]" } sendUSART("\n\n\n"); waitms(300); } /*### Digitalwerte ###*/ void Digitalwerte(void) { //Einige interne Pullups an, andere aus -> gibt bei einigen "Rauscheffekt", mal misst er "high", mal "low" und mal irgendwas dazwischen "?". //Ein kleines Stückchen Draht an einem der Ports wirkt wahre Wunder, was das Rauschen betrifft -> viel öfter "low" dabei als ohne. Nachteil: Die Tastenerkennung funktioniert kaum noch. setportaoff(0); setportaon(1); setportaoff(2); setportaon(3); setportaon(4); setportaon(5); for(uint8_t i=0; i<8; i++) { utoa(i, wort, 10); sendUSART("Digital"); sendUSART(wort); sendUSART(" = "); //Ausgabe: "Digital[i] = " if (PINA & (1<<PINA0)) {sendUSART("high");} else {sendUSART("low");} //Abgleich des Zustandes - Ausgabe: "high" oder "low" sendUSART("\r\n"); } sendUSART("\n\n\n"); waitms(300); } /*### Hauptschleife ###*/ int main(void) { /*###Initialisierungsphase###*/ //Pins bzw. Ports als Ein-/Ausgänge konfigurieren DDRA |= 0x00; //00000000 -> alle Analogports als Eingänge DDRB |= 0x03; //00000011 -> PORTB.0 und PORTB.1 sind Kanäle des rechten Motors DDRC |= 0xFF; //11111111 -> PORTC.6 und PORTC.7 sind Kanäle des linken Motors, Rest sind LEDs für Lauflicht DDRD |= 0xB0; //10110000 -> PORTD.4 ist PWM-Kanal des linken Motors, PORTD.5 des rechten //Initialisierungen setportcon(0); setportcon(1); setportcon(2); setportcon(3); setportcon(4); setportcon(5); //LEDs ausschalten setportdoff(7); //Speaker aus init_timer1(); //Initialisierung Timer für PWM init_USART(); //USART konfigurieren /*###Hauptschleife###*/ sound(6, 270); //Startmelodie sound(8, 270); sound(11, 270); sound(7, 270); waitms(10); sound(7, 270); sound(6, 270); sound(11, 540); sendUSART("\r\n\n\n"); //Sendet einen kleinen Begrüßungstext. "\r" setzt den Cursor wieder auf Zeilenanfag, "\n" beginnt dann die nächste Zeile sendUSART("**** RN-CONTROL 1.4 *****\r\n"); sendUSART(" \r\n"); sendUSART("Fuer C umgeschrieben Version des mitgelieferten\r\n"); sendUSART("Bascom-BASIC Beispielprogramms inkl. eigener\r\n"); sendUSART("Header-Datei mit wichtigen Grundfunktionen.\r\n"); sendUSART(" \r\n"); sendUSART("Vielen Dank an die RN-Community fuer ihre Hilfe!\r\n\n\n\n"); Mlinksstop(); Mrechtsstop(); setPWMlinks(0); setPWMrechts(0); while(1) { switch(button()) { case 1: Batteriespannung(); break; case 2: Motortest(); break; case 3: Lauflicht(); break; case 4: Analogwerte(); break; case 5: Digitalwerte(); break; default: break; } } return 0; }

wie gesagt der Demo Code aus der community

Wenn du unter Project / Configuration Options die richtige Frequenz eingestellt hast, sollte alles stimmen. Zum testen fehlt mir noch die rncontrol.h .

Zitat:

Zitat von Hubert.G

... Zum testen fehlt mir noch die rncontrol.h ...

Beide Teile des Demoprogramms stehen hier im RNWissen.

Als ich meine RNControl in Betrieb genommen hatte, habe ich zum Üben gleich zwei fabrikfrische mega32 dazubestellt. Original mit Demoprogramm und bootloader kopiert, Fuses ausgelesen und notiert, originalen Controller raus, fabrikfrischen m32 rein, Fuses nach dem Original gesetzt und den kopierten File geflasht. Lief einwandfrei - warum auch nicht. Danach das Demo compiliert und geflasht. Soweit ich weiß, lief das ebenfalls problemlos. Aufgefallen war mir, dass zwar das Demoprogramm brav publiziert wurde, aber von Fuses steht dort nix geschrieben - da darf man alleine durch . . . . . Wenn meine Notizen stimmen, war damals SPIEN (klar), BOOTSZ1 und BOOTRST gesetzt.

Später gabs dann mal mit einem neuen m32 Probleme mit JTAGEN.

das kann ich nachher mal testen (hab noch einen m32 da)

So habs probiert. ...original C-File, original Header und das auf einen neuen m32 (Fuses hab ich vom Alten kopiert)
SPIEN
Bootsz size=1024 address 3C00
Bootrst
sut_CKsel Ext.Crystal High Freq. 16K ck+64ms

in der config hab ich 16000000 Hz eingestellt (16 Millionen /16MHz)

probleme bestehen wie gehabt.

Also da ist doch ein Wurm im Programm. Kann allerdings nur das Piepen testen.
In der rncontrol.h habe ich bei sound das _delay_ms durch waitms ersetzt und in der Funktion waitms den Wert __c = 400 eingegeben, anstelle 4000.
Kann nicht sagen wie sich das auf das Lauflicht auswirkt.

Setze am besten mal F_CPU von Hand, damit auch wirklich sichergestellt wird, dass im Programm mit 16000000 Hz gearbeitet wird. Achte auch auf Warnungen wie "warning: F_CPU redefined" die ein Hinweis darauf sein können, dass im Quelltext F_CPU an irgendeiner Stelle auf einen falschen Wert (mit dem dann weitergearbeitet wird) gesetzt wird.

(Falls du es noch nicht weißt, dass Makro F_CPU wird von z.B. util\delay.h zur Zeitberechnung verwendet. Setzen mit #define F_CPU 16000000ul)

mfg

Die F_CPU mit 16000000 stimmt, sonst würde der UART nicht funktionieren.

habe zuerst F_CPU getestet...ohne erfolg

danach habe ich das _delay_ms durch waitms ersetzt....das hat zumindest einiges an verbesserung gebracht (Der Controller ist jetzt fast so flott wie mit dem Bascom Compilat)
vorrübergehend werde ich mir mit Bascom etwas aushelfen um wenigstens meine ersten schritte mit dem Atmel zu machen.
ich denke das problem liegt in der erzeugung der verzögerungen (_delay_ms) und da werde ich mich demnächst mit befassen

vielen dank an alle für die hilfe.
Gruß
Lineage

selbes Problem mit Eclipse

Hallo miteinander, ich habe auch das Problem, dass das Programm zu langsam abläuft. RN-Control 1.4 16 MHz, fertig aufgebaut gekauft von robotikhardware.de . Die Fuses müssten daher doch auf den Quarz mit 16 MHz passend voreingestellt sein, oder? _delay_ms durch waitms ersetzen sowie in der Funktion waitms den Wert __c = 400 anpassen hat geholfen, aber ich würde gerne verstehen, warum das so ist. Wenn das Programm für einen 16MHz-Quarz geschrieben ist, warum muss ich dann diese Werte anpassen? RS232-Ausgabe in Hyperterminal funktioniert, ich benutze Eclipse mit AVRDude.

Eiegntlich müsste _delay_ms bei korrekt gesetzten Fuses und F_CPU funktionieren (hat es bei mir zumindest immer getan).

Zitat:

Die Fuses müssten daher doch auf den Quarz mit 16 MHz passend voreingestellt sein, oder?

Bei neuen AVRs ist standartmäßig ein interner Takt von 4 MHz eingestellt (sofern sie nicht schon programmiert wurden).

mfg

Ja, kommt mir eben deswegen ja auch komisch vor. Laut AVRDude sind meine Fuses Low EF , High D9. Hab mir mal über http://www.engbedded.com/fusecalc/ die Sache angeschaut mit diesen Werten, scheint doch eigentlich zu passen so. Weiss aber nicht, ob ich das alles richtig deute. In dem Beispielcode ( http://www.rn-wissen.de/index.php/RN...oprogramm_in_C ) ist der Wert F_CPU nicht defined. Hab das mal mit #define F_CPU 16000000UL vor dem include <util/delay.h> gemacht, zeigt aber keine Änderung. Kann jemand, der mit Fuses Erfahrung hat, mir mal sagen, ob der Proz mit Quarz 16 MHz getaktet ist anhand obiger Fuse-Werte. Und ob das JTAG so steht, daß mir alle Ports zur Verfügung stehen (hab kein JTAG Debugger oder sowas). Danke im Voraus...

Zitat:

Zitat von michl78

... Hab mir mal über http://www.engbedded.com/fusecalc/ die Sache angeschaut mit diesen Werten, scheint doch eigentlich zu passen so ...
... Kann jemand, der mit Fuses Erfahrung hat ...

Diese Frage verstehe ich jetzt nicht. Im Fusecalculator kannst Du Dir die Fuses auf Low EF , High D9 einstellen, [Apply Values] drücken - und dann anschauen. Der Calculator sagt doch ALLES ! (Anmerkung: manchmal lohnt es, eine Seite runterzuscrollen).

Ja das hab ich ja gemacht, hatte ich ja auch geschrieben. Wollte das halt von jemand mit Ahnung bestätigt haben. Bin mir nicht ganz sicher, weil ich gelesen habe ( http://www.mikrocontroller.net/articles/AVR_Fuses ): "Bei Atmel AVR µCs heisst eine Fuse setzen (programmieren) übrigens, dieses Bit auf Null zu setzen". Wäre klasse, wenn mir jemand meine Frage beantworten könnte, ob mein RN-Control richtig gefused ist...

Dein RN-Control ist richtig gefused.
Das ganze ist ein Compiler-Problem. Es funktioniert nicht richtig wenn man dem _delay_ms eine Variable übergibt. Der Compiler optimiert dann da einiges weg.
Du brauchst nur die Optimierung abschalten, dann hast du den richtigen ton.

Danke für die Hilfe, werde ich mal ausprobieren, klingt plausibel.

EDIT: Bevor ich es probieren kann, habe ich mich noch etwas schlau gemacht: http://www.nongnu.org/avr-libc/user-...il__delay.html erklärt den Sachverhalt ganz gut.
Speziell der Auszug: "In order for these functions (_delay_ms und _delay_us) to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known CONSTANT at compile-time. If these requirements are not met, the resulting delay will be much longer" ist für mich die Erklärung des Problems.

Zitat:

Du brauchst nur die Optimierung abschalten, dann hast du den richtigen ton.

Und auch einen speicherfressenden Code. Der Compiler sollte nichts optimieren, wenn die entsprechedne Variable mit volatile deklariert wird, also z.B. volatile int iTest;
Probiere das mal aus.