BCD auf C: was mache ich falsch?

[Maxim B. (max182)]

Guten Tag,
ich bitte um Hilfe:
um besser C zu verstehen, habe ich eine Testschaltung gemacht: ATmega88 
kommuniziert mit MAX7219. Problem ist folgendes:
wenn die Ziffer 3 von 0 bis 7 ist, ist alles OK. Wenn aber 8 oder 9, 
bekomme ich in Ziffer 4-7 statt zu erwartenden Ziffer nur "FFFF".
Hier ist C-Text von BCD-Funktion (ich denke, das Problem liegt hier):

unsigned long preobras_bin10bcd3(unsigned long a) 
 {
  unsigned char ziff1 = 0;
  unsigned char ziff2 = 0;
  unsigned char ziff3 = 0;
  unsigned char ziff4 = 0;
  unsigned char ziff5 = 0;
  unsigned char ziff6 = 0;
  unsigned char ziff7 = 0;
  unsigned char ziff8 = 0;
  unsigned long c = 0;
  unsigned long b = 0;

  while(a>=10000000)
    {
      ziff1++;
      a-=10000000;
    }
  while(a>=1000000)
    {
      ziff2++;
      a-=1000000;
    }
  while(a>=100000)
    {
      ziff3++;
      a-=100000;
    }
  while(a>=10000)
    {
      ziff4++;
      a-=10000;
    }
  while(a>=1000)
    {
      ziff5++;
      a-=1000;
    }
  while(a>=100)
    {
      ziff6++;
      a-=100;
    }
  while(a>=10)
    {
      ziff7++;
      a-=10;
    }
  ziff8 = (a & 0x0000000f);
  ziff7 = (ziff7 & 0x0f);
  ziff6 = (ziff6 & 0x0f);
  ziff5 = (ziff5 & 0x0f);
  ziff4 = (ziff4 & 0x0f);
  ziff3 = (ziff3 & 0x0f);
  ziff2 = (ziff2 & 0x0f);
  ziff1 = (ziff1 & 0x0f);


  b = (ziff5<<12)|(ziff6<<8)|(ziff7<<4)|(ziff8);
  c = (ziff1<<12)|(ziff2<<8)|(ziff3<<4)|(ziff4);
  b |= (c<<16);

  return b;
}

Zuerst habe ich am Ende statt

  b = (ziff5<<12)|(ziff6<<8)|(ziff7<<4)|(ziff8);
  c = (ziff1<<12)|(ziff2<<8)|(ziff3<<4)|(ziff4);
  b |= (c<<16);

so geschrieben:

 b = (ziff1<<28)|(ziff2<<24)|(ziff3<<20)|(ziff4<<16)|(ziff5<<12)|(ziff6<<8)|(ziff7<<4)|(ziff8);

Aber Compiler sagte, ich bin aus dem zulässigen Bereich.
Ich habe vieles ausprobiert, kapiere aber noch nicht...

Diese Variante gibt allerdings richtige Ergebnis:

unsigned long preobras_bin10bcd3(unsigned long a) 
 {
  unsigned long b = 0;
  while(a>=10000000)
    {
      b = b + 0x10000000;
      a-=10000000;
    }
  while(a>=1000000)
    {
      b = b + 0x01000000;
      a-=1000000;
    }
  while(a>=100000)
    {
      b = b + 0x00100000;
      a-=100000;
    }
  while(a>=10000)
    {
      b = b + 0x00010000;
      a-=10000;
    }
  while(a>=1000)
    {
      b = b + 0x00001000;
      a-=1000;
    }
  while(a>=100)
    {
      b = b + 0x00000100;
      a-=100;
    }
  while(a>=10)
    {
      b = b + 0x00000010;
      a-=10;
    }
  while(a>=1)
    {
      b = b + 0x00000001;
      a-=1;
    }
  return b;
}

Wo liegt das Problem?
Vielen Dank im voraus!

[Peter D. (peda)]

Wozu soll das ganze Rumgeschiebe gut sein?
Du hast 8 Ziffern und der MAX7219 braucht 8 Ziffern.
Mit packed BCD kann der nix anfangen.

[Stefan E. (sternst)]

Maxim B. schrieb:
> wenn die Ziffer 3 von 0 bis 7 ist, ist alles OK. Wenn aber 8 oder 9,
> bekomme ich in Ziffer 4-7 statt zu erwartenden Ziffer nur "FFFF".

Glaube ich dir nicht so recht. Das Problem sollte bei Ziffer 5 (wenn 8 
oder 9) auftauchen, nicht bei Ziffer 3.

Grund:

  b = (ziff5<<12)|(ziff6<<8)|(ziff7<<4)|(ziff8);

hier wird die rechte Seite in signed int gerechnet und dementsprechend 
findet eine Sign-Extension statt beim Zuweisen an b.

[Falk B. (falk)]

@ Maxim Burtsev (Firma: BBO-Potsdam) (max182)

>Hier ist C-Text von BCD-Funktion (ich denke, das Problem liegt hier):

Das Problem liegt vor deiner Tastatur. 8-0

Schon mal was von Schleifen und Arrays gehört?

Mach lieber erstmal einen Test mit konstanten Daten, um zu prüfen ob 
deine SPI-Ansteuerung OK ist. DANN kannst du dein bin2bcd Routine 
testen.

[Falk B. (falk)]

@ Stefan Ernst (sternst)

>  b = (ziff5<<12)|(ziff6<<8)|(ziff7<<4)|(ziff8);

>hier wird die rechte Seite in signed int gerechnet

INT ist aber nicht long! Zumindest nicht auf deinem Compiler (avr gcc?)

>und dementsprechend findet eine Sign-Extension statt beim Zuweisen an b.

Nö. Eher so.

>  b = ((long)ziff5<<12)|((long)ziff6<<8)|((long)ziff7<<4)|((long)ziff8);

[Stefan E. (sternst)]

Falk B. schrieb:
> INT ist aber nicht long! Zumindest nicht auf deinem Compiler (avr gcc?)
>
>>und dementsprechend findet eine Sign-Extension statt beim Zuweisen an b.
>
> Nö. Eher so.
>
>>  b = ((long)ziff5<<12)|((long)ziff6<<8)|((long)ziff7<<4)|((long)ziff8);

Wie kommst du darauf, dass die rechte Seite in long gerechnet würde?
Bei seinem Code wird sie in int gerechnet.

[Falk B. (falk)]

Man beachte Table 4, Decode Mode Register.

[Maxim B. (max182)]

Danke an alle!
Mit SPI und mit MAX7219 gibt es kein Problem, das habe ich mit anderen 
Tests festgestellt.
Auf die in MAX7219 eingebaute Möglichkeit, 7-segm- Decoder zu nutzen, 
verzichte ich aus zwei Gründen: dort sind die Zeichen ab 10 bis 15 
anders, keine "abcdef". Und ich wollte auch die Funktion fürs 7-segm. 
testen.

Untere Programmbeispiel arbeitet korrekt, mir geht es hier vor allem um 
die Erklärung, warum die Zeilen wie

b = (ziff1<<28)|(ziff2<<24)|(ziff3<<20)|(ziff4<<16)|(ziff5<<12)|(ziff6<<8)|(ziff7<<4)|(ziff8);

 und

b = (ziff5<<12)|(ziff6<<8)|(ziff7<<4)|(ziff8);
  c = (ziff1<<12)|(ziff2<<8)|(ziff3<<4)|(ziff4);
  b |= (c<<16);

  falsche Ergebnis bringen (d.h. nicht was ich erwartete). Ich brauche 
