Moin, ich habe folgende Situation: Ich habe auf einem PCB zwei ATMega 328p Prozessoren. Diese sollen per SPI kommunizieren. Weiterhin brauche ich aber die Möglichkeit, sie zu flashen, dafür würde ich ISP präferieren, dann brauche ich nicht noch irgendwo zwei USB <-> Seriell Chips unterzubringen und einen Bootloader zu flashen. Jetzt allerdings zu meiner Frage: Sehe ich das richtig, dass die Reset Leitung des 328p als Chip Select dient? Da ja beide meiner uCs auf dem SPI hängen, möchte ich natürlich nicht, dass einer das Programm vom anderen beim flashen mit abbekommt ;-) Ich würde also einfach die Reset Pins mit 10K als Pullup auf High ziehen, und mit einem Jumper jeweils einen der Reset Pins als CS Pin aktivieren oder deaktivieren, um eben nur einen Chip zu flashen. Weiterhin: Macht es irgendwelche Probleme, wenn der zweite Controller dann mit Strom versorgt wird, und somit nur "lauscht"? Das Senden von Daten müsste ich dann natürlich deaktivieren während des flashens. Sollten die MISO, MOSI SS und SCK Leitungen auch noch einen Pull-Up oder Pull-Down bekommen? Fragen über Fragen ... ;-) Ich hoffe, da kann mir jemand kurz auf die Sprünge helfen. Danke schonmal! LG Lukas
Lukas E. schrieb: > Sehe ich das richtig, dass die Reset Leitung des 328p als Chip Select > dient? Kann man so sagen ja. > Weiterhin: Macht es irgendwelche Probleme, wenn der zweite Controller > dann mit Strom versorgt wird, und somit nur "lauscht"? Nein, warum sollte es? > Das Senden von Daten müsste ich dann natürlich deaktivieren > während des flashens. Ja. > Sollten die MISO, MOSI SS und SCK Leitungen auch noch einen Pull-Up oder > Pull-Down bekommen? Kann man machen, muss man nicht.
Alles klar, danke dir für die schnelle & unkomplizierte Antwort :) Der Punkt ob das Probleme macht, wenn ein anderer Busteilnehmer noch mit dran hängt: Warum das Probleme machen sollte, kann ich mir nicht erklären, aber bevor ich PCB's bestelle und dann da einen gravierenden Fehler mache, nur weil ich es nicht wusste, wäre das ärgerlich :D LG Lukas
Lukas E. schrieb: > Sehe ich das richtig, dass die Reset Leitung des 328p als Chip Select > dient? Würde ich so nicht sehen.... Lukas E. schrieb: > und mit einem Jumper jeweils einen der Reset Pins als CS Pin > aktivieren oder deaktivieren, um eben nur einen Chip zu flashen. Hätte ja jetzt eher den SCLK Pin genommen.
Lukas E. schrieb: > aber bevor ich PCB's bestelle Würde ich einen Prototypen auf Lochraster aufbauen.
Arduino Fanboy D. schrieb: >> Sehe ich das richtig, dass die Reset Leitung des 328p >> als Chip Select dient? > Würde ich so nicht sehen.... Die ISP Schnittstelle ist aktiv, während /Reset auf LOW liegt.
Stefan ⛄ F. schrieb: > Lukas E. schrieb: >> aber bevor ich PCB's bestelle > > Würde ich einen Prototypen auf Lochraster aufbauen. Das kommt natürlich dazu - das hatte ich ganz vergessen zu erwähnen, aber auch dort wäre es Ärgerlich, wenn sich so ein Fehler einschleicht :) Ich würde wahrscheinlich einen 2x2 Header einbauen, belegt wie folgt: ISP_RESET CHIP2_RESET CHIP1_RESET GND Dadurch kann ich jeweils einen Chip entweder auf GND oder den ISP Reset jumpern, solange der Chip im Dauerreset hängt, sollte er doch auf den SPI Pins wenig schaden anrichten.
Da du schion so unsicher bist und auch keine Lust auf Lötversuche hast, nimm doch einfach Arduino Module und Dupont Kabel zum ausprobieren.
Die Arduinos sind auf dem Weg zu mir, ich mach mir nur trotzdem gerne bei Projekten vorher schon ein paar Gedanken :)
Lukas E. schrieb: > Sehe ich das richtig, dass die Reset Leitung des 328p als Chip Select > dient? Bezogen auf ISP ist das so, ja. > Weiterhin: Macht es irgendwelche Probleme, wenn der zweite Controller > dann mit Strom versorgt wird, und somit nur "lauscht"? Kommt drauf an. Wenn er der Master ist und während des Programmierens des Peers eine Kommunikation versucht, wird er erstens scheitern und zweitens den Erfolg des Programmierens des Slave mit einiger Wahrscheinlichkeit verhindern. Aber auch ein Slave kann stören, obwohl er normalwerweise keine SPI-Kommunikation initiieren kann. Bei dem ist das Problem, dass sein \SS-Signal vom Master kommt. Der ist aber beim Programmieren im Reset, alle seine Pins (außer den zum Programmieren benutzten) sind High-Z, also auch der, der normalerweise das \SS für den Slave liefert. Der Pegel dieses Signals ist also während des Programmierens des Masters undefiniert und könnte leicht in Bereiche rutschen, wo der Slave ein aktives \SS "sieht". Dieses Problem ist aber zum Glück leicht durch einen PullUp für das \SS-Signal zu lösen. Für alle Slaves am SPI-Bus einfach einen PullUp-Widerstand für die jeweilige \SS-Strippe vorsehen... Bleibt also 1) das Problem, dem Master mitzuteilen, dass gerade ein Slave programmiert wird, damit er einfach die Schnauze hält in der Zeit. Und zweitens die Tatsache, das MOSI und MISO (vom Programmieradapter) zu tauschen sind, je nachdem, ob man nun den Master oder einen Slave des SPI-Busses programmieren will...
c-hater schrieb: > Lukas E. schrieb: > >> Sehe ich das richtig, dass die Reset Leitung des 328p als Chip Select >> dient? > > Bezogen auf ISP ist das so, ja. > Darauf bezog ich mich, sonst ist das nur ein normaler Reset Pin, das ist mir bewusst. >> Weiterhin: Macht es irgendwelche Probleme, wenn der zweite Controller >> dann mit Strom versorgt wird, und somit nur "lauscht"? > > Kommt drauf an. Wenn er der Master ist und während des Programmierens > des Peers eine Kommunikation versucht, wird er erstens scheitern und > zweitens den Erfolg des Programmierens des Slave mit einiger > Wahrscheinlichkeit verhindern. > > Aber auch ein Slave kann stören, obwohl er normalwerweise keine > SPI-Kommunikation initiieren kann. Bei dem ist das Problem, dass sein > \SS-Signal vom Master kommt. Der ist aber beim Programmieren im Reset, > alle seine Pins (außer den zum Programmieren benutzten) sind High-Z, > also auch der, der normalerweise das \SS für den Slave liefert. Der > Pegel dieses Signals ist also während des Programmierens des Masters > undefiniert und könnte leicht in Bereiche rutschen, wo der Slave ein > aktives \SS "sieht". Dieses Problem ist aber zum Glück leicht durch > einen PullUp für das \SS-Signal zu lösen. Für alle Slaves am SPI-Bus > einfach einen PullUp-Widerstand für die jeweilige \SS-Strippe > vorsehen... > > Bleibt also 1) das Problem, dem Master mitzuteilen, dass gerade ein > Slave programmiert wird, damit er einfach die Schnauze hält in der Zeit. > Und zweitens die Tatsache, das MOSI und MISO (vom Programmieradapter) zu > tauschen sind, je nachdem, ob man nun den Master oder einen Slave des > SPI-Busses programmieren will... Das Problem des "reingrätschens" wollte ich so lösen, den nicht zu programmierenden Controller per Jumper einfach im Dauerreset zu halten, dann dürfte er eigentlich dort nichts reinschicken. Die SS Pins von beiden ATMegas sind ja direkt verbunden, dort also einfach einen 10K Pullup ranhängen, verstehe ich dich dort soweit richtig? Es gibt nur einen Master & einen Slave, diese tauschen auch nicht ihre Rollen.
Lukas E. schrieb: > Das Problem des "reingrätschens" wollte ich so lösen, den nicht zu > programmierenden Controller per Jumper einfach im Dauerreset zu halten, Aber dann ist doch auch bei dem die ISP Schnittstelle aktiviert!
Um es ganz kurz zu bringen: Baue Jumper/Stecker ein, mit deren Hilfe die Schaltung in zwei getrennte Teile zerlegt werden kann. Dann kannst Du jede Seite getrennt programmieren. Der Slave muß einen Widerstand an CS bekommen, damit er ohne uC inaktiv bleibt. MfG
Christian S. schrieb: > Baue Jumper/Stecker ein, mit deren Hilfe die Schaltung in zwei getrennte > Teile zerlegt werden kann. Mir scheint es am einfachsten, beide µC mit dem üblichen 6 pol ISP Stecker auszustatten und dazu ein Flachkabel anzufertigen, dass die beiden miteinander verbindet. Wenn du das Verbindungskabel abziehst, kannst du auf die gleichen Stecker deinen Programmieradapter stecken.
Das ist eine sehr gute Idee, das werde ich so implementieren, dankeschön!
Lukas E. schrieb: > Ich habe auf einem PCB zwei ATMega 328p Prozessoren. Diese sollen per > SPI kommunizieren. Eh Du Dich da umständlich mit einem Protokoll abquälst, nimm doch einfach einen größeren AVR, z.B. ATmega1284.
Peter D. schrieb: > Eh Du Dich da umständlich mit einem Protokoll abquälst, nimm doch > einfach einen größeren AVR, z.B. ATmega1284. Das ist nicht immer der Ausweg. Es kommt darauf an, wo's genau klemmt. Wenn's bei der Pinzahl oder dem verfügbaren Speicher klemmt, dann ist natürlich ein größerer Controller derselben Familie immer die sinnvollere Lösung. Aber nicht, wenn's an der Rechenleistung oder dem Timing (als Folge mangelnder Rechenleistung) klemmt und der mögliche Takt bereits ausgereizt ist und/oder es schon der größte Controller der Familie ist... Dann könnte es durchaus sinnvoll sein, die Aufgaben auf zwei Controller zu verteilen. Die einzige Alternative wäre dann nämlich der Wechsel der Architektur. Also vergleichsweise hoher Aufwand. Kommt dann halt sehr auf das konkrete Problem und das vorhandene Knowhow an, was vorzuziehen wäre...
c-hater schrieb: > Dann könnte es durchaus sinnvoll sein, die Aufgaben auf zwei Controller > zu verteilen. Der Aufwand für ein zuverlässiges Kommunikationsprotokoll wird gerade von Anfängern völlig unterschätzt. Wenn man sich mal professionelle Protokolle anschaut, ist da kaum was unter 100kB zu finden. Dagegen ist es oft einfacher, die CPU-Leistung sinnvoller auf die einzelnen Tasks zu verteilen, d.h. den Programmfluß besser zu analysieren. Ganz abgesehen davon, ist bei den AVRs ausgerechnet das SPI ein pain in the ass (kein Sendepuffer). Optimal ist CAN geeignet, da übernimmt schon die Hardware viel an Datensicherung (Arbitration, CRC, Retry).
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.