Eigener Versuch eines UART-Puffers

[Alex V. (bastel_alex)]

Hallo, sorry für den bereits zweiten Code-Beitrag heute:

Ich versuche gerade das erste mal UART-Kommunikation zwischen PC und 
AtMega644 umzusetzen. Einzelne Bytes senden und empfangen hat bereits 
geklappt - Hardware und UART-Konfiguration sollte soweit also stimmen.

Nun Habe ich versucht einen Sende-Puffer einzurichten. Das Ziel:
Es sollen immer 3 Byte in den Puffer geschrieben und nacheinander 
gesendet werden, während die nächsten drei Bytes in Vorbereitung sind. 
Das ganze soll Interrupt-Gesteuert und ohne Polling passieren.

Für den Code habe ich mir auch schon 
http://www.mikrocontroller.net/articles/Interrupt zu Gemüte geführt und 
mich auch grob daran orientiert, wollte das ganze aber noch 
spartanischer auf mich zugeschnitten einmal selber umsetzen.

Nur: Der Code läuft (natürlich) nicht, mal wieder die Frage warum.

// IM HEADER DEFINIERT: 
void transmit_string(volatile uint8_t * uart_tx_flag, char * uart_tx_buffer[], char data[3]);

// IN EINER C FILE DEFINIERT: 
/* Transmit a String */
void transmit_string(volatile uint8_t *uart_tx_flag, char *uart_tx_buffer[], char data[3])        
{
  if (&uart_tx_flag==1)              // check whether last string has been sent completely
  {
    for (int i=0; i<3; i++)
    {
      uart_tx_buffer[i] = data[i];      // Copy String into send buffer
    }
    uart_tx_flag = 0;              // Delete "Sent-Flag"
    UCSR0B |= (1<<UDRIE0);            // UDRIE Interrupt on
  }
}
// 

// MAIN FILE:

#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdlib.h>
#include <string.h>

#include "Mainboard_UART_functions.h"
#include <util/delay.h>

#define uart_buffer_size 3

// VARIABLES

unsigned char byte_buffer;
volatile uint8_t uart_rx_flag=0;            // Flag, complete string received
volatile uint8_t uart_tx_flag=1;            // Flag, complete string sent
volatile uint8_t rx_buff_cnt=0;        // RX buffer counter
volatile uint8_t tx_buff_cnt=0;        // TX buffer counter
char uart_rx_buffer[uart_buffer_size];      // Receive-Buffer
char uart_tx_buffer[uart_buffer_size+16];   // Send-Buffer



// UART TX data register empty interrupt:
// loading new data into UART sending register
ISR(USART0_UDRE_vect) 
{
  if (tx_buff_cnt > 2)      // Buffer completely sent (counter >2)?
  {
    tx_buff_cnt = 0;      // reset counter
    uart_tx_flag = 1;      // set String-Sent Flag
    UCSR0B &= ~(1<<UDRIE0);    // UDRIE Interrupt Flag off
  }
  else
  {
    UDR0 = uart_tx_buffer[tx_buff_cnt];    // put next byte into UDR
    tx_buff_cnt++;              // increase tx buffer counter
  }
}


int main(void)
{
  
  char stringbuffer[64];  // general buffer for Strings
  char data[3] ={0xFF, 0xAA, 0xBB};
  uint8_t buffer_full=0;  // buffer full flag
  char * charpointer;     // pointer
    
  /*********************** Initialization ***********************/
  //Port Directions
                    
  DDRC= 0b01010001;        // SPI Slave select, LEDs                    
  DDRD= 0b00001010;        // UART
  
  UART_Init();          // UART Initialisierung
  
  sei();              // Globale Interrupts enable
  
  
    while(1)
    {
    
    transmit_string(&uart_tx_flag, &uart_tx_buffer, data);
  
    }
}