das zu klären, um ähnliche Probleme in anderen Programmen zu vermeiden.

Ich habe mit unsigned und mit signed ausprobiert, das war immer 
gleiches; wenn in Ziffer 3 (Ziffer 0 auf MAX7219 ist die kleinste) 8 
oder 9, dann vier höhere Ziffer zeigen "FFFF".

Vielen Dank!

P.S. Schleifen kenne ich. Aber daß das Pflicht ist, Schleifen zu 
verwenden - das habe ich bisher nicht gewußt. Ich glaube, Compiler ist 
selbst genug klug, um alles passend zu optimieren. Oder? Wenigstens, wie 
ich versucht habe, eine Aufgabe mit Assembler und dann mit C zu machen - 
kam überraschend vor, daß C-Variante schneller und mit weniger Hex-Code 
war, als Assemblers :) Das hat mich für C noch mal überzeugt.

Übrigens, volle Code von Test-Programm: ich werde für Kritik sehr 
dankbar.

#define F_CPU 1000000UL
#include <avr/io.h>      
#include <util/delay.h>    
#include <avr/interrupt.h>   
#include <stdint.h> 

#define KALFREQ 0xa5 
/* 
0xab
120c  8 MHz 3,3V: 1:57,16 5V: 1:56,17 = +0,497 %/V
1 MHz 5V  1:56,14
0xa5 598,85/600 +0,192%
0xa4 603,23/600  -0,538%
*/

volatile unsigned char FLAG_TIK = 0; 
#define KSCH1 ((F_CPU/64)-1)  



#define setSS (PORTB |= (1<<PB2))
#define resSS (PORTB &= ~(1<<PB2))
#define spi_einschalten  SPSR = 1<<SPI2X; SPCR = (1<<SPE)|(1<<MSTR); 

#define spi_ausschalten SPCR &= ~(1<<SPE); 

ISR(TIMER1_COMPA_vect) 
{
  
  FLAG_TIK = 1;    
}





unsigned char semisegment(unsigned char e) 
{
  switch(e) {  case 0: e=0x7e; break;
        case 1: e=0x30; break;
        case 2: e=0x6d; break;
        case 3: e=0x79; break;
        case 4: e=0x33; break;
        case 5: e=0x5b; break;
        case 6: e=0x5f; break;
        case 7: e=0x70; break;
        case 8: e=0x7f; break;
        case 9: e=0x7b; break;
        case 10: e=0x77; break;
        case 11: e=0x1f; break;
        case 12: e=0x4e; break;
        case 13: e=0x3d; break;
        case 14: e=0x4f; break;
        case 15: e=0x47; break;
        default: e=0; break;
      } 
      return e; 
}

void outword(unsigned char a,unsigned char b) 
  {
  resSS;
  /* Start transmission */
    SPDR = a;
    /* Wait for transmission complete */
    while(!(SPSR & (1<<SPIF)));
    SPDR = b;
    /* Wait for transmission complete */
    while(!(SPSR & (1<<SPIF)));
  setSS;
  }

unsigned long preobras_bin10bcd3(unsigned long a) 
 {
  unsigned long b = 0;
  while(a>=10000000)
    {
      b = b + 0x10000000;
      a-=10000000;
    }
  while(a>=1000000)
    {
      b = b + 0x01000000;
      a-=1000000;
    }
  while(a>=100000)
    {
      b = b + 0x00100000;
      a-=100000;
    }
  while(a>=10000)
    {
      b = b + 0x00010000;
      a-=10000;
    }
  while(a>=1000)
    {
      b = b + 0x00001000;
      a-=1000;
    }
  while(a>=100)
    {
      b = b + 0x00000100;
      a-=100;
    }
  while(a>=10)
    {
      b = b + 0x00000010;
      a-=10;
    }
  while(a>=1)
    {
      b = b + 0x00000001;
      a-=1;
    }
  return b;
} 



void display(unsigned long a, char adrs)
{
unsigned long b;
b=preobras_bin10bcd3(a);
unsigned char c;
c=b&0x0000000f;
c=semisegment(c);
spi_einschalten;
outword(adrs,c);
b=(b>>4);
c=b&0x0000000f;
c=semisegment(c);
outword((adrs+1),c);
b=(b>>4);
c=b&0x0000000f;
c=semisegment(c);
outword((adrs+2),c);
b=(b>>4);
c=b&0x0000000f;
c=semisegment(c);
outword((adrs+3),c);
b=(b>>4);
c=b&0x0000000f;
c=semisegment(c);
outword((adrs+4),c);
b=(b>>4);
c=b&0x0000000f;
c=semisegment(c);
outword((adrs+5),c);
b=(b>>4);
c=b&0x0000000f;
c=semisegment(c);
outword((adrs+6),c);
b=(b>>4);
c=b&0x0000000f;
c=semisegment(c);
outword((adrs+7),c);
spi_ausschalten;
}

void max7219init(void) 
{
  spi_einschalten;
     unsigned char i;
    for (i=1;i<10;i++) 
      {
        outword(i,0); 
      }

   outword(0x0a,0x0f); 
   outword(0x0b,0x07); 
   outword(0x0c,0x01); 
   outword(0x0f,0x01); 
  _delay_ms(1000);    
   outword(0x0f,0); 
   spi_ausschalten;
   }
/**********************************************************/

int main(void)
{
OSCCAL=KALFREQ;

PORTB = 0;
DDRB = 0xff;
PORTC = 0;
DDRC = 0x0f;
PORTD = 0;
DDRD = 0xff;
setSS; 
ACSR = (1<<ACD);


max7219init(); 


TCNT1=0;  
OCR1A=KSCH1; 
TCCR1C = 0;

TCCR1A = (1<<COM1A0);
TIMSK1 = (1<<OCIE1A);

// TCCR1B = (1<<WGM12)|(1<<CS12);
TCCR1B = (1<<WGM12)|(1<<CS11)|(1<<CS10);

sei();        

  long a=0; 
  display(a,1);


while(1)
{
  PORTB |= (1<<PB0);
  _delay_ms(5);
  PORTB &= ~(1<<PB0);
  while(!(FLAG_TIK));
  FLAG_TIK = 0;
  a++;
  display(a,1);
  if(a==100000000)
    {
    a=0;
    display(a,1);
    }  
}
return 0;

}

[Falk B. (falk)]

@ Maxim Burtsev (Firma: BBO-Potsdam) (max182)

>anders, keine "abcdef". Und ich wollte auch die Funktion fürs 7-segm.
>testen.

>Untere Programmbeispiel arbeitet korrekt, mir geht es hier vor allem um
>die Erklärung, warum die Zeilen wie

>b = (ziff1<<28)|(ziff2<<24)|(ziff3<<20)|(ziff4<<16)|(ziff5<<12)|
>(ziff6<<8)|(ziff7<<4)|(ziff8);

eben WEIL hier die Cast auf long fehlen!

Deshalt HIER so!

b = ((long)ziff1<<28)|((long)ziff2<<24)|((long)ziff3<<20)|((long)ziff4<<16)|((long)ziff5<<12)|
>((long)ziff6<<8)|((long)ziff7<<4)|((long)ziff8);

>  falsche Ergebnis bringen (d.h. nicht was ich erwartete). Ich brauche
>das zu klären, um ähnliche Probleme in anderen Programmen zu vermeiden.

Du musst ganz andere Dinge klären, u.a. ein paar Programmiergrundlagen.

