mega128-Fragen

[Apollo]

Beim Umstieg von der C-Control auf den Atmega stoße ich nun auf ein par problemchen. Hab schon einiges rumgegoogelt, aber konnte keine Erklärungen bekommen.
1. Beim C-Control-Basic konnte ich mehrere rechenoperationen zusammenfassen. (z.B. var=var1-(var2/10) ) Das scheint beim AVR nicht zu gehen, oder?
2. Beim C-Control-Basic gibts den Befehl "pulse". Bei Bascom habe ich noch keinen vergleichbaren Befehl gefunden. 2 mal "toggle" hintereinander sieht nicht so elegant aus. Gibts da ne andere Möglichkeit?
3. Warum geht der "Sound"-Befehl nicht auf den PG-Ports?

Ich hoffe das mir da jemand weiter helfen kann.

[uwegw]

1. der avr selbst kann natürlich nur einen befehl nach dem anderen ausführen. die von dir angegebene konstruktion wird daher vom complier in mehrere einzelbefehle zerlegt. bascom sollte sowas eigentlich können, aber ich bin mir nicht sicher
2. in bascom heißt das "pulseout"
3. was ein "sound" befehl ist kann ich ja noch raten aber was ist im zusammenhang mit dem m128 ein "PG-port"?
edit: stimmt der m128 hat ja auch nen port g! was hast du vor damit, und welchen anschluss benutzt du genau? denn einige pins sind auch mit anderen funktionen doppelt belegt und müssen erst auf normale io- funktion umgeschaltet werden...

[Apollo]

1. ok. war von mir falsch ausgedrückt. Der AVR kann das natürlich auch nicht, genau so wenig wie der Motorola auf der C-Control. Aber Bascom kann das scheinbar nicht zerlegen. bei einer simplen Addition von 3 variablen gibt er schon folgende Fehlermeldung aus.
Error: 35 Line: xx 3parameters expected
Dann werd ich das wohl selber zerlegen müssen.
2. pulseout, ja klar. den hatte ich zwar gesehen, aber für unbrauchbar gefunden. warum kann ich mit jetzt aber auch nicht erklären.
danke für den Tipp.
3. In meinem Fall wollte ich Portg.2 verwenden. An g3 und g4 hab ich den Quarz für den RTC. Portf kann ich aber auch nicht mit dem "sound"-Befehl benutzen. Als normale Ausgabeports kann ich beides verwenden.

[uwegw]

so erstmal bascom installiert...

also
SOUND PORTG.2 , 10000, 10 'BEEP
aus der hilfe kopiert und nur G.2 eingesetzt wird ohne probleme kompiliert. gibt es bei dir da ne fehlermeldung, oder taucht dein problem erst bei der realen ausführung im m128 auf?



edit: so jetzt glaube ich zu wissen wo der hase im pfeffer liegt!
ich habe einfach mal den avr-typ in den optionen auf "m128 in 103 mode" umgestellt. denn irgendwann hab ich mal gelesen dass der m128 im auslieferungszustand in einem modus geschaltet sit, wo er kompaktible zu seinem vorgänger(?), dem mega103, ist, und daher nicht alle funktionen nutzbar sind. und da gabs sofort ne fehlermeldung weil es beim m103 weder portF noch portG gibt...

lösen kannst du dein problem demnach mit den fusebits. da kann man diesen kompaktibilitätsmodus ausschalten, um den m128 voll nutzbar zu machen. dazu klickst du in bascom auf manuell programmieren, dann auf "lock and fuse bits". dann weiß ich nicht mehr weiter weil die einzelnen fusebits nur angezeigt werden wenn wirklich ein m128 an der leitung hängt, aber die sollten beschriftet sein. aber meld dich am besten nochmal bwevor du irgendwas verstellst wo du dir nicht 100% sicher bist...

[Apollo]

die fuse stehen schon auf 128.
aber ich kann machen was ich will.

$regfile = "M128def.dat"
$crystal = 16000000
Ddrg.2 = 1
Do
Sound Portg.2 , 10000 , 10
Wait 1
Loop

