RN-Control 1.4: Hex erstellen für Übertragung per RS232

Hallo wiedereinmal

Gestern habe ich mein RN-Control bekommen. Auf den ersten Blick macht es auch schon ein super Eindruck. Leider bin ich bereits auf ein Problem gestossen:

1. Wie erstelle ich aus meinen Beispielprogrammen aus der CD ein HEX-File, um es per RS232 zu übertragen?
Ich habs bereits mit Programmer's Editor probiert, stehe aber an, welches Makefile ich nehmen muss. Wie kann ich die Datei der beiliegenden CD ("E:\Anleitungen_Projekte und Boards\rn-control\c_beispiel\Makefile" umwandeln, dass sie vom Programm gelesen wird und funktioniert (HEX-File ausgibt)? => Natürlich in C++

Code:

---

# Hey Emacs, this is a -*- makefile -*-
#
# WinAVR Sample makefile written by Eric B. Weddington, Jörg Wunsch, et al.
# Released to the Public Domain
# Please read the make user manual!
#
# Additional material for this makefile was submitted by:
#  Tim Henigan
#  Peter Fleury
#  Reiner Patommel
#  Sander Pool
#  Frederik Rouleau
#  Markus Pfaff
#
# On command line:
#
# make all = Make software.
#
# make clean = Clean out built project files.
#
# make coff = Convert ELF to AVR COFF (for use with AVR Studio 3.x or VMLAB).
#
# make extcoff = Convert ELF to AVR Extended COFF (for use with AVR Studio
#                4.07 or greater).
#
# make program = Download the hex file to the device, using avrdude.  Please
#                customize the avrdude settings below first!
#
# make filename.s = Just compile filename.c into the assembler code only
#
# To rebuild project do "make clean" then "make all".
#


# MCU name
MCU = atmega32

# Output format. (can be srec, ihex, binary)
FORMAT = ihex

# Target file name (without extension).
TARGET = rncontrol


# List C source files here. (C dependencies are automatically generated.)
SRC = $(TARGET).c


# List Assembler source files here.
# Make them always end in a capital .S.  Files ending in a lowercase .s
# will not be considered source files but generated files (assembler
# output from the compiler), and will be deleted upon "make clean"!
# Even though the DOS/Win* filesystem matches both .s and .S the same,
# it will preserve the spelling of the filenames, and gcc itself does
# care about how the name is spelled on its command-line.
ASRC =



# Optimization level, can be [0, 1, 2, 3, s].
# 0 = turn off optimization. s = optimize for size.
# (Note: 3 is not always the best optimization level. See avr-libc FAQ.)
OPT = s

# Debugging format.
# Native formats for AVR-GCC's -g are stabs [default], or dwarf-2.
# AVR (extended) COFF requires stabs, plus an avr-objcopy run.
DEBUG = stabs

# List any extra directories to look for include files here.
#    Each directory must be seperated by a space.
EXTRAINCDIRS =


# Compiler flag to set the C Standard level.
# c89  - "ANSI" C
# gnu89 - c89 plus GCC extensions
# c99  - ISO C99 standard (not yet fully implemented)
# gnu99 - c99 plus GCC extensions
CSTANDARD = -std=gnu99

# Place -D or -U options here
CDEFS =

# Place -I options here
CINCS =


# Compiler flags.
#  -g*:          generate debugging information
#  -O*:          optimization level
#  -f...:        tuning, see GCC manual and avr-libc documentation
#  -Wall...:    warning level
#  -Wa,...:      tell GCC to pass this to the assembler.
#    -adhlns...: create assembler listing
CFLAGS = -g$(DEBUG)
CFLAGS += $(CDEFS) $(CINCS)
CFLAGS += -O$(OPT)
CFLAGS += -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -Wall -Wstrict-prototypes
CFLAGS += -Wa,-adhlns=$(<:.c=.lst)
CFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS))
CFLAGS += $(CSTANDARD)



# Assembler flags.
#  -Wa,...:  tell GCC to pass this to the assembler.
#  -ahlms:    create listing
#  -gstabs:  have the assembler create line number information; note that
#            for use in COFF files, additional information about filenames
#            and function names needs to be present in the assembler source
#            files -- see avr-libc docs [FIXME: not yet described there]
ASFLAGS = -Wa,-adhlns=$(<:.S=.lst),-gstabs



#Additional libraries.

# Minimalistic printf version
PRINTF_LIB_MIN = -Wl,-u,vfprintf -lprintf_min

# Floating point printf version (requires MATH_LIB = -lm below)
PRINTF_LIB_FLOAT = -Wl,-u,vfprintf -lprintf_flt

PRINTF_LIB =

# Minimalistic scanf version
SCANF_LIB_MIN = -Wl,-u,vfscanf -lscanf_min

# Floating point + %[ scanf version (requires MATH_LIB = -lm below)
SCANF_LIB_FLOAT = -Wl,-u,vfscanf -lscanf_flt

SCANF_LIB =

MATH_LIB = -lm

# External memory options

# 64 KB of external RAM, starting after internal RAM (ATmega128!),
# used for variables (.data/.bss) and heap (malloc()).
#EXTMEMOPTS = -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff

# 64 KB of external RAM, starting after internal RAM (ATmega128!),
# only used for heap (malloc()).
#EXTMEMOPTS = -Wl,--defsym=__heap_start=0x801100,--defsym=__heap_end=0x80ffff

