Guten Tag,
bevor ich meine Tischplatte ganz durch beiße möchte ich mich an euch
wenden, denn im Moment drehe ich mich etwas im Kreis und die
Suchfunktion hat auch nicht so richtig die passenden Ergebnisse
gebracht.
Also ich will mittels eine Midi-Fußleiste (zum Beispiel
http://www.thomann.de/de/rocktron_midi_xchange.htm) per Mide-Befehle
über einen Atmega ein paar Relais schalten die dann Lampen ein und
ausschalten.
Die Fußleiste die ich habe sendet auf Kanal 1 und immer einen "Programm
Change" Befehl. Wenn ich das Midi-Protokoll richt verstanden habe, dann
wir im ersten Byte der Programm Change im oberen Nibbel und der Kanal im
unteren Nibbel übertragen und die Programmnummer folgt im zweiten Byte.
Zum Test wollt eich jetzt das zweite Byte auslesen und die Bits dann auf
ein paar LEDs "übertragen" was allerdings nicht so richtig funktioniert.
Daten werden zwar empfangen aber irgendwie passt die zu erwartende
Anzeige nicht zu der tatsächlichen Anzeige. Wenn ich z.B. Programm
Nummer 1 oder 2 schicke, dann müssten nur die ersten beiden LEDs an
gehen, es gehen aber viel mehr an und auch vergleiche der Art Byte = 1
oder Byte = 2 funktionieren irgendwie nicht.
Ich weiss nicht ob ich einen grundlegenden Denkfehler mache oder der
Ansatz falsch ist und von daher wäre ich für jede Tipps sehr dankbar.
Hier ist der Programmansatz:
1
$regfile "m168def.dat"
2
$crystal = 8000000
3
$baud = 31250
4
5
On Urxc Onrxd
6
Enable Urxc
7
Enable Interrupts
8
9
Dim Rxbyte As Byte
10
Dim I As Integer
11
I = 0
12
13
Led1 Alias Portc.5
14
Config Portc.5 = Output
15
Led2 Alias Portc.4
16
Config Portc.4 = Output
17
Led3 Alias Portc.3
18
Config Portc.3 = Output
19
Led4 Alias Portc.2
20
Config Portc.2 = Output
21
Led5 Alias Portc.1
22
Config Portc.1 = Output
23
Led6 Alias Portc.0
24
Config Portc.0 = Output
25
26
27
Cls
28
Do
29
Loop
30
31
32
Onrxd:
33
If I = 1 Then
34
Rxbyte = Udr
35
36
Led1 = Rxbyte.0
37
Led2 = Rxbyte.1
38
Led3 = Rxbyte.2
39
Led4 = Rxbyte.3
40
Led5 = Rxbyte.4
41
Led6 = Rxbyte.5
42
Waitms 500
43
Gosub Reset_leds
44
I = 0
45
46
Else
47
Incr I
48
End If
49
50
Return
51
52
Reset_leds:
53
Led1 = 0
54
Led2 = 0
55
Led3 = 0
56
Led4 = 0
57
Led5 = 0
58
Led6 = 0
59
Return
Ein Problem mit der Hardware selbst schließe ich aus. Diese ist getestet
und überprüft. Ich vermute eher, dass das Problem vor dem Bildschirm
sitzt ;-)
Vielen Dank.
Frank
Ich würde dir drigend empfehlen die empfangenen Daten in einer
Statemachine zu verarbeiten und nicht "blind" einfach jedes zweite Byte
"fressen".
Wenn die Fußtreter einen running-status sendet (oxfe glaub ich), oder
die Daten "komprimiert" sendet dann funktioniert deine Vorgehensweise
nicht.
Einfach eine Statemachine implementieren die im Startzustand auf ein
Program-Change Befehl "wartet", dann in einen anderen Zustand
weiterschaltet indem dein Datenbyte ausgewertet wird. Ist der befehl
komplett "durchgelaufen" wieder in den ersten Zustand auf ein erneutes
Program-Change warten.
Sich bei MIDI darauf zu verlassen das jedes zweite Byte dies und das ist
nur weil man nur diese Befehlstypen erwartet geht zu 120% in die Hose.
Hallo,
natürlich muss noch eine gewisse Sicherheit implementiert werden. Das
Programm ist auch nur als "Test" anzusehen um zu sehen was tatsächlich
ankommt und die grundsätzliche Frage ist, ob der Ansatz richtig ist oder
ob eine andere Art des Datenempfangs sinnvoller bzw. besser geeignet
ist.
Die Daten die der vorhandene Fußschalter liefert habe ich mir mit einem
Midi-Monitor am PC angeschaut und dort zeigt Byte 1 und Byte 2 genau
das, was ich auch erwartet würde (laut Midi-Protokoll) aber wenn ich wie
oben gezeigt das zweite Byte direkt ausgeben will, dann bekommen ich
eine andere Anzeige bzw. es sind Bits gesetzt, die eigentlich nicht
gesetzt sein sollten.
Viele Grüße, Frank
>ob der Ansatz richtig ist oder ob eine andere Art des Datenempfangs>sinnvoller bzw. besser geeignet ist.
Wie gesagt : Statemachine. Ist das einzig sinnvolle bei MIDI-Empfang.
Und die "Sicherheit" bekommst du damit automatisch. Einfach Bytes zählen
wäre mir zu riskant, zumal eben der Fußtreter evtl noch 0xfe schickt
oder die Daten "komprimiert" (Folgedaten werden dann ohne gesetztem 7.
Bit übertragen und beziehen sich dann auf das zuletzt versendete
Kommando)
>Midi-Monitor am PC angeschaut und dort zeigt Byte 1 und Byte 2 genau>das, was ich auch erwartet würde
Edit :
Und sicher das der die 0xFE (sofern deine Fußtretminen den senden) nicht
vllt einfach nur nicht anzeigt bzw ggf "komprimierte" Daten nicht
automatisch dekomprimiert ?
entschuldige bitte die späte Antwort...
Ich bin mir sehr sicher, daß der Bodenschalter nur zwei Byts sendet denn
ich habe bereits ein C-Programm für das Board, welches nur das zweite
Byte auswertet und auch richtig anzeigt. Allerdings würde ich gerne aus
verschiedenen Gründen nicht auch noch mit C anfangen wollen - nur wenn
es überhaupt nicht anders geht.
Von daher bin ich mir also sehr sicher, daß der eigentliche "Denkfehler"
im BASCOM Programm liegt und nicht an der Hardware, dem Board oder dem
Sender.
Was mir derzeit noch nicht ganz klar ist: werden Daten die über UART
gesendet werden irgendwo zwischengespeichert bis diese abgeholt werden
oder überschreiben sich die Daten gegenseitig ?
Viele Grüße, Frank
Hallo,
so, ich bin einen großen Schritt weiter. Ursache für die ganze
Verwirrung scheint $crystal = 8000000 zu sein. Wird der Wert auf 1000000
geändert dann werden Daten empfangen, welche logischer zu sein scheinen.
Ich muss diese jetzt noch im Detail auswerten.
Das ist auf der einen Seite jetzt schön aber auf der anderen Seite
verwirrt es mich jetzt doch noch mehr.
Der Atmega16 wird mit einem externe Quarz betrieben welches mit 7,3728
angegeben ist. Die Baud-Rate bei MIDI ist 31,25 kBit. Wie errechnet man
nun die Optimale Einstellung für den Parameter $cyrstal ? In der
Bascom-Hilfe bin ich leider nicht fündig geworden.
Viele Grüße, Frank
Frank Broma schrieb:> Der Atmega16 wird mit einem externe Quarz betrieben welches mit 7,3728> angegeben ist. Die Baud-Rate bei MIDI ist 31,25 kBit. Wie errechnet man> nun die Optimale Einstellung für den Parameter $cyrstal ?
Gar nicht!
Du gibst das an, was du hast.
WEnn du einen Quarz mit 7.3728 Mhz am M16 hast und der auch aktiviert
ist, dann schreibst du da auch 7327280 rein.
Lüg niemals deinen Compiler an!
> Wird der Wert auf 1000000
Also 1Mhz
Das heißt, dein Quarz ist noch gar nicht aktiv.
Der M16 läuft immer noch auf Auslieferungszustand mit dem eingebauten
RC-Schwingkreis auf ungefähr 1Mhz.
> so, ich bin einen großen Schritt weiter.
Hättest du dir alles sparen können, wenn du erst mal den Banaltest
gemacht hättest und eine LED mittels Wait(1) im Sekundentakt hättest
blinken lassen. Deine Sekunde wäre nicht 1 Sekunde gewesen und du
hättest gewusst, dass mit der Takversorung was nicht stimmt.
Du gehst mir ein wenig zu sorglos an die Dinge ran (siehe zb das partout
darauf bestehen, dass man keine Fehlercheck braucht um das Datenbyte zu
isolieren. Und nein, das ein C-Programm das kann, ist kein Argument. Das
ist genauso schlecht gemacht. Wenn dir auf der Bühne dann das erste mal
das Kabel abgeht, du es in der Hektik schnell wieder einsteckst und dann
drauf kommst, dass nichts mehr stimmt, weil deine banale 1-2-1-2 Zählung
sich nicht mehr richtig einklinkt, dann wirst du dich dafür verfluchen,
dass du das bischen Aufwand nicht getrieben hast, dass COmmandobyte zu
identifizieren)
Man rechnet gar nicht. man stellt crystal auf den Wert, mit dem der Chip
läuft. Wenn das Timing kritisch ist, musst Du einen Quarz anschließen.
Bascom "rechnet" selbst aus, wie viele Wartetakte er bei 31,5kBit und
z.B. 8MHz Takt einlegen muss.
Karl Heinz Buchegger schrieb:> Du gehst mir ein wenig zu sorglos an die Dinge ran (siehe zb das partout> darauf bestehen, dass man keine Fehlercheck braucht um das Datenbyte zu> isolieren.
Das ist nicht richtig wiedergegeben. Ich habe nicht behaupte, daß ich
keinen Fehlercheck oder ähnliches machen will. Im ersten Ansatz ging es
nur darum die reinen Daten die übermittelt werden irgendwie anzuzeigen.
Das kann man auch in dem Programm erkennen welches oben steht. Nicht
mehr und nicht weniger. Aber nachher kam man sich natürlich weit aus dem
Fenster lehnen. Nicht sehr hilfreich.
Da aber noch kein Meister vom Himmel gefallen ist stehe ich der Sache
weiterhin positiv gegenüber zumal dies der Erste Ansatz mit einem Atmel
ist.
Viele Grüße, Frank
Thread beobachten
Seitenaufteilung abschalten