Go Down

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

Psyco

Hi,

ich möchte eine Kamera per LANC-Anschluß mit einem Core Due (Arduino Due Klon) steuern, bzw. Infos abfragen (also senden und empfangen).

Wegen der Spannungsdifferenz (LANC 5-8V, Due 3.3V) werde ich die folgende Schaltung verwenden:



So weit so gut und wenn ich das dann an einen GPIO-Pin hänge, muss ich halt das LANC-Protokoll per Software implementieren.
Das kostet aber CPU-Zeit, blockt teilweise die CPU (damit das Timing stimmt) und/oder kann durch andere Interrupts aus dem Takt gebracht werden. Ist also keine besonders gute Lösung.

Deshalb würde ich gerne einen der UART-Ports nutzen und den halb duplex LANC-Anschluß mit RX3 und TX3 verbinden. Dafür bietet sich wohl eine ähnliche Schaltung wie diese...



...oder diese an



(oder ein Analog switch IC das ich entsprechend steuere).


Das Problem ist aber dann folgendes:

Quote
To send a command to the camera the command has to be synchronized to the LANC signal from the camera. The camera puts out a start bit before and a stop bit after each byte. The first command byte from the controller (Arduino) has to be transmitted exactly between the start bit that follows the long pause between the 8 byte data packages and the following short stop bit.

(http://controlyourcamera.blogspot.de/2011/02/arduino-controlled-video-recording-over.html)
Die Kamera sendet also immer die Start- und Stopbits, auch wenn der Controller (Arduino) etwas sendet.

Kann man die UART-Schnittstelle so programmieren, dass beim Senden keine Start- und Stopbits gesendet werden? (Beim Empfangen diese aber berücksichtigt werden.)

Und wie kann ich am RX-Pin das Startbit von der Kamera "abfangen"?

Doc_Arduino

Hallo,

halb duplex bedeutet, nur einer kann senden, es können nicht 2 oder mehr gleichzeitig senden.

Die UART kannste programmieren wie du möchtest. Nur um das Start/Stop Bit musste dich nicht kümmern. Das macht die UART alleine, wenn man sie lässt.

Mehr kann ich dir nicht sagen, weil ARM stat AVR.
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

Halb Duplex ist klar. Im Fall von LANC sendet erst der Controller 4 Byte (Befehle) und dann die Kamera 4 Byte zurück (Statusinfos). Das Timing ist vorgegeben.

Aber, die Kamera sendet immer die Start- und Stopbits, auch wenn der Controller mit senden dran ist.
Und das ist halt völlig an einem normalen UART-Protokoll vorbei.

Die UART-Schnittstelle des Arduino muss also beim Empfangen die Steuerbits berücksichtigen und beim Senden diese aber weg lassen (weil die Kamera die ja sendet und keine Steuerbits erwartet).
Und (so weit ich weiß) kann man den UART-Controller nicht für Senden und Empfangen unterschiedlich konfigurieren... oder geht das?


Zudem muss der UART-Controller mit dem Senden warten, bis die Kamera das nächste Startbit gesendet hat. Dazu könnte ich ggf. noch einen GPIO-Pin mit dem RX-Pin verbinden und über einen Pin-change Interrupt auf das Startbit warten. Schön wäre es aber, wenn ich nicht noch einen Pin und noch einen Interrupt verwenden müßte.


(Ich hatte am Anfang die Wahl zwischen Arduino Mega und Due und hatte den Eindruck (aus den Datenblättern), dass der ARM-Chip auch alles kann, was der AVR-Chip kann (und noch viel mehr). Also wenn man den UART-Controller des AVR so programmieren kann, dann geht das (sicher) auch mit dem ARM.)

Doc_Arduino

#3
Nov 11, 2017, 05:38 pm Last Edit: Nov 11, 2017, 05:38 pm by Doc_Arduino
Hallo,

wenn die Kamera unkontrolliert sendet, was ich mir nicht vorstellen kann, aber gut ich weiß es nicht, dann musste dir Gedanken machen. Entweder der Kamera eine extra serielle gönnen oder Empfangslücken ausnutzen. Man muss kreativ werden.


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

Hmm, ich glaube das hast du falsch verstanden:

Die Kamera gibt dem Controller die Startbits vor! Nach jedem Startbit darf der Controller ein Byte senden (die Baudrate ist dabei vorgegeben). Mit einem Stopbit beendet die Kamera dieses "Übertragungsfenster".

Auf die Kamera (und ihr Timing) habe ich dabei keinen Einfluß, es ist aber festgelegt und läuft immer nach dem gleichen Schema ab (siehe den Link im ersten Post).

Erst "empfängt" die Kamera 4 Byte:
0) Lange Pause
1) Startbit von der Kamera zum Controller
2) Controller sendet erstes Kommando, 1 Byte
3) Stopbit von der Kamera zum Controller
4) kurze Pause
5) Startbit von der Kamera zum Controller
...
(insgesamt 4 mal)

