Go Down

Topic: LANC mit RX und TX steuern? (Read 590 times) previous topic - next topic

Doc_Arduino

Hallo,

lies einfach nochmal ...

Tschau
Doc Arduino '\0'

Messschieber auslesen: http://forum.arduino.cc/index.php?topic=273445
EA-DOGM Display - Demos: http://forum.arduino.cc/index.php?topic=378279

Psyco

Quote
lies einfach nochmal ...
Das ist nicht wirklich hilfreich, besonders da ich zwei voneinander unabhängige Fragen gestellt hab.

ArduFE

Die LIN-Library macht das Umschalten ja bei Baudraten bis 20000, also gut doppelt so schnell wie man es bei LANC bräuchte. Ist also kein Problem.

Psyco

Ok, das klingt schon mal gut.


Dann zur zweiten Frage: Kann ich das Senden der einzelnen Bytes per UART im SPI-Modus machen?

Das hätte den Vorteil, dass ich das Byte nur an den (gepufferten) UART-Controller schicke, der dann das Timing der einzelnen Bytes übernimmt und die CPU frei gibt (im Gegensatz zum bitbanging der LIN library).

ArduFE

Zum SPI-Modus kann ich nichts sagen, dazu kenne ich den Due nicht gut genug, habe da schon vor einiger Zeit beschlossen zum Teensy zu wechseln.

Es stimmt aber nicht, dass die LIN-Library Bitbanging bei den Datenbytes macht. Das macht sie nur bei den LIN-Spezialitäten, die andere Bitzeiten erfordern.

Ausschnitte:
Code: [Select]
// Start interface
 sleep(1); // Go to Normal mode
 // Synch Break
 serial_pause(13);
 // Send data via Serial interface
 if(ch==1){ // For LIN1 or Serial1
   Serial1.begin(bound_rate); // config Serial
   Serial1.write(0x55); // write Synch Byte to serial
   Serial1.write(ident); // write Identification Byte to serial
   for(int i=0;i<data_size;i++) Serial1.write(data[i]); // write data to serial
   Serial1.write(checksum); // write Checksum Byte to serial
   Serial1.end(); // clear Serial config


Und nur die Dinge wie das LIN-Break macht sie durch Bitbanging.
Code: [Select]

int lin_stack::serial_pause(int no_bits){
// Calculate delay needed for 13 bits, depends on bound rate
unsigned int del = period*no_bits; // delay for number of bits (no-bits) in microseconds, depends on period
if(ch=2){
PIOA->PIO_PER = PIO_PA13; // enable PIO register
PIOA->PIO_OER = PIO_PA13; // enable PA13 as output
PIOA->PIO_CODR = PIO_PA13; // clear PA13
delayMicroseconds(del); // delay
PIOA->PIO_SODR = PIO_PA13; // set pin high
PIOA->PIO_PDR = PIO_PA13; // clear configuration for PIO, needs to be done because Serial wont work with it
}else if(ch=1){
PIOA->PIO_PER = PIO_PA11; // enable PIO register
PIOA->PIO_OER = PIO_PA11; // enable PA11 as output
PIOA->PIO_CODR = PIO_PA11; // clear PA11
delayMicroseconds(del); // delay
PIOA->PIO_SODR = PIO_PA11; // set pin high
PIOA->PIO_PDR = PIO_PA11; // clear configuration for PIO, needs to be done because Serial wont work with it


Ich bin mir nur nicht sicher, wie das Starbit bei deinem Protokoll da hineinpasst.

Bei Teensy würde ich mich wohl an Beispielen orientieren, wo über PIT-Timer und DMA beliebige Bitfolgen über Pins ausgegeben werden. Bin aber weit davon entfernt, dass a) mal eben so hinzuschreiben oder b) auf den Due umzuschreiben.

Psyco

#20
Nov 14, 2017, 05:52 pm Last Edit: Nov 14, 2017, 06:04 pm by Psyco
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
Quote
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).

ArduFE

#21
Nov 14, 2017, 06:18 pm Last Edit: Nov 14, 2017, 06:18 pm by ArduFE
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.

Psyco

Quote
nur etwa 8x seltener
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.


Quote
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.

Psyco

Im "Datenblatt" (Datasheet) nachlesen... purer Sarkasmus, bei 1459 Seiten :-P

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.)

Go Up