>P.S. Schleifen kenne ich. Aber daß das Pflicht ist, Schleifen zu
>verwenden - das habe ich bisher nicht gewußt.

Mensch bist du cooool!

> Ich glaube, Compiler ist
>selbst genug klug, um alles passend zu optimieren. Oder?

Wirst du nach Programmzeilen bezahlt?

unsigned long preobras_bin10bcd3(unsigned long a) {
  long b=0;
  int i;

  for(i=0; i<8, i++) {
    b >>=4;
    b |= (a % 10)<<28;
    a /= 10;
  }
  
  return b;
}

>Wenigstens, wie
>ich versucht habe, eine Aufgabe mit Assembler und dann mit C zu machen -
>kam überraschend vor, daß C-Variante schneller und mit weniger Hex-Code
>war, als Assemblers :) Das hat mich für C noch mal überzeugt.

Wenn das unser Moby hört!

[Maxim B. (max182)]

Falk B. schrieb:

> eben WEIL hier die Cast auf long fehlen!
Danke für die Erklärung!
> Deshalt HIER so!

> Du musst ganz andere Dinge klären, u.a. ein paar Programmiergrundlagen.
Ich weiß das. Mit der Zeit erlerne ich auch das.
Viele Grüße!

[Maxim B. (max182)]

Falk B. schrieb:

>

> unsigned long preobras_bin10bcd3(unsigned long a) {
>   long b=0;
>   int i;
> 
>   for(i=0; i<8, i++) {
>     b >>=4;
>     b |= (a % 10)<<28;
>     a /= 10;
>   }
> 
>   return b;
> }
>

8 mal % und 8 mal Dividieren... Eigentlich wollte ich gerade Dividieren 
ohne akute Notwendigkeit vermeiden: zu langsam.

[Falk B. (falk)]

@ Maxim Burtsev (Firma: BBO-Potsdam) (max182)

>8 mal % und 8 mal Dividieren...

Darauf ist der Code nicht optimiert, sondern auf minimale Schreibarbeit.

>Eigentlich wollte ich gerade Dividieren
>ohne akute Notwendigkeit vermeiden: zu langsam.

Ach so? Wieviele Millionen Umwandlungen dieser Art willst du denn 
machen, daß die Geschwindigkeit sooo wichtig ist?

https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung

Und wie schnell ist dein Code bei der Umwandlung der Zahl 99999999?

[Maxim B. (max182)]

Falk B. schrieb:

> Ach so? Wieviele Millionen Umwandlungen dieser Art willst du denn
> machen, daß die Geschwindigkeit sooo wichtig ist?
>
In Test wohl nicht wichtig. Wenn aber Text woanders stehen wird, dann 
wird schon wichtig.

Wenn ich schon etwas lerne, dann praxisorientiert. Für die Zukunft.

Schleifen sind natürlich eine schöne Sache.
Allerdings habe ich noch Problem damit.

Z.B. es gibt Massiv von Zähler. Mit jedem Zähler ist LED verbunden, wenn 
Zähler bis 0 zählt, dann wird LED abgeschaltet. Es ist mir bisher nicht 
gelungen, Befragung und Verändern von Zähler und Löschen von LED mit 
einer Schleife zu machen.

Meine Lösung ist leider nur so:

void ledgasch(void)    
{
  if (tai_V[0] > 0)  
    {
      tai_V[0]--;
      if (tai_V[0]==0)
        {
        resVL0;
        }
    }
  if (tai_V[1] > 0)
    {
      tai_V[1]--;
      if (tai_V[1]==0)
        {
        resVL1;
        }
    }
  if (tai_V[2] > 0)
    {
      tai_V[2]--;
      if (tai_V[2]==0)
        {
        resVL2;
        }
    }
  if (tai_V[3] > 0)
    {
      tai_V[3]--;
      if (tai_V[3]==0)
        {
        resVL3;
        }
    }
  if (tai_V[4] > 0)
    {
      tai_V[4]--;
      if (tai_V[4]==0)
        {
        resVL4;
        }
    }
  if (tai_V[5] > 0)
    {
      tai_V[5]--;
      if (tai_V[5]==0)
        {
        resVL5;
        }
    }
  if (tai_V[6] > 0)
    {
      tai_V[6]--;
      if (tai_V[6]==0)
        {
        resVL6;
        }
    }
  if (tai_V[7] > 0)
    {
      tai_V[7]--;
      if (tai_V[7]==0)
        {
        resVL7;
        }
    }

  if (tai_V[8] > 0)  
    {
      tai_V[8]--;
      if (tai_V[8]==0)
        {
        resVR0;
        }
    }
  if (tai_V[9] > 0)
    {
      tai_V[9]--;
      if (tai_V[9]==0)
        {
        resVR1;
        }
    }
  if (tai_V[10] > 0)
    {
      tai_V[10]--;
      if (tai_V[10]==0)
        {
        resVR2;
        }
    }
  if (tai_V[11] > 0)
    {
      tai_V[11]--;
      if (tai_V[11]==0)
        {
        resVR3;
        }
    }
  if (tai_V[12] > 0)
    {
      tai_V[12]--;
      if (tai_V[12]==0)
        {
        resVR4;
        }
    }
  if (tai_V[13] > 0)
    {
      tai_V[13]--;
      if (tai_V[13]==0)
        {
        resVR5;
        }
    }
  if (tai_V[14] > 0)
    {
      tai_V[14]--;
      if (tai_V[14]==0)
        {
        resVR6;
        }
    }
  if (tai_V[15] > 0)
    {
      tai_V[15]--;
      if (tai_V[15]==0)
        {
        resVR7;
        }
    }
}

[Wolfgang (Gast)]

Maxim B. schrieb:
> unsigned char semisegment(unsigned char e)
> {
>   switch(e) {  case 0: e=0x7e; break;
>         case 1: e=0x30; break;
>          ...
>         case 15: e=0x47; break;
>         default: e=0; break;
>       }
>       return e;
> }

Guck dir mal an, was man mit const Array machen kann. Das macht aus der 
Funktion einen Einzeiler.

[Maxim B. (max182)]

Irgendwie mit progmem. Aber ich kapiere das noch nicht ganz...

Ich habe zuerst das so gemacht, wie ich verstehe. Damit nicht alles 
wegen einem klemmt. Das ist nicht optimal, klar - aber arbeitet.

Gleich habe ich noch ADC ausprobiert. Komisch - aber das arbeitet! :)

So mit kleinen Schritten möchte ich die Elementen eineignen, die für 
größere Projekte notwendig sind. Und wenn das etwas nicht optimal wird - 
dann werde ich weiter lernen. Oder auch so lassen - wenn MCU auch so 
macht, was ich davon erwarte. :)

[OldMan (Gast)]

Mal als Anregung eine andere Möglichkeit in BCD zu wandeln:

uint16_t convtab[3]={10,100,1000};

uint_fast16_t tobcd(uint_fast16_t val){
  
  uint_fast8_t i,res;
  uint_fast16_t valret=0;
  
  
  i=3;    // Number of digits minus 1
  
  do {
  i--;
  
  for(res=0; val >= convtab[i]; val -= convtab[i]){
    res++;
  }
  valret |= res;
  valret <<= 4;
  
  } while(i);
  valret |= val;
  
  return(valret);
}

[Maxim B. (max182)]

Sehr interessant, danke!

[Falk B. (falk)]

@ Maxim Burtsev (Firma: BBO-Potsdam) (max182)

>Wenn ich schon etwas lerne, dann praxisorientiert. Für die Zukunft.

