Hallo zusammen!
ich versuche in den letzten tagen das programm von manni
TWI_Master-Slave_C_Functions
Beitrag "AVR TWI Master und Slave Funtionen in C" zum laufen zu bringen!
ich benutzte einen atmega16 als slave und einen atmega 2561 als master!
ich habe die statusbytes entsprechend umbenannt, compilieren und flashen
funktioniert.
zum deguggen lasse ich mir über printf funktion texte ausgeben!
printf ("jetzt kommt die zahl\n"); funktioniert eiwandfrei!
Allerdings streikt bei mir die printf-funktion, sobald ich werte
ausgeben möchte zbsp: int test1=3; printf ("jetzt kommt die zahl: %d
\n", test1);
mein programm bzw meine terminals für die com schnittstelle hängen sich
dann immer auf!
------------------------------------------------------------------------
--
ich verwende die aktuelle avr studio 4.14 version und das im moment
neuesete winavr.
in anderen foren habe ich gelesen dass ich über die configurtion options
noch die bibliotheken lbprintf_flt.a und libprintf_min.a
und bei den custom options beim linker die -Wl,-u,vfprintf und
-lprintf_flt miteinfügen soll.
allerdings keine verbesserung oder verschlechterung!
kennst jemand den Fehler?
vielen dank
hans-jakob
>Allerdings streikt bei mir die printf-funktion, sobald ich werte>ausgeben möchte
Wie äussert sich das? Irgendwie mußt du das ja feststellen.
Wird bei der printf-Zeiel überhaupt etwas ausgegeben, oder lässt sie
sich schon nicht compilieren?
Also die "3" aus test1 scheint er ja auszugeben, nur den Text nicht, der
davor steht. Kann es sein, dass dein RAM irgendwie voll ist mit text?
Also wenn dein Programm sehr viel Text hat, solltest du diesen im
Flash-Speicher lassen und auch von dort ausgeben (siehe
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Array_aus_Zeichenketten_im_Flash-Speicher
). Ich persönlich verzichte auch immer auf printf etc. weils einfach den
ganzen code so aufbläht.
Timmo H. wrote:
> Also die "3" aus test1 scheint er ja auszugeben
Das ist keine 3, sondern ein <ETX>.
Irgendwie scheint das printf() in der benutzten Bibliothek kaputt zu
sein, oder falsche Bibliothek, weiß der Geier. Die ersten beiden
printf()s wird der Compiler vermutlich in puts() umwandeln (was aus
seiner Sicht eine Optimierung ist, da puts() ja schneller geht als
printf()).
Wie sehen denn die genauen Compiler- und Linker-Kommandozeilen aus?
Übrigens: Bildformate Screenshot als JPG sieht einfach grässlich
aus.
im Quellcode der main funktion werden folgende Funktionen eingebunden:
#include <stdio.h>
#include <avr/interrupt.h>
#include "General.h" // cpu usw..
#include "RS232.h" // RS232_Init(), RS232_putchar(),...
#include "Delay.h" // zeitverzögerung für die verlangsammung des HPT
prog
#include "TWI_Master.h" //twi master funktioen
Nee, bitte gib mir mal die Kommandozeilen, die wirklich aufgerufen
werden. Muss doch irgendwo in einem Message-Fenster zu finden sein.
Lieber auch als Text statt als Bildschirmschüsse.
Alternativ das generierte Makefile, dann kann ich es auch
nachvollziehen.
diese Fehlermeldungen beziehen sich auf den obigen Quellcode und sind
die abgespeckte Version, von ganz oben. ffprintff- ist der Name des
Projektes und der main-Datei. Also von den Namen bitte nicht abschrecken
lassen.
so und hier die compiler meldungen:
avr-gcc.exe -mmcu=atmega1281 -Wall -gdwarf-2 -std=gnu99 -Os
-funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT ffprintff.o
-MF
dep/ffprintff.o.d -c ../ffprintff.c
Build succeeded with 0 Warnings...
und die strg+F7 Bemerkungen:
Build started 7.5.2008 at 19:11:30
avr-gcc.exe -mmcu=atmega1281 -Wl,-u,vfprintf -Wl,-Map=ffprintff.map
ffprintff.o -lm
-lprintf_flt -o ffprintff.elf
avr-objcopy -O ihex -R .eeprom ffprintff.elf ffprintff.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load"
--change-section-lma
.eeprom=0 --no-change-warnings -O ihex ffprintff.elf ffprintff.eep ||
exit 0
avr-objdump -h -S ffprintff.elf > ffprintff.lss
AVR Memory Usage
----------------
Device: atmega1281
Program: 3598 bytes (2.7% Full)
(.text + .data + .bootloader)
Data: 52 bytes (0.6% Full)
(.data + .bss + .noinit)
Build succeeded with 0 Warnings...
***********************************************************************
LÖSUNG LÖSUNG LÖSUNG LÖSUNG LÖSUNG LÖSUNG LÖSUNG LÖSUNG LÖSUNG LÖSUNG
Über den Disassembler bin ich das Programm nochmals im Simulationsmodus
durchgeangen! hier habe ich dann festgestellt, dass im Assebmlercode
falsche Sprünge waren.
Bsp. eine While schleife sollte nur um eins zurückspringen, anstatt
wieder die while schleife zu wieder holen, wurde ein sprung von 0x21
gemacht - und somit habe ich mich dann in eine anderen Funktion gefunden
die eine Eingabe erwartet hat.
Hierbei wurde die Optimization: -Os verwendet!
Bei der Optimization: -O0 ist der Sprungbefehlfehler nicht aufgetaucht!
ich hatte die WinAVR version 20080402 und die AVR Studio 4.13 mit den
SP2 , später dann die 4.14 verwendet.
------------------------------------------------------------------------
---
Mittlerweile ist die WinAvr version 20080512 veröffentlicht und eine
Neuinstallation von AVR Studio 4.14 und WinAvr version 20080512
hat die ganze Sche ins Laufen gebracht!
vielen Dank für eure Mithilfe
Hans-Jakob