Problem mit Fleury UART lib und Mega644 ...

[vklaffehn]

Moin!

Ich bastel mal wieder, und verzweifel grad an folgendem :

Ich habe einen Mega644 mit Standardschaltung lt. RN-Wissen, also Spannungsregler 7805 mit Elko und Kerko (Schaltung läuft aber eh mit Akkus 6x1,2V), 10KOhm Pullup an Reset, 18,432 MHz Quarz mit 22pF Kondensatoren dran sowie Max232. Das erste Phenomän ist, die Übertragung von Daten zum PC (hterm) funktioniert nur bis 57600baud stabil, bei 115200 kommen Werte doppelt/fehlerhaft an, dabei ist das doch so ein schöner Baudratenquarz...
Das ist allerdings in meinem Fall nicht so schlimm, ich weiß nur nicht, ob das evtl. eine Randerscheiung meines eigentlichen Problems ist.

Das da wäre :

Daten senden mit

uart_putc(x)

geht, strings senden mit

uart_puts("text")

geht, aber beim senden aus dem Programmspeicher mit

uart_puts_p("text")

kommt mist, bzw. auch manchmal nur ein Byte, das aber auch schon falsch.

Ich habe die Bibliothek jetzt schon auf verschiedenen Controllern benutzt, aber noch nie auf dem 644, und hatte nie Probleme damit....

Ich hab die Schaltung nochmal neu aufgebaut, und auch den Mega644 sowie den Max232 getauscht, aber das wars nicht.

Das komplette Programm hänge ich mal dran, steht allerdings nicht viel drin...

Die bytes 0-255 kommen sauber an (bei 57600baud), das 'a' auch, das "test" nicht.

#include <avr/io.h>
#include <stdlib.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include "uart.h"
#include <avr/pgmspace.h>
#include <avr/eeprom.h>
#define UART_BAUD_RATE      57600
void init()
{
 DDRD = 0b00000010;
 uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
 sei(); 
}
int main(void)
{
 int x;
 init();
 //while (1)
 {
  for (x=0;x<=255;x++)
   uart_putc(x);
 }
 uart_putc('a');
 uart_puts_p("test");
 while (1)
 {}
}

MfG
Volker


/edit: Geschwindigkeitsrätsel gelöst, schien irgendwie an meiner Max232-Schaltung zu liegen, jetzt geht es auch mit 115200baud, und es hat sich herausgestellt, dass beim uart_puts_p die anzahl bytes stimmt, nur der Inhalt nicht.... also evtl. ein Problem in der UART lib, ich forsche mal, bin aber weiterhin für Tipps dankbar!!

[radbruch]

Hallo

Gleich vorweg: Ich kann's auch nicht erklären. Weil ich aber nun schon Zeit investiert habe, möchte ich meine Erkenntnisse wenigstens auch mitteilen.

Mein erster Verdacht: Ein Dual-USART mit dem die Peter Fleury-Lib nicht zurecht kommt. Da ich aber nur ein Mega64er-Datenblatt auf der Platte hatte, wollte ich zuerst einen Blick in das 644er-Datenblatt werfen. Zweiter Verdacht: Zugriff auf die falschen Register. Aber die Definitionen in uart.c scheint unverdächtig, weil eben vorhanden und auf den ersten Blick auch richtig:

#elif defined(__AVR_ATmega644__)
 /* ATmega with one USART */
 #define ATMEGA_USART0
 #define UART0_RECEIVE_INTERRUPT   SIG_USART_RECV
 #define UART0_TRANSMIT_INTERRUPT  SIG_USART_DATA
 #define UART0_STATUS   UCSR0A
 #define UART0_CONTROL  UCSR0B
 #define UART0_DATA     UDR0
 #define UART0_UDRIE    UDRIE0
