Kannst Du momentan testen oder erst spät am Abend?
Ganz spät.
Ich fahr direkt nach der Arbeit zur Bandprobe
Also LED dazu nehmen...
Ihr verbessert mich bitte wieder
Also die 3 Masterregler sollen eine LED bekommen die jeweils
Bei VOLL dauerleuchtet
Bei nicht VOLL blinkt oder Pulsiert
Hier ein Versuch mit Blink
Im Setup
pinMode(13, OUTPUT)
Das gleiche für 14,15
Und im Loop
if controllerWert[20] = 127{
digitalWrite (13, HIGH);
}
if ControllerWert[20] < 127{
digitalWrite (13, LOW);
delay(1000);
digitalWrite (13, HIGH);
delay(1000);
}
Das noch mit 21 und 22
Passt das ?
LG Rebecca
Nicht der Untergang des Abendlandes, aber für Dein Programm, denn 1 Sekunde passiert nichts!
1 Like
Ist dann nicht so hektisch 
Dann 500? Mal testen
Ansonsten stimmt es????
Schön langsam immer mehr durch zu blicken...
Bedenke: ich kann nicht bei dir auf den Tisch schaun.
Du musst schon sagen, was da nicht oder nicht richtig geht.
Du blockiert dir damit den kompletten restlichen code.
Das macht dann entweder blinken oder Taste.
Öh böh....
Oder doof
Also wenn im Loop irgendwo ein delay ist wird alles gestoppt?
Ok dann wäre mit meinem Wissen nur aus...
Da bin ich gespannt auf den besseren Weg
Falls noch nicht gemacht schau dir in der IDE den Sketch Blink Without Delay an. Bau ihn nach. Lerne ihn zu verstehen. Das Prinzip zeigt dir wie man mehrere Sachen "fast parallel" macht. Studiere den code bis du ihn auswenig hinschreiben kannst. Dieser Code ist deine wichtigste Programmierhife ( neben myxy und agmue).
1 Like
Da ließe sich ja etwas über Signal oder threema mit Handy machen.
@martin-lo hatte ja schon mehrfach vergeblich auf das Datenblatt verwiesen, ohne mich so richtig überzeugen zu können. Abseits dieses Themas haben wir uns dann ausgetauscht und beispielsweise festgestellt, daß ich in das von TI und er in das von Philips schaue. Ich beziehe mich jetzt ausdrücklich auf das Datenblatt von Philips, dort hauptsächlich auf "7.1 Quasi-bidirectional I/Os".
After power-on as all the I/Os are set HIGH all of them can be used as input.
Rot eingerahmt die Stromquelle, die den Eingang auf HIGH zieht. Du verwendest, wenn ich mich richtig erinnere, am Eingang einen PullDown-Widerstand von 10 kΩ, um den Eingang auf LOW zu ziehen, bis die gedrückte Taste den Eingang nach HIGH zieht.
Eine übliche Vorgehensweise, der ich daher leider auch nicht widersprochen habe. Ungewöhnlich ist die Stromquelle von ca. 100 µA, deren Strom durch den PullDown-Widerstand fließt und dort eine Spannung von 0,1 mA * 10 kΩ = 1 V abfallen läßt. Genauer mit den Daten aus dem Datenblatt "10 CHARACTERISTICS":
IOH = 30 bis 300 µA mit einem Spannungabfall an 10 kΩ von 0,3 bis 3 V.
LOW-level input voltage VIL2 = 0 bis 0,3 * VDD = 0 bis 1,5 V
Im schlechten Fall liegen die 3 V deutlich über den 1,5 V!
Soweit Theorie und Datenblatt, das wollte ich natürlich an meinen prinzipiell baugleichen PCF8574 nachmessen und erhalte 1,47 V Spannungsabfall an dem 10 kΩ PullDown-Widerstand. Die Theorie wird also bestätigt.
"Aber es funktioniert doch!" höre ich Dich sagen.
Ja, aber nur zufällig, weil beispielsweise die Lufttemperatur stimmt. Bei Deinen Einsätzen kan sich das ändern. Daher solltest Du nochmal genau prüfen, wie viel Aufwand ein Schwenk zu PullUps tatsächlich darstellt, denn aus meiner Sicht mußt Du das ändern.
Ich lese mir jetzt nicht alle Beiträge in diesem Thema nochmal durch, aber sollte ich Dich nicht rechtzeitig gewarnt haben, so bitte ich um Entschuldigung 
2 Likes
Mir würde schon reichen, wenn Du erklären könntest, was Du erwartest und was (oder nicht) passiert.
Ich hab jetz gut 2 Stunden Zugfahrt. Deine Chance
Dein blinken.
Blockadefrei und für alle(!!!) leds mit einer Funktion.
const byte ledPin = 13;
const uint32_t intervall = 500;
uint32_t lastmillisLed;
byte controllerWert[20] = {100};
void setup()
{
Serial.begin(115200);
Serial.println(F("\r\nStart...\r\n"));
pinMode(ledPin, OUTPUT);
digitalWrite(ledPin, LOW);
}
void loop()
{
checkFader();
}
void checkFader()
{
switch (controllerWert[20])
{
case 1 ... 126:
blinkLed(ledPin, lastmillisLed);
break;
case 127:
digitalWrite (ledPin, HIGH);
break;
case 0:
digitalWrite(ledPin, LOW);
break;
}
}
void blinkLed(const byte pin, uint32_t &lastblink)
{
if (millis() - lastblink > intervall)
{
digitalWrite(pin, !digitalRead(pin));
lastblink = millis();
}
}
1 Like
Wieder mit Tisch?
Mir würde "blockadearm" besser gefallen, weil ja jede Aktion andere ein wenig behindert.
Gute Fahrt!
Klappt heute nicht
Hab bandprobe
1 Like
@agmue
Vermutungen sind doof, also werde ich bei mir mal Messen.
Es umlöten wäre fast alles auseinander zu nehmen!!!
Die Leitungen sind so konzipiert, dass sie an Arduinos Funktionieren. Das heißt: Ein Teil so und ein anderer Teil muss völlig anders verdrahtet werden. Das heißt Taster nebeneinander.
Lieber nehme ich dann etwas anderes als den PCF...
Ich möchte einfach kein pfuschiges gefriggel bei dem Teil .
Mal sehen was das Multimeter sagt...
Zu Delay
Ich hab da viel probiert, auch zwischen den 0x20 etc.
Leider keine Veränderung.
Ist in Arbeit
Also ich benutze HairlessMIDI mit einer Bautrate von 38400 auf Serial 1
Diesen Wert verändere ich auf 31250 wenn ich über den DIN 5Pol gehe.
31250 geht in HairlessMIDI leider nicht ein zu stellen.
Das Programm ist for free
Hier ein link
https://projectgus.github.io/hairless-midiserial/
Wenn du das Tool installieren würdest, wirst du mich wahrscheinlich besser verstehen, denn es Checkt die Signale nach korrektem Format und zeigt alles was auf dem Bus ist an.
MIDI ist so ausgelegt, dass Ruhe herrscht, nur wenn etwas passiert soll gesendet werden, damit Zeit kritisches auf den Punkt kommt.
Darum ist Taste drücken ein Ereignis, dann Ruhe und Taste loslassen ein neues Ereignis.
Regler belasten den Ausgang ja mehr, durch die Änderung der Werte. 2, 3 ,4, 5 ,6 geht aber durchaus noch während man auf Tasten spielt. Keine Ahnung wo eine Grenze ist.
Wenn ich deinen Code aktiviere:
Die Anzeige rauscht nur so durch, weil die Potiwerte hin und her springen , die müssen unbedingt noch geglättet werden. Der traffik ist so stark, das ich kaum etwas erkennen kann. Wenn ich Taster drücke steht oft auch
"MIDI Nonsens", wahrscheinlich diese "unverändert" Meldung?
Im IDE Serial Monitor (HairlessMIDI muss deaktiviert sein) zeigt der Code bei den Tastern die 3 Meldungen, alle Taster arbeiten, bei den Reglern gibt es Kryptische Zeichen.
LG Rebecca
1 Like
das wäre eine klassische "State Change Detection"
https://docs.arduino.cc/built-in-examples/digital/StateChangeDetection
oder besser noch "Debounce" weil das ohne delay auskommt:
1 Like
Ist alles bereits drin.
Darum habe ich die serielle Ausgabe ja extra gefertigt.
Auf dem SerMon funktioniert das mit den Tasten schon.
Rest schreib ich da wo es hingehört 
1 Like
Wie Midi funktioniert ist bekannt. Ich hatte in frühen Zeiten schon damit zu tun. Als Z-Netz und Usenet Austauschplattformen waren... Mit Soundblaster Soundkarte auf dem 15poligen Anschluss die Adapter selbst gelötet... Hach...
Genug Vergangenheit.
Das was jetzt passiert ist, war nur Dein Code für die Fader einzuarbeiten. Da kann mir natürlich ein Fehler unterlaufen sein, aber das bekomme ich hin.
Die kryptischen Zeichen sind echt. das ist aber nicht so problematisch...
HairlessMIDI ist natürlich schick, aber ich habe keinerlei Hardware. Nix. Selbst wenn ich wollte, könnte ich also nix antackern.
Dein Problem ist die Doppelbelegung, sodas Du die DebugAusgaben nicht dem MIDI-Satz zuordnen kannst. Daher mal die Frage, ob Du Dir nicht ein zusätzlicher USB-Adapter gut tuen würde.
Artikelliste:
https://www.amazon.com/usb-serial-arduino/s?k=usb+to+serial+arduino
Der kommt dann an Serial1 und macht Dir einen neuen COM-Port am Rechner auf.
Alternativ könnte ich Dir anbieten einen zweiten Controller (UNO/NANO) einfach nur als MIDI-Empfänger zu bauen, der dann die Daten vom Serial1 des MEGA aufnimmt und 1:1 auf dem USB-Port zur Verfügung stellt.
Dann könntest damit hairlessMIDI an dem USB-Port anbinden und gleichzeitig auf dem MEGA-SerMon mitschauen, was passiert.
Ein paar zusätzliche debugausgaben rein und gut wäre es.
Ich werd mal für die fader die MIDI-Ausgabe überarbeiten und da genauso arbeiten wie mit dem was ich vorher gamcht habe. - Zustand merken, einmalig ausgeben und erst bei tatsächlicher Änderung das Spiel von vorn.
Alles andere ist bei den Tastern bereits drin, sowohl das debounce als auch das reagieren auf den Zustandswechsel.
Es wird
1 Like
Dieser Tage schwärmte mir jemand von seinem Testprogramm einschließlich PCB-Entwurf vor, was mich auf die Frage bringt, würde Dir ene Platine helfen?
Ich war wegen der 1,47 V auf meinem etwas erschrocken, auch wenn sich dadurch meine Theorie bestätigte.
@rebel_tilt: Ja bitte, so mache ich das:
- Serial für Upload und MIDI
- Serial3 für den seriellen Monitor
Ich öffne dann zwei IDEs, eins mit dem Programm und dem COM-Port für den Upload, das zweite ist irgendeine ino-Datei mit dem COM-Port für den UARTzuUSB-Adapter. Dann sind Textausgaben auf Serial3 und kryptische MIDI-Zeichen sauber getrennt.
Ob Serial1 oder 2 oder 3 ist egal, nur eben nicht Serial.