Entwicklung eines "Debug Tool's"

Und was soll das bringen? Viel Arbeit, wenig Nutzen. Um was zu debuggen, 
muß ständig im zu debuggenden Programm rumgewurschtelt werden. Der 
ICE200 ist doch wirklich preiswert geworden, man kann mit AVR-Studio 
arbeiten, beliebige Breakpoints, Einzelschritt, jederzeit kompletten 
Prozessorstatus -was will man mehr??

Mich würde viel eher ein JTAG Debugger interessieren

Hallo crazy horse,

Was kostet der ICE200 zur Zeit, und welche AVR's unterstützt er ?

----------------------------------
Hallo Markus,

ich bin für alles offen !

leider weiß ich aber nicht genau was ein JTAG Debugger ist bzw. wie er 
funktioniert.

Kannst du mich ein wenig aufklären ?

JTAG ist ein standartisiertes Interface, das es ermöglicht, ohne den 
Ablauf des Prozessors zu beeinflussen, sämtliche Register auszulesen. 
Das Interface ist der SPI Schnittstelle ziemlic hähnlich, d.h. es gibt 
auch zwei Daten- und eine Taktleitung. Es gibt noch eine vierte, aber da 
weiß ich nicht mehr wozu die ist.
Dieses Interface haben aber nicht alle Controller. Die neuen Mega AVR 
haben das z.B. Mit einem 8515 oder 4433 gehts nicht.
Über dieses Interface kann man auch den Flash und das EEPROM 
programmieren, ähnlich wie über SPI.
Ich bin allerdings auch noch nicht richtig tief in die Materie 
eingestiegen

Gruß
Markus

Ich versuch auch gerade sowas zu machen, aber mit einem einzigen µC, 
nämlich dem, der am Ende das fertige Programm auch ausführt. Dazu will 
ich ein spezielles Programm schreiben, das auf dem µC ausgeführt wird 
und nur das macht, was es über den URAT mitgeteilt bekommt. Am PC soll 
dann ein Simulator laufen, der das eigentliche Programm ausführt und nur 
Sachen wie z.B. Portzustand ändern, PWM, ADC, etc. an den µC übergibt. 
Die einzigen Probleme die es geben kann sind:
1. Keinen Verbindung über den URAT zu anderen Geräten als dem PC
2. Evtl. kein Echtzeitverhalten
Zum Punkt 2: Ich werde versuchen den Simulator deutlich schneller als 
das AVR-Studio zu machen. Jedoch können über die serielle Schnittstelle 
nicht schnellgenug Datenübertragen werden um z.B. einen Port bei jedem 
Zyklus eines 8MHz prozessors umzuschalten. Solche Situation dürfen aber 
eher selten sein und man könnte ja evtl. die Daten bereit puffern.
Diese Lösung hätte den Vorteil komplett auf andere Hardware (außer dem 
meist sowieso schon vorhandenen MAX232) verzichten zu können und dabei 
auch ein Schritt für Schritt debuging ohne dauerndes Flashen des µCs zu 
ermöglichen. Auch Variablenwerte ließen sich während dem Ablauf der 
Software ändern um die Auswikungen auf das System zu sehen (ähnlich wie 
bei Delphi).

Die Software für den µC sollte in C und die für den PC in Delphi 5 oder 
6 geschrieben werden.
Ich würde mich freuen wenn du dich meinem Projekt anschließen möchtest. 
Jeder andere kann natürlich auch mitarbeiten.

Hermann
P.S.: Das ICE200 ist in der Hilfe des AVR-Studios gut dokumentiert. Was 
es kostet weiß ich aber auch nicht.

Der ICE200 kostet 99$, also im Moment incl. MwSt 116 Euro, unterstützt 
alle Classic-AVR und ist wirklich zu empfehlen. Die meisten 
Elektronikanbieter haben allerdings "vergessen", Atmels Preissenkung 
weiterzugeben (allen voran im Preis natürlich wie immer Conrad, da 
kostet der nach wie vor stolze 349 Euro).
Wer einen braucht, Mail.

Hallo Markus,

ist das AVR-JTAG-Interface Protokoll dokumentiert ? Dann könnte man 
einen solchen "Umwandler" zwischen Ziel-AVR und AVR-Studio entwickeln 
...

Bist du an der Entwicklung eines solchen Gerätes interresiert ?
--------------------------------------

Hallo Andreas,

Was kostet ein solcher JTAG-Debugger ? Besitzt jemand einen ? Gibt es 
Schaltpläne ...?

