www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik all-test Online Terminal Programm für AVR?


Autor: Robert K. (mc1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist eine coole Idee, gibt es sowas?

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert K. (mc1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: DKM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Elektro Gandalf (e_g)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte auch interesse an so einer Software!

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt alles sehr interessant. Könnt ihr euren Code hier ins Forum 
stellen?

Autor: frankieboy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht sowas wie das hier ?
http://elm-chan.org/docs/avr/avrisp.html

Benutzt die ISP Pins per Soft-Uart zum Debuggen.

Autor: DKM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Robert K. (mc1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert K. (mc1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ging gerade beim Check der Anhang wieder weg. Hier ist er.

Autor: Andreas Thanheiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Robert K. (mc1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Thanheiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Robert K. (mc1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.