Hardware > Hardware (Classic 16-/32-Bit)

MiST - erster Kontakt

<< < (3/6) > >>

guest3744:
Genug der Theorie!

Hier ist der Boardsatz aus meiner Praxis:
DE0, DE1 und das Parallax-Board(Propeller).
Rechts auf dem Parallax-Board sitzt der DE-Nano
der einen 2. Propeller nachbildet zu 100%.

Gruss

MiST:

--- Zitat von: peter hold am Sa 10.10.2015, 13:05:37 ---czietz, ja bei mir funktionierte ein FPGA (35 Euro) nicht mehr.

--- Ende Zitat ---
Natürlich kann man Hardware zerstören, vor allem, wenn man irgendwas dran rumlötet oder auf eigene Faust Dinge zusammen steckt, die nicht zusammen gehören. Und genau darum lohnt es sich. einer Anleitung zu folgen. Die ist schlauerweise so aufgebaut, dass man keinen Schaden anrichten kann.


--- Zitat von: peter hold ---Habe mit den Quartus einfach die Pins zugeordnet, gegeneinander und undefinierte Zustände.
Beim durchlesen der Beschreibung (zu spät...) vom FPGA stand etwas , was ich aber nicht begriffen hatte mangels Englischkenntnisse.

--- Ende Zitat ---
Diese Aussagen verstehe ich nicht. Also ums abzukürzen: Ich ersetze 2 komplette MISTs dem ersten, der es schafft mir eine FPGA-Config-Datei zu erzeugen, die das MIST beschädigt. Einzige Ausnahme: Die Pin-Zuordnung in der QSF-Datei soll dem entsprechen, was ich auch in den c't-Artikeln immer mitliefere (deshalb liefere ich es ja mit). In dieser Datei kann man nämlich jeden Pin des FPGA zu Ausgang erklären und ihn damit potenziell gegen einen anderen Ausgangspin auf dem Board treiben lassen. ABER: Erstens glaube ich auch nicht, dass man damit Schaden anrichten kann. Das wäre mir nach Jahren des Bastelns sicher mal passiert. Und zweitens ist das FPGA auf dem MIST mit sehr wenigen Ausgangspins anderer Chips verbunden, so dass man den Zustand sogar mit Absicht nur schwer herstellen kann. Aber wie gesagt: Wer es als erster schafft mir eine Core-Datei zu schicken, die das Board zerstört bekommt zwei neue.

Bitte stelle hier einen kurzen Code-Schnippsel rein, von dem Du meinst, dass man damit ein FPGA beschädigen kann. ich schaue mir das sehr gerne mal an.


--- Zitat von: peter hold ---Da habe ich gemerkt das ein FPGA kein Atmegeá ist, die ich vorher für meine Roboter programmiert habe mit BASCOM. Habe damals nicht begriffen , das im FPGA sogenannte Drahtverbindungen hergestellt werden, ich dachte es ist nur Software die draufkommt.

--- Ende Zitat ---
Doch, es ist genau das gleiche. Bei einem FPGA wie bei einem Atmega schaffst Du es bestenfalls, Pins auf Ausgang zu schalten, die ihrerseits mit einem Ausgang eines anderen Chips verbunden sind. Das führt potenziell zu einer leichten Überlastung dieser Pins. Das kann einem beim Atmega sogar leichter passieren, denn das ist diese Umschaltung Teil des eigentlichen Softwareprogramms. Beim FPGA müsste man dazu in der QSF-Datei rumändern, wozu man aber während der Core-Entwicklung keinen Grund hat.

Und "Drahtverbindungen" stellt man natürlich auch nicht her. Da sind keine "Drähte" im FPGA, die sich irgendwie bewegen lassen. Verbindungen werden Chip-Intern durch kleine steuerbare Schaltelemente hergestellt. Nix anderes passiert in einem Atmega, wenn man an einen Pin die Richtung umschaltet oder ähnlich.

Es passiert auch nichts, wenn man versehentlich eine völlig falsche Datei versucht in das FPGA zu laden (eine Word-Datei, die man passend umbenennt z.B.). Das FPGA merkt das, quittiert die Übertragung nicht, das wiederum merkt der Arm-Controller und der blinkt dann mit der LED, um anzuzeigen, dass der Download nicht geklappt hat.

Es gibt ein paar Leute, die seit mehreren Jahren fast täglich neuen FPGA-Code auf ihr MIST laden und testen. Dabei passieren uns natürlich alle möglichen Fehler. Dabei ist noch nie irgendwas beschädigt worden.

Bitte liefert ein paar Beispiel für solche Warnungen. Alles andere ist nicht konstruktiv.

MiST:

