Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #221421 > unrolled thread

Effizientes serielles Protokoll für Arduino?

Back to article view | Back to de.sci.electronics

Contents

  Effizientes serielles Protokoll für Arduino? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-01-22 11:57 +0100
    Re: Effizientes serielles Protokoll für Arduino? Christian Zietz <newsgroup.1001@chz.xyz> - 2017-01-22 12:18 +0100
      Re: Effizientes serielles Protokoll für Arduino? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-01-22 11:29 +0000
        Re: Effizientes serielles Protokoll für Arduino? Christian Zietz <newsgroup.1001@chz.xyz> - 2017-01-22 13:25 +0100
        Re: Effizientes serielles Protokoll für Arduino? Hermann Riemann <nospam.gerct08@hermann-riemann.de> - 2017-01-22 14:10 +0100
          Re: Effizientes serielles Protokoll für Arduino? Christian Zietz <newsgroup.1001@chz.xyz> - 2017-01-22 15:00 +0100
            Re: Effizientes serielles Protokoll für Arduino? Hermann Riemann <nospam.gerct08@hermann-riemann.de> - 2017-01-22 15:11 +0100
            Re: Effizientes serielles Protokoll für Arduino? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-01-22 17:13 +0100
            Re: Effizientes serielles Protokoll für Arduino? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-01-22 19:40 +0000
              Re: Effizientes serielles Protokoll für Arduino? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-01-22 19:47 +0000
          Re: Effizientes serielles Protokoll für Arduino? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-01-22 19:32 +0000
    Re: Effizientes serielles Protokoll für Arduino? "MaWin" <me@private.net> - 2017-01-22 12:20 +0100
      Re: Effizientes serielles Protokoll für Arduino? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-01-22 17:07 +0100
        Re: Effizientes serielles Protokoll für Arduino? "MaWin" <me@private.net> - 2017-01-22 19:22 +0100
    Re: Effizientes serielles Protokoll für Arduino? Martin Τrautmann <t-usenet@gmx.net> - 2017-01-22 12:40 +0000
    Re: Effizientes serielles Protokoll für Arduino? Hermann Riemann <nospam.gerct08@hermann-riemann.de> - 2017-01-22 14:04 +0100
    Re: Effizientes serielles Protokoll für Arduino? Ralph Aichinger <ra@pi.h5.or.at> - 2017-01-22 12:32 +0100
      Re: Effizientes serielles Protokoll für Arduino? Hermann Riemann <nospam.gerct08@hermann-riemann.de> - 2017-01-22 15:56 +0100
      Re: Effizientes serielles Protokoll für Arduino? Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2017-01-22 17:14 +0100
    Re: Effizientes serielles Protokoll für Arduino? Holger <me@privacy.org> - 2017-01-22 16:55 +0100
      Re: Effizientes serielles Protokoll für Arduino? Stefan <df9bi@arcor.de> - 2017-01-23 10:24 +0100
        Re: Effizientes serielles Protokoll für Arduino? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2017-01-23 11:20 +0000
    Re: Effizientes serielles Protokoll für Arduino? Edzard Egberts <news@edzeg.net> - 2017-01-23 08:12 +0100

Page 1 of 2  [1] 2  Next page →

#221421 — Effizientes serielles Protokoll für Arduino?

Hallo,

ich brauche ein Protokoll um drei verschiedene Werte zu übertragen.

Jeder Wert hat die Länge von einem Byte. Die volle Länge des Bytes wird 
genutzt. Ich habe also keine "Magic-Values" die ich zum Synchronisieren 
verwenden könnte.

Die Werte kommen nicht immer in der selben Reihenfolge.

Es kommt auf Geschwindigkeit an. Es handelt sich um einen Datenstrom der 
mit möglichst geringem Delay vom PC zum Arduino soll. Ich habe also 
keinen Platz die Werte erst aufwendig in ein XML oder wasauchimmer zu 
basteln.

Mein aktueller Plan:

Ich splitte ein Byte auf 2*4 Bit:

8765 4321
  ^    ^
  |    '- Nutzdaten
  '------ Adresse