Die Funktionalität sollte eigentlich einfach sein:
Ich habe einen default 3-Wort-block "data" (1. Byte 0xFF, 2. Byte 0xAA, 
3. Byte 0xBB), der mit einem counter stück für stück gesendet wird - 
unter Verwendung des UDRE (USART Data register empty= Flag-Interrupts. 
Immer wenn ein Byte raus ist wird der Interrupt neu aufgerufen und das 
nächste Byte verschickt, bis der counter >2 ist - dann wird der counter 
auf 0 gesetzt und der UDRIE ausgeschaltet.

Wo habe ich einen fehler gemacht? Es scheint so, als ob die 
ISR(USART0_UDRE_vect)  Routine nicht aufgerufen wird (mal wieder 
LED-Blink-Test)..

[hufnala (Gast)]

Hi,

UART Interrupt freigegeben? Hab das Datenblatt gerade nicht aber TIMSK 
koennte das richtige register sein. Dort steht auch ob der Interrupt 
ueberhaupt beim Senden geht, ich hab ihn bisher nur fuer RX verwendet.

//hufnala

[Jonas B. (jibi)]

>transmit_string(&uart_tx_flag...

Warum dieser Umweg mit der Adresse vom flag? Übergebe doch einfach das 
Byte?! Deine Variante erzeugt sogar noch mehr Code und längere Laufzeit, 
wenngleich das hier nicht wichtig ist.

Ich würde das Rad auch nicht neuerfinden. Saubere Implementationen für 
Ringbuffer findest du in der Softwaresammlung.

Gruß Jonas

[Alex V. (bastel_alex)]

hufnala schrieb:
> UART Interrupt freigegeben?

ja ist freigegeben,
in der  UART_Init(); die nicht im code drin ist oben:

 void UART_Init()
 {
   // baud Calculation: baud = (fosc/ 16*Baudrate)-0.5
   // baud = (20 MHz / 16*9600)-0.5 = 129.708 --> = baud = 130
   unsigned int baud = 130;
   
   //* Set baud rate */
   UBRR0H = (unsigned char)(baud>>8);
   UBRR0L = (unsigned char)baud;
   /* Enable receiver and transmitter, Set Interrupts: RXCIE - RX-Complete, TCVIE - TX-Complete */
   UCSR0B = (1<<RXEN0)|(1<<TXEN0)|(1<<RXCIE0);
   /* Set frame format: 8data, 2stop bit */
   UCSR0C = (1<<USBS0)|(3<<UCSZ00);
   
 }

Jonas Biensack schrieb:
> Warum dieser Umweg mit der Adresse vom flag? Übergebe doch einfach das
> Byte?!

ich bin nicht sicher ob ich dich richtig verstehe aber:
Ich übergebe die adresse vom flag (und nicht das flag) nur, weil die 
methode in einem anderen file steht und die variable dort nicht 
deklariert ist.
Das mit flag und buffer habe ich eigentlich von der idee her (wenn ichs 
denn richtig gemacht habe) von 
http://www.mikrocontroller.net/articles/Interrupt abgeguckt...
Die transmit funktion enabled ja im wesentlichen nur den UDRE-Interrupt, 
damit so lange vom buffer in das UDR0 register geschaufelt wird, bis der 
buffer leer ist.

Ich würde mich aber nicht wundern wenn es klügere implementierungen gibt 
als meine, ich bin da ja anfänger. nur trotzdem sollte der code ja 
laufen, wenn auch nicht zeitoptimal meinetwegen...?

[Karl H. (kbuchegg)]

Alex v. L. schrieb:

> ich bin nicht sicher ob ich dich richtig verstehe aber:
> Ich übergebe die adresse vom flag (und nicht das flag) nur, weil die
> methode in einem anderen file steht und die variable dort nicht
> deklariert ist.

Wen kümmerts?

Die Funktion kriegt ja bei

void foo( int i )
{
  printf( "%d", i );
}

int main()
{
  int j = 7;

  foo( j );
}

ja sowieso nie zu sehen, dass der Aufruf von foo mit j gemacht wurde. 
Der Funktion wird der Wert 7 übergeben, der vom Aufrufer aus j geholt 
wird, an die Funktion übergeben wird, und den die Funktion sich für sich 
selbst in i ablegt.
Die Funktion muss nicht wissen, dass es in main ein j gibt und das von 
dort der Wert für ihren Aufruf herstammt.



> Die transmit funktion enabled ja im wesentlichen nur den UDRE-Interrupt,
> damit so lange vom buffer in das UDR0 register geschaufelt wird, bis der
> buffer leer ist.

Das müsste man jetzt genauer analysieren.
Grundsätzlich ist die Versteifung auf die 3-er Sequenzen schon mal 
etwas, was man anzweifeln kann. Bringt eigentlich nichts. D.h. man würde 
einen Buffer Mechanismus schreiben, der erst mal mit einzelnen Bytes 
umgehen kann. Das du als Aufrufer dann jeweils gleich immer 3 Aufrufe 
machst um Bytes einzustellen, ja das ist dein Bier als Aufrufer. Aber es 
ist nichts, was den Buffermechanismus jetzt groß kümmern müsste.

Es gibt derartige IMplentierungen. Zb ist in der UART Lib vom P.Fleury 
eine ethalten. Vielleicht möchtest du ja die mal studieren wie die 
arbeitet, ehe du dich dann selber daran versuchst?

[Oliver (Gast)]

Wenigstens folgendes ist falsch:
if (&uart_tx_flag==1)
Richtig wäre:
if (*uart_tx_flag==1)

Oliver

[Uwe (Gast)]

Hi,

>ja ist freigegeben,
>in der  UART_Init(); die nicht im code drin ist oben: void UART_Init()
.
.
>   /* Enable receiver and transmitter, Set Interrupts: RXCIE - RX->Complete, 
TCVIE - TX-Complete */
>   UCSR0B = (1<<RXEN0)|(1<<TXEN0)|(1<<RXCIE0);
>   /* Set frame format: 8data, 2stop bit */
>   UCSR0C = (1<<USBS0)|(3<<UCSZ00);

Das sehe ich aber anders, oder kann ich nicht lesen?

RXCIE ist nicht UDRIE
Bit 7 – RXCIEn: RX Complete Interrupt Enable
Bit 5 – UDRIEn: USART Data Register Empty Interrupt Enable

Bit 7      6       5     4     3      2     1     0
  RXCIEn TXCIEn UDRIEn RXENn TXENn UCSZn2 RXB8n TXB8n UCSRnB

viel Erfolg, Uwe

[Alex V. (bastel_alex)]

Herzlichen Dank für alle Rückmeldungen! Mal sehen was damit der heutige 
Tag bringt! ;)

[Karl H. (kbuchegg)]

Alex v. L. schrieb:


Da ist auch noch ein Bock

> void transmit_string(volatile uint8_t *uart_tx_flag, char
> *uart_tx_buffer[], char data[3])
> {
...
>     uart_tx_flag = 0;              // Delete "Sent-Flag"


Ich denke ehrlich gesagt nicht, dass derartige Mechanismen momentan 
schon etwas für dich sind.
Soalnge du derart eklatante Schwächen in grundlegenden C Dingen hast, 
solltest du ehrlich gesagt besser ein C-Buch durcharbeiten und die 
Übungen da drinnen machen (auf dem PC), als dich mit weiterführenden 
Konzepten auf einem AVR beschäftigen. Da klafft ein scheinentorgrosses 
Wissensloch, das erst gestopft werden sollte.


Und ja. Das Argument muss ein Pointer sein. Wenn sich auch deine 
Begründung dafür ein wenig hahnebüchern liest.

[Alex V. (bastel_alex)]

Eine ganz kurze generelle Frage, die mich beim datenblattlesen und coden 
gerade noch einmal stutzig gemacht hat:

Das UDR-Register besteht aus eigentlich zwei 8-Bit registern - einem 
Empfangs- und einem Senderegister - oder nur EINEM 8 Bit register?

Ich lese ja aus UDR wenn ich einen RXC-Interrupt bekomme und schreibe 
wenn mir der UDRE-Interrupt zeigt, dass das register leer ist - aber 
doch wohl nicht beide male auf das selbe register?

Wenn es zwei sind - wieso haben sie dann nur einen namen? - 
unterscheidet der µC durch die Lese/schreibaktion dann auf welches 
zugegriffen wird, dient das ganze also der simplifizierung?
Im Datenblatt des Atmega644 auf s.165 wird im USART-Block Diagramm ja 
UDR(Transmit) und UDR(Receive) unterschieden.

Wenn es ein und das selbe ist: wie wird dann verindert, dass beim senden 
und empfangen gleichzeitig das selbe register beschrieben wird?

[Karl H. (kbuchegg)]

Alex v. L. schrieb:

> Das UDR-Register besteht aus eigentlich zwei 8-Bit registern - einem
> Empfangs- und einem Senderegister - oder nur EINEM 8 Bit register?

Genau

> Ich lese ja aus UDR wenn ich einen RXC-Interrupt bekomme und schreibe
> wenn mir der UDRE-Interrupt zeigt, dass das register leer ist - aber
> doch wohl nicht beide male auf das selbe register?

Nö. Wozu auch.
Aber es ist völlig klar, dass beim Schreiben das eine Register gemeint 
ist und beim Lesen das andere. Also kann man die beiden Register an eine 
gemeinsame Speicheradresse legen und durch die Art des Zugriffs 
(Schreiben oder Lesen) entscheiden, welches von beiden gemeint ist.

>
> Wenn es zwei sind - wieso haben sie dann nur einen namen?

Weil das Adressen einspart und der "Preis" dafür akzeptabel ist. Man 
verliert die Möglichkeit aus dem Sende-UDR auslesen zu können, was 
eigentlich gesendet wird. Das interessiert aber sowieso keinen, denn das 
Programm hat ja den Wert selber reingeschrieben. Der muss aber von 
irgendwoher gekommen sein und daher weiß man auch was man 
reingeschrieben hat ohne im Schreibe-UDR nachsehen zu müssen.
Auf der anderen Seite macht es keinen Sinn, etwas in den Lese-UDR 
einschreiben zu wollen. Aus diesem UDR kommt das raus, was die UART 
empfangen hat. Wozu soll ich da was reinschreiben?

[Jonas B. (jibi)]

>Das mit flag und buffer habe ich eigentlich von der idee her (wenn ichs
>denn richtig gemacht habe) von
>http://www.mikrocontroller.net/articles/Interrupt abgeguckt...
>Die transmit funktion enabled ja im wesentlichen nur den UDRE-Interrupt,
>damit so lange vom buffer in das UDR0 register geschaufelt wird, bis der
>buffer leer ist.

Doch wird dort nirgends ein einzelnes Byte über einen Pointer als 
Parameter übergeben, das macht auf 8-Bit Systemen einfach keinen Sinn 
weil
>Deine Variante erzeugt sogar noch mehr Code und längere Laufzeit,
>wenngleich das hier nicht wichtig ist.

[Alex V. (bastel_alex)]

Danke!

[Jonas B. (jibi)]

Aber hey, jeder Anfang war schwer und da mussten wir alle durch bzw. 
stecken wir noch drin...

Gruß Jonas

[Karl H. (kbuchegg)]

Jonas Biensack schrieb:

> Parameter übergeben, das macht auf 8-Bit Systemen einfach keinen Sinn
> weil
>>Deine Variante erzeugt sogar noch mehr Code und längere Laufzeit,
>>wenngleich das hier nicht wichtig ist.


Es würde dann Sinn machen, wenn man hier

void transmit_string(volatile uint8_t *uart_tx_flag, char *uart_tx_buffer[], char data[3])        
{
  if (&uart_tx_flag==1)              // check whether last string has been sent completely
  {
    for (int i=0; i<3; i++)
    {
      uart_tx_buffer[i] = data[i];      // Copy String into send buffer
    }
    uart_tx_flag = 0;              // Delete "Sent-Flag"

den Kapitalen Fehler beseitigen würde.
Auf der anderen Seite liegt da noch ein Konzeptfehler drüber.
Dieses uart_tx_flag hat im Grunde genommen in main() überhaupt nichts 
verloren, sondern gehört zu den UART Routinen wodurch sich die ganze 
Notwendigkeit es zu übergeben, sofort in Luft auflösen würde.

Hier fehlt es einfach unter anderem an grundlegenden Fertigkeiten bzw. 
Übung und Erfahrung, wie man sich Module baut, speziell wenn die in ein 
eigenes C-File ausgelagert werden. Gepaart mit einigen C-Schwächen ist 
das dann eben eine brisante Mischung.

[greg (Gast)]

Alex v. L. schrieb:
> Nun Habe ich versucht einen Sende-Puffer einzurichten. Das Ziel:
> Es sollen immer 3 Byte in den Puffer geschrieben und nacheinander
> gesendet werden, während die nächsten drei Bytes in Vorbereitung sind.
> Das ganze soll Interrupt-Gesteuert und ohne Polling passieren.

Das hört sich umständlich an. Nimm lieber einen kleinen Ringpuffer/FIFO, 
das ist die Standardlösung, und braucht neben dem Buffer nur zwei 
Indizes für Producer und Consumer.

So ein Puffer ist beim Empfangen aber wichtiger, denn da gibt der Sender 
das Timing vor; wenn der ohne Pause ein Byte nach dem anderen sendet, 
musst du hinterher kommen. Wenn du selbst sendest, ist das Timing 
unkritisch.

[Jonas B. (jibi)]

>Das hört sich umständlich an. Nimm lieber einen kleinen Ringpuffer/FIFO,
>das ist die Standardlösung, und braucht neben dem Buffer nur zwei
>Indizes für Producer und Consumer.

sag ich doch:

>>Ich würde das Rad auch nicht neuerfinden. Saubere Implementationen für
>>Ringbuffer findest du in der Softwaresammlung.

>Auf der anderen Seite liegt da noch ein Konzeptfehler drüber.
>Dieses uart_tx_flag hat im Grunde genommen in main() überhaupt nichts
>verloren, sondern gehört zu den UART Routinen wodurch sich die ganze
>Notwendigkeit es zu übergeben, sofort in Luft auflösen würde.

Eben.

>Hier fehlt es einfach unter anderem an grundlegenden Fertigkeiten bzw.
>Übung und Erfahrung, wie man sich Module baut. Gepaart mit einigen
>C-Schwächen ist das dann eben eine brisante Mischung.

100 % ack

Gruß Jonas

[Jonas B. (jibi)]

Die Ringbuffer-Implementierungen haben schon einige Tricks, die die 
Performance massiv steigern, auf die kommst DU nie. Also wenn man keine 
Ahnung hat lieber mal über den leeren Tellerrand schauen.

Gruß Jonas

[Alex V. (bastel_alex)]

Also ich habe mir eure Kommentare zu Herzen genommen und seit heute 
morgen mal eine Ringpufferlösung programmiert. die funktioniert auch 
grundsätzlich, nur bin ich jetzt am Macken ausbessern - wenn ich nämlich 
den unten eingefügten code zur kontrolle durchlaufen lasse, kommt am 
Terminal die dezimal-zahlenreihe (ACHTUNG, LANG):
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
0
16
17
18
19
20
21
22
23
24
25
26
27
28
29
0
0
32
33
34
35
36
37
38
39
40
41
42
43
44
45
0
0
48
49
50
51
52
53
54
55
56
57
58
59
60
61
0
0
64
65
66
67
68
69
70
71
72
73
74
75
76
77
0
0
80
81
82
83
84
85
86
87
88
89
90
91
92
93
0
0
96
97
98
99

an. Man sieht: Da sind Nullen wo keine hingehören! ;-) Für tips bin ich 
außerordentlich dankbar, auch wie man die hier nun gepostete 
-->bisherige Lösung noch weiter verbessern kann:

/*.............RINGPUFFER.............*/
struct circ_buffer {
  uint8_t data[buffer_size];
  uint8_t read_ptr;      // points to last input data
  uint8_t write_ptr;      // always points to empty field
  uint8_t fillcount; 
  };

void buffer_init (struct circ_buffer *buf)          // Initialization of circular buffer values
{
  buf->fillcount=0;
  buf->read_ptr=buffer_size;
  buf->write_ptr=0;
}

void buffer_write(struct circ_buffer *buf, uint8_t byte)  // Write byte into buffer, increment fillcounter and write pointer
{
  buf->data[buf->write_ptr] = byte;
  buf->fillcount++;
  
  if (buf->write_ptr>= buffer_size)
  buf->write_ptr = 0;  
  else
  buf->write_ptr = buf->write_ptr + 1;
}

uint8_t buffer_read(struct circ_buffer *buf)        // Read byte out of buffer, decrement fillcounter, increment read ptr
{
  if (buf->fillcount>0)
  {
    buf->fillcount--;
    
    buf->read_ptr = buf->read_ptr + 1;
    if (buf->read_ptr >= buffer_size)
    {
      buf->read_ptr = 0;
      return buf->data[buffer_size];
    }
    else
    return buf->data[buf->read_ptr-1];
  }
  else return 0;
}

bool buffer_full (struct circ_buffer *buf)
{
  if (buf->fillcount == buffer_size)
  return true;
  else return false;
}

bool buffer_empty (struct circ_buffer *buf)
{
  if (buf->fillcount == 0)
  return true;
  else return false;
}

*/ ........... UART FUNCTIONS ........... */

 void UART_Init()
 {
   // baud Calculation: baud = (fosc/ 16*Baudrate)-0.5
   // baud = (20 MHz / 16*9600)-0.5 = 129.708 --> = baud = 130
   unsigned int baud = 130;
   
   //* Set baud rate */
   UBRR0H = (unsigned char)(baud>>8);
   UBRR0L = (unsigned char)baud;
   /* Enable receiver and transmitter, Set Interrupts: RXCIE - RX-Complete */
   UCSR0B = (1<<RXEN0)|(1<<TXEN0)|(1<<RXCIE0);
   /* Set frame format: 8data, 2stop bit */
   UCSR0C = (1<<USBS0)|(3<<UCSZ00);
 }
 
void UART_start_transmit (void) 
{
  UCSR0B |= (1<<UDRIE0);              // Enable UDRIE- UART Data Register empty Interrupt - UDRE-ISR is going to put data in UDR
}

void UART_stop_transmit (void) 
{
  UCSR0B &= ~(1<<UDRIE0);              // Disable UDRIE- UART Data Register empty Interrupt - UDRE-ISR is going to put data in UDR
}

/* .................. MAIN ................ */
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdlib.h>
#include "stdbool.h"
#include <string.h>

#include "UART_functions.h"
#include "circbuf.h"
#include <util/delay.h>



// VARIABLES

unsigned char byte_buffer;
bool transmission_flag = false;

struct circ_buffer uart_rx_buffer;            // Receive-Circular-Buffer
struct circ_buffer uart_tx_buffer;            // Send-Circular-Buffer



// UART RX-Complete interrupt: 
// Receiving data + buffering (saving)
ISR(USART0_RX_vect) 
{
  buffer_write(&uart_rx_buffer, UDR0);
}

// UART Data register empty interrupt:
// loading new data into UART sending register
ISR(USART0_UDRE_vect) 
{
  if (buffer_empty(&uart_tx_buffer))          // Is buffer empty?
  {
    UART_stop_transmit();              // If yes: Disable UDRE Interrupt
    transmission_flag = false;
  }
  else
  UDR0 = buffer_read(&uart_tx_buffer);
  
  
}



int main(void)
{
  /* Buffer Initialization */
  buffer_init(&uart_rx_buffer);
  buffer_init(&uart_tx_buffer);
  
  /* Variables */
  uint16_t number =0;
    
  /*********************** Initialization ***********************/
  //Port Directions
  
  DDRA= 0b11011011;        // NIRS-Module 1-3 Communication                  
  DDRB= 0b10100110;        // NIRS-Module 3-4 Communication, SPI                    
  DDRC= 0b01010001;        // SPI Slave select, LEDs                    
  DDRD= 0b00001010;        // UART
  
  UART_Init();          // UART Initialisierung
  
  sei();              // Globale Interrupts enable
  
    while(1)
    {
    
    if (number < 100)
    {
      buffer_write(&uart_tx_buffer, number);
      number++;
      _delay_ms(100);
    }
    
    UART_start_transmit();
    
    }
}

Das sieht finde ich schon einigermaßen viel übersichtlicher aus.
In der testschleife nutze ich nur den TX-Buffer und lese keine bytes. 
Grundsätzlich ist es aber so gedacht, dass Interrupt-Gesteuert UDR 
gelesen und beschrieben wird (aus und in die zwei Ringpuffer) und in der 
main diese puffer bearbeitet. Sinnvoll?

[Alex V. (bastel_alex)]

Jonas Biensack schrieb:
> Also wenn man keine
> Ahnung hat lieber mal über den leeren Tellerrand schauen.

Ich bin nicht sicher, was du mir damit sagen willst - ganz so leer ist 
der teller gar nicht - nur die Seite vom Gemüse (C-Programmierung) ist 
bisher eben beschränkt und muss noch gefüllt werden. Zum Füllen aber bin 
ich ja HIER! ;)

[RomanK (Gast)]

Hallo Alex,

dann such doch mal auf der Seite von Atmel nach dem Dokument 1307. Da 
steht alles notwendige drin.

Gruss

Roman

[Alex V. (bastel_alex)]

Karl Heinz schrieb:
> Ich denke ehrlich gesagt nicht, dass derartige Mechanismen momentan
> schon etwas für dich sind.
> Soalnge du derart eklatante Schwächen in grundlegenden C Dingen hast,
> solltest du ehrlich gesagt besser ein C-Buch durcharbeiten und die
> Übungen da drinnen machen (auf dem PC), als dich mit weiterführenden
> Konzepten auf einem AVR beschäftigen.

Dem würde ich an der Stelle mal klar widersprechen und zwar:
Ich habe schon C/C++ Bücher durchgearbeitet, nur ist das schon ganz 
schön her. Die µC Programmierung ist für mich bisher immer Mittel zum 
Zweck gewesen - und auch hier wieder. Ich muss mich dann allerdings 
jedes mal wieder neu reinfummeln - und mache auch immer erstmal wieder 
ähnliche Fehler bis ich mich wieder eingearbeitet habe.
Das UART-Kommunikationsmodul brauche ich eigentlich nur um eine ganz 
andere Hardware zu unterstützen, damit ich die damit gemessenen Signale 
auf den PC bekomme.
Ich finde es eigentlich eher spannend mir verschiedene grundlagen durch 
größere Projekte anzueignen, auch wenn der weg umso steiniger ist (durch 
mehr flüchtigkeits und dummheitsfehler), sonst fehlt mir die Motivation.
Gerade bin ich sehr motiviert! ;-)

[greg (Gast)]

Alex v. L. schrieb:
> void buffer_init (struct circ_buffer *buf)          // Initialization of
> circular buffer values
> {
>   buf->fillcount=0;
>   buf->read_ptr=buffer_size;
>   buf->write_ptr=0;
> }

read_ptr und write_ptr sollten beide mit 0 initialisiert werden, sonst 
haut das nicht hin. fillcount ist unnötig.

Alex v. L. schrieb:
> if (buf->write_ptr>= buffer_size)
>   buf->write_ptr = 0;
>   else
>   buf->write_ptr = buf->write_ptr + 1;

buf->write_ptr = (buf->write_ptr + 1) % buffer_size;

ist kürzer und klarer.

Keine Ahnung was da konkret nicht klappt, hab nur mal kurz 
drübergeschaut und das ist mir aufgefallen.

[Alex V. (bastel_alex)]

greg schrieb:
> read_ptr und write_ptr sollten beide mit 0 initialisiert werden, sonst
> haut das nicht hin.

ok, gemacht. kommt allerdings das selbe raus am terminal wie vorher

greg schrieb:
> fillcount ist unnötig.

Ja ich weiß, auf der mikrocontroller.net-FiFo Seite ists auch ohne 
gemacht. Ich habs drin weil mein Kleingeist das besser versteht ;-)

