Problem mit Quarz und verwendeter UART-Baudrate

[dark emporer]

Ich hatte mal proleme beim compilieren eines quellcodes aus dem internet. Jetzt habe ich von dem autor die hex datei bekommen die ist alerdings für ein 11.059200 MHz quarz gedacht. Ich wollte das nur schnell zum laufen brinngen d.h bestellen dauert zu lange. Kann ich auch ein anderen qwartz verwenden? ich habe 5Mhz 14318.18khz und 16Mhz mein avr ist ein AT90S2313. Wie müsste ich dann mein pc konfigurieren?

[SprinterSB]

Wenn du das gleiche hex verwendest, dann geht die Baudrate linear mit der Quarzfrequenz. Das auszurechnen ist Dreisatz.

Wenn du dein PC (also dein Betriebssystem) so konfigurieren kannst, daß es die bei deinen Quarzfrequenzen entstehenden krummen Baudraten schluckt, bist du fertig.
Oft ist es aber nicht möglich, die Baudrate im OS frei zu wählen.
Dann brauchst du einen 'Baud-Quarz'
1.8432 MHz
3.6864 MHz
7.3728 MHz
11.0592 MHz
14.7456 MHz
18.4320 MHz
22.1184 MHz
etc

Wobei ich den AT90S2313 nicht mehr als 10% übertakten würde (normale Temperatur und Vcc bei 5V).

Die Quelle hast du doch, und übersetzt bekommst du sie auch.
Ist doch kein Problem...

[dark emporer]

das ich das von dir veränderte code compilieren kann hilft mir leider nichts denn die hex datein sind von erstem byte verschiden. funktioniren tut es auch nicht.


ewentuel würde mir auch reihen wenn ich die hex codes zu denn befehlen
irgedwo nachguken könnte.


ldi
out

dann könte ich ewentuel die stelle wo busdratte gesetzt wird finden

[SprinterSB]

avr-gcc (und damit avr-as) erzeugen keinen Intel-Hex-Code.

Beim Compilieren entstehen folgende (temporären) Dateien:

*.c (C-Quelle)
*.i (precompilierte C-Quelle)
*.s (Assembly)
*.o (Object)
*.elf (elf32)

Beim Assemblieren:
*.s (Assembly)
*.o
*.elf

Wenn du nur compilierst (gcc -c ...), erhälst du ein Object-File (*.o), wenn du nur assemblierst (gcc -S ...) eine Assembler-Datei.

Aus den *.o bekommst du nach dem Link (avr-ld) mit deinen anderen Objekten ein *.elf.
Das elf enthält alle Informationen (auch debug-Info etc)

Wenn du nur 1 Quelle hast, kannst du die direkt übersetzen, as und ld werden von gcc aufgerufen (was abgeht siehst du mit gcc -v ...)

Ein hex bekommst du dann mit avr-objcopy aus dem elf:

avr-objcopy -j .text -j .data -O ihex foo.elf foo.hex

Daß die hex-Dateien nicht gleich sind, ist nicht verwunderlich.
Schliesslich übernimmt ld das Lokatieren und das Erstellen der vectab (wo die Interrupts stehen).
Ausserdem hatte ich die Wertetabellen nach hinten gelegt wegen der Übersicht.

[dark emporer]

also ne *.c habe ich garnicht ich habe nur eine main.c und makefile wenn ich make ausfüre gibt er mir das:



