Bei den LANC-Datenbytes müßte ich aber eben das Senden bitbangen, da ich ja reine Daten ohne Steuerbits brauche.
Und auch bei der LIN-Library sind das Problem die
delayMicroseconds(del); // delay
Das mit dem PIT ist etwas besser. Man könnte sicher einen Timer des Due so programmieren, dass man einen entsprechenden Interrupt bekommt. Ob man allerdings genau 9600 baud hin bekommt, weiß ich jetzt so ausm Stegreif nicht (wahrscheinlich nicht).
Trotzdem würde das jedes mal die CPU machen müssen und Kollisionen mit anderen Interrupts sind vorprogrammiert. In wie weit man das beim Due einen DMA-Controller machen lassen kann, weiß ich leider (noch) nicht - hast du mal nen Link zu Programmcode wo das auf dem Teensy gemacht wird?
Wenn jetzt in meinem Projekt nicht (saublöderweise) ausgerechnet die RX3/TX3-Pins am anderen Ende der Platine sitzen würden, könnte ich die Hardware einfach fertig machen und dann alles mal (in Software) ausprobieren - blöd gelaufen.
(Alle anderen UART-Pins sind anderweitig belegt und die Clock-Leitung des RX3/TX3 Anschlusses ist im SAM3X8E 144-Pin package eh nicht nach draußen geführt, was ja gerade passen würde.)
Der Teensy sieht nett aus, ist aber für mein Projekt "zu klein" - ich bin noch nicht ganz fertig und schon bei über 60 I/O-Pins, deshalb benutze ich auch den Core Due, der alle I/O-Pins des SAM3X8E nach außen führt (ist glaube ich der einzige Arduino Clon mit so vielen Anschlüssen).
9600 Baud wären ziemlich genau 104 Mikrosekunden. Ein paar Prozent Toleranz wären da wahrscheinlich erlaubt. Müsste man ausprobieren, ob das System dafür zu ausgelastet ist.
Falls man den UART im SPI-Modus betreiben kann, hätte man das Problem mit den Startbits ja nicht. Es stellen sich mir dann aber Fragen wie: Kriegt man bei SPI die Bitrate soweit runter ? Wieviele Bytes kann die SPI-Hardware da selbständig versenden, ohne dass da auch wieder ein Interrupt benötigt wird ?
Wenn das SPI die Bytes über Interrupt einzeln holen müsste, hätte man ja wieder ein ähnliches Problem wie mit dem Timer, nur etwa 8x seltener. Beim Teensy haben, glaube ich, je nach Modell eine oder zwei der SPIs einen vier Bytes Hardware TX FIFO. Da könnte man wahrscheinlich bei 9600 Bit/s einfach gelegentlich in der loop nachschieben, vier Bytes dauern ja über drei Millisekunden.
Das könnte schon reichen, um keine größeren Probleme zu machen. Zumal die CPU ja recht schnell ist und durch den Buffer nur das nächste Byte kopieren muss. Danach übernimmt wieder die UART Hardware. (So hat die CPU keine "delays" und muss auch nicht jedes Bit einzeln übertragen.)
Also der TX- und RX-Pin läuft als GPIO-Pin, bis das Startbit kommt (per Pin change interrupt), dann umschalten auf SPI und ein Byte am TX-Pin senden,... das ganze 4 mal, danach auf UART umschalten, am RX-Pin die Antwort von der Kamera empfangen und am Ende (nach einer festen Zeit seit dem Starbit) wieder auf GPIO umschalten.
Ob der Buffer auch größer sein kann, muss ich im Datenblatt erst mal nachlesen.
wie: Kriegt man bei SPI die Bitrate soweit runter ?
Puh, da dachte ich nicht das es ein Problem geben könnte. Eigentlich läuft ja nur der UART-Controller im SPI-Modus und damit sollte der zugehörige Timer die gleichen Geschwindigkeitsoptionen haben wie bei normalem UART Betrieb... aber auch das muss ich erst mal im Datenblatt nachlesen.
Im "Datenblatt" (Datasheet) nachlesen... purer Sarkasmus, bei 1459 Seiten
Soweit ich das verstanden habe, hat der USART-Controller nur einen Buffer für ein Byte. Durch die Verwendung des DMA Controllers kann man aber seinen eigenen Buffer/FIFO bauen - nur wie man das macht, liegt noch (weit) jenseits meines Verständnisses dieser Funktion.
Die Bitrate ist kein Problem: Frequenz(Bitrate) = Clock/CD
CD ist ein 16bit Wert, also selbst wenn man als Clock die maximalen 84MHz nimmt, bekommt man die UART/SPI-Frequenz runter bis auf 84.000.000/65536 = 1282 (Hz).
Dann bin ich noch über den Synchronous Serial Controller (SSC) gestolpert. Da heißt es, der sei extrem flexibel und bietet verschiedenste Konfigurationsmöglichkeiten, um eine großen Zahl von Schnittstellen/Protokollen zu unterstützen...
Kennt sich jemand mit dem SSC aus und kann mir sagen, ob der in diesem Fall für das LANC-Protokoll konfiguriert werden kann?
(Ich finde leider nur Beispiele für Audio-Anwendungen, keine Darstellung was man überhaupt alles mit einem SSC machen kann.)
