Hi Jens,
ich quote es mal:
Ich hatte die Hoffnung, dass mein Eva-Board irgendwie direkter unterstützt wird. Für das STK600 gibt es unter Templates/AtmelBoards ja einiges. Und auch bei den ASF examples ist das STK600 aufgeführt. Ich bin nur verunsichert, warum das STK500 dort nicht aufgeführt ist
Erfordert das STK600 einfach "mehr drumherum" ?
Ich denke es ist viel einfacher, das STK500 Board ist ja schon etwas älter, deswegen hatte Atmel einfach kein Bock mehr das Board in AS6 mit aufzunehmen.
Das STK600 frißt ja alles, angefangen von megaAVR bis hin zu den UC3.
Auch wenn STK600 dort nicht aufgeführt ist, macht es nichts, die MCU ist ja unabhängig vom Board.
Flashen geht also nicht ohne Zusatzhardware. Das hatte ich wegen Standalone-Fähigkeit erwartet/erhofft.
Die von Dir erwähnten AVRDragon und AVRISP mkII werden im Atmel Studio unter "Supported Tools" des uC genannt. Sehe ich das richtig, dass diese Tools die Programmer, Debugger,... sind?
Jein.
Der AVRISP mkII ist ein reiner Programmer.
Der Dragon ist sowohl Debugger als auch Programmer. Der Dragon hat hat einen ISP-Anschluß (nur flashen), JTAG (debug + flashen), HV (programmieren über high voltage), debugWire (wie der Name schon sagt, ein Debugger). Es ist halt so, dass nicht jede MCU über einen JTAG-Interface verfügt (wobei die größeren es haben), deswegen kannst Du sie dann nur über debugWire oder gar nicht debuggen. ISP ist aber immer da, darüber wird die MCU geflashed. Über JTAG geht sowohl flashen als auch debuggen.
Gerade für Anfänger halte ich persönlich einen Debugger für wichtig. Die "Erfahreneren" können da eher sehen, woran es happert, aber oft ist es schon sehr hilfreich zu sehen, was tatsächlich in den Register steht.
Jetzt ist unter diesen Tools das STK500 nicht aufgeführt - aber das STK600 schon
Okay, das ist dann auch die Erklärung, warum STK500 nicht am Anfang auftaucht, das wird vom AS 6 gar nicht unterstützt.
Bzgl. Doku habe ich schon die beigelegte CD, Atmel und diverse Foren durchwühlt. Alle Beschreibungen sind auf die Board-Revision 1.0 ausgerichtet. Dort ist zumindest eine Steckerleiste für die I/O Ports aufgelötet, der Lichtsensor bestückt und - manchmal - die beiden 40-poligen Stiftleisten am Rand (zum Aufstecken auf das STK500) bestückt.
Ich habe Board-Rev 1.1: Kein LDR, keine Stiftleisten für I/O und STK500 Konnektivität. Darüberhinaus ist das im Manual beschrieben Testprogramm (LED-Blinken) nicht vorhanden. Das Board habe ich von Reichelt, also hoffentlich kein zerflashtes.
Das kann einfach sein, dass sie bei der Rev 1.1 etwas eingespart haben, kommt ja häufig vor. Aber das Board hat sowohl JTAG als auch ISP Interfaces, also perfekt. Mit dem Dragon könntest Du die MCU auch debuggen.
Bzgl. CAN:
Ja, es geht um einen Fahrzeug-CAN. Dass es dabei viele Klippen gibt habe ich erwartet, wenn auch nicht in diesem Ausmass. CAN-Manipulationen mit CANalyzer und CAPL sind mir nicht fremd. Hast Du mir eventuell mehr Infos zu den potentiellen rechtlichen Problemen? (gerne auch als PM)
Danke, Jens
Das Problem ist halt, dass am CAN Bus noch sowas wie ABS, ESP und der ganze Geraffel dran hängt. Wenn Du mit Deinen Exterimenten die Kommunikation irgendwie beeinträgtigst, sprich Buscollision oder weiß der Geier was, gehen die SGs in's Notprogramm und Ruhe ist. Dann hast Du halt kein ABS. Aber sollte es krachen und es kommt raus, wird die Versicherung versuchen Dir einen Strick draus zu drehen und da kann es häßlich werden. Da musst Du nämlich beweisen, dass Deine Modifikationen nichts mit dem Unfall zu tun haben und genau das ist alles andere als einfach. Das muss man halt im Hinterkopf behalten.
Und nach dem Prinzip Finger-Arm schiebe ich gleich noch eine Frage nach
Ich habe ein Paket mit Beispielen gefunden. Unter anderem jeweils ein *.c und *.h für bequemeres Ansteuern der LEDs sowie Auslesen der Taster.
In den *.c wird nicht nur die korrespondierende *.h inkludiert, sondern zusätzlich eine config.h
Diese config.h liegt aber nicht bereit. Dafür finden sich diverse unterscheidliche config.h bei anderen Beispielen.
Eine davon habe ich meinem Projekt hinzugefügt - und konnte dann auch compilieren.
Ist es "normal", dass die ersten Schritte so erschwert werden? Oder ist das DVK90CAN1 eben eher was für den fortgeschrittenen Bastler?
Danke, Jens
Naja, in der config.h kann alles mögliche drin sein, irgendwelche Macros für die Konfiguration. Das kann man machen, aber ob man es macht, ist immer so eine Sache. Viele (mich inklusive) machen zum Beispiel eine separate .c-Datei, in der die ganzen ISRs drin sind. Das mache ich aber nur bei der Cortex-MCU, beim Atmega mache ich sowas nicht.
Der AT90CAN128 scheint ein Atmega mit einem integrierten CAN-Controller zu sein, also was änliches wie ATA6613 nur mit LIN. Deswegen egal auf was für einem Board er drauf ist, die MCU ist wichtig. Das drumherum ist nur die Peripherie. Solange die MCU von der IDE unterstützt wird, ist der Rest völlig egal. Diese EVA-Boards sind ganz nett, wenn Du reinschnuppern willst oder wenn Du ein Projekt vor Augen hast. Aber am Ende wird eh eine eigene Schaltung dafür gebaut. Oder das Projekt verworfen. Ich habe hier ein EVA-Board von Steitec.net liegen. Da ist ein LPC1768 drauf. Die MCU wird von der IDE unterstützt, aber das Board kennt die IDE ist. Und? Wenn interessiert es? MCU + Debugger werden unterstützt, also passt es.
Da die MCU nur einen CAN-Controller drauf hat, brauchst Du noch einen CAN-Transceiver. Da kann ich Dir den TJA104x empfehlen, ist bombensicher das Teil. Ist für High-Speed. Für LowSpeed müsste ich nachschauen.
Das Board scheint auch eher etwas älter zu sein. Vielleicht gibt es deswegen nicht so viele Beispiele dafür. Oder es ist einfach nicht zu sehr verbreitet.
Grüße
Heinrich