Warum ist es nützlicher einen GDB-kompatiblen Monitor zu schreiben ? Ich 
denke, wenn überhaupt, wäre besser ein AVR-studio 4 Plugin zu schreiben 
...
--------------------------------------

Hallo Hermann,

Die Idee ist nicht unbedingt schlecht, aber sehr Aufwendig ...
--------------------------------------

Hallo crazy horse,

Wo kann ich den ICE200 für 116€ kaufen / bestellen ?

Sollen die Mega`s nicht die AT90S Serie ablösen ?
--------------------------------------


Gruß Matthias

Hallo Freunde,

ich habe folgendes über JTAG ICE gefunden:

Das JTAG ICE habe ich zum Preis von 299 Dollar gesehen.

Das JTAG Interface an den AVR's wird ein wenig in dem Datenblatt zum 
ATmega128 beschrieben.

Das Protokoll zwischen AVR-Studio und JTAG-ICE wird komplett in der 
Application Note 60 beschrieben.

Das On-Chip-Debugging Protokoll zwischen AVR und dem JTAG ICE ist 
geheim. Dies stellt uns vor Probleme ...


Gruß Matthias

>Das On-Chip-Debugging Protokoll zwischen AVR und dem JTAG ICE ist
>geheim. Dies stellt uns vor Probleme ...
Könnte das evtl. identisch mit dem von National verwendeten Protokoll 
sein? Ich glaub das ist nämlich dokumentiert.

>Warum ist es nützlicher einen GDB-kompatiblen Monitor zu
>schreiben ?
Würde mich auch interessieren. Ich denke Windows ist und bleibt(leider) 
die häufigste Entwicklungsplattform. Und ich kann mir nicht vorstellen, 
das es einfacher ist das ganze Ding zu portieren und anschließend auch 
noch zu updaten, als gleich etwas ganz neues zu schreiben.

> Ich denke, wenn überhaupt, wäre besser ein AVR-studio 4 Plugin
>zu schreiben ...
Warum für AVR-Studio 4? Ich hab gehört da gibt's mit manchen µCs 
Probleme. Das ist zwar jetzt ein bisschen OT, aber was findet ihr 
besser? Version 3 oder 4?

>Die Idee ist nicht unbedingt schlecht, aber sehr Aufwendig ...
So aufwändig würde ich sagen ist das ganze garnicht. Du muss vielleicht 
100Befehle emulieren, fast alle davon sind durch Hochsprachenbefehle 
problemlos machbar. Dann noch ein bisschen Kommunikation mit dem Chip. 
Und manche Befehle kannst du dir einfach sparen, wie z.B. NOP, BREAK, 
und die ganzen die Testen ob ein bestimmtes Bit (nicht) gesetzt 
ist(BRCS, BRCC, BRVS, BRVC). Die sind alle schon durch BRBS, BRBC 
erledigt. Schwierig wird's nur wenn du versuchen willst das in Echtzeit 
zu machen. Aber so das durchschnittliche Programm sollte nicht langsamer 
als 2fach laufen.

Hallo Hermann,

>Könnte das evtl. identisch mit dem von National verwendeten >Protokoll sein? Ich 
glaub das ist nämlich dokumentiert.
Hast du über daß Protokoll von National irgendwelche Informationen ?

Soweit ich gehört habe, ist es möglich eigene Plugins für's AVR Studio 4 
zu schreiben. Dadurch müsste man daß Rad nicht neu erfinden.

Du sagtest, das µP Programm soll in C geschrieben werden. Davon möchte 
ich abraten, da der Assembler Freeware ist, und die meisten (zumindest 
die erschwinglichen) C - Compiler noch nicht ausgereift sind. Und das 
Programm würde dadurch kleiner und schneller.


Ich habe noch nicht ganz verstanden wie daß ganze funktionieren soll. 
Was ich denke:

Du möchtest den Ziel - AVR benutzen ? D.h. für jeden AVR ein seperates 
Programm Programm schreiben, mit dem er "ferngesteuert" werden kann ? 
Warum nicht einen großen AVR, und ihn über Adapter in die Zielschaltung 
einsetzten?

Ein weiterer Nachteil ist, daß du den UART verwenden willst, der dadurch 
für das eigentliche Programm "gestorben" ist. Meiner Meinung nach, wird 
der UART oft / meistens verwendet.

Das eigentliche Programm möchtest du dann per Software im PC emulieren ? 
Dann brauchst du einen "Emulator" - Kern für jeden AVR !?

Wie soll dieses "Emulieren" und debuggen funktionieren ? Möchtest du auf 
der Basis des "Hex" Files oder / und des Quellcodes emulieren ? Dann 
brauchst du evtl. einen "Interpreter" für die jeweilige 
Programmiersprache ...

Das eigentliche "Frontend" / die graphische Oberfläche wird (meiner 
Meinung nach) auch sehr aufwendig:

- MDI Sourcecode Editor (Betrachter) inkl. Brachpoints, Syntax 
Highlighting ...
- Die ganzen Fenster für Register, Prozessor I/O ...
...
...


Daher kann ich nicht ganz nachvollziehen, daß du meinst, dies sei nicht 
viel Aufwand ...
Daher auch mein Vorschlag, daß ganze über ein Plugin im AVR - Studio 4 
zu realisieren, da dort das eigentliche Frontend schon vorhanden ist ...


Gruß
Matthias

Aber zum Schreiben von Pluggins müßte Studio 4.0 mal endlich aus dem 
Alpha Status. Siehe auch www.avrfreaks.net

Hi Matthias,

>Hast du über daß Protokoll von National irgendwelche Informationen ?
Ich hab gemeint mal was darüber gelesen zu haben, kann mich aber leider 
im Moment nicht mehr erinnern wo. Schau doch mal auf der HP 
(www.nsc.com) nach. Ich glaub die ganzen Flashtypen unterstützen das 
Protokoll. Evtl. einfach mal ein Datenblatt runterladen.

>Soweit ich gehört habe, ist es möglich eigene Plugins für's AVR Studio 4 zu 
schreiben. Dadurch >müsste man daß Rad nicht neu erfinden.


>die meisten (zumindest die erschwinglichen) C - Compiler noch nicht ausgereift 
sind.
Hast du schon mal AVR-GCC probiert. Finde ich nicht schlecht. Evtl. muss 
man den C-Code etwas Compilerfreundlich gestalten, aber ich glaube das 
es kein Problem sein sollte alles in 4kb unterzubringen.

>Und das Programm würde dadurch kleiner und schneller.
>D.h. für jeden AVR ein seperates Programm Programm schreiben,
Das das Prog. durch ASM effektiver wird ist klar, aber bei ASM hast du 
eben das Problem, mit dem verschiedenen AVRs. Bei C lässt sich sowas 
relativ einfach protieren und ggf. durch ein paar #ifdef Bedingungen 
anpassen lassen. Von Adaptern halte ich nicht so viel, weil du dann 
einen ATMega128(SMD!) brauchst um alle möglichen µCs zu emulieren.

>Meiner Meinung nach, wird der UART oft / meistens verwendet.
Der Meinung bin ich auch, aber wie oft wird der URAT nur zur 
Kommunikation mit dem PC verwendet? Fast immer! Und wenn das Programm 
sowieso am PC läuft, kann er den URAT ja in Software nachbilden, oder?

>Dann brauchst du einen "Emulator" - Kern für jeden AVR !?
Die Befehle sind bei allen AVRs die gleichen. Nur manchmal fehlen 
welche. Und was die Register angeht: Die müsstest du sonst mit deinem 
anderen AVR nachbilden, wenn es nicht die gleichen sind. Und wo meinst 
du geht das einfacher? Am PC oder im AVR???

>Wie soll dieses "Emulieren" und debuggen funktionieren?
Der ganze AVR soll in Software "nachgebaut" werden. So änhlich wie es 
"VMWare" macht, nur das ein AVR weit weniger komplex ist als ein ganzer 
PC. Und wenn man schon die ganzen Register im RAM hat ist es kein 
Problem mehr diese auch auf den Bildschirm auszugeben.

>Möchtest du auf der Basis des "Hex" Files oder / und des Quellcodes emulieren ?
Das soll so ablaufen, wie bei AVRStudio: Die COF-Datei hernehmen und 
damit
a) das Programm aus den ASM-Befehlen ablaufen lassen
und
b) dazu passend den Sourcecode anzeigen lassen.
Dazu bräuchte ich aber Hilfe oder Docs, weil ich das Format nicht kenne.

>Das eigentliche "Frontend" / die graphische Oberfläche wird (meiner Meinung nach) 
auch sehr aufwendig:
Das geht eigentlich recht schnell. Es gibt eine fertige Komponente für 
Syntaxhighlighting(ASM, C(++), Pascal, Basic, uvm.) mit Breakpoints, 
etc. Die anderen Fenster lassen sich mit Delphi ja auch recht schnell 
erzeugen.

>Daher kann ich nicht ganz nachvollziehen, daß du meinst, dies sei nicht viel 
Aufwand
"Nicht viel" ist relativ. Wenn du vorher Programme mit max. 100 Zeilen 
geschrieben hast, wird das Projekt riesig. Wenn du es mit dem 
Linux-Kernel vergleichst aber winzig. Meine Schätzung ist mal so an die 
5000Zeilen/250kb-Code.

Mit AVR-Studio Plugins glaub ich aber es wird auch nicht viel einfacher:
a) >Aber zum Schreiben von Pluggins müßte Studio 4.0 mal endlich aus dem 
Alpha Status.
b) Du kennst die API noch nicht! Einarbeitungsaufwand (tolles Wort)!
c) Es ist fraglich wie gut die Möglichkeiten zur Manipulation der Werte 
in den Fenstern sind. => Evtl. doch wieder eigene Fenster entwerfen.

Hermann

Hi Matthias,
es gibt sicher eine Doku für das JTAG Interface. Den Teil aus dem M128 
Datenblatt hab ich mir sogar mal ausgedruckt, aber noch nicht gelesen. 
Ob sich der Aufwand lohnt und ob man in einem solchen Projekt alle 
möglichen Funktionen, insbesondere das Setzten von Breakepoints usw, 
implementieren kann wage ich zu bezweifeln. Ich weiß das E-Lab an einem 
JTAG Debugger arbeitet. Derzeit verwenden sie einen M323, der aber 
anscheinend zu langsam ist. Sobald der M32 draussen ist soll der 
eingesetzt werden. Das zeigt schonmal, welchen Umfang das ganze haben 
muß.

Gruß
Markus

Hallo Herman,

> Hast du schon mal AVR-GCC probiert.

Nein, aber Codevision und Imagecraft. Beide eine reine Katastrophe !

> Das das Prog. durch ASM effektiver wird ist klar

Ich würde das Programm in ASM schreiben, um vernünftige Laufzeiten zu 
bekommen ...

> Adaptern halte ich nicht so viel, weil du dann einen ATMega128
> (SMD!) brauchst um alle möglichen µCs zu emulieren.

Wäre daß so schlimm ?

> Der Meinung bin ich auch, aber wie oft wird der URAT nur zur
> Kommunikation mit dem PC verwendet?

Nein, der UART wird nicht immer für die Kommunikaion mit dem PC 
verwendet. (aber meistens)

> Fast immer! Und wenn das Programm sowieso am PC läuft, kann er den URAT ja in 
Software nachbilden, oder?

Wenn man schon von "Echtzeit" absieht, sollte man wenigstens alle µP - 
Pins zur Verfügung haben ...

>Wenn du vorher Programme mit max. 100 Zeilen geschrieben hast, >wird das Projekt 
riesig.
>Meine Schätzung ist mal so an die 5000Zeilen/250kb-Code.

Ich programmiere in C / C++. ( Auch Programme jenseits von 5000 Zeilen 
...) Leider kann ich nicht in Delphi programmieren, daher kann ich auch 
nichts zu deiner Schätzung von 5000 Zeilen sagen.

Ich würde aber vorschlagen, den "Emulator-Kern" in C++ zu programmieren. 
Evtl. mit Borland C++ Builder 5 (welcher jetzt kostenlos ist ...).

Die GUI kannst du ja in Delphi programmieren, wo dies evtl. einfacher 
sein dürfte als in C++ ...

Aber bei dem Emulator-Kern würde ich wieder an die Laufzeit denken ...

>Dazu bräuchte ich aber Hilfe oder Docs, weil ich das Format
>nicht kenne.

Leider kenne ich das Format auch nicht ...

> Mit AVR-Studio Plugins glaub ich aber es wird auch nicht viel
> einfacher:

Ich habe bis jetzt auch noch keine Doku dazu gesehen. Das AVR-Studio 4 
wurde ja auch nur so früh veröffentlicht, um den ICE50 verwenden zu 
können, alles andere ist noch in Entwicklung ...

-------------------
Hallo Andreas,

> Es gibt bereits einen Open-Source-Simulator für AVR, und GDB
> ist ein ausgereiftes Debuggingsystem für das es auch viele
> lickibunti-Oberflächen gibt (->Insight). Wenn ihr euch die
> Mühe macht das mit dem Monitorprogramm mal zu probieren, dann
> könnt ihr euch den ganzen Kram (cof-Datei analysieren,
> Simulator entwickeln, GUI bauen) sparen.

könntest du mir bitte die einzelnen Komponenten bitte mal ein wenig 
beschreiben ?

Du sprichst von 3 Programmen ?

- OpenSource Simulator für AVR ? Welcher ?
- GDB
- Insight. GDB enthält aber doch eine GUI oder ?
-------------------

Hallo Markus,

> es gibt sicher eine Doku für das JTAG Interface

Ja, daß JTAG Interface wird in dem Datenblatt des M128 beschrieben. Aber 
das Protokoll um den AVR debuggen zu können wird dort nicht beschrieben. 
Stattdessen:

" The On-chip debug support is considered being private JTAG 
instructions, and distributed within ATMEL and to selected 3rd party 
vendors only."

Hallo!
>Nein, aber Codevision und Imagecraft. Beide eine reine Katastrophe !
Dann probier doch mal AVR-GCC! Mit GCC ist der Standardlinuxcompiler, 
mit dem auch fast alle Linux-C(++)-Programme compiliert sind. Ist also 
im PC-Bereich ziemlich verbreitet und mit dieser guten Grundlage ist 
dann auch ein IMHO sehr guter AVR-Compiler entstanden.

> Ich würde das Programm in ASM schreiben, um vernünftige Laufzeiten zu bekommen 
...
Schau dir mal an wie GCC dein C-Prog. compiliert. Mein ASM-Code ist 
dagegen ziemlich schlecht. (OK, ich kenn mich mit ASM auch noch nicht so 
toll aus)

>> weil du dann einen ATMega128 (SMD!) brauchst um alle möglichen µCs zu 
emulieren.
>  Wäre daß so schlimm ?
JA! SMD=>Platine fertigen lassen=>Teuere Platine+Teuerer µC! Und dass 
kann ich mir nicht leisten ich bin noch Schüler und muss ein bisschen 
auf das Geld achten.

>> Nein, der UART wird nicht immer für die Kommunikaion mit dem PC verwendet. 
(aber meistens)
> Wenn man schon von "Echtzeit" absieht, sollte man wenigstens alle µP - Pins zur 
Verfügung haben
Am seriellen Port gibt es noch ein paar Anschlüsse (RTS, CTS), die sich 
für diesen Zweck missbrauchen lassen würden. Und der MAX232 wird 
meistens eh nur zur Hälfte genutzt.

>Ich programmiere in C / C++. ( Auch Programme jenseits von 5000 Zeilen ...) 
Leider kann ich
>nicht in Delphi programmieren,
Dann kann ich dir nur empfehlen das zu lernen. Manches ist zwar 
schwieriger zu handhaben(Pointer), dafür hat man aber die damit 
verbundenen Probleme auch nicht. Ich nehme es auch weil ich von meiner 
Schule eine kostenlose Version davon zur Verfügung gestellt bekommen 
hab.

>Ich würde aber vorschlagen, den "Emulator-Kern" in C++ zu programmieren. Evtl. 
mit Borland C++ >Builder 5 (welcher jetzt kostenlos ist ...).
Echt ist jetzt C++ Builder kostenlos. Ich hab gedacht, nur der Compiler 
wäre gratis. Die Oberfläche gibt nicht dazu, oder? Aber mir ist's 
eigentlich egal. Dann Bau ich mir die Oberfläche dazu eben selber.
>Die GUI kannst du ja in Delphi programmieren, wo dies evtl. einfacher sein dürfte 
als in C++ ...
Glaub ich auch, bis jetzt hab ich nur mal unter Linux versucht eine 
Oberfläche mit C++ zu entwerfen, aber da war's ne Katastrophe.

>Aber bei dem Emulator-Kern würde ich wieder an die Laufzeit denken ...
Delphi ist IMHO nicht langsamer als C++.

>Leider kenne ich das Format auch nicht ...
Wir könnten ja mal bei Programmierer des ELF2COF-Converters nachfragen, 
wenn wir uns entschieden haben wie das Prog. aussehen soll.

>" The On-chip debug support is considered being private JTAG instructions, and 
distributed >within ATMEL and to selected 3rd party vendors only."
Ok, damit ist jetzt sicher, dass JTAG nicht in Frage kommt. Wenn wir 
schon bei solch schlechten Geschäftspraktiken sind: Bis du damit 
einverstanden, dass das ganze Prog. GPL wird?

Hermann

Hallo Hermann,

>Dann probier doch mal AVR-GCC!

Bei Mikrocontroller Programmen, wo es auf Laufzeit und Codeumfang 
ankommt, ziehe ich Assembler einem C Compiler vor ...

>JA! SMD=>Platine fertigen lassen=>Teuere Platine+Teuerer µC! Und
>dass kann ich mir nicht leisten ich bin noch Schüler und muss
>ein bisschen auf das Geld achten.

Ich ätze zuhause problemlos SMD Platinen. Habe gestern erst einen 
ATmeag128 auf eine selbstgeätzte Adapterplatine gelötet.

>Am seriellen Port gibt es noch ein paar Anschlüsse (RTS, CTS),
>die sich für diesen Zweck missbrauchen lassen würden. Und der
>MAX232 wird meistens eh nur zur Hälfte genutzt.

Das endet doch in einer Katastrophe => Windoze und Timing ...

>Dann kann ich dir nur empfehlen das zu lernen.

Nein, daß glaube ich nicht. Ich verwende (unter Windoze) die MFC, und 
ein Umstieg (bzw. das dazulernen) einer komplett anderen (und evtl. 
langsameren) API halte ich nicht unbedingt für sinvoll.

>Ich hab gedacht, nur der Compiler wäre gratis.

Ja, nur der Compiler ist kostenlos.

>Dann Bau ich mir die Oberfläche dazu eben selber.

Kann es evtl. sein, daß du so etwas noch nie gemacht hast ?

>Glaub ich auch, bis jetzt hab ich nur mal unter Linux versucht >eine Oberfläche 
mit C++ zu entwerfen, aber da war's ne >Katastrophe.

Mit dem Resourceneditor und der MFC ist daß gar nicht so schwer ...

>Delphi ist IMHO nicht langsamer als C++.

Ich habe es noch nicht getestet, aber ich glaube, daß C++ um ein 
vielfaches schneller als Pascal/Delhpi ...

>Bis du damit einverstanden, dass das ganze Prog. GPL wird?

Ja, wenn überhaupt, dann OpenSource inkl. GPL ...!


Gruß
Matthias

>Bei Mikrocontroller Programmen, wo es auf Laufzeit und Codeumfang ankommt, ziehe 
ich Assembler >einem C Compiler vor ...
Der Codeumfang sollte hier nicht das Problem sein. Und was die Laufzeit 
angeht: Der Controller dürfte die meiste Zeit mit warten auf das 
umschalten eines Ports beschäftigt sein.

>Ich ätze zuhause problemlos SMD Platinen.
Tja, da fehlen mir noch die Geräte. Mal sehen wieviel Geld ich an 
Weihnachten zusammenbekomme.

>>Am seriellen Port gibt es noch ein paar Anschlüsse (RTS, CTS),
>>die sich für diesen Zweck missbrauchen lassen würden.
>Das endet doch in einer Katastrophe => Windoze und Timing ...
z.b. PonyProg kann das und da könnte man ja nach der LIB fragen.

>>Dann kann ich dir nur empfehlen das zu lernen.
> einer komplett anderen (und evtl. langsameren) API halte ich nicht unbedingt für 
>sinvoll.
Die API ist nicht komplett anders. Du hast exakt die gleichen 
API-Funktionen wie bei C++, nur die Datentypen+Syntax ist anders.
> { Translated from WINDEF.H }
Steht in der Datei Windows.pas und in den anderen Dateien sieht es 
ähnlich aus. Nur die GUI-Objekte haben Zusatzfunktionen bekommen, 
basieren aber auch wieder auf den Windowsstandardelementen.

>Kann es evtl. sein, daß du so etwas noch nie gemacht hast ?
Wovon redest du?
Von der Oberfläche, oder vom µC-Emulator?
Oberfläche: Hab ich schon gemacht, bei interesse kann ich ein etwas 
älteres Beispiel posten (Syntaxhighlighting für C++/PHP, HTML-Export, 
Auswertung der Compilermeldungen(leider kein aktueller Compiler), noch 
keine Projektverwaltung).
Emualtor: Stimmt, sowas hab ich noch nie gemacht.

>Mit dem Resourceneditor und der MFC ist daß gar nicht so schwer ...
Zu windows kann ich nix sagen. M$ Visual Studio nehm ich aus prinzip 
nicht (M$-Zeug) und C++-Builder ist mir zu teuer.

>Ich habe es noch nicht getestet, aber ich glaube, daß C++ um ein vielfaches 
schneller als >Pascal/Delhpi ...
Und warum? Delphi erzeugt ziemlich schnellen code. Und führt auch viele 
Optimierungen durch(weißt dich z.B. auf unnütze/vergessene 
initalisierungen von Variablen hin, etc.)

Hermann

Hallo zusammen, ich bin relativ neu was die AVR Geschichte anbelangt. 
Aber die Diskussion hier finde ich sehr interessant. Eigentlich bin ich 
professioneller Softwareentwickler.

Eines vorneweg: Die Oberfläche usw. für einen ICE zu schreiben ist kein 
Problem. Die Diskussion über die "richtige" Programmiersprache ist müßig 
und überflüssig. Grundsätzlich ist dies in mehreren Programmiersprachen 
nahezu gleich gut möglich.

Das was mich viel mehr interessiert, ist die Elektronik bzw. die 
Ansteuerung dieser. Wie ich gesehen habe kann ein AVR bis zu 16 MHz 
getaktet werden. Da mit einem Maschinenbefehl maximal 8 Bit gleichzeitig 
angesprochen werden können, schent mir die wesentliche Aufgabe zu sein, 
dass ein PC mit dem ICE 8 Bit Daten mit dieser Geschwindigkeit 
austauschen kann. Prinzipiell bin ich der Meinung, dass man diese 
Anforderungen auch noch runterschrauben kann aber unterhalb von 1MHz 
wird es so langsam uninteressant. Es gibt, soweit ich das Überblicke, 
eigentlich nur eine vernünftige Methode das zu bewerkstelligen:

Es ist eine PCI Einsteckkarte zu entwickeln, die die komplette Logik für 
die Emulation enthält. Der PCI Bus wird mit 33 MHz getaktet und erlaubt 
einen voll adressierbaren 32 Bit Zugriff. Außerdem ermöglicht der Bus 
das Erzeugen von Interrupts. Interessant wäre hier eine einfache Mimik 
zu entwickeln um den AVR direkt zu emulieren.

Falls es nicht auf Echtzeit ankommen soll, gibt es immer noch die 
Möglichkeit mehrere AVRs einzusetzen, um z.B. einen kompletten 
AVRMEGA128 zu emulieren.
Prinzipiell können dann beide COM Schnittstellen des PCs für den 
Emulator verwendet werden. Damit wäre ein vollwertiger Emulator zu 
realisieren, der dann allerdings bei weitem nicht in Echtzeit läuft.
Das betrifft prinzipiell die Ports, denn deren Durchsatz ist durch die 
Bandbreite der verwendeten Schnittstelle begrenzt.

Wie steht es eigentlich mit diesem Projekt aus?
Sind schon andere Ansätze oder Erfolge zu berichten?

warum bekommst du so viele antworten und ich fast nie welche?

Hallo AVR freunde!

kurz: Ich habe compilers, simulators und programmers für AVR 
geschrieben. Alles ist machbar. Frage ist was lohnt auf dauer, und bring 
butter auf brot am ende des tages.

JTAG interfaces - jawahl - kein 'standard' aber 96% prozent von allen 
LPT donglen kan man mit 5EUR hardware emulieren - ich habe so ein desing 
schon 6 jahre in meinem schublade (ispLSI1016 basierend) jetzt ist ein 
ähnliches auch kommerziell suche nach Chameleon www.amontec.com das 
kostet zwar 199 aber dasselbe kann man selber machen mit unter 5EUR. Bin 
gerade dabei auszudenken lohnt es sich entweder meinen alten desing zu 
veroffentlcihen oder neues machen.

Emulation/Simulation: grosse FPGAs kosten - NICHTS, und tools sind frei. 
wenn es um irgendwelche hardware geht für die simulation/emulation zu 
entwickeln dann lohnt es sich nicht mehr halbeweg zu gehen. Ein FPGA das 
ausreicht für AVR als soft-IP core koster unter 12 EUR. Aber wenn man es 
so ansieht sollte der emulator nicht auf AVR beschrankt sein.

so zum zusammenfassung was würde sinn machen:

PCB desing mit FPGA (200k+ gates), SRAM, LPT port (alle leitungen frei 
um alle moglichen dongles zu emulieren). mann kann auch Burched B5 board 
nehmen.

Auf einer solcher platine kann man AVR code in real time emulieren. nur 
für die analog braucht man zusatlichen "POD" zu entwickeln.

die VHDL für AVR core is frei, aber es braucht viel mühe um das zu 
nutzen. hier liegt die meiste arbeit - die VHDL core zu überprüfen und 
mit embedded ICE zu erganzen.

manche firmen machen es auch schon so, PSoC ICE
www.cypressmicro.com enthalt keinen bond-out chip sondern einen 200k 
gatter spartan FPGA das den target micro emuliert.

sorry für das zu lange kommentar

>Die Oberfläche usw. für einen ICE zu schreiben ist kein Problem.
Hab ich auch gesagt.
>Es ist eine PCI Einsteckkarte zu entwickeln, die die komplette Logik
>für die Emulation enthält.
Nur leider wird das warscheinlich ziemlich kompliziert(PCI-Spec.,Timing, 
hohe Frequenz(33Mhz glaub ich), etc.). Und ich schätze mal wenn du die 
gesammte Emulation in hardware ablaufen lassen willst ist es besser dir 
JTAG-ICE zu kaufen.

>Wie steht es eigentlich mit diesem Projekt aus?
>Sind schon andere Ansätze oder Erfolge zu berichten?
Ich habe noch nichts entwickelt, da niemand so recht mithelfen wollte 
und ich mich in der AVR-Programmierung noch nicht gut genug auskenne, 
das alles selber zu machen.

Hermann

eine Überlegung wäre auch ein Software Debugger wert. Dieser müsste dann 
auf dem AVR mitlaufen. Das Problem dabei ist, dass ein AVR seine 
Programme im EEPROM und nicht in externem RAM ablaufen lassen muss. 
Damit ist es mit Breakpoints schon mal schlecht bestellt. Allerdings 
könnte man im Betrieb Register, Ports und Speicher auslesen und auch 
setzen. Angestoßen werden könnte der Software Debugger über einen 
Interrupt oder durch einbinden in die Hauptschleife des Programms.

Das würde für die meisten Diagnose und Debugging Anwendungen reichen. 
Allerdings belegt dieser Debugger mindestens 1-2 Ports oder einen UART. 
Ich werd mal experimentieren sobald ich meine neue Testumgebung habe.

Auch bei einer PCI Einsteckkarte würde man die Emulation nicht in 
Hardware laufen lassen. Diese würde nur das Interface für den Software 
Emulator bereitstellen.
Ist allerdings schweine Kompliziert, wenn man es richtig machen will.

Vielleicht wirds doch ein JTAG ICE. Der kostet momentan unter 100 Euro 
und das ist eigentlich machbar.

@Thomas Maierhofer:
Hallo Thomas, wo kostet denn der JTAG ICE unter 100 Euro? Wenn Du die 94 
Euro aus dem Reichelt-Katalog meinst, das ist wohl ein Druckfehler. Im 
Online-Katalog steht er mit 399 Euro zu Buche.

Gruss Jens

Dem Druckfehler bin ich wohl aufgesessen!

Übrigens es gibt einen interessanten USB 2.0 nach RS232 Converter Chip 
FT 232 BM. Beziehungsweise den FT 245 BM als USB / FIFO Konverter. Er 
kostet bei Segor (www.segor.de) 9,80 Euro. Damit ist die Kommunikation 
mit dem PC über USB möglich.
Infos unter: http://www.ftdichip.com/Documents/ds232b11.pdf (RS232)
http://www.ftdichip.com/Documents/ds245b10.pdf (FIFO)

mit diesen Chips wäre ein Datentransfer von bis zu 1 MByte/Sekunde 
möglich. D.H man könnte den kompletten I/O Raum eines AVR auf einem 
Software Emulator abbliden und hätte mindestens einen I/O Durchsatz von 
100Khz bis fast 1/2 MHz je nach Implementierung. Damit wäre z.B. die 
Emulation im Audiobereich (48KHz) schon greifbar Nahe.

Für die ganzen Popel Anwendungen, die im Millisekundenbereich reagieren 
müssen ist das eh mehr als ausreichend.

Es sind USB Treiber für alle möglichen Betriebssysteme verfügbar 
(frei!!!). Das ist auch für andere Problemstellungen hochinteressant. 
Zum einen gibt es Treiber für virtuelle COM Ports (wenn z.B. schon eine 
RS232 vorhanden ist bzw. mit angesteuert werden muss) zum anderen gibt 
es direkte Treiber, die via DLL in die Applikation integriert werden 
können.

Hallo crazy horse

kannst du den ICE200 immer noch zu dem Preis besorgen

Gruß Peter

Hi!

Ich wollte mal berichten wie sich das jetzt entwickelt hat: Ich bin 
jetzt auf Linux umgestiegen und arbeite jetzt an der Entwicklung von 
Simulavr mit. Zwar noch ziemlich unfertig, aber gut. Evtl. bekommt das 
irgendwann mal ne Schnittstelle zu einem Hardware-Emulator. Bis dahin 
kann man ja auch das DIY-JTAG-ICE nehmen.

Hermann

Hi,

@Crazy Horse:
"Der ICE200 kostet 99$, also im Moment incl. MwSt 116 Euro,
unterstützt alle Classic-AVR und ist wirklich zu empfehlen."

Wo haste den ICE200 fuer diesen Preis gesehen. Ich hab gestern mir sehr
interessiert die Doku im AVR Studio gelesen. Leider finde ich kein
Anbieter fuer den ICE50 bzw. ueberhaupt den Preis.


Mfg
Dirk

Hallo,
der ICE200 für den o. g. Preis würde mich auch interesieren. Ist das
Angebot zur Zeit den noch gültig?
Gruß
Boris