- 12V Akku mit 280 Ah bauen         
Seite 3 von 3 ErsteErste 123
Ergebnis 21 bis 27 von 27

Thema: RN-Control 1.4: Hex erstellen für Übertragung per RS232

  1. #21
    Erfahrener Benutzer Robotik Visionär Avatar von Hubert.G
    Registriert seit
    14.10.2006
    Ort
    Pasching OÖ
    Beiträge
    6.220
    Anzeige

    Praxistest und DIY Projekte
    Wenn du einen 16MHz Quarz laut Datenblatt anschaltest passt es so.
    Wenn dieser Mega32 dann läuft versorgst du deinen alten M32 mit Spannung und machst eine Verbindung von neu XTAL2 auf alt XTAL1.
    Damit hast du einen ext. Takt auf deinem alten M32 und dann kannst du auch bei diesem die Fusebit umstellen, denn kaputt ist er sicher nicht.
    Grüsse Hubert
    ____________

    Meine Projekte findet ihr auf schorsch.at

  2. #22
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.653
    Zitat Zitat von adso
    ... ein wenig herumgespielt und geschafft, die Fusebits ... gab wieder die tiefen Töne ...
    So etwas kommt schon mal vor.
    Zitat Zitat von adso
    ... einen Kollegen (Er erzählte mir, er arbeite viel mit Ponyprog ...) gefragt...
    Warum sollte auch ein persönlich bekannter Kollege schlechter sein als wir anonymen AVRholiker? Das ist garnicht spöttisch gemeint. Könnte mir auch so gehen.

    Zitat Zitat von adso
    ... ich hätte alle Kreuzlein invertieren müssen ...
    Dumm gelaufen.
    Zitat Zitat von oberallgeier am: 27 Nov 2008, 21:26
    ... dann guck Dir mal diesen Fuse-Rechner an ...
    Zitat Zitat von McJenso am 01 Dez 2008, um 17:31
    ... ansonsten noch der Link auf den beliebten fusebit calculator ...
    In diesem Fusebitrechnern steht das mit dem Invertieren etwa so drin. Leider ist das nicht WIRKLICH einfach verständlich dargestellt. Da fallen viele drauf rein.

    Zitat Zitat von adso
    ... Vielleicht wäre es an der Zeit ein Beispiel in RN Wissen fürs RN-Control mit C anzulegen ...
    Ganz unten auf der RNControl-Seite steht der passende Link dazu.

    Zitat Zitat von adso
    ... Ich habe jedoch bereits einen neuen ATMEGA32 bestellt ...
    Na ja, für weitere Spielereien gibts ja nun den neuen Trick von Hubert.G - übrigens danke Hubert.G dafür, damit hatte ich erst kürzlich zwei Controller gerettet.
    Ciao sagt der JoeamBerg

  3. #23
    Neuer Benutzer Öfters hier
    Registriert seit
    19.10.2007
    Alter
    35
    Beiträge
    27
    der 16MHz quarz ist sicherlich richtig geschaltet -> RN-Control

    Mit meinen wenigen Widerständen, Quartze, … zu Hause ist das so eine Sache mit dem neu Ansteuern. Nach Schaltplan müsste ich ca 10 Pins ansteuern (6, 7, 8, 9, 10, 11, somit 13, 30, 31, 32) ohne Wirkliche Ausstattung spende ich lieber 10 € für einen neuen Atmega. Der alte Atmega werfe ich sicherlich nicht fort und vielleicht ergibt sich einmal etwas.
    Gibt es sonst keine Fehler in den Fusebits?

  4. #24
    Neuer Benutzer Öfters hier
    Registriert seit
    19.10.2007
    Alter
    35
    Beiträge
    27
    So, habe heute den ATmega bereits bekommen. Natürlich direkt ausgewechselt und versucht zu programmieren.
    *grins* ich bekam immer den Fehler, dass Ponyprog den MIC nicht findet. *grins* ... bis ich gemerkt habe, dass das Netzteil nicht eingeschaltet war *grins*

    Naja, jetzt funktionierts. Leider ist das mit den tiefen Tönen wieder da. Ich habe gleich ein Programm geschrieben, das mir über die RS232 Schnittstelle im Sekundentakt was ausgibt. Das klappt auch. (Jede Sekunde, nicht jede 2. Sekunde). Also Zeitlich funktioniert das Ganze. Für mich heisst das, dass auch die Taktfrequenz stimmen müsste.
    Code:
    	for (unsigned char i=0; i<50; i++){
    		sendUSART("Jetzt");
    		setportcoff(0);
    		waitms(150);
    		setportcon(0);
    		waitms(850);
    	}
    Dann habe ich die Soundausgabe unter die Lupe genommen. Die Funktion ist ja sound(höhe, länge) und die Ausgabe sieht dann so aus: es ist eine Schleife, die einige Male durchlaufen wird, bis sie die Zahl der Länge erreicht hat. In der Schleife wird der Port aktiviert, x millisekunden gewartet, ausgeschalten und x millisekunden gewartet, bis die Schleife von neuem Startet (x=höhe). daraus ergibt sich eine Frequenz von f=1/(2*Höhe) [kHz]. Beim Beispiel wird u.A. auch Höhe=7 angenommen, was zu einer Frequenz von 71 Hz führt. Es muss also beim Beispielprogramm in C so tief sein. (Nach mir wird f=440Hz für Musikinstrumente zum Stimmen gebraucht, aber nur so als Vergleich.)

    Code:
    	sound(6, 270); //Startmelodie
    	sound(8, 270);
    	sound(11, 270);
    	sound(7, 270);
    	waitms(10);
    	sound(7, 270);
    	sound(6, 270);
    	sound(11, 540);
    und

    Code:
    void sound(uint8_t hoehe, uint16_t laenge)
    {
    	for(uint16_t i=0; i<laenge*15; i=i+(2*hoehe))
    	{
    	setportdon(7);
    	_delay_ms(hoehe);
    	setportdoff(7);
    	_delay_ms(hoehe);
    	}
    }
    und ich dachte schon ...
    Hat jemand eine Funktion, bei der man also anstatt einer Maximalen Frequenz (höhe=1 -> Frequenz=500), eine Ausgabe mit sound (frequenz, länge in ms) hat?

    Jetzt hab ich also den Fehler, es war nicht die Arbeitsfrequenz des Atmega, sondern ein Denkfehler, dass die Töne standartmässig höher sein müssten.

    Gruss und Dank

  5. #25
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.653
    Zitat Zitat von adso
    ... tiefen Tönen wieder da ... Programm ... das ... im Sekundentakt was ausgibt ...
    Hmmm, und wie entsteht der Sekundentakt?
    Zitat Zitat von adso
    ... waitms(150); waitms(850); ...
    Aha. Dem waitms traue ich nie. Aber der Test ist für diesen Zweck wohl einigermaßen ok. Wie sehen Deine Fuses aus? Sind die mit dem Vorschlag des fuse calculators abgestimmt?

    Ich habe mir vor Zeiten eine Routine geschrieben, die den Hardwaretimer des aktuellen µC´s benutzt und einen 50 µs-Takt erzeugt (Code für m168 ist hier gezeigt) . Da zähle ich in der ISR z.B. von 1 rauf auf 20 000 - das ist dann genau 1 sec. - - - und zwar nur dann, wenn der zugrundegelegte Takt auch stimmt. Übrigens flackert während meiner Hard+Softwareentwicklung fast immer eine LED (meist auf dem sowieso aufgebauten I2C-Stecker), die im Sekundentakt auf-und-ab-schaltet - solange Interrupt enabled ist. Die lasse ich auch nach dem Reset aber vor dem Erlauben der Interrupts kurz blitzen _ - und hier kommt eine meiner wenigen waitms-Anwendungen. Ein oder zwei Sekunden lang 3/97 waitmsse. Eine sehr praktische Einrichtung, um gelegentlich pannenweise auftretende Interrupts zu entdecken und der Sekundentakt zeigt mir sofort Taktprobleme.

    Aber jetzt scheint ja bei Dir alles im Lot zu sein.
    Ciao sagt der JoeamBerg

  6. #26
    Neuer Benutzer Öfters hier
    Registriert seit
    19.10.2007
    Alter
    35
    Beiträge
    27
    Ok, das mit dem Sekundentakt hab ich nochmals angeschaut -> ist wirklich dumm gemacht und hat eine sehr hohe Abweichung.

    Das mit dem Calculator habe ich nochmals angeschaut.
    In dem Fall kommt es mir so heraus:
    [ ] OCDEN
    [ ] JTAGEN
    [ ] CKOPT
    [ ] EESAVE
    [X] BOOTSZ1
    [X] BOOTSZ0
    [ ] BOOTRST
    [ ] BODLEVEL
    [ ] BODEN
    [ ] SUT1
    [ ] SUT0
    [ ] CKSEL3
    [ ] CKSEL2
    [ ] CKSEL1
    [ ] CKSEL0

    (Auswahl:
    Ext. Clock, Start-up-time: 6CK +64ms, [CKSEL=0000 SUT=10]
    Alle Kreuzlein deaktiviert (da ich offenbar davon nichts brauche,
    BodLevel=1, Bootsz=01)

    Ist vielleicht eine saudumme Frage, aber ich muss die Häckchen im Ponyprog genauso wie im Fuse Calculator setzten, also nicht invertiert? Und seid ihr mit der Auswahl zufrieden? Jetzt muss es fast einmal stimmen. Doch meine Frage: Wie erkennt der MIC ob es ein 16MHz oder ein 8MHz Quarz ist?

    Gruss und Dank
    Euer Adso

  7. #27
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.653

    Q

    Hallo adso,

    der waitms-(Sekunden-)Takt ist praktisch, aber eben von der Sorte "quick ´nd dirty".

    Deine Fuses sind ja ganz ok - ich nehme an, Du hast da den Bootloader drin? Sonst würde der viele Bootloader-Speicherplatz nicht recht Sinn machen. Ich habe bei meinem selbst geflashten M32 diese Fuses. (Anm.: gerade ausgelesen - extra für Dich - mit PonyProg aus dem m32 in der RNControl mit meinem selbst geschriebenen/compilierten/geflashten Testprogramm).

    Die Fuses im PonyProg setzt Du so wie im attachement gezeigt, wenn Du Deine Auswahl "drin" haben willst.

    ... Doch meine Frage: Wie erkennt der MIC ob es ein 16MHz oder ein 8MHz Quarz ist? ...
    Tja, das ist die Frage. Soweit ich es weiß, erkennt der Quarz das garnicht *gggg* (ist nicht spöttisch gemeint - es ist eben so --- woher weiß Dein Auto, dass in der Stadt nur 50 gefahren werden darf?). Du sagst das dem µC im Quelltext, so nach der Art (hier für meinen m168 mit 20 MHz):
    Code:
    #define MCU = AVR_ATmega168
    #define F_CPU  20000000         // Quarz 20 Mhz-CPU
    Eine andere Möglichkeit, den Quarztakt zu definieren ist es auch, den Wert im makefile oder im Compiler reinzuschreiben (mit Beidem habe ich null Erfahrung - ich mache es immer so, wie es oben steht).
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken bsz10.jpg  
    Ciao sagt der JoeamBerg

Seite 3 von 3 ErsteErste 123

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Solar Speicher und Akkus Tests