Dann solltest du lernen, dass man die Daten der 8 Digits, die man 
sowieso byteweise an den MAX7219 schickt, nicht vorher "aufwändig" in 
einen 32 Bit Wert presst. Eher so. Damit spart man sich tonnenweise 
Schieberei, was besonders auf kleinen Controllern CPU-Zeit kostet. 
Ausserdem kann man die Daten deutlich einfacher weiterverarbeiten, ohne 
sie über Schieberei und Maskierung wieder auseinandernehmen zu müssen.

void preobras_bin10bcd3(unsigned long a, char* digits) {
  int i;

  for(i=7; i>=0, i--) {
    digits[i] = (a % 10);
    a /= 10;
  }
}

>Schleifen sind natürlich eine schöne Sache.
>Allerdings habe ich noch Problem damit.

Das musst du schnellstens ändern, die sind elementar.

>Z.B. es gibt Massiv von Zähler. Mit jedem Zähler ist LED verbunden, wenn
>Zähler bis 0 zählt, dann wird LED abgeschaltet. Es ist mir bisher nicht
>gelungen, Befragung und Verändern von Zähler und Löschen von LED mit
>einer Schleife zu machen.

Das Zauberwort heißt Index.

void ledgasch(void) {
  int i;

  for(i=0; i<16; i++) {
    if (tai_V[i] > 0) {
      tai_V[i]--;
      if (tai_V[i]==0) {
        resVL0;  // hier muss auch was mit Index her, ANPASSEN
      }
    }
  }
}

[OldMan (Gast)]

Falk B. schrieb:
> was besonders auf kleinen Controllern CPU-Zeit kostet.
Modulo ist wesentlich langsamer als eine Subtraktion und ein Shift.
Das ist meine Erfahrung. Denn ich hatte vorher auch Modulo genutzt und 
das hatte den 2313 ziemlich lahm gemacht. Auch der Code hatte sich 
erheblich aufgebläht.
Der von mir gepostet Code läuft aktuell auf einem Attiny 2313, mit 3,7 
MHz.
Entwicklungsumgebung Atmel Studio 6.2.

[Maxim B. (max182)]

Falk B. schrieb:

 resVL0;  // hier muss auch was mit Index her, ANPASSEN

Hier ist gerade das Problem. Weil:

/* VL0 PORTC PC3 */
#define setVL0 (PORTC |= (1<<PC3))
#define resVL0 (PORTC &= ~(1<<PC3))

/* VL1 PORTC PC2 */
#define setVL1 (PORTC |= (1<<PC2))
#define resVL1 (PORTC &= ~(1<<PC2))

/* VL2 PORTC PC1 */
#define setVL2 (PORTC |= (1<<PC1))
#define resVL2 (PORTC &= ~(1<<PC1))

/* VL3 PORTC PC0 */
#define setVL3 (PORTC |= (1<<PC0))
#define resVL3 (PORTC &= ~(1<<PC0))

/* VL4 PORTB PB2 */
#define setVL4 (PORTB |= (1<<PB4))
#define resVL4 (PORTB &= ~(1<<PB4))

/* VL5 PORTB PB1 */
#define setVL5 (PORTB |= (1<<PB1))
#define resVL5 (PORTB &= ~(1<<PB1))

/* VL6 PORTD PD7 */
#define setVL6 (PORTD |= (1<<PD7))
#define resVL6 (PORTD &= ~(1<<PD7))

/* VL7 PORTB PB0 */
#define setVL7 (PORTB |= (1<<PB0))
#define resVL7 (PORTB &= ~(1<<PB0))

/* VR0 PORTD PD1 */
#define setVR0 (PORTD |= (1<<PD1))
#define resVR0 (PORTD &= ~(1<<PD1))

/* VR1 PORTD PD0 */
#define setVR1 (PORTD |= (1<<PD0))
#define resVR1 (PORTD &= ~(1<<PD0))

/* VR2 PORTD PD2 */
#define setVR2 (PORTD |= (1<<PD2))
#define resVR2 (PORTD &= ~(1<<PD2))

/* VR3 PORTD PD4 */
#define setVR3 (PORTD |= (1<<PD4))
#define resVR3 (PORTD &= ~(1<<PD4))

/* VR4 PORTB PB6 */
#define setVR4 (PORTB |= (1<<PB6))
#define resVR4 (PORTB &= ~(1<<PB6))

/* VR5 PORTB PB7 */
#define setVR5 (PORTB |= (1<<PB7))
#define resVR5 (PORTB &= ~(1<<PB7))

/* VR6 PORTD PD5 */
#define setVR6 (PORTD |= (1<<PD5))
#define resVR6 (PORTD &= ~(1<<PD5))

/* VR7 PORTD PD6 */
#define setVR7 (PORTD |= (1<<PD6))
#define resVR7 (PORTD &= ~(1<<PD6))

Die Macros beschreiben Verhältnis Ports:LED.
Ich weiß noch nicht, wie ich aus diesen Macros auf "C" etwas mit Index 
machen kann.

[Falk B. (falk)]

@ Maxim Burtsev (Firma: BBO-Potsdam) (max182)

> resVL0;  // hier muss auch was mit Index her, ANPASSEN
>Hier ist gerade das Problem. Weil:

Da kann man einfach eine Funktion draus machen.

void VLx(int port, int value) {

  if (value !=0) {
    switch (port) {
      case 0: PORTC |= (1<<PC3); break;
      case 1: PORTC |= (1<<PC2); break;
      case 2: PORTC |= (1<<PC1); break;
      case 3: PORTC |= (1<<PC0); break;
      case 4: PORTB |= (1<<PB4); break;
      case 5: PORTB |= (1<<PB1); break;
      case 6: PORTD |= (1<<PD7); break;
      case 7: PORTB |= (1<<PB0); break;
    }
  } else {
    switch (port) {
      case 0: PORTC &= ~(1<<PC3); break;
      case 1: PORTC &= ~(1<<PC2); break;
      case 2: PORTC &= ~(1<<PC1); break;
      case 3: PORTC &= ~(1<<PC0); break;
      case 4: PORTB &= ~(1<<PB4); break;
      case 5: PORTB &= ~(1<<PB1); break;
      case 6: PORTD &= ~(1<<PD7); break;
      case 7: PORTB &= ~(1<<PB0); break;
    }
  } 
}

[Karl H. (kbuchegg)]

Falk B. schrieb:
> @ Maxim Burtsev (Firma: BBO-Potsdam) (max182)
>
>> resVL0;  // hier muss auch was mit Index her, ANPASSEN
>>Hier ist gerade das Problem. Weil:
>
> Da kann man einfach eine Funktion draus machen.

Ist eine Möglichkeit.

Man könnte das ganze auch in eine andere Richtung weitertreiben.
Mit dieser Vorgabe
> Z.B. es gibt Massiv von Zähler. Mit jedem Zähler ist LED verbunden,
> wenn Zähler bis 0 zählt, dann wird LED abgeschaltet.
könnte man auch in diese Richtung weiterarbeiten, dass man einen Zähler 
nicht einfach nur als eine unsigned int Variable auffasst, sondern als 
ein Objekt welches aus
* Zählvariable
* Portdefinition
* Bit an diesem Port
besteht. Also ein

struct backCounter
{
  unsigned int            value;
  volatile unsigned char* port;
  unsigned char           bitmask;
};

dann definiert man sich die benötigten Zähler

struct backCounter counter[] =
{
  { 0, &PORTC, 1<<PC3 },
  { 0, &PORTC, 1<<PC2 },
  { 0, &PORTC, 1<<PC1 }
};

