Ich möchte beim starten eines Atmega1284P auswählen, welcher UART (der
hat zwei) benutzt wird.
Es soll z.B. ein Pin abgefragt werden und danach entschieden werden: Pin
= 0, UART0 wird genutzt, Pin = 1, UART1 wird genutzt.
Nun habe ich aber das Problem, dass einerseits für #Channel anscheinend
keine Variablen erlaubt sind, der Compiler andererseits meckert, wenn
ich die UARTS Situationsabhängig initialisiere: "Error 66, device
already OPENED".
Kennt hier vielleicht jemand einen Weg, dieses Ziel zu erreichen?
Vielleicht könnte man im Quelltext erkennen, woran es liegt....
Gleich "oben" im Programm abfragen, ob Einer den Jumper gesteckt hat:
If Pinb.0 = 0 dann
initialisiere den Uart 1
mache den Channel auf
sonst
den anderen Uart
und den anderen Channel
end if
MfG Paul
Bascomicer schrieb:> Kennt hier vielleicht jemand einen Weg, dieses Ziel zu erreichen?
Benutze eine Sprache, der die Limitierungen der Abstraktion nicht gleich
ganz so deutlich anzumerken sind wie diesem (ziemlich räudigen)
Basic-Dialekt. So einfach ist das.
Wenn du aber unbedingt mit diesem Bullshit weiter arbeiten willst, ist
die einzige Möglichkeit, daß du selber eine weitere Abstraktionsschicht
darüber legst.
Für alle relevanten Operationen (Öffnen, Schließen, Schreiben und Lesen)
mußt du also jeweils ein Paar von Unterprogrammen schreiben, die
entsprechend des übergebenen Parameters für den Kanal verzweigen.
Kinderkram für richtige Programmierer. Die können auch um die Schwächen
der aus irgendeinem (meist sinnlosen) Grund "vorgegeben" Sprache
herumprogrammieren.
Bascomicer schrieb:> Kennt hier vielleicht jemand einen Weg, dieses Ziel zu erreichen?
select case pin
case 0: print #1
case 1: print #2
end select
oder eine if Schleife (kicher)
Wok schrieb:> select case pin> case 0: print #1> case 1: print #2> end select
Ja, das ist sicher eine Lösung, allerdings hatte ich gehofft, dass es
einen Weg gibt, das etwas eleganter zu lösen.
Rein technisch sehe ich zumindest keinen Grund, warum BASCOM sich hier
so verhält. Gerade bei dem Ansatz über die Initialisierung, ist das
einfach nur "doof".
Werde mal in DB schauen, ob sich da nicht was über die Register machen
lässt.
Bascomicer schrieb:> Da gibt es dieses Problem nicht?
Zumindest haben die Macher von Luna-AVR ihrem Compiler eine ordentliche
Expression-Auswertung verpasst und nicht dieses Simple-Gedöns wie bei
BASCOM. Ich hab durchaus auch gewisse Sympathien für BASCOM, aber das
was an dieser Stelle gemacht wurde, ist einfach nur lächerlich.
Expression-Parsing ist eine der ersten Übungen im Compilerbau. Und dann
kann man überall, wo man eine konstante Zahl angeben kann, dann auch den
Wert zur Laufzeit berechnen lassen. Und das durchaus mit Ausdrücken, die
auch mehr als nur einen Operator enthalten. Das kann eigentlich so
ziemlich jede höhere Programmiersprache problemlos. Nur halt leider
BASCOM nicht.
Wo bitte ist in BASCOM die Abstraktion. Beim Rechnen kann man da gleich
Assembler verwenden, das ist auch nicht komplizierter.
BASCOM fand ich mal nett, als es vor gefühlten Jahrzenten ein
preisgünstiger intel51 Compiler war. Gekauft hab ich ihn dann aber doch
nie und so hatte ich die großen "Vorzüge" des Produkt nie erfahren.
Und wer C++ KANN, der kann abstrahieren.
Wer chinesisch kann, der ist klar im Vorteil.
Unbestritten!
Aber deswegen sind meine Deutsch- Englisch- und Spanischkenntnisse nicht
weniger brauchbar.
Karli schrieb:> Wer chinesisch kann, der ist klar im Vorteil.>> Unbestritten!>> Aber deswegen sind meine Deutsch- Englisch- und Spanischkenntnisse nicht> weniger brauchbar.
Alex W. (a20q90) gefällt das.
Karl Heinz schrieb:> Das kann eigentlich so> ziemlich jede höhere Programmiersprache problemlos. Nur halt leider> BASCOM nicht.
ist das eventuell nur speziell bei diesem Befehl oder generell?
Wenn generell ist es dann vielleicht vielmehr ein Makro-Assembler? Weil
diese Art Verarbeitung sieht mir eher danach aus, was auch der erzeugte
Maschinencode vermuten ließe ala aneinandergefügte Bausteine?
und was ist jetzt außer den "echten" Ausdrücken der Unterschied zu dem
Luna? Macht der Compiler überhaupt eine Flussanalyse mit Optimierungen
wie z.B. der GCC oder ist das auch nur ein aneinander kopiertes Zeugs?
@ Die Welt geht vor die Hunde
Was hindert Dich eigentlich daran es mal bei der Luna Webseite selber zu
lesen?
Hier mal der Link für Faule:
http://avr.myluna.de/doku.php?id=de:optimierer
> Macht der Compiler überhaupt eine Flussanalyse mit Optimierungen> wie z.B. der GCC oder ist das auch nur ein aneinander kopiertes Zeugs?
Der kann noch nicht mal Ausdrücke mit mehr als 2 Operanden. Wo
bitteschön sollen der/die Entwickler je die Begriffe Datenflußanalyse
oder Optimierung gehört haben?
Immerhin macht das Ding aus einer 2-Operanden-Maschine eine
3-Operanden-Maschine. Statt "ADD R16,R17" hat man dann "ADD R16,R17 TO
R18", das ist schon viel komfortabler. (bruuusstt)
OK, es ist aber mehr wert als ein GCC, denn der kostet ja gar nichts.