EXTMEMOPTS =

# Linker flags.
#  -Wl,...:    tell GCC to pass this to linker.
#    -Map:      create map file
#    --cref:    add cross reference to  map file
LDFLAGS = -Wl,-Map=$(TARGET).map,--cref
LDFLAGS += $(EXTMEMOPTS)
LDFLAGS += $(PRINTF_LIB) $(SCANF_LIB) $(MATH_LIB)




# Programming support using avrdude. Settings and variables.

# Programming hardware: alf avr910 avrisp bascom bsd
# dt006 pavr picoweb pony-stk200 sp12 stk200 stk500
#
# Type: avrdude -c ?
# to get a full listing.
#
AVRDUDE_PROGRAMMER = stk200

# com1 = serial port. Use lpt1 to connect to parallel port.
AVRDUDE_PORT = lpt1

AVRDUDE_WRITE_FLASH = -U flash:w:$(TARGET).hex
#AVRDUDE_WRITE_EEPROM = -U eeprom:w:$(TARGET).eep


# Uncomment the following if you want avrdude's erase cycle counter.
# Note that this counter needs to be initialized first using -Yn,
# see avrdude manual.
#AVRDUDE_ERASE_COUNTER = -y

# Uncomment the following if you do /not/ wish a verification to be
# performed after programming the device.
#AVRDUDE_NO_VERIFY = -V

# Increase verbosity level.  Please use this when submitting bug
# reports about avrdude. See <http://savannah.nongnu.org/projects/avrdude>
# to submit bug reports.
#AVRDUDE_VERBOSE = -v -v

AVRDUDE_FLAGS = -p $(MCU) -P $(AVRDUDE_PORT) -c $(AVRDUDE_PROGRAMMER)
AVRDUDE_FLAGS += $(AVRDUDE_NO_VERIFY)
AVRDUDE_FLAGS += $(AVRDUDE_VERBOSE)
AVRDUDE_FLAGS += $(AVRDUDE_ERASE_COUNTER)



# ---------------------------------------------------------------------------

# Define directories, if needed.
DIRAVR = c:/winavr
DIRAVRBIN = $(DIRAVR)/bin
DIRAVRUTILS = $(DIRAVR)/utils/bin
DIRINC = .
DIRLIB = $(DIRAVR)/avr/lib


# Define programs and commands.
SHELL = sh
CC = avr-gcc
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump
SIZE = avr-size
NM = avr-nm
AVRDUDE = avrdude
REMOVE = rm -f
COPY = cp




# Define Messages
# English
MSG_ERRORS_NONE = Errors: none
MSG_BEGIN = -------- begin --------
MSG_END = --------  end  --------
MSG_SIZE_BEFORE = Size before:
MSG_SIZE_AFTER = Size after:
MSG_COFF = Converting to AVR COFF:
MSG_EXTENDED_COFF = Converting to AVR Extended COFF:
MSG_FLASH = Creating load file for Flash:
MSG_EEPROM = Creating load file for EEPROM:
MSG_EXTENDED_LISTING = Creating Extended Listing:
MSG_SYMBOL_TABLE = Creating Symbol Table:
MSG_LINKING = Linking:
MSG_COMPILING = Compiling:
MSG_ASSEMBLING = Assembling:
MSG_CLEANING = Cleaning project:




# Define all object files.
OBJ = $(SRC:.c=.o) $(ASRC:.S=.o)

# Define all listing files.
LST = $(ASRC:.S=.lst) $(SRC:.c=.lst)


# Compiler flags to generate dependency files.
GENDEPFLAGS = -Wp,-M,-MP,-MT,$(*F).o,-MF,.dep/$(@F).d


# Combine all necessary flags and optional flags.
# Add target processor to flags.
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)





# Default target.
all: begin gccversion sizebefore build sizeafter finished end

build: elf hex eep lss sym extcoff

elf: $(TARGET).elf
hex: $(TARGET).hex
eep: $(TARGET).eep
lss: $(TARGET).lss
sym: $(TARGET).sym



# Eye candy.
# AVR Studio 3.x does not check make's exit code but relies on
# the following magic strings to be generated by the compile job.
begin:
        @echo
        @echo $(MSG_BEGIN)

finished:
        @echo $(MSG_ERRORS_NONE)

end:
        @echo $(MSG_END)
        @echo


# Display size of file.
HEXSIZE = $(SIZE) --target=$(FORMAT) $(TARGET).hex
ELFSIZE = $(SIZE) -A $(TARGET).elf
sizebefore:
        @if [ -f $(TARGET).elf ]; then echo; echo $(MSG_SIZE_BEFORE); $(ELFSIZE); echo; fi

sizeafter:
        @if [ -f $(TARGET).elf ]; then echo; echo $(MSG_SIZE_AFTER); $(ELFSIZE); echo; fi



# Display compiler version information.
gccversion :
        @$(CC) --version



# Program the device. 
program: $(TARGET).hex $(TARGET).eep
        $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH) $(AVRDUDE_WRITE_EEPROM)




# Convert ELF to COFF for use in debugging / simulating in AVR Studio or VMLAB.
COFFCONVERT=$(OBJCOPY) --debugging \
--change-section-address .data-0x800000 \
--change-section-address .bss-0x800000 \
--change-section-address .noinit-0x800000 \
--change-section-address .eeprom-0x810000


