Hallo, ich möchte ein "Debug Tool" entwickeln: - an dem zu "debuggenden" AVR werden nur 2 I/O Pins gebraucht: TxD und SCK - diese beiden Pins werden an eine kleine Schaltung angeschlossen: kleiner AVR (AT90S1200 ..), MAX202/232 ... - die kleine Schaltung wird an eine serielle Schnittstelle des PC's angeschlossen Das ganze soll folgendermaßen funktionieren: In den Quellcode des zu "debuggenden" werden "Debug" - Unterprogramme aufgerufen, die ein Register o.ä. über die 2 I/O Pins an den an den anderen AVR senden. Dabei möchte ich eine Art I²C Protokoll mit variabler Baudrate verwenden, damit ich im zu debugenden AVR keine Interrupts / Timer ... brauche ... Der andere AVR empfängt diese Daten, bereitet sie auf (evtl. nach ASCII ...) und sendet diese über einen "Software - UART" per RS232 an den PC. Dort können die "Debug - Meldungen" dann mit jedem Terminal Programm auf jedem Betriebssystem empfangen werden. -------------------------- Ist irgendjemand an diesem Projekt interresiert bzw. an der Mitwirkung interressiert ? Matthias
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??
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
Standardisiert? Diese angebliche Standardisierung ist in der Praxis ein Witz. Ob ispLSI, AVR, MSP430, 68k, jedes Teil braucht seine eigene spezielle Hard- und Software. Wenn man sich wenigstens auf die Hardware hätte einigen können... Trotzdem ist es eine feine Sache zum Debuggen, auch wenn die Hardware beim AVR saumäßig teuer ist.
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.
Nützlicher wäre es, einen GDB-kompatiblen Monitor zu schreiben bzw. den existierenden (http://www.pvv.ntnu.no/~torhr/avrmon-stk200/) auf einen aktuellen Stand zu bringen, auf Windows zu portieren und zu dokumentieren, dann könnte man mit Insight debuggen und hätte einen fast vollwertigen JTAG-Ersatz.
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
@Markus: Ein paar Leute von der avr-gcc-Mailingliste haben sich mit dem Analysieren der JTAG-Schnittstelle versucht. Ob schon was brauchbares dabei rausgekommen ist weiß ich nicht. @Hermann: Warum wollt ihr eigentlich alle das Rad neu erfinden? Es gibt bereits einen Open-Source-Simulator für AVR, und GDB ist ein ausgereiftes Debuggingsystem für das es auch viele Klickibunti-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.
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?
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.