und hat damit dann in so einem backCounter Objekt alles beisammen, so 
dass eine einzige Decrement Funktion es bearbeiten kann

void decCounter( struct backCounter* cnt )
{
  if( cnt->value > 0 )
    cnt->value--;
  if( cnt->value == 0 )
    *(cnt->port) |= cnt->bitMask;
}

bzw. dann eben für alle Counter

...
  for( i = 0; i < sizeof(counter) / sizeof(*counter); ++ i ) {
    if( counter[i].value > 0 )
      counter[i].value--;
    if( counter[i].value == 0 )
      *(counter[i].port) |= counter[i].bitMask;
  }
...

bzw. dann eben eine entsprechende Setzfunktion, die einen Counter auf 
einen bestmmten Wert setzt und gleich auch noch die zugehörige LED 
einschaltet

void setCounter( int cntIndex, unsigned int value )
{
  counter[cntIndex] = value;
  if( value > 0 )
    *(counter[cntIndex].port) &= ~counter[cntIndex].bitMask;
}

zugegeben, die Portzugriffe optimieren dann nicht mehr so gut. Aber so 
schlimm ist das meistens dann auch wieder nicht.

Möglichkeiten gibt es viele und fast immer ist die Copy&Paste 
Programmierung mit weiterkopieren eines Codes und ersetzen von ein paar 
Konstanten die schlechteste davon.

[Maxim B. (max182)]

Vielen Dank!
Mit Struct muß ich noch für mich klären. Variante mit Funktion verstehe 
ich schon genug gut.Wird zwar etwas langsamer, als so. Aber ich denke, 
für meine Aufgabe ist das nicht so kritisch. Es geht um Pegelmesser: 
jeder LED leuchtet bei Überschreitung von Pegel, wird aber mit 
Verzögerung gelöscht (für bessere Sichtbarkeit). Ich denke, so eine 
Schema läßt sich stromsparender mit ATmega zu machen, als mit LM3915. 
Ich habe LED gekauft, die schon bei 0,25 - 0,3 mA ziemlich hell sind. So 
wird 2-Kanal-8 Pos.-Indikator bei mittlerem Pegel (die Hälfte LEDs 
leuchtet) alles zusammen nicht über 3 mA bei 3,3 Volt fressen. So rechne 
ich mindestens.

[Karl H. (kbuchegg)]

Maxim B. schrieb:
> Vielen Dank!
> Mit Struct muß ich noch für mich klären. Variante mit Funktion verstehe
> ich schon genug gut.Wird zwar etwas langsamer, als so. Aber ich denke,
> für meine Aufgabe ist das nicht so kritisch.

Für die meisten Aufgaben ist so etwas komplett unkritisch, wenn man 
ein paar Taktzyklen herschenkt.

[Falk B. (falk)]

@Karl Heinz (kbuchegg) (Moderator)

>> Da kann man einfach eine Funktion draus machen.

>Ist eine Möglichkeit.

Das ist die, welche dem OP im Moment am meisten hilft.

>könnte man auch in diese Richtung weiterarbeiten, dass man einen Zähler
>nicht einfach nur als eine unsigned int Variable auffasst, sondern als
>ein Objekt welches aus

DAS ist was für die höheren Semester. Der OP muss erst einmal die 
Grundlagen lernen. Dann reden wir weiter.

[Karl H. (kbuchegg)]

Falk B. schrieb:

> DAS ist was für die höheren Semester. Der OP muss erst einmal die
> Grundlagen lernen. Dann reden wir weiter.

Da gebe ich dir recht.
Er könnte es allerdings auch als Ansporn sehen, sein C drastisch zu 
verbessern, ehe er dann auch ein reales Projekt geht.
Und so schwer sind Strukturen dann auch wieder nicht zu verstehen.

[Falk B. (falk)]

@ Karl Heinz (kbuchegg) (Moderator)

>> DAS ist was für die höheren Semester. Der OP muss erst einmal die
>> Grundlagen lernen. Dann reden wir weiter.

>Da gebe ich dir recht.
>Er könnte es allerdings auch als Ansporn sehen, sein C drastisch zu
>verbessern, ehe er dann auch ein reales Projekt geht.

Sehe ich nicht so.

>Und so schwer sind Strukturen dann auch wieder nicht zu verstehen.

Ich würde nicht den 3. Schritt vor dem 1. machen wollen. Du bist da 
schon ein gutes Stück betriebsblind, denn es geht nicht nur um structs 
sondern auch Pointer und Adressen und die dazugehörigen 
Dereferenzierungen und Schreibweisen. Das ist für den Anfänger schon 
reichlich kryptisch!

[Maxim B. (max182)]

>>DAS ist was für die höheren Semester.

Ja, so denke ich auch. Man kann nicht gleich nach 10 Stunden 
Orgelunterricht schon Bachsche Fantasie und Fuge g-moll spielen. Manche 
können das auch nach 5 Jahren kaum.
Ich denke, mit Programmieren ist das nicht viel anders. Das ist kein 
Handwerk sondern Kunst.

[Karl H. (kbuchegg)]

Ich seh schon.
Ich fahr wieder nach China. Die wollen noch was lernen.

[Falk B. (falk)]

@ Maxim Burtsev (Firma: BBO-Potsdam) (max182)

>Ja, so denke ich auch. Man kann nicht gleich nach 10 Stunden
>Orgelunterricht schon Bachsche Fantasie und Fuge g-moll spielen. Manche
>können das auch nach 5 Jahren kaum.

Wohll wahr.

>Ich denke, mit Programmieren ist das nicht viel anders. Das ist kein
>Handwerk sondern Kunst.

Naja, wenn man mal GANZ oben Softwareentwicklung (aka Software Design) 
macht, dann vielleicht. Aber in den Normalgegenden ist es "nur" 
Handwerk.

[Falk B. (falk)]

@ Karl Heinz (kbuchegg) (Moderator)

>Ich seh schon.
>Ich fahr wieder nach China. Die wollen noch was lernen.

Karl Heinz, dein Ansatz ist schlicht nicht soderlich pädagogisch. Du 
bringst einem Erstklässler auch keinen Satz des Phytagoras bei . . ., 
auch wenn der keine hohe Mathematik darstellt!

Merksatz:

Abraham sacht zu Bebraham: "Kann ich mal dein Cebra ham?". ;-)

[Maxim B. (max182)]

Falk B. schrieb:

> Naja, wenn man mal GANZ oben Softwareentwicklung (aka Software Design)
> macht, dann vielleicht. Aber in den Normalgegenden ist es "nur"
> Handwerk.

Musizieren ist auch oft so. Das ist Realität. Trotzdem - die Leute haben 
von unseren Konzerten Spaß, sonst kämen sie nicht.

Auch MCU - wenn das Gerät macht, was davon erwartet wird - welcher 
Musiker wird drin kucken, ob auf C alles nach besten Regeln stimmt? Das 
ist eher das Problem von Künstler selbst, für eigene Selbstgefühl. 
Stimmt, daß die Wahrscheinlichkeit von Fehler von Weise abhängig ist. 
Wenn es aber um ganz einfache Dinge geht und sowieso viel Flash und Ram 
frei bleibt...

[Maxim B. (max182)]

Falk B. schrieb:
> resVL0;  // hier muss auch was mit Index her, ANPASSEN
Lieber Herr Brunner,
ich habe diese Hausarbeit gemacht.
Ergebnis: Ihre Variante ist 350 bytes kleiner. Aber um 3-5 mal 
langsamer. D.h. alles hat Preis.

