Forum: Mikrocontroller und Digitale Elektronik CRC Fehlerkorrektur -> Lookuptable


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 John P. (brushlesspower)


Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

ich habe folgendes Problem:

Mit einem Arduino empfange ich mit der Softserial Daten über UART (10 
Byte)
Wie man weiß ist die Softserial leider nicht die beste, besonders bei 
115200 Baud.
Die Hardwareserial ist leider schon belegt, und der MC festgelegt 
(Atmega328P)

Die Daten sind folgende:
XX 00 00 00 00 00 00 XX XX CRC

Die X Werte sind die gesendeten Daten. die 0en sind immer gleich.
Aus meinen Test mit der Softserial ist das 1. Byte immer korrekt.
Das erste Byte nach den 0en ist meistens falsch.


Meine Idee:
Wenn die CRC falsch ist prüfe ich ob die Bytes 1 bis 6 = 0 sind.

aus 00 13 macht die Softserial immer 00 10

aus 00 55 macht die Softserial immer 00 54

So könnte man mit einer lookuptable das 7. Byte korrigieren. (und 
anschließend den CRC prüfen)



Gibt es noch andere Möglichkleiten die euch einfallen?

Das Protokoll ist leider closed source und kann nicht geändert werden. 
Daher auch 115200 Baud
Ich brauche auch nicht 100% der Daten. Wenn jeder 2 Frame nicht 
korrigiert werden kann ist das auch ok.
Ich möchte nur die Fehlerrate verringern.

: Bearbeitet durch User
von Falk B. (falk)


Bewertung
1 lesenswert
nicht lesenswert
@ John P. (brushlesspower)

>Mit einem Arduino empfange ich mit der Softserial Daten über UART (10
>Byte)

Hmm.

>Wie man weiß ist die Softserial leider nicht die beste, besonders bei
>115200 Baud.

Uff! Das ist mal SEHR sportlich!

>Die Hardwareserial ist leider schon belegt, und der MC festgelegt
>(Atmega328P)

Sowas kann man ändern oder anpassen, ggf. multiplexen.

>So könnte man mit einer lookuptable das 7. Byte korrigieren. (und
>anschließend den CRC prüfen)

Schrott! Eine CRC dient der FehlerERKENNUNG, nicht Korrektur!

>Gibt es noch andere Möglichkleiten die euch einfallen?

Mach es gleich richtig! Entweder mit deutlich kleinerer Baudrate 
empfangen oder einen Hardware-UART nutzen. Es gibt auch Arduinos mit 
mehreren UARTS, z.B. den MEGA.

>Das Protokoll ist leider closed source und kann nicht geändert werden.
>Daher auch 115200 Baud
>Ich brauche auch nicht 100% der Daten. Wenn jeder 2 Frame nicht
>korrigiert werden kann ist das auch ok.

Schrott!

>Ich möchte nur die Fehlerrate verringern.

Die schnellste und preiswerteste Art, etwas zu tun, ist es gleich 
richtig zu machen.

von John P. (brushlesspower)


Bewertung
-1 lesenswert
nicht lesenswert
Falk B. schrieb:
> Schrott! Eine CRC dient der FehlerERKENNUNG, nicht Korrektur!

Richtig, dadurch weiß ich ja das bei der Übertragung was schief gegangen 
ist.
Erst dann möchte ich meine Daten ja korrigieren.
Wenn nach der korrektur die CRC wieder stimmt ist alles gut. Wenn nicht 
warte ich halt auf den nächsten frame.

Und ich gebe dir Recht das man das alles eleganter lösen kann. In dem 
falle aber nicht.

Besonders weil eben nicht alle Daten benötigt werden.

: Bearbeitet durch User
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Man kann durchaus auch aus Schrott noch was Schoenes basteln. Und wenn 
man auf einer einsamen Insel gestrandet ist, muss man halt nehmen was da 
ist.

So von der rein informationsuebertragungtechnischen Seite her kann man 
natuerlich auch CRC zur Fehlerkorrektur hernehmen. Ob Fehlerkorrktur 
moeglich ist oder nicht, ist nur eine Frage der Mindesthammingdistanz, 
nicht des Algorithmus.
Das CRC in der Praxis nicht zur Korrektur hergenommen wird, hat aber 
auch Gruende. Es gibt da anscheinend keinen "schoenen" Algorithmus, um 
die Position des/der Fehler anzuzeigen.
In diesem speziellen Fall, und wenn man auch noch bestimmte Annahmen 
ueber auftretende Fehler treffen kann, koennt' es durchaus sein, dass 
man da mittels Lookuptable ein gutes Stueck weiterkommt.
Natuerlich ist's herumdoktoren an den Symtomen, klar. Aber bevor man 
garnix macht...
Es sollte aber auch klar sein, dass so eine Fehlerkorrektur, wenn mehr 
Fehler drinnen waren, immer auch klammheimlich schief gehen kann. D.h. 
dann kommen durch die Korrektur evtl. noch mehr Fehler in die Nachricht, 
also korrekte Bits werden gedreht. Und keiner merkts.

Gruss
WK

von John P. (brushlesspower)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Es sollte aber auch klar sein, dass so eine Fehlerkorrektur, wenn mehr
> Fehler drinnen waren, immer auch klammheimlich schief gehen kann.

Das ist klar. Daher würde ich auch nur ein Byte korrigieren. Wenns das 
nicht war, wird der Frame ignoriert.



Aus meinen Testübertragungen konnte ich folgende erkenntnisse erlangen.

Der Fehler tritt nur bei einem vorherigen 0 Byte auf
Der Fehler tritt nur bei den letzten 4 Bit auf
X1 wird zu X0 +1
X3 wird zu X0
X7 wird zu X0
XF wird zu X0
X5 wird zu X4 +1
X9 wird zu X8 +1
XB wird zu X8
XD wird zu XC +1

Das bedeutet für mich:
Wenn ich das Fehlerhafte Byte (7.Byte) um eins hochrechne (bzw bit 0 
invertiere) habe ich eine 50% chance das es korrekt ist.

wenn das 6. und das 7. Byte 0 sind kann ich den Frame nicht retten
dann kann das 7. byte falsch sein (1,3,7 oder F)
oder das 7. Byte ist wirklich 0 und das 8. Byte müsste korrigiert 
werden.
Dann ist es aber auch schon fast aussichtslos, zumindest wenns schnell 
gehen soll

: Bearbeitet durch User
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

John P. schrieb:
> Das ist klar. Daher würde ich auch nur ein Byte korrigieren. Wenns das
> nicht war, wird der Frame ignoriert.

Du weisst dann nicht sicher, ob's das nicht war.

Wenn's meine Baustelle waere, wuerd' ich schon auch eher gucken, dass 
ich den Soft-UART irgendwie besser in den Griff kriege.
Aber so vom nachrichtentechnischen Standpunkt her ist so ne 
Fehlerkorrektur auf Nachrichten, die ja in sich anscheinend noch viel 
Redundanz tragen schon eine interessante Sache.

