Hallo, ich möchte gerne die Device ID beim Atmega 168 im Programmverlauf auslesen. Gemäß Datenblatt ist das allerdings nur im Parallel bzw. Seriell Mode möglich. Kennt jemand eine Möglichkeit dies im C oder Assembler Programm auszuführen? uint8_t *avr_id = (*unit8_t) 0x00 ... war leider nicht erfolgreich. Gruß Christian
Gast
#787659
Nein, geht nicht per Firmware. Was macht es denn für einen Sinn, die eigene DeviceID auszulesen ? LG EC
Gast
#787662
Wozu soll das gut sein? Ich glaube nicht, das das geht.
Doppelposting. :-( Beitrag "atmega device ID"
Ich möchte die ID über SPI auslesen und auswerten, damit ich extern feststellen kann, welches Gerät an meinem CS hängt.
SPI impliziert zwei verschiedene Teilnehmer, die miteinander reden. Das ist irgendwie nicht das, wie deine restlichen Fragen bisher klangen. Nun lass dir mal nicht alles aus der Nase ziehen, sondern erzähle, wie dein Aufbau aussieht und wer darin was wissen möchte. Dann kann man dir vielleicht auch helfen.
Siehe Datenblatt Seite 299ff
Angehängte Dateien:
-
atm168.png
(18 KB)
Travel Rec. wrote:
> Siehe Datenblatt Seite 299ff
Das ist aber nicht SPI sondern ISP... Fast dasselbe, aber nicht ganz.
Anders kommst Du nicht an die Signatur aber nicht heran! Statt /CS ist dann halt der Reset des zu lesenden Controllers auf LOW zu ziehen. Wieder ndere Devices geben ihre ID auch über das normale SPI-Protokoll preis, so zum Beispiel die DataFlash Bausteine.
Ziel ist es, den atmega168 von einem at91 via SPI als slave anzusprechen. Wobei wahlweise am SPI Bus des AT91 auch andere Geräte hängen können. Meinen Software, auf dem AT91, muß prüfen welches Device sich am SPI Bus (fester CS) befindet und entprechend reagieren. Zur Erkennung der Gerätes möchte ich dessen ID auslesen, wie es z.B. bei A/D Wandler möglich ist.
Es ist wahrscheinlich besser, sich einen eigenen ID-Mechanismus per Software zu realisieren. Ansonsten können z.B. zwei Geräte mit gleichem Controllertyp nicht voneinander unterschieden werden. Gruß Jörg
Du müsstest den AVR zu diesem Zweck praktisch komplett außer Betrieb nehmen, da das Auslesen der Fuses nur im Programmiermodus (der einen Hardware-Reset impliziert) möglich ist. Ich würde das an deiner Stelle höchstens auf diese Weise tun, wenn 1.) der Reset des AVR nicht stört und 2.) du die ISP-Funktionalität ohnehin implementieren musst (weil z. B. der AVR damit auch Firmwareupgrades bekommen können soll). Ansonsten stimme ich Jörg W. zu. Ferner solltest du dir darüber im Klaren sein, dass SPI gegen einen AVR als Slave nicht sonderlich glücklich ist: SPI ist letztlich ein Schieberegister und als solches am besten in Hardware abbildbar. Bei einer Softwareimplementierung muss der Master sehr viel Geduld mitbringen, damit der Slave die nötige Zeit bekommt, die Daten bereit zu stellen. Anders als z. B. I²C besitzt der SPI-Slave ja keinerlei Möglichkeit, den Master zu informieren, ob er mit seiner internen Verarbeitung bereits fertig ist.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.