Manchmal umgekehrt. Ok, war nicht Hobby, aber ein junger Ingenieur bei einem Kunden: Sein Design lief, meistens. Hin und wieder aber auch nicht, je nach Marskonstellation, Windrichtung und Anzahl schwarzer Kater. Dann fragte ich ihn nach Brown-Out Reset. "Aehm, das ist im uC doch alles drin". Kurzes Wuehlen im Datenblatt. Ja, einen Power-on Reset hatten sie drin. Allerdings einen IMHO recht schlabberigen. Aber den Brown-Out Fall packte das Dingen nicht. Eigentlich ein Armutszeignis fuer das uC Design-Team, doch was will man machen? Haben wir also einen externen BOR gebaut und danach war alles paletti. BOR ist gerade auch bei der MSP430 Serie so eine Sache. F2xxx hat es m.W. drin, aber etliche aletere aus mir unerklaerlichen Gruenden nicht.
Wollte mich jetzt vor allem erstmal bei allen bedanken, die mir hier so nett geholfen haben.
Habe mir jetzt mal einiges an Hardware bestellt. Ich glaube das "so billige wie m=C3=B6glich" h=C3=A4tte ich anders schreiben sollen... Das gan= ze soll eine Art kleines Hobby werden. So grob hab ich jetzt ca. 50=E2=82=AC ausgegeben und das ist durchaus noch ok. :-)
Also Controller hab ich jetzt den ATmega16 gew=C3=A4hlt. Mal sehen wie weit ich damit komme... AVR-Studio hab ich auch schon installiert und einige Tests gemacht. Ich denke damit komme ich sehr gut klar. Bin mir im moment eigentlich nur nicht ganz sicher, ob "AVR Entwicklungsplatine (ATmega16)" und "AVR-In-System-Programmer" aus dem Shop bei Mikrocontroller die richge Wahl war. Kann ich damit den Controller programmieren?
Ich denke schon, bin aber auch Neueinsteiger, resp. "Wiedereinsteiger"
- mein letzter Kontakt auf dem Gebiet war vor ca. 25 Jahren mit 8080, Z80, 6502 & Co.
Ich habe mich für eigene kleine Projekte mit dem ATMega8 angefreundet, vorher allerdings Gelegenheit gehabt mit einer fertigen Platine (ATMega128 Board) Erfahrungen zu sammeln.
Im Unterschied zu früher ist es schon erstaunlich dass man mit (meinen) sehr überschaubaren Elektronik- und Lötkenntnissen, einem 28 poligen Käferchen und ein paar Drähten (ISP-Stecker, USB-Stromklau, ein paar LEDs und Taster) schon ein lauffähiges uC-System zusammenkriegt, ohne aufwändige Stromversorgung(en), Quarz/Taktgenerator, 2764, UV-Lampe, externer Prommer, Port Controller, 6116, etc. etc.
Der Programmer wird Dir wahrscheinlich länger gute Dienste leisten wie das Experimentierboard, aber für den Anfang ist es gut, wenn die einzige Schraube an der man zwecks Fehlerdiagnose / Behebung drehen muss die eigene Software ist, und man Fehler in der Schaltung oder dem Programmer erstmal ausschliessen kann.
Später wirst Du wahrscheinlich die Software nicht mit dem Experimentierboard entwickeln, sondern in der Zielhardware.
WinAVR hast Du wahrscheinlich auch schon gefunden - ich komme inzwischen mit gcc, make und UltraEdit ganz gut ohne AVRStudio zurecht.
Ironie aus Mangel an Bedarf entsorgt, aber wo bleibt das Positive, Herr Kästner :-)
Das Thema sieht ggf. mit JTAG-Möglichkeiten anders aus, ich hab' (wie der OP) nur einen ISP-Programmer zur Verfügung.
Nach Studium der Debugging- und Simulationsmöglichkeiten in AVRStudio kam mir das Ganze in diesem Rahmen doch recht akademisch vor - nett um den Chip kennenzulernen, aber ich konnte mir nicht vorstellen, die Hardware duch manuelles Togglen von Registerbits (oder statische Stimuli-Dateien) abzubilden, resp. ich stelle es mir recht mühselig vor.
Einen Simulator/Debugger Plugin-Mechanismus (Anwender-DLL die Zustands-Änderungen mitkriegt und ihrerseits die Aussenwelt abbildet) mag es geben, (es scheint z.B. möglich, bestimmte LCD zu emulieren) eine entsprechende Beschreibung zum "Selbermachen" habe ich aber nicht gefunden.
Die Liste der "Known Simulator Issues" war auch eher wenig vertrauenerweckend - der Löwenanteil der Doku zum Thema Simulator beschreibt, was alles nicht unterstützt wird oder nur eingeschränkt funktioniert.
Vielleicht tue ich dem Teil aber auch Unrecht und hab' zu schnell aufgegeben - Use cases und Success stories (im Kontext ISP) willkommen, auch zweckdienliche Hinweise auf eine evtl. existierende Plugin API(-Doku) ...
Also zumindest das Debugging ist schonmal sehr sinnvoll, um Fehler in der Implementierung allgemeiner Algorithmen zu finden und nicht zuletzt auch Compilerfehler. Das funktioniert mit AVR-Studio auf jeden Fall. Sogar die Fehler des AVR-Assemblers selber kann man auf diese Art finden. ;)
Umfassende Qualitätssicherung von Software IST mühselig. Niemand hat je etwas anderes behauptet. Außer irgendwelchen Marketingfuzzies und die lügen eh' wie gedruckt.
Ja, es gibt diese Möglichkeit, aber sie ist leider _nicht_ vom AVR-Studio selber vorgesehen, sondern mehr oder weniger per reverse engineering (oder vielleicht auch durch Anwendung von Wissen, was unter NDA-Bedingungen erworben wurde) drangestrickt worden.
Als Beispiel fällt mir da Hapsim ein. Diese Lösung ist weder besonders schön noch wirklich eine auch nur näherungsweise treffende Simulation der Hardware, weil jegliche Timingaspekte dabei weitgehend unter den Tisch fallen. Die im AVR-Studio eingebaute Simulation der AVR-Hardware und deren Anregung per Stimuli ist hingegen immerhin wenigstens synchron.
Hmm, erinnert mich irgendwie an die Doku von gcc. Und der hat immerhin nur die Aufgabe, eine genau beschriebene formale Sprache in eine andere, ebenfalls genau beschriebene zu übersetzen, ganz ohne zusätzliche Stimuli _während_ seiner Arbeit...
Wie schon gesagt: Externe Hardware läßt sich derzeit höchsten sehr unvollkommen an eine AVR-Studio-Simulation dranstricken. Für richtig kitzlige Sachen bleibt in-circuit-debugging via JTAG deshalb fast unerläßlich. Geht mit AVR-Studio, geht nicht mit der von dir genannten Toolchain.
Aber der eigentliche Punkt ist:
Mit der von dir empfehlenen Toolchain ist nichtmal primitivstes und unvollkommenstes Debugging in irgendeiner Form möglich, von Simulation gleich ganz zu schweigen. Gegen diesen Zustand ist das Gespann aus AVR-Studio und Hapsim selbst mit all ihren Macken, Fehlern und Unzulänglichkeiten immer noch das pure Gold. (Inbesondere natürlich, wenn man sich über die Macken, Fehler und Limitierungen jederzeit im Klaren ist und seine Fehlersuchstrategie entsprechend einrichtet)
|> Aber der eigentliche Punkt ist: |> |> Mit der von dir empfehlenen Toolchain ist nichtmal primitivstes und |> unvollkommenstes Debugging in irgendeiner Form möglich, von Simulation |> gleich ganz zu schweigen.
Kann man auch ohne recht gut leben, solange man 1-2Leds oder gar RS232 dran hat. Man kann auch in Schönheit sterben...
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Was sollen dann gdb, insight und avarice in WinAVR? Richtig, debuggen via JTAG. Es ist auch noch simulavr als Simulator dabei, der ist allerdings in der Tat höchst unvollständig, da nur wenige Controller unterstützt werden.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.