Gruss
WK

von John P. (brushlesspower)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Du weisst dann nicht sicher, ob's das nicht war.

Richtig, aber ich weiß dann sicher das ich die Finger von dem Frame 
lassen sollte.

Dergute W. schrieb:
> Wenn's meine Baustelle waere, wuerd' ich schon auch eher gucken, dass
> ich den Soft-UART irgendwie besser in den Griff kriege.

Ich hoffe noch auf den 20Mhz Takt.


Hatte erst mit dem 8Mhz Arduino angefangen. Da ging gar nichts mit 
115200 Baud.
Dann habe ich den 16Mhz Arduino genommen. Damit sieht das schon ganz gut 
aus. Vorallem die widerholgenauigkeit passt.

Die kommende Hardware bekommt dann einen 20Mhz Takt spendiert. Dann 
läuft die Softserial eventuell noch besser. Aber die Fehlerkorrektur 
bleibt ein Backup.

Ich werde noch den Arduino die 10 Bytes von der Hardwareserial zur 
Softserial senden lassen.
Dabei die Bytes jedesmal hochzählen und prüfen wie viele Fehler 
aufgetreten sind, wie viele korrigiert wurden, und wieviele frames 
verloren sind.

Dann habe ich mal einen Überblick über die Fehlerquote.


Die Daten enthalten die Drehzahl eines Brushlessmotors. Diese soll auf 
SD Karte geloggt werden und per Telemetrie an die Fernbedinung gesendet 
werden. Deswegen ist die Hardwareserial belegt. Die Telemetrie 
unterliegt kritischeren Timings.
Und wenn ich die drehzahl mal für 100ms nicht aktualisiere ist das kein 
Beinbruch.

: Bearbeitet durch User
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

John P. schrieb:
> Und wenn ich die drehzahl mal für 100ms nicht aktualisiere ist das kein
> Beinbruch.

Ja, aber wenn du die falsche Drehzahl meldest, bricht sich dann 
immernoch keiner ein Bein?

Ich hab' keine Ahnung vom Arduino und seinem Soft-UART. Muesste ich 
sowas bauen, wuerde ich halt gucken, dass ich das mit einer Kombi aus 
Pin-change-IRQ und nem Timer gebacken krieg. Dann sollte die 
CPU-Taktfrequenz wurscht sein, wenn nicht andauernd von anderen Teilen 
der SW die Interrupts abgeschaltet werden.

Gruss
WK

von John P. (brushlesspower)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Ja, aber wenn du die falsche Drehzahl meldest, bricht sich dann
> immernoch keiner ein Bein?

Dann müssten aber die falschen Daten die richtige CRC ergeben?
Unwarscheinlich.

Und wenn doch bricht sich trotzdem niemand ein Bein. ;)

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
John P. schrieb:
> Das bedeutet für mich:
> Wenn ich das Fehlerhafte Byte (7.Byte) um eins hochrechne (bzw bit 0
> invertiere) habe ich eine 50% chance das es korrekt ist.

 Und das bedeutet für mich, dass dein Softwareserial zu schnell ist.

 Versuche es mal mit 115000 oder weniger.

von TSchl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
bist du dir wirklich sicher das die Baudrate innerhab der Spec liegt? 
kommt mir so vor als hättest du keine 115kBaud

von John P. (brushlesspower)


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Und das bedeutet für mich, dass dein Softwareserial zu schnell ist.
>
>  Versuche es mal mit 115000 oder weniger.

das dachte ich auch.

bei 115000 Baud stellt sich keine besserung ein.
bei weniger als 115000 Baud werden die Daten nur noch schlimmer.



TSchl schrieb:
> bist du dir wirklich sicher das die Baudrate innerhab der Spec liegt?
> kommt mir so vor als hättest du keine 115kBaud

Jup, das oszi bestätigt das. Zumindest das was gesendet wird.
Was die softserial daraus macht, und wie "richtig" die läuft weiß ich 
nicht.

: Bearbeitet durch User
von Thomas S. (thschl)


Bewertung
0 lesenswert
nicht lesenswert
Paritiy Einstellung stimmt auch? Ich arbeite viel mit seriellen 
Schnittstellen.. irgendwie scheint es aber an sowas zu liegen. Die Oszi 
Einstellungen sind wirklich ok? ich nutze gerne den saleae Logiganalyser 
für sowas

von John P. (brushlesspower)


Bewertung
0 lesenswert
nicht lesenswert
Von den Einstellungen ist alles OK.

Es ist eine ganz normale 8N1 Übertragung.

Bei 57600 Baud habe ich auch absolut keine Fehler.
Erst mit 115200 Baud.


getestet habe ich die normale arduino "softwareserial" und die 
alternative "altsoftserial"

Die Fehlerkorrektur funktioniert zwar, aber eher schlecht als recht.

von 255 frames
kommen etwa 80 korrekt an.
etwa 20 werden erfolgreich korrigiert.


Das Problem ist, das immer die selben Frames Fehler verursachen (weil 
mehr als ein fehler vorhanden ist).

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dann nimm 57600. Mit dem ganzen Fehlerkorrektur-Quark und retransmit 
hast Du unterm Strich auch keine höhere Datenrate.

von John P. (brushlesspower)


Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Dann nimm 57600. Mit dem ganzen Fehlerkorrektur-Quark und retransmit
> hast Du unterm Strich auch keine höhere Datenrate.

Jo, das ich da noch nicht früher drauf gekommen bin.
Die Ausgabe erfolgt nunmal mit 115200Baud. Daran kann ich nichts ändern

