Hallo , ihr wissende. Ich stehe im Moment ganz tief im Wald mit einem Problem. Ich habe einen Mega48, der Taster abfragt. Je nach gedrückter Taste sendet der M48 einen String an den Tiny2313. Der Tiny führt einen Befehl aus und sendet einen String an den M48 zurück, der eine LED umschaltet. Soweit die Theorie. Ich habe sowohl den M48 als auch den Tiny2313 über einen MAX232 an den PC angeschlossen und mir mit dem Terminal den Datenfluss angesehen. Jeder µC für sich funktioniert, wenn das Terminal den anderen Controller simuliert. Naiv , wie ich bin, habe ich dann beide Controller miteinander verbunden (Rx1 --> Tx2) (Tx1 --> Rx2). Ergebnis -nichts passiert-. Ist wahrscheinlich wieder was ganz banales, aber kommen muss man erst drauf. Ich habe die beiden Programme mit angehängt. Nicht wundern, später soll der M48 mit mehreren Tinys kommunizieren. Aber bevor es mit einem nicht klappt, brauche ich es mit mhreren erst gar nicht zu probieren. Schaltplan gibt es noch nicht, ist alles auf dem Brotbrett. Aber wer den Kopfkommentar der Listings liest, kann sich bestimmt ein Bild machen. Falls jemand die Kettensäge hat, um Licht in den dunklen Wald zu bringen, ich würde mich sehr darüber freuen. Deka65
Gast
#4317371
>Nicht wundern, später soll der M48 mit mehreren Tinys kommunizieren. >Aber bevor es mit einem nicht klappt, brauche ich es mit mhreren >erst gar nicht zu probieren. Input ist blockierend, das wird wohl mit mehr als 2 MCs so nicht gehen. Dafür gibt es in Bascom aber nichtblockierende Alternativen wie ich gesehen habe. Hier mit deinen 2 MCs ist es aber wohl nicht der Grund für das Nichtfunktionieren. Wenn ich mit Bascom arbeiten würde, wäre für mich das Bascom Forum die erste Anlaufstelle und erst wenn es da nicht weiter geht würde ich hier aufschlagen.
Gast
#4317381
Detlef K. schrieb: > Aber wer den Kopfkommentar der Listings liest, kann sich bestimmt > ein Bild machen. Die interne Taktfrequenz taugt nicht für stabilen UART-Betrieb. Mehr sollte ich ja nicht lesen ;-)
Hallo, @ bastler Das Input blockierend wirkt, weiß ich. Es ist sogar gewollt. Es soll erst was anderes gemacht werden, wenn ein Vorgang ab- geschlossen ist. Ich weiß, das auch hier viele Bascom'er unterwegs sind. Es geht hier auch um Microcontroler. deka65
Hallo. m.n. schrieb: > Mehr sollte ich ja nicht lesen ;-) das bezog sich nur auf den nicht vorhandenen Schaltplan (den Smilie habe ich auch gesehen)!! Also werde ich mich mal nach Baudratenquarzen umsehen und probieren. Schön wäre es ja, wenn damit das Problem erschlagen ist. deka65
Gast
#4317491
Detlef K. schrieb: > Also werde ich mich mal nach Baudratenquarzen umsehen und probieren. Die brauchst Du nicht! Mit 8, 16 oder 20 MHz kann man auch schnelle Baudraten mit hinreichender Genauigkeit erreichen. Den Quellcode habe ich mir deshalb nicht weiter angesehen, da mir Struktur und Kommentare fehlen.
Gast
#4317499
m.n. schrieb: > Die brauchst Du nicht! Mit 8, 16 oder 20 MHz kann man auch schnelle > Baudraten mit hinreichender Genauigkeit erreichen. Huch? Nur mit sehr gewagten Definitionen von "schnelle Baudraten" und "hinreichende Genauigkeit"... Was tatsächlich erreichbar ist, steht für alle Dödels, die zu blöd sind, das selbst auszurechnen, freundlicherweise im Datenblatt eines jeden AVR mit USART als Tabelle abgedruckt. Das einzige, was man dazu noch wissen muss, ist: alles über 2% ist völlig indiskutabel, alles über 1% vielleicht gerade so erträglich, aber nur dann, wenn nicht noch andere Gegenidikationen bestehen, z.B. ein ungenauer Systemtakt. Dessen Fehler kommt nämlich zum systematischen noch dazu...
Gast
#4317518
c-hater schrieb: > Huch? Nur mit sehr gewagten Definitionen Ja, heute nach dem vielen Regen bin ich Softi ('weichgespült'). Ausgehend von den jetztigen 4800 Bd sind 500 kBd bei 8 MHz mit 0% Abweichung doch schon recht schnell, wenn nicht sogar schon zu schnell. Dein ABER kannst Du Dir verkneifen ;-) Du kannst aber Deinen Assembler-Code zur Lösung beitragen, da dieser unter BASCOM sehr gut zu integrieren ist. AVR-GCC macht dagegen richtig Streß ;-)
Gast
#4317538
m.n. schrieb: > Ausgehend von den jetztigen 4800 Bd sind 500 kBd bei 8 MHz mit 0% > Abweichung doch schon recht schnell, wenn nicht sogar schon zu schnell. Du vergißt: Kommunikation macht nur Sinn, wenn man einen Partner hat. Die Gegenstellen, die 500kBd verstehen, sind relativ rar... Natürlich kann man mit solchen "schrägen" Baudraten innerhalb eines proprietären Systems hervorragend agieren, aber der Kontakt zur normierten Außenwelt ist dann schwierig bis unmöglich.
c-hater schrieb: > Du vergißt: Kommunikation macht nur Sinn, wenn man einen Partner hat. > Die Gegenstellen, die 500kBd verstehen, sind relativ rar... Wenn er zwei µC unter seiner Kontroller via UART verbinden möchte, dann ist genau das gegeben. Siehe Ursprungspost.
Gast
#4317907
c-hater schrieb: > Du vergißt: Kommunikation macht nur Sinn, wenn man einen Partner hat. > Die Gegenstellen, die 500kBd verstehen, sind relativ rar... Gerade das solltest Du Dir doch verkneifen! Standard Baudraten - vom PC vorgegeben - sind doch sowieso nicht mehr das Maß der Dinge. Mit aktuellen USB-RS232-Adaptern kann man auch 500 kBd einstellen.
Hallo, vielen Dank für die rege Diskussion. Ich bin in der Zwischenzeit , was Quarze betrifft, fündig geworden. In meiner Kiste mit Quarzen langweilen sich noch ein paar mit 9,8504 MHz. Die werde ich mal einbauen und sehen, ob die Verständigung unter den Controllern dann funktioniert. Sollte es dann immer noch Probleme geben, ist der Fehler dann wahrscheinlich in der Software zu suchen. Wie der Kaiser schon sagte "schau 'mer mal". Gruß deka65
Hallo, ich habe in der Zwischenzeit de Quarze eingebaut, die Fuses eingestellt und die Programme neu geflasht. Leider jauchse ich noch nicht vor Euphorie. Bei der direkten Verbindung beider Controller passiert folgendes. Beim Druck auf den 1. Taster ändert sich nach kurzer Zeit die Ledfarbe von rot nach grün -so wie gewünscht-. Beim Druck auf die 2. Taste, die letztendlich die Led wieder umschalten soll, passiert nichts mehr. Jeder Controller für sich funktioniert über Terminal so, wie es soll. Ich vermute also, das der Fehler in der Software beim Zusammenspiel beider Programme liegt. Ich habe auch schon ECHO ausgeschaltet, damit die gesendeten Daten nicht hin und her geschickt werden. m.n. schrieb: > Den Quellcode habe ich mir deshalb nicht weiter angesehen, da mir > Struktur und Kommentare fehlen. Ich habe die Programme nach "bestem Wissen und Gewissen" geschrieben. Es sollte auch so universell wie möglich sein, da damit mehrere Aufgaben erfüllt werden können. Es soll auch ein Laie dem Controller eine Adresse zuweisen können. Mir reichen jedenfalls die angeführten Kommentare. Es sollte ja keine Dissertation werden. ;-) Gruß deka65
Hallo, falls das ein Admin oder Moderator liest, bitte ich , diesen Thread komplett zu löschen. Das von mir angestoßene Thema hat im Forum keine Interesse geweckt, wie an Hand der Beteiligung zu sehen. Ausserdem nimmt es nur Speicher weg. Es sind auch keine Erkenntnisse, die erhaltenswert sein würden. Außer, das interne Oszillatoren keine stabile Baudrate generieren, das ist aber schon ein alter Hut, gibt es nichts Erhaltenswertes. Vielleicht liegt es aber auch im Trend der Zeit. Bastler schrieb: > Wenn ich mit Bascom arbeiten würde, wäre für mich das Bascom Forum die > erste Anlaufstelle und erst wenn es da nicht weiter geht würde ich hier > aufschlagen. Du bist nicht von Hier (Bascom) Du sprichst nicht mal unsere Sprache ( C ) Also geh woanders hin. Also , wenn jemand berechtigt ist und es kann, dann den Thread löschen. deka65
Hast du schon die Kommunikation zwischen den beiden Controllern mitgeschnitten? (Also entweder mit nem Oszi, LA oder 2 Schnittstellen am Rechner + entspr. Software). Wenn die richtigen Zeichen über UART gehen, dann bleibt dir nicht viel anderes übrig als das Programm weiter via LED zu Debuggen. Ich hab leider noch nie praktisch mit Bascom zu tun gehabt. Aber ich probiere trotzdem mal ein paar Gedankengänge: "Input Bef NoEcho" hast du auch schon probiert wie ich gemeint gelesen zu haben? Desweiteren meine ich gelesen zu haben unter: http://avrhelp.mcselec.com/index.html?input.htm
1 | |
2 | |
3 | |
Aber da es hier ja irgendwie keine Probleme gibt, wenn das über das Terminal vom Rechner aus geschickt wird, wird es das wohl nicht sein. Mein nächster Tip wäre, dass "Print" ja üblicherweise CR und LF mit anhängt (es sei denn, es wird mit ";" beendet). Aber auch ein PC würde, je nach Konfiguration des Terminals, mindestens LF schicken. Daher wirds das wohl auch nicht sein.
Hallo, das Problem hat sich in der Zwischenzeit gelöst. Ich kann jetzt über UART zwischen den zwei Controllern kommunizieren. Das Problem bestand im PRINT Befehl. deka65
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.