Und mal wieder eine kurze Frage, wo ich hoffe, daß jemand etwas Erfahrung hat. Wenn ich zwei µC mit einer RS232-Verbindung (paar Meter Entfernung, TTL-Pegel, Telefonkabel) kommunizieren lassen möchte, reicht da der interne RC-Taktgenerator für eine stabile Verbindung bei 1200 oder 2400bps aus? Und wie steht's um die Temperaturstabilität? Ansonsten würde ich die beiden µC lieber mit einem Quarz oder Keramik-Resonator ausstatten um sicherzugehen, aber da ich keine hohe Datentransferrate brauchte, kann man sich das vielleicht sparen. Danke!
Ben B. schrieb: > aber da ich keine hohe > Datentransferrate brauchte, kann man sich das vielleicht sparen. Der Fehler ist prozentual. Da würde nur eine Datenrate von 0 Bd helfen. Nimm einfach zwei Quarze und alles ist in Ordnung!
Ben B. schrieb: > Ansonsten würde ich die beiden µC lieber mit einem Quarz oder > Keramik-Resonator ausstatten um sicherzugehen, Tu das. > aber da ich keine hohe > Datentransferrate brauchte, kann man sich das vielleicht sparen. 10% Fehler sind 10%. Egal ob schnell oder langsam. Wenn du langsam unterwegs bist könntest du den Oszillator entsprechend dem Bittiming hintrimmen. Aber nach langen Versuchen und etlichen Rückschlägen wirst du sagen: warum habe ich nicht von Anfang an den Quarz eingebaut?
Ben B. schrieb: > Wenn ich zwei µC mit einer RS232-Verbindung (paar Meter Entfernung, > TTL-Pegel, Telefonkabel) kommunizieren lassen möchte, reicht da der > interne RC-Taktgenerator für eine stabile Verbindung bei 1200 oder > 2400bps aus? Und wie steht's um die Temperaturstabilität? Jain. Meistens wird das arbeiten, aber ohne Garantie. Wenn RC-Taktgenerator und Garantie notwendig, dann gibt es aber eine Lösung: XCK benutzen. Dafür ist das auch erfunden. Geschwindigkeit kann dabei beliebig sein.
:
Bearbeitet durch User
Bei 10 bit Länge des RS232-Zeichens (Startbit+8 bit Daten + parity) Darf nur eine Verschiebung in der "Länge" von ca.10 Prozent stattfinden, sonst wird das vorletzte oder das (nach parity kommende) Stopbit als zehntes gelesen. im worst case sind sogar nur 5% Genauigkeit erlaubt, wenn ein Partner um 5% schneller, der andre um 5% langsamer ist. Bei atmegas ist gerade deswegen der Oszillator per fuses justierbar. Atmel erzählt, dass dann die Frequenzstabilität ausreichen würde. Ich selbst habs noch nicht ausprobiert.
Lothar M. schrieb: > 10% Fehler sind 10%. Egal ob schnell oder langsam. So isses. > Wenn du langsam unterwegs bist könntest du den Oszillator entsprechend > dem Bittiming hintrimmen. Das geht bei "schnell" natürlich ebenfalls. Autokalibrierung ist möglich, sobald der Takt des AVR mindestens 4x höher ist als die zu verwendende Bitrate. Jedenfalls wenn man die richtige Sprache für kleine µC benutzt... > Aber nach langen Versuchen und etlichen > Rückschlägen wirst du sagen: warum habe ich nicht von Anfang an den > Quarz eingebaut? Klar, für den normalen Fall ist das sicher die einfachste, beste und zuverlässigste Lösung. Würde ich auch jederzeit empfehlen, außer bei folgenden Gegenanzeigen: - Batteriebetrieb - extreme mechanische Beanspruchung (Vibrationen oder starke Schläge) - Mangel an Pins - das Device ist überhaupt nicht zum Betrieb mit einem Quarz/Resonator befähigt (Tiny13 z.B.)
Peter R. schrieb: > Bei 10 bit Länge des RS232-Zeichens (Startbit+8 bit Daten + parity) Darf > nur eine Verschiebung in der "Länge" von ca.10 Prozent stattfinden, > sonst wird das vorletzte oder das (nach parity kommende) Stopbit als > zehntes gelesen. > > im worst case sind sogar nur 5% Genauigkeit erlaubt, wenn ein > Partner um 5% schneller, der andre um 5% langsamer ist. Halb so viele Prozent, denn die Bits werden ungefähr in ihrer Mitte abgetastet.
Oder I2C? Da wird ja der Takt mit"übertragen". Allerdings habe ich da schon viel über Probleme gelesen, die viele Leute damit haben, so daß der Bus in irgendeinem Status klebenbleibt oder so... Naja mal sehen ob ich noch zwei Baudratenquarze habe. Was ist XCK? Nie gehört.
Der I²C Bus bleibt nur hängen, wenn man einen Hardwaredefekt hat.
Na oder Programmierfehler... Scheint mir einfach schwerer zu handhaben als RS232.
Ben B. schrieb: > Was ist XCK? Nie gehört. Die USARTs der AVR können auch "synchron" (ist keine echte Synchronität) betrieben werden. Der entsprechende Ein-/Ausgang heisst typisch XCK(n). Zur Nutzung dieses Features ist halt eine Strippe mehr erforderlich. Ansonsten ist es weitgehend schmerzlos, ein Bit hier und ein Bit da beim Setup der USARTs und die Sache läuft. Und sie ist wirklich geeignet, jegliche Probleme durch abweichende Takte der Peers zu beheben. Wenn der Peer denn überhaupt eine USART besitzt und der XCK-Pin dafür nicht anderweitig gebraucht wird...
Was soll das Gezerre ? Ein Quarz kostet um die 20 cents. Die Frage ist also eher oberhalb 1000 Stueck interessant zum Untersuchen.
Peter R. schrieb: > im worst case sind sogar nur 5% Genauigkeit erlaubt, wenn ein Partner um > 5% schneller, der andre um 5% langsamer ist. Beide dürfen insgesamt nicht mehr als 4% abweichen. Einer +2, der andere -2 ist bereits Ende. Das letzte Bit (11 mit Party) muss auf 7/16bit genau sein. 7/176 sind 4%. Dabei schlägtt schon einer der 3 Samples fehl und die Flanken müssen Perfekt sein. Sollen alle 3 Samples passen, sind es 3.4% in Summe maximal
Den Atmel mit der Zwille in eine Erdumlaufbahn schiessen, und einen PIC nehmen. Komisch das die die 1 % hinkriegen und die anderen nicht.
Ein PIC kriegt 1% Genauigkeit mit dem RC-Takt über den gesamten Temperaturbereich ohne Kalibrierung hin? Stauni.
Es geht auch ohne Quarz. Am wenigsten Ärger hast Du, wenn es die gleichen Controller sind. ATXMege gegen ATMega ist schlecht. Der eine hat nen temperaturkompensierten RC, der andere nicht. Bei den wenigen Ausnahmen wo es bei gleichen Typen nicht auf Anhieb funktioniert, dreht man üblicherweise ein wenig am Baudratenregister, dann klappt es stabil. Bei den wenigen Anwendungsfällen, wo unterschiedliche Controller miteinander kommunizieren, oder wo wirklich sich ändernde Temperaturunterschiede auftreten (z.B. Außensensor zu Innenstation), kann man auch 'ne Synchronisation anhand eines Prüfbytes vornehmen, wenn man die 9-Bit Übertragung wählt. Das neunte Bit setzt man immer auf 0 und klemmt es quasi zwischen einem manchmal übertragenen 1MSB und dem Stopbit ein. Beim Senden werden 0xAA-Bytes eingeschleust (!UART=LSBit first!). Wird beim Empfang das 9. Bit als 1 empfangen, geht was schief. Dann horcht man eine Weile, misst den kürzesten Wechsel (Es kommen ja weitere 0xAAs) und stellt die Baudrate oder den RC-Kalibrierer neu ein. Alles andere ist Angstmache. Wo es allerdings KEINE Angstmache ist: BT- oder WLan-Module übertragen Deine Signale nicht 1:1, haben in der Regel auch keine 9 Bit-Übertragung.
PICklig schrieb: > PIC > nehmen. > Komisch das die die 1 % hinkriegen und die anderen nicht. da dürfte eher die interne Taktquelle als 1% gefühlt worden sein um spezifische Baudraten zu erreichen: AVR(8MIPS/_8MHz)Prescaler:_5=>100kb/s; _4=>125,0(115,2+9,0%) PIC(6MIPS/24MHz)Prescaler:15=>100kb/s; 13=>115,4(115,2+0,2%) In Situationen in denen die Oszis u.U. nicht so genau gehen,Nettobandbreite kein Thema ist und das Risiko von Lötstellen von Quarzen oder Extraleitungen unangenehm ist, kann auch bspw. 5-bit (nibble +metabit) ganz praktisch sein. 5% Fehler sind nach 6 bitzeiten 30% d.h bei 16fach sampling +4,8;nach 9 bitzeiten 45%+7,2 ein Sample damit aus der folgenden bitzeit.
Angehängte Dateien:
-
PIC_OSC_Accuracy1.PNG
9,8 KB -
PIC_OSC_Accuracy2.PNG
23 KB
Ben B. schrieb: > Naja mal sehen ob ich noch zwei Baudratenquarze habe. Du brauchst nur 2 gleiche Quarze. Denn ob die µC mit einer "Normfrequenz" miteinander kommunizieren oder mit 123456Bd(*) ist egal, solange sie nur bei Sender und Empfänger gleich ist. (*)solche "unpassenden" Baudraten werden auch von Leuten gern genommen, die auf "einfache" Art ihre Kommunikation "verschlüsseln" wollen... Federfuzzi schrieb: > Es geht auch ohne Quarz. Ja. Man kann es auf etliche Arten "hinmurksen". Hinterher beißt man sich dann sonstwohin, weil man unbedingt die 50 Cent "sparen" musste. S. R. schrieb: > Ein PIC kriegt 1% Genauigkeit mit dem RC-Takt über den gesamten > Temperaturbereich ohne Kalibrierung hin? Und über den gesamten Spannungsbereich? Natürlich kochten die PIC-Designer mit dem selben Wasser wie die AVR Designer und bekommen auch keine besseren internen RC-Oszillatoren hin. In den Bildern mal exemplarisch zwei Auszüge aus PIC-Datenblättern...
:
Bearbeitet durch Moderator
Ben B. schrieb: > Und wie steht's um die Temperaturstabilität? Die Temperaturstabilität kann dir egal sein, solange beide etwa die gleiche Temperatur und eine ausreichend ähnliche Temperaturabhängigkeit besitzen.
Stefanus F. schrieb: > Der I²C Bus bleibt nur hängen, wenn man einen Hardwaredefekt hat. Ist das wirklich so? Mir war als wenn Atmel AVR ATmega Probleme mit Clockstretching haben und hängen bleiben können. Ausserdem sind ATmega nicht OC open collector.
Joachim B. schrieb: > Stefanus F. schrieb: >> Der I²C Bus bleibt nur hängen, wenn man einen Hardwaredefekt hat. > Mir war als wenn Atmel AVR ATmega Probleme mit Clockstretching haben und > hängen bleiben können. Auch das wäre ein hardwaredefekt und betrifft ganz sicher nicht pauschal alle AVR Modelle. > Ausserdem sind ATmega nicht OC open collector. Richtig. Sie sind Open-Drain.
Moin, Jetzt ist G. schrieb: > Was soll das Gezerre ? Ein Quarz kostet um die 20 cents. Die Frage > ist > also eher oberhalb 1000 Stueck interessant zum Untersuchen. Die 20 ct tun wahrscheinlich weniger weh als die 2 Pins die der Quarz am µC ausserdem kostet. Gruss WK
Dirk B. schrieb: > 5-bit > (nibble +metabit) ganz praktisch sein. 5% Fehler sind nach 6 bitzeiten > 30% d.h bei 16fach sampling +4,8;nach 9 bitzeiten 45%+7,2 ein Sample > damit aus der folgenden bitzeit. Der Tipp verdient es IMHO, etwas weniger im langen Posting unterzugehen. Mit 5 Datenbits sind es nicht 10 oder 11 Bit insgesamt, sondern nur 7 Bit (ohne Parity), es reicht also eine Genauigkeit von 7/(7*16) = 1/16 = 6.25%. Ob das ein AVR mit RC-Oszillator schafft, weiß das Datenblatt. MfG, Arno
PICklig schrieb: > Komisch das die die 1 % hinkriegen und die anderen nicht. Zeig mal Deine Zwille und Deine Abschussvorrichtung (Arme) :-)
Also, drei Möglichkeiten: 1. RC. Unsicher, aber 2 Pin gespart. 2. XCK. Sehr sicher, 1 Pin mehr besetzt. 3. Quarz. Sehr sicher, aber bei Mega8 und 48-88-168-328 2 Pin von PORTB weg. Bei Mega324-644-1284 und 128-2560 ist das nicht der Fall, XTAL-Pins sind dort separat. Ich würde Variante 1 lieber nicht machen. Sonst ist das wie Minenfeld. Murphy's law: Anything that can go wrong will go wrong
Zum gelegentlichen Update von Firmware per Bootloader oder zum Ausgeben von Logmeldungen genügt mir der RC Oszillator. Für ernsthafte UART Kommunikation würde ich den RC Oszillator bei keinem µC verwenden.
> Natürlich kochten die PIC-Designer mit dem selben Wasser wie die AVR ... Wohl kaum. Saemtliche PICs die mir bis jetzt untergekommen sind, schafften die 1 % problemlos ueber den fuer mich relevanten Temperatur- und Spannungsbereich. Und alles was AVR hiess, versagte dabei klaeglich. Das asynchrone Kommunikation mit normalen Parametern wie 8n1 mit dem internen Oszillator des AVR nicht zuverlaessig funktioniert ist ja wohl bekannt... Bei einem 8- oder 14-Pinner will man nicht unbedingt noch einen Quarz haben. Schliesslich koennte das ganze ja auch mal runterfallen.
PICklig schrieb: > Das asynchrone Kommunikation mit normalen Parametern wie 8n1 mit > dem internen Oszillator des AVR nicht zuverlaessig funktioniert ist > ja wohl bekannt... All den AVRs, die ich bislang in den Fingern hatte, war das zum Glück nicht bekannt. :-)
Oki, ich danke euch... Habe leider keine Bauratenquarze mehr da, muß ich welche bestellen. Oder gibts diese 3Pin-Keramikresonatoren auch mit Baudratenfrequenzen?
Ben B. schrieb: > Oder gibts diese 3Pin-Keramikresonatoren auch mit Baudratenfrequenzen? Gibt's auch. Wie dir aber oben schon geschrieben worden ist: Baudratenquarz muss es nur sein, wenn du mit jemandem (bspw. einem PC) kommunizieren möchtest, der nur Standard-Baudraten beherrscht. Für die Kommunikation zwischen zwei Controllern verbietet dir niemand, einen 8-MHz-Quarz zu nehmen und eine Baudrate von 500 kbps oder 1 Mbps festzulegen.
PICklig schrieb: > Und alles was AVR hiess, versagte dabei klaeglich. Bei den Xmegas geht UART mit R/C Oszillator einigermaßen zuverlässig. Außer wenn man sie richtig heiß macht (z.B. mit einem Fön). Der Trick besteht bei den Xmegas darin, den schnellen grob justierten PLL Oszillator auf den genaueren 2MHz Oszillator zu synchronisieren:
1 | // Set clock source to 32Mhz using the internal R/C Oscillator.
|
2 | OSC.CTRL|=OSC_RC32MEN_bm; |
3 | while (!(OSC.STATUS & OSC_RC32MRDY_bm)); |
4 | CCP=CCP_IOREG_gc; |
5 | CLK.CTRL=CLK_SCLKSEL_RC32M_gc; |
6 | // Synchronize to the calibrated 32kHz oscillator (needed for the UART)
|
7 | OSC.CTRL&=(~OSC_RC2MEN_bm); |
8 | OSC.CTRL|= OSC_RC32KEN_bm; |
9 | while (!(OSC.STATUS & OSC_RC32KRDY_bm)); |
10 | OSC.DFLLCTRL &= ~OSC_RC32MCREF_bm; |
11 | DFLLRC32M.CTRL |= DFLL_ENABLE_bm; |
Es ist immer sinnvoll zu wissen, wie schnell der Takt tatsächlich ist. Man müsste den Takt mit einer rtc messen und die ausgemessene Konstante im eprom hinterlegen. Danach dann F_CPU berechnen. Problem bei delay.h ist nur, dass F_CPU vor dem Programmstart gesetzt wird. Wie bekommt man F_CPU aus dem eeprom ausgelesen?
grundschüler schrieb: > Wie bekommt man F_CPU aus dem eeprom ausgelesen? Geht nicht. Die delay-Makros brauchen zwingend eine zur Compilezeit bekannte Frequenz. Wenn die tatsächliche Frequenz zur Laufzeit eine andere ist, dann werden die Delays halt länger oder kürzer. Dynamische Anpassung geht nur mit einem Timer, dessen Wert zur Laufzeit aus der tatsächlichen (ggf. im EEPROM hinterlegten) Frequenz ermittelt wird. Aber: das hat mit dem Thema dieses Threads (serielle Kommunikation) rein gar nichts zu tun.
Muss ich überlegen. :) Ich habe noch 12 und 4 Mhz als Quarz, damit könnte man ein Päärchen bauen, allerdings ohne passenden kleinen Kondensatoren. Also irgendwas bestellen muß ich sowieso, dann nehm ich halt die Quarze dazu. Edit: Was ist mit dem 128kHz-Oszillator, den die AVRs für den Watchdog haben? Wird der von dem internen RC-Oszillator der CPU abgeleitet und wie genau ist der?
:
Bearbeitet durch User
Ben B. schrieb: > Was ist mit dem 128kHz-Oszillator, den die AVRs für den Watchdog haben? > Wird der von dem internen RC-Oszillator der CPU abgeleitet und wie genau > ist der? Der wird nicht davon abgeleitet (der Watchdog soll ja schließlich auch dann arbeiten können, wenn der Controller schläft), aber er ist viel ungenauer als der Hauptoszillator. Beim Watchdog ist Energie sparen viel wichtiger als Genauigkeit.
Stefanus F. schrieb: > Der Trick besteht bei den Xmegas darin, den schnellen grob justierten > PLL Oszillator auf den genaueren 2MHz Oszillator zu synchronisieren: Sorry, ich habe mich hier vertippt. Man muss auf den 32kHz Oszillator synchronisieren.
Ben B. schrieb: > Edit: Was ist mit dem 128kHz-Oszillator, den die AVRs für den Watchdog > haben? Wird der von dem internen RC-Oszillator der CPU abgeleitet Das steht in DB: Nein. > und > wie genau ist der? Das steht im DB. Kurzfassung: noch deutlich ungenauer als der kalibrierte RC-Oszillator. Eben weil der kalibriert ist..
Angehängte Dateien:
-
Rel-Fehler.png
4,3 KB -
Osc-Temp.png
63 KB
PICklig schrieb: > Und alles was AVR hiess, versagte dabei klaeglich. Und das hast du - woher ? Ben B. schrieb: > Edit: Was ist mit dem 128kHz-Oszillator, den die AVRs für den Watchdog > haben? Wird der von dem internen RC-Oszillator der CPU abgeleitet und > wie genau ist der? Im bestem Fall so genau wie der interne RC-Oszillator, meistens aber viel ungenauer. Aber die immer wieder erwähnte Abhängigkeit von der Temperatur und Spannung ist überhaupt nicht so tragisch, siehe Bild. Laut ATMEL ergibt das zwischen 10°C und 40°C einen Fehler von max. 0.6%, mit Oszillator kalibriert auf 1% Fehler, ist das ein Gesammtfehler von max. 1.6%. Und das ist mehr als genug für eine zuverlässige Kommunikation.
:
Bearbeitet durch User
Ben B. schrieb: > Habe leider keine Bauratenquarze mehr da, muß ich welche bestellen. Oder > gibts diese 3Pin-Keramikresonatoren auch mit Baudratenfrequenzen? Die Teiler der UARTs in atmegas lassen sich so programmieren, dass man auch mit "runden" Frequenzen wie 4M,5M,20M ausreichend genaue Taktfrequenzen einstellen kann. Siehe Daten"blatt". Achim S. schrieb: > Beide dürfen insgesamt nicht mehr als 4% abweichen. Einer +2, der andere > -2 ist bereits Ende. Jo, hast recht. Ich hab halt mal kurz skizziert und überlegt und bin dadurch auf diese groben Werte gekommen.
Wenn ich mich im grünen Bereich bewege (auch mit internen Taktraten) - fühle ich mich sicher https://cache.amobbs.com/bbs_upload782111/files_22/ourdev_508497.html Hatte bisher keine Probleme :-) Ansonsten: "Baudraten-Quarz" verwenden und noch sicherer sein ... (0 % Fehler)
Egal, wenn ich Quarze verwenden möchte, fehlen mir die kleinen Keramikkondensatoren, die da mit dran müssen. Es wäre nur gegangen wenn es ganz ohne Quarze zuverlässig funktioniert hätte. Das scheint mir nach euren Antworten hier aber ein größeres Abenteuer zu sein und ich glaube, darauf verzichte ich lieber. Da kaufe ich lieber die Teile und warte noch ein paar Tage bis die da sind.
Ben B. schrieb: > fehlen mir die kleinen > Keramikkondensatoren, die da mit dran müssen Ja, die kosten Unsummen - mindestens 1 - 2 Ct. pro Stück :-)
Ben B. schrieb: > Es wäre nur gegangen wenn > es ganz ohne Quarze zuverlässig funktioniert hätte. Siehe "grüner Bereich".
Beitrag #5545753 wurde von einem Moderator gelöscht.
Dieter F. schrieb: > Ja, die kosten Unsummen - mindestens 1 - 2 Ct. pro Stück :-) Milchmädchenrechnung. Da werden erst dreimal die falschen bestellt und hier in einem ellenlangen Thread die Werte geklärt, weil sie nicht zum Quarz passen (dessen genaues Datenblatt leider nicht vorliegt). Dann gehts noch mal ebensolang ums passende Layout wegen EMV und so. MfG Klaus
Nur weil ich gerade rein zufällig eine Schaltung mit einem PIC12F629 auf dem Tisch liegen habe: Er läuft mit dem internen 4MHz RC-Oszillator, kommuniziert zum PC mit 9600_8N1, ein DS1820-Temperatursensor ist angeschlossen -> läuft sehr gut, wie aus dem DB absehbar war. In einem anderen Projekt werden ein 12F629 (Sender) und ein 16F628 (Empfänger) in einer (Outdoor-)IR-Fernsteuerung (beide mit 4MHz-intern-Osc) verwendet, läuft sehr gut. Der Empfänger synchronisiert sich bei jedem Bitwechsel neu, das habe ich wegen des großen Temperaturbereiches so gemacht. An den 8-Bit-PICs habe ich bisher nur 32-KHz-Quarze an den Low-Power-Oszillator angeschlossen, wenn es um Uhrzeit o.ä. ging. mfG ffje
:
Bearbeitet durch User
Ben B. schrieb: > Und wie steht's um die Temperaturstabilität? Wo hast Du sie denn stehen? Wenn sie beide den gleichen Temperaturen ausgesetzt sind, laufen die RCs auch in die gleiche Richtung. Ich hab nen ATmega328 mit internen 8MHz mit 57600 Baud 8 Bit am PC hängen, geht. Hab aber keinen Temperaturgang getestet.
Das Schöne dabei ist doch: Der Controller läuft mit'm RC auch ohne Quarz, d.h. man kann schon losgelegt haben, bis Quarze und Kaps. da sind. Ob man die dann später noch einlötet oder nicht, kann man dann immer noch entscheiden.
Marc V. schrieb: > Laut ATMEL ergibt das zwischen 10°C und 40°C einen Fehler von max. > 0.6% Nur bei den neuesten Modelreihen, also denen mit der verbesserten Temperaturkompensation des RC-Oszillators. Und außerdem: Winter gibt's nicht in deiner Welt? Direkte Sonneneinstrahlung gibt's nicht in deiner Welt? Wir liefern aber z.B. Geräte, die einfach mal nur im Freien stehen. Die müssen da genauso mit den -35°C klarkommen, die es dort in einer klaren Winternacht geben kann als auch mit den +80°C, auf die sich das Gehäuseinnere im Hochsommer bei direkter Sonneneinstrahlung aufheizen kann. Da helfen nichtmal die durchaus lobenswert verbesserten Eigenschaften des RC-Oszillators in neuesten Modellreihen wirklich weiter...
c-hater schrieb: > Wir liefern aber z.B. Geräte, die einfach mal nur im Freien stehen. Die > müssen da genauso mit den -35°C klarkommen, die es dort in einer klaren > Winternacht geben kann Damit muß die Steuerung meiner Beregnung auch klarkommen, nur funktionieren muß sie nicht. Das Wasser ist da gerade gefroren. Und nur weil du so ein harter Kerl bist, der erst bei minus 40° den obersten Hemdknopf zumacht, muß das nicht für andere gelten. MfG Klaus
Warum nicht SPI benutzen? Okay, das sind drei Leitungen, aber bidirektional, einfach zu handhaben und der Takt kommt auch gleich mit...
Also ich hab das mal ausprobiert. Geht auf dem Labortisch wunderbar, nur im Klimaschrank bei -10°C läuft das nicht mehr. Mit Abgleich könnte das funktionieren, wirklich toll ist das aber nicht. Übrigens würde ich bei ein paar Metern schon eher auf symmetrische Leitungen gehen, zum Beispiel RS-422, oder RS-485. Zu den I2C und SPI-Leuten muss ich sagen, dass eine normale asynchrone serielle Verbindung den Vorteil hat, dass man es sehr viele leichter debuggen kann. Eine serielle Schnittstelle hat fast jeder PC.
Angehängte Dateien:
-
2018-09-04_205018.png
6,7 KB
c-hater schrieb: > Und außerdem: Winter gibt's nicht in deiner Welt? Direkte > Sonneneinstrahlung gibt's nicht in deiner Welt? > > Wir liefern aber z.B. Geräte, die einfach mal nur im Freien stehen. Die > müssen da genauso mit den -35°C klarkommen, die es dort in einer klaren > Winternacht geben kann als auch mit den +80°C, auf die sich das > Gehäuseinnere im Hochsommer bei direkter Sonneneinstrahlung aufheizen > kann. > > Da helfen nichtmal die durchaus lobenswert verbesserten Eigenschaften > des RC-Oszillators in neuesten Modellreihen wirklich weiter... Doch, könnte schon gehen, siehe Bild. Aber warum sollte etwas, das von -35°C bis +80°C funktionieren soll, sich auf internen RC-Oszillator verlassen ? Geiz ? Blödheit ?
Es gibt einen Weg, eine zuverlässige Kommunikation nur mit RC-Oszillator aufzubauen. Das wird beim LIN-Bus (mal googeln!) so gemacht. Die Methode geht so: 1. Alle Daten werden in kurzen Datenblöcken versendet. 2. Jeder Block beginnt mit einem BREAK, einer Folge von 0-Bits, die so lang ist, dass sie in einer normalen Übertragung nie auftreten kann. Das ist sozusagen das Aufwachsignal. 3. Danach kommt ein SYNC-Byte hex 55 oder AA. Das besteht aus einer Folge von 0 und 1 Bits. Damit kann der Empfänger die Bitrate ausmessen und anpassen. 4. Jetzt kommen die Daten mit CRC am Ende. Wenn der Block kurz genug ist, ändert sich die Frequenz des RC-Oszillators nur so wenig, dass der Empfang trotzdem noch möglich ist. Beim nächsten Block wird die Bitrate ja wieder ausgemessen. Die Automobilindustrie hat diesen Bus so gebaut, dass er möglichst billig zu implementieren ist. Einfach mal so als Anregung. fchk
Das wäre meine zweite-dritte Idee gewesen. Ein eigenes Protokoll zusammenbasteln und die Bits z.B. über die Pulsbreite zu kodieren. Das hätte bei langsamen Geschwindigkeiten eine sehr hohe Zuverlässigkeit, aber kann der µC nicht in Hardware. Und ja, um die Preise ging es mir wirklich nicht. Ich habe die Teile einfach nicht hier. Mich "stört" das Bestellen, nicht der Preis. Zu diesem Thema: Kennt jemand einen Laden, wo ich solche Kleinteile zusammen mit einem SIM800/900 GSM-Modul herbekomme? Normalerweise bestelle ich sowas bei Reichelt, aber deren Sortiment scheint immer schlechter zu werden. Weniger Teile, dafür höhere Preise. GSM-Module haben die z.B. nur als Arduino-Kacke für 70 Euro oder so. Das können die vergessen, soviel bezahle ich dafür nicht, schon gar nicht wenn ich nur das nackte GSM-Modul brauche.
Sind 10 Eur für SIM800 bei TME zuviel? https://www.tme.eu/de/details/sim800c32/m2m-gprshspalte-module/simcom/ Kondensatoren haben die auch soviele, dass sie die verkaufen müssen.
Beitrag #5546194 wurde von einem Moderator gelöscht.
Marc V. schrieb: > Aber warum sollte etwas, das von -35°C bis +80°C funktionieren soll, > sich auf internen RC-Oszillator verlassen ? Soll man ja eben nicht, genau darauf wollte ich hinaus.
Marc V. schrieb: > Aber warum sollte etwas, das von -35°C bis +80°C funktionieren soll, > sich auf internen RC-Oszillator verlassen ? Und warum soll man sein Hobbyprojekt für -35° bis +80° auslegen, wenn es nur in geheizten Innenräumen betrieben wird? MfG Klaus
Klaus schrieb: > Und warum soll man sein Hobbyprojekt für -35° bis +80° auslegen, wenn es > nur in geheizten Innenräumen betrieben wird? Hat doch keiner verlangt.
c-hater brauchte doch nur mal wieder was, an dem er sich hochziehen konnte. Was er stillschweigend dabei unter den Tisch fallen lässt: -35 °C ist eine Anforderung, bei der man sich auch bei der Quarzauswahl bereits umschauen muss, dass das überhaupt garantiert wird. Es gibt genügend Quarze, die nur bis 0 oder -10 °C hinab spezifziert sind.
Marc V. schrieb: > Laut ATMEL ergibt das zwischen 10°C und 40°C einen Fehler von max. > 0.6%, mit Oszillator kalibriert auf 1% Fehler, ist das ein > Gesammtfehler von max. 1.6%. Wenn der RC-Oszillator kalibriert ist. Ist er das ab Werk bei den neuen Typen? Hannes H. schrieb: > Warum nicht SPI benutzen? Okay, das sind drei Leitungen, aber > bidirektional, einfach zu handhaben und der Takt kommt auch gleich > mit... Oder I2C. Braucht nur zwei Leitungen, "nur" Halbduplex, aber mit Hardwareunterstützung und verfügbaren Bibliotheken eigentlich auch recht einfach aufzubauen. Den XCK-Pin mitzunutzen geht natürlich auch. Es gibt viele Möglichkeiten. Etwas neues erfinden oder sowas wie LIN oder CAN implementieren würde ich daher eher nicht :) MfG, Arno
Arno schrieb: > Wenn der RC-Oszillator kalibriert ist. Ist er das ab Werk bei den neuen > Typen? Ja.
Arno schrieb: > Wenn der RC-Oszillator kalibriert ist. Ist er das ab Werk bei den > neuen Typen? Ich weiß ja nicht, wie "neuere Typen" definiert sind. Letztens habe ich viel ATtiny25-20 verbaut, die im nagelneuen Zustand doch erhebliche Taktunterschiede aufwiesen. Aber auch ein nachträglichlicher Abgleich brachte kein zündendes Ergebnis. Bei der Anwendung geht es nur im LED-Blinkerei, weshalb es nur 'unschön' ist, wenn bei mehreren LEDs die Blinkfrequenz lustig auseinanderdriftet. Sofern die Platine noch ein bißchen Platz für Quarz oder keram. Resonator läßt, kommt dieser mit dazu. Das erspart im Zweifelsfall jede Menge vergeudete Zeit!
m.n. schrieb: > Sofern die Platine noch ein bißchen Platz für Quarz oder keram. > Resonator läßt, kommt dieser mit dazu. Gerade bei einem ATtiny25 dürfte es eher die Pinanzahl sein, die man sparen möchte denn der Platinenplatz.
Egal, Quarze sind bestellt. Ich hatte das Zeug halt einfach nicht da - und was macht man da? Man überlegt, wie man mit dem klarkommt, was da ist. Da lag der interne RC-Oszi nahe, aber das war mir nach den Antworten hier dann doch zu unsicher. Hab gleich ein paar Quarze (und passende Kondensatoren ;) ) mehr bestellt, so daß das Problem erstmal nachhaltig gelöst sein sollte.
Jörg W. schrieb: > Gerade bei einem ATtiny25 dürfte es eher die Pinanzahl sein, die man > sparen möchte denn der Platinenplatz. Und ich dachte Beides ;-) Aber ist der ATtiny25 denn nun den neueren Typen zuzurechnen? Ben B. schrieb: > Hab gleich ein paar Quarze (und passende Kondensatoren ;) ) mehr > bestellt, so daß das Problem erstmal nachhaltig gelöst sein sollte. Gut gemacht! ;-)
m.n. schrieb: > Aber ist der ATtiny25 denn nun den neueren Typen zuzurechnen? Bezüglich des RC-Oszillators: ja. Allerdings sind natürlich 1 % Frequenztoleranz zwar für RS-232 völlig OK, für irgendwelche Blink-Timings und deren Synchronität dagegen nicht: 1 % Abweichung heißt, dass beide nach reichlich 1,5 Minuten bereits um 1 Sekunde abgedriftet sind – im schlimmsten Fall sogar jeder von beiden in eine andere Richtung. Solche optischen Gimmicks sind daher, auch wenn man das auf den ersten Blick kaum vermutet, viel anspruchsvoller als das bisschen RS-232-Kommunikation.
Das war ja die ursprüngliche Überlegung, die ich hatte: Die Übertragung eines Bytes bei RS232 geht sehr schnell, daher hatte ich angenommen, der Fehler wirkt sich bei geringen Baudraten kaum aus. Aber wenn man bei der Zeitdehnung den Fehler mit-dehnt, bringen die niedrigen Baudraten leider nichts...
Ben B. schrieb: > der Fehler wirkt sich bei geringen Baudraten kaum aus Der Fehler ist relativ, insofern ist es völlig egal, ob die Baudrate gering oder hoch ist. Das Einzige an dieser Stelle ist, dass du mit dem Standardtakt des RC-Oszillators (meist 8 MHz) halt die „krummen“ Baudratenwerte wie 9600, 19200 etc. nur mit einem gewissen systematischen Fehler annähern kannst, und dass (bedingt durch die Granularität des Teilerfaktors) bei höheren Baudraten dann dieser systematische Fehler im Mittel größer ist als bei kleinen Baudraten (m.a.W.: kleine Baudraten lassen sich treffsicherer konfigurieren). Da der systematische Fehler plus die tatsächliche Abweichung die 2-%-Grenze erfüllen müssen, setzt dies für solche Standard-Baudraten und den unmodifizierten RC-Oszillator eine zusätzliche Grenze. Es ist vom Datenblatt immer garantiert, dass man den RC-Oszillator auf 7,37 MHz herunter justieren kann, dann hat man keinen systematischen Fehler mehr an dieser Stelle. Allerdings muss man sich dafür den Kalibrierwert für den RC-Oszillator selbst ermitteln. Wenn du nur zwei Controller miteinander kommunizieren lassen willst, hast du allerdings diesese Problem nicht, denn du bist nicht an diese „Standard“-Datenraten gebunden. Dann entscheidet nur die zufällige Abweichung der Oszillatoren, und damit ist die Sache unabhängig von der eingestellten Baudrate.
Ben B. schrieb: > Das war ja die ursprüngliche Überlegung, die ich hatte: Die > Übertragung > eines Bytes bei RS232 geht sehr schnell, daher hatte ich angenommen, der > Fehler wirkt sich bei geringen Baudraten kaum aus. Aber wenn man bei der > Zeitdehnung den Fehler mit-dehnt, bringen die niedrigen Baudraten leider > nichts... in der Praxis (physikalisch) verringern niedrige Baudraten lediglich den Wechselanteil mit den Pegeländerungen, also - relativ zur Übertragung - steilere Flanken und können damit schon eine (noch) sichere Übertragung bringen. Der Spezialfall in dem ein Experimentator mit LED-Blinken nicht vorher sein Thema "zündendes Ergebnis für schöne LED_Blinkerei ohne Synchronisation möglich?" erfragen konnte und aufgrund seines Unwissens wie "neuere Typen" und "erhebliche Taktunterschiede" definiert sind versehentlich seine Zeit! in einen "nachträglichlicher Abgleich" investieren musste kann aber auch beim Thema "RC-Takt genau genug für asynchrone Bitübertragung mit max.12-bit?" Nennwerte zur Veranschaulichung liefern. Bspw. "erhebliche Taktunterschiede" (Angabe(T1-T2)/T2=1% aus dem Platz über dem kopierten Text) korrekte LED-Blinkerei (T1):500mHz u.U. lustige Blinkerei (T2):505mHz (+1%) im simulierten Langzeittest über 3 Min T1:45,00 Blinks/bits T2:45,45 (u.U. Definition;"Blinkfrequenz lustig auseinanderdriftet"; konventionell Phasendrift/nach 3 Min praktisch Invertierung) Nach 12 Blinks/bits (Thema Rs232) T1:12,00 T2:12,12 (völlig problemlos) Viele Ir-Fernbedienungen kommen auch ohne dunkle Kristalle in Aluhütchen oder Porzellan-Schwingern klar, praktisch dürfte es bei den Rahmenbedingungen ähnliche Temperatur in 2m (kein µC liegt auf einer in praller Sonne geparkten Hutablage)/ ähnliche Spannung/... auch bei 12-bit keine Probleme geben, aber für 5-bit hat Atmel vor vielen Jahrn noch mal nachgerechnet und 6% für _zu_(!) "erhebliche Taktunterschiede" definiert/bzw. berechnet.
Dirk B. schrieb: > Viele Ir-Fernbedienungen kommen auch ohne dunkle Kristalle in Aluhütchen > oder Porzellan-Schwingern klar Kunststück... In jedem gebräuchlichen IR-Protokoll ist ja auch eine längere Sync-Sequenz vorgesehen, an der sich der Empfänger kalibrieren kann. Und seitdem die Empfänger praktisch ausschließlich µC sind, machen die das sinnvollerweise auch nahezu alle. Früher(tm) war das noch anders und dementsprechend hatte früher auch praktisch jede FB einen Resonator als Taktquelle.
c-hater schrieb: > Kunststück... In jedem gebräuchlichen IR-Protokoll ist ja auch eine > längere Sync-Sequenz vorgesehen, an der sich der Empfänger kalibrieren > kann. die Künstler aus der 3 Punkte-Generation, die noch keinen barriefreien Zugang ins Internet haben um bspw. sog. "längere" Sequenzen anhand von üblichen IR-Protokollen anhand der bits aus den Sequenzen abzuzählen zu können kommen sicherlich nicht auf Seiten wie: https://www.elv.de/elektronikwissen/die-wichtigsten-infrarot-codeverfahren.html > Und seitdem die Empfänger praktisch ausschließlich µC sind, machen die > das sinnvollerweise auch nahezu alle. Früher(tm) war das noch anders und > dementsprechend hatte früher auch praktisch jede FB einen Resonator als > Taktquelle. Die Früher(tm) Generation die keinen Zugang zu Opensource Quelltexten wie Irmp hat und auch keine Abweichung eines(!) Resonators in einer(!) FB angeben kann muss sich natürlich mit Ersatzwörtern beschäftigen. Dein Glaube an irgendwie längere Sync-Sequenzen beruht vermutlich darauf, dass es einige Protokolle gibt die als Präambel einen(!) Messwert und andere die in der Linecodierung eine Taktrückgewinnung ('Manchester')haben, aber wenn du Zugang zu Nennwerten bekommen solltest, dann könntest du auch die problemlos zuverarbeitenden Abweichungen bei den meist <<40 bit langen Sequenzen ablesen. Praktisch hast du bei 8n1 alle 10 bit(zeiten) Sync (20% Sync-Overhead;lt. Atmel Rmax. 3,5%) bei 5n1 alle 07 bit(zeiten) Sync (ca.40% Sync-Overhead;Rmax.6,5%) aber "Kunststück..." Produzenten dürften schnell ähnliche Schwierigkeiten bekommen wie der Experimentator der "jede Menge vergeudetet Zeit!" für den Versuch nach dem Verbauen von viel ATtiny25-20 einen sog. "Abgleich" durchzuführen investiert hat, weil er nicht vorher fragen konnte. Jeweils eine(!) kurze Nennwertangaben für ein Beispiel - "längere Sync-Sequenz": Länge in Bits/Zeichen/.. - "erhebliche Taktunterschiede": x% .... kann Kunststückhersteller zu Menschen machen die auch mit Nennwerten klar kommen.
m.n. schrieb: > Bei der Anwendung geht es nur im > LED-Blinkerei, weshalb es nur 'unschön' ist, wenn bei mehreren LEDs die > Blinkfrequenz lustig auseinanderdriftet. Ist das nicht das Verfahren (Schwebung) um mit einfachsten Mitteln geringste Frequenzunterschiede zu erkennen? MfG Klaus
m.n. schrieb: >>Jeweils *eine*(!) kurze Nennwertangaben für ein Beispiel - "erhebliche Taktunterschiede": x% >>kann Kunststückhersteller zu Menschen machen die auch mit Nennwerten klar kommen. > Stimmt, [mehrere] Drogen können schädlich sein. Deine Erfahrung mit Drogen könnten zumindest die Schwebungen - "erhebliche Taktunterschiede" (u.U. durch die Substanzen vergessener erheblicher Nennwert) - "zündendes Ergebnis"(u.U. durch die von dir überprüfte schädliche Wirkung) - "nachträglichlicher Abgleich"[für zündendes Erlebnis](u.U. schädliche Zeitwirkung auf den Ausgebenden) plausibel erklären, aber nicht warum du deine Erfahrung mit Drogen bei µC-net bekanntgeben musstest. Bei so vielen Drogen als Alternative zu Nennwerten gehen natürlich Vergleichsdaten zur Frage "RC-Takt genau genug für RS232?" schnell verloren. Falls Du einmal neben der jeden Menge an vergeudeter Zeit für einen "Abgleich" aus LED-Blinkerei und Deinen sonstigen Erfahrungen mit Drogen etwas zur Frage suchen solltest, dann noch mal kurz die Erfahrung/Berechnung von Atmel ("genau genug"/alle Bits werden zeitlich richtig gemessen) 8n1 (10 bit brutto)(20% Sync-Overhead;genau genug max. 3,5%) 5n1 (07 bit brutto)(ca.40% Sync-Overhead;genau genug max. 6,5%)
Da ich gerade ein paar Tiny25 verwurschtelt habe, hier die Abweichungen bei 13 Stück "Gesamtmenge". 8 Stück +/-1% 4 Stück ca. +2% 1 Stück -2,5% Für RS232-Anwendungen ist mir das nicht ausreichend genau.
Ben B. schrieb: > Naja mal sehen ob > ich noch zwei Baudratenquarze habe. Statt der Löterei paß ich einfach die Taktenratenkonstante F_CPU (C-Macro) an den tatsächlichen RC-Takt genauer an. Bei konstanter Spannung und grob Zimmertemperatur hatte ich damit noch nie Probleme. 100 Sek. LED-Licht o.ä. programmiern, mit der Stoppuhr die Abweichung messen und auf die F_CPU rechnen, fedsch. Das Baudratenmacro berechnet daraus automatisch die passenden Registerwerte.
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.