OK, es gibt bei Serial einen Timeout.
Aber der verwendet bei allen AVR Arduinos den Timer0, wie es auch delay(), millis() usw. tun.
Keine Kollision möglich.
Es kann natürlich sein das DMX auf UART0, mit Serial auf UART0, kollidiert.
Auch können deine Libs irgendwelche Timer benutzen.
Aber wie schon gesagt: Wire und Serial tun das nicht.
Man liest halt immer anders.
In meinem Post vor ein paar Tagen hieß es ich greife über UART auf die selbe Schnittstelle zu wie unter I²C.
Ich krieg auch die Selben Fehler wenn ich mit dem Seriellen Monitor und DMX arbeiten will.
Immer Vector 18 und 19 doppelt belegt.
Mit DMX auf RX1 auf nem Mega geht es.
In meinem Post vor ein paar Tagen hieß es ich greife über UART auf die selbe Schnittstelle zu wie unter I²C.
Naja....
Die I2C Vectoren liegen ganz woanders.
Mega: Vector 40 $004E TWI 2-wire Serial Interface
Uno: Vector 25 0x0030 TWI 2-wire Serial Interface
Immer Vector 18 und 19 doppelt belegt.
Mit DMX auf RX1 auf nem Mega geht es.
Mega:
Vector 18 $0022 TIMER1 COMPA Timer/Counter1 Compare Match A
Vector 19 $0024 TIMER1 COMPB Timer/Counter1 Compare Match B
UNO
Vector 18 0x0022 SPI, STC SPI Serial Transfer Complete
Vector 19 0x0024 USART, RX USART Rx Complete
Wenn DMX diesen Timer oder auch UART benutzt, dann ist das so.
Aber dieses dann Serial und Wire anzulasten ist mindestens ungerecht.
1: Denn diese können sich nicht dagegen wehren.
2: Nutzen sie diesen Timer überhaupt nicht.
3. Sie benötigen ihre jeweiligen Rx/Tx ISRs, zwingend.
Wenn du versuchst 2 ISR auf einen Vector zu legen, dann haut dir der Compiler/Linker das um die Ohren.
Mit Fug und Recht.
Ich krieg auch die Selben Fehler wenn ich mit dem Seriellen Monitor und DMX arbeiten will.
Beides auf einer Schnittstelle?
Daran versagst du sowieso, auch ohne Meldungen.
Die UART ist kein Bus, welcher 2 Dinge gleichzeitig tun kann.
Also kannst du nur eine Verwendung fpr eine UART Schnittstelle finden.
Aber kann dann der MPU6050 Vector 18 und 19 verwenden wenn er I²C gesteuert wird?
Sollte doch dann Vector 25 sein wenn ich dich jetzt richtig verstehe?
Aber kann dann der MPU6050 Vector 18 und 19 verwenden wenn er I²C gesteuert wird?
Wenn du Vector 18 und 19 benennst, musst du auch benennen welchen µC du meinst.
Ohne, ist die Information fast wertlos.
Sollte doch dann Vector 25 sein wenn ich dich jetzt richtig verstehe?
Du meinst also den UNO bzw. den ATMega328P
Ja, der benötigt für TWI den Vector 25 und nicht 18 + 19.
18 + 19 gehen beim UNO für Serial drauf.
Benutzt du Serial auf dem UNO, dann kannst du kein DMX einsetzen.
Denn dein DMX benötigt die gleichen Vectoren.
Der serielle Monitor und DMX gleichzeitig ist so nicht möglich.
Daher die Doppelbelegung.
Mit I2C oder MPU6050 hat das alles überhaupt nichts zu tun.
Und die Idee mit dem Timer Problem scheint wohl nur eine Nebelkerze zu sein, um dich selber und mich auch gleich zu verwirren.
Keineswegs.
Is der Nano, also Uno oder 328p.
Füge mal DMXSerial.h und MPU6050.h in einem Sketch ein und kompiliere ohne den Seriellen Monitor einzubinden. Das der nicht geht mit DMX zusammen seh ich ja noch ein.
Aber der MPU ist am I²C angebunden.
combie:
In meinem Post vor ein paar Tagen hieß es ich greife über UART auf die selbe Schnittstelle zu wie unter I²C.
Nein. Was da passiert ist dass die DMX Library die serielle Schnittstelle (UART) nochmal selbst implementiert hat statt auf die Arduino Implementation zuzugreifen. Sehr wahrscheinlich aus Performance-Gründen. Dann konntest du nicht einfach das Arduino Serial verwenden. Hatte nichts mit I2C zu tun. Deshalb ging es ja sobald du Serial1 statt Serial verwendet hast.
Der Konflikt mit den Interrupt Vektoren kam ganz einfach weil die DMX Library und die Arduino Serial Klasse versucht haben das Gleiche zu machen.
UART ist übrigens eine Punkt-zu-Punkt Verbindung. I2C ist dagegen ein Bus an denen man mehrere Teilnehmer anschließen kann, solange diese unterschiedliche Adressen habe
DMX benötigt ein definiertes Break Signal.
Das ist mit den ganzen HardwareSerial Klassen nicht zu erzeugen oder gar zuverlässig auszuwerten.
Das dürfte der Hauptgrund sein.
Auch ist ein DMX512 Universum 512Byte groß.
Der originale Ringpuffer ist da wenig hilfreich.
Kadara:
Keineswegs.
Is der Nano, also Uno oder 328p.
Füge mal DMXSerial.h und MPU6050.h in einem Sketch ein und kompiliere ohne den Seriellen Monitor einzubinden. Das der nicht geht mit DMX zusammen seh ich ja noch ein.
Aber der MPU ist am I²C angebunden.
Der MPU ist nur eine Nebelkerze.
Sachte ich doch schon!
Der Sketch verwendet 878 Bytes (2%) des Programmspeicherplatzes. Das Maximum sind 32256 Bytes.
Globale Variablen verwenden 533 Bytes (26%) des dynamischen Speichers, 1515 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
Ah, so genau habe ich mit das nicht gesehen. Und ich weiß auch nicht wie DMX genau funktioniert.
Aber woher der Konflikt kommt sieht man sehr leicht wenn man sich mal den Quellcode anschaut:
Das muss man nicht im Detail verstehen, aber man sieht dass hier mit den Registern und Interrupt-Vektoren (ab Zeile 437) der seriellen Schnittstelle hantiert wird. Dann sollte eigentlich klar dass sein dass sich das beißt wenn man dann nochmal Serial.begin() macht.
Auch ist eben auf Arduinos mit mehrere seriellen Schnittstellen vorgesehen eine der zusätzlichen Schnittstellen zu verwenden. Auf dem Mega kann man in Zeile 26 die Kommentar-Schrägstriche entfernen. Dann läuft DMX auf Serial1 und man kann Serial für die Kommunikation mit dem PC verwenden. Auf dem DMX Shield gibt es da wohl je nach Version Lötbrücken oder Löcher für Kabel um das einzustellen:
Ich sag ja, mit serial.begin seh ichs ein.
Aber dann strick DMX alles wohl so um das auch der MPU auf 18 19 landet oder wie?
Ich brauch den Seriellen Montor ja nicht zwingend.
Nur ohne gehts halt auch nicht.
Das Display jedenfalls bleibt recht unbeindruckt wenn ich DMXSerial und Liquidcristal einfüge.
Der MPU eben nicht.
Kadara:
Aber dann strick DMX alles wohl so um das auch der MPU auf 18 19 landet oder wie?
Nein.
1.) Die DMX Library macht nichts außer auf die serielle Schnittstelle zuzugreifen
2.) Sie kann kann gar nichts anderes machen. Die Interrupt Vektoren sind in der Hardware fest vergeben!
Dann schauen wir uns mal den Quellcode der MPU Library an:
Hier wird es komplizierter. Da gibt es wohl einzelne Methoden die Ausgaben auf der seriellen Schnittstelle machen. PID(), printfloatx() und PrintActiveOffsets().
Das sollte aber nicht kompiliert werden wenn man es nicht verwendet. Könnte man auch auskommentieren
Sicher ist es wie gesagt das so umzustricken dass DMX mit Serial1 läuft. Also den Kommentar in der Library ändern und das Shield entsprechend verdrahten. Dann kann mit Serial machen was man will
Aber dann strick DMX alles wohl so um das auch der MPU auf 18 19 landet oder wie?
Der MPU ist eine Nebelkerze, an der du dich fest gefressen hast.
Und Reproduzierbar, bei mir, ist es auch nicht.
Vielleicht ist es mal an der Zeit mir ein Beispiel zu zeigen.
Hier wird es komplizierter. Da gibt es wohl einzelne Methoden die Ausgaben auf der seriellen Schnittstelle machen. PID() und und printfloatx().
Das sollte aber nicht kompiliert werden wenn man es nicht verwendet. Könnte man auch auskommentieren
Das macht die MPU Library, welche ich verwende, nicht.
Aber schon klar, wenn die Lib selber Ausgaben auf Serial macht, dann werden auch die Vektoren für Serial etabliert. Was sollen Compiler/Linker denn auch sonst tun, als ihren Job.
Natürlich kracht es dann mit DMX.
Aber mit I2C, Wire oder TWI hat das dann immer noch überhaupt nichts zu tun.
Einfach nur eine Gemeinheit in der MPU Lib.
Welche Lib verwendest du denn?
Alle die ich probiert habe, hatten die selben Probleme.
Wenns soweit aufgedrüselt wird versteh ich langsam auch wo das Problem ist.
Der MPU belegt eben nicht nur I²C sondern auch UART.
Ein Beispiel ist wie gesagt das hier.
#include <DMXSerial.h> #include "MPU6050.h"
void setup() {
// put your setup code here, to run once:
}
void loop() {
// put your main code here, to run repeatedly:
}
Das ergibt den Fehler.
Sowie jede andere DMX, oder MPU Lib die ich gefunden hab.
Ich will hier nicht verwirren, sondern nur selbst verstehen.
Ich bin verwirrt - 102 Post's und keinen Code-Tag?
Um uns diese Fehlermeldung zu ermöglichen, wäre jeweils ein Link auf diese Libs wünschenswert.
(warum wird hier eine örtliche MPU6050 eingebunden? Liegt ggf. dort schon der Hund begraben, da Dort 'was Eigenes' passiert?)
Du musst dir halt mal den Quellcode anschauen und nach "Serial" suchen (Notepad++ hilft da vielleicht). Der Baustein selbst braucht kein Serial. Aber die Library macht evtl. ein paar unnötige Ausgaben auf die man auch verzichten kann.
Das ist aber auch ein Zeichen unschöner Programmierung. Da sollte man wirklich eine saubere Library verwenden, die nicht von selbst sowas macht.
Oder was ich jetzt schon wiederholt gesagt habe:
Öffne DMXSerial.cpp und entferne die Kommentarstriche in Zeile 26 so dass DMX_USE_PORT1 gesetzt ist. Dann läuft DMX auf Serial1. Dann musst du wohl das DMX Shield so verkabeln dass es auch auf Serial1 geht, aber das ist vorgesehen wenn ich das richtig sehe.
Dann hast du nicht nur keine Probleme mit fremden Libraries, sondern kannst auch selbst den seriellen Monitor zur Ausgabe verwenden
Auf die Libs habe ich ja verwiesen.
Die Sache war auch auf dem Nano und da gibts kein USE PORT1.
Ich wollte das hier auch nicht unnötig in die Länge ziehen in nem anderen Thread.
Aber ich habe jetzt andere Controller gekauft und neue Platinen bestellt.
Denn mir fehlt leider das Hintergrundwissen die Library anzupassen.
Bei der Von Combie verlinkten Lib sehe ich aber auch nicht wo da ein Gyrosensor angesprochen werden soll.
Wenn du den Thread liest verstehst du daß der Mini erst ins spiel kam als der Nano nicht funktioniert hat und ich bereits Platinen mit Nano und MPU und DMX drauf hab machen lassen.
Das ich auf den mini gehen musste, weil ich nur so den kram kompiliert gekriegt hab wollte ich eigentlich mit dem Thread vermeiden.