Danke für deine Anmerkungen!

[greg (Gast)]

Eine Sache noch: immer erst die Daten lesen/schreiben, und danach erst 
read_ptr/write_ptr/fillcount aktualisieren. Sonst hast du eine race 
condition! Wenn der Interrupt in einem ungünstigen Augenblick feuert, 
dann hat dein Ringbuffer sonst einen inkonsistenten Zustand. Das ist 
insgesamt recht tricky.

Einfachere Lösung: Interrupts kurzzeitig deaktivieren.

[Jonas B. (jibi)]

>Eine Sache noch: immer erst die Daten lesen/schreiben, und danach erst
>read_ptr/write_ptr/fillcount aktualisieren. Sonst hast du eine race
>condition! Wenn der Interrupt in einem ungünstigen Augenblick feuert,
>dann hat dein Ringbuffer sonst einen inkonsistenten Zustand. Das ist
>insgesamt recht tricky.

>Einfachere Lösung: Interrupts kurzzeitig deaktivieren.

Um wieder nur einen Teil der ganzen Wahrheit preiszugeben.

Also wenn es wirklich nur darum geht, den Algorithmus der 
Implemtierungen zu verstehen, verstehe ich deine Mühe. Aber ganz ehrlich 
das ist doch unwichtig.
Ich meine, ein Ringbuffer ist doch meist ein nur kleiner Teil einer viel 
größeren Anwendung. Oder in welchem Rahmen findet das alles statt?

