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
