Hallo, ich habe so 10 Fertige Platinen (BCA8-BTM222) und komme jetzt an den Punkt, wo ich eine 2. Serielle, nur TX, allerdings mit 115200 Baud bräuchte. Der ATmega328P läuft mit 8MHz. Die Hardware Serielle ist fest verdrahtet auf der Platine und fällt flach. Hier brauche ich zwingend RX und TX. Bei der 2. Serielle soll nun "SUMD", was 115200 Baud hat, gesendet werden. Softuart mit 115200 Baud ist wohl nicht zuverlässig möglich, was ich so gelesen habe. Was ich frei hätte wäre der SPI und andere Digitale IO Pins. I2C wäre auch noch eine Möglichkeit, bräuchte ich eben eine Wandlung I2C zu RS232. Jemand eine Idee ? Gruss Juergen
Hallo, zum einen würde ich einen anderen AVR µC mit zwei USART wählen Jürgen S. schrieb: > Bei der 2. Serielle soll nun "SUMD", was 115200 Baud hat, gesendet > werden. > > Softuart mit 115200 Baud ist wohl nicht zuverlässig möglich, was ich so > gelesen habe. Dann ist das ein Gerücht. Man wähle z.B. einen 12MHz Quarz, dann beträgt die Wartezeit recht genau 104µs pro Bit. Am Stück sendet man i.A. 10Bit, also ist der µC insgesamt 10*104µs pro Zeichen blockiert. Zwischen den Zeichen kann man sich jede Zeit nehmen, die man braucht. Ich betreibe z.B. 3 (TX-)Softwareuart mit 57600 Bit/s im Interruptbetrieb.
Wie gesagt fertige existierende Platine. http://rf-store.com/index.php?view=2&pv=showart&prod_id=BCA8-BTM-328P Die CPU tauschen geht leider nicht. Die CPU Frequenz ändern, wäre eventuell möglich. Würde ich, sofern irgend möglich, gerne vermeiden. Das würde 2 IO Pins kosten und ich müsste das Quarz Signal über einen Steckverbinder schicken. Wie gesagt, das ganz ist schon fertig und seid mehreren Jahren in Betrieb. Gruss Juergen
Aha, wie etwas mehr Infos. Schau mal hier: https://www.maximintegrated.com/en/products/interface/controllers-expanders/MAX3107.html
Noch eine Möglichkeit, man nehme einen weiteren AVR mit Usart und setze ihn als I2C Client zu Uart ein.
Jürgen S. schrieb: > Das würde 2 IO Pins kosten Soll das heissen, du betreibst den Controller ohne Quarz? Das ist bei seriellen Verbindungen sowieso eine ganz schlechte Idee. Georg
Hi Georg, sein Modul braucht nur 9600 Bit/s, das funktioniert also nach seiner Aussage. Nicht optimal.
Die Applikation läuft erstaunlich gut. Temperaturbereich ist so 0°C bis so +35°C bisher und hatte noch kein Problem. Kommunikation mit dem BTM222 läuft mit 38400. Ist letzten Endes ein Bluetoth RC Empfänger, der Servo Signale ausgibt. Das hat aber sicher auch damit zu tun, dass der USART des ATmega und BTM222 da recht Tolerant ist. Die neuere Variante läuft mit einem ATmega 1284 mit 16MHz Quarz. Kann ich bei diesen Platinen aber nicht ändern. Karl M.: Ja, an die Lösung hab ich auch schon gedacht. Ich hoffe nur noch, dass jemand eine Lösung hat, ohne extra Hardware. Ich überlege ob ich den SPI nicht nutzen kann. Da mir hier Start und Stopbit fehlt, könnte ich eventuell tricksen und die 10 UARt Bits mit 2 Bytes (16 Bit) und dem SPI simulieren.
Jürgen S. schrieb: > Softuart mit 115200 Baud ist wohl nicht zuverlässig möglich, was ich so > gelesen habe. Nur TX ist softUART kein Problem, Timer, im Interrupt einfach zu sendendes Byte serialisieren und Pin setzen/rücksetzen. mfg Achim
Hi Jürgen S., dann rechne Dir bitte mal das Timing bei 8Mhz für 115200 Bit/s aus. Das passt nicht! 115200 Bit/s bedeutet alle 1/115200 ~ 8,6806µs ein Bit(-wechsel). Das sind dann bei 8Mhz: 8*10^6Hz /115200 = 69,44.. Takte zwischen jedem Bit(-wechsel). Puh das geht nicht auf. So kannst Du dass mit allen anderen Hardwareeinheiten mal durchrechnen. Wie sieht das mit dem SPI Takt dann aus?
Das Softuart nicht geht, schrieb ich ja schon in meinen Start Post. Den UART duch 2 SPI Bytes simulieren, wird wohl auch nicht gehen, da ich über 6% Fehler hätte. Bei 8MHz müsste ich mit einem 64 Teiler arbeiten und würde bei 125000Bau landen. Schade. Im Zweifel dann eben doch I2C auf Seriell Wandler. I2C könnte ich eh noch brauchen für ein Display :-) Da ich davon 10 Stück bräuchte (Maximal), wäre eine fertige Platine toll. So wie das: https://www.sparkfun.com/products/retired/9981 Allerdings nicht mehr lieferbar. Kennt jemand eine ähnliche Platine? Achso, ich brauche 5V Pegel, da es ja SUMD Simulieren soll.
:
Bearbeitet durch User
Ok, das Problem mit den I2C Seriell Bausteinen ist die 3,3V, da ich hier mit 5V fahren will. Somit muss ich wohl doch in den sauren Apfel beißen und einen Mikrocontroller Programmieren als I2C Slave. Der kann dann natürlich gleich mehr Aufgaben übernehmen. Ist eben nur nochmal ein Stück Software zu pflegen. Langfristig werde ich mir wohl eine Platine mit BTM222 drauf machen lassen und einem größeren ATmega und einem 16MHz Quarz Gruß Juergen
Jürgen S. schrieb: > einem größeren ATmega und einem 16MHz Quarz ATMega328PB. Im Prinzip das gleiche nur mit nem 2. UART. Und noch ein bisschen was anderem anders.
Angehängte Dateien:
-
2018-12-17_125109.png
36 KB
Jürgen S. schrieb: > Softuart mit 115200 Baud ist wohl nicht zuverlässig möglich, was ich so > gelesen habe. Jürgen S. schrieb: > Somit muss ich wohl doch in den sauren Apfel beißen und einen > Mikrocontroller Programmieren als I2C Slave. Natürlich stimmt das nicht. M328P internen Oszillator kann man auf 1% genau kalibrieren, was für SoftUart vollkommen ausreicht. Und Soft-Tx läuft ohne Probleme, sofern man während des sendens Interrupts sperrt. Das sind pro Byte 86,8us, danach INT freigeben (wegen ev. Hard-RxD), nächstes Byte senden und so bis zum Ende der Message. P.S. Hier ein Bild aus DaBla.
:
Bearbeitet durch User
Karl M. schrieb: > Das sind dann bei 8Mhz: > 8*10^6Hz /115200 = 69,44.. Takte zwischen jedem Bit(-wechsel). > > Puh das geht nicht auf. Das ergibt 0,6% Fehler, das geht noch.
Marc V schrieb: > Und Soft-Tx läuft ohne Probleme, sofern man während des Sendens > Interrupts sperrt. > Das sind pro Byte 86,8us, danach INT freigeben (wegen ev. Hard-RxD), > nächstes Byte senden und so bis zum Ende der Message. +1 Wenn du die Interrupts für die Dauer sperren kannst/darfst, ist Senden kein Problem. Empfang ist schwierig.
Stefanus F. schrieb: > Der Atmega328PB hat zwei serielle Schnittstellen. Dann braucht man aber ein Baudratenquarz für die 115,2k, z.B. 7,3728MHz.
>> Das sind dann bei 8Mhz: >> 8*10^6Hz /115200 = 69,44.. Takte zwischen jedem Bit(-wechsel). >> >> Puh das geht nicht auf. > > Das ergibt 0,6% Fehler, das geht noch. Insbesondere kann man die Bits abwechselnd mit 69 und 70 Takten einlesen - dann liegt man im Sub-Promille-Bereich.
Stefanus F. schrieb: > Peter D. schrieb: >> Das ergibt 0,6% Fehler, das geht noch. > > Ja, geht. Habe ich ausprobiert. Ja, nur sind das 0,6% Fehler zusätzlich zum Oszi Fehler.
Peter D. schrieb: > Stefanus F. schrieb: >> Der Atmega328PB hat zwei serielle Schnittstellen. > > Dann braucht man aber ein Baudratenquarz für die 115,2k, z.B. 7,3728MHz. Genau. 115Kb mit 8MHz und Hard-Uart ist sowieso ein ganz schlechter Ansatz - Fehler liegt zwischen +8,5% beim U2x=0 und -3.5% beim U2x=1. Das funktioniert nie und nimmer zuverlässig - wenn überhaupt.
:
Bearbeitet durch User
Hallo Marc V. schrieb: > Genau. > 115Kb mit 8MHz und Hard-Uart ist sowieso ein ganz schlechter Ansatz > - Fehler liegt zwischen +8,5% beim U2x=0 und -3.5% beim U2x=1. > > Das funktioniert nie und nimmer zuverlässig - wenn überhaupt. Es geht um einen möglichen SoftUart bei 8MHz.
Karl M. schrieb: >> Das funktioniert nie und nimmer zuverlässig - wenn überhaupt. > > Es geht um einen möglichen SoftUart bei 8MHz. Nein. Stefanus F. schrieb: > Der Atmega328PB hat zwei serielle Schnittstellen. Jürgen S. schrieb: > Somit muss ich wohl doch in den sauren Apfel beißen und einen > Mikrocontroller Programmieren als I2C Slave.
Also mit Zuverlässig nicht möglich meine ich, dass das die CPU schon an die grenzen kommt, und man Interrupts sperren muss. Jetzt war ich doch etwas verunsichert und habe nochmals nachgerechnet. Meine Hardware UART läuft mit 38400Baud mit entweder 8MHz oder bei neuen Platinen mit 16MHz. Laut Datenblatt des ATmega328P bekomme ich so 0,2% Fehler, was vollkommen ok ist :-) Also alles Save. Wie gesagt läuft so seit 2013 ohne Probleme. Jetzt zu meiner zusätzlichen Seriellen, die SUMD RC Signale ausgeben soll. Laut Doku von Graupner läuft dass mit 115200 Baud. Doku, siehe hier: https://www.deviationtx.com/media/kunena/attachments/98/HoTT-SUMD-Spec-REV01-12062012-pdf.pdf Zitat: "The serial connection needs to be set to 115200 Bit/s, 8 Databits, no Paritybit, 1 Stopbit. Each data frame is sent as a consistent data burst leaving minimal gaps less than 50µs between transmitted data bytes." Es können maximal 32 Kanäle übertragen werden, mir würden 16 reichen. Andere Alternative wäre das SBUS Protokoll. Läuft "nur" mit ca.100000Baud. Weniger Datenbyte, dafür "komplizierter" verpackt und geringere Auflösung. Bleiben wir mal bei SUMD, und treiben es auf die Spitze. 32 Kanäle. Macht 3 Byte Header + 2*32Byte(Kanäle) + 2 Byte CRC = 69 Byte. 69 Byte * 11 Bit (Ich rechne mit 11 für 2 Stopbit und etwas Sicherheit.) 759 Bit. Bitdauer 8,68us * 759 Bit = ca 6,6ms Übertragungsdauer. Übertrage ich nur 16 Kanäle, wären es nur ca 3,6ms. Uff Da ist nicht mehr viel CPU Zeit über, wenn ich das per Softuart und sperren der Interrupts machen müsste. Alle 10ms soll man das senden, das wäre nicht das Problem, das könnte ich in der Pause der anderen PPM Signale machen. Einzig mein Timer für die Zeit wäre dann wohl dahin. Der feuert alle 0,01s und bestimmt das interne Timing durch setzen von Flags. Und zwischendurch sollte ich ja noch die anderen PPM Signal generieren. Wegen der anderen CPU, das wäre nur eine alternative, wenn die 100% Pincompatibel ist, ich also den ATmega328p auslöten und die neue CPU einlöten könnte. Zudem sollte die beschaffbar sein in kleinen Stückzahlen. Habe ich beides aktuell nicht geprüft. Das Flash und RAM eher größer als kleiner sein sollten, versteht sich von selber :-)
Jürgen S. schrieb: > Wegen der anderen CPU, das wäre nur eine alternative, wenn die 100% > Pincompatibel ist Der ATmega328PB ist pinkompatibel, TXD1 liegt auf PB3. Ein passender Quarz wäre z.B. 14,7456MHz.
Jürgen S. schrieb: > Zitat: "The serial connection needs to be set to 115200 Bit/s, 8 > Databits, no Paritybit, 1 Stopbit. Each data frame is sent > as a consistent data burst leaving minimal gaps less than 50µs between > transmitted data bytes." Schrieb ich dir oben schon einmal: Marc V. schrieb: > Das sind pro Byte 86,8us, danach INT freigeben (wegen ev. Hard-RxD), > nächstes Byte senden und so bis zum Ende der Message. Min. 50µs gap ist doch mehr als genug Zeit sowohl für ev. RxD-Int, als auch für deinen Timer-INT (welcher sowieso nur alle 10ms feuert). So schwer zu verstehen ? P.S. 86,8µs/Byt + 40µs im Sendeloop auf ev. INT warten, ergibt eff. 78,8Kb. d.h. 37Byt * 126,8µs gleich 4691µs für normale Frames. Das lässt dir immer noch mehr als 5300µs zwischen den Frames. P.P.S. Wenn dein Timer-INT alle 10ms feuert, dann kannst du ihn gleich fürs senden der Frames ausnutzen, oder ?
:
Bearbeitet durch User
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.