danach sendet die Kamera 4 Byte zurück:
a) Startbit von der Kamera
b) 1 Byte von der Kamera
c) Stopbit von der Kamera
d) kurze Pause
e) Startbit von der Kamera
...
(auch das insgesamt 4 mal)

Die Kamera gibt also immer den Takt vor, was kein Problem ist, wenn die Kamera im zweiten Teil sendet. Das kann ich so direkt über den RX-Pin und die UART-Schnittstelle empfangen.

Aber der erste Teil ist mein Problem. Wie sage ich dem UART-Controller, dass er die Startbits von außen vorgegeben bekommt?

Doc_Arduino

Hallo,

gut, die Kamera sendet also nur auf Anforderung. Liest sich schon einmal anders.
Tja ich habe keine Ahnung was das mit dem Startbit genau sein soll. Wenn das über die UART kommt und wirklich nur das Startbit/Stopbit ist, dann bekommste immer einen Frame Error von der UART als Antwort. Ich kann mir immer noch nicht vorstellen das deine Beschreibung so stimmt.

Der 2. Teil deiner Kommunikation haut hin. Das muss man nicht extra ausdrösseln. Das ist der ganz normale Ablauf mit Standardkonfiguration einer UART. Die Kamera sendet 4 Byte und gut ist.

Der erste Teil ist seltsam. Entweder ist deine Beschreibung falsch oder das ist wirklich so komisch. Keine Ahnung. Da hilft nur ein Datalogger. Wie gesagt, ich kann mir nicht vorstellen das nur ein einziges Bit auf der UART gesendet wird. Es sollte immer ein Byte sein. Da kann ich dir nicht weiterhelfen. Ehrlich. Du kannst dich nur selbst mit der UART befassen. Nebenbei lernste die damit richtig kennen. Ein Datalogger ist bestimmt hilfreich.

PS:
Falls das mit dem einzelnen Startbit/Stopbit wirklich so sein sollte, kannste nur die UART Pins zwischendurch umkonfigurieren zu normalen I/Os, wenn der eine Signalwechsel kommt, zur UART umschalten usw.
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

ArduFE

Der erste Teil ist seltsam. Entweder ist deine Beschreibung falsch oder das ist wirklich so komisch.
Scheint wirklich so zu sein. In Wikipedia steht
Quote
The bi-directional protocol is made up of 8 (8-bit) bytes, usually clocked by the camera at 9600 bit/s. Each frame of bytes occurs in sync with the beginning of each video frame (NTSC or PAL).
Ich nehme an, das hier ist schon bekannt ?
https://create.arduino.cc/projecthub/L-Rosen/serial-to-lanc-control-l-70f735

Es gibt solche seriellen Protokolle, wo Teile eines Frames von zwei Teilnehmern gesendet werden, z.B. den LIN-Bus im Auto. Da es dafür was für den Due gibt, hilft das vielleicht weiter, um zu sehen was man da machen kann. So wie ich das sehe, wechseln die da zwischen Serial und direktem Portzugriff:
https://github.com/macchina/LIN
(Der Machina M2 ist ein Due Clon für Automotive Anwendungen.)

Doc_Arduino

Hallo,

dann ist das wirklich so ein doofes Protokoll. Jetzt hat er ja was er wollte.   :)
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
Ich nehme an, das hier ist schon bekannt ?
https://create.arduino.cc/projecthub/L-Rosen/serial-to-lanc-control-l-70f735
Klar, aber auch da (wie in allen anderen Lanc-Projekten die ich gefunden habe) wird das über einen GPIO-Pin und bitbanging gelöst.

Quote
...wechseln die da zwischen Serial und direktem Portzugriff:
https://github.com/macchina/LIN
(Der Machina M2 ist ein Due Clon für Automotive Anwendungen.)
Interessantes Projekt, aber auch da wird der nicht-standart UART Teil per bitbanging gemacht.


Mein Problem ist, dass ich insgesamt 9 Geräte an allen verfügbaren SPI, UART im SPI-Modus und UART - Ports des Core Due hängen hab. Davon sind min. 2 äußerst zeitkritisch und die CPU muss aber noch 3D-Gyro Daten auswerten, 3 Schrittmotoren steuern, ein Display mit Daten versorgen und den gesamten Datenverkehr überwachen.
Deshalb möchte ich möglichst viel Arbeit an die Zusatzeinheiten (UART Controller, DMA Controller,...) abgeben. Leider sind die 2 zeitkritischen Geräte genau die, die nicht dem SPI/UART Standart folgen.

