Servus alle miteinander....

Steinschnüffler

Neues Mitglied
21. Feb. 2009
5
0
0
Sprachen
Hallo zusammen,
ich bin schon seit einiger Zeit in verschiedenen Foren fleissig am lesen...
habe auch schon einige Programme/Projekte realisiert (learning by doing..)
hat eigentlich alles mehr oder weniger recht schnell geklappt.

Komme vom schönen Bodensee bin 44 Jahre alt.

Nun hab ich auch gleich mal ne Verständnisfrage(ich schreib sie jetzt hier, daich nicht richtig gewusst habe in welchen Fred ich sie schreiben soll:(hoffe das geht i.O.)

wenn ich z.B. einen Atmega8 habe und ihn intern mit "$crystal = 1000000"
takte und einen Wait-Befehl mit WAIT 1 ( also 1 sec) im Programm habe, dann passt es und im Programm wird eine Sekunde gewartet.... wenn ich aber einen höheren $crystal eingebe dann wird aus der Sek erheblich mehr????
Da stehe ich irgendwie auf dem Schlauch und verstehe es einfach nicht!!

Also vielleicht kann mir das ja jemand kurz erklären, vielen Dank schon im voraus.

Viele Grüße
Heinz
 
Hallo und Willommen.

Ich verabscheue Bascom zwar, aber das mit der Taktfrequenz kann ich dir trotzdem verraten.

Mit "$crystal = 1000000" sagst du dem Compiler nur, dass er Code für einen Controller compiliert der mit 1Mhz getaktet ist.
Den Controller auch wirklich auf einen Mhz zu konfigurieren ist nicht die Aufgabe des Compilers.
Du musst dich selber darum kümmern, dass der Controller mit dem im Programm angegebenen Takt betrieben wird.
Also entweder durch einen externen Oszillator oder die durch den Programmer einstellbaren Control-Bits.

Pfui Teufel Bascom.
 
Willkommen im Forum Heinz,

wie Nomis schon erwähnt hat, mußt du den tatsächlichen Systemtakt über die Fusebits des AVR einstellen und Bascom dann über die Anweisung $crystal beibringen, welchen Systemtakt der AVR hat.

Wenn du ein Thema veröffentlichen möchtest, welches sich mit Software für AVR befaßt und sich nicht richtig in ein Unterforum einordnen läßt, dann erstelle das Thema einfach im Forum AVR-Mikrocontrollerfamilie/Software.

@Nomis:
Auch wenn dir Bascom nicht gefällt, der Basic-Compiler hat neben C, Assembler oder Pascal seine Daseinsberechtigung. Ich selber programmiere nicht in Bascom, möchte den Compiler aber trotzdem verteidigen. Gerade für Anfänger ist Bascom sehr interessant, da man hiermit sehr schnell Erfolge erziehlt und größere Projekte sind auch möglich, dieses sieht man an einigen Beispielen hier im Forum. Für AVR32-Projekte ist Bascom natürlich nicht geeignet, noch nicht. Ich akzeptiere zwar deine Meinung, allerdings wünschte ich, du würdest diese ein bisschen fundierter und mit einer anderen Ausdrucksweise rüberbringen.

Grüße,
Dirk
 
Du hast natürlich Recht, die Anschuldigungen gegen Bascom sind natürlich nicht fundiert. Im Grunde spricht ja nur der Neid aus mir, so ein Bascom-Programmierer hat es in manchen Dingen eben leichter.
In der Schule habe ich mich auch geweigert die IEC 61131 zu lernen bis ich zumindest AS und AWL anerkannt habe. Der Grund war das die anderen vier Sprachen aus dem zusammenklicken von Kästchen bestanden haben, was ich aber auf den Tod nicht ertragen konnte. Also einfach nicht hinhören wenn ich mal wieder was gegen eine Sprache habe.


Sobald ich aber durch irgendwelche selbstfinanzierten Studien nachweisen kann das Bascom Krebserregend(oder ähnliches) ist lasse ich es euch wissen.

<nachdenk>Ob die PETA etwas dagegen hat wenn ich Laborratten Basic beibringe?</nachdenk>
Zum Schluss: Real Ninjas only use Assembler
 
Hallo Nomis3000,

zunächst möchte ich mich Dirk anschließen!!! Nicht weil ich hier im Forum als BASCOM-Experte agiere und in dieser Rolle BASCOM verteigigen muss. Deine Argumentation zeigt mir, dass Du von BASCOM keine Ahnung hast und dann würde ich Dich auch bitte, unqualifizierte Bemerkungen zu vermeiden!

Ich habe in meinem Leben schon sehr viel programmiert. Assembler (auf Z80, 80386 und Motorola DSP 56303), Basic, C, C++, Pascal, Prolog, Lisp um nur einige zu erwähnen. Ich behaupt von mir die Sprachen zu kennen.
Und Du wirst lachen, seit zwei Jahren verwende ich wieder BASCOM für die Umsetzung meiner Projekte und ich bin sehr sehr zufrieden!

Es muss und darf jeder selbst entscheiden welche Programmiersprache er wählt und was im besser liegt. Jeder darf das tun ohne sich rechtfertigen zu müssen warum er das tut. OK? Du tust mr ja auch nicht leid nur weil Du bei Assembler stehen geblieben bist denn ich bin der Meinung dass sich verschiedene Programmiersprachen gegenseitig ergänzen. BASCOM hat nicht umsonst eine INLINE Assembler-Funktion genauso wie C da manche Dinge eben direkt auf der Maschine leichter zu machen sind!

So aber ich glaube das reicht! Dann zu Heinz.....


Hallo Heinz,

der wesentliche Teil wurde ja bzgl. der Drequenzangabe schon geschrieben. Unabhängig von der tatsächlichen HW muss der Compiler wissen, mit welcher Taktfrequenz Deine reale HW arbeitet da die Programmiersprache sowie der Code der dann auf dem Mega läuft nicht wissen können wie schnell der Mega rennt. Das ist aber z.B. für die Konfguration von Timern usw. besonders wichtig. Wichtig ist hier, dass Deine HW und die "SW Beschreibung zusammenpassen.
BASCOM leitet aus dem $crystal Statement interne Abläufe zum Handling von z.B. wait, waitms, waitus aber auch Entprellzeiten z.B. für debounce, Konfigurationen für Softclock, Timing für SW-TWI-Interface und SW-RS232-Interface ab. Deswegen ist es wichtig.

Wenn die $chrystal-Angabe zu Deiner tatsächlichen HW passt dann ist alles OK! Wenn Du "mehr chrystal" angibst als die HW hergibt dann ist der Programmablauf zu langsam. wait's dauern länger, timer können nicht richtig konfiguriert werden und auch bei SW-Interfaces wird nichts funktionieren.
Hast Du "weniger chrystal" als die HW dann bist Du schneller. Auch hier werden die Ergebnisse nicht zufriedenstellen sein, bis hin das nichts funktioniert!

Ich hoffe es ist Dir nun klarer geworden!

Grüße,
Markus
 
Vielen Dank...

Erstmal VIELEN DANK für Eure schnellen Antworten.
Klar jetzt ist der Groschen gefallen!!!!:banghead:

Ich hab immer gedacht mit der "$crystal" Anweisung teile ich dem µC mit mit welchem Takt er laufen soll....
da der Atmega8 standardmässig mit 1MHz taktet hat es so immer gepasst:)
von den Fusebits hab ich bisher immer die Finger gelassen...werd ich morgen mal testen.
Also vielen Dank nochmals für die Hilfe!!!!

