Forum: Mikrocontroller und Digitale Elektronik UART als "Layer" auf SPI?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Guten Mittag,

hat jemand zufällig schon mal ein Protokoll mit Source gebastelt, mit 
dem man quasi UART als layer auf SPI aufsetzen kann?

Bevor jemand schreit - mir ist schon klar, dass SPI synchron und UART 
asynchron ist - es geht mir eigentlich nur darum, mit möglichst wenig 
Aufwand eine Firmware, die per UART kommuniziert, jetzt per SPI 
kommunizieren zu lassen, ohne dass viel am (UART-)Protokoll* geändert 
werden muss :)

Großartig wäre natürlich, wenn es auf Master-Seite (Raspi) gleich eine 
entsprechende Lib in zB Python geben würde - aber ich vermute, das muss 
man sich dann selbst bauen :)

Viele Grüße,
Mampf


*: Es werden eigentlich nur JSON-enkodierte Daten (als jeweils eine 
Zeile mit \n terminiert) hin und hergeschickt. Nach Empfang werden die 
JSON-Daten verarbeitet und es kann ein paar Sekunden dauern, bis die 
Antwort fertig ist, die dann als JSON zurückgeschickt wird.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Man könnte sich eine riesen super-duper Lib schreiben, welche sämtliche 
UART-Protokolle auf der ganzen Welt versteht (Baudrate, Timeouts, 
Handshake, 5..9 Datenbits, Parity, Break usw.).
Oder man schreibt eine einfache Lib für das UART-Protokoll, welches man 
konkret verwenden will.

von Gute Frage (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das größte Problem ist denke ich dass spi  ein Master/Slave System ist 
während bei Uart einfach jeder senden kann wenn er grad Lust hat.

Das heißt der SPI Master muss zyklisch immer wieder nach Daten pollen.

Finde ich keine sexy Lösung um ehrlich zu sein...

von Frank K. (fchk)


Bewertung
1 lesenswert
nicht lesenswert
Der größere Unterschied ist, dass es bei SPI Master und Slave gibt. Wenn 
Du aber ohnehin ein Request-Resonse-Protikoll fährst, ist das einfach:

Der Master schickt dem Request und ab dann einfach nur 0-Bytes und 
wartet darauf, dass irgendwann mal was anderes als 0-Bytes zurück kommen 
und liest die Antwort bis zum nächsten 0-Byte ein und stoppt dann. Da es 
ja ASCII ist, wäre das eine einfache Möglichkeit.

Oder Du hängst das hier

https://www.nxp.com/docs/en/data-sheet/SC16IS752_SC16IS762.pdf

oder einen entsprechend programmierten PIC an den Slave und bleibst bei 
Deiner UART-Kommunikation.

Fertigen Source habe ich nicht - ich hatte dieses Problem bis jetzt noch 
nicht gehabt.

fchk

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:

> Bevor jemand schreit - mir ist schon klar, dass SPI synchron und UART
> asynchron ist

Das ist nicht das Problem. Das ist vielmehr, das man bei UART zwei 
völlig unabhängige Signalpfade hat und zwei gleichberechtigte Peers. 
Jeder von beiden kann prinzipiell senden, wann immer er möchte.

Das ist bei SPI NICHT so, da gibt es einen Boss (master) und einen 
Befehlsempfänger (slave). Ausschließlich der Boss kann eine 
Kommunikation initiieren.

Um sowas wie eine UART-Kommunikation darüber zu implementieren, wird 
also im Minimum eine zusätzliche Leitung benötigt, mit der der Slave dem 
Master Kommunikationsbedarf signalisieren kann.

Hat man diese zusätzliche Leitung, ist es nicht mehr sehr schwer, eine 
"Dreidraht"-UART durch SPI zu "tunneln". Ein sehr einfach gestricktes 
Software-Protokoll macht das dann möglich.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Das ist bei SPI NICHT so, da gibt es einen Boss (master) und einen
> Befehlsempfänger (slave). Ausschließlich der Boss kann eine
> Kommunikation initiieren.

Hmm jaaaa, aber ... Du hast schon recht, allerdings ist meine 
Uart-Kommunikation eh nur halb-duplex. Der Master weiß eigentlich, wenn 
was zurückkommen sollte, insofern wird die Eigenschaft der 
gleichberechtigten Peers nicht genutzt.

Ich glaub ich weiß, wie ich es mache ... Schröööcklich ineffizient aber 
stupid simple.

1. Fall: Slave wartet auf Daten

Master sendet daten - terminiert mit einem "\n".

Slave arbeitet, währenddessen sendet Master 0x00 oder 0xff als Polling. 
Ist der Slave beschäftigt, shiften die 0x00/0xff durch das SPI und 
werden wieder an den Master gesendet. Der verwirft sie einfach, weil sie 
schlicht heißen "Keine Daten.

2. Fall: Slave will senden

Master pollt fleißig. Slave pusht Daten (ASCII-Zeichen) in den 
SPI-Puffer und Master empfängt dann andere Daten als 0x00/0xff. Die 
werden im Empfangspuffer gespeichert und mit \n terminiert.

Ich denke simpler geht es dann nicht mehr :thinking:

Zugegeben, das ist jetzt schon stark auf meinen Anwendungsfall 
zugeschnitten.

Mit einem schnellen Polling - vlt interrupt-driven - könnte man doch 
locker eine asynchronen UART mit 115kBaud emulieren.

Echt erstaunlich, dass es sowas noch nicht gibt ... Google war da 
absolut unergiebig.

: Bearbeitet durch User
von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:

> Slave arbeitet, währenddessen sendet Master 0x00 oder 0xff als Polling.
[...]
> Master pollt fleißig.

Unnützes Pollen ist mindestens ugly. Meistens ist es aber komplett 
idiotisch.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:

> Unnützes Pollen ist mindestens ugly. Meistens ist es aber komplett
> idiotisch.

Im konkreten Fall natürlich selbsterklärend dadurch, das während des 
Polling der SPI-Bus für andere Aktivitäten unbenutzbar ist...

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> c-hater schrieb:
>
>> Unnützes Pollen ist mindestens ugly. Meistens ist es aber komplett
>> idiotisch.

Ich bin mehr der Pragmatiker und weniger der Ästhetiker ¯\_(ツ)_/¯

>
> Im konkreten Fall natürlich selbsterklärend dadurch, das während des
> Polling der SPI-Bus für andere Aktivitäten unbenutzbar ist...

Natürlich^^ Und wenn ich jetzt behaupten würde, der Bus würde sonst für 
nichts anderes benutzt werden? Wäre es dann immer noch idiotisch? ;-)

