Guten Morgen! Ich arbeite jetzt wieder am RS485-Bus, bei dem mir der User ms vor zwei Jahren sehr geholfen hat. Leider funktioniert er immer noch nicht wie gewünscht. Kurz zum Aufbau des Busses: Vier Mega328 kommunzieren über RS-485 mit max485 als Bustreiber. Ein Master und drei Slaves. An den Slaves hängen ein paar Taster und Aktoren und die Kommunikation wird über den Master gesteuert. Zum Einsatz kommt hier die 9 Bit Usart im MPCM-mode. Der RS-485 wird als zweileiter-Bus betrieben. Zum Problem: Wenn der bus nach dem Einschalten angeht, die Betonung liegt auf wenn, dann funktioniert er einwandfrei für Stunden, Tage, Monate, in den meisten Fällen tut er das aber nicht. Alle Teilnehmer werden über ein Labornetzteil gespeist und somit gleichzeitig eingeschaltet. Man muss teilweise bis zu 10-Mal und öfter Einschalten, bis er endlich angeht. Der Bus startet mit einer Blinksequenz von Leds. Drei Sekunden nach dem Einschalten sendet der Master an jeden Slave das Kommande seine Led einmal kurz blinken zu lassen. Das gewünschte Verhalten wäre dann, dass jeder Slave der Reihe nach seine Led kurz blinken lässt. In den meisten Fällen blinkt aber nur die Led vom ersten Slave (0x44) und das wiederholt sich ständig. Ich habe bereits sehr viel an den timings gearbeitet und verschiedenste Controller im Einsatz gehabt. Das Problem dürfte aber am Master liegen. Interessant ist, dass verschiedene Controller als Master hierbei unterschiedliches Verhalten zeigen. Während ein Mega48 hier besseres Verhalten beim Einschalten zeigt, benötigen hier die größeren Brüder Mega88, 168, 328 deutlich mehr Einschaltvorgänge, bis der Bus richtig angeht. Weiters hatte ich einen Nano(mega328) getestet, der nahezu immer sofort richtig anging. Leider ist das nur bei diesem einen der Fall. Was ist bei diesem einen Nano anders, als bei den anderen von mir getesteten?. Würde vielleicht ein "besseres" Board, wie zb. ein Xplained mini mit genauerem Quarz helfen? Was ich noch herausgefunden habe, da ich gestern noch einen Uno getestet habe, wenn ich nach dem Programmieren den ISP-Programmieradapter am Controller angesteckt lasse, geht er ebenfalls immer an. Warum? Im Anhang habe ich die wesentlichen Schaltplanteile sowie den vollständigen Code für jeden Teilnehmer bereit gestellt. Vom Schaltplan her habe ich nur den Master und einmal die Busanbindung rausgenommen, da alle anderen Teilnehmer identisch sind. Die Failsave-Widerstände kommen nur einmal vor und die Abschlusswiderstände beim Master und beim letzten Slave. Vielleicht könntet ihr euch das mal ansehen. Wenn noch etwas fehlt, bitte einfach melden. wäre vielleicht jemand bereit, mir bei der erstellung einer Timeout-Funktion zu helfen. Laut ms sollte diese noch in den Code mit rein. Über eure Hilfe würde ich mich sehr freuen. @ms, wenn Du das liest, wäre es toll, wenn Du mir nochmal helfen könntest. Grüße mw73
Angehängte Dateien:
-
mega328p.JPG
72 KB -
rs485.JPG
38 KB
Wo ich am Port JP2 nur zwei Signale lese, die erste Klassikerfrage: Ist GND mitverdrahtet? Wenn nicht: Die heissen Diskussionen darüber tauchen hier immer wieder auf, und der Fazit ist immer: Ohne Rückflusskanal ist ein Differentialsignal für die Katz und reine Glücksache, ob's läuft.
Versuchs mal mit 2x 0R in A und B (R5, R6). Wenn du Probleme mit EMI hast, nimm die passenden Transceiver..
Markus W. schrieb: > Alle Teilnehmer werden über ein Labornetzteil gespeist und somit > gleichzeitig eingeschaltet. Man muss teilweise bis zu 10-Mal und öfter > Einschalten, bis er endlich angeht. Echte Gleichzeitigkeit gibt es nicht - hat Einstein schon festgestellt. Haben deine Slaves genug Zeit(-reserve) zum Starten, bevor der Master mit seiner Abfrage los legt?
Starten die Slaves überhaupt zuverlässig? füge mal am Anfang deines Programmes etwa dies ein:
1 | int main() |
2 | {
|
3 | // PB0 kurz blinken
|
4 | DDRB |= 1; |
5 | PORTB |= 1; |
6 | _delay_ms(500); |
7 | PORTB &= ~1; |
8 | _delay_ms(500); |
9 | PORTB |= 1; |
10 | _delay_ms(500); |
11 | PORTB &= ~1; |
12 | _delay_ms(500); |
13 | }
|
An-Aus-An-Aus Bei jedem Slave muss diese LED beim Einschalten dieses Blinkmuster zeigen. Wenn nicht, hat der Mikrocontroller nicht gestartet. Ursache dafür ist häufig das Netzteil. Wenn dessen Ausgangsspannung zu langsam ansteigt oder anfangs instabil ist, kann sich der Mikrocontroller aufhängen. In diesem Fall hilft eine Beschaltung des Reset Pins: https://www.mikrocontroller.net/attachment/9818/reset.gif Mit 10k Ohm und durchaus bis zu 100µF als Kondensator. Allerdings stört der Kondensator die ISP Schnittstelle, sollte daher durch einen Jumper abtrennbar sein.
Wolfgang schrieb: > Haben deine Slaves genug Zeit(-reserve) zum Starten, bevor der Master > mit seiner Abfrage los legt? Markus W. schrieb: > Drei Sekunden nach dem > Einschalten sendet der Master an jeden Slave das Kommande seine Led > einmal kurz blinken zu lassen Ich fürchte, da sind sie schon vor Langeweile wieder eingeschlafen... Konstruktiv: Wie sieht die GND-Verbindungen der Geräte untereinander aus?
Hallo Markus, LEDs sind ja schön und gut, aber am RO des MAX485 macht du dir mit der LED den Pegel den du mit dem Pullup erreichen willst wieder kaputt. Ich habe schon seit Jahren einen Bus mit 6 Geräten in Betrieb - ohne Probleme, und das obwohl die meisten Geräte eigene Stromversorgung haben und auch mal einzeln abgeschalten werden. Sascha
Stefanus F. schrieb: > Bei jedem Slave muss diese LED beim Einschalten dieses Blinkmuster > zeigen Ich würde das noch erweitern: jeder Slave sollte einen Power-On-Selftest machen und das mit seiner LED anzeigen, im Betrieb wäre eine Anzeige des Link-Status auch nicht verkehrt. Ist nach dem Start der Transmitter des Masters aktiv, die der Slaves nicht? Und funktioniert das Timing der Richtungsumschaltung? Georg
Vielen Dank für die schnellen Antworten. Ich bin gerade am Testen und habe folgendes versucht: Spielt das Mitführen von GND hier eine Rolle, der Aufbau befindet sich am Steckbrett und alles wird vom gleichen Netzteil versorgt. Ich habe aber mal alle GND-Anschlüsse von den Max485-Bausteinen miteinander verbunden, obwohl es hier eher sinnlos ist. Hat auch nichts gebracht. Mir ist klar, dass es normalerweise erforderlich ist, wenn zb. von verschiedenen Spannungsquellen gespeist wird. Die Widerstände R5 und R6 hab ich mit Brücken ersetzt, hatte aber auch keinerlei Auswirkungen gezeigt. Die Slaves sollten ausreichend Zeit zum Starten haben 200ms nach den Initialisierungen und zusätzlich 3s bis der Master seine Kommandos startet. @Stefanus - das werde ich nachher gleich testen. Grüße mw73
Nochmal eine Frage meinerseits: Der Bus befindet sich ja auf dem Steckbrett. Ist hierfür eine gesonderte GND-Verbindung erforderlich? > LEDs sind ja schön und gut, aber am RO des MAX485 macht du dir mit der > LED den Pegel den du mit dem Pullup erreichen willst wieder kaputt. Das hab ich auch befürchtet. Leider ist es aber nicht das Problem, bzw. führt eine wegnahme der Leds zu keiner Verbesserung des Einschaltverhaltens > Ich habe schon seit Jahren einen Bus mit 6 Geräten in Betrieb hättest Du hierzu noch Tips für mich? > Und funktioniert das Timing der Richtungsumschaltung? Ich kann nur sagen, dass es zumindest im Betrieb funktioniert. mfg Markus
Ich sehe neben der flasch angeschlossenen RX Led (die gehört active Low, sonst sieht man nix bei UART) auch eine fragwürdige Busanbindung. Die 47R Serienwiderstände sind verdammt groß dimensionert, insbesondere verglichen zum 50 Ohm Busabschluss (2*100R parallel). Da kommt doch eine Busspannung raus die nur noch knapp über dem Limit liegen dürfte. Abhilfe: RX-LED auslöten oder auf active Low umlöten, Serienwiderstände überbrücken oder auf 1..10R umstellen. Sourcen als RAR schaue ich mir nicht an, das löst bei mir ein "insert Coin" aus.
Jim M. schrieb: > Sourcen als RAR schaue ich mir nicht an, das löst bei mir ein "insert > Coin" aus. Bei über 500kB muss da wohl mehr drin sein, als der Quellcode für ein paar blinkende LEDs ;-)
Danke Jim für Deinen Beitrag! > Ich sehe neben der flasch angeschlossenen RX Led (die gehört active Low, > sonst sieht man nix bei UART) auch eine fragwürdige Busanbindung. Der Bus befindet sich am Steckbrett und die hab ich bereits weg gemacht. Hat aber nichts gebracht. > Abhilfe: RX-LED auslöten oder auf active Low umlöten, Serienwiderstände > überbrücken oder auf 1..10R umstellen. alles bereits gemacht, leider ohne Erfolg > Sourcen als RAR schaue ich mir nicht an, das löst bei mir ein "insert > Coin" aus. ich habe mal die Sourcen vom Master angehängt Die "main" ist RS485_Master.c Der Masterservice enthält eine State-machine, die über eines Status die zu sendenden Daten festlegt. RS485 ist für die Kommunikationssteuerung und crc16 eben für die Checksumme Der Rest ist fürs lcd Grüße Markus
> Bei über 500kB muss da wohl mehr drin sein, als der Quellcode für ein > paar blinkende LEDs ;-) ...aber um Dich zu beruhigen handelt es sich hier um den gesamten Atmel Studio Projektordner, incl. aller Busteilnehmer und der Kompilate als Debug sowie Release. Markus
- Failsafewiderstände unbedingt raus! Allerhöchstens nur bei einem Busteilnehmer drin lassen! - Serienwiderstände raus, ansonsten allerhöchstens 10 Ohm! Wenn EMV Stress -> Slewratelimited Treiber verwenden! - GND Mitführen Lektüre von TI: Bulletproof RS485 Werner
Deine I2C Sachen haben dieses unrühmliche
1 | while((TWCR & (1 << TWINT)) == 0); |
drinnen. Wenn ein I2C-Device den Bus lahm legt, was es übrigens darf, dann steht auch deine Software. Vielleicht hier auch mal suchen.
> - Failsafewiderstände unbedingt raus! Allerhöchstens nur bei einem > Busteilnehmer drin lassen! Sind nur beim Master dran! > - Serienwiderstände raus, ansonsten allerhöchstens 10 Ohm! Hab ich bereits gebrückt, leider nichts gebracht. > - GND Mitführen HMM, Aufbau ist am Stecktbrett, wird alles vom gleichen NT versorgt. > while((TWCR & (1 << TWINT)) == 0); > drinnen. Wenn ein I2C-Device den Bus lahm legt, was es übrigens darf, > dann steht auch deine Software. Vielleicht hier auch mal suchen. Diesen Verdacht hatte ich auch schon. Macht aber bei meinem Problem keinen Unterschied Danke für eure Beiträge!
Hallo, wenn du ein Oszi hast solltest du mal einen Versuch machen ob das reine Umschalten von Empfang auf Senden einen Pegelwechsel aud dem RS485-Bus verursacht oder nicht. Das Problem ist, dass ein unerwünschter Pegelwechsel beim Umschalten den Start eines Zeichens vortäuschen kann und damit mindestens das erste gewollte Zeichen verloren geht (bzw verfälscht). Abhilfe schafft hier nur den "Hardware-Fehler" (Pegelwechsel) beseitigen oder nach dem Umschalten mindestens eine Byte-Länge warten und dann erst mit dem Senden beginnen. So ermöglicht man dem Empfänger in jedem Fall eine Synchronisation auf den wahren Zeichenanfang. Gruss
Das Bulletproof RS485 von TI kannte ich bereits, hab es aber nochmals gelesen. Es hat aber auch keine neuen Erkenntnisse gebracht. Mit den Bias-Widerständen hab ich eigentlich genug experimentiert und sämtliche Werte durch - auch mehrmals. Ich probiere jetzt mal die Reset-Beschaltung und die Blinkmuster für die Slaves, wie Stefanus das vorgeschlagen hat.
Hallo Stefan, Danke für den interessanten Ansatz > Abhilfe schafft hier nur den "Hardware-Fehler" (Pegelwechsel) beseitigen > oder nach dem Umschalten mindestens eine Byte-Länge warten Dafür ist im Modul RS485.c folgende Vorkehrung:
1 | ISR(USART_TX_vect) // Leztes Byte wurde gesendet |
2 | {
|
3 | NetSetTxEnable(false); |
4 | NOP; |
5 | NOP
|
Ein doppeltes NOP sollte doch reichen,oder? Markus
@Stefan, was wäre in diesem Fall eigentlich ein Hardware-Fehler? Markus
Hallo, ich sollte mich besser Stefan_123 nennen denn ich hab gesehen da ist noch ein Stefan. Nein, 2 NOPs reichen nicht! Es muss wirklich mindestens eine Byte-Länge sein. Also bei 9k6 mindesten eine Millisekunde, das sind bei 1MHz Clock etwa 1000 NOPs. Du musst bei einem fälschlichen Start eines Zeichen sein fiktives Ende abwarten, erst dann ist der "getäuschte" Empfänger wieder bereit. Aber noch was anderes. Was willst du an den LEDs in den Datenleitungen sehen, die gehören da nicht hin, das ist Unsinn und verfälschen dir höchstens das Signal, kein Informationsgewinn. Gruss
Markus W. schrieb: > Ein doppeltes NOP sollte doch reichen,oder? Rechne doch mal aus wie lange ein Byte (8 Bit + Start- und Stoppbit) braucht. Bei 9600 Baud sind das: 1/(9600/10) = ~1,05ms Laeuft dein uC mit 16MHz sind ein NOP aber nur 62,5ns. Heisst: Du brauchst 1,05ms/0,0000625s = 16800 NOPs um eine Bytelaenge abzuwarten.
Kaj schrieb: > Du > brauchst 1,05ms/0,0000625s = 16800 NOPs um eine Bytelaenge abzuwarten. Es muss natuerlich 1,05ms/0,0000625ms heissen.
Hallo, Markus W. schrieb: > @Stefan, was wäre in diesem Fall eigentlich ein Hardware-Fehler? Ich hab jetzt nicht nachgerechnet oder sonst was, aber wenn z.B. die LED-Beschaltung in der TX-Leitung den Ruhepegel der TX-Leitung verändert dann wäre das ein Hardware-Fehler. Denn dann hab ich beim Umschalten von Empfang auf Sendung automatisch auch eine Änderung des Ruhepegels auf dem RS485-Bus. Aber wie gesagt, ich weiss nicht ob sie das tut oder nicht. Gruss
Stefanus F. schrieb: > In diesem Fall hilft eine Beschaltung des Reset Pins: > > https://www.mikrocontroller.net/attachment/9818/reset.gif @Markus W.: Ergänzend oder alternativ: Hast du die Brown-out-Fuses passend eingestellt, um einen sicheren Reset zu garantieren?
> Abhilfe schafft hier nur den "Hardware-Fehler" (Pegelwechsel) beseitigen > oder nach dem Umschalten mindestens eine Byte-Länge warten also ein wait einbauen - in die ISR? Ich muss trotzdem noch einmal betonen, dass die Probleme nur beim Einschalten vorliegen. Geht der Bus erst an, arbeitet er wie gewünscht. > Ich hab jetzt nicht nachgerechnet oder sonst was, aber wenn z.B. die > LED-Beschaltung in der TX-Leitung den Ruhepegel der TX-Leitung verändert > dann wäre das ein Hardware-Fehler Die Leds hab ich bereits entfernt, hat aber das Problem nicht gelöst. Grüße Markus
Was ist denn nun mit der Stromversorgung und dem Reset?
Hallo, mach mal die frei gewordenen LEDs in die Sendeumschaltung von Master und den Slaves, dann weisst du zumindest wer gerade Senden will. Vielleich blockiert ja einer und den Bus. Gruss
Stefanus und Stefan_123 ich musste kurz weg, teste das aber gleich und melde mich dann zurück Grüße
Was irgendwie zu fehlen scheint ist ein Protokol. Bei so einem Bus muss man irgend einen Teilnehmer irgendwann ausschalten koennen, irgendwann einschalten koennen, ohne die Anderen zu beeinflussen. Alles andere ist Quatsch.
So, die Reset-Schaltung ist erledigt, jedoch hat sich nichts
wesentliches verändert.
Das einzige, was Wirkung zeigte, war der Tausch auf eine andere
Spannungsquelle. Hierfür hab ich statt dem Netzteil eine große 6V
Batterie genommen (Mit ein paar Dioden in Serie).
Es funktioniert zumindest die Blinksequenz auf Anhieb. Dafür geht der
Bus hinterher meistens aus - war aber auch nur ein Test.
Die Slaves gehen alle verlässlich an, hab ich mittels Led getestet.
Die initialisierungszeit beim Master hab ich um 100ms verlängert.
Hat aber auch nichts gebracht.
Als nächstes hänge ich die freien Leds in die Sendeumschaltung wie von
Stefan_123 vorgeschlagen.
> Was irgendwie zu fehlen scheint ist ein Protokol
hast Du eines, das Du mir zeigen kannst?
Grüße Markus
>> Was irgendwie zu fehlen scheint ist ein Protokol >hast Du eines, das Du mir zeigen kannst? Ja. sicher. Also. -Die Slaves machen von sich aus nichts, sind auf Empfang. -Der Master ist auch auf Empfang ausser wenn er sendet. (*) -Jede Kommunikation wird vom Master initiiert. -Die Slaves sind adressiert, jede Meldung ist adressiert. -Der Master sendet eine Anfrage, die adressierten Slaves antworten immer. -Der Master wartet mit einem Timeout auf eine Antwort, wenn nichts kommt kann er repetieren oder vergessen. Allenfalls, wahlweise - kann jedes Packet mit einem CRC gesichert werden. (*) Default auf Empfang bedeutet ein 2.Master kann existieren. Zb Zu Debugzwecken. Uebergeordnet. Die Slaves werden der Reihe nach abgefragt. Die Zykluszeit richtet sich nach der gewuenschten Reaktionszeit. Was noch zu tun waere .. es kommt ein neues Geraet an den Bus. Ist auch machbar.
:
Bearbeitet durch User
Hallo, jetzt noch eine Sache die man bei Startproblemen immer mal versuchen sollte ist zu testen ob der Oszillator auch sicher anschwingt. Oder anders gesagt: - bei Oszillatorproblemen empfielt sich ein 1MOhm Widerstand parallel zum Quarz. Wird heutzutage gern weggelassen aber mal ausprobieren, schaden tuts nicht. Gruss
Guten Morgen, @Zitronen F > Ja. sicher. Also. > -Die Slaves machen von sich aus nichts, sind auf Empfang. > -Der Master ist auch auf Empfang ausser wenn er sendet. (*) > -Jede Kommunikation wird vom Master initiiert. > -Die Slaves sind adressiert, jede Meldung ist adressiert. > -Der Master sendet eine Anfrage, die adressierten Slaves antworten > immer. > -Der Master wartet mit einem Timeout auf eine Antwort, > wenn nichts kommt kann er repetieren oder vergessen. Danke für die Info aber hast Du einmal einen Blick auf den Code geworfen. Bis auf die Timeout-Funktion ist alles genau so, wie Du es beschrieben hast. Der Bus funktioniert ja bis aufs Einschalten sehr gut. Ich weis aber nicht, wie ich die Timeout-Funktion realisieren kann, bzw. welche Zeiten ich verwenden müsste - könnte das ein Grund für die Einschaltprobleme sein? @Stefan_123 Danke für den Tipp, auch das werde ich anschließend testen. > - bei Oszillatorproblemen empfielt sich ein 1MOhm Widerstand parallel > zum Quarz. Die 22pico Kerkos bleiben ober, oder? -Das war auch eine meiner Fragen zu Beginn, ob es am Oszillator/Controller liegen könnte, da sich auch unterschiedliches Verhalten mit verschiedenen Controllern als Master gezeigt hat. Ein Mega48 geht nach 2-3Mal Einschalten, während größere Controller wie der168 oder 328 zwischen 5 und 20 Versuche benötigen. -Sind die Standard HC-Quarze überhaupt ausreichend geeignet? -Sollte ich überhaupt als Master ein Board wie zb das Xplained mini verwenden? - Würde sich ein Arduino due als Master eignen? Wie würde denn eine Codeanpassung bzw. Programmierung dessen aussehen? - Noch eine ganz wichtige Frage, deren Grund für mich unverständlich ist: Warum geht der Bus immer nach dem Programmieren des Masters verlässlich an, und zwar so lange, bis ich den Programmieradapter abstecke? Für Antworten wäre ich sehr dankbar! Grüße Markus
Markus W. schrieb: > - Noch eine ganz wichtige Frage, deren Grund für mich unverständlich > ist: > Warum geht der Bus immer nach dem Programmieren des Masters verlässlich > an, und zwar so lange, bis ich den Programmieradapter abstecke? Die Antwort nach dieser Frage würde ich zuerst suchen. Was passiert, wenn du mal nur den Master zurücksetzt und neu startest?
> Was passiert, wenn du mal nur den Master zurücksetzt und neu startest?
Ist der Bus nach dem Einschalten korrekt angeggangen, kann ich beim
Master einen Reset ausführen. Der Bus startet mit der Blinksequenz an
jedem Slave erneut und das nach jedem Reset.
Schalte ich den Bus ein, dieser läuft aber nicht wie gewollt an (Die
Blinksequenz wiederholt sich immer beim ersten Slave) dann nutzt auch
ein Reset am Master nichts.
Grüße Markus
Ich habe das Gefühl, dass du nicht wirklich weißt, was deine Mikrocontroller im Störfall gerade machen. Mir ist auch sehr unklar was "der Bus geht an" bedeutet. Du solltest deine Gerät im Störfall mal ernsthaft Debuggen. Entweder mit einem Atmel ICE oder mit Hilfe von vielen Statusmeldungen, die über irgendeinen Pin seriell ausgegeben werden. Die kannst du dann mit einem Terminalprogramm auf deinem PC anzeigen. Es ist eine ganz schlechte Idee, jetzt auf komplexere Mikrocontroller zu wechseln. Denn dein problem wird dadurch sehr wahrscheinlich nicht auf magische Weise verschwinden. Und wenn doch müsstest du ständig fürchten, dass es wieder kommt denn du hast die Ursache noch nicht erkannt. Was die Quarze angeht: Ich war bisher davon ausgegangen, dass du fertige µC Module verwendet hast, wo man schon davon ausgehen kann, dass die Bauteile zusammen passen. Es ist auf jeden Fall so, dass nicht jeder Quarz geeignet ist und dass die Kondensatoren passend gewählt werden müssen. Die so oft genanten 22pF sind meistens Ok, aber eben nicht immer. Die Berechnung der korrekten Werte ist in dieser AppNote beschrieben: http://ww1.microchip.com/downloads/en/appnotes/atmel-2521-avr-hardware-design-considerations_applicationnote_avr042.pdf Bei Steckbrettern muss man z.B. noch die Kapazität der Steck-Kontakte subtrahieren. Hier läuft es mit 12pF oder ganz ohne Kondensatoren oft besser. Wichtig ist auch, dass die Leitungen an XTAL1 und XTAL1, sowie die Leitungen vom Kondensator zum GND-Pin des µC so kurz wie möglich sein müssen. Mehr als 2cm kämen mir da schon sehr verdächtig vor.
Hallo Hab deine Schaltung jetzt nicht genau studiert.. deshalb die Frage: Hast du am Bus-Ende einen Abschlusswiederstand eingebaut ? Gruß Günter
Sind hinreichend Kondensatoren verbaut worden ? Der Reset sollte ein 10k pullup mit einem 100nF sein. Nicht offen. Der Timeout sollte die Zeit fuer einen sinnvolle Reaktion beinhalten.
:
Bearbeitet durch User
Leute, lest doch mal bitte bevor Ihr Antworten gebt die längst da gewesen waren.
Markus W. schrieb: > Schalte ich den Bus ein, dieser läuft aber nicht wie gewollt an (Die > Blinksequenz wiederholt sich immer beim ersten Slave) dann nutzt auch > ein Reset am Master nichts. So wie ich deinen Aufbau bisher verstanden habe würde das doch bedeuten das der Master nachdem er den 1.Slave angesprochen hat selbständig einen Reset macht!? Sascha
> Mir ist auch sehr unklar was "der Bus geht an" bedeutet. Nach dem Einschalten kommt zuerst die Blinksequenz, bei der der Reihe nach die Led eines jeden Slaves einmal kurz blinkt. Dannach wird jeder Slave zyklisch abgefragt (zb. aktueller ADC-Wert) und diese Wert erscheinen dann am lcd des Masters. meistens nach dem Einschalten blinkt aber nur die Led des ersten Slaves und das war es dann. Am Lcd kommen natürlich keine weitere Ausgaben. > Du solltest deine Gerät im Störfall mal ernsthaft Debuggen Ich habe versucht mit Hilfe von Leds mir Durchblick zu verschaffen, bin aber hierbei zu keinen Erkenntnissen gekommen. Auch ein Einbau der Leds in die Sendeumschaltung lieferte mir keine brauchbaren Resultate. Entweder funktioniert die Kommunikation nach dem Einschalten oder sie wiederholt sich an der besagten Blinksequenz des ersten Slaves. Hast Du mal einen Blick auf den Code geworfen?
> So wie ich deinen Aufbau bisher verstanden habe würde das doch bedeuten > das der Master nachdem er den 1.Slave angesprochen hat selbständig einen > Reset macht!? > Sascha Das hatte ich auch vermutet, dem ist aber nicht so. In der Statemachine des Moduls MasterService.c ist zu Beginn der Satus auf "wait". Nach 3 Sekunden ändert sich der Status auf "flash_led1". Das wird auch ausgeführt denn die Led des ersten Slaves blinkt ja. Das habe ich mit einer Led überprüft, die, wenn er einen Reset machen würde, jetzt blinken würde. Grüße Markus
Markus W. schrieb: > Ich habe versucht mit Hilfe von Leds mir Durchblick zu verschaffen, bin > aber hierbei zu keinen Erkenntnissen gekommen. Wundert mich nicht. Dein Problem ist zu komplex, um es mit ein paar LEDs zu untersuchen. Immerhin weißt du, ob die µC überhaupt starten, aber jetzt musst du weiter gehen. Wenn du Debug-Meldungen seriell ausgibst, kannst du davon hunderte pro Sekunde haben und dennoch den Überblick bewahren, denn das Terminalprogramm zeigt sie in chronologisch korrekter Reihenfolge an. Du kannst quasi in die Vergangenheit zurück scrollen, um zu sehen, was vorher passierte. Dein LCD Display ist für so etwas zu klein. Du könntest damit beginnen, am Anfang und Ende jeder einzelnen Funktionen eine Debug Meldung auszugeben, etwa: main() start initMasterService() start initMasterService() end main() enabling interrupts main() interrupts are enabled main() init LCD start main() init LCD end main() LCD output before main loop main() Entering main loop main() main loop executing masterService() start masterService() master_state=0 masterService() case STATE_WAIT start masterService() case STATE_WAIT end masterService() end main() main loop executing masterService() start masterService() master_state=0 masterService() case STATE_WAIT start masterService() case STATE_WAIT end masterService() end und so weiter. gebe die Werte wichtiger Variablen aus, und vor allem Stati von allem Möglichen. Immer wenn eine Bedingung geprüft wurde, dann logge das, so dass am Log genau abgelesen werden kann, welche Codeabschnitte warum durchlaufen wurden. Benutze PSTR, PROGMEM und die _P Funktionen um RAM zu sparen. Wenn die Strings nicht in den Flash Speicher passen, dann musst du dich Schrittweise an den Kern des Problems heran tasten, anstatt alle Debug Meldungen gleichzeitig zu aktivieren. Der entscheidende Vorteil dieser Methode ist, dass du nicht nur siehst wo er hängt, sondern auch, was vorher passiert. Idealerweise aktivierst du im Terminalprogramm die Anzeige on Zeitstempeln, dann siehst du auch ungefähr das Timing (welches durch die ganzen Debug Meldungen natürlich in gewissem Umfang versaut wird, aber besser als nichts). > Hast Du mal einen Blick auf den Code geworfen? Nein. Der interessiert mich erst, wenn das Problem weiter eingekreist wurde. Noch wissen wir nicht genau genug, an welcher Stelle es Hakt.
Was ein Protokoll betrifft: Ein simples, verbreitetes und etabliertes Protokoll wäre Modbus-RTU. Das hat den Vorteil, daß es dafür genügend freie Software gibt, mit denen man sowohl Modbus-Geräte als auch einen Modbus-Master simulieren kann. Die zu transportierenden Inhalte sind primitiv - entweder ein 16-Bit-Wert oder einzelne Bits. Alles darüber hinausgehende muss man sich auf einer Metaebene darüber zurechtschnitzen, aber das ist nicht wirklich ein Problem; in der realen Welt werden über die einfachen Modbus-Mechanismen auch echte float-Werte transportiert etc. Wie Werte zu interpretieren sind, ist halt eine zweite Protokollebene, die im Schichtenmodell oberhalb des eigentlichen Modbus zu liegen kommt.
Der Einbau von 1Mohm-Widerständen parallel zu den Quarzen hat auch nichts gebracht. Grüße Markus
Danke mal zwischenzeitlich an Alle. Ich denke ich werde die Methode von Stefanus forcieren und dahingehend versuchen neue Erkenntnisse zu erlangen. Auch eine Implementierung von Modbus wäre eine weitere Möglichkeit, sollte ich das nicht in den Griff bekommen. Ich melde mich, wenn ich das Problem weiter einkreisen konnte. Grüße Markus
Markus W. schrieb: > So, die Reset-Schaltung ist erledigt, jedoch hat sich nichts > wesentliches verändert. Und hast du auch das gemacht?: Dietrich L. schrieb: > Hast du die Brown-out-Fuses passend > eingestellt, um einen sicheren Reset zu garantieren?
Also. Vergiss mal den Bus. Die Komponenten alleine muessen schon zuverlaessig laufen, sonst ist eh nichts. Also mach in alle einen Laufzeitzaehler rein, der seriell abfragbar ist. zB eine 32bit Variable, die alle Sekunden inkrementiert. Und dann wird darauf aufgebaut.
Markus W. schrieb: > Ich weis aber nicht, wie ich die Timeout-Funktion realisieren kann, bzw. > welche Zeiten ich verwenden müsste - könnte das ein Grund für die > Einschaltprobleme sein? Ich habe mir den Code jetzt nicht angeschaut, aber allgemein: Wenn der Master nach dem Senden auf eine Antwort wartet und erst nach einer gültigen Antwort weiter macht, dann brauchst du unbedingt ein Time-Out. Sonst würde bei einer beliebigen Störung auf der Leitung oder beim Slave die "Maschine" hier hängen bleiben. Wie Time-Out realisieren? Z.B.: - Timer-Interrupt mit 1ms - eine Time-Out-Variable wird zu Beginn des Wartens auf Antwort auf den gewünschten Wert gesetzt - die Timer-ISR zählt die Variable bei jedem Aufruf herunter bis 0 erreicht ist - während des Wartens wird die Time-Out-Variable abgefragt, ob sie 0 erreicht hat - wenn 0 erreicht ist weiter mit erneutem oder nächstem Senden.
Ein Timeout muss natuerlich solange warten bis etwas gekommen sein muss. Wenn also ein Slave max 22ms fuer eine Antwort benoetigt. Setzt du das timeout auf 30ms. Oder so. Das Timeout wird per interrupt runtergezaehlt.
Dietrich und Troll, danke für eure Antworten! Wie müsste ich den die Brown-out fuses setzen? Das hab ich nämlich nicht gemacht. ... und danke für die Tips mit der Timeout-funktion, ich werde versuchen, diese noch umzusetzten.
Markus W. schrieb: > Wie müsste ich den die Brown-out fuses setzen? Dann schau doch mal ins Datenblatt! Da du mit +5V arbeitest, wäre BODLEVEL = 100 sinnvoll. Dann ist die Schaltschwelle für der Reset bei 4,3V +/- 0,2V.
Hallo, ich möchte nochmal wegen der failsafe-Widerstände nachfragen: welcher Pegel wird denn erzeugt, wenn kein Knoten sendet ? RS485 mit failsafe-Erkennung darf in den Sende-Pausen keine Unterbrechung erkennen. Mir ist allerdings nicht klar, wie so überhaupt eine Unterbrechung erkannt werden kann. Gruß, Michael
Ich hab sie auf 4,3V gestellt. ...hat funktioniert, 10x ein- und ausgeschaltet. Dann den Programmieradapter abgesteckt - und vorbei. Wieder das gleiche Verhalten. Ich mach mich jetzt mal an eine Timeout-Funktion.
Markus W. schrieb: > Ich hab sie auf 4,3V gestellt. > ...hat funktioniert, 10x ein- und ausgeschaltet. > > Dann den Programmieradapter abgesteckt - und vorbei. > Wieder das gleiche Verhalten. Frage dich, was denn nun anders ist. a) Der Programmieradapter stellt eine GND Verbindung zum PC her, und somit eventuell auch zur Erdung. b) Der Programmieradapter erzeugt nach dem Hochfahren der Stromversorgung einen zweiten recht langen Reset-Impuls (jedenfalls macht meiner das). c) Eventuell stellt dein Programmieradapter eine Stromversorgung bereit? Das kann man doch auch ohne Programmieradapter man eben händisch simulieren.
>Frage dich, was denn nun anders ist. >a) Der Programmieradapter stellt eine GND Verbindung zum PC her, und >somit eventuell auch zur Erdung. >b) Der Programmieradapter erzeugt nach dem Hochfahren der >Stromversorgung einen zweiten recht langen Reset-Impuls (jedenfalls >macht meiner das). >c) Eventuell stellt dein Programmieradapter eine Stromversorgung bereit? >Das kann man doch auch ohne Programmieradapter man eben händisch >simulieren. ich habe den Diamex usb-isp-Programmer. Die Stromversorgung habe ich immer ausgeschaltet, weil ich ja Versorgung über das Netzteil nutze. Den Rest hab ich händisch schon simuliert. Das Problem ist ja, das das mit dem Adapter ja nur nach dem Programmieren funktioniert. Sobald ich ihn abnehme, funktioniert es nicht mehr, auch wenn ich ihn erneut anstecke - bis ich den Master wieder programmiere, dann läuft es wieder einwandfrei
Markus W. schrieb: >> - Failsafewiderstände unbedingt raus! Allerhöchstens nur bei einem >> Busteilnehmer drin lassen! > Sind nur beim Master dran! Auch die 100 Ohm Abschlusswiderstände (R7) gehören nur an die beiden physikalischen Enden des Bus. Ob dort der Master steht oder ein Slave oder nix, ist Wurst.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.