Betreff Bascom Abneigung von Nomis3000, ich denke jeder nach seinem Gusto...

Also bis dann
Heinz
 
Takt - Definition und Fuses

Hallo @Stein...,
erst einmal herzlich willkommen im Forum.
Nun, Deine Bemerkung über BASCOM war vielleicht nicht ganz so despektierlich gemeint,
wie es wohl rübergekommen ist. (Auch von @N...) Kraftausdrücke sind aber bislang in diesem Forum noch nie gefallen, wenn auch einige User manchmal kurz vor der "grünen Minna" waren.
Dirk mußte da wohl auch noch etwas zu bemerken. Insofern nicht gleich übel nehmen.
Da ich von BASCOM null Ahnung habe, kann ich nichts dazu sagen.
Hab natürlich auch mit GWBASIC und QBASIC noch ein paar Experimente gemacht, dieser "Spaghetti-Code" ist aber keineswegs vergleichbar mit BASCOM.
Fest steht, das steht sogar im "Schmitt", dem schlauen Buch, daß einige Anwendungen auch in C sich von den ASM-Anweisungen nicht unterscheiden. Wie @Markus schon bemerkte, ist es ein unschlagbarer Vorteil, daß man also in BASCOM auch in ASM werkeln kann, ohne, daß es einem Fehlermeldungen bringt. (Unknown statement, unknown code, code mismatch oder dergleichen.)