--- Zitat von: peter hold ---Pinleisten und  dem Programm "Quartus", weil man die eigenen VHDL-Beschreibungen auch behalten möchte wenn der MIST ausgeschaltet ist.

--- Ende Zitat ---
Mit "Pinleisten" meinst Du den JTAG-Stecker, den man nachrüsten kann, ja? Über den wird nichts geflasht. Alles ist RAM-basiert und alles geht verloren, wenn das Gerät ausgeschaltet ist. Das einzige, was auf dem MIST geflasht wird ist der Arm-Controller. Und dazu hast Du als Core-Entwickler tatsächlich keinen Grund und das wird auch im c't-Artikel nicht weiter erwähnt.

Nur zur Vollständigkeit: Den Arm kann man auch nicht durch Flashen beschädigen. Man kann ihn allerdings mit eigenem Unsinn-Code so flashen, dass das Board nicht mehr bootet und weitere Updates über SD-Karte nicht mehr klappen. Man muss dann einen Jumper schließen und einen PC zur Hilfe nehmen, um es wieder ans Laufen zu bekommen. Aber "bricken" kann man das MIST generell nicht, man kann es sich schlimmstenfalls etwas schwieriger machen, eine neue/heile Firmware auf den Arm-Controller zu laden.


--- Zitat von: peter hold ---Natürlich kann man ein FPGA zerkonfigurieren. zB unbeschaltete Pins als
Eingänge schalten. Dann gehen die auf einen unbestimmten Zustand und
ziehen Strom wie verrückt. Das Powersupply bringt die Spannung nicht mehr
und mit der halben Spannung kann nicht neu programmiert werden. Nach
einer halben Minute ist der Chip hin.

--- Ende Zitat ---
Es gibt/gab Chips, bei denen offene Eingänge anfangen können zu schwingen und deren Stromverbrauch dann deutlich steigt. Wenn das bei einem FPGA passieren könnte, dann könnte niemand ein FPGA sinnvoll einsetzen, denn direkt nach dem Einschalten des FPGAs ist es unkonfiguriert (ist ja alles nur RAM-basiert im FPGA) und alle Pins sind erstmal als Eingang geschaltet (ist übrigens beim Atmega direkt nach dem Einschalten genauso). Und das FPGA würde ja sofort genau dieses Schwing-Verhalten zeigen und kaputt gehen. Das passiert offensichtlich nicht ...

Also: 1. passiert das nicht und 2. hättest Du das gleiche Problem ja z.B. beim Atmega. Hast Du aber auch dort nicht, weil die Hersteller sowas verhindern.


--- Zitat ---Der sich mit den Reklamationen rumschlagen muss sitzt in Polen.

--- Ende Zitat ---
Jepp. Mit dem arbeite ich zusammen und wenn der ein Problem hätte wäre ich der erste, bei dem er sich beschweren würde. Tut er aber nicht.


--- Zitat ---Aber trotzdem viel Spass mit dem MIST und den offiziellen CORES.
Meine Core-Heimat ist der ST/STE auf dem MIST, die Hardwarebeschreibung liegt da fast bei 100%
Auch der Core vom ATARI800 hat auch schon einen über  99%zigen Beschreibungsstand erreicht auf dem MIST.

--- Ende Zitat ---

Finde ich wirklich toll, dass Du da Spass mit hast und Dir das Gerät gefällt. Umso wichtiger ist mir, dass Du mir glaubst, dass ich mit diesen Anleitungen nicht das Leben Deines teuren Spielzeugs riskiere. Ich glaube Dir gerne, dass Dir mal ein FPGA kaputt gegangen ist, aber durch so einfache Experimente wie ich sie vorschlage passiert da nichts.

Die meisten offizellen Cores sind ja von mir und ich beschreibe in der c't praktisch genau das, was ich selbst da mache.

guest3744:

--- Zitat ---denn direkt nach dem Einschalten des FPGAs ist es unkonfiguriert (ist ja alles nur RAM-basiert im FPGA) und alle Pins sind erstmal als Eingang

--- Ende Zitat ---

Jedes gute Board hat eine Beschreibung im FPGA, die beim starten ein Test durchschaltet , so das alle Componenten eine definierten Zustand haben. Dieses kann man durch flashen überspielen und zb sein eigene Beschreibung beim Einschalten setzen.

Der CPC-Core ist derart beschissen , das der Anwender den BIN-Code reinspielen soll mit Sam-Ba zb und mit diesem CPC-BIN-Code kann man den MIST nur wieder mit SAM-BA und einem originalen BIN überspielen, damit der MIST überhaupt wieder einen anderen Core annimmt.

GRuss

guest3744:
Mach mal bitte eine Erweiterungsbeschreibung für den ST-Core , das man über USB auch einen RS232-USB betreiben kann.

GRuss

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete