mikrocontroller

[marvin]

Hi Timo,

hmm, gute Frage. Die Kommandozeilen Parameter habe ich auch nur irgendwo abgekupfert ohne groß nachzudenken.

In der Avrdude Doku steht zu -u folgendes:

[pre]
-u Disables the default behaviour of reading out the fuses three times before programming,
then verifying at the end of programming that the fuses have not
changed. If you want to change fuses you will need to specify this option, as
avrdude will see the fuses have changed (even though you wanted to) and will
change them back for your "saftey". This option was designed to prevent cases
of fuse bits magically changing (usually called safemode).[/pre]

wenn ich das richtig verstanden habe, sollte man -u also explizit verwenden, wenn man die Fuses setzen will.

Gruß marvin

[eax]

Hi marvin,

also ich dachte bisher immer, das deaktiviert nur den "Safemode" und der macht beim Fuse Bit schreiben IMHO gar keinen Sinn.
Ich habe meine Fuse Bits immer ohne -u geschrieben, ging einwandfrei jedes Mal, darum war ich vorhin verwundert.

Gruß Timo

[Frutiger]

@marvin,
@eax,
inzwischen habe ich dem m644 die Fuse Bits untergejubelt und konnte sie auch wieder auslesen.

Es hat also alles prima funktioniert, Danke an Euch.
Nun sind die Sensoren an der Reihe...

[eax]

bitte und viel Erfolg mit den Sensoren!

Gruß Timo

[Frutiger]

es mußte so kommen ... ... mein c't-Bot macht das, was in diversen
Foren bereits beschrieben wird: Er dreht sich nach dem Einschalten nur
im Kreis und das Display zeigt bloß zwei Balken. Die LEDs leuchten mit
jedem Reset eine nach der anderen auf, sehr hübsch.

Wenn ich meinem ollen Oszi glauben darf, dann schwingen keine 16 MHz
an XTAL1/2.
Daten werden beim flashen geschoben. Allerdings habe ich noch kein
Programm, das für den m644 übersetzt wurde, ausprobieren können. Kann
mir da wer aushelfen? Ein einfacher LED-Test wäre hier genau das Richtige.


-- EDIT:
Ich hatte wie beschrieben auf ein Softwareproblem getippt und begab
mich in's Trainingslager .
Die bereits weiter oben genannten Fuse Bits sind ok. Damit der Bot mit
seiner Anzeige etwas Sinnvolles anzeigen kann, ist ganz offensichtlich
ein für den m644 erstelltes Programm notwendig.
Das mag für alte Projekthasen ein Selbstgänger sein, ist jedoch wegen
der Pinkompatibelität zum m32 irreführend.
Um halbwegs schnell zu einem Ergebnis zu kommen muß also das
komplette Paket, wie in der c't beschrieben, installiert werden (und dort
lauern dann weitere Fallen). Anschließend können dann die c't-Quellen
übersetzt und ausprobiert werden.

[mkosch]

Was habt ihr mit dem Takt gemacht. Der ATMega32 schafft ja nur 16MHz, der 644 schafft 20MHz. Hat sich jemand schon an den Quarzaustausch gemacht?

Den Quarz von meinem c't-Bot habe ich jetzt ausgetauscht. (Und bei der Gelegenheit noch einige andere Änderungen an der Hauptplatine vorgenommen.)

Das einzige Problem hatte ich im Prinzip mit dem Treiber für den Fernbedienungssensor, weil das Timing nicht mehr gestimmt hat. Außerdem musste ich den Timer-Interrupt anpassen, damit die interne Zeit wieder korrekt zählt.

Ich verwende jedoch nicht den offiziellen Code vom c't-Bot, sondern habe ihn komplett selbst programmiert. Beim offiziellen Code wird man wahrscheinlich auch die Multiplikatoren für den TWI- und SPI-Bus anpassen müssen, falls der Takt sonst die zulässigen Grenzwerte übersteigt. Mit USART habe ich mich noch nicht beschäftigt.

Es sollten jedoch nur sehr kleine Änderungen notwendig sein.

[QuisaZaderak]

Den Quarz von meinem c't-Bot habe ich jetzt ausgetauscht. (Und bei der Gelegenheit noch einige andere Änderungen an der Hauptplatine vorgenommen.)

Welche Änderungen wenn ich neugierig fragen darf ?

[mkosch]

Welche Änderungen wenn ich neugierig fragen darf ?

Weil ich keine Transportfachverriegelung an meinen Roboter anbauen möchte, habe ich den Klappen-Sensor demontiert. Dadurch wurde eine E/A-Leitung und eine Enable-Leitung frei. Die Enable-Leitung habe ich so verdrahtet, dass ich damit die Hintergrundbeleuchtung des LCD-Displays per Software aktivieren/deaktivieren kann. (Eventuell lässt sich durch eine entsprechende Steuerung etwas Strom sparen.)
Außerdem habe ich den Widerstand von 20 Ohm nach 10 Ohm getauscht, damit das Display heller leuchtet. (Dazu muss ich sagen, dass das Display bereits selbst integrierte Widerstände hat und es also immer noch dunkler ist als "normal". Das spart auch etwas Strom.) Leider musste ich erfahren, dass der BS250 auch etwa 9 Ohm hat, weswegen im Endeffekt nichts heller leuchtet.

Nun habe ich zwei freie E/A-Leitungen. (Auch noch die an PC5.)
Beide habe ich auf die nicht benutzten Anschlüsse am Stecke für die Maussensorplatine gelegt. Damit plane ich, noch eine eigene Erweiterung (geplant sind ein weiterer Atmega644 mit einige Sensoren, SpeakJet, Piezo-Pieper, Echtzeituhr und eventuelle meine alte Conrad-Funkuhr für den Parallel-Port, vielleicht auch noch ein paar Mikroschalter rundherum zum Erkennen von Kollisionen) per SPI-Bus anzubinden, die ich dann einfach über diesen Stecker anschließen kann.

Die Servo-Anschluss PB3 plus den Anschluss PB4 habe ich davor mit den beiden freien Leitungen vertauscht. Nun hängen beide Servo-Anschlüsse am Timer/Counter 2 und nicht mehr an 0, sodass es keine Kollisionen mit dem Software-Timer gibt, falls ich irgendwann mal 2 Servos anschließen sollte. PB4 ist der "SlaveSelect"-Anschluss vom SPI-Bus. Das hat unter anderem praktische Gründe, weil ich dann nicht mehr beachten muss, dass die Leitung während SPI-Transfers LOW wird und sie auch selbst für SPI-Transfers verwenden kann.

Für die ganzen Änderungen musste ich nur ein paar Leiterbahnen unterbrechen und 7 kleine Drahtstücke auf der Unterseite der Platine anlöten. Allerdings habe ich auf der WLAN/MMC-Platine auch nicht den Servo-Patch angebracht, weil er sonst am falschen Pin hängen würde.
Wenn ich nicht schon alles wieder zusammen geschraubt hätte, könnte ich ein Bild davon machen. Vielleicht stelle ich es bei der nächsten Gelegenheit in meine Galerie.