Viele Grüße

P.S. Unterschätzt nicht dein Wissen! :D

[Karl H. (kbuchegg)]

Alex v. L. schrieb:

> Dem würde ich an der Stelle mal klar widersprechen und zwar:
> Ich habe schon C/C++ Bücher durchgearbeitet, nur ist das schon ganz
> schön her.

red nicht um den heissen Brei rum.
Wer bei Argumentübergabe an Funktion bzw. deren Weiterverwendung in der 
Funktion Schwächen hat, hat ganz einfach ein Basis-Problem.
Da diskutiere ich nicht drüber.

[Jonas B. (jibi)]

>red nicht um den heissen Brei rum.
>Wer bei Argumentübergabe an Funktion bzw. deren Weiterverwendung in der
>Funktion Schwächen hat, hat ganz einfach ein Basis-Problem.
>Da diskutiere ich nicht drüber.

Jetzt wird'r böss.

Auch noch'm Karl-Heinz sein Middag versauen und kein C-können. Oh oh, 
ich seh schwarz :D

Nur Spass, schönes Wochenende euch!

AFK Jonas

[Alex V. (bastel_alex)]

greg schrieb:
> Eine Sache noch: immer erst die Daten lesen/schreiben, und danach erst
> read_ptr/write_ptr/fillcount aktualisieren. Sonst hast du eine race
> condition! Wenn der Interrupt in einem ungünstigen Augenblick feuert,
> dann hat dein Ringbuffer sonst einen inkonsistenten Zustand. Das ist
> insgesamt recht tricky.

Danke, umgesetzt.

Jonas Biensack schrieb:
> Oder in welchem Rahmen findet das alles statt?

Der Rahmen: Ein eigenes kleines ADC Board. Darauf: Ein Atmega644, ein 
LTC2468 16 Bit ADC und ein AMB2300 Bluetoothmodul.

Ziel: (beliebige) Analogdaten samplen und an den PC per bluetooth 
senden.

Board steht, software eben noch nicht. da gibts drei schritte
1. UART einarbeiten (grade dran)
2. SPI einarbeiten (ADC, folgt)
3. ADC-Werte über UART-Schnittstelle ans Bluetoothmodul.

Karl Heinz schrieb:
> Da diskutiere ich nicht drüber.

In ordnung. Ich werde mir meine Basisprobleme trotzdem an größeren 
zielen austreiben! Bislang hat das ganz gut funktioniert.. 
Frust-Tolerant bin ich ;-)
P.S. Die Fehler habe ich durchaus noch entdeckt.

[Jonas B. (jibi)]

>Der Rahmen: Ein eigenes kleines ADC Board. Darauf: Ein Atmega644, ein
>LTC2468 16 Bit ADC und ein AMB2300 Bluetoothmodul.

Mit Rahmen meinte ich eher deinen "persönlichen Rahmen", Vorkenntnisse 
und Ausbildung etc. Sonst hätte ich vermutlich eher Board oder 
Evaluationsboard oder so geschrieben.

Wie sieht's damit aus?

[Alex V. (bastel_alex)]

Uni Elektroingenieur in den letzten studienzügen. Schwerpunkt allerdings 
biomedizintechnik.

[Jonas B. (jibi)]

Also für die Uni, oder für dich, dein Kumpel, oder Karl-Heinz ;)?

Man "Etwas jemandem aus der Nase ziehen" ist bei dir schon fast 
übertrieben. :D

Gruß Jonas

[Jonas B. (jibi)]

Sag doch einfach du bist fast "Elektroingenieur" und kannst keinen MC 
dazubringen ein Signal in einen Buffer zu schreiben?
Das übliche halt.

[Alex V. (bastel_alex)]

Sorry ich scheine nur deine Fragen nie richtig zu deuten! :D
Eine Mischung. Das Gesamtprojekt nennt sich Masterarbeit, das was ich 
grade mache ist aber im Prinzip ein eigenes oben drauf (was mir auch 
evaluieren helfen soll) ;-)
Fehlt noch was?

[Alex V. (bastel_alex)]

Jonas Biensack schrieb:
> Sag doch einfach du bist fast "Elektroingenieur" und kannst keinen MC
> dazubringen ein Signal in einen Buffer zu schreiben?

war das jetzt ironie? ;)

[Jonas B. (jibi)]

Sagen wir so mit Augenzwinkern. Du musst, wenn du ein guter Ingenieur 
werden willst, verstehen, dass nur Erfahrung hilft so cool zu bleiben 
das man alle Probleme überblicken kann. Im Umkehrschluss verfängst du 
dich ohne Erfahrung in allen möglichen nur erdenklichen Problemen. Oder 
um es mal anders zu formulieren, ein fleißiger Bastler bringt das Ding 
an einem Tag zum laufen, ohne jemals eine Uni betretten zu haben. Um 
also das massive Fachwissen was die Uni mit sich bringt zu nutzen, musst 
du tun. Du braucht Interesse, das ist viel wichtiger, such dir eigene 
Projekte. Nur dass Zeug für die Uni reicht nicht, das willst du auch gar 
nicht. geb gas man.

Gruß Jonas

[Alex V. (bastel_alex)]

Jonas Biensack schrieb:
> Nur dass Zeug für die Uni reicht nicht, das willst du auch gar
> nicht. geb gas man.

Haha danke, ganz meine Einstellung. Womit wir wieder bei dem Grund 
meiner Anwesenheit und dem Forenbeitrag sind :D

[Jonas B. (jibi)]

>Haha danke, ganz meine Einstellung. Womit wir wieder bei dem Grund
>meiner Anwesenheit und dem Forenbeitrag sind :D

Ok digga. Dann ziehen wir das jetzt durch. Ich helf dir.

Anforderung nochmal genau, bitte jetzt mit den neuen Erkenntnissen:

-Samplen...
-Ringbuffer...
...

Gruß jonas

[Jonas B. (jibi)]

>Es sollen immer 3 Byte in den Puffer geschrieben und nacheinander
>gesendet werden, während die nächsten drei Bytes in Vorbereitung sind.
>Das ganze soll Interrupt-Gesteuert und ohne Polling passieren.

DAs ganze macht nur Sinn wenn die berechnung der 3 bytes fast unendlich 
dauert, was wird da berechnet der Bauchumfang von cyblords ma?

gruß Jonas

[Alex V. (bastel_alex)]

;)

Also der µC wird zum schluss

- einzelne (wenige ~16) Konfigurationsbytes vom PC verarbeiten müssen, 
der empfangspuffer ist also unkritisch. Das wird eine einfache 
Switch-Case geschichte, die z.B. den Kanal des ADC wählt. unkritisch.

- Mit vorgegebenem Takt (über Timer, kenne ich auch - unkritisch) den 
ADC wert eines kanals des LTC2468 abrufen über SPI (kenne ich noch nicht 
- wird kritisch ;-) und direkt in den Sendepuffer des UART kanals 
packen. Der ADC hat 16 bit werte, davor soll ein Byte konfigdaten (kanal 
etc). Also: Pro Messung drei Bytes.

Tatsächlich ist die UART geschichte für mich soweit vollständig geklärt 
und umgesetzt, sobald der Puffer einwandfrei funktioniert. Und der 
knarzt gerade nur noch an einer Stelle, die mit den write/read pointern 
zu tun haben muss. Wenn du mir ein schafes auge für den Debug leihen 
willst freue ich mich natürlich sehr. Der aktuelle Code auf dem PC 
(kommt unten nochmal) inkrementiert eine zahl und steckt sie in den 
puffer, damit ich sehe ob alles richtig klappt. Tut es noch nicht - und 
zwar immer bei den Sprüngen auf den Anfang des Puffers zurück - dann 
kommt eine Null. Mit einer Ausnahme: Dem ersten Durchlauf, der klappt.

Konkreter auszug:
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
0
18
19
20
21
22
23
24
25
0
27
28
29
30
31
32
33
34
0
...

Der Puffer ist jetzt unter Berücksichtigung der meisten Rückmeldungen so 
aufgebaut:

struct circ_buffer {
  uint8_t data[buffer_size];
  uint8_t read_ptr;      // points to last input data
  uint8_t write_ptr;      // always points to empty field
  uint8_t fillcount; 
  };

#include "circbuf.h"

void buffer_init (struct circ_buffer *buf)          // Initialization of circular buffer values
{
  buf->fillcount=0;
  buf->read_ptr=0;
  buf->write_ptr=0;
}

void buffer_write(struct circ_buffer *buf, uint8_t byte)  // Write byte into buffer, increment fillcounter and write pointer
{
  buf->data[buf->write_ptr] = byte;
  
  buf->fillcount++;
  if (buf->write_ptr >= buffer_size)
  buf->write_ptr = 0;
  else
  buf->write_ptr = buf->write_ptr + 1;
}

uint8_t buffer_read(struct circ_buffer *buf)        // Read byte out of buffer, decrement fillcounter, increment read ptr
{
  uint8_t returnval =0;
  
  if (buf->fillcount>0)
  {
    returnval= buf->data[buf->read_ptr];
    
    if (buf->read_ptr >= buffer_size)
    {
      buf->read_ptr = 0;
    }
    else 
    buf->read_ptr = buf->read_ptr + 1;
  
    buf->fillcount--;
    return returnval;
  }
  else return 0;
}

bool buffer_full (struct circ_buffer *buf)
{
  if (buf->fillcount == buffer_size)
  return true;
  else return false;
}

bool buffer_empty (struct circ_buffer *buf)
{
  if (buf->fillcount == 0)
  return true;
  else return false;
}

wie gesagt - und wie ganz oben im codebeispiel: In der main passiert im 
wesentlichen

    if (number < 100)
    {
      buffer_write(&uart_tx_buffer, number);
      number++;
      _delay_ms(100);
    }

Wenn das läuft bin ich schon ziemlich glücklich, der rest ist 
fleißarbeit.
Offen ist nur noch die Anmerkung von greg mit den race-conditions:
Ich habe jetzt lesen/schreiben immer vor den 
dekrementierungen/inkrementierungen gemacht aber

greg schrieb:
> Einfachere Lösung: Interrupts kurzzeitig deaktivieren.

die interrupts noch laufen...

[Alex V. (bastel_alex)]

Ah kurze Anmerkung zu oben noch:
Im zahlenbeispiel ist die Buffersize 8.

[Jonas B. (jibi)]

greg schrieb:
> Einfachere Lösung: Interrupts kurzzeitig deaktivieren.

die interrupts noch laufen...

Um erst mal den Ball wieder zurück zu spielen, du weisst wie man 
Interrupts global aktiviert und deaktiviert?
Davon sehe ich gerade nichts?

Oder hast du den Hazard gelöst?

Gruß Jonas

[Alex V. (bastel_alex)]

ja weiß ich, ist aber ja noch nicht umgesetzt.
ich kann gerne mal ein sei() und cli() einbauen aber ich dachte erstmal 
nicht dass das am ringpufferverhalten in diesem fall was ändert - aber 
vll ist das ja tatsächlich eine periodische race condition?.. mal 
probieren

[Jonas B. (jibi)]

>ich kann gerne mal ein sei() und cli() einbauen aber ich dachte erstmal
>nicht dass das am ringpufferverhalten in diesem fall was ändert - aber
>vll ist das ja tatsächlich eine periodische race condition?.. mal
>probieren

Das sind keine Endzeit-Phänomäne, sondern sowas bringt Raketen zum 
Absturz. Da kann Morphy noch weiter schlafen und da hast Ärger damit.
Siehst du doch gerade :) So geil...

Gruß Jonas

[Alex V. (bastel_alex)]

ja, wars leider nicht.
habe am anfang der buffer_read und _write funktionen global 
ausgeschaltet und am ende wieder ein. Das so zu lassen ist aber wegen 
den race-c empfehlenswert?

und nein - hazard ist damit noch nicht gelöst. ;)

[Jonas B. (jibi)]

Alex sorry, bin erstmal afk from keyboard. Mein wauwau muss raus. BIn 
heute abend wieder one, dann helf ich dir weiter gerne - aber du bist ja 
der .Ing. :D

Gruß Jonas

[Alex V. (bastel_alex)]

;) Danke soweit und ich schreib hier rein wenn ichs gelöst habe - sonst 
bist du herzlich eingeladen heute abend noch beizusteuern!!
LG

[Jonas B. (jibi)]

So, Hund schon an der Leine...

Gerne - viel Erfolg!
P.S. Softwareentwicklung ist nicht wie Schule - Abschauen ist 
ausdrücklich erlaubt!


Gruß Jonas

[Alex V. (bastel_alex)]

Habs gelöst. UNNGH.

.. >= buffer_size -1!!

[jibi (Gast)]

Freut mich dann schönes Wochenende! Wetter ist doch Hammer

gruß Jonas

[Alex V. (bastel_alex)]

Dir auch! :)