Hi, ich habe als etwas länger fristiges Ziel, mehrere Atmegas miteinander kommunizieren zu lassen. Ich möchte serielle Kommunikation benutzen. Dazu möchte ich die zentral vom Rechner programmieren. Meine Konstellation und Fortschritte: Programmieren von einem Pollin Board vom Rechner funktioniert über ISP. Dann stecke ich das Kabel um auf RS232 und rede mit dem Computer. Nun habe ich ein 2tes Board. Ich habe die Kabel für die ISP- und JTAG- Anschlüsse (einfach 10er Kabel 1 zu 1). Nun stehe ich ochsentechnisch vorm Berg. Ich würde jetzt also einfach mit einem Kabel die ISP-Anschlüsse verbinden, aber wie kann ich dann unterscheiden, welchen mC ich programmiere, oder ist das schon Quatsch? Nun möchte ich die ja auch seriell kommunizieren lassen... Laut Schaltplan ist beim Atmega16/32 ja PD8 und PD1 als TX/RX für seriell. Ich dachte, wohl Fehlverständnis, das JTAG- und seriell irgendwie zusammenhängen. Wohl total falsch. Was nun? Idee: Ich könnte auf dem 40poligen Stecker vielleicht Pins brücken, um den JTAG-Anschluss zu einem seriellen Anschluss zu machen? Wenn ich einfach das Kabel am JTAG-Anschluss nehme, dann habe ich ja glaube ich nur 4 Pins von Port C verbunden? Kein Plan... Danke für bissi Nachhilfe! LG Jens
Moin Jens, ich fürchte Du wirfst da vieles durcheinander ;-) Leg mal einen Moment deine beiden Boards an die Seite und lass uns erst mal was Grundlagen anschauen. JTAG ist eigentlich nicht dafür gedacht das 2 (oder mehr) Prozessoren sich unterhalten. Es ist viel eher eine Fehlersuchschnittstelle (Schau Die mal den WIKI zum Thema JTAG an) ISP bei den AVRs muss ich jetzt mal die Runde ragen ob es überhaupt funktionieren würde mehrere parallel anzuschließen. Um 2 (oder mehr?) AVRs zu verbinden würde ich in Richtung SPI schauen. Da gab es hier auch schon mal ein Beispiel zu.... Ich bin nur gerade zu dusselig es wieder zu finden. In jedem Fall ist es aber eine gute Idee auch hier mal ein bischen im WIKI zu stöbern. Du kannst auch den UART benutzen, nur würde ich mir an deiner Stelle den Frei halten um mit dem PC zu reden ;-) Grüße Frank
Frank Sander schrieb: Hi Frank, > ich fürchte Du wirfst da vieles durcheinander ;-) durchaus möglich ;) > Leg mal einen Moment deine beiden Boards an die Seite und lass uns erst > mal was Grundlagen anschauen. > > JTAG ist eigentlich nicht dafür gedacht das 2 (oder mehr) Prozessoren > sich unterhalten. Es ist viel eher eine Fehlersuchschnittstelle (Schau > Die mal den WIKI zum Thema JTAG an) Schon iwi klar, ich werde vor das ganze noch einen Dragon spannen, das ist auch noch eine Baustelle... um dann halt zu debuggen, auch das checke ich noch nicht. > > ISP bei den AVRs muss ich jetzt mal die Runde ragen ob es überhaupt > funktionieren würde mehrere parallel anzuschließen. > Ja, dafür müsste man ja glaube ich zwischen den Prozessoren unterscheiden können! Ich sehe nicht, wie ich die adressieren kann. > Um 2 (oder mehr?) AVRs zu verbinden würde ich in Richtung SPI schauen. > Da gab es hier auch schon mal ein Beispiel zu.... Ich bin nur gerade zu > dusselig es wieder zu finden. > In jedem Fall ist es aber eine gute Idee auch hier mal ein bischen im > WIKI zu stöbern. > Okay, ich möchte aber definitiv mit einer Art Kommunikation im Sinne von RS232 mit lesbarer Kommunikation arbeiten... ist das ein Widerspruch? UART halt... ich möchte für die Prozessoren definitiv kein I2C nehmen oder so, ich würde die ganzen Prozessoren eben "richtig reden lassen", und vom Computer aus möchte ich denen dann lauschen können! > Du kannst auch den UART benutzen, nur würde ich mir an deiner Stelle den > Frei halten um mit dem PC zu reden ;-) Ja, wie gerade geschrieben: Ich möchte über UART mit allen Komponenten reden! Danke, Jens
Moin Jens, Da hake ich noch mal nach ;-) "reden lassen" ist ein hübscher Begriff ;-) Ich denke wir sind uns einig, es sollte eine Serielle Kommunikation sein weil man damit IO Pins sparen kann. Jetzt ist die Frage wie genau das ganze umgesetzt wird. Vergleichen wir mal: UART hat (im einfachsten Fall) 2 Pins (RX & TX) und sonst nix. Damit der Empfänger den Sender verstehen kann muss er auf die gleiche Übertragungsgeschwindigkeit eingestellt sein UND braucht min. 1 Startbit und ein Stopbit. Das bedeutet aber das um 8Bit Nutzdaten zu übertragen immer mind. 10 Bit übertragen werden. SPI hat (im einfachsten Fall) 3 Piins (DI, DO & CLK) hier bekommt der Empfänger die Geschwindigkeit durch das CLK vorgegeben. Das bedeutet ich brauche nur 8Bit für 8 Bit Nutzdaten. In meinen Nutzdaten kann ich in beiden Fällen übertragen was ich will. Kurz gesagt sehen die Nutzdaten in beiden Fällen gleich aus. Viele Prozessoren besitzen 1 oder max 2 UARTs fertig eingebaut, ein SPI kann man mit wenig Aufwand auf 3 beliebigen IO Pins abbilden. Zusammengefasst: Ohne deinen Wunsch UART benutzen zu wollen zu ignorieren ist es immer gut sich die Alternativen an zu schauen ;-) Sei es nur dafür gut das Du die Unterschiede und Gleichheiten erkennst. "lesbar" ist dabei immer das was in den Nutzdaten steht ! Grüße Frank
Frank Sander schrieb: > > "reden lassen" ist ein hübscher Begriff ;-) > Ich denke wir sind uns einig, es sollte eine Serielle Kommunikation sein > weil man damit IO Pins sparen kann. Jetzt ist die Frage wie genau das > ganze umgesetzt wird. Genau genommen nicht. Es ist nicht die Ersparnis, sondern die Sicherheit. Ich möchte auf einer höheren ISO-OSI-Ebene dafür sorgen, dass sich alle Komponenten wirklich verstehen! ;) Ich hoffe, ich kann da fertige Protokolle benutzen... > > Vergleichen wir mal: > UART hat (im einfachsten Fall) 2 Pins (RX & TX) und sonst nix. Damit der > Empfänger den Sender verstehen kann muss er auf die gleiche > Übertragungsgeschwindigkeit eingestellt sein UND braucht min. 1 Startbit > und ein Stopbit. > Das bedeutet aber das um 8Bit Nutzdaten zu übertragen immer mind. 10 Bit > übertragen werden. > Okay, kein Problem. Habe eh schon BAUD-Quarze an den 2 Kontrollern dran, mir sind die Paketlängen relativ wurscht. Siehe oben: Notfalls baue ich noch softwaremäßig CRC-Checks ein oder so, mir wurscht, hauptsache, ich habe verlässlichkeit. > SPI hat (im einfachsten Fall) 3 Piins (DI, DO & CLK) hier bekommt der > Empfänger die Geschwindigkeit durch das CLK vorgegeben. Das bedeutet ich > brauche nur 8Bit für 8 Bit Nutzdaten. Okay, welchen Vor- oder Nachteil habe gegenüber den 2 Pins oben? > > In meinen Nutzdaten kann ich in beiden Fällen übertragen was ich will. > Kurz gesagt sehen die Nutzdaten in beiden Fällen gleich aus. > > Viele Prozessoren besitzen 1 oder max 2 UARTs fertig eingebaut, ein SPI > kann man mit wenig Aufwand auf 3 beliebigen IO Pins abbilden. > Vielleicht verstehe ich da was falsch, aber ich würde halt gerne die Hardware ausnutzen, ein robustes (mehrere Meter langes) serielles Bussystem haben, bei dem ich mal eben den Laptop anstöpsel, und dabei mit all den kleinen schwarzen eckigen Freunden seriell rede ;) > Zusammengefasst: > Ohne deinen Wunsch UART benutzen zu wollen zu ignorieren ist es immer > gut sich die Alternativen an zu schauen ;-) Sei es nur dafür gut das Du > die Unterschiede und Gleichheiten erkennst. > > "lesbar" ist dabei immer das was in den Nutzdaten steht ! Ja, und genau da habe ich noch ein gewaltiges Verständnisproblem. Was hälst du von meinem Ansatz? Ich finde die Idee eigentlich nett, alle Daten der Unterhaltungen immer am Rechner zu haben... ob sich das widerspricht mit SPI kannst eher du mir sagen... > > Grüße Jens
> > ISP bei den AVRs muss ich jetzt mal die Runde ragen ob es überhaupt > funktionieren würde mehrere parallel anzuschließen. Ich glaube, das geht nur hardwaremäßig. Die mC müssten so eine Art MAC haben, mit der ich die programmieren kann. Haben die aber ja aber wohl nicht. Im Roboternetz gab es mal eine Idee: http://www.roboternetz.de/community/threads/46288-Mehrere-AVR-an-einer-ISP-Schnittstelle-und-Programmieren Also, Baustelle, wie programmiere ich mehrere Atmega? LG, Jens
Moin Jens, Bei der Baustelle mehrere AVR n einem ISP Programmieren muss ich mich ersteinlesen. Da bin ich auch nicht fit... aber das schaue ich mir heute Abend mal an. Zu deinem Wunsch mit dem PC mitlesen zu können (da hatte ich Dich misverstanden) ist UART wirklich am einfachsten um ein Hardwareprotokoll zu haben das es am PC schon fertig gibt. Auf die Gefahr hin das ich korrigiert werde, behaupte ich jetzt aber mal das es auf der gleichen OSI Ebene liegt wie SPI ;-) Damit der PC lauschen kann solltest Du sicherstellen das Du RS232 Pegel zur Verfügung hast. Das wird häufig mithilfe eines MAX232 erledigt. Wenn ich mich noch recht erinnere ist das aber schon auf dem Pollin Board vorhanden. Dann kommt der schwierige Teil: Wenn der PC von beiden AVRs mitlesen soll braucht es 2 RS232 im PC. Du kannst schließlich nicht 2 TX Leitungen zusammen schalten ;-) CRC (jetzt wechseln wir OSI Schichen ;-) ) würde ich an deiner Stelle erst etwas später einführen, ist allerdings als Absicherung durchaus Sinnvoll. Also frisch ans Werk :-D Grüße Frank
Frank Sander schrieb: > Moin Jens, > > Bei der Baustelle mehrere AVR n einem ISP Programmieren muss ich mich > ersteinlesen. Da bin ich auch nicht fit... aber das schaue ich mir heute > Abend mal an. > > Zu deinem Wunsch mit dem PC mitlesen zu können (da hatte ich Dich > misverstanden) ist UART wirklich am einfachsten um ein Hardwareprotokoll > zu haben das es am PC schon fertig gibt. > Auf die Gefahr hin das ich korrigiert werde, behaupte ich jetzt aber mal > das es auf der gleichen OSI Ebene liegt wie SPI ;-) > > Damit der PC lauschen kann solltest Du sicherstellen das Du RS232 Pegel > zur Verfügung hast. Das wird häufig mithilfe eines MAX232 erledigt. > Wenn ich mich noch recht erinnere ist das aber schon auf dem Pollin > Board vorhanden. > Dann kommt der schwierige Teil: > Wenn der PC von beiden AVRs mitlesen soll braucht es 2 RS232 im PC. Du > kannst schließlich nicht 2 TX Leitungen zusammen schalten ;-) > > CRC (jetzt wechseln wir OSI Schichen ;-) ) würde ich an deiner Stelle > erst etwas später einführen, ist allerdings als Absicherung durchaus > Sinnvoll. > > Also frisch ans Werk :-D > > Grüße > Frank Alles klar Frank, und ich kann Dir fast garantieren: Wir landen wieder beim Thema Bootloader... LG Jens
Moin Jens "wieder" ?? Habe ich was verpasst oder vergessen? Na wie dem auch sei ;-) Ich bin noch nicht dazu gekommen wegen des ISP und mehreren Prozessoren zu lesen. Bisher sind alle Schaltpläne an die ich mich erinnern kann immer von einer CPU ausgegangen. Ob man das mit einem Bootloader umgehen kann? Habe ich offen gestanden noch gar nicht drüber nach gedacht. Nun denn ich werde mal forschen ;-) Grüße Frank
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.