#define KPOR0 1100000 // Konst fuer Schwellen, ist gleich Referenz in uV
const unsigned int POR[] PROGMEM = {KPOR0/1283,KPOR0/1615,KPOR0/2282,
KPOR0/3225,KPOR0/6432,KPOR0/12790,KPOR0/25581,KPOR0/50000};

// Laenge fuer LED (x10 mS)
const unsigned char PeakLaenge[] PROGMEM = {30,29,28,27,26,25,24,23};

void vyvod_led(void)   // Alte Funktion LED ein

{
if (adclinks>POR[0])  // Links
  {
  tai_V[0] = pgm_read_byte(&PeakLaenge[0]);
  setVL0;;
  }
if (adclinks>POR[1])
  {
  tai_V[1] = pgm_read_byte(&PeakLaenge[1]);
  setVL1;
  }
if (adclinks>POR[2])
  {
  tai_V[2] = pgm_read_byte(&PeakLaenge[2]);
  setVL2;
  }
if (adclinks>POR[3])
.
.
.
if (adcrechts>POR[7])
  {
  tai_V[15] = pgm_read_byte(&PeakLaenge[7]);
  setVR7;
      }
}

void ledgasch(void)    // Alte Funktion LED aus 
{
if (tai_V[0] > 0)  // Links 
  {
  tai_V[0]--;
  if (tai_V[0]==0)
  {
  resVL0;
  }
  }
if (tai_V[1] > 0)
  {
  tai_V[1]--;
  if (tai_V[1]==0)
  {
  resVL1;
  }
  }
if (tai_V[2] > 0)
.
.
.
  resVR7;
}
}
}

void VLx(int port, int value) // Neue Funktion fuer LED mod
{

  if (value !=0) {
    switch (port) {
      case 0: setVL0; break;
      case 1: setVL1; break;
      case 2: setVL2; break;
      case 3: setVL3; break;
      case 4: setVL4; break;
      case 5: setVL5; break;
      case 6: setVL6; break;
      case 7: setVL7; break;
    case 8: setVR0; break;
    case 9: setVR1; break;
    case 10: setVR2; break;
    case 11: setVR3; break;
    case 12: setVR4; break;
    case 13: setVR5; break;
    case 14: setVR6; break;
    case 15: setVR7; break;
    }
  } else {
    switch (port) {
      case 0: resVL0; break;
      case 1: resVL1; break;
      case 2: resVL2; break;
      case 3: resVL3; break;
      case 4: resVL4; break;
      case 5: resVL5; break;
      case 6: resVL6; break;
      case 7: resVL7; break;
    case 8: resVR0; break;
    case 9: resVR1; break;
    case 10: resVR2; break;
    case 11: resVR3; break;
    case 12: resVR4; break;
    case 13: resVR5; break;
    case 14: resVR6; break;
    case 15: resVR7; break;
    }
  } 
} 

void v_led(int a, int b)   // Neue Funktion LED ein, POR und index
{
  int i;
  for(i=0; i<8; i++) 
  { 
  if (a > POR[i])
  {
    tai_V[i+b] = pgm_read_byte(&PeakLaenge[i]);
      VLx(i+b, 1);  
    }
  }
} 

void vyvod_led(void)   // Neue Funktion LED ein
{
  v_led(adclinks,0);
  v_led(adcrechts,8);
} 

void ledgasch(void) // Neue Funktion LED aus 
{
  int i;

  for(i=0; i<16; i++) 
  {
    if (tai_V[i] > 0) 
  {
      tai_V[i]--;
      if (tai_V[i]==0) 
    {
        VLx(i, 0);  
      }
    }
  }
} 
/* Alte Variante:1724 bytes LED aus: 247 Cycles max, LED ein: 215 Cycles max
   Neue Variante 1374 bytes LED aus: 848 Cycles max, LED ein: 1051 Cycles max */

Noch mal Vielen Dank!
Ich glaube, ich habe noch ein bißchen etwas erlernt!

[Falk B. (falk)]

@ Maxim Burtsev (Firma: BBO-Potsdam) (max182)

>ich habe diese Hausarbeit gemacht.
>Ergebnis: Ihre Variante ist 350 bytes kleiner. Aber um 3-5 mal
>langsamer. D.h. alles hat Preis.

So ist es meistens. Nur in sehr wenigen Fällen ist ein Algorithmus 
kürzer UND schneller.

https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung

https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Wie

[Maxim B. (max182)]

Falk B. schrieb:

> 
https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung
>
> https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Wie

Ich habe das gelesen...

Also, die Variante ohne Schleifen hat auch Recht fürs Leben?

Warum?

Alle Pins sind schon so besetzt, daß etwas darüber zu machen kaum 
möglich erscheint (das ist Grund, warum SPI immer ein- und ausgeschaltet 
wird: wenn SPI eingeschaltet, wird MISO als Eingang von Hardware 
eingestellt, sonst ist das VL4-Ausgang. Variante mit TQFP auch - nur 
zwei LED mehr, sonst alles gleich).

Es gibt keine ATmega x8 mit 1,5 kB Flash, mindestens 4, oder was ich 
verwende (ATmega88) hat 8 kB. Ist Programm 1724 Bytes lang oder nur 
1374, bleibt sowieso viel Flash unbenutzt. Aber die Variante mit 1724 
Bytes ist spürbar schneller, und das ist absolut gratis! Hier ist 
Geschwindigkeit nicht absolut erforderlich, wirkt aber positiv auf 
Genauigkeit.

while(1)
  {            // Einmal in 400 mS mit Ind. MAX7219
  adclinks = leselinks();    
  adcrechts = leserechts();  
  vyvod_led();        // LED Einschalten nach Signal
    if (FLAG_TIK == 1) // Wenn Tik=1
    {
    ledgasch();  // LED-Zaehler aktualisieren und die mit "0" loeschen
    FLAG_TIK = 0;  
    }
#if (max7219_spi) // Wenn Indikator eingeschlossen, dann einmal in 400 mS

    if (FLAG_IND == 1)  // Wenn IND=1
    {
    CLKPR = 0x80; // F_CPU=Max
    CLKPR = K_CLKPR_MAX;
    ind_max7219(adclinks,0); // ADC-links > indikator ab 0
    ind_max7219(adcrechts,4);  // ADC-rechts > indikator ab 4
    FLAG_IND = 0;
    
    CLKPR = 0x80; 
    CLKPR = K_CLKPR; // F_CPU=Norm
    }
#endif
  }

Programm macht nichts anderes als mit ADC 2 Eingänge ablesen und 
bewerten. Einstimmung geht mit Programm, deshalb gibt es Funktionen für 
MAX7219, aber die sind mit #if - #endif nach der Einstimmung aus dem 
endgültigen Programm ausgeschlossen (Funktionen für MAX7219 brauchen 
relativ viel Zeit). Danach wird das Programm noch um 510 Bytes kürzer, 
was übrigens nichts ändert: Flash bleibt um mehrfaches über Bedarf.

In einem anderen Fall wird Schleife vielleicht praktischer, in diesem 
Beispiel aber eher nicht (lieber noch mehr F_CPU absenken, um 
Stromverbrauch zu reduzieren. Aber ich glaube, bei 500 kHz kann man 
schon nicht mehr viel optimieren). Interessant, daß Compiler eigentlich 
gleicher Meinung ist! :) Funktion

int lesenadc(void)    // ADC lesen
{
  ADCSRA |= (1<<ADSC);
  while (ADCSRA & (1<<ADSC)) {}
  return ADCW;
}

 macht er inline.

