Gibts für den AVR vielleicht schon einen bestehenden "all-test" Programmcode (avr-gcc), mit welchem man online über serielle Terminal-Kommandos Register & Memory,Bits... live (ggf. per Namen) leicht setzen/abfragen/durchprobieren kann, kleine (Late-Init-)Macros ausführen (PWM test ausgaben in vielen Variationen, ADC/AC lesen, UART ...) etc. und selbst sukzessive seine Macros dazubauen kann. Mit sowas habe ich auf anderen µC's immer am schnellsten HW und Software-Elemente in Gang gebracht - und übersichtlich dokumentiert mit entsprechender Vielfalt an Macros dient es auch also flüssigste µC-Doku / Code-Vorlage ( Die AVR Doku ist recht hoprig gemacht im Vergleich zu anderen µC's ). Robert
Robert K. wrote: > Gibts für den AVR vielleicht schon einen bestehenden "all-test" > Programmcode (avr-gcc), mit welchem man online über serielle > Terminal-Kommandos Register & Memory,Bits... live (ggf. per Namen) > leicht setzen/abfragen/durchprobieren kann, kleine (Late-Init-)Macros > ausführen (PWM test ausgaben in vielen Variationen, ADC/AC lesen, UART > ...) etc. und selbst sukzessive seine Macros dazubauen kann. Meinst Du soetwas, das man früher (zu Z80-Zeiten) einen "Monitor" genannt hat? Das hatte früher fast jedes uC-Eva-Board. Man konnte über Befehle wie z.B. "F" (Fill) Speicherbereiche mit festen Werten füllen, mit "I" Daten in Hex eingeben, mit "M" Speicherbereiche ausgeben/anschauen, mit "G" Programme ausführen (allerdings nur bei Von-Neumann-Prozessoren, also nicht bei AVR's), usw. Für die AVR's kenne ich keinen Monitor; aber Du kannst ja einen schreiben. Das dürfte nicht so schwer sein: - Umgang mit UART, Daten über UART senden und empfangen - Gepufferte Eingabe auf eine Kommandozeile mit einfachen Edit-Befehlen (Return, Backspace, Esc) - Befehle erkennen, Parameter in verschiedenen Formaten (Hex, Dezimal, evt. Binär) einlesen, Kommandofunktionen aufrufen (anhand Befehlstabelle) - Mit HyperTerminal in Verbindung treten
Günter R. wrote: > Robert K. wrote: >> Gibts für den AVR vielleicht schon einen bestehenden "all-test" >> Programmcode (avr-gcc), mit welchem man online über serielle >> Terminal-Kommandos Register & Memory,Bits... live (ggf. per Namen) >> leicht setzen/abfragen/durchprobieren kann, kleine (Late-Init-)Macros >> ausführen (PWM test ausgaben in vielen Variationen, ADC/AC lesen, UART >> ...) etc. und selbst sukzessive seine Macros dazubauen kann. > > Meinst Du soetwas, das man früher (zu Z80-Zeiten) einen "Monitor" > genannt hat? Das hatte früher fast jedes uC-Eva-Board. Man konnte über > Befehle wie z.B. "F" (Fill) Speicherbereiche mit festen Werten füllen, > mit "I" Daten in Hex eingeben, mit "M" Speicherbereiche > ausgeben/anschauen, mit "G" Programme ausführen (allerdings nur bei > Von-Neumann-Prozessoren, also nicht bei AVR's), usw. > > Für die AVR's kenne ich keinen Monitor; aber Du kannst ja einen > schreiben. Das dürfte nicht so schwer sein: > > - Umgang mit UART, Daten über UART senden und empfangen > - Gepufferte Eingabe auf eine Kommandozeile mit einfachen Edit-Befehlen > (Return, Backspace, Esc) > - Befehle erkennen, Parameter in verschiedenen Formaten (Hex, Dezimal, > evt. Binär) einlesen, Kommandofunktionen aufrufen > (anhand Befehlstabelle) > - Mit HyperTerminal in Verbindung treten Ja einen "Monitor" - nur eben als deutlichen Code-Vorlage mit zusätzlichen primitiven Funktions-Set wo man dann selbst Primitive dazubaut. Zunächst v.a. um Hardware-Register/Funktionsblöcke/Memory.. bequem per Namen zu befummeln und um während des eigentlichen Programlaufs nebenher (Monitor in der mainloop mit Step-Aufrufen versorgt) "mit zuschauen und interaktiv eingreifen zu können". Hatte auch nix mehr dazu gefunden habe schon wieder selbst angefangen und das mit dem Mem und Register-Fummeln per Namen etc. geht schon. Ohne sowas kann ich auf keinem µC mich "wohl fühlen". Falls jemand anderes noch Interesse hat kann ich ja demnächst die V0.1 oder höher posten. Robert
Ich hab sowas ähnliches (Assembler,Software-Uart) damit kann man per RS232 Klartext Kommandos an den AVR senden (mit Parametern) und kann auch Ergebnisse zurückgeben (Hex Dez Texte..) Eigene Kommandos können sehr einfach über eine Sprungtabelle hinzugefügt werden. Das ist so eine kleine "shell", mit der man eigene Unterprogramme ausführen und testen kann. Ist recht angenehm, wenn man mit dem AVR "direkt" reden kann.. bei Interesse werd ich den Code mal zur Veröffentlichung aufbereiten..
Klingt alles sehr interessant. Könnt ihr euren Code hier ins Forum stellen?
Vielleicht sowas wie das hier ? http://elm-chan.org/docs/avr/avrisp.html Benutzt die ISP Pins per Soft-Uart zum Debuggen.
Meine Software gibts unter http://www.loetstelle.net/projekte/tinyclock/tinyclock.php Ist in eine RS232-Schaltuhr eingebunden. Der "Befehlsinterpreter" kann leicht um eigene Kommandos erweitert werden und so um Monitor-Funktionen ergänzt werden. Die Eingabe unterstüzt (fast) keine Syntax-Prüfung, da sie bei mir die Kommandos aus einer anderen Software erhält, aber das könnte man nachrüsten.
Habe anbei mal den AVR Spy v0.1 aufbereitet. Wurde bislang nur mit ATMega8 benutzt. In res/table_io*.h sind aber schon die SFR-Namenstabellen für alle derzeitigen AVR µC's generiert und es sollte auch sonst recht kompatibel in Gang zu bringen sein (entsprechend den Resourcen s.u.). Ansonsten Feedback. Wenn's sich etwas gesetzt hat, kann ichs beizeiten rüber ins Codesammlungs-Forum stellen. Unten aus dem README.txt Grüsse Robert ----- AVR Spy Monitor (AVR-GCC) v0.1 Description: AVR µC monitor & code evolution base for Rapid Development on AVR µC's. Provides a direct serial (UART<->Terminal) shell interface into the AVR and to your software building blocks (parallel to a mainloop potentially). Advantage: AVR Quickstart with no/little code. Speeds up hardware and software development by direct interaction. Reduces need for frequent trial&error downloads by factors. Encourages a clear modularized and test driven programming style from the beginning. Can be a starting point for any new software project. Features: * Standalone or attachable to existing/new software * Shell-Prompt, Backspace, Command-History (Arrow-UP), .. * SFR Byte/Word/Bit access by name * RAM/FLASH/EEPROM Byte/Word/Bit read/write * Standard Tools (AD,PWM,..) * Simple scheme for new tool commands (callback with commandline and easy-parsing examples) Files: * avrspy_test.c : test main program shows HOW TO attach the AVR Spy to a project or use it naked * Makefile : complete make file (AVR-GCC) * avrspy.h & .c : the AVR Spy and UART & parse & tool functions * defines.h : definitions for your CPU, Clock, Baudrate * README.txt : this file * res\table_io*.h : SFR name table files for AVR µC Variants * avrspy_test.lst .map .hex : precompiled example for Mega8, 16MHz, Pollin-EvalBoard-LEDs Example Shell Session: > AVR SPY:Spy-only loop until 'q(uit)' is pressed 1st time: > m12A # read RAM memory byte (HEX) RAM[012A]: 25 : m12C=6b # write RAM momory byte (HEX); History edited RAM[012C]=6B > mw12a # read RAM memory word (HEX) RAM[012A]: 3025 > sDDRD # read SRF by name: PortD Data Direction? (HEX) DDRD: E0 > sPORTD/5=1 # set bit 5 (LED1) of that SFR (HEX) PORTD=20 : sPORTD/6=1 # set bit 6 (LED2)of that SFR (HEX) PORTD=60 > sPIND # true state of PORTD Input (HEX) PIND: 61 > sPORTD/7=1 # bit 7 (BEEPER) on PORTD=E0 : sPORTD/7=0 PORTD=60 > sADMUX # SFR by name (HEX) ADMUX: 00 > AD2 # ADC read tool (ADLAR=1) (DEC) ADC[2]: 51648 > sADMUX/6=1 ADMUX=42 > sADMUX ADMUX: 42 : sADMUX=43 # Set (HEX); History Command Editor with Arrow-UP ADMUX=43 > sSP # watch Stack Pointer SP: 042C > sSREG # .. and SREG flags SREG: 20 > PWM1=3000 # PWM1 16bit tool 3000/65536/prescale=#4=clk/256 (DEC) PWM1 set. : PWM1=3000,30000 PWM1 set. : PWM1=3000,30000,3 # History Edited PWM1 set. > BLINK=3 # extra tool (in my_spy_tool_callback) blink... > BEEP=500 # another extra tool (DEC) beep... : Beep=1500 # History edited beep... > q Bye. 2nd life: my hot mainloop feeding spy with spy_step() > > sPORTD # watch how main program is blinking ... PORTD: 20 : sPORTD PORTD: 60 : sPORTD PORTD: 20 : sPORTD PORTD: 60 : sPORTD PORTD: 20 > sADC # check free running ADC (Word-SFR-Register) ADC: 8EC0 > > e0 # read EEPROM (HEX) EEP[0000]: FF > e0=12 EEP[0000]: 12 # write EEPROM (HEX) > e0 EEP[0000]: 12 > > p26 # Check FLASH[26] (HEX) for 'T' of 'TWBR' string (see avrspy_test.lst) FLASH[0026]: 54 # 'T' > p1FFE # Check PonyProg's SerialNumber Counter in FLASHw[1FFE:1FFF] FLASH[1FFE]: 08 : p1FFF FLASH[1FFF]: 00 > m239 # check 1st byte of 'char spy_buf[20]' according to .map file: COMMON 0x00800239 0x14 avrspy.o 0x00800239 spy_buf RAM[0239]: 6D # yes, our 'm' of 'm239' itself ! > Requirements: A AVR µC with UART, 8k Flash and 512 Byte RAM. ( Remove SFR name table by #include "res/table_dummy.h" for lower memory consumption. TODO: lazy stdio.h/printf requirements to be removed in future versions for <4k µC requirements ) Install & Run the avrspy_test: * set CPU-Clock (F_CPU) and baud rate (UART_BAUD) in defines.h * adapt 'MCU_TARGET=atmega8' for your µC in Makefile * adapt '#include "res/table_iom8.h"' in avrspy.c for your µC in order to have a correct SFR name table. Some are by x. For example table_iomx8.h for ATmega48/88/168 * Check/Modify the avrspy_test.c code for reasonable Ports (LEDs..), hardware related code ... * "make" or "make run/upload" (default PonyProg - see Makefile) Notes/ToDo: * test other µC variants * remove costly printf/stdio.h requirements (#ifdef SPY_STDIO) from avrspy.c * ISR-based UART to allow smoot edit on bumpy mainloops (only by #ifdef) * do some cleanup
Ging gerade beim Check der Anhang wieder weg. Hier ist er.
Servus. Gehört jetz vielleicht net direkt zum Thema. Aber ich find die Idee von AVRmon-stk200 http://mypage.bluewin.ch/laforge.brenles/avr/index.html irgendwie charmant. Hat dazu vielleicht jemand Erfahrung? Ich habs leider nie richtig zum Laufen gebracht. Würd mich aber schon interessieren. Es gibt auch Bootloader mit Monitor-Funktion, was die allerdings können weiß ich nicht. Mich würd halt die Möglichkeit des Sourcecode-Debugging (mit gdb) reizen.
Andreas Thanheiser wrote: > Mich würd halt die Möglichkeit des Sourcecode-Debugging (mit gdb) > reizen. Das hier scheint aktueller zu sein: http://savannah.nongnu.org/projects/freeice/ Grüsse Robert
>Das hier scheint aktueller zu sein: >http://savannah.nongnu.org/projects/freeice/ Das ist von 2003 (soweit ich gesehen hab). AVRmon is von 2006. Is mir ja eigentlich wurscht. Hab jemand mit freeice Erfahrung gemacht? Werd mir aber auf jeden Fall den avr-spy mal anschauen, wenn ich mal wieder Zeit hab. Ist bestimmt ne low-cost Alternative zu JTAG.
Andreas Thanheiser wrote: >>Das hier scheint aktueller zu sein: >>http://savannah.nongnu.org/projects/freeice/ > > Das ist von 2003 (soweit ich gesehen hab). AVRmon is von 2006. > Is mir ja eigentlich wurscht. Hab jemand mit freeice Erfahrung gemacht? > Werd mir aber auf jeden Fall den avr-spy mal anschauen, wenn ich mal > wieder Zeit hab. Ist bestimmt ne low-cost Alternative zu JTAG. Je nachdem was Du meinst. Ich sah vorhin, dass im FreeICE ein Modul namens jtag-avr-spy enthalten ist. Jetzt änder ich den Namen von obigem AVR Spy aber auch nicht mehr. Ein erweitertes, geglättetes und (konfigurierbar) schlankeres v0.2 poste ich vielleicht demnächst - wobei die Philosophie eben ist, dass das zu entwickelnde Programm "sich selbst debug'ed". Man kann angeblich auch über die ISP Schnittstelle so einiges von User/Monitor PC-Kommunikation bis vielleicht sogar Source-Level-Remote-Debuggen, was ggf. interressant ist. Wenn ein solches Interface-Modul einfach mit dem (AVR-GCC-compilierten) Programm verlinkbar und einheitlich uploadbar ist (statt mit Bootloadern, ICE's etc rummachen) sowie alles über das gleiche übliche ISP Kabel liefe, wäre alles schön kompakt und es gäb nicht diese IB-Probleme und Verkabelungsproblem (v.a auf den Kleinen) - die zu lösen ja länger dauert als der Nutzen ist. Am interessantesten aber ist wohl das neue Debug-Wire der neuen (auch der kleinen) Controller, was nur die Reset-Leitung braucht. Ggf. komm ich mal selber dazu. Habe nur auf den kleinen AVR Controllern kaum ein Debug-Problem auf dieser unteren Ebene überhaupt mehr - zumindest sobald ich die SW aus Building-Blocks gemäßig obigem Schema aufbaue und ohnehin mit dem Spy zuschauen und reinfummeln kann, funktioniert auf diesen überraschend sauber konstruierten Controllern alles so glatt... Nur ein paar komplizierte Berechnungsfunktionen debugge ich isoliert auf dem PC. Ansonsten würde das ständige Remote-Rumdebuggen fast mehr Zeit kosten als eine saubere Remodularisierung. Habe ich z.B. stabile Grundfunktionen und kann die schon auf dem Spy ein wenig flexibel rumschubsen - z.B. einfach ad-hoc mal einen zusammengesetzten Vorgang mit dem ADC-sampler selbst beobachen wie mit.. > atrace=1,7;puls=10;discharge=1;trace 828 828 817 814 810 807 803 798 794 791 787 783 779 776 772 768 764 762 758 ... ..dann verschwinden viele Probleme sehr schnell einfach von selbst. Grüsse Robert
Bitte 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.