Ahoi. Ich spiele gerade mit der seriellen Schnittstelle vom ATmega 2560
rum und habe da ein String-Problem. Es handelt sich konkret um einen
Arduino mit ATmega 2560, der mittels ISP & AVR Studio 7.0 programmiert
wird (nicht über die Arduino IDE). Für die serielle Schnittstelle habe
ich die allgemein etablierten Funktionen uart_putc und uart_puts
verwendet. uart_putc (Char) funktioniert tadellos. uart_puts
funktioniert nur für Strings mit einer Länge von 3-4 Zeichen. Bei
längeren Strings werden nur 0xFF Bytes übertragen.
Hier meine Main-Loop.
Am Linker liegt es nicht, oder siehts du da eine Fehlermeldung?
Aber dein putc dürfte das Problem verursachen. Da du das aber nicht
zeigst...
Schau dir im Tutorial nochmal das Kapitel zu Daten im Flash an.
Olivet
Oliver S. schrieb:> Am Linker liegt es nicht, oder siehts du da eine Fehlermeldung?>> Aber dein putc dürfte das Problem verursachen. Da du das aber nicht> zeigst...>> Schau dir im Tutorial nochmal das Kapitel zu Daten im Flash an.>> Olivet
Nein, an putc liegt es nicht. Sonst würde doch A-Z nicht ausgegeben
werden. Und putc sieht aus wie im Tutorial.
Bernd schrieb:> Ein Tipp: Gehe mit dem Simulator Schritt für Schritt durch dein> Programm, dann sollte sich der Fehler offenbaren.
Auch das habe ich schon gemacht und das sah gut aus. :-)
Sascha S. schrieb:> Bernd schrieb:>> Ein Tipp: Gehe mit dem Simulator Schritt für Schritt durch dein>> Programm, dann sollte sich der Fehler offenbaren.>> Auch das habe ich schon gemacht und das sah gut aus. :-)
Dann ist ja alles OK. Klinke mich hier aus.
Das liest aber aus dem RAM, nicht aus dem Flash.
Also muss hier __flash verwendet werden, und die Funktion funktioniert
dann nur für Strings im Flash. __flash muss dann auch der Address-Space
sein in dem die (String-)Objekte liegen wie Bernd schon schrieb.
Oder eben die Asbach Lösung mit pgmspace.h + pgm_read_xxx.
Bernd schrieb:> Was funktioniert nicht? Wie sieht die Ausgabe aus?
Vielleicht so, wie im Anhang des ersten Beitrages?
Bernd schrieb:> Dann ist ja alles OK. Klinke mich hier aus.
Besser ist das.
Interessant ist, dass das erste "ABC" richtig ausgespuckt wird.
Im Debugger sind die ?=0xFF Zeichen richtig belegt.
Als Anhang noch das LSS File.
Ich bin ratlos. :/
Sascha S. schrieb:> Moin Männer,
Es gibt hier auch Frauen!
Der LSS-File entspricht nicht dem C-Code den Du hier gepostet hast.
Das wollte ich einmal festhalten. Denn das ist nicht gut, wenn man Dir
helfen soll.
Lt. LSS-File ist das Array b falsch, das passt nicht.
Vorschlag:
Bereinige Dein Projekt mit Make Clean. Das 7er Studio kenne ich nicht,
das sollte allerdings ein Menüpunkt unter Build sein.
Lösche alle Hex+Elf Files im Projekt-Ausgabeordner.
D.h., vor allem die Datei die auf den AVR schreibst.
Hast Du auch die richtige Datei verwendet?
Dann lösche ALLE const Definitionen. Auch in den uart-Routinen.
Wo hast Du denn die abgekupfert?
Danach änderst Du alle char (unsigned oder nicht) in uint8_t.
Schalte in der Compiler-Konfiguration die Warnings auf -Wall und die
Optimierung auf -O0 (keine Optimierung).
Jetzt solltest Du das Programm noch einmal compilieren und testen.
Sollte funktionieren.
Hallo Codix & guten Morgen zusammen,
ich habe Codix Vorschläge durchprobiert und es ändert sich nichts an der
Ausgabe. Habe extra ein neues Projekt angelegt, aber ohne Erfolg. Ich
habe mal das komplette Projekt als ZIP angehängt.
Die const Anweisung hatte ich übrigens eingefügt, weil der Compiler
diesbzgl. eine Warnung ausspuckte.
Die Programmierung des µC erfolgt über Atmel-Studio (F5) via ISP. Ich
muss dazu keine Datei auswählen, sondern die IDE macht das für mich
unmittelbar nach dem Kompilieren automatisch. Sonst wäre ein
Entwicklungszyklus doch sehr umständlich. ;-)
Die Ausgabe bei der Compilierung:
1
------ Rebuild All started: Project: UART-Test, Configuration: Debug AVR ------
2
Build started.
3
Project "UART-Test.cproj" (Clean target(s)):
4
Target "Clean" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "E:\avr-sandbox\Atmel AVR\UART-Test\UART-Test.cproj" (entry point):
Sascha S. schrieb:> Nein, an putc liegt es nicht. Sonst würde doch A-Z nicht ausgegeben> werden. Und putc sieht aus wie im Tutorial.
Wie du meinst...
Du rufst puts mal mit Strings im Flash und man mit Strings im SRam auf.
Eins von beiden kann nicht funktionieren. Aber poste ruhig weiter völlig
sinnfreie Compilerausgaben. Ist dein Code und dein Problem...
Oliver
Oliver S. schrieb:> Sascha S. schrieb:>> Nein, an putc liegt es nicht. Sonst würde doch A-Z nicht ausgegeben>> werden. Und putc sieht aus wie im Tutorial.>> Wie du meinst...>> Du rufst puts mal mit Strings im Flash und man mit Strings im SRam auf.> Eins von beiden kann nicht funktionieren. Aber poste ruhig weiter völlig> sinnfreie Compilerausgaben. Ist dein Code und dein Problem...>> Oliver
Hallo Oliver,
eben, ich habe uart_puts mal mit Strings ausm SRAM und mal ausm FLASH
aufgerufen - um zu prüfen, welcher Speicher denn nun gelesen wird.
Beides hat aber nicht geklappt. Wenn Du dir meine letzten Postings
durchgelesen hast, dann siehst du, dass es auch bei einer
RAM-only-Lösung nicht funktioniert.
Mit dem Debugger kann ich umgehen und da war alles OK.
Und ich bleibe dabei, dass mein uart_putc semantische dem aus dem
Tutorial gleicht. :P
Tutorial:
1
intuart_putc(unsignedcharc)
2
{
3
while(!(UCSRA&(1<<UDRE)))/* warten bis Senden moeglich */
Letzte Idee von mir.
Es könnte sein, dass a und b innerhalb der main Probleme machen.
Was ich allerdings nicht wirklich glaube.
Aber zum Testen einfach die Deklaration global machen und
mit volatile versehen. Damit sollte sicher sein, dass der Compiler das
nicht mehr anfasst/irgend etwas optimiert.
Die Optimierung solltest Du wieder auf -O2 stellen, damit der Delay
sauber funktioniert.
Ausserdem solltest Du in den Compilereinstellungen des Studios -DF_CPU
angeben und nicht im Source.
1
#define F_CPU 16000000UL // <- Das in den Compiler settings
2
3
#include<avr/io.h>
4
#include<util/delay.h>
5
6
7
#define BAUD 9600UL
8
9
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
10
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
11
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)
12
13
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
14
#error Systematischer Fehler der Baudrate groesser 1% und damit zu hoch!
Danke Codix! Leider gibts weiterhin nur 0xFF.
Ich werde es morgen mal mit dem STK500 und anderen AVRs probieren -
derzeit ist es ja ein Arduino mit ATmega 2560. Der ist im Gehäuse etwas
praktischer auf der Couch, als das STK.
Mit großer Sicherheit kann man sagen, dass es ein Flash/Speicherproblem
ist. Wenn ich ein char[] Buffer (RAM) definiere und die ASCII-Codes da
nacheinder eintrage, dann klappt es. Weise ich dem char[] (RAM) einen
String zu, klappt es nicht. Speichere ich einen String im FLASH und
kopiere diesen in den char[] Buffer mittels strcpy_P, so hängt sich der
µC weg. Beim Debugging in der Simulierung vom Atmel-Studio kann man sich
die Speicherbereiche anschauen und es schaut alles i.O. aus.
Ich werde berichten, sobald ich neue Erkenntnisse habe. :)
Schönen Abend noch.
Codix schrieb:> Letzte Idee von mir.> Es könnte sein, dass a und b innerhalb der main Probleme machen.> Was ich allerdings nicht wirklich glaube.>> Aber zum Testen einfach die Deklaration global machen und> mit volatile versehen. Damit sollte sicher sein, dass der Compiler das> nicht mehr anfasst/irgend etwas optimiert.>> Die Optimierung solltest Du wieder auf -O2 stellen, damit der Delay> sauber funktioniert.>> Ausserdem solltest Du in den Compilereinstellungen des Studios -DF_CPU> angeben und nicht im Source.
TADAAAA!
Mit dem STK 500 und einem ATMEGA 8151 funktioniert es problemlos (RAM &
FLASH - Strings).
Nun kann man darüber Vermutungen anstellen, ob für den ATMEGA 2560 des
Arduinos falsch kompiliert wurde, der µC eine Macke hat oder irgendetwas
anderes im Busch ist. Mir ist es wurscht, denn ich war dem Wahnsinn
schon sehr nahe und nun ist es gelöst. Der Fehler lag nicht in meinem
Code.
Danke an diejenigen, die konstruktiv mitgeholfen haben. Und über die
dussligen Kommentare schmunzel ich jetzt mal. ;-P
VG
Innoran schrieb:> Sascha S. (excess) schrieb:>>> Und über die dussligen Kommentare schmunzel ich jetzt mal. ;-P>> Es ist schön, dass du über dich selbst lachen kannst.
:D :D Ja, ich kann auch über mich selbst schmuzeln. Und ich sehe auch
ein, dass nicht alles zu 100% korrekt von mir formuliert war. Aber ich
bin seit 20 Jahren Informatiker und habe ein gewisses Grundverständnis.
Bin mit Assembler auf C64 und Acorn Archimedes mit ARM-Processoren groß
geworden. Ist aber schon paar Jahre her und hauptberuflich nun auf
höherem Abstraktionslevel unterwegs. Manchmal bringe ich vielleicht
etwas durcheinander, aber Kommentare ala "Der Fehler ist in dem Code,
den du nicht zeigst" sind einfach Quark.
Sascha S. schrieb:> Mir ist es wurscht, denn ich war dem Wahnsinn> schon sehr nahe und nun ist es gelöst. Der Fehler lag nicht in meinem> Code.
Nun ja mit deiner unendlichen Erfahrung solltest du eigentlich wissen,
daß gar nichts "gelöst" ist. Du hast herausgefunden, daß ein anderer
Code auf einer anderen Hardware funktioniert. Das ist zwar prima, löst
aber nix.
Oliver
Oliver S. schrieb:> Nun ja mit deiner unendlichen Erfahrung solltest du eigentlich wissen,> daß gar nichts "gelöst" ist. Du hast herausgefunden, daß ein anderer> Code auf einer anderen Hardware funktioniert. Das ist zwar prima, löst> aber nix.>> Oliver
Lass uns doch nicht streiten. Ich habe mein "Problem gelöst", dass ich
eine serielle Schnittstelle mit einem AVR ausprobieren wollte. Der
C-Code vom 2560er und 8151er ist strukturell identisch. Ja, die Register
waren anders und der daraus resultiere Maschinencode auch. Ich bestelle
mir jetzt mal einen neuen 2560er [mist, gibts ja gar nicht als THT für
den Sockel] und teste den im STK 500. Von "unendlich" habe ich nichts
geschrieben - das wäre vermessen. Es sollte nicht überheblich rüber
kommen, nur dass ich (meist) weiß, was ich tue und warum. Manchmal
Trail-and-Error, wenn man der Verzweiflung nahe ist und es laut
Spezifikation eigentlich klappen sollte. Aber das haben wir doch alle
schon mal gemacht, oder? ;)
Mein einziger Fehler im ersten Beitrag war doch, dass ich aus dem Flash
direkt lesen wollte, d.h. den als RAM behandelt habe. Aber der
"RAM-String" hätte in jedem Fall ausgegeben werden müssen.
Schönes WE!
Hallo Zusammen,
mir ist klar, dass der Thread schon was älter ist, dennoch wollte ich
eine mögliche Lösung für das hier geschilderte Problem posten.
Ich habe jetzt selber mehrere Stunden verbracht mit dem atmega2560 und
der seriellen Kommunikation. Bei mir wurden Strings, die größer als 3
Zeichen waren nur als 0xff ausgegeben.
Hier lag's an den FUSE, besser gesagt am "boot reset vector". Da dieser
beim mega2560 R3 im Auslieferungszustand aktiviert ist wurden die
Strings nicht richtig ausgegeben. Im deaktivierten Zustand läuft alles
perfekt.
Gruß gunit
Thread beobachten
Seitenaufteilung abschalten