P.S. das ist immer noch nicht realisiert. Ich überlege noch, ob es nicht 
besser wird, auf einer Leitplatte gleich 4 Spuren zu machen, und zwar 
zusammen mit Vorverstärker und auch Stromversorgung. Es gibt Argumente 
dafür und dagegen.

[Falk B. (falk)]

@ Maxim Burtsev (Firma: BBO-Potsdam) (max182)

>Also, die Variante ohne Schleifen hat auch Recht fürs Leben?

Hier nicht, allgemein schon, wenn man die maximale Geschwindigkeit 
braucht.

>Es gibt keine ATmega x8 mit 1,5 kB Flash, mindestens 4, oder was ich
>verwende (ATmega88) hat 8 kB. Ist Programm 1724 Bytes lang oder nur
>1374, bleibt sowieso viel Flash unbenutzt. Aber die Variante mit 1724
>Bytes ist spürbar schneller, und das ist absolut gratis!

Sürbar? Wer spürt denn das? Du? Wo? Im Simulator?
Deine CPU langeweilt sich bei der Aufgabe so oder so zu tode!

>Hier ist
>Geschwindigkeit nicht absolut erforderlich, wirkt aber positiv auf
>Genauigkeit.

Blödsinn.


>    CLKPR = 0x80; // F_CPU=Max
>    CLKPR = K_CLKPR_MAX;
>    ind_max7219(adclinks,0); // ADC-links > indikator ab 0
>    ind_max7219(adcrechts,4);  // ADC-rechts > indikator ab 4
>    FLAG_IND = 0;

>    CLKPR = 0x80;
>    CLKPR = K_CLKPR; // F_CPU=Norm

Warum stellst du hier den Prescaler für die CPU um? Das ist nicht 
sonderlich sinnvoll, zumal die SPI selber einen Prescaler hat. Nutze den 
Sleep Mode.

>relativ viel Zeit). Danach wird das Programm noch um 510 Bytes kürzer,
>was übrigens nichts ändert: Flash bleibt um mehrfaches über Bedarf.

Du wirst es überleben. Oder nimm einen kleinen Attiny2313 und ein paar 
Schieberegister als Porterweiterung, wenn es dich glücklich machen, den 
Flash nahzu zu 100% auszunutzen.

>In einem anderen Fall wird Schleife vielleicht praktischer,

Meistens. Denn damit hat man weniger Schreibarbeit und es ist deutlich 
übersichtlicher.

> in diesem
>Beispiel aber eher nicht (lieber noch mehr F_CPU absenken, um
>Stromverbrauch zu reduzieren.

Das macht man anders, siehe oben.

[Andreas H. (ahz)]

Maxim B. schrieb:
> P.S. das ist immer noch nicht realisiert. Ich überlege noch, ob es nicht
> besser wird, auf einer Leitplatte gleich 4 Spuren zu machen, und zwar
> zusammen mit Vorverstärker und auch Stromversorgung.

Hallo Maxim

Mir ist ehrlich gesagt nicht ganz klar WAS Du eigentlich machen willst.

Willst Du nur einmal ausprobieren, ob Du so ein VU Meter zum laufen 
bekommst ?
Oder willst Du eher ein bisschen programmieren ?
Oder einfach nur ein bisschen spielen ?
Oder willst Du eigentlich ein VU-Meter irgendwo einsetzen ?

Dann könnte Dir das Forum vielleicht auch etwas zielgerichteter helfen.
Und Du müsstest nicht viel Geld für eine Platine ausgeben, die nachher 
nicht das macht, was Du eigentlich wolltest.

Viele Grüße
Andreas

[Maxim B. (max182)]

Falk B. schrieb:

>>    CLKPR = 0x80; // F_CPU=Max
>>    CLKPR = K_CLKPR_MAX;
>>    ind_max7219(adclinks,0); // ADC-links > indikator ab 0
>>    ind_max7219(adcrechts,4);  // ADC-rechts > indikator ab 4
>>    FLAG_IND = 0;
>
>>    CLKPR = 0x80;
>>    CLKPR = K_CLKPR; // F_CPU=Norm
>
> Warum stellst du hier den Prescaler für die CPU um? Das ist nicht
> sonderlich sinnvoll, zumal die SPI selber einen Prescaler hat. Nutze den
> Sleep Mode.
Weil dadurch nicht nur SPI beschleunigt wird, sondern auch alle 
Funktionen, die für BCD u.ä. verantwortlich sind.
Was spricht dagegen? Das brauche ich nur für Abstimmung (weil Vref große 
Toleranz hat). Nach Abstimmung wird alles für Indikator raus.

>Oder nimm einen kleinen Attiny2313
Der hat doch kein ADC?

[Falk B. (falk)]

@ Maxim Burtsev (Firma: BBO-Potsdam) (max182)

>>Oder nimm einen kleinen Attiny2313
>Der hat doch kein ADC?

Stimmt, hab ich übersehen. Es gibt aber andere Tinys mit ADC.
Solches krampfhafte Sparen von Flash, RAM oder sonstigen Resourcen lohnt 
sich nur bei (Groß)serienproduktion. Bei Einzelstücken oder Kleinserien 
sind die Kosten für die Hardware meist nebensächlich.

[Maxim B. (max182)]

Andreas H. schrieb:

> Oder willst Du eigentlich ein VU-Meter irgendwo einsetzen ?
das möchte ich, klar. Ich brauche Schema fünfmal.

Alles, was ich mache, hat immer mehrere Ziele gleichzeitig in Visier.

Natürlich möchte ich auch etwas damit erlernen (schon etwas in dieser 
Richtung gegangen, vielen Dank an alle für eure geduldige Erklärungen!).

Wozu ich so etwas brauche? Ich habe einmal bei dem Mitschnitt etwas 
erlebt: jemand hat Mikrofonkabel zertreten. Ich habe das leider zu spät 
erkannt. So ein Indikator könnte mir damals helfen. Da das eine 
Nebenaufgabe ist, wäre es natürlich blöd, dafür zu viel Strom ausgeben - 
solange alles von Akku laufen soll.

Entschuldigung - ich möchte hier keinen provozieren. Aber wirklich: ich 
verstehe nicht, warum ich Schleife machen muß, solange das nur alles 
verlangsamt und Flash auch ohne Schleifen genug bleibt?

Wissen, wie man eine Schleife macht - das möchte ich (und hier hat man 
mir erklärt, was ich selber nicht finden konnte: wie man das mit Pins 
macht, innerhalb einer Schleife). Verwenden - hier ist zu überlegen.

Gerade in dem Artikel, den mir Herr Brunner gegeben hat, steht: 
optimieren kann man für Größe oder für Geschwindigkeit, je nachdem was 
man braucht.

Viele Grüße,

[Falk B. (falk)]

@ Maxim Burtsev (Firma: BBO-Potsdam) (max182)

>verstehe nicht, warum ich Schleife machen muß,

Muss nicht, aber es ist meistens günstiger. Sagte ich bereits.

>solange das nur alles
>verlangsamt und Flash auch ohne Schleifen genug bleibt?

Denn damit hat man weniger Schreibarbeit und es ist deutlich
übersichtlicher.

[Maxim B. (max182)]

Tinys haben bis 20 Pin. ich wollte eine Einheit, die gleich zwei Spuren 
bedient. Für jede Spur eigene Schema - das wäre zu viel bei 10 oder 12 
Spuren. Alles muß noch in eine Gehäuse vernünftiger Größe passen. So 
etwa 300 x 180, damit alle Buchsen bequem liegen und alle LED zu sehen 
sind, aber noch zu tragen wäre.

[Maxim B. (max182)]

Falk B. schrieb:

> Denn damit hat man weniger Schreibarbeit und es ist deutlich
> übersichtlicher.

Ja, das stimmt. Viel übersichtlicher. Schließlich kann ich F_CPU bis auf 
1 MHz einstellen und Differenz ausgleichen (ADC braucht ungefähr gleiche 
Zeit unabhängig von CPU-Freq.), Preis dafür wäre 0,5 mA, das wäre noch 
zu verdauen.

Schön, wenn man viele Varianten hat, daß man wählen kann!

Was Sleep betrift: ich habe schon über ADC Noise Reduction Mode gedacht. 
Das wird wohl die Richtung für weitere Programmentwicklung. Noch ein 
paar hundert uA sparen :) Ob das dem Wandler für negative Spannung nicht 
merkbar stört? Was ich in keinem Fall möchte: Subfrequenzen in 
Speiseleitungen, die in Klang durchsickern können.