Ich brauche also für jedes Byte zwei Bytes und zwei Adressen, kann die 
Werte aber in beliebiger Reihenfolge vom PC zum Arduino senden. Am 
Arduino müsste ich dann den ersten Teil des Bytes cachen und erst wenn 
der zweite Teil kommt kann kombiniert und verarbeitet werden.

Geht es eleganter/schneller?

Danke im Voraus

Gruß

Manuel

[toc] | [next] | [standalone]

#221423

> Ich splitte ein Byte auf 2*4 Bit:
> 
> 8765 4321
>   ^    ^
>   |    '- Nutzdaten
>   '------ Adresse
> 
> Ich brauche also für jedes Byte zwei Bytes und zwei Adressen, kann die 
> Werte aber in beliebiger Reihenfolge vom PC zum Arduino senden.

Warum so umständlich? Wenn Du eh mit zwei Bytes pro Nutzbyte arbeitest,
dann doch lieber: ID(8bit) Nutzbyte(8bit). Welchen Sinn hat es, die zwei
Nibbles des Nutzbytes so umständlich aufzuteilen, wie Du es oben
beschreibst?

> Geht es eleganter/schneller?

Gleich 10 Bit lange Frames übertragen? Also ID(2bit) Nutzbyte(8bit). Du
schreibst ja nichts dazu, wie Deine Übertragung abläuft. Ist die
Schnittstelle auf ganze Bytes beschränkt?

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

[toc] | [prev] | [next] | [standalone]

#221425

On 2017-01-22, Christian Zietz <newsgroup.1001@chz.xyz> wrote:
>
> Warum so umständlich? Wenn Du eh mit zwei Bytes pro Nutzbyte arbeitest,
> dann doch lieber: ID(8bit) Nutzbyte(8bit). Welchen Sinn hat es, die zwei
> Nibbles des Nutzbytes so umständlich aufzuteilen, wie Du es oben
> beschreibst?

Synchronisation. Wenn Du bei Deinem Verfahren einmal ein Byte verlierst,
hast Du keine Chance mehr, zu erkennen, was ID und was Daten sind.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#221427

Michael Schwingen schrieb:

> Synchronisation. Wenn Du bei Deinem Verfahren einmal ein Byte verlierst,
> hast Du keine Chance mehr, zu erkennen, was ID und was Daten sind.

Zugegeben. Um zu wissen, ob das aber überhaupt ein Problem ist, müsste
Manuel seine Schnittstelle auch mal beschreiben. Übertragung "vom PC zum
Arduino" kann ja alles sein von seriellem Bit-Banging bis zu HTTP über WLAN.

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

[toc] | [prev] | [next] | [standalone]

#221432

Am 22.01.2017 um 12:29 schrieb Michael Schwingen:

> Synchronisation. Wenn Du bei Deinem Verfahren einmal ein Byte verlierst,
> hast Du keine Chance mehr, zu erkennen, was ID und was Daten sind.

1. Mit einem timer eine Ruhepause einlegen
und danach wieder Sendebeginn.

2. Die ID belegt nicht alle Werte im Bereich 0:255.
Bei einem nicht durch ID belegten Inhalt sollte es ich
um ein Datenbyte handeln.

Hermann
    der allerdings bei jedem Verfahren das Risiko
    fehlerhafte Daten sieht,
    und Daten  kein IoT-Vertrauen entgegen bringen mag.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#221435

Hermann Riemann schrieb:

> 1. Mit einem timer eine Ruhepause einlegen
> und danach wieder Sendebeginn.
> 
> 2. Die ID belegt nicht alle Werte im Bereich 0:255.
> Bei einem nicht durch ID belegten Inhalt sollte es ich
> um ein Datenbyte handeln.

3. Man kann die sonst ungenutzten 6 Bits der ID auch eine Checksumme
über ID und Daten reinpacken. Das verringert die Wahrscheinlichkeit
weiter, dass man ein Nutzbyte fälschlicherweise als ID-Byte betrachtet
und sichert zusätzlich noch gegen Übertragungsfehler, gegen die Manuels
ursprüngliche Idee machtlos ist.

