Druckbare Version
Ich habe bisher prinzipiell zwei Ansätze entdeckt, wie beim AVR ein Software UART implementiert werden kann:
- Verwendung eines Interrupteingangs für RX
- Verwendung eines beliebigen Input-Pins mit Überabtastung, d.h. es wird der RX-Pin mit einem Vielfachen der Baudrate abgefragt
Welches Prinzip liegt denn dem BASCOM SW UART zugrunde?
Ich hab da irgendwie noch keine rechte Information gefunden....
Da hier so gar keine Antwort kommt, sollte ich meine Frage vielleicht noch einmal anders formulieren:
Kann ich für den Software UART des BASCOM AVR jeden belieibigen GPIO Pin eines AVR (genauer ATMEGA128) nutzen oder muss der RX-Pin einen Interrupt auslösen?
Hat sich wirklich noch niemand damit beschäftigt?
Um übrigens Anmerkungen zu den 2 HW USARTS des ATMEGA128 vorzugreifen: Diese werden ebenfalls benötigt und stehen nicht zur Verfügung, da ich insgesamt 3 serielle Schnittstellen (2x RS485 + 1 xRS232) benötige.
Nach meinen Erfahrungen sind die SW-UARTs nicht interrupt-basierend. Das heißt einerseits dass jeder I/O Pin verwendet werden kann, andererseits muss die SW-UART Empfangsroutine aufgerufen werden, bevor die Zeichen eintreffen.
das ist das geheimnis von bascom. die interrups von bascom machen was sie wollen. es ist nicht nachvollziehbar für einen mittelschlauen progger. erst wenn man mit viel mühe versucht den cof-code im avrstudio zum laufen bringt kann man einige sachen sehen, was bascom da vollbringt, ich sage immer , bascom büffelt (nach dem motto dran,drüber drauf).
ich habe mich vorher, bevor ich auf winavr-c und fastavr-basic umgestiegen bin immer geärgert, das plötztlich ein timer benutzt worden war und ich nicht mit meiner routine drauf zugreifen konnte. ist sehr ärgerlich. aber was solls. ich kann nur raten, wer mehr wert auf eine saubere progausgabe legt , umsteigen.
mfg pebisoft
Das Geheimnis lüftet sich, wenn man den Hilfe-Text zum jeweiligen Befehl liest. Ein beim Programmieren nicht unüblicher Vorgang, wenn es um Inplementierungdetails von Befehlen geht. Beim entsprechenden Befehl OPEN steht nichts von einem Interrupt, also wird auch keiner verwendet.
Pauschale Abwertungen eines Produktes sind unglaubwürdig, solange man nicht ein konkretes Beispiel für Behauptungen geben kann.
Es gehört sich wirklich nicht solch pauschalen unbegründeten Gerüchte zu streuen.
Das es einige Bibliotheksfunktionen gibt die Interrupt oder Timer nutzen mag ja sein, sowas ist bei allen Compilern der Fall, aber wenn das so ist stehts auch in der Bascom Befehlsbeschreibung die wirklich Vorbildlich ist.
Aber ich will die nevige Compilerdiskussion nicht noch ausdehnen und bitte nur bei Kritik an Dingen diese konkret zu belegen!
Ja, das hab' ich auch gelesen, dass das schon mal wer getan hat, wär sicher interessant, ihn persönlich kennenzulernen :mrgreen:Zitat:
Zitat von Anonymous
"Kann ich für den Software UART des BASCOM AVR jeden belieibigen GPIO Pin eines AVR (genauer ATMEGA128) nutzen oder muss der RX-Pin einen Interrupt auslösen?"
wäre interessant, wenn was in der hilferrouotine stehen würde.
ich finde nichts darüber welcher interrupt genutzt wird wenn ein softwaremässiger rx-pin genutzt wird. auch der waitbefehl macht mir schaffen mit dem interrupt. der "waitus 1" z.b dauert über 1,8 us in der realen welt beim ablauf, das darf nicht sein.
in der beschreibung steht nur allgemeines basicgeplänkel für den totalen anfänger, geht aber nicht auf besonderheiten der speziellen bascomroutinen ein, die ihren eigenen weg gehen und nicht den man vermutet.
mfg pebisoft
Also, das Du nichts findest ist nun wirklich Dein ganz persönliches Problem.Zitat:
Zitat von pebisoft
Was bitte ist unklar an:
No accurate timing is possible with this command.
In addition, the use of interrupts can slow this routine.
The minimum delay possible is determined by the used frequency.
The number of cycles that are needed to set and save registers is 17.
When the loop is set to 1, the minimum delay is 21 uS. In this case you can better use a NOP that generates 1 clock cycle delay.
At 4 MHz the minimum delay is 5 uS. So a waitus 3 will also generate 5 uS delay.
Above these values the delay will become accurate.
und:
ASM
WaitMS will call the routine _WAITMS. R24 and R25 are loaded with the number of milliseconds to wait.
Uses and saves R30 and R31.
Depending on the used XTAL the asm code can look like :
Gleiches gilt auch für die Comport Arie. Steht alles da, zugegeben, bisweilen muss man etwas suchen.Code:_WaitMS:
_WaitMS1F:
Push R30 ; save Z
Push R31
_WaitMS_1:
Ldi R30,$E8 ;delay for 1 mS
Ldi R31,$03
_WaitMS_2:
Sbiw R30,1 ; -1
Brne _WaitMS_2 ; until 1 mS is ticked away
Sbiw R24,1
Henrik
In der BASCOM-Hilfe steht nichts von einem Interrupt, daher wird auch keiner verwendet, damit is klar, dass die Variante
verwendet wird. Es kann doch nicht bei jedem Befehl dortstehen, was dieser Befehl nicht macht.Zitat:
- Verwendung eines beliebigen Input-Pins mit Überabtastung, d.h. es wird der RX-Pin mit einem Vielfachen der Baudrate abgefragt
Ein WaitUS 1 Befehl dauert in BASCOM bei einem 8MHz Quartz 1,125 µSec. Unter welchen Rahmenbedingungen diese 1,8 µSec (wenn überhaupt) zustandekommen sollen, kann ich nicht nachvollziehen. Bei dem von Pebisoft derzeit so stark propagierten Compiler FASTAVR ist das kleinste Wait überhaupt nur 10µSec und das sinnigerweise mit dem Befehl
WaitUS 1
Hier ist nämlich die Zeiteinheit bei WaitUS 10µSec und nicht 1µSec wie man annehmen könnte.
Prinzipiell gilt das wohl für alle derartigen Schleifen. Das einzige, was wenigstens so genau geht wie der Quartz, ist der Timer-Counter vom Start bis er den Interrupt setzt, nicht einen Zentimeter länger.Zitat:
Zitat von BasCom Help
Ist halt ein Glück, dass solche Fehler in % gemessen werden.