E:\D\WinAVR\dss>make
makefile:396: no file name for `-include'

-------- begin --------
avr-gcc (GCC) 3.4.1
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Assembling: main.S
avr-gcc -c -mmcu=at90s2313 -I. -x assembler-with-cpp -Wa,-adhlns=main.lst,-gstab
s main.S -o main.o
main.S:358:81: warning: no newline at end of file

Linking: main.elf
avr-gcc -mmcu=at90s2313 -I. -g -O0 -funsigned-char -funsigned-bitfields -fpack-s
truct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o -std=gnu99 ma
in.o --output main.elf -Wl,-Map=main.map,--cref -lm

Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex

Creating load file for EEPROM: main.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex main.elf main.eep

Creating Extended Listing: main.lss
avr-objdump -h -S main.elf > main.lss

Creating Symbol Table: main.sym
avr-nm -n main.elf > main.sym

Size after:
main.elf :
section size addr
.text 1792 0
.data 0 8388704
.bss 0 8388704
.noinit 0 8388704
.eeprom 0 8454144
.stab 1740 0
.stabstr 35 0
Total 3567



Errors: none
-------- end --------

[SprinterSB]

Jo, und das gibt dir ne main.hex, oder nicht?
Der Fehler bei '-include' ist ein Fehler im Makefile, scheint aber nicht weiter zu stören.

Gesetzt wird die Baudrate hier:


ldi r16,0x05 ; set uart speed to 115.2 kbps
out UBRR,r16

ldi r16,0x98 ; enable RXint and enable tx/rx
out UCR,r16


Die Relation zwischen CPU-Frequenz und Baudrate ist.
16 * (UBRR+1) * BAUDRATE = CPU_FREQ

Der relative Fehler bei der Baudrate sollte 2% nicht übersteigen, was mit deinem 5MHz-Quarz und den von deinem OS angebotenen Bauraten drin ist, musst du eben abchecken.

Welche Opcodes den einzelnen Befehlen zugeordnet sind, siehst du im lst-File.

Zudem gibt's noch folgenden Hack im Code:


ldi r24,0x55 ; setup adder value
ldi r25,0x35 ; to 1 kHz

Das musst du auch alles nachziehen bei geänderter CPU-Frequenz ... so ist das bei Knaup & Hack... ;-)

[dark emporer]

das ich das von dir veränderte code compilieren kann hilft mir leider nichts denn die hex datein sind von erstem byte verschiden. funktioniren tut es auch nicht.

d.h das du da was verändert hast das programm nicht mehr funktioniert

ich kann das leider nicht im system programmiren d.h das ich bei jedem test haunemen muss noch sind die pins heile das endert sich oft schneller als man denken kann.

am libsten würde ich die bautrate in der hex ändern aber ich müsste sie erst finden??

[dark emporer]

Kannst du dan mir bitte mal erklären wiso du der meinung bist das SP auf so gesetzt werden muss?

[SprinterSB]

Ich programmiere ja in C und hab mir eben geschaut, was der gcc so ausspuckt an Assembler-Code und wie man was formulieren muss, und auch, wie er den SP setzt. gcc setzt den SP allerdings auf __stack und nicht auf RAMEND.

Schon in Adresse 0 steht was anderes, weil der rjmp an eine andere Stelle geht: Eben an die Adresse, wo der Code jeweils anfängt. Und diese Adresse kann unterschiedlich sein, ohne daß der Code deshalb falsch ist.

Ich hab den Code nochmals überflogen.
Ich würd dir vorsichtig raten, das Zeug zu vergessen.
Wenn ich's recht sehe ist die komplette Interrupt-Programmierung darin fehlerhaft:
- das Status-Register wird nicht gesichert --> im Hauptprogramm werden falsche Werte berechnet (sporadisch, wegen korruptem C-Flag)
- das Hauptprogramm ist nicht auf Interrupts vorbereitet --> im Hauptprogramm werden falsche Werte berechnet (sporadisch, denn die Addition in LOOP1 ist nicht atomar).

Wenn du kein ISP hast ist das natürlich recht misslich und guter Rat teuer...

Wie wärs zB mit einem kleinen Steckboard, da hat man mal fix ne kleine Schaltung aufgebaut ohne rumzulöten -- ok, nen Adapter für SUBD9 musst du löten und evtl einen für ISP, aber das nur ein mal.
Du kannst dann über ISP proggen und via LED (zB) ergendwas anzeigen, ob dein Prog was macht oder da landet, wo es soll.

Ist nur n Vorschlag, weil so holst du dir nur den Frust und ruinierst dir die Nerven, vor allem wenn man erst anfängt damit und erst mal nix geht und man noch lernt (das tut man immer).

::EDIT::

Das sieht dann etwa so aus:

http://s-huehn.de/elektronik/avr-prog/avr-test1.jpg

Die Dinger gibt's bei Conrad.
Sind zwar nicht billig wie alles beim C, aber ich möcht es nicht mehr missen. Bis heute hab ich kein 'richtiges' Board. Platinen lass ich erst machen, wenn die Schaltung stabil ist.

[dark emporer]

na ja mittlerweile habe ich das vergessen. Also die hex file hat wunderbar funktioniert d.h das programm ist richtig nur der comliler falsch. So eon stkbord habe ich auch das war nicht das problem und ätzen löten sowiso nicht. Das enzige problem momentan ist das ich kein passenden quartz habe d.h die verbndung zum rechner geht nicht. Ein zu bestellen geht auch schlecht mindestbestelbwert usw ...

Ich lase das erstmal wenn ich zeit habe schreibe ich mir das selbst in C

Danke für eur bemühen