CRC-6 wäre vielleicht übertrieben:
<http://reveng.sourceforge.net/crc-catalogue/1-15.htm#crc.cat-bits.6>.

Übrigens: Wenn wir uns schon Sorgen über den Verlust der Synchronsation
machen, wer sagt denn, dass bei Manuels Schnittstelle nicht auch die
Synchronsation auf Bytegrenzen verloren gehen kann?

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

[toc] | [prev] | [next] | [standalone]

#221439

Am 22.01.2017 um 15:00 schrieb Christian Zietz:
> Übrigens: Wenn wir uns schon Sorgen über den Verlust der Synchronsation
> machen, wer sagt denn, dass bei Manuels Schnittstelle nicht auch die
> Synchronsation auf Bytegrenzen verloren gehen kann?

Da gibt es start- und stop-bit
http://www.elektronik-labor.de/RS232/RS232_2.htm

Oder ungerades paritybit.
Wenn das die Synchronisation nicht stimmt, gibt es bemerkbare
Übertragungsfehler.

Hermann
    der meint, 2-bit-Fahle würden
    bei parity-Verfahren nicht bemerkt.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#221445

On 01/22/2017 03:00 PM, Christian Zietz wrote:
> Übrigens: Wenn wir uns schon Sorgen über den Verlust der Synchronsation
> machen, wer sagt denn, dass bei Manuels Schnittstelle nicht auch die
> Synchronsation auf Bytegrenzen verloren gehen kann?

Wie schon an anderer Stelle angefügt: Es geht um einen 
USB2Serial-Wandler am Atmel (Standard "Arduino-Verschaltung").

Bytes werden also auf Übertragungsweg bereits einigermaßen sauber 
auseinandergehalten. Deshalb ja auch meine Idee die Bytes nochmal zu 
spalten um Adresse und Nutzdaten in je einem "Datenpaket" zu übertragen.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#221477

On 2017-01-22, Christian Zietz <newsgroup.1001@chz.xyz> wrote:
> Hermann Riemann schrieb:
>
>> 1. Mit einem timer eine Ruhepause einlegen
>> und danach wieder Sendebeginn.
>> 
>> 2. Die ID belegt nicht alle Werte im Bereich 0:255.
>> Bei einem nicht durch ID belegten Inhalt sollte es ich
>> um ein Datenbyte handeln.
>
> 3. Man kann die sonst ungenutzten 6 Bits der ID auch eine Checksumme
> über ID und Daten reinpacken. Das verringert die Wahrscheinlichkeit
> weiter, dass man ein Nutzbyte fälschlicherweise als ID-Byte betrachtet
> und sichert zusätzlich noch gegen Übertragungsfehler, gegen die Manuels
> ursprüngliche Idee machtlos ist.
>
> CRC-6 wäre vielleicht übertrieben:
><http://reveng.sourceforge.net/crc-catalogue/1-15.htm#crc.cat-bits.6>.
>
> Übrigens: Wenn wir uns schon Sorgen über den Verlust der Synchronsation
> machen, wer sagt denn, dass bei Manuels Schnittstelle nicht auch die
> Synchronsation auf Bytegrenzen verloren gehen kann?
>
> Christian

[toc] | [prev] | [next] | [standalone]

#221478

On 2017-01-22, Michael Schwingen <news-1457978346@discworld.dascon.de> wrote:

Hm - keine Ahnung, wo mein text hin verschwunden ist ...

>>> 1. Mit einem timer eine Ruhepause einlegen
>>> und danach wieder Sendebeginn.

Auf Multitasking-PC mit FIFO-Uart (gar per USB) u.U. schwierig umzusetzen.

>>> 2. Die ID belegt nicht alle Werte im Bereich 0:255.
>>> Bei einem nicht durch ID belegten Inhalt sollte es ich
>>> um ein Datenbyte handeln.

Das ist aber nur gut geraten und nicht wirklich sicher.