da kann ja nicht so viel falsch sein.
aber trotzdem
Error: 222 Line: 5 Illegal character [expected(,got"]

[Apollo]

Eventuell liegt es an der Bascom Version?
Habe die 1.11.7.4

[uwegw]

BASCOM-AVR IDE Version : 1.11.7.3
Compiler: Version 1.11.7.3

kompilert deinen text fehlerfrei... merkwürdig...

[Apollo]

habs gerade mit der neuen demo versucht, da gehts auch.
sehr merkwürdig

[Apollo]

tatsächlich, in der ...7.3 gehts auch. und warum dann nicht in der ...7.4
dann werd ich meine ...7.4 wohl updaten müssen.

[Apollo]

ok, da in Bezug auf die ..7.4 keiner mehr eine Idee hat, komm ich zur nächsten Frage.
Es geht die Timer an. Ich konnte noch nicht so recht herausfinden, was passiert, wenn mehrere Timer Interrupts gleichzeitig anstehen.

Also mal angenommen, Timer1 ist gerade in der Interruptroutine um z.B. die Zeit eines DCF Impulses zu messen, und während dessen läuft Timer2 über und löst dadurch ebenfalls einen Interrupt aus.
Wird der dann ignoriert, oder wird die entsprechende Routine anschließend ausgeführt?
Wenn letzteres der Fall ist, könnte es ja bei zeitkritischen Anwendungen Probleme geben.

[oe9vfj]

Zu Deinen Fragen mit den Timer-Interrupts:

Falls während eines Interrupts ein weiterer auftritt, wird dieser nach Beendigung des gerade laufenden ausgeführt. Daher sollten die Interrupt-Routinen auch so kurz wie möglich gehalten werden. Mit dem Aufruf einer Interrupt-Routine werden die Interrupt-Aufrufe gesperrt und mit Beendigung (ASM-Befehl RETI) wieder freigegeben. Dann kann ein anstehender weiterer Interrupt ausgeführt werden.
Es wäre zwar möglich, in einer Interrupt-Routine die Interrupts explicit wieder freizugeben, diese würde aber zu verschachtelten Interrupt-Aufrufen führen mit einem entsprechenden (nicht) abschätzbaren Stack-Bedarf und ist daher nicht ratsam.

[Apollo]

so hab ich mir das schon gedacht.
Aber der RTC läuft doch auch über Interrupts (timer0), wenn ich mich nicht irre.
Wenn da noch andere Interrupts im Spiel sind, kann es doch schnell mal zu Ungenauigkeiten der Uhr kommen.
Auch wenn das ja nur minimale Verzögerungen sind, die addieren sich doch irgendwann.

[oe9vfj]

Es gibt dann eine Ungenauigkeit, wenn ein weiterer Interrupt von der gleichen Quelle auftritt, bevor ein vorhergehender in der Interrupt-Routine abgearbeitet wurde.
Die Auslösung des Interrupts und die Abarbeitung können in dem Fall der RTC getrennt betrachtet werden. Der Timer löst zum Beispiel jede Sekunde einen Interrupt aus und ist nur von der Quarzgenauigkeit abhängig. Die Auslösung des nächsten Interrupts ist von einer allfällig durchgeführten Interrupt-Routine unabhängig. Die Ungenauigkeit ist nur von der Zeit abhängig, welche vergeht, bis die Interrupt-Routine durchgeführt wird und die entsprechenden Zeit-Variablen berichtigt werden. Also bei einem gut programmierten System von einigen µSec bis mSec. In jedem Fall muss natürlich die Interrupt-Routine innerhalb einer Sekunde zur Ausführung kommen, sonst verfälscht sich die RTC-Zeit.

[Apollo]

ah, ich glaub ich verstehe.
Wenn der Überlauf des RTC-Timers stattfindet wird das Interruptregister gesetzt, und der läuft ja dann weiter weiter. Un dann hat der Prozessor ja knapp ne Sekunde zeit, um die entsprechende Routine auszuführen.
Das sieht dann aber anders aus, wenn man den Timer in der Interruptroutine auf einen bestimmten Wert setzten will. Da wirds dann schon Zeitkritischer.
Hab ich das so richtig verstanden?