von Kaj (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Dann nimm 57600.

Wer lesen kann und so...

John P. schrieb:
> Das Protokoll ist leider closed source und kann nicht geändert werden.
> Daher auch 115200 Baud

von Rainer V. (a_zip)


Bewertung
0 lesenswert
nicht lesenswert
John P. schrieb:
> von 255 frames
> kommen etwa 80 korrekt an.
> etwa 20 werden erfolgreich korrigiert.

Hallo, vielleicht ist es eine Option, ein Frame mehrfach zu senden und 
im Empfänger zu vergleichen. Wenn du eh nur 80 von 250 Frames richtig 
bekommst, kannst du das Frame doch auch 3x senden. Vielleicht wird die 
Übertragung dann sicherer. In den Anfängen der digitalen 
Modellbahnsteuerung wurde das so gemacht. Der Empfänger mußte bis zu 4 
gleiche Frames empfangen, um sich angesprochen zu fühlen. Wenn du also 
nicht mit der Baudrate runter kannst, dann geht es vielleicht so! Es 
wundert mich allerdings, dass mit 57600 Baud alles problemlos gehen 
soll. Wahrscheinlich wirst du dich doch ein wenig um arduino 
"softwareserial" kümmern müssen! Kenne mich damit aber leider nicht aus, 
so dass ich dir auch keinen konkreten Tip geben kann...
Viel Erfolg und Gruß, Rainer

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
John P. schrieb:
> Jup, das oszi bestätigt das. Zumindest das was gesendet wird.
> Was die softserial daraus macht, und wie "richtig" die läuft weiß ich
> nicht.

 Ich rate mal:
 Die Software Routine beim Arduino ist Sch...e.

 Wenn der uC Stoppbit (Log. 1) nicht richtig erkant hat, gibt es einen
 Frame Error.
 Danach braucht es einen Startbit (Log. 0), ansonsten startet der
 Empfang nicht.
 Es muss aber nach dem Startbit eine Log. 1 als bit 0 kommen, ansonsten
 würdest du keinen Wert+1 kriegen.
 Eine Log. 1 gibt es aber beim Wert 0 nicht, ausser beim Stoppbit.

John P. schrieb:
> Bei 57600 Baud habe ich auch absolut keine Fehler.
> Erst mit 115200 Baud.
 Ergo, die Software Library schafft es nur bis 57600 Baud.

 Mein Rat:
 Hardware USART benutzen oder, wenn es nicht geht, selber eine Routine
 in Assembler schreiben (muss aber blockierend sein).

: Bearbeitet durch User
von Dieter M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe jetzt nicht alles gelesen,
werfe aber einfach mal den ATMEGA328pB in den Raum.
Kompatibel und hat 2 UARTs.

von georg (Gast)


Bewertung
1 lesenswert
nicht lesenswert
John P. schrieb:
> Bei 57600 Baud habe ich auch absolut keine Fehler.
> Erst mit 115200 Baud.

Wundert dich das? Asynchron funktioniert mit höherer Abtastrate, 
üblicherweise 8 x oder eher 16 x Baudrate. Daher muss zum Empfang eine 
Timer-Interruptroutine mit rund 1 Mio mal pro Sekunde ausgeführt werden. 
Es gibt nur wenige Prozessoren mit denen dass in Software möglich ist.

Wenns garnicht anders geht: ein geeignetes Prozessörchen 
dazwischenschalten, das 115 kBaud empfängt und mit (höchstens) 57 kBaud 
weitergibt.

Georg

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von John P. (brushlesspower)


Bewertung
0 lesenswert
nicht lesenswert
Also,

mit der original Arduino Softwareserial läuft es besser als mit der 
alternative.

Bei 113950 Baud habe ich aktuelle eine Fehlerrate von 50% ohne 
korrektur.
Die Fehler liegen in einzelnen geflippten Bits.


Fazit:
original Softwareserial ist nicht so schlecht wie es im Netz immer 
behauptet wird.
Aber sie ist natürlich viel schwächer als die Hardwareserial, klar!


Für mich reichen diese 50% erstmal völlig aus.
Eventuell werden die 20Mhz noch etwas mehr performance bringen.


Dieter M. schrieb:
> Hallo,
> ich habe jetzt nicht alles gelesen,
> werfe aber einfach mal den ATMEGA328pB in den Raum.
> Kompatibel und hat 2 UARTs.

sind die Register 1 zu 1 kompatibel?
besonders für die UART1 und die ganzen Timer?
dann wäre das vielleicht einen versuch wert.

georg schrieb:
> Wenns garnicht anders geht: ein geeignetes Prozessörchen
> dazwischenschalten, das 115 kBaud empfängt und mit (höchstens) 57 kBaud
> weitergibt.

Die idee hatte ich auch schon^^
Das wäre dann aber Mikrocontroller nummer 3 auf der Platine.
Erstens finde ich das etwas übertrieben.
Und 2. geht mir der Platz aus.

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich denke auch, dass die Ursache des Problems in dem Overhead des 
Arduino-Frameworks liegt, in der Implementierung des Software-UART, in 
der sonst durch die Anwendung erzeugten Last oder in einer Kombination 
dieser Faktoren.

Falls der TO auf die Vorzüge des Arduino-Frameworks angewiesen ist, 
würde ich 1. eine Loop schreiben, die nur das empfangene auswertet, die 
CRC berechnet und entsprechend signalisiert ob Fehler vorliegen. Falls 
nicht, dann wird vermutlich die zusätzliche Last durch die Anwendung das 
Problem sein. 2. (alternativ oder in Folge von 1.) einen grösseren AVR 
mit wenigstens zwei UARTs nehmen auf dem Arduino läuft (falls es das 
gibt).

Die Empfehlung von Arduino ganz abzurücken, mag auch sinnvoll sein. 
Erfordert dann aber nochmal einen gewissen Lernprozess.

In jedem Fall scheint mir der alte Rat angebracht, die Ursache zu 
bekämpfen und nicht das Symptom.

Dazu wäre es vielleicht nützlich zuerst einmal auf dem Oszilloskop 
mehrere  ganze Telegramme anzuschauen und zu verifizieren. Timing und 
Timing-Stabilität. Und eben Daten im Zusammenhang mit dem CRC.

Angaben über die Datenquelle wären für eine Hilfestellung u.U. auch 
nützlich.

von John P. (brushlesspower)


Bewertung
0 lesenswert
nicht lesenswert
Theor schrieb:
> Angaben über die Datenquelle wären für eine Hilfestellung u.U. auch
> nützlich.

Die Datenquelle ist ein STM32F051 mit der closed source Firmware 
"BlHeli_32" für die Motorreglung.

Das Telemetrieprotokoll besagt:

One transmission will have 10 8-bit bytes sent with 115200 baud and 
3.6V.
Byte 0: Temperature
Byte 1: Voltage high byte
Byte 2: Voltage low byte
Byte 3: Current high byte
Byte 4: Current low byte
Byte 5: Consumption high byte
Byte 6: Consumption low byte
Byte 7: Rpm high byte
Byte 8: Rpm low byte
Byte 9: 8-bit CRC

google: KISS ESC 32-bit series onewire telemetry protocol



Der Grund warum ich Arduino (328p) verwenden möchte:
Alle Telemetrieprotokolle für Jeti, Futaba, Hott, FRSky usw sind in 
Arduino bzw für den 328p verfügbar.
Besonders beim Futaba Protokoll ist die Arduino Lib direkt in den 
Registern programmiert (ohne Arduino Framework).

https://github.com/BrushlessPower/SBUS2-Telemetry

D.h. wenn ich auf einen anderen MC umsteige funktioniert eine oder 
mehrere Telemetriefunktionen nicht mehr. Dann fange ich mehr oder 
weniger bei 0 an.
Und das "nur" wegen der RPM information aus dem STM32

: Bearbeitet durch User
von John P. (brushlesspower)


Bewertung
0 lesenswert
nicht lesenswert
Abschließend:


114000 Baud
Fehlerkorrektur der 0 Bytes

auf 255 Frames
140 Korrekt übertragen
32  Korrigiert

172/255 = 67% -> Das ist erstmal ausreichend. Mehr lässt sich über die 
Softserial nicht herausholen

von Patrick B. (p51d)


Bewertung
1 lesenswert
nicht lesenswert
John P. schrieb:
> D.h. wenn ich auf einen anderen MC umsteige funktioniert eine oder
> mehrere Telemetriefunktionen nicht mehr. Dann fange ich mehr oder
> weniger bei 0 an.

Ja und? Anscheinend bist du sowieso an einer neuen Hardware am 
beschaffen (mit 20MHz). Wieso dann nicht gleich einen anderen 
Controller? Das PCB wird wohl nicht sehr aufwendig sein und Code kann 
man wiederverwenden.

Ich würde mir den Mehraufwand gönnen, wenn ich etwas robustes und 
zukunftsorientiertes bekomme. Wieso jetzt schon auf 99% "Auslastung" 
gehen, wenn man bei einem Privatprojekt mit Stückzahl 1 ohne Probleme 
etwas Klotzen kann und nicht Kleckern muss.

von Falk B. (falk)


Bewertung
1 lesenswert
nicht lesenswert
@ John P. (brushlesspower)

>Die Ausgabe erfolgt nunmal mit 115200Baud. Daran kann ich nichts ändern

Schon klar, aber was hängt am Hardware-UART? Vielleicht kannst du deinen 
anderen UART gegen den Soft-UART tauschen und den Soft-UART dann 
deutlich langsamer laufen lassen, weil du dort flexibel bist?

von c-hater (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
georg schrieb:

> Wundert dich das? Asynchron funktioniert mit höherer Abtastrate,
> üblicherweise 8 x oder eher 16 x Baudrate. Daher muss zum Empfang eine
> Timer-Interruptroutine mit rund 1 Mio mal pro Sekunde ausgeführt werden.
> Es gibt nur wenige Prozessoren mit denen dass in Software möglich ist.

Die AVR8 gehören durchaus zu der Riege von MCUs, mit denen das möglich 
ist. Allerdings natürlich nur unter gewissen Randbedingungen, die man 
nur garantieren kann, wenn man in Assembler programmiert.

Mit C/C++ kann man diese zwar (mühsam) ebenfalls erreichen, aber nicht 
garantieren bzw. höchstens für einen ganz bestimten Compiler in einer 
ganz bestimmten Version mit ganz bestimmten Compilerflags.

Asm rules.

von it's me (Gast)


Bewertung
0 lesenswert
nicht lesenswert
John P. schrieb:
> Der Fehler tritt nur bei einem vorherigen 0 Byte auf

Dann sorge dafür, dass Byte 6 kein "0 Byte" ist.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Kannst du wirklich nicht auf den ATmega328PB ausweichen? Der hätte 2 
serielle Schnittstellen.

Wenn du niemals von beiden Geräten gleichzeitig empfangen musst, kannst 
du sie vielleicht beide über dein einzigen "echten" RxD Kanal laufen 
lassen:
1
                         2,2kΩ
2
Gerät 1 Tx o---|<|---+---[===]---o
3
                     |
4
Gerät 2 Tx o---|<|---+-----o AVR Rx

: Bearbeitet durch User
von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
John P. schrieb:
> X1 wird zu X0 +1

Was meinst Du damit?

von X4U (Gast)


Bewertung
1 lesenswert
nicht lesenswert
John P. schrieb:
> 114000 Baud
> Fehlerkorrektur der 0 Bytes
>
> auf 255 Frames
> 140 Korrekt übertragen
> 32  Korrigiert
>
> 172/255 = 67% -> Das ist erstmal ausreichend. Mehr lässt sich über die
> Softserial nicht herausholen

Kann sein, bei mir läuft es mit 115 k immer ohne Probleme, ist aber auch 
kein Arduino. Kommt dir vielleicht ein Interrupt in die quere?

Sende mal 0xAA (oder war es  0x55? ) dauernd und messe mit dem oszi die 
Pulsweite. Wenn ich mich recht erinnere ist der Kehrwert gleich der 
Baudrate.

von Alex G. (dragongamer)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
>
> Mit C/C++ kann man diese zwar (mühsam) ebenfalls erreichen, aber *nicht*
> garantieren bzw. höchstens für einen ganz bestimten Compiler in einer
> ganz bestimmten Version mit ganz bestimmten Compilerflags.
>
> Asm rules.
Ja super. Das ASM Programm läuft dafür ausschlieslich auf dem einen 
Chip. Wiederverwendbarkeit des Ganzen praktisch Null.
Das soll ein Vorteil sein?

Wie auch immer, denke nicht dass der TE überhaupt einen Uart neu 
entwickeln will/wird.

von zyxw (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stimmt meine Vermutung?
Hardware-Serial = BLDC-Controller
Software-Serial = Telemetrie?
Brauchst Du für Telemetrie auch die Rx-Richtung?
Solche Angaben bitte immer gleich im ersten Post bekanntgeben.

1. Hast Du schon mal probiert, die Telemetrie über softserial zu senden 
und die Hardware für den BLDC?
Die Senderoutine ist deutlich einfacher und weniger resourcenhungrig als 
die zum Empfangen.
Sie Posting von Georg.

2. Erhöhen der Taktfrequenz auf 20, 22 oder 24 MHz klappt in der Regel. 
Dann aber alles gut abblocken und abschirmen.

3. Mit welcher Baudrate läuft die Telemetrie?  Kannst Du nicht die 
Hardware-RX für den BLDC und die Hardware-TX für die Telemetrie 
verwenden?

4. Ist die Hardware gut? Gnd-Schleifen, sonstige Einstreuungen, Spikes 
etc?

5. Mega328PB ist auch mein Tip.

von Dergute W. (derguteweka)


Bewertung
1 lesenswert
nicht lesenswert
Moin,

Alex G. schrieb:
> Ja super. Das ASM Programm läuft dafür ausschlieslich auf dem einen
> Chip. Wiederverwendbarkeit des Ganzen praktisch Null.
> Das soll ein Vorteil sein?

Ich denke mal eher, der Vorteil waere, dass die Shice funktioniert. Und 
dass man dann "unportable" Software hat, ist der Preis, den man dafuer 
zahlt, dass man unzulaengliche Hardware hat. Es hat ja einen Grund, 
warum man UARTs haeufig aus Flipflops und Gattern baut und selten 
programmiert.

Gruss
WK

von avr (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lass c hater doch mit seinem c bashing. Es ist ohne Probleme möglich 
eine serielle Schnittstelle in C zu implementieren, die fehlerfrei mit 
115200kbaud läuft. Dafür braucht man aber zwingend interruptprioritäten, 
bzw muss diese nachbilden indem im interrupt gleich sei() aufgerufen 
wird. Bedeutet bei Nutzung des Arduino Frameworks Änderungen am Kern, 
weil immer ein timerinterrupt im Hintergrund läuft.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
John P. schrieb:
> Softserial [...] 115200 Baud

avr schrieb:
> dafür braucht man aber zwingend interruptprioritäten

.. die ein AVR Dir aber nich in Hardware bietet, und die in Software 
sehr fehlerträchtig sind - insbesondere wenn man nachträglich sei 
Instruktionen einbaut.

Du darfst bei so hoher Baudrate praktisch keine weiteren Interrupts mehr 
nebenher fahren, denn dafür bleibt kaum Zeit übrig. Das gilt auch für 
die Arduino Libs, die z.B. Timer Interrupts benutzen.

von avr (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> und die in Software sehr fehlerträchtig sind

Wie sollen die fehlerträchtig sein? Damit markierst du quasi interrupts 
die unterbrochen werden dürfen. Dass interrupts mehrfach aufgerufen 
werden muss man natürlich verhindern.

Jim M. schrieb:
> Du darfst bei so hoher Baudrate praktisch keine weiteren Interrupts mehr
> nebenher fahren, denn dafür bleibt kaum Zeit übrig. Das gilt auch für
> die Arduino Libs, die z.B. Timer Interrupts benutzen.

Mit Software Prioritäten ist das trotzdem machbar auch wenn es nicht 
einfacher wird. Man hat bei 115200kbaud und 16Mhz über 100 Takte pro 
Symbol. Das reicht selbst in C locker. Wenn weitere und vor allem 
längere interrupts vorhanden sind, müssen diese in den serial handlern 
temporär deaktiviert werden.
Und klar ist: ohne Kontrolle der Arduino libs kann man das ganze 
vergessen.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
1 lesenswert
nicht lesenswert
avr schrieb:
> 115200kbaud läuft. Dafür braucht man aber zwingend interruptprioritäten,
> bzw muss diese nachbilden indem im interrupt gleich sei() aufgerufen
> wird.

 Was für ein Blödsinn.
 Die fallende Flanke von Startbit löst einen Interrupt aus, danach ist
 bis Stoppbit (mindestens Mitte) nix mit anderen Interrupts.
 Der Empfang muss ganz einfach blockierend sein, ansonsten passiert
 das, was beim TO passiert - bits werden falsch eingelesen.
 Und selbst in Software sollte man jedes bit mindestens 3 Mal
 abtasten - beim 115KB etwa nach 47Cy das erste Mal, danach noch
 2 Mal im Abstand von 22Cy.
 Verbleiben noch 47Cy beim Startbit oder 48Cy bei Stoppbit und
 bits 0 bis 7.
 Ergibt ziemlich genau 115200B (115191B) bei 16MHz.
 Natürlich müssen die 3 Samples miteinender verglichen werden und
 entschieden werden ob Log.1 oder Log.0 empfangen wurde und das
 entsprechende bit muss auch dementsprechend gesetzt werden.
 Dauert auch eine gewisse Zeit, oder?
 Nachdem Stoppbit eingelesen ist, werden entsprechende Flags gesetzt,
 das empfangene Byte wird ins Buffer reingeschrieben und erst dann
 werden weitere Interrupts wieder freigegeben (durch RETI aber).
 Natürlich wird zuerst das ev. gesetzte IntFlag für RxPin gelöscht.


> Bedeutet bei Nutzung des Arduino Frameworks Änderungen am Kern,
> weil immer ein timerinterrupt im Hintergrund läuft.

 LOL.
 Nach dem cli laufen keine Interrupts mehr im Hintergrund.

: Bearbeitet durch User
von Thomas E. (picalic)


Bewertung
-1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Und selbst in Software sollte man jedes bit mindestens 3 Mal
>  abtasten

Das ist vielleicht ein nettes Gimmick für Perfektions-Fetischisten, aber 
notwendig ist das nicht! Meine SW-UARTs laufen bislang alle immer 
fehlerfrei, und da wird nur einmal in der Mitte jedes Bitframes 
abgetatstet, d.h. das erste mal 1,5 Bitzeiten nach der fallenden Flanke 
vom Startbit, dann jeweils nach genau 1 Bitzeit. In der Pin Change ISR 
durch die fallenden Start-Flanke wird allerdings der Pin-Status nach ein 
paar µs einfach nochmal verifiziert, um einen falschen Trigger zu 
erkennen.
Wenn die Zuverlässigkeit kritisch ist, wird das durch CRC o.ä. im 
Protokoll geregelt und nicht in der Emulation der UART-Hardware.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
1 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Wenn die Zuverlässigkeit kritisch ist, wird das durch CRC o.ä. im
> Protokoll geregelt und nicht in der Emulation der UART-Hardware.
 Nein, bestimmt nicht.
 Du verwechselt Zuverlässigkeit mit Fehlererkennung.

> Marc V. schrieb:
>> Und selbst in Software sollte man jedes bit mindestens 3 Mal
>>  abtasten
>
> Das ist vielleicht ein nettes Gimmick für Perfektions-Fetischisten, aber
> notwendig ist das nicht! Meine SW-UARTs laufen bislang alle immer
> fehlerfrei, und da wird nur einmal in der Mitte jedes Bitframes

 Selbstverständlich kann das fehlerfrei laufen, fragt sich nur in
 welcher Umgebung und für wie lange. Für Eigengebrauch und Hobby mag
 das genügen.
 Es ist auch nicht notwendig, dass Hardware USART einen bit 16 Mal
 abtasten und trotzdem machen es alle so und dass, obwohl Hardware
 USART Noise Filterung haben aber der Pin für Software UART so etwas
 meistens nicht hat.

von Dergute W. (derguteweka)


Bewertung
-1 lesenswert
nicht lesenswert
Moin,

Marc V. schrieb:
> dass Hardware USART einen bit 16 Mal
>  abtasten und trotzdem machen es alle so

Haste mal fuer diese These irgendeinen "amtlichen" Beleg?

Gruss
WK

von Marc V. (Firma: Vescomp) (logarithmus)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Haste mal fuer diese These irgendeinen "amtlichen" Beleg?

 Ja, das entsprechende Datenblatt.

 P.S.
 Für alle, die das nicht finden können, Bild anbei.

: Bearbeitet durch User
von Dergute W. (derguteweka)


Bewertung
-1 lesenswert
nicht lesenswert
Moin,

Marc V. schrieb:
> Ja, das entsprechende Datenblatt.

Vielleicht einen Ticken spezieller, nicht so allgemein gehalten?
UARTs wie der 16550 haben ganz gerne einen 16 fach hoeheren Takt als 
ihre Bitrate, aber daraus wuerde ich nicht folgern

> dass Hardware USART einen bit 16 Mal
>  abtasten

Gruss
WK

von Dergute W. (derguteweka)


Bewertung
-1 lesenswert
nicht lesenswert
Moin,

Auch PS: Das auf dem Bild sieht aus wie bei der Hl. Handgranate von 
Antiochia und auch eher wie ich erwartet habe: Drei ist die Zahl auf die 
du zaehlen sollst. Und nicht 16.
:-)

Gruss
WK

von Thomas E. (picalic)


Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> fragt sich nur in
>  welcher Umgebung und für wie lange. Für Eigengebrauch und Hobby mag
>  das genügen.

Wenn sich eine professionelle Anwendung darauf verlässt, daß in einer 
evtl. störverseuchten Umgebung eine UART-Schnittstelle garantiert 
fehlerfrei funktioniert, ist das in meinen Augen ein Design-Fehler - da 
kannst Du so oft abtasten, wie Du willst.

Marc V. schrieb:
> Du verwechselt Zuverlässigkeit mit Fehlererkennung.

Für mich ist Zuverlässigkeit, wenn ich ein Paket mit Nutzdaten 
garantiert ohne Verfälschung der Daten von A nach B übertragen kann. Der 
Schüssel dazu ist eine Fehlererkennung. Eine bloße Verringerung der 
Fehlerrate durch Verbesserung des Übertragungskanals (hier durch 
Mehrfachabtastung) kann das nicht leisten. Sie verbessert nur die 
Qualität der Übertragung, macht sie aber nicht zuverlässig.
Ob man jedes 100. oder nur jedes 1000. Datenpaket ggf. nochmal 
übertragen muss, macht bei der Performance praktisch keinen Unterschied 
(99.0% zu 99.9%).

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Auch PS: Das auf dem Bild sieht aus wie bei der Hl. Handgranate von
> Antiochia und auch eher wie ich erwartet habe: Drei ist die Zahl auf die
> du zaehlen sollst. Und nicht 16.

 Wer lesen kann, ist klar im Vorteil:
 Abtasten und auswerten ist nicht das gleiche.

Thomas E. schrieb:
> Schüssel dazu ist eine Fehlererkennung. Eine bloße Verringerung der
> Fehlerrate durch Verbesserung des Übertragungskanals (hier durch
> Mehrfachabtastung) kann das nicht leisten. Sie verbessert nur die
> Qualität der Übertragung, macht sie aber nicht zuverlässig.

 CRC ist bei TO schon vorhanden, was hat das mit Fehlern bei der
 Übertragung bzw. mit Abtastung zu tun ?

 Fängt die Korinthenkackerei schon wieder an ?

von Thomas E. (picalic)


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> CRC ist bei TO schon vorhanden, was hat das mit Fehlern bei der
>  Übertragung bzw. mit Abtastung zu tun ?

Ein Grund mehr, warum er mit einer simplen Einzelabtastung in der Mitte 
der Bitframes auskommt. Fehler bei der Übertragung durch Störsignale 
o.ä. kannst Du auch durch Deine 3-fach Abtastung nicht zu 100% 
vermeiden, hast dadurch aber einen gewissen Mehraufwand beim SW-UART. Ob 
sich dieser Mehraufwand lohnt, soll jeder selbst entscheiden, ggf. auch 
anhand von verschiedenen Beiträgen in diesem Forum, wenn er hier schon 
um Rat fragt - es ist ja schließlich ein Diskussionsforum, wo Argumente 
ausgetauscht werden können. Du hast pauschal und ohne nähere Angaben 
dazu, was der zu erwartende Mehrwert ist, geschrieben: "man sollte..."
Ein unbedarfter Forenbesucher könnte von Dir den Eindruck besonderer 
Kompetenz gewinnen und würde dann Dein "man sollte..." interpretieren 
als: "wenn's ordentlich funktionieren soll, muss man..." - schließlich 
nimmt man die Ratschläge von Koryfäen doch ernst.
Und ich habe geschrieben, daß ich das eben nicht so sehe. Ich meine, man 
kann sich die Mehrfachabtastung schenken, ohne in der Praxis nennenswert 
an Funktion einzubüßen, zumindest bei nicht allzu schlechter (also eher 
"normaler") Leitungsqualität.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
1 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Ein Grund mehr, warum er mit einer simplen Einzelabtastung in der Mitte
> der Bitframes auskommt. Fehler bei der Übertragung durch Störsignale
> o.ä. kannst Du auch durch Deine 3-fach Abtastung nicht zu 100%
> vermeiden,

 Ja, sure.
 Fehler kann man zu 100% nicht mal durch 50-fache Abtastung vermeiden.
 Es muss sich nur jemand finden, der 49 Störspitzen genau in die
 Abtastintervalle plaziert.
 Die Möglichkeit dafür ist zwar ungefähr 1:10000000 aber was soll's -
 Hauptsache, es kann passieren, demnach ist es deiner Meinung nach egal
 ob man 50 Mal abtastet oder nur ein einziges Mal.
 Dass einzelne Störspitzen aber gar nicht mal so selten sind und drei-
 faches Abtasten deswegen viel sicherer ist, ist auch ohne Bedeutung.

> Ein unbedarfter Forenbesucher könnte von Dir den Eindruck besonderer
> Kompetenz gewinnen und würde dann Dein "man sollte..." interpretieren
> als: "wenn's ordentlich funktionieren soll, muss man..." - schließlich
> nimmt man die Ratschläge von Koryfäen doch ernst.

 Wenn ich muss meine, schreibe ich das auch.
 Wenn ich aber soll schreibe, hat das auch einen Grund, vor allem in
 der fehlenden Noise Filtering bei normalen GPIOs.

> o.ä. kannst Du auch durch Deine 3-fach Abtastung nicht zu 100%
> vermeiden, hast dadurch aber einen gewissen Mehraufwand beim SW-UART.

 Bei 115KB sollte die Softuart Routine blockierend sein, da bedeutet
 der "gewisse Mehraufwand" genau gar nichts - es sind auf jeden Fall
 weniger als 20 zusätzliche Bytes.
 Und ob der uC die Zeit zwischen 2 Abtastungen mit NOP oder mit
 CP vertrödelt, dürfte auch ohne Bedeutung sein.

: Bearbeitet durch User
von avr (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Marc V. schrieb:
>> Bedeutet bei Nutzung des Arduino Frameworks Änderungen am Kern,
>> weil immer ein timerinterrupt im Hintergrund läuft.
>
>  LOL.
>  Nach dem cli laufen keine Interrupts mehr im Hintergrund.

Das nützt dir gar nichts, wenn du erst viel zu spät in deinen Interrupt 
kommst, wenn andere interrupts diesen verzögert haben.

Ich redete offensichtlich von Full-Duplex UART. Half-Duplex ist trivial 
- selbst nicht blockierend. Kontrolle über alle Interrupts ist dennoch 
essentiell.

Ich bin jetzt auch raus. Um mit Marc über seine Flausen zu diskutieren 
ist mir meine Zeit zu schade.

Beitrag #5586869 wurde vom Autor gelöscht.
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
1 lesenswert
nicht lesenswert
avr schrieb:
> Ich redete offensichtlich von Full-Duplex UART.
 Mit wem ?
 Oder anders gefragt - was hat das mit der Frage, die der TO stellte
 und die sich offensichtlich auf Half-Duplex bezog, zu tun ?
 Redest du immer mit dir selbst ?


> Half-Duplex ist trivial - selbst nicht blockierend.
 Schon möglich, nur schade, dass die Leute von Arduino nicht von
 dir gehört haben, ansonsten hätten sie dich angerufen, du hättest
 dieses für dich triviales Problemchen in null Komma nichts gelöst
 und der TO hätte das ganze Problem überhaupt nicht.


> Ich bin jetzt auch raus. Um mit Marc über seine Flausen zu diskutieren
 LOL.
 Du hast nicht mit mir diskutiert, du hast ein paar Behauptungen
 aufgestellt, die nicht richtig sind.
 Eine davon ist sogar absolute Blödsinn.
 Und wenn man diese falschen Behauptungen nicht belegen kann, geht
 man raus mit der Behauptung es sind meine Flausen.
 Nö, nix meine Flausen - ganz einfach dein Unwissen.

 P.S.
 Hört sich immer gut an: Ich bin jetzt auch raus.
 Ich könnte auch sagen: Ich sehe jetzt auch, dass du Blöd bist.

 Ich tue das natürlich nicht.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Wiederverwendbarkeit des Ganzen praktisch Null.
> Das soll ein Vorteil sein?

Wiederverwendbarkeit ist nicht immer von Interesse.

von Alex G. (dragongamer)


Bewertung
-1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Alex G. schrieb:
>> Wiederverwendbarkeit des Ganzen praktisch Null.
>> Das soll ein Vorteil sein?
>
> Wiederverwendbarkeit ist nicht immer von Interesse.
Dass es nicht nur "für einen ganz bestimten Compiler in einer ganz 
bestimmten Version mit ganz bestimmten Compilerflags" geht, allerdings 
auch nicht...

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Stefanus F. schrieb:
>> Alex G. schrieb:
>>> Wiederverwendbarkeit des Ganzen praktisch Null.
>>> Das soll ein Vorteil sein?
>>
>> Wiederverwendbarkeit ist nicht immer von Interesse.
> Dass es nicht nur "für einen ganz bestimten Compiler in einer ganz
> bestimmten Version mit ganz bestimmten Compilerflags" geht, allerdings
> auch nicht...

 Da es sich um Software UART handelt, werden GPIOs verwendet und
 diese können in Assembler mit .def und .equ dem jeweiligen Typ
 angepasst werden.

 Und das muss in C genauso festgelegt werden, selbstverständlich
 kann z.B. bei M328 kein PORTA oder PORTE ausgewählt werden.
 Wo soll da ein Problem sein?

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Wer lesen kann, ist klar im Vorteil:
>  Abtasten und auswerten ist nicht das gleiche.

Du hast Abtasten in dem Kontext verwendet, dass dies (bis zu) 16-fach 
pro Bit geschieht.
Marc V. schrieb:
> Es ist auch nicht notwendig, dass Hardware USART einen bit 16 Mal
>  abtasten und trotzdem machen es alle so

Wenn Du jetzt darauf ansetzt, dass davon nur 3 Samples ausgewertet 
werden, dann hast Du anscheinend die Aufgabe des 16-fachen Taktes nicht 
verstanden. Der ist aber jedem klar, der schon Mal intensiver mit Uarts 
gearbeitet hat. Von daher, entschuldige die Verwirrung.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Wenn Du jetzt darauf ansetzt, dass davon nur 3 Samples ausgewertet
> werden, dann hast Du anscheinend die Aufgabe des 16-fachen Taktes nicht
> verstanden. Der ist aber jedem klar, der schon Mal intensiver mit Uarts
> gearbeitet hat. Von daher, entschuldige die Verwirrung.
 Nein, anscheinend hast du es nicht ganz verstanden.

Was genau verwirrt dich, vielleicht kann man dir noch irgendwie helfen?

von John P. (brushlesspower)


Bewertung
-1 lesenswert
nicht lesenswert
Falk B. schrieb:
> Schon klar, aber was hängt am Hardware-UART? Vielleicht kannst du deinen
> anderen UART gegen den Soft-UART tauschen und den Soft-UART dann
> deutlich langsamer laufen lassen, weil du dort flexibel bist?

Hallo Falk,

Leider läuft der Hardware Uart ebenfalls mit 115kBaud. das gibt mir 
keinen Vorteil.

Patrick B. schrieb:
> Ich würde mir den Mehraufwand gönnen, wenn ich etwas robustes und
> zukunftsorientiertes bekomme. Wieso jetzt schon auf 99% "Auslastung"
> gehen, wenn man bei einem Privatprojekt mit Stückzahl 1 ohne Probleme
> etwas Klotzen kann und nicht Kleckern muss.

Naja, eben genau weil es ein Hobbyprojekt ist möchte ich keinen neuen 
Mikrocontroller nutzen.
Ich habe privat nicht die Zeit den ganzen (oder teilweise) code neu zu 
schreiben.
Unter professioneller Sicht wäre ich auch schon auf nen anderen MC 
umgestiegen

zyxw schrieb:
> Stimmt meine Vermutung?
> Hardware-Serial = BLDC-Controller
> Software-Serial = Telemetrie?
> Brauchst Du für Telemetrie auch die Rx-Richtung?
> Solche Angaben bitte immer gleich im ersten Post bekanntgeben.
>
> 1. Hast Du schon mal probiert, die Telemetrie über softserial zu senden
> und die Hardware für den BLDC?
> Die Senderoutine ist deutlich einfacher und weniger resourcenhungrig als
> die zum Empfangen.
> Sie Posting von Georg.
>
> 2. Erhöhen der Taktfrequenz auf 20, 22 oder 24 MHz klappt in der Regel.
> Dann aber alles gut abblocken und abschirmen.
>
> 3. Mit welcher Baudrate läuft die Telemetrie?  Kannst Du nicht die
> Hardware-RX für den BLDC und die Hardware-TX für die Telemetrie
> verwenden?
>
> 4. Ist die Hardware gut? Gnd-Schleifen, sonstige Einstreuungen, Spikes
> etc?
>
> 5. Mega328PB ist auch mein Tip.

Die Telemetrie zum RC Sender hängt an der HardUart mit 115kBaud (bzw 
100kBaud je nach Protokoll)
In der Theorie brauche ich da natürlich nur Senden. Aber ich muss leider 
auch empfangen. Sobald alle Servodaten gesendet sind muss ich exakt xx 
ms warten und dann die Telemetriedaten senden.
Wenn ich dort also nicht fehlerfrei empfange laufe ich noch in 
schlimmere Probleme.
Die Daten vom BLDC Controller sind eher ein nebeneffekt der sich erst 
kursfritig ergeben hat. Deswegen wollte ich mehr oder weniger auf die 
Softuart ausweichen.
Ich denke erst im Feldversuch wird sich zeigen wie gut (oder schlecht) 
das funktioniert.

Die Hardware ist ein ganz normaler Arduino Mini pro zum testen.
Später kommt dann der 328p mit auf die BLDC Platine. Sicher ist die 
Arbeitsumgebeung mit (max. 200A und max. 42V) dort nicht ideal.


Ich werde mir den Mega328PB angucken und sehen ob der Code für die 
Telemtrieprotokolle darauf läuft. Bzw ob nur geringfügige Änderungen 
Notwendig sind.
Laut Internet ist der Code vom 328P eins zu eins kompatibel. Das Wäre 
perfekt. Dann brauche ich nur die 2. Hardserial in Arduino nutzbar 
machen. Entsprechende files gibt es ja alles schon.
Das ist echt ein sehr guter Tipp von euch. Danke ;)


Leider fehlt mir wie gesagt die Zeit eine eigene Firmware bis ins Detail 
zu schreiben.
Allein die Probleme mit dem Arduino weil er keine invertierte UART kann 
ist mehr als nervtötend.
Aber mit Arduino ist es eben möglich alle meine gewünschten Funktionen 
schnell zusammenzubringen. Innerhalb von ein paar Stunden hatte ich alle 
3 Telemetrieprotokolle am laufen und die SD Card logging funktion.
Das hätte ich alleine, auf einer neuen Hardware sicherlich nicht 
geschafft.

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
John P. schrieb:
> Die Hardware ist ein ganz normaler Arduino Mini pro zum testen.
> Später kommt dann der 328p mit auf die BLDC Platine. Sicher ist die
> Arbeitsumgebeung mit (max. 200A und max. 42V) dort nicht ideal.

 Nimm doch einfach einen zweiten Mini Pro. Dieser empfängt die
 Telemetriedaten mit 115KB über Hardware-Uart und sendet dann die
 Daten weiter zum ersten Mini Pro mit 57600B über Software-Uart.
 Genauso empfängt der die Daten vom ersten Mini Pro mit 57600B
 über Software-Uart und sendet diese mit 115KB über Harware-Uart.
 Also:
 Beide Software-Uarts laufen mit 57600B, was die Arduinos ohne
 Probleme schaffen, Hardware-Uarts laufen mit 115KB, was die
 Arduinos auch ohne Probleme schaffen.

 Mehrkosten etwa 1,5Euro.

: Bearbeitet durch User
von John P. (brushlesspower)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Nimm doch einfach einen zweiten Mini Pro.

Wie bereits gesagt. Diese Idee hatte ich auch schon. Da würde ich sogar 
soweit gehen und sagen:

1. 328p -> Messen und loggen auf SD
2. 328p -> Telemetrie

Das einzige was mich davon abhält -> kein Platz mehr auf der Platine. 
Und selsbt wenn ich noch was frei mache muss ich wohl 4 Lagen nehmen.
Außerdem finde ich es doch etwas overkill...3 Mikrocontroller für einen 
"simplen" BLDC Controller

: Bearbeitet durch User
von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Nein, anscheinend hast du es nicht ganz verstanden.
>
> Was genau verwirrt dich, vielleicht kann man dir noch irgendwie helfen?

OK, Was genau meintest Du mit

Marc V. schrieb:
> Es ist auch nicht notwendig, dass Hardware USART einen bit 16 Mal
>  abtasten und trotzdem machen es alle so

Zumal Du mit keinem Wort erwähnst, dass der 16-fache Takt dem "Jitter" 
der Startflanken-Erkennung geschuldet ist.

von Thomas E. (picalic)


Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Zumal Du mit keinem Wort erwähnst, dass der 16-fache Takt dem "Jitter"
> der Startflanken-Erkennung geschuldet ist.

Vielleicht hat er den "Takt" mit "Abtasten" verwechselt und meint daher, 
daß alle(?) UARTs 16-fach samplen. Nur so kann ich mir seine 
Korinthenkackerei "Abtasten ist nicht Auswerten" erklären. Ein normaler 
Mensch nimmt genau soviele Proben, wie er dann auch auswertet, daher 
muss man das bei der Anzahl für das Ergebnis nicht unterscheiden.
Wenn er aber mit "Abtasten" den internen Sample-Takt meint, ergibt die 
Unterscheidung sogar einen gewissen Sinn...

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Vielleicht hat er den "Takt" mit "Abtasten" verwechselt und meint daher,
> daß alle(?) UARTs 16-fach samplen. Nur so kann ich mir seine
> Korinthenkackerei "Abtasten ist nicht Auswerten" erklären.
 Es war deine Korinthenkackerei:
Marc V. schrieb:
> Fängt die Korinthenkackerei schon wieder an ?


Thomas E. schrieb:
> Ein normaler
> Mensch nimmt genau soviele Proben, wie er dann auch auswertet, daher

 Vielleicht solltest du ATMEL davon benachrichtigen...
 Beitrag "Re: CRC Fehlerkorrektur -> Lookuptable"

Thomas E. schrieb:
> Wenn er aber mit "Abtasten" den internen Sample-Takt meint, ergibt die
> Unterscheidung sogar einen gewissen Sinn...

 Ja, meint er.
to sample
1
abtasten
2
abfragen
3
samplen

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
John P. schrieb:
> as einzige was mich davon abhält -> kein Platz mehr auf der Platine.
> Und selsbt wenn ich noch was frei mache muss ich wohl 4 Lagen nehmen.
 Nein.
 Ein Mini Pro ist 18x33mm. Das passt doch locker sogar längst unter
 deiner Platine (83,82x32,00).
 BTW, was hindert dich daran, Mini Pro einfach am Kabel zu befestigen?
 Ein Ferritkern am Kabel ist fast genauso groß, manche sind sogar
 noch größer.

> Außerdem finde ich es doch etwas overkill...3 Mikrocontroller für einen
> "simplen" BLDC Controller
 Wenn interessiert es, ob da 2 oder 6 uC werkeln?

 Ich habe es erst neulich irgendwo im Forum geschrieben:
 Wir nehmen MEGAs(328P) für Abfrage der verschiedenen Sensoren sowie
 Steuern der Aktoren und STM32 als Master macht die notwendigen
 Berechnungen bzw. Umrechnungen, sendet die entsprechenden Befehle und
 komuniziert mit der Zentrale, falls notwendig und vorgesehen.
 Funktioniert wunderbar und auf us genau ohne irgendwelche Akrobatik.

 Preisunterschied (für uns) etwa 6Euro - für Kunden entsprechend mehr,
 aber Sicherheit und Performance sind ganz einfach nicht miteinander
 zu vergleichen.

: Bearbeitet durch User
von John P. (brushlesspower)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Ein Mini Pro ist 18x33mm. Das passt doch locker sogar längst unter
>  deiner Platine (83,82x32,00).

Ich baue doch nicht den Mini Pro ober oder über meine Platine???
Der Atmega328 wird schon direkt mit auf die PCB gepackt und im 
Reflowofen aufgelötet.
Außerdem ist unter der Platine kein Platz, da sitzen die Mosfets.

Ich bin aber grad dabei einen 2. Atmega 328p zu platzieren. Es scheint 
doch zu passen. (5mm größere PCB)
Siehe Bild

Und der Vorteil:

ich kann mit dem 1. Atmega schnell messen (und eventuell abschalten) und 
alles loggen.
Und mit dem 2. Atmega kann ich im sekundentakt Telemetriedaten senden.

Die Verbindung der beiden geht dann über die Softuart oder alternativ 
über I2C

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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