Nun zu Deiner Frage:

Die Bedeutung einer Direktive mit Crystal sagt nur aus, wie die hernach im Programm folgenden Baudratenteiler und die Timer, vielleicht Zeitschleifen arbeiten sollen.
Dafür habe ich ein Uhren-ASM-Proggi schnipselweise hier parat.
Prinzipiell gilt das wohl auch für BASCOM:

PHP:
;
.nolist
.include "2313def.inc"
.list
;
.equ	daten = portb
.equ	mctakt = 4000000 ;Quarzfrequenz 
.equ	baud = 9600 	;Baudrate
.equ	bdteiler = 25	;(mctakt/(16*baud))-1 ;Baudratenteiler
;....
ldi	temp,	bdteiler 	; Baudratengenerator
out	UBRR,	temp 		; Teiler setzen
ldi	temp,	0x18 		; enablen TX und RX
out	UCR,	temp 		; an UART Control-Register
ldi	temp,	high(39998)	; Timer 1 einrichten
out	OCR1AH,	temp	; Output Compare Register
ldi	temp,	low(39998)	; in CTC-Modus, Vorteiler 1:1
out	OCR1AL,	temp
ldi	temp,	0x09	; TCCR1B in CTC-Modus
out	TCCR1B,	temp	; WGM12 und CS10 setzen
ldi	temp,	0x40	; Timerinterruptmaskierungsregister
out	TIMSK,	temp	; auf OCIE1A einrichten
;......


Wie ich im Experiment feststellte - das ist genau Deine Frage wohl - kann man die Toleranz des Quarzes nun per "Software" finetunen, ohne das Quarz nachzupolieren (kleiner Scherz).
Da die Uhr nachgeht, habe ich mal am Timer Comparewert herumgespielt.
Die Uhr geht dann vor, wenn der Wert verkleinert wird, mehr nach, wenn er vergrößert wird.
Normalerweise müßte der Comparewert auf 40000 stehen, damit ich hinterher den Hundertstelsekunden-Takt rausbekomme, - ist hier nicht zu sehen - da folgt nämlich noch eine Teilerschleife durch hundert, um auf die Sekunden zu kommen.

Bei BASCOM mußt Du nun nicht extra noch in bestimmte zeitabhängige Terme manuell reingehen, das macht dann das Crystal-Statement ein für allemal.

Im ASM-Prog hab ich's schon rausgeremt, weil im vorausgegangenen Versuch der Assembler mir das Ergebnis schon lieferte. Die Denkweise ist ja folgendermaßen:
Beim Compilieren bzw. Assemblieren können auch beim AVR-ASM Anweisungen erfolgen, die nicht im Befehlssatz der Mnemonik enthalten sind. Auch IF und dergleichen, sowie besondere Statements zur Erzeugung von MAKROS. Es werden auch Fehlermeldungen dann unter Umständen ausgegeben.
Das hat aber mit dem Programm hinterher nichts zu tun. Die MCU "rechnet" diese Dinge nicht aus, die arbeitet dann mit dem "Ergebnis", deswegen oben schon direkt die 25 als Baudratenteilerwert konkret reingesetzt.

.equ bdteiler = 25 ;(mctakt/(16*baud))-1 ;Baudratenteiler

Man könnte auch anders vorgehen, nämlich die folgende Definition

.equ mctakt = 4000000 ;Quarzfrequenz

abändern, also auf beispielsweise 3999800.

Dann würden sich alle "Rechenvorgänge", die sich auf diese Konstante beziehen, beim Assemblieren/Compilieren dementsprechend ändern. (Und natürlich bleibt der Timer-Comparewert dann bei 40000 !)


Die Einstellung der tatsächlichen Taktgenerierung erfolgt beim ATMEL-Studio4 über die Fuses-Maske. (Obiges Programm läuft mit einem fabrikneuen ATTiny2313 nicht. Wieso? Ich muß erst den standardmäßig gesetzten Prescaler durch 8 rausnehmen in den Fuses. Bingo!)
(Hier im Offline-Modus, da ich die serielle Schnittstelle ja für das Modem brauche..)
Siehe angehängtes Bildchen

Gruß von Oskar01
 

Anhänge

  • fuses_takt.png
    fuses_takt.png
    6,5 KB · Aufrufe: 5

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)