: Bearbeitet durch User
von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:

> Natürlich^^ Und wenn ich jetzt behaupten würde, der Bus würde sonst für
> nichts anderes benutzt werden? Wäre es dann immer noch idiotisch? ;-)

Naja, zumindest wäre es "ugly". Denn es schließt zukünftige Nutzungen 
des Bus aus. Ohne jede Not...

Also wohl doch zumindest stark in der Nähe von Idiotie. Der einzige 
nachvollziehbare Grund wäre, das eben jener eine IO-Pin wirklich nicht 
mehr verfügbar ist. Was allerdings meiner Erfahrung nach praktisch nie 
der Fall ist, wenn C'ler Libs zusammenleimen...
Da bleiben in aller Regel mehr genug Pins, die sich sharen ließen, um 
einen für wirklich wichtige Aufgaben freizumachen, z.B. die Nutzbarkeit 
eines kompletten Bus...

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Der einzige
> nachvollziehbare Grund wäre, das eben jener eine IO-Pin wirklich nicht
> mehr verfügbar ist. Was allerdings meiner Erfahrung nach praktisch nie
> der Fall ist, wenn C'ler Libs zusammenleimen...

Jau, da hast du recht.

Ich mache die Anpassungen für einen Bekannten, dem ich geraten habe, in 
seinem Platinen-Layout eine zusätzliche I/O-Leitung zu meinem Modul zu 
ziehen, damit der main-µC benachrichtigt werden kann, wenn der Slave 
Daten senden möchte.

Wahrscheinlich werde ich die dann auch benutzen.

Vielen Dank für eure Antworten!
Mampf

von Dieter R. (drei)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:

> 2. Fall: Slave will senden
>
> Master pollt fleißig.

Nach deinen einleitenden Worten zur Aufgabenstellung:

"Nach Empfang werden die JSON-Daten verarbeitet und es kann ein paar 
Sekunden dauern, bis die Antwort fertig ist, die dann als JSON 
zurückgeschickt wird."

muss er nicht fleißig pollen, sondern bloß mal gelegentlich. Wenn er das 
z. B. alle 100 ms tut, dann ist das keine merkbare Belastung. Also kein 
Grund, über weiteren Aufwand nachzudenken.

von Joggel E. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Ich wuerde die Funktionalitaet ueber das UART Uebertragen. Denn 
offensichtlich sitzt auf der anderen Seite des Uarts ein Controller.
Also ReadADC(), WriteDAC(u), usw und mich nicht um unterliegende Details 
kuemmern.

von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> hat jemand zufällig schon mal ein Protokoll mit Source gebastelt, mit
> dem man quasi UART als layer auf SPI aufsetzen kann?

Leider nicht, sollte aber theoretisch kein Problem sein.

Die SPI muss nur schneller laufen als die UART Baudrate-. Der Master 
muss dann dauernd senden damit Empfangsdaten auch eingelesen werden.

von сорок две (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt 16C550-artige UARTs mit SPI Anbindung in Hardware, z.B. 
SC16IS752.

сорок две

von Dieter R. (drei)


Bewertung
0 lesenswert
nicht lesenswert
сорок две schrieb:
> Es gibt 16C550-artige UARTs mit SPI Anbindung in Hardware, z.B.
> SC16IS752.
>
> сорок две

Das ist aber SPI als Layer auf UART.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.