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
@ 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.
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
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
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
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
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
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
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. ;)
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.
bist du dir wirklich sicher das die Baudrate innerhab der Spec liegt? kommt mir so vor als hättest du keine 115kBaud
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
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 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).
Dann nimm 57600. Mit dem ganzen Fehlerkorrektur-Quark und retransmit hast Du unterm Strich auch keine höhere Datenrate.
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
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
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
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
Hallo, ich habe jetzt nicht alles gelesen, werfe aber einfach mal den ATMEGA328pB in den Raum. Kompatibel und hat 2 UARTs.
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
Nachtrag: das gibts auch fertig: http://www.advantech.com/products/9b61869b-9881-49a5-ae89-43f1437c14d1/bb-232brc/mod_de20c037-35f8-4c4e-9141-2edfb6034228 Georg
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.
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.
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
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
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.
@ 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?
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.
John P. schrieb: > Der Fehler tritt nur bei einem vorherigen 0 Byte auf Dann sorge dafür, dass Byte 6 kein "0 Byte" ist.
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 |
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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
Angehängte Dateien:
-
2018-10-13_144408.png
21 KB
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
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
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
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
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 ?
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.
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
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.
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
Alex G. schrieb: > Wiederverwendbarkeit des Ganzen praktisch Null. > Das soll ein Vorteil sein? Wiederverwendbarkeit ist nicht immer von Interesse.
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...
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?
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.
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?
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
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
Angehängte Dateien:
-
PCB.png
12 KB
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
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.
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
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
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
Angehängte Dateien:
-
PCB_neu.png
5,5 KB
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.