coff: $(TARGET).elf
        @echo
        @echo $(MSG_COFF) $(TARGET).cof
        $(COFFCONVERT) -O coff-avr $< $(TARGET).cof


extcoff: $(TARGET).elf
        @echo
        @echo $(MSG_EXTENDED_COFF) $(TARGET).cof
        $(COFFCONVERT) -O coff-ext-avr $< $(TARGET).cof



# Create final output files (.hex, .eep) from ELF output file.
%.hex: %.elf
        @echo
        @echo $(MSG_FLASH) $@
        $(OBJCOPY) -O $(FORMAT) -R .eeprom $< $@

%.eep: %.elf
        @echo
        @echo $(MSG_EEPROM) $@
        -$(OBJCOPY) -j .eeprom --set-section-flags=.eeprom="alloc,load" \
        --change-section-lma .eeprom=0 -O $(FORMAT) $< $@

# Create extended listing file from ELF output file.
%.lss: %.elf
        @echo
        @echo $(MSG_EXTENDED_LISTING) $@
        $(OBJDUMP) -h -S $< > $@

# Create a symbol table from ELF output file.
%.sym: %.elf
        @echo
        @echo $(MSG_SYMBOL_TABLE) $@
        $(NM) -n $< > $@



# Link: create ELF output file from object files.
.SECONDARY : $(TARGET).elf
.PRECIOUS : $(OBJ)
%.elf: $(OBJ)
        @echo
        @echo $(MSG_LINKING) $@
        $(CC) $(ALL_CFLAGS) $(OBJ) --output $@ $(LDFLAGS)


# Compile: create object files from C source files.
%.o : %.c
        @echo
        @echo $(MSG_COMPILING) $<
        $(CC) -c $(ALL_CFLAGS) $< -o $@


# Compile: create assembler files from C source files.
%.s : %.c
        $(CC) -S $(ALL_CFLAGS) $< -o $@


# Assemble: create object files from assembler source files.
%.o : %.S
        @echo
        @echo $(MSG_ASSEMBLING) $<
        $(CC) -c $(ALL_ASFLAGS) $< -o $@



# Target: clean project.
clean: begin clean_list finished end