Im Moment sieht es also so aus, als müßte ich die Lanc-Leitung direkt an den RX-Pin hängen, der dann nur "zuhört" und parallel dazu einen GPIO-Pin, der das Startbit abfängt, umschaltet und dann sofort per bitbanging den Rest sendet.
Wobei ich noch nicht weiß, wie ich bei den vielen Interrupts das Timing sicherstelle (ohne die CPU zu blocken), da LANC mit 9600 baud extrem langsam ist und das senden eines Bytes einfach ewig dauert (im Vergleich dazu laufen die SPI-Geräte mit 200 kHz bis 1 MHz).


Quote
dann ist das wirklich so ein doofes Protokoll. Jetzt hat er ja was er wollte.   :)
Danke, aber Schadenfreude ist hier etwas fehl am Platz. Ist ja nicht so, dass ich mir dieses bekloppte Protokoll ausgesucht hätte. Oder ganz allgemein, JEDER Kamerahersteller verbiegt die normalen Schnittstelleprotokolle so, dass es immer ein PITA ist, einen Controller selber zu bauen... wozu das auch immer gut sein soll?

Doc_Arduino

#9
Nov 12, 2017, 09:14 pm Last Edit: Nov 12, 2017, 09:15 pm by Doc_Arduino
Hallo,

das hast du komplett missverstanden. Das war und ist keine Schadensfreude. Ich dachte du kannstest die Seite noch nicht und hast jetzt endlich alles zur Hand für dein Problem/Projekt. Alles erklärt und mit Code. Im Grunde hast du alles zur Hand.
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

Ok, aber wenn ich das per bitbanging machen wollte, dann hätte ich schon vor dem Post hier im Forum alle Infos gehabt - eben weil ich mir die ganzen Projekte im Netz schon gründlich angesehen habe...

...aber mir gehts ja darum, ob es einen Weg gibt bitbanging zu vermeiden und die Hardware des ARM geschickt einzusetzen.

Deshalb mein Post hier - ich hoff(t)e halt, dass jemand einen Trick kennt, wie man die UART-Schnittstelle so verbiegen kann, dass sie das LANC-Protokoll versteht/beherrscht.


Theseus

Das einfachste wird sein, einen zusätzlichen Nano, Pro mini oder Stand-Alone 328 zu nehmen, der sich um den LANC-Bus kümmert und die Ergebnisse an den Due weiterreicht.

Psyco

Quote
Das einfachste wird sein, einen zusätzlichen Nano, Pro mini oder Stand-Alone 328 zu nehmen, der sich um den LANC-Bus kümmert und die Ergebnisse an den Due weiterreicht.
Dafür hab ich in dem Projekt eigentlich keinen Platz mehr (außerdem muss der Chip dann auch noch programmiert werden... von außen!).

Doc_Arduino

#13
Nov 13, 2017, 01:16 am Last Edit: Nov 13, 2017, 01:16 am by Doc_Arduino
...aber mir gehts ja darum, ob es einen Weg gibt bitbanging zu vermeiden und die Hardware des ARM geschickt einzusetzen.

Deshalb mein Post hier - ich hoff(t)e halt, dass jemand einen Trick kennt, wie man die UART-Schnittstelle so verbiegen kann, dass sie das LANC-Protokoll versteht/beherrscht.
Der Trick ist, wie meine reine Vermutung schon war und im hinzugekommen Link beschrieben steht, die UART Pins immer umzukonfigurieren. Anders geht das erstmal nicht. Was man noch machen könnte wäre einen extra I/O Pin mit dem Rx der UART zuverbinden der nur zur Startbit/Stopbit Erkennung dient. Allerdings erfordert das einigen Aufwand der Filterung, weil der sieht ja sämtliche Signalwechsel der Frames die eingelesen werden. Das heißt du musst vorher wissen was für ein geplantes Frame reinkommt um dann entscheiden zu können. Obs ein echter UART Fehler ist oder nicht.
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

Dann zwei Fragen:

  • Ist es ein Problem den UART-Controller/eine UART-Schnittstelle im kHz-Bereich umzukonfigurieren? Oder ist das nicht vorgehsehen, so dass der Chip an dieser Stelle dann zu heiß wird,...?
  • Nachdem man die Start- und Stopbits (beim Senden) der UART-Schnittstelle anscheinend nicht abschalten kann, könnte man den UART-Controller doch dazu in den SPI-Modus schalten, oder? Da werden ja keine Steuerbits gesendet (die Clock-Leitung wird einfach ignoriert).


Das würde dann beudeuten, dass ich die Schnittstelle/die Pins im kHz-Bereich zwischen UART, SPI und GPIO hin und her schalten muss..."hurra".

Go Up