Für Spannungwandler plane ich ATtiny261A - und das mache ich eher mit 
Assembler. Oder doch C? :) Das wird ein einfacher Ersatz für 74HC-Serie, 
ein IC-Körper statt 6 oder 7.

[Maxim B. (max182)]

Andreas H. schrieb:

> Und Du müsstest nicht viel Geld für eine Platine ausgeben, die nachher
> nicht das macht, was Du eigentlich wolltest.
So viel Geld ist das nicht. Eine Fotoplatine 160x100 für 2,2€, 1 oder 2 
Folien, ein bißchen Tinten, ein Löffel NaOH, etwas FeCl3... Etwas 
Meckern von meiner Frau vielleicht noch :)

[Andreas H. (ahz)]

Maxim B. schrieb:
>> Und Du müsstest nicht viel Geld für eine Platine ausgeben, die nachher
>> nicht das macht, was Du eigentlich wolltest.
> So viel Geld ist das nicht. Eine Fotoplatine 160x100 für 2,2€, 1 oder 2
> Folien, ein bißchen Tinten, ein Löffel NaOH, etwas FeCl3... Etwas
> Meckern von meiner Frau vielleicht noch :)

Maxim B. schrieb:
>> Oder willst Du eigentlich ein VU-Meter irgendwo einsetzen ?
> das möchte ich, klar. Ich brauche Schema fünfmal.

Dann wäre das evtl. eher etwas für Dich. Und macht auch weniger Ärger 
mit Deiner Frau ;-)

https://www.itead.cc/open-pcb/pcb-prototyping/2layer-green-pcb-5cm-x-10cm-max.html?___SID=U

Die angegebene Größe ist die Maximalgröße. Die Platine darf also auch 
kleiner sein. Andere Maximalgrößen gibt es natürlich auch (z.B. 10cm x 
10 cm)

Maxim B. schrieb:
> Wozu ich so etwas brauche? Ich habe einmal bei dem Mitschnitt etwas
> erlebt: jemand hat Mikrofonkabel zertreten. Ich habe das leider zu spät
> erkannt. So ein Indikator könnte mir damals helfen.

Ich verstehe Dein Problem. Aber ist das, was Du vorhast dann eine Lösung 
?
Wenn Du gerade am spielen bist, dann kannst Du vermutlich nicht laufend 
auf die Anzeige schauen.

Wenn gerade nicht gespielt wird, dann zeigt das VU-Meter nichts an. Auch 
kein kaputtes Kabel.

Was für Mikrofone benutzt Du denn? Bei Mikros mit Phantomsspeisung 
könntest Du probieren den Abschlusswiderstand zu messen und ggf. EINE 
Led einschalten, wenn der Widerstand weg (also Kabel ab) ist.
Das lenkt beim spielen nicht ab (ausser das Mikro ist ab) und geht auch, 
wenn gerade nicht gespielt wird.

> Da das eine
> Nebenaufgabe ist, wäre es natürlich blöd, dafür zu viel Strom ausgeben -
> solange alles von Akku laufen soll.

Aber der Stromverbrauch Deiner Schaltung (die Du gepostet hattest) ist 
doch nicht das was der Prozessor verbraucht. Am meisten Strom 
verbrauchen Deine LEDs oder? Und die müssen On-Stage schon etwas heller 
sein. Sonst siehst Du sie nicht mehr richtig.

Meinst Du nicht, dass Du da an der falschen Stelle Strom sparen willst?

Maxim B. schrieb:
> Entschuldigung - ich möchte hier keinen provozieren. Aber wirklich: ich
> verstehe nicht, warum ich Schleife machen muß, solange das nur alles
> verlangsamt und Flash auch ohne Schleifen genug bleibt?
>

Du provozierst keinen (denke ich). Wenn Du nicht fagst bekommst Du auch 
keine Antworten. Also frag ;-)

Du musst keine Schleifen nehmen. Es ist das Deine Entscheidung.

Allerdings bieten Schleifen sooo viel Vorteile, dass man sie sehr gerne 
benutzt.
Der Code ist viel einfacher lesbar. Vergleiche doch z.B. Deinen Code mit 
dem Code den Falk oder Karl-Heinz gepostet haben. Ihr Code ist kürzer 
(was nicht notwendigerweise besser sein muss) und es wird auch sehr 
schnell klar, wie sich die Variablen von Schritt zu Schritt (also pro 
Schleifendurchlauf) verändern.

DU (und nur Du) siehst das bei Deinem Code vieleicht noch auf Anhieb. 
Aber andere Leute müssen da Zeile für Zeile genau hinsehen.
Auch deswegen, weil sie vermuten werden "Es gibt bestimmt einen 
speziellen Grund, warum er keine Schleife genommen hat".
Und wenn Du in 5 Jahren noch einmal in Dein Programm reinschaust, dann 
freust Du Dich auch, wenn Du ihn noch verstehst ;-)

Wenn Du Dich erst mal an Schleifen gewöhnt hast (und das geht sehr 
schnell), dann "denkst" Du auch beim Programmentwurf in diese Richtung.
Es ist nur ein Konstrukt der Dir (und anderen) das Verstehen des 
Programms vereinfacht. Mehr nicht ;-)

> Wissen, wie man eine Schleife macht - das möchte ich (und hier hat man
> mir erklärt, was ich selber nicht finden konnte: wie man das mit Pins
> macht, innerhalb einer Schleife). Verwenden - hier ist zu überlegen.
>
Probiere es einfach aus.

> Gerade in dem Artikel, den mir Herr Brunner gegeben hat, steht:
> optimieren kann man für Größe oder für Geschwindigkeit, je nachdem was
> man braucht.

Ist das nicht erst dann interessant, wenn Du entweder Platz oder 
Geschwindigkeitsprobleme hast?
Dein Prozessor (AT8 ?) macht typ. 8 Millionen Anweisungen pro Sekunde 
(!!!). Nutzt Du da wirklich schon alles aus? Ich vermute nicht.

Und Platz im Flash ist doch auch noch reichlich, oder?

Es ist ein sehr beliebter Fehler, die Leistungsfähigkeit von Prozessoren 
zu unterschätzen. So ein kleiner AT8 schafft schon gut was weg.
Vieleicht solltest Du das Programm erst einmal "im Groben" fertig machen 
und dann (!) schauen, ob es irgendwo zu eng wird? (Klappt oft :-D )

Viele Grüße
Andreas