Hallo, hat jemand schon mit dem Mikrocontroller AT91SAM9G45 gearbeitet. Bei mir ist es so, dass über diesem mehrere Komponenten gesteuert werden, z.B. LCD, Sensoren, Relais usw... Werde demnächst ein Testsystem in LabVIEW schreiben müssen, das diese Kompoenenten testet... Dazu werde ich höchstwahrscheinlich mit dem Atmel kommunizieren müssen. Dadurch, dass ich komplett neu in diesem Gebiet bin, bräuchte ich große Hilfe. Für Unterstützung aller Art, wär ich sehr dankbar Vlg, Yesim
Nicht schwer, aber dafür das du keine Ahnung hast, hast du dir nicht grade einen einfachen µC rausgesucht. Sehr viel wird dir da kaum einer helfen können außer gegen teures Geld. Erstmal solltest du dir das Datenblatt herunterladen und, wenn du viel Glück hast, ein entsprechendes SDK für LabView herunterladen. Wenn LabView diese Komponenten unterstützt, hast du Glück und es wird relativ simpel das zu realisieren was du möchtest. Weitere Fragen wären, ob du schon eine fertige Hardware besitzt, ob ein OS schon drauft läuft etc... Aber grade bei diesem µC wär es recht ratsam ein OS zu benutzen. MfG Stefan
Hallo Stefan, also...ich haben den Mikrokontroller nicht ausgesucht... So ist leider die Vorgabe. Der Mikrocontroller besitzt bereits eine Software...Die Hardware hierzu sind auch ausgesucht worden. Würde es nicht reichen über RS232 mit dem Mikrocontroller zu kommunizieren?? (Abfrage der Pins) Mit Unterstützung habe ich eigentlich nicht gemeint, ob jemand mir dies programmieren würde...Sondern ob jemand mir gute Tipps geben könnte, wie ich z.B. die Schnittstelle I²C testen könnte... lg
Wenn es nur ums Testen geht, sollte das recht simpel mit einem entsprechender Hardware gehen. Also bräuchtest du für I²C z.b. einen Empfänger und Sender(oder nur einen wenn nur ein weg betrachtet werden soll) oder aber wenn du nur kontrollieren möchtest ob der µC die richtigen Daten sendet nimm ein Oszi und guck dir die Daten an. Es gibt welche, die Übersetzen dir die Spannungswerte auch gleich in Daten. Bin grad zu faul um mir das Datenblatt anzugucken, aber es kann durchaus sein, dass einige Komponenten eine Loop-Back Funktioninalität haben, wo sie intern das Ausgegebene Signal direkt umleiten in die Empfangshardware. Dazu müßte dies aber per Software aktiviert werden. Im Grunde brauchst du aber geeignete Hardware um alle Komponenten vollständig zu testen. Für jede Schnittstelle eine. Allgemein zum Testen von Übertragungsmedien bieten sich Bitmuster an wie 0xFFFF, 0x0000, 0xAAAA, 0x5555.
´Hallo Stefan, könnten die Pins nicht eventuell über Datenerfassungskarten (analoge/digitale Ausgänge/Eingänge) nicht getestet werden. Oder ist da andere Hardware nötig?? lg
Bei uns im Unternehmen wird das ganze so realisiert, dass via MIO-Card von NI die Eingangspins mit den entsprechenden Werten beaufschlagt werden und dann das Ergebnis mit dem zu erwartenden verglichen wird. Das gane hat den Vorteil dass so auch gleich die Software mitgetestet werden kann, bedeutet aber einen hohen Aufwand bei der Entwicklung entsprechender Eingangs/Ausgangsmuster
Das geht auch, dann muß das nur schnell genug sein (Datenrate beachten) und du mußt dann die empfangenen Daten selbst auseinander nehmen und richtig zusammensetzen. Ob es geht oder nicht hängt davon ab wie schnell du die Daten in den PC zu Labview bekommst und wie schnell die Schnittstellen getaktet sind. Aber ich würd mal rein aus dem Bauch sagen, dass die LabView-Hardware die du hast, das nicht packt, da du wenn du es wirklich testen willst eine Abtastrate brauchst die 10x mal höher liegt als dein Nutzsignal um es auch richtig analysieren zu können. Also wenn du deine I²C Schnittstelle mit 400kHz betreibst brauchst du eine Abtastrate von 4 MSPS und das für Datenleitung und Glock also 2x.
Hallo Daniel, Daniel F. schrieb: > dass via MIO-Card > > von NI die Eingangspins mit den entsprechenden Werten beaufschlagt > > werden und dann das Ergebnis mit dem zu erwartenden verglichen wird. Könntest du mir bitte eventuell diesen Part näher erläutern?? Welche Eingangpins werden mit welchen Werten und wie beaufschlagt?? lg
Stefean Kunz schrieb: > Aber ich würd mal rein aus dem Bauch > > sagen, dass die LabView-Hardware die du hast, das nicht packt, da du > > wenn du es wirklich testen willst eine Abtastrate brauchst die 10x mal > > höher liegt als dein Nutzsignal um es auch richtig analysieren zu > > können. Hallo Stefan, ich weiß nicht wie sehr du dich mit NI-Hardware auskennst...Aber mit ensprechender FPGA-Datenerfassungskarten ist eine Signalgeschwindigkeit von 10 ms möglich...
Ich weiß ja nicht welche Hardware ihr zur Verfügung habt und ich hoffe du hast dich nur verschrieben und meinst nanosekunden. Denn mit einer Auflösung von 10 ms Sekunden hättest du ganz schlechte Karten auch nur annährend das I²C Signal zu erfassen. Wie gesagt es kommt drauf an wie gut du das Signal auflösen kannst und ob du die Zeit dafür investierst dich mit der Schnittstelle auseinander zu setzen zu verstehen und dann das ganze dann in Labview hinzubiegen. Ich bin mir auch ziemlich sicher, dass Labview entsprechende Hardware für die Schnittstellen anbietet, daher mal gucken was billiger ist. Die Hardware oder die zu leistenden Stunden.
So Was willst du denn eigentlich machen? So wie ich das jetzt rausgehört habe, sollst du ein auf einen G45 basierte HW mittels LabView Testen. Die Frage ist eigentlich, Was willst du genau testen? Funktionalität der FW die auf dem G45 läuft? Funktionalität der HW? sind alle Steker richtig gelötet und beschaltet? Ist die Bestückung richtig erfolgt? Alles sauber gelötet? Für erstes, wenn die umgebende HW nicht zu umfangreich und komplisiert, diese Mittels LabView und den passenden Steckern nachbauen / Kontrollieren / Steuern. oder die Orginalkomponente verwenden und mittels LabView überwachen und Kontrollieren / steuern. Bei der Variante sollte es prinzipiell egal sein ob da ein G45 oder ein pic oder sonst was die steuerung übernimmt. Quasie ein BlackBox test. Du testest ob die Orginal FW in dieser umgebung auf dem Board fehlerfrei funktioniert. Bei Variante 2 Spielt nicht die Funktionalität der FW in verbindung mit dem HW die rolle sondern nur die HW selber. die FW wird aussen vorgelassen. Hier hängt an den Steckern irgend welche Dummies für die Motoren / Relais, .... die LabView überwacht / Steuert. Hierbei ist es dann notwendig, das die FW dier entsprechende Testkommandos zur verfügung stellt. um an den Pins zu wackeln, die Motoren zu bewegen, Ströme einzustellen, ... I2C muss man ja nicht über die Leitung bis zum Stecker jagen um festzustellen ob der signalpfad funktioniert oder nicht. ein einfaches set High / set Low würde ja schon reichen. ggf stellt die FW auch gesonderte Selbst test rotinen zur verfügung, in denen die FW z.B. eine Schreib lese sequenz auf einen I2C baustein fährt und danach sagt, ob das erfolgreich war oder nicht. über welche Schnittstelle die FW konntaktiert wird, ist Design frage. was stellt dir deine HW denn zu der verfügung? RS232 über die DBUG schnittstelle oder eine andere? das ganze kann auch ganz ohne FW unterstützung über die JTAG Scann Chain erfolgen.
123 schrieb: > Bei Variante 2 Spielt nicht die Funktionalität der FW in verbindung mit > > dem HW die rolle sondern nur die HW selber. die FW wird aussen > > vorgelassen. Hier hängt an den Steckern irgend welche Dummies für die > > Motoren / Relais, .... die LabView überwacht / Steuert. > Also die Hardware selber mit den angeschlossenen Komponenten soll auf Funktion und Qualität getestet werden...Somit ist die Variante 2 genau richtig :) > > Hierbei ist es dann notwendig, das die FW dier entsprechende > > Testkommandos zur verfügung stellt. um an den Pins zu wackeln, die > > Motoren zu bewegen, Ströme einzustellen, ... I2C muss man ja nicht über > > die Leitung bis zum Stecker jagen um festzustellen ob der signalpfad > > funktioniert oder nicht. ein einfaches set High / set Low würde ja schon > > reichen. Genau diese Testkommandos werde ich brauchen...Nur die Frage ist, wie ich diese Testkommandos bereitstelle bzw. programmiere und wie ich sie über LabVIEW abfrage?? Da bin ich momentan nur am grübeln... > > > > ggf stellt die FW auch gesonderte Selbst test rotinen zur verfügung, in > > denen die FW z.B. eine Schreib lese sequenz auf einen I2C baustein fährt > > und danach sagt, ob das erfolgreich war oder nicht. > > > > über welche Schnittstelle die FW konntaktiert wird, ist Design frage. > > was stellt dir deine HW denn zu der verfügung? RS232 über die DBUG > > schnittstelle oder eine andere? Meine Hardware stellt eine RS232 über die Debug-Schnittstelle bereit. > > > > das ganze kann auch ganz ohne FW unterstützung über die JTAG Scann Chain > > erfolgen. Welche wäre den deinerseits besser...RS232 oder JTAG zum debuggen??
JTag Scan Chain Tools bereits vorhanden? Kennt jemand was frei verfügbares, und hat damit schon erfahrungen? Hätte da selber interesse dran. Sollen die Funktionen bestandteil der FW werden oder eine eigenständige FW? nächste frage, wann kommt die orginal FW auf das Board, vor dem Test oder danach? Wer entwickelt die FW? die steuern sowieso die HW an. Haben die ggf schon test funktionen an die man sich ranklemmen kann? Was läuft auf der RS232 schon? oder ist die nur für dich reserviert? (wenn keine eigenständige Test FW) wie bekommst du deine FW auf das Board? SD - Card RS232 (USB) Reichen 60Kb für deine Test FW aus? Ansonsten ist ggf ein Booter fällig. RS232 sollte LabView doch können. ups usb geht ja momentan nicht laut erata Gruss
123 schrieb: > JTag Scan Chain Tools bereits vorhanden? > > Kennt jemand was frei verfügbares, und hat damit schon erfahrungen? > > Hätte da selber interesse dran. > damit hatte ich leider noch keine Erfahrungen > > > Sollen die Funktionen bestandteil der FW werden oder eine eigenständige > > FW? Die Test-Funktionen in LabVIEW werden eigenständig behandelt... > > nächste frage, wann kommt die orginal FW auf das Board, vor dem Test > > oder > > danach? > Dies ist noch nicht sichergestellt...Möglichweise vor dem Test schon.. > > > Wer entwickelt die FW? die steuern sowieso die HW an. Haben die ggf > > schon test funktionen an die man sich ranklemmen kann? Die Firmware wird von einer Gruppe aus unserer Gruppe entwickelt und ist schon im fertigen Zustand... Kann ich wohl von denen einige Funktionsbausteine klauen und in LabVIEW einbinden womöglich?? > > > > Was läuft auf der RS232 schon? oder ist die nur für dich reserviert? > > (wenn keine eigenständige Test FW) Auf RS232 werden mehrere Komponenten laufen... > > wie bekommst du deine FW auf das Board? SD - Card RS232 (USB) Ich schätze über SD Karte? (Bin noch am Anfang dieses Projektes) > > Reichen 60Kb für deine Test FW aus? Weiß ich noch nicht > > Ansonsten ist ggf ein Booter fällig. > ??? > > > RS232 sollte LabView doch können. > Das tut es auch... > > > ups usb geht ja momentan nicht laut erata
Ok Läuft somit auf eine eigene Software raus. Wen der G45 von SD - Card Bootet, dann brauchst du für deine Tests nur eine spezielle SD - Card mit deiner Softwre drauf. Die Orginal SD - Card mit Orginal FW muss nur nach deinem Test wieder eingesetzt werden. (Bootkonzept sollte eigentlich schon stehen. das Board ist ja schon fertig) Booter werdet ihr dann schon haben. Der Interne BootCode des G45 kann nur ca 60KB code laden und ausführen. internes SRAM. alles andere muss dann von diesem Stück software erfolgen. DDR Ram init, umkopieren der Softare. z.B. UBoot für LINUX Von der fertigen FW kannst du sicher einiges erben. zumindest wäre das aus kostengründen sicher sinvoll. ggf können die ja auch einen teil davon implementieren, oder zumindestens dabei helfen. gruss. ps. test und qualifikation von selchen boards ist ein umfangreiches thema.
123 schrieb: > Wen der G45 von SD - Card Bootet, dann brauchst du für deine Tests nur > > eine spezielle SD - Card mit deiner Softwre drauf. Die Orginal SD - Card > > mit Orginal FW muss nur nach deinem Test wieder eingesetzt werden. > > (Bootkonzept sollte eigentlich schon stehen. das Board ist ja schon > > fertig) Hallo 123, also ich habe noch mal meinen Kollegen nachgefragt...Die SD-Karte wird nur zum Speichern von diversen Testparametern genutzt.. Für das Downloaden der Firmware, wird offiziell die RS232 bzw. die serielle Schnittstelle benutzt.. 123 schrieb: > ps. test und qualifikation von selchen boards ist ein umfangreiches > > thema. wie definierst du "umfangreich" ?? :))
Hallo zum Thema umfangreiche Tests. Die Leiterplatte kann vom Leiterplatten hersteller geprüft werden. Das Board kann beim Bestücker bereits ICT gestet werden und / oder Optisch untersucht werden. Wenn das gemacht wird, was kann danach noch kaput sein? was kann wann und wo beschädigt werden? Danach der Test den du machst. Was soll alles getestet werden. und Wie Tief soll der test gehen. reicht es über I2C den IC zu addressieren und zu prüfen ob er antwortet, oder ist ggf dessen Funktion noch zu kontrollieren. bei einen AD wandler die Werte auslesen und Validieren. Es gibt Leute die sich nur mit solchen sachen beschäftigen. Da kommen dann so sachen raus wie RS232 Loop Test. Frage: was kann alles beschädigt sein, das der Test fehl schlägt? Antwort: BGA lötpunkte, Verlötung Stecker, Verlötung Transiver, Transiver selber, umgebungsbeschaltung nicht korrekt, leiterbahnen durchtrennt, Vias nicht richtig gefertigt, ... Nächste frage: wann kann der Fehler passieren, und bei wem. hätte er nicht bereits vorher erkannt werden müssen, z.B. ICT test / Optischer test.
123 schrieb: > Hallo > > zum Thema umfangreiche Tests. > Die Leiterplatte kann vom Leiterplatten hersteller geprüft werden. > Das Board kann beim Bestücker bereits ICT gestet werden und / oder > Optisch untersucht werden. > > Wenn das gemacht wird, was kann danach noch kaput sein? was kann wann > und wo beschädigt werden? Ich denke nicht, dass wir so tief reingehen werden... > > Danach der Test den du machst. > Was soll alles getestet werden. und Wie Tief soll der test gehen. > reicht es über I2C den IC zu addressieren und zu prüfen ob er antwortet, > oder ist ggf dessen Funktion noch zu kontrollieren. bei einen AD wandler > die Werte auslesen und Validieren. Testbeispiel 1: - Test Kommunikationsherstellung I²C - Kommen die Temperaturwerte von Temperatursensoren richtig an? -> Wertevergleich (Funktionstest Temperatursensoren) Testbeispiel 2: - Test Kommunikationsherstellung LCD-Parallel - Test Display (mit allen möglichen Textvarianten, Vergleich mit Bitmuster) Testbeispiel 3: - A/D-Wandler - Wertevergleich - Test Funktion der A/D-Wandler so in der Art müssen die Testdurchläufe laufen... > > Es gibt Leute die sich nur mit solchen sachen beschäftigen. > Da kommen dann so sachen raus wie RS232 Loop Test. > Frage: was kann alles beschädigt sein, das der Test fehl schlägt? > Antwort: BGA lötpunkte, Verlötung Stecker, Verlötung Transiver, > Transiver selber, umgebungsbeschaltung nicht korrekt, leiterbahnen > durchtrennt, Vias nicht richtig gefertigt, ... > > Nächste frage: wann kann der Fehler passieren, und bei wem. hätte er > nicht bereits vorher erkannt werden müssen, z.B. ICT test / Optischer > test. Wann kann so ein Fehler passieren: z.B. ist ein Leistungsschütz abgebrannt und das System gibt einen Fehler aus...
Hallo Du hast ja die notwendigen Leute ja im Haus, Frag die doch mal wie die sich das vorstellen. Gerade was den ablauf betrifft FW einspielen, Starten deiner Test FW, ... Ich kenn deine HW nicht. Wie ist der Ram angebunden DDR SRAM extern intern, SPI Flash, paralel Flash, sdcard, i2C, von welchem speicher wird gebootet, .... Auch zu den Tests: die Elektronik entwickler werden genau wissen, wie man feststellen kann, das gewisse parts nicht funktionsfähig sind oder nicht. Es gibt wie gesagt viele möglichkeiten eine Schnittstelle zu testen. z.B. den I2C bus, wenn er extern rausgeführt ist. 1. die beiden pins mittels LabView überwachen, und über Deine FW an den Pins Toggeln. siehst du die von dir gesteuerte signalveränderung ist alles ok. 2. du schliest einen i2c baustein extern an, und betreibst die schnittstelle nicht mit PIO sondern mit der internen Peripheral. und liest z.b. speicherstellen aus und gibst dir diese über die RS232 aus. Da du weist, was im speicher stehen sollte, kannst du darauf zurückschliesen ob der test erfolgreich war oder nicht. 3. wie test 2, nur das du hierbei über einen Protokoll analyser oder eine schnellgenuge TI Karte den Buss aufzeichnest und auswertest. Zappelt der Buss wie erwartet, kommt das was ich da als antwort auf dem Bus gesehen habe auch auf der RS232 zurück, ... 4 ... Bei motoren z.B. 1. Lastwiederstand beschalten, über die RS232 den Motor bestromen lassen (links / rechts lauf, maximalstrom, anzahl steps dauer geschwindigkeit ), und die aufgenommene Leistung messen, und polung überprüfen. 2. echten Motor anschliesen, über die RS232 den Motor Starten, und die aufgenommene Leistung Messen. (wie belaste ich den Motor, der hat ja keine Last zu bewegen und verhält sich dadurch nicht wie im echten system)
Ok ich bin davon ausgegangen, daß das ein Test in der Fertigung werden soll. So wie ich das jetzt raushöhre, soll der auch für die Reperatur verwendet werden, wenn z.B. boards mit fehlern aus dem Feld zurückkommen.
123 schrieb: > ich bin davon ausgegangen, daß das ein Test in der Fertigung werden > soll. > Neee das soll ein Test nach der Fertigung sein... > So wie ich das jetzt raushöhre, soll der auch für die Reperatur > verwendet werden, wenn z.B. boards mit fehlern aus dem Feld > zurückkommen. Dadurch dass es sich erstmal um einen Prototyp handelt, (später automatisierte Herstellung) geht es erstmal grundsätzlich um die Funktion der Komponenten
Hallo Fitzel Fatzel, :) hast mir wohl nachspioniert? Hast mein Xing-Profil entdeckt
Scheinbar wurde für den Atmel bereits ein UDP-Protokoll fertig geschrieben... Ist dies als eine Art Bootloader zu sehen??? Vielleicht könnte ich dadurch auf die Pins zugreifen und mit diesen kommunizieren und die notwendigen Daten rausholen?? Ich muss zugeben ich werde einiges an Info hier rausziehen müssen, da ich während Studium wirklich nur sehr theoretisch damit konfrontiert war... Vlg yesim
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.