clean_list :
        @echo
        @echo $(MSG_CLEANING)
        $(REMOVE) $(TARGET).hex
        $(REMOVE) $(TARGET).eep
        $(REMOVE) $(TARGET).obj
        $(REMOVE) $(TARGET).cof
        $(REMOVE) $(TARGET).elf
        $(REMOVE) $(TARGET).map
        $(REMOVE) $(TARGET).obj
        $(REMOVE) $(TARGET).a90
        $(REMOVE) $(TARGET).sym
        $(REMOVE) $(TARGET).lnk
        $(REMOVE) $(TARGET).lss
        $(REMOVE) $(OBJ)
        $(REMOVE) $(LST)
        $(REMOVE) $(SRC:.c=.s)
        $(REMOVE) $(SRC:.c=.d)
        $(REMOVE) .dep/*



# Include the dependency files.
-include $(shell mkdir .dep 2>/dev/null) $(wildcard .dep/*)


# Listing of phony targets.
.PHONY : all begin finish end sizebefore sizeafter gccversion \
build elf hex eep lss sym coff extcoff \
clean clean_list program

---

2. Die Übertragung sollte (so glaub ich) per Bascom-AVR gehen. Einfach das Hex-File auswählen und übertragen? (Mein Laptop hat kein Parallelport, es ist jedoch eine an der Dokingstation vorhanden, USB-ISP-Dongle kostet fast gleichviel wie ein Board) Die Übertragung mit dem Beispielprogramm hat funktioniert. Die Batteriespannung wird angezeigt, …

3. Wieso gibt es immer noch kein Tutorial, wie man das C-Programm auf den Controller kriegt? Ist denn C++ so selten? :-k

Gruss
Euer Adso

PS: Im Forum habe ich nichts passendes gefunden.

Welchen Compiler verwendest du, C++ macht auf einem AVR wenig bis keinen Sinn.
Verwende das AVR-Studio zum compilieren, dort kannst du auch deine Programme erstellen. Übertragen kannst du sie dann mit PonyProg, oder was du sonst verwenden willst.

RN-Control -> AtMega32

Kannst du mir beschreiben, wieso C++ für AVR keinen Sinn macht? Da ich noch wenig Ahnung habe, dachte ich, dass ausser der Syntax kein grosser Unterschied herrscht. Der Asuro ist bekanntlich mit einem AtMega8 aufgebaut und wird vorallem in C programmiert.

Du hast es richtig geschrieben, vor allem in C programmiert, aber nicht in C++. C++ beinhaltet zwar den C Syntax aber doch mit einigen mächtigen Erweiterungen die auf einer µC-Plattform keinen Sinn machen, oder diese sogar bei weitem überfordern würde.
Die Frage nach dem C-Compiler den du verwendest, hast du mir noch nicht beantwortet.

Das ist wahrscheinlich mein Problem. C++ ist in der "Einsteigerversion" sowieso nur C. Also das richtige für mich :D

Mit allen Programmen hänge ich noch ein wenig. Von mir aus wäre Eclipse das richtige, leider hänge ich da noch. Beschrieben wird alles im Microcontrollerforum:
http://www.mikrocontroller.net/articles/AVR_Eclipse

Jetzt möchte ich jedoch entlich mal programmieren können.
Mein Aufbau: jetzt per Parallelport vom Laptop über ISP-Dongle von robotikhardware.de auf die ISP-Schnittstelle des RN-Control 1.4 Board. (ISP Dongle hängt an LTP-1.)

Bei der Software habe ich einiges an Problemen: Was empfehlt ihr, damit es grundsätzlich klappt mit der Programmierung? Tutorials helfen mir nicht wirklich weiter, da es noch beim Start hängt. Wie schon beschrieben: Bascom-AVR klappt hervorragend, leider möchte ich C. Compiler sollte WINAVR sein.

Jetzt habe ich bereits den gesammten AVR-Kram ausprobiert: AVR Studio und Programmer's Notepad. Ich komme jedoch einfach nicht darauf, wie ich die Programme einstellen kann, damit die Programmierung klappt. Im Anhang habe ich direkt ein Bild der (fast) Standartkonfiguration und des Projekts erstellt im Programmer's Notepad erstellt. Leider klappt es hier überhaupt nicht. Programmer's Notepad scheint mir bisher nochBS ist Windows.

Und noch was: Braucht ich irgendeinprogramm wie WINdude zum flashen?

Und noch herzlichen Dank für die superschnellen Antworten.

Gruss
Euer Adso

Hallo Adso,

sicherlich kann Dir Hubert.G besser raten als ich, aber ich bin näher am Anfang als er - eben noch nicht soooo lang "im Geschäft" wie er. Daher ein paar Anmerkungen von mir.

Zitat:

---

Zitat von adso

... Jetzt möchte ich jedoch entlich mal programmieren können ... Parallelport vom Laptop über ISP-Dongle von robotikhardware.de auf die ISP-Schnittstelle des RN-Control 1.4 Board ...

---

Genauso ist es richtig.

Zitat:

---

Zitat von adso

... Jetzt habe ich bereits den gesammten AVR-Kram ausprobiert: AVR Studio und Programmer's Notepad. Ich komme jedoch einfach nicht darauf, wie ich die Programme einstellen kann, damit die Programmierung klappt ...

---

Diese Schwelle habe ich ganz einfach genommen - ich habe keinerlei Einstellungen (zum Übersetzene/Compilieren) gemacht.

Mein Ausgangspunkt: AVRStudio als Programmierumgebung und WINAVR als GCC-Compiler. Meine Kenntnisse zum Compilieren - uralt, um es mit einem Wort zu sagen. Meine Kenntnisse in C: Null. Daher hatte ich in AVRStudio ein neues Projekt aufgemacht, den Controller gewählt, den Code (Beispiel aus dem Forum, nicht selbst erstellt) ins Codefenster gepackt und auf [F7] gedrückt. Den Rest machte "der Computer". Es klingt ein bisschen wie - und ist es auch - experimentelles Programmieren. Läuft oder läuft nicht.

AVRStudio macht beim Einrichten des neuen Projektes einen Standard-Makefile in dem alles Mögliche, aber eben in Standardversion, drinsteht. Und es klappte.

Zitat:

---

Zitat von adso

... Und noch was: Braucht ich irgendeinprogramm wie WINdude zum flashen? ...

---

Dazu hatte ich PonyProg genommen (kostenlos erhältlich). Auch hier waren die Einstellungen ziemlich einfach, geht meist aus der on-board-Hilfe der Software hervor - ansonsten hatte ich im Forum gefragt.

Dann hatte ich, glaube ich, das Beispielprogramm in C für die RNControl ins Editorfenster von AVRStudio geladen, die rncontrol.h ins Projektverzeichnis gestellt und compiliert. Flashen - und fertig. Danach kamen einzelne Änderungen um vorsichtig zu sehen, wie das eigentlich laufen sollte. Mittlerweile bin ich über die ersten Schritte hinaus und mein kleiner Roboter läuft - selbst programmiert. Ach ja, erste Fallen bei Textausgabe über RS232 an PC hatte mir Hubert.G repariert. Auch über andere Stolperstellen wurde mir von ihm und anderen geholfen.

Viel Erfolg

Wow, dankeschön.
Bis jetzt hat alles funktioniert, selbst das übertragen habe ich hinbekommen. Leider ertönen lediglich einige tiefe Töne, und die Tasten haben keine Wirkung, obwohl ich das Beispielprogramm übertragen habe. Ich habe dazu das Hex-File aus /default genommen.
Wenn ich das Beispielprogramm, das als Hex vorliegt, mit PonyProg übertrage, funktioniert das Board, wie es sollte.
Wenn ich die Hex-Dateien anschaue, fällt mir auf, dass sie komplett unterschiedlich sind.
Im Anhang habe ich nochmals ein Screenshot, wie das AVR Studio eingestellt ist.


Zu sagen gibt es noch was: Die Version des Ponyprogs auf der Robotikhardware hat kein AtMega32. Es klappt jedoch mit einer neuen Version aus dem Internet.

Also so wie ich das sehe sind das lediglich die Optionen für den Debugger (den ich übrigens nicht Empfehlen kann da er macht was er will). Es sei denn meine AVR Studio Kenntnisse sind total für die Katz.

IdR musst du einfach oben rechts den Controllertyp auswählen - Programmieren und Kompilieren. Dann erstellt er eben das besagte .hex file im default Ordner. Wenn du das Überträgst sollte es vorrausgesetzt das Programm ist richtig, klappen.

Achja: Die Frequenz wird im Programm selbst definiert vielleicht hast du das vergessen oder eben die falsche Frequenz eingestellt.

#define F_CPU 4000000UL so oder so etwas aehnliches sollte irgendwo stehen. (Angepasst an den verbauten Quarz )

Empfehlen kann ich fuer Anfänger www.mikrocontroller.net dort lernt man zumindest die Basics.

Ansonsten gibt es vllt noch die Option das die .hex file aus dem Forum von einer neueren Version des Programms stammt und das Programm eben fehlerhaft ist.

Schreib einfach selber ein kleines Programm um vllt einen Taster und eine LED "anzusteuern". Wenn das geht sollte der Rest auch funktionieren.

P.S: Wenn ich falsch liege tuts mir leid ;)

Zitat:

---

Zitat von adso

... Bis jetzt hat alles funktioniert, selbst das übertragen habe ich hinbekommen ...

---

Fein, das ist ja ein Fortschritt.

Zitat:

---

Zitat von adso

... ertönen lediglich einige tiefe Töne, und die Tasten haben keine Wirkung, obwohl ich das Beispielprogramm übertragen habe ...

---

*gggg* - zum Glück machst Du ähnliche Fehler wie ich.

Tiefe Töne entstehen vermutlich dadurch, dass Du die Fuses nicht ordentlich eingestellt hast - ein typischer (Anfänger-) Fehler. Klick in PonyProg auf den Button "Security and Configuration Bits" - das ist der mit dem Vorhängeschloss. Dann klicke auf [Read] um die Fuses auszulesen. Jetzt steht wohl in dem weißen Kästchen neben CKDIV8 ein schwarzes Häkchen. Das wird ausgeklickt - das Kästchen ist jetzt weiß. CKDIV8 heißt, dass der Clock (Prozessortakt) durch 8 dividiert wird - daher die tiefen Töne! Jetzt könnte es sein, dass bei Dir noch neben JTAGEN auch ein schwarzes Häkchen steht. Auch dieses wird auf weiß geklickt. Danach die Fuses Zurückschreiben - also auf [Write] klicken. Vorsicht! Wenn das eine oder andere kritische Fuse falsch gesetzt ist, dann geht anschließend nix mehr. Also: Fuses lesen - und sicher sein, dass keinerlei Fehlermeldung kommt. Danach nur das tun, was hier steht - und Fuses zurückschreiben. Nun müsste das Testprogramm richtig laufen. >>> Sollte CKDIV8 NICHT angehakt sein, dann warte mit dem [Write]. Vielleicht liegts an dem angeblichen Takt 16800000 Hz. Dann diskutieren wir noch mal ! ?

Zitat:

---

Zitat von adso

... Im Anhang habe ich nochmals ein Screenshot, wie das AVR Studio eingestellt ist ...

---

Gut dokumentiert. Fein. Aber was ist das für ein seltsamer Prozessortakt: 16 800 000 Hz. Diese Frequenz ist wohl eher (D)ein Tippfehler ! ? ! ? Übrigens lasse ich mir auch Map und List Files erstellen. Die können (wenn man später etwas mehr weiß) ganz praktisch sein. Der Outputfile "RN-Control.etc" ist ein seltsamer Name. Meine Outputfiles heißen *.elf. Aber wenn Du so klar kommst - Du wirst es sicher später perfektionieren und alles nach "richtig" bringen.

Viel Erfolg.

Eine Freudensmeldung: ES FUNKTIONIERT! Danke tausendfach.

Danke vielmals, die Fusebits sind zwar immer wieder beschrieben, es scheiterte jedoch am Ponyprog und am Tutorial: http://www.robomodules.de/portal/ind...?id=112&type=1

Noch eine Frage: Wie kann man von C89 auf C99 umstellen, damit man eine Variable in einer For-Schleife bestimmen kann(for(int i=0, i<255, i++)?

Gruss
Euer Adso

Zitat:

---

Zitat von adso

... Freudensmeldung ...

---

Dann mein Glückwunsch, schön!

Zitat:

---

Zitat von adso

... es scheiterte jedoch am Ponyprog und am Tutorial ...

---

PonyProg ging nicht? Tutorial war nicht tut (verständlich) genug? Woran lag es denn? Lag es an den Fuses? Egal, nun geht es ja. Wenn Du noch mehr Fuses umstellen willst (der Name Fuse kommt NICHT von Kon-Fus-ion) dann guck Dir mal diesen Fuse-Rechner an. Da hab ich am mega32 die Fuses seeeeehhhhr sparsam eingestellt *ggggg*.

Zitat:

---

Zitat von adso

... Noch eine Frage: Wie kann man von C89 auf C99 umstellen, damit man eine Variable in einer For-Schleife bestimmen kann(for(int i=0, i<255, i++)? ...

---

No entiendo (muss ich in Spanisch schreiben, weil mir der ganze Satz spanisch vorkommt). Auf Deutsch: Kapier grad nix. Ich kenne allenfalls den C64 - der hat aber mit Mikrocontrollern nichts zu tun.

for(int i=0; i<255; i++)
{

}

So sollte das aussehen.. keine Kommas wenn du das wissen wolltest

Hallo,

unter Project -> Configuration Options (Da warst du ja schon)
Seitlich den Tab Custom Options und dann -std=c99 zufügen.

Gruß

Jens

Hi, McJenso, hallo adso,

und bitte - was bedeutet das jetzt? Ich habe bei mir das -std=gnu99 gefunden. (Hatte ja gesagt, dass ich NIE etwas an der Configuration einstelle, FAST nie - solche Arbeiten hatte bisher AVRStudio praktisch immer für mich gemacht *gggggg*).

Über die www.gnu.org habe ich eine Erklärung gefunden:

Zitat:

---

Zitat von Die GNU-Website - GCC 4.2 Release Series
Changes, New Features, and Fixes

-std=c99 or -std=gnu99 will direct GCC to handle inline functions as specified in the C99 standard. In preparation for this, GCC 4.2 will warn about any use of non-static inline functions in gnu99 or c99 mode

---

... nur verstehe ich nicht, was das hilft - oder was ein anderer Modus nicht hilft ? ? ?

Hallo,

C89 bzw C99 ist der Name für die Norm von C. Erst gab es C89 dann wurde C erweitert und so entstand nach und nach C99. Das sind übrigens imoh die Erscheinungsjahre.
In C89 war for (int i;i<10;i++){} so nicht vorgesehen, in C99 schon.
Bzw bei C89 durften die Deklarationen nur am Anfang stehen.
Es gibt natürlich noch andere Sachen die geändert wurden.


Gruß

Jens

Hallo McJenso,

danke, grad bin ich mit einigen Leseminuten fertig: Kernighan/Ritchie und AVR-GCC-Tutorial beim netten mikrocontroller dot net. So einen Schimmer von static (und dessen Gegenteil) und dem möglichen Sinn vor Warnungen zu inline-Funktionen habe ich bekommen. Vielleicht wird dieser Schimmer mal zu einem Licht.

Jedenfalls vielen Dank für Deine Erklärung. Das mit den Erscheinungsjahren hatte ich (fast) gedacht - obwohl mein Horizont fast bei FORTRAN77 aufhört *gggg*. Und über verschiedene C-Standards aus unterschiedlichen Zeiten lassen sich ja auch K+R ja hin und wieder aus.

So, danke vielmals.

Jetzt programmiere ich mal eine Weile und bau mir dann noch ein Roboter zum RN-Control.

Gruss
Euer Adso

Hallo zusammen

Ich muss das Thema gleich nochmals aufgreifen. Ich habe noch ein wenig herumgespielt und geschafft, die Fusebits zurückzusetzen. Das wäre ja nicht schlimm, es gab wieder die tiefen Töne. Leider habe ich dann einen Kollegen (Er erzählte mir, er arbeite viel mit Ponyprog ...) gefragt, wie ich die Fusebits einstellen muss. Leider hat er mir gesagt, es müsse alles wie im Vordefinierten AVRStudio sein. Unter Complimieren -> "Disconnected Mode" -> "Fuses":
[X] Bootsz=11 (Boot Flash size=256 words Boot start adress=$3F00)
[X] Bodlevel=1 (Brown-out detection level at VCC=2.7 V)
[X] CDSEL=1111 SUT=11 (Ext. Crystal/Resonator High Freq,; Start-up time: 16CK + 64ms)
Alle anderen Kästchen sind deaktiviert.
Somit hat er mir gesagt, ich solle im Ponyprog die Fuses folgendermassen einstellen: (Natürlich Finger weg von Bootlock und Lock).
[ ] OCDEN
[ ] JTAGEN
[ ] CKOPT
[ ] EESAVE
[X] BOOTSZ1
[X] BOOTSZ0
[ ] BOOTRST
[X] BODLEVEL
[ ] BODEN
[X] SUT1
[X] SUT0
[X] CKSEL3
[X] CKSEL2
[X] CKSEL1
[X] CKSEL0
Naja, im nachhinein ist man immer schlauer, ich hätte alle Kreuzlein invertieren müssen. (Nach microcontroller Forum)->
[X] OCDEN
[X] JTAGEN
[X] CKOPT
[X] EESAVE
[ ] BOOTSZ1
[ ] BOOTSZ0
[X] BOOTRST
[ ] BODLEVEL
[X] BODEN
[ ] SUT1
[ ] SUT0
[ ] CKSEL3
[ ] CKSEL2
[ ] CKSEL1
[ ] CKSEL0

Stimmt das So? Der ATMEGA32 reagiert nicht mehr und einen Frequenzgenerator (nach Kollegen sollte das so gehen) habe ich leider nicht. Ich habe jedoch bereits einen neuen ATMEGA32 bestellt und der sollte voraussichtlich morgen bereits kommen. Frequenz sollte 16Mhz sein.

Gruss und Dank
Euer adso

Hallo,

die Bits für den Takt passen so. Möchtest du On Chip Debug, Jtag und Brown-out detection wirklich aktivieren? Brauchst du das?
Wenn der neue AtMega da ist programmier damit erst einmal einen Taktgenerator, ohne die Fusebits zu ändern, also mit internem Takt. ;-)
Damit solltest du den anderen wiederbelebt bekommen.
ansonsten noch der Link auf den beliebten fusebit calculator.

Gruß

Jens

Der Atmega32 scheint komplett tot zu sein. Kann keine Progs oder Fusebits überschreiben.

In den Fall sieht die optimale Einstellung folgendermassen aus (nach Fusebit calculator):
[ ] OCDEN
[ ] JTAGEN
[X] CKOPT
[ ] EESAVE
[ ] BOOTSZ1
[ ] BOOTSZ0
[ ] BOOTRST
[ ] BODLEVEL
[ ] BODEN
[ ] SUT1
[ ] SUT0
[ ] CKSEL3
[ ] CKSEL2
[ ] CKSEL1
[ ] CKSEL0

:cry: :cry: :cry:

Wäre nicht so schwer. Was muss ich denn tun, um ihn mit 16 MHz laufen zu lassen? Im Manual steht nur was zu tun ist bis 8MHz. (Anhang)
Leider sind diese Fusebits wenig schwer zu verstehen, wenn man erst in die Thematik eingestiegen ist. Zum Glück seid ihr noch da. Vielen, vielen Dank. O:)

Vielleicht wäre es an der Zeit ein Beispiel in RN Wissen fürs RN-Control mit C anzulegen?


Gruss
Euer Adso

Wenn du einen 16MHz Quarz laut Datenblatt anschaltest passt es so.
Wenn dieser Mega32 dann läuft versorgst du deinen alten M32 mit Spannung und machst eine Verbindung von neu XTAL2 auf alt XTAL1.
Damit hast du einen ext. Takt auf deinem alten M32 und dann kannst du auch bei diesem die Fusebit umstellen, denn kaputt ist er sicher nicht.

Zitat:

---

Zitat von adso

... ein wenig herumgespielt und geschafft, die Fusebits ... gab wieder die tiefen Töne ...

---

So etwas kommt schon mal vor.

Zitat:

---

Zitat von adso

... einen Kollegen (Er erzählte mir, er arbeite viel mit Ponyprog ...) gefragt...

---

Warum sollte auch ein persönlich bekannter Kollege schlechter sein als wir anonymen AVRholiker? Das ist garnicht spöttisch gemeint. Könnte mir auch so gehen.

Zitat:

---

Zitat von adso

... ich hätte alle Kreuzlein invertieren müssen ...

---

Dumm gelaufen.

Zitat:

---

Zitat von oberallgeier am: 27 Nov 2008, 21:26

... dann guck Dir mal diesen Fuse-Rechner an ...

---

Zitat:

---

Zitat von McJenso am 01 Dez 2008, um 17:31

... ansonsten noch der Link auf den beliebten fusebit calculator ...

---

In diesem Fusebitrechnern steht das mit dem Invertieren etwa so drin. Leider ist das nicht WIRKLICH einfach verständlich dargestellt. Da fallen viele drauf rein.

Zitat:

---

Zitat von adso

... Vielleicht wäre es an der Zeit ein Beispiel in RN Wissen fürs RN-Control mit C anzulegen ...

---

Ganz unten auf der RNControl-Seite steht der passende Link dazu.

Zitat:

---

Zitat von adso

... Ich habe jedoch bereits einen neuen ATMEGA32 bestellt ...

---

Na ja, für weitere Spielereien gibts ja nun den neuen Trick von Hubert.G - übrigens danke Hubert.G dafür, damit hatte ich erst kürzlich zwei Controller gerettet.

der 16MHz quarz ist sicherlich richtig geschaltet -> RN-Control

Mit meinen wenigen Widerständen, Quartze, … zu Hause ist das so eine Sache mit dem neu Ansteuern. Nach Schaltplan müsste ich ca 10 Pins ansteuern (6, 7, 8, 9, 10, 11, somit 13, 30, 31, 32) ohne Wirkliche Ausstattung spende ich lieber 10 € für einen neuen Atmega. Der alte Atmega werfe ich sicherlich nicht fort und vielleicht ergibt sich einmal etwas.
Gibt es sonst keine Fehler in den Fusebits?

So, habe heute den ATmega bereits bekommen. Natürlich direkt ausgewechselt und versucht zu programmieren.
*grins* ich bekam immer den Fehler, dass Ponyprog den MIC nicht findet. *grins* ... bis ich gemerkt habe, dass das Netzteil nicht eingeschaltet war *grins* ](*,) ](*,)

Naja, jetzt funktionierts. Leider ist das mit den tiefen Tönen wieder da. Ich habe gleich ein Programm geschrieben, das mir über die RS232 Schnittstelle im Sekundentakt was ausgibt. Das klappt auch. (Jede Sekunde, nicht jede 2. Sekunde). Also Zeitlich funktioniert das Ganze. Für mich heisst das, dass auch die Taktfrequenz stimmen müsste.

Code:

---

        for (unsigned char i=0; i<50; i++){
                sendUSART("Jetzt");
                setportcoff(0);
                waitms(150);
                setportcon(0);
                waitms(850);
        }

---

Dann habe ich die Soundausgabe unter die Lupe genommen. Die Funktion ist ja sound(höhe, länge) und die Ausgabe sieht dann so aus: es ist eine Schleife, die einige Male durchlaufen wird, bis sie die Zahl der Länge erreicht hat. In der Schleife wird der Port aktiviert, x millisekunden gewartet, ausgeschalten und x millisekunden gewartet, bis die Schleife von neuem Startet (x=höhe). daraus ergibt sich eine Frequenz von f=1/(2*Höhe) [kHz]. Beim Beispiel wird u.A. auch Höhe=7 angenommen, was zu einer Frequenz von 71 Hz führt. Es muss also beim Beispielprogramm in C so tief sein. (Nach mir wird f=440Hz für Musikinstrumente zum Stimmen gebraucht, aber nur so als Vergleich.) ](*,) ](*,)

Code:

---

        sound(6, 270); //Startmelodie
        sound(8, 270);
        sound(11, 270);
        sound(7, 270);
        waitms(10);
        sound(7, 270);
        sound(6, 270);
        sound(11, 540);

---

und

Code:

---

void sound(uint8_t hoehe, uint16_t laenge)
{
        for(uint16_t i=0; i<laenge*15; i=i+(2*hoehe))
        {
        setportdon(7);
        _delay_ms(hoehe);
        setportdoff(7);
        _delay_ms(hoehe);
        }
}

---

und ich dachte schon ...
Hat jemand eine Funktion, bei der man also anstatt einer Maximalen Frequenz (höhe=1 -> Frequenz=500), eine Ausgabe mit sound (frequenz, länge in ms) hat?

Jetzt hab ich also den Fehler, es war nicht die Arbeitsfrequenz des Atmega, sondern ein Denkfehler, dass die Töne standartmässig höher sein müssten.

Gruss und Dank

Zitat:

---

Zitat von adso

... tiefen Tönen wieder da ... Programm ... das ... im Sekundentakt was ausgibt ...

---

Hmmm, und wie entsteht der Sekundentakt?

Zitat:

---

Zitat von adso

... waitms(150); waitms(850); ...

---

Aha. Dem waitms traue ich nie. Aber der Test ist für diesen Zweck wohl einigermaßen ok. Wie sehen Deine Fuses aus? Sind die mit dem Vorschlag des fuse calculators abgestimmt?

Ich habe mir vor Zeiten eine Routine geschrieben, die den Hardwaretimer des aktuellen µC´s benutzt und einen 50 µs-Takt erzeugt (Code für m168 ist hier gezeigt) . Da zähle ich in der ISR z.B. von 1 rauf auf 20 000 - das ist dann genau 1 sec. - - - und zwar nur dann, wenn der zugrundegelegte Takt auch stimmt. Übrigens flackert während meiner Hard+Softwareentwicklung fast immer eine LED (meist auf dem sowieso aufgebauten I2C-Stecker), die im Sekundentakt auf-und-ab-schaltet - solange Interrupt enabled ist. Die lasse ich auch nach dem Reset aber vor dem Erlauben der Interrupts kurz blitzen _ - und hier kommt eine meiner wenigen waitms-Anwendungen. Ein oder zwei Sekunden lang 3/97 waitmsse. Eine sehr praktische Einrichtung, um gelegentlich pannenweise auftretende Interrupts zu entdecken und der Sekundentakt zeigt mir sofort Taktprobleme.

Aber jetzt scheint ja bei Dir alles im Lot zu sein.

Ok, das mit dem Sekundentakt hab ich nochmals angeschaut -> ist wirklich dumm gemacht und hat eine sehr hohe Abweichung.

Das mit dem Calculator habe ich nochmals angeschaut.
In dem Fall kommt es mir so heraus:
[ ] OCDEN
[ ] JTAGEN
[ ] CKOPT
[ ] EESAVE
[X] BOOTSZ1
[X] BOOTSZ0
[ ] BOOTRST
[ ] BODLEVEL
[ ] BODEN
[ ] SUT1
[ ] SUT0
[ ] CKSEL3
[ ] CKSEL2
[ ] CKSEL1
[ ] CKSEL0

(Auswahl:
Ext. Clock, Start-up-time: 6CK +64ms, [CKSEL=0000 SUT=10]
Alle Kreuzlein deaktiviert (da ich offenbar davon nichts brauche,
BodLevel=1, Bootsz=01)

Ist vielleicht eine saudumme Frage, aber ich muss die Häckchen im Ponyprog genauso wie im Fuse Calculator setzten, also nicht invertiert? Und seid ihr mit der Auswahl zufrieden? Jetzt muss es fast einmal stimmen. =P~ Doch meine Frage: Wie erkennt der MIC ob es ein 16MHz oder ein 8MHz Quarz ist?

Gruss und Dank
Euer Adso

Hallo adso,

der waitms-(Sekunden-)Takt ist praktisch, aber eben von der Sorte "quick ´nd dirty".

Deine Fuses sind ja ganz ok - ich nehme an, Du hast da den Bootloader drin? Sonst würde der viele Bootloader-Speicherplatz nicht recht Sinn machen. Ich habe bei meinem selbst geflashten M32 diese Fuses. (Anm.: gerade ausgelesen - extra für Dich - mit PonyProg aus dem m32 in der RNControl mit meinem selbst geschriebenen/compilierten/geflashten Testprogramm).

Die Fuses im PonyProg setzt Du so wie im attachement gezeigt, wenn Du Deine Auswahl "drin" haben willst.

Zitat:

---

... Doch meine Frage: Wie erkennt der MIC ob es ein 16MHz oder ein 8MHz Quarz ist? ...

---

Tja, das ist die Frage. Soweit ich es weiß, erkennt der Quarz das garnicht *gggg* (ist nicht spöttisch gemeint - es ist eben so --- woher weiß Dein Auto, dass in der Stadt nur 50 gefahren werden darf?). Du sagst das dem µC im Quelltext, so nach der Art (hier für meinen m168 mit 20 MHz):

Code:

---

#define MCU = AVR_ATmega168
#define F_CPU  20000000        // Quarz 20 Mhz-CPU

---

Eine andere Möglichkeit, den Quarztakt zu definieren ist es auch, den Wert im makefile oder im Compiler reinzuschreiben (mit Beidem habe ich null Erfahrung - ich mache es immer so, wie es oben steht).