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.
Der gestandene Bascomer programiert heute vorsichtshalber gleich in LunaAVR. http://avr.myluna.de/doku.php?id=de:about
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.
Es gibt in diesem Forum C++ Programmierer, die BASCOM nicht verstehen. Das ist eine reine Abstraktionsschwäche.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.