#elif defined(__AVR_ATmega164P__) || defined(__AVR_ATmega324P__) || defined(__AVR_ATmega644P__)
 /* ATmega with two USART */
 #define ATMEGA_USART0
 #define ATMEGA_USART1
 #define UART0_RECEIVE_INTERRUPT   SIG_USART_RECV
 #define UART1_RECEIVE_INTERRUPT   SIG_USART1_RECV
 #define UART0_TRANSMIT_INTERRUPT  SIG_USART_DATA
 #define UART1_TRANSMIT_INTERRUPT  SIG_USART1_DATA
 #define UART0_STATUS   UCSR0A
 #define UART0_CONTROL  UCSR0B
 #define UART0_DATA     UDR0
 #define UART0_UDRIE    UDRIE0
 #define UART1_STATUS   UCSR1A
 #define UART1_CONTROL  UCSR1B
 #define UART1_DATA     UDR1
 #define UART1_UDRIE    UDRIE1

(Aus uart.c)

Was mir noch auffällt: Meine Datei uart.c stammt vom 29.11.2009 und ist die neuste Datei im Archiv. Die 644er-Definitionen sind die Letzten in der Datei und möglicherweise in deiner "schon immer verwendeten" Version nicht vorhanden/fehlerhaft.

Welcher 664er ist es denn?
http://www.atmel.com/dyn/products/de...ource=left_nav

Gruß

mic

P.S.:
Die Sende-ISR könnte auch ein Kandidat sein.

Noch ein Edit:
"Die bytes 0-255 kommen sauber an (bei 57600baud), das 'a' auch, das "test" nicht." ist doch klar. Das Senden geschieht asyncron über einen Ringpuffer und der Sende-ISR. Beim "T" von "Test" ist Schluß mit lustig:

 uart_puts_p("test");
 while (1)
 {}
}

Ich bin mir nicht sicher, würde aber eher ein ; nach while machen. Bauchgefühlsmäßig.

[vklaffehn]

Moin!

Ich habe den 644 ohne 'P', also mit einem USART, und die Bibliothek habe ich zwischendurch frisch heruntergeladen. das while-dingens ist ein Rest, es spielt keine Rolle, an welcher Stelle ich das uart_puts_p verwende....
ich habe das testweise in ener Endlosschleife laufen lassen, für das letzte 'test' kommen immer die selben 4 (falschen) bytes an, als würde der Controller Murks lesen, oder evtl. auch schon vorher schreiben, der Rest funktioniert ja....

[sternst]

Ich habe die Bibliothek jetzt schon auf verschiedenen Controllern benutzt, aber noch nie auf dem 644, und hatte nie Probleme damit....

Tja, dann hast du dort (im Gegensatz zu hier) wohl die richtige Funktion (eigentlich Makro) benutzt.
Entweder

uart_puts_p(PSTR("text"));

oder

uart_puts_P("text");

Aber bei

uart_puts_p("text");

liegt der Text im RAM, und dann liest die Funktion natürlich Müll aus dem Flash.

[radbruch]

Danke, wieder mal was gelernt:

/**
 * @brief    Put string from program memory to ringbuffer for transmitting via UART.
 *
 * The string is buffered by the UART library in a circular buffer
 * and one character at a time is transmitted to the UART using interrupts.
 * Blocks if it can not write the whole string into the circular buffer.
 *
 * @param    s program memory string to be transmitted
 * @return   none
 * @see      uart_puts_P
 */
extern void uart_puts_p(const char *s );

/**
 * @brief    Macro to automatically put a string constant into program memory
 */
#define uart_puts_P(__s)       uart_puts_p(PSTR(__s))

[vklaffehn]

Arg.

Danke. Da ich immer die zweite Variante benutzt habe, war mir überhaupt nicht bewußt, dass es das Makro auch mit kleinem 'p' gibt.... Hätte da nicht mal ein warning kommen können ?

Auf alle Fälle vielen Dank, jetzt kann ich mich endlich wieder dem Bluetoothmoduk widmen!

MfG
Volker