>> Übrigens: Wenn wir uns schon Sorgen über den Verlust der Synchronsation
>> machen, wer sagt denn, dass bei Manuels Schnittstelle nicht auch die
>> Synchronsation auf Bytegrenzen verloren gehen kann?

Was meinst Du mit "Synchronsation auf Bytegrenzen"?

Bytes konnen verlorengehen oder verfälscht werden. Mit beidem sollte ein
gutes Protokoll klarkommen.  Ob man verfälschte Daten erkennen und
aussortieren muss, hängt von der Auswirkung ab - neu aufsynchronisieren muß
aber auf jeden Fall gehen.

Wenn man eh 2 Bytes übertragen muss, ist das auch kein Problem - Beispiel:

Byte 0: 1iixxxxd
Byte 1: 0ddddddd

ii = ID, dddddddd = Daten.

Wenn nötig kann man in xxxx CRC, Parity oder sonstwas unterbringen.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#221475

On 2017-01-22, Hermann Riemann <nospam.gerct08@hermann-riemann.de> wrote:
>> Synchronisation. Wenn Du bei Deinem Verfahren einmal ein Byte verlierst,
>> hast Du keine Chance mehr, zu erkennen, was ID und was Daten sind.
>
> 1. Mit einem timer eine Ruhepause einlegen
> und danach wieder Sendebeginn.

Das ist auf einem Multitasking-PC mit FIFO-UART u.U. schwierig
hinzubekommen.

> 2. Die ID belegt nicht alle Werte im Bereich 0:255.
> Bei einem nicht durch ID belegten Inhalt sollte es ich
> um ein Datenbyte handeln.

Geht. Andererseits kann man dann auch die Daten so splitten, daß man jedem
Byte eindeutig ansehen kann, ob es ID oder Daten sind, und hat nicht das
Problem, raten zu müssen.

Verfälschte Daten sind vermutlich eher selten, Synchronisationsfehler nicht
- da reicht es, das PC-Programm abzuschiessen und neu zu starten, damit
sollte das Verfahren sauber klarkommen.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#221424

"Manuel Reimer" <manuel.nulldevice@nurfuerspam.de> schrieb im Newsbeitrag 
news:o6233i$h5i$1@dont-email.me...

> Geht es eleganter/schneller?

Mit Sicherheit.
Aber bei der dürftigen Information z.B. über die
tatsächlichen Wertebereiche der Byte-Werte und
deren Wertabfole (z.B. zeitliche Erhebung) wird
man sich nicht die Mühe im Rästelratehn machen.
-- 
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

[toc] | [prev] | [next] | [standalone]

#221444

On 01/22/2017 12:20 PM, MaWin wrote:
>> Geht es eleganter/schneller?
>
> Mit Sicherheit.
> Aber bei der dürftigen Information z.B. über die
> tatsächlichen Wertebereiche der Byte-Werte und
> deren Wertabfole (z.B. zeitliche Erhebung) wird
> man sich nicht die Mühe im Rästelratehn machen.

"Arduino-Standard-Serieller-Port".

Also Byteweise über einen CH340G (USB-Serial-Wandler) zum Atmel.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#221464

"Manuel Reimer" <manuel.nulldevice@nurfuerspam.de> schrieb im Newsbeitrag 
news:o62l8n$t0j$1@dont-email.me...

> "Arduino-Standard-Serieller-Port".
> Also Byteweise über einen CH340G (USB-Serial-Wandler) zum Atmel.

Du verstehst nicht, wo das Problem liegt.
Nciht bei der seriellen Übertragung.
Sondern weill man wissen will, ob etwas eleganter geht,
muss man alle Rahmenbedingungen kennen.
Aus dem bischen, was du erzählst, kann man nicht erahnen,
was denn die sinnvollste Lösung wäre.

Allerdings nehme ich an, daß 1 Byte Kennung und 1 Byte Wert
eleganter ist als deine Lösung und nicht so unpassend, daß
es eine schlechte Lösung wäre. Nur vielleicht nicht die
eleganteste.
-- 
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

[toc] | [prev] | [next] | [standalone]

#221428

On Sun, 22 Jan 2017 11:57:25 +0100, Manuel Reimer wrote:
> ich brauche ein Protokoll um drei verschiedene Werte zu übertragen.
>
> Jeder Wert hat die Länge von einem Byte. Die volle Länge des Bytes wird 
> genutzt. Ich habe also keine "Magic-Values" die ich zum Synchronisieren 
> verwenden könnte.
>
> Die Werte kommen nicht immer in der selben Reihenfolge.
>
> Es kommt auf Geschwindigkeit an. Es handelt sich um einen Datenstrom der 
> mit möglichst geringem Delay vom PC zum Arduino soll. Ich habe also 
> keinen Platz die Werte erst aufwendig in ein XML oder wasauchimmer zu 
> basteln.

Was ist daran so wahnsinnig kritisch?

> Ich splitte ein Byte auf 2*4 Bit:
>
> 8765 4321
>   ^    ^
>  |    '- Nutzdaten
>   '------ Adresse
>
> Ich brauche also für jedes Byte zwei Bytes und zwei Adressen, kann die 
> Werte aber in beliebiger Reihenfolge vom PC zum Arduino senden. Am 
> Arduino müsste ich dann den ersten Teil des Bytes cachen und erst wenn 
> der zweite Teil kommt kann kombiniert und verarbeitet werden.

Warum so kompliziert?

> Geht es eleganter/schneller?

1 Startbit, zwei Adressbits, ein Byte reicht für drei verschiedene Werte
mit je einem Byte Dateninhalt.

Enden kann das ganze mit Prüfbit (Parity) und evtl. Stopbit oder ganz
ohne.

Das sind Standard-Prozeduren, die so ziemlich jedes Modem-Protokoll
schon beherrscht. 

Schönen Gruß
Martin

[toc] | [prev] | [next] | [standalone]

#221430

Am 22.01.2017 um 11:57 schrieb Manuel Reimer:

> ich brauche ein Protokoll um drei verschiedene Werte zu übertragen.

> Jeder Wert hat die Länge von einem Byte. Die volle Länge des Bytes wird
> genutzt. Ich habe also keine "Magic-Values" die ich zum Synchronisieren
> verwenden könnte.

Ich würde es so machen.
Die drei byte puffern und übertragen.
dann mit einem byte mit dem Wert 0x0F starten
und mit xor jedes nibble draufrechnen. (parity)
Dieses 4. byte Übertragen und im Ziel kontrollrechnen.
( Dort die gleiche Rechnung und mit dem 4. byte dann vergleichen.)

Mir die Fehlerrate merken.
Ist sie sehr klein, kann man das mit mehr bytes machen oder es lassen.
Soweit ich mich erinnere, wird, je nach Einstellung,
  beim serieller Übertragung ohnehin bei jedem Byte ein serielles
parity Bit und hinzugefügt.

Wenn bei den 3 byte ein unvollständiger Adressbereich dabei ist,
kann man den fehlenden Adressbereich zweckentfremden.
Z.B.u.a. für Synchronisation.

> Die Werte kommen nicht immer in der selben Reihenfolge.

Das müssen Sender und Empfänger ohnehin wissen.

> Geht es eleganter/schneller?

Die meiste Zeit wird sehr wahrscheinlich bei der Übertragung verwenden.
(ca Bitrate /10)
Da sind 4 byte Übertragung, dafür mehr Berechnung schneller.

Bisher habe ich noch keinen Arduino im Betrieb gehabt.
Zwischen 2 Atari STs habe ich über die MIDI-Schnittstelle
über BIOS Aufrufe mal Daten Übertragen.

Beim Arduino gibt es Serial*.read() und Serial*.write(byte);
wobei * nichts 1,2, oder 3 ist (1 2 3 bei Arduino2560 ..)
wobei * als nichts auch zusätzlich über USB geht.

Was mir noch fehlt ist das (Linux) PC (und raspberry pi)
wenn ich ohne sketch
(auch 2 oder mehr Arduinos an USB hängen habe)
und sie von meinen eigenen C oder Python3 Programme
(ohne sudo..) auf gleiche Art aufrufen will.
Ich vermute es geht über /dev/tty*

Hermann
    der die Kombination raspberry pi aktiver USB-Hub
    Magnetplatte, Arduino z.B. für zweckmäßig hält
    um häufig sich ändernde Messwerte zu speichern,
    zumal sonst die maximale Überschreibzahl von
    EEPROM und SD-Karte erreicht werden könnte.
    Und er leicht erreichbares Ferro-RAM vermisst.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#221434

Manuel Reimer <manuel.nulldevice@nurfuerspam.de> wrote:
> Ich brauche also für jedes Byte zwei Bytes und zwei Adressen, kann die 
> Werte aber in beliebiger Reihenfolge vom PC zum Arduino senden. Am 
> Arduino müsste ich dann den ersten Teil des Bytes cachen und erst wenn 
> der zweite Teil kommt kann kombiniert und verarbeitet werden.
> 
> Geht es eleganter/schneller?

Verwende Firmata. 

https://github.com/firmata/protocol

https://www.arduino.cc/en/Reference/Firmata

Das Protokoll ist IIRC sehr ähnlich zu MIDI, und das war als Musikprotokoll
echtzeitoptimiert.

/ralph -- ja, ich hab mir auch mal ein Protokoll für sowas ausgedacht, 
          aber ich denke wenn irgendwie geht, sollte man Firmata verwenden.

[toc] | [prev] | [next] | [standalone]

#221441

Am 22.01.2017 um 12:32 schrieb Ralph Aichinger:

> Verwende Firmata.

> https://github.com/firmata/protocol

Da steht:
commands bytes are 8 bits and data bytes are 7 bits

Sowas werde ich mir vermutlich nicht antun.

Momentan neige ich zu Nachrichten variabler Länge.
das 1. byte enthält 1+Länge des  Paketes.

Der Empfänger entscheidet sich anhand des 1.bytes
(sofern vorhanden) wie damit umgehen.  Beispiele
- ignorieren. (vereinzelte Synchronisation oder Hallo noch da? byte.
- ein lokaler Befehl (pseudocode)
- Alarmreaktion(en) wegen Ungültigkeit
  (Sicherheitschecks,  Chaos Schutzschirm)
- um den Anfang verkürzten Bereich weiterleiten (I2C, anderer port ..)

Hermann
    der sich nahezu täglich über fremde software ärgert.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#221447

On 01/22/2017 12:32 PM, Ralph Aichinger wrote:
>> Ich brauche also für jedes Byte zwei Bytes und zwei Adressen, kann die
>> Werte aber in beliebiger Reihenfolge vom PC zum Arduino senden. Am
>> Arduino müsste ich dann den ersten Teil des Bytes cachen und erst wenn
>> der zweite Teil kommt kann kombiniert und verarbeitet werden.
>>
>> Geht es eleganter/schneller?
>
> Verwende Firmata.
>
> https://github.com/firmata/protocol

Schaue ich auf jedem Fall mal an. Danke für den Tipp.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#221443

Am 22.01.2017 um 11:57 schrieb Manuel Reimer:
> Hallo,
> 
> ich brauche ein Protokoll um drei verschiedene Werte zu übertragen.
> 
> Jeder Wert hat die Länge von einem Byte. Die volle Länge des Bytes wird
> genutzt. Ich habe also keine "Magic-Values" die ich zum Synchronisieren
> verwenden könnte.
> 
> Die Werte kommen nicht immer in der selben Reihenfolge.
> 
> Es kommt auf Geschwindigkeit an. Es handelt sich um einen Datenstrom der
> mit möglichst geringem Delay vom PC zum Arduino soll. Ich habe also
> keinen Platz die Werte erst aufwendig in ein XML oder wasauchimmer zu
> basteln.

Die einfachste Möglichkeit bestünde darin, ein Byte einfach in zwei
ASCII-Zeichen zu verwandeln, um sie auf dem Arduino dann wieder ins
Binäre umzusetzen.

Holger

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.sci.electronics

csiph-web