Attiny2313 macht Probleme

Ich habe das Fusebit CKDIV8 deaktiviert. Nun brummt der Servo nur, aber 
auf dem Oszilloskop ist der Pegel öfter hoch als niedrig und die Phasen 
müsten 10 mal länger sein. Was muss ich verändern? Muss ich irgendwelche 
Fuses setzen?

So wie ich das verstehe braucht das Programm einen Takt von 8MHz, damit 
der UART auf der richtigen Frequenz arbeitet. Ist denn der externe Quarz 
bestückt? Wenn ja, welcher Wert?
Wie sind die Fuses gesetzt?

Wenn Du das Servo-Signal misst, dann müßtest Du bei korrekter 
Taktfrequenz eine Wiederholrate von 50Hz (20ms Periodendauer) bekommen.

Bei den Fuses ist nichts von den Grundeinstellungen verändert bis auf 
CKDIV8 also nur noch SPIEN ist gesetzt. Ich verwende z.Z. keinen 
externen Quarz. Ich habe das Oszilloskop auf 1ms/cm und das Signal ist 2 
Kästchen lang. Also 2ms bzw. 500Hz oder? Müsste das Signal nicht auch 
Invertiert werden? Der Servo knurrt nur und bewegt sich nicht. Das 
Signal ändert sich, wenn man die Schaltung mit Daten füttert. Da ich mir 
nicht sicher bin, ob ich alles richtig abgelesen habe, hänge ich Fotos 
von Oszilloskop an.

Am Motor Ausgang tut sich übrigens immer noch nichts, bzw die Daten die 
Ausgegeben werden stimmen nur teilweise. Man bemerk nur den Unterschied 
ob A oder a als Daten eingegeben werden, Die Spannung steigt auf +0.5V 
oder -0.5V an und bricht dann wieder zusammen. Danach beginnt das selbe 
erneut.

Das sind für meinen Geschmack zu viele Problemkreise auf einmal, die von 
hier aus nicht zu kontrollieren sind.

Daher eines nach dem anderen.

Als erstes solltest du mal feststellen, ob dein µC mit der vorgesehenen 
Taktfrequenz läuft.

Dazu hängst du an PB0 (entweder direkt oder hinter dem Transistor) eine 
LED samt 220 Ohm Vorwiderstand an.

Das Programm

1

#define F_CPU 8000000UL

2

3

#include <avr/io.h>

4

#include <util/delay.h>

5

6

int main()

7

{

8

  DDRB = 0x01;

9

10

  while( 1 ) {

11

    PORTB = 0x01;

12

    _delay_ms( 1000 );

13

    PORTB = 0x00;

14

    _delay_ms( 1000 );

15

  }

16

}

Wenn alles stimmt, dann blinkt deine LED mit 1 Sekunde. 1 Sekunde ein / 
1 Sekunde aus.

LED ist in diesem Fall besser als Oszi, weil die LED von keinen 
Geräteeinstellungen abhängt. Und 1 Sekunde kannst du nach Gefühl gut 
schätzen. Die Alternative ist 8 Sekunden und den Unterschied erkennst du 
mit freiem Auge :-)

Kannst du das bitte mal verifizieren?

> Dazu hängst du an PB0

Edit: mein fehler - PB3 natürlich. Dort wo auch das Servo hängt

Und das Programm muss lauten

1

#define F_CPU 8000000UL

2

3

#include <avr/io.h>

4

#include <util/delay.h>

5

6

int main()

7

{

8

  DDRB = 0x08;

9

10

  while( 1 ) {

11

    PORTB |=  0x08;

12

    _delay_ms( 1000 );

13

    PORTB &= ~0x08;

14

    _delay_ms( 1000 );

15

  }

16

}

Ich habe nun das Oszilloskop an den Ausgang für den Motor gehängt. Das 
Oszilloskop gibt ein Bild aus, fast wie ein EKG aussieht. Kommen große 
werte nach A bzw. a werden die Phase weiter. Kann mir jemand sagen, 
warum das so ist? Und ich muss oben gesagtes Korrigieren. Ich drehte den 
Servo von Hand ganz na links und habe ihn noch einmal angeschlossen. Er 
drehte wieder nach rechts.

PEBKAC-Fehler... Der arme Tiny2313 kann nichts dafür...!

Von hier kann auch niemand auf dein Oszi schauen. Du mußt schon mit den 
Infos rüberrücken die angefragt werden. Das sind in der Tat viele 
Baustellen, Du mußt eine nach der anderen fertig machen.

An alle anderen.

Bitte beachtet diese Info aus dem Eröffnungsposting

> Dann habe ich mit WinAVR, in dem ich die beiden C
> Dateien in das Programmers Notepad gezogen habe, mit
> selbigen auch auf den Controller gebrannt.

Das bedeutet zunächst mal: kein extern definiertes F_CPU
und im Code hab ich beim schnellen drüberschauen auch keines gesehen.

Also habe eine LED drangehängt. Die leuchtet etwa 2 mal in der Sekunde 
also 2HZ. Heist das der Chip ist doppelt so schnell wie er eigentlich 
sein sollte?

Viermal ... Nach dem Programm sollte sie eine Sekunde lang leuchten, 
eine Sekunde dunkel, eine Sekunde leuchten, eine Sekunde dunkel ..... 
ASO.

und nun?

Fuses kontrollieren.
Auf der Schaltung nachsehen, ob der richtige Quarz eingebaut ist.

Karl Heinz Buchegger schrieb:
> Fuses kontrollieren.
> Auf der Schaltung nachsehen, ob der richtige Quarz eingebaut ist.

Edit: Was hast du eigentlich für einen Quarz verbaut? Auf dem Schaltplan 
ist kein Wert eingetragen.

Karl Heinz Buchegger schrieb:
> Fuses kontrollieren.
> Auf der Schaltung nachsehen, ob der richtige Quarz eingebaut ist.

Wie schon gesagt, die Schaltung läuft ohne Quarz. Wie oben steht habe 
ich auch die Fuses bis auf CKDIV8 nicht verändert, das heißt der interne 
Quarz wird benutzt.

Öhm Moment. Was ist denn bei Dir für ein Quarz dran?

Das Programm von kbuchegg kann nur korrekt laufen wenn auch ein 8 MHz 
Quarz dran ist. Bzw. Du mußt F_CPU auf den Wert ändern, den Dein Quarz 
tatsächlich hat.

Es ist kein Quarz in der Platine

Könnte ich auch für den Test ein 4MHz Quarz verwenden? Ich habe gerade 
keinen 8 MHz Quarz da.

Für welche Frequenz ist DEIN Programm denn ausgelegt? Also wie ist F_CPU 
in DEINEM Programm definiert?

Hi,
der ATtiny2313 hat nen internen 8 und 4 MHz Oszi lässt sich über die 
CKSEL 3 - 0 einstellen (siehe Bild) also hast du zusammen mit CLkDIV8 
folgende Möglichkeiten: 8 MHz, 1 MHz, 4 MHz, 500 KHz. Das solltest du 
als erstes überprüfen. (Fuse-bits). Des weiteren könnte _delay_ms() 
durch kompilereinstellungen wegoptimiert werden. ich würde ja zu einer 
PWM mit 50% am Timer 0 ohne vorteiler starten dann kannst du genau sehen 
wie lang der timer braucht und dir daher die Frequenz herleiten.

> 8 MHz, 1 MHz, 4 MHz, 500 KHz
Dann frag ich mich, wie kbucheggs Programm mit F_CPU 8 Mille und 2 
1000er Delays auf 2 Hz kommt. Es dürfte bestenfalls 0,5 Hz oder noch 
weniger erreichen.

Ben _ schrieb:
> Für welche Frequenz ist DEIN Programm denn ausgelegt?

Ist schwer zu sagen.
In den uart Routinen findet sich ein Hinweis auf 8Mhz
Und die Timereinstellung sieht beim schnellen Querlesen auch so aus, als 
ob sie auf 8MHz gerechnet wäre. (Ich habs aber nicht im Detail 
nachgerechnet)


> Also wie ist F_CPU
> in DEINEM Programm definiert?

Tja.
Hat er gar nicht.

Ben _ schrieb:
>> 8 MHz, 1 MHz, 4 MHz, 500 KHz
> Dann frag ich mich, wie kbucheggs Programm mit F_CPU 8 Mille und 2
> 1000er Delays auf 2 Hz kommt. Es dürfte bestenfalls 0,5 Hz oder noch
> weniger erreichen.


Das wiederrum ist mir auch nicht klar.


Dru mhab ich absichtlich 1 Sekunde an 1 Sekunde aus geschrieben. Damit 
es nur ja keine Misverständnisse gibt.


Hmm.
Eine Möglichkeit gibt es noch, die alles durcheinander bringt: Optimizer 
nicht eingeschaltet.
Nicht vergessen, er benutzt kein AVR-Studio!

> Tja.
> Hat er gar nicht.
Achso. Na große Klasse. Dann weiß er doch schon was er jetzt ändern muß.

Simon H. schrieb:

> als erstes überprüfen. (Fuse-bits). Des weiteren könnte _delay_ms()
> durch kompilereinstellungen wegoptimiert werden.

Können sie nicht.
Die _delay_ms Routine, die mit dem GCC mitkommt, wird 100% sicher nicht 
wegoptimiert.

Ben _ schrieb:
>> Tja.
>> Hat er gar nicht.
> Achso. Na große Klasse. Dann weiß er doch schon was er jetzt ändern muß.

Kopfkratz.
Das Problem:
Der Code ist so geschrieben, dass die 8Mhz überall implizit eingerechnet 
sind.

1

void UART_Init (unsigned long baudrate) { 

2

  /* Set the baud rate */   

3

  //Assumes 8Mhz clock in single speed (U2X=0) mode

4

  switch(baudrate){

5

  case 9600:   UBRRL = 51; break; //.2% error

6

  case 19200:  UBRRL = 25; break; //.2% error

7

  case 38400:  UBRRL = 12; break; //.2% error

8

  case 57600:  UBRRL = 8; break;  //-3.5% error

9

  case 115200: UBRRL = 1; break;  //8.5% error

10

  default: UBRRL=12;

11

  }

D.h. das Ziel muss es sein, dass der µC mit dem Testprogramm (und 
eingeschalteter Compiler Optimierung) die Blinkzeiten auch einhält. Nur 
dann können wir sicher sein, dass der µC auch wirklich mit 8Mhz läuft.
Und dann sollte eigentlich alles funktionieren (wenn wir mal davon 
ausgehen, dass das restliche Programm soweit fehlerfrei ist)

Eigenartig ist jedoch, dass seine LED zu schnell blinkt.
Maximilian: Hast du das Testprogramm (wegen Fehler oder so) irgendwie 
verändert?

Okay... dann würd ich an der Stelle sagen der TE besorgt sich einen 8 
Mhz Quarz und 2x 22pF.

ok aber interessant ist das bei eingestellter F-CPU 8MHz das ding 4 mal 
so schnell blinkt was bei richtiger verarbeitung der delays doch auf 
32MHz schließen lässt. (das nenn ich mal Hardwarebeschleunigung :-D )

achso und falsch ablaufende delays hate ich schon, allerdings nur bei 
avr studio 5

OT: Kifft der Maximilian? ;) **und wegrenn**

SCNR

Neinnein. Ich habe überlegt wo ich einen Quarz herbekomme. Ich muss 
nähmlich extra nach München fahren. Hier auf den Land gibt es keinen 
entsprechenden Laden

Simon H. schrieb:

> achso und falsch ablaufende delays hate ich schon, allerdings nur bei
> avr studio 5

Falsch ablaufende delays können 5 Ursachen haben

* F_CPU stimmt nicht mit der tatsächlichen Taktfrequenz überein
* _delay_ms wird nicht mit einer Konstanten benutzt
* F_CPU wird im Code zu spät definiert (nach dem #include)
* Optimizer ist nicht eingeschaltet
* es gab mal eine WinAvr Version, die tatsächlich falsche
  Wiederholraten erzeugte.


War nicht bei der fehlerhaften WinAVR Version ein Faktor 4 im Spiel?

OK. machen wir einen Gegentest, nur um Compilerabhängigkeiten 
auszuschliessen.

1 Sekunde blinken mit Hilfe des Timers.

Melde mich gleich wieder.

Laut AVR Studio 4 benutze ich gerade den internen RC 8Mhz und 
Start-up-time 14CK+65ms. Sollich mal bei den Zeiten rumspielen oder ist 
der AVR dann verfuset?

Wie schalte ich die Optimierung bei AVR Studio 4 ein?

Besser nicht an den Fuses spielen, zu große Gefahr daß Du ihn verfusest.

Maximilian A. schrieb:
> Laut AVR Studio 4 benutze ich gerade den internen RC 8Mhz und
> Start-up-time 14CK+65ms. Sollich mal bei den Zeiten rumspielen oder ist
> der AVR dann verfuset?

Lass das so.

Sihst du ob CKDIV8  eingeschaltet ist? (EIn Häkchen hat)

Maximilian A. schrieb:
> Wie schalte ich die Optimierung bei AVR Studio 4 ein?


Project - Configuration Options

Im Dialog muss die Einstellung für Optimization auf -Os stehen.


Probier mal dieses Programm aus

1

#include <avr/io.h>

2

#include <avr/interrupt.h>

3

4

ISR( TIMER1_OVF_vect )

5

{

6

  static int i = 0;

7

8

  i++;

9

  if( i == 122 ) {

10

    i = 0;

11

    PORTB ^= 0x08;

12

  }

13

}

14

15

int main()

16

{

17

  DDRB = 0x08;

18

19

  TIMSK = ( 1 << TOIE1 );

20

  TCCR1B = ( 1 << CS10 );

21

22

  sei();

23

24

  while( 1 ) {

25

  }

26

}

das ist unabhängig von irgendwelchen Compilereinstellungen.
Wieder: Die LED muss 1 Sekunde ein / 1 Sekunde aus

Jetzt funktioniert es. CKDIV8 hat noch immer keinen Hacken

Maximilian A. schrieb:
> Jetzt funktioniert es. CKDIV8 hat noch immer keinen Hacken

Und die delay Lösung ist immer noch zu schnell?

->  Compiler auf eine neuere Version updaten

Soll ich nun WinAVR updaten? Oder muss ich AVR Studio 5 nehmen?

AVR Studio ist die Entwicklungsumgebung
WinAVR ist der Compiler.

WinAVR integriert sich in AVR Studio

AVR-Studio ist ok, kannst du ruhig so lassen. Aber es scheint so, als ob 
du die schadhafte WinAVR Version erwischt hast.

Ich bin jetzt eine Version bei WINAVR zurück gegangen. Das Resultat ist 
aber das Selbe!

Maximilian A. schrieb:
> Ich bin jetzt eine Version bei WINAVR zurück gegangen.

OK.

D.h. die delay Version der Blink-Geschichte blinkt jetzt mit 1 Sekunde?


Dieses Programm, unverändert und Compiler auf -Os eingestellt

1

#define F_CPU 8000000UL

2

3

#include <avr/io.h>

4

#include <util/delay.h>

5

6

int main()

7

{

8

  DDRB = 0x08;

9

10

  while( 1 ) {

11

    PORTB |=  0x08;

12

    _delay_ms( 1000 );

13

    PORTB &= ~0x08;

14

    _delay_ms( 1000 );

15

  }

16

}

By the way.

Welche anderen Hardware-Modifikationen hast du sonst noch vorgenommen? 
Ist der Transistor am Servo Ausgang vorhanden? Der ist insofern wichtig, 
als er das Signal invertiert und diese Inversion natürlich vom Programm 
berücksichtigt wird. (Das würde zb erklären warum für dich die Signale 
genau falsch herum aussehen. Kann natürlich auch sein, dass du mit dem 
Oszi am falschen Messpunkt bist. Also am Servokabel selber messen, nicht 
am µC Pin)

Es ist das gleiche wie vor dem Versionswechsel. Es blinkt 2 mal pro sec.

Ups! Den Transistor habe ich vergessen, da er ja nicht auf der Platine 
ist und in einen Schrumpfschlauch kommt.

Beitrag "Re: _delay_ms() läuft 4 Mal schneller als erwartet"
Hm...

Bis auf die Widerstände am Rand und den Quarz ist sonst alles so wie im 
Schaltplan aufgebaut.

Könnte einer von euch, da ja mein Winavr wie auch AVR Studio zerschossen 
scheint, bitte mal die Datei kompellieren und dann hier Posten. Dann 
könnte man zumindest ausschließen ob es an der Entwicklungsumgebung 
liegt.

Maximilian A. schrieb:
> Es ist das gleiche wie vor dem Versionswechsel. Es blinkt 2 mal pro sec.

OK. Ich schieb das mal auf den libc Fehler zu dem Michael H. (übrigens 
danke dafür) einen Link gepostet hat.
Das die Timer Sache zum richtigen Ergebnis führt beruhigt mich dann 
zumindest soweit, dass ich der Sache wieder traue.

Maximilian A. schrieb:
> Bis auf die Widerstände am Rand und den Quarz ist sonst alles so wie im
> Schaltplan aufgebaut.

Ich meinte R7, 8, 9 bezüglich der Widerstände.

OK. Es reicht. Der Leidensdruck ist zu groß.
Das ist mir nämlich zu blöd, da jedesmal ins Zip-File reinschauen zu 
müssen.

Maximilian A. schrieb:
> Maximilian A. schrieb:
>> Bis auf die Widerstände am Rand und den Quarz ist sonst alles so wie im
>> Schaltplan aufgebaut.
>
> Ich meinte R7, 8, 9 bezüglich der Widerstände.

R7 hab ich im Schaltplan gefunden.
Wo sind R8 und R9?


WEnn du den Inverter nicht hast, dann musst du das Signal softwareseitig 
invertieren. ISt soweit vom Autor ja schon vorgesehen, einfach die 
jeweils anderen Anweisungen auskommentieren.

1

ISR (TIMER1_COMPA_vect)

2

{

3

  PORTB |= 0x08;

4

  // PORTB &= ~0x08;

5

  OCR1A = TCNT1 + 20000;   //20000 * 1MHz = 20ms

6

  OCR1B = TCNT1 + ServoPulse;

7

  //Enable OC

8

  //TIMSK |= _BV(OCIE1B);

9

}

10

11

//Turn off servo control pulse

12

ISR (TIMER1_COMPB_vect)

13

{

14

  PORTB &= ~0x08;       //PB3 is servo control

15

  // PORTB |= 0x08;

16

17

  //Disable OC

18

  //TIMSK &= ~(1<<OCIE1B);

19

}

Karl Heinz Buchegger schrieb:

>
> R7 hab ich im Schaltplan gefunden.
> Wo sind R8 und R9?

Hab sie gefunden.

Die kannst du doch nicht einfach weglassen!

Und wofür sind diese Widerstände da?

Maximilian A. schrieb:
> Und wofür sind diese Widerstände da?

Damit die Basis des dahinterliegenden PNP nicht in der Luft hängt, wenn 
der NPN (der ebenfalls ein Inverter ist) nicht durchgeschaltet hat. Oder 
hat der Autor einen Bugfix gegeben, dass diese R nicht zu bestücken 
sind?

Aber eins nach dem anderen. Was ist mit dem Servo? Klappt das jetzt?

Ja, er läuft jetzt. Zwar spigelverkehrt, aber das kann man mit der 
Software am Computer regeln.

Maximilian A. schrieb:
> Ja, er läuft jetzt. Zwar spigelverkehrt, aber das kann man mit der
> Software am Computer regeln.

Kannst du ja auch auf dem Tiny umdrehen

1

void SetServo(unsigned char input){

2

  unsigned short calc;

3

  calc = 2000 - 4*input;     // <---------

4

  ServoPulse = calc;

5

}

Vielen Dank für die Hilfe. Die erste Hälfte läuft läuft jetzt. Jetzt 
muss ich nur noch die Motorsteuerung mit der H-Brücke hinbekommen. Bis 
heute Abend bekomme ich noch passende Widerstände.
 Nochmals vielen Dank!!

Habe nun auch den Motor am laufen. Es war eins der Mosfets kaputt. 
Vielen Dank. Nun habe ich aber noch eine Frage: Wie kann ich den Strom 
auf 5-6A begrenzen?

Maximilian A. schrieb:
> Wie kann ich den Strom
> auf 5-6A begrenzen?

Shuntwiderstand unter die Lo-Side Mosfets machen und den Spannungsabfall 
daran messen. Der 2313 hat doch einen Analog-Komparator, oder?
Immer wenn der Strom über die von dir gesteckte Grenze geht, Brücke auf 
"Durchzug" schalten und beim nächsten PWM-Zyklus wieder aktivieren.

Das Ausschalten kann man Interruptgetrieben machen. Das Einschalten geht 
ja immer von allein wenn der Timer wieder einspringt und Anschaltet. 
Oder?

Geht natürlich nur bei Software-PWM. Ansonsten muss eben in der 
Interruptroutine fürs Auschhalten der PWM-Pin abgeschaltet werden und 
bei einem Timerüberlauf eben wieder an(der Overflow interrupt vector 
lässt sich auch erzwingen, woweit ich weiß).

mfg mf

Ich habe einen 1 Ohm 100W Widerstand, der müsste niederohmig genug sein. 
Und den hänge ich jetzt an den Motorausgang?

Maximilian A. schrieb:
> 1 Ohm 100W Widerstand

Von der Leistung kein Problem, aber vom Spannungsabfall:
U = R * I = 1Ω * 6A = 6V

Da musst du dir einen kleineren Widerstandswert hernehmen.
mfg mf

Maximilian A. schrieb:
> Und den hänge ich jetzt an den Motorausgang?

Nein, der kommt unter die Lo-Side MOSFETs zwischen Source un Masse, wie 
im angehängten Bild.

An I_mess kann man dann die Spannung über dem Shuntwiderstand abgreifen. 
Die Spannung ist proportional zum Strom. Für geringstmögliche Verluste 
sollte der Shunt nur so so klein wie möglich und für die Messgenauigkeit 
so groß wie nötig sein.

Ich sehe aber gerade, dass am Tiny die Analogkomparatoreingänge AIN0..1 
schon belegt sind. Da musst du dir eine andere Möglichkeit zum 
"reinholen" des Messwerts überlegen.

Möglich wäre eine geeignete Verstärkung des Signals an I_mess(Opamp). 
Das verstärkte Signal kann auf einen AD-Wandler gegeben werden, der z.B. 
mit an der SPI-Schnittstelle hängt(die ist ja im Moment nur zum brennen 
da).

Im Post vor 
dir(Beitrag "Re: Attiny2313 macht Probleme") 
hab ich einen Chopperbetrieb beschrieben.

Du kannst nun, da mit AD-Wandler quasikontinuierliche Werte vorliegen, 
eine echte Strom(ab)regelung realisieren.

mfg mf

PS: Warum ist an "Servo3.3" zur Basis des Transistors Q4 kein Widerstand 
dran? Benutzt du den internen Pullup als Vorwiderstand?

Mini Float schrieb:
> Von der Leistung kein Problem, aber vom Spannungsabfall:
> U = R * I = 1Ω * 6A = 6V
>
> Da musst du dir einen kleineren Widerstandswert hernehmen.
> mfg mf

So, bis hierher komme ich mit. Ich brauchen einen kleineren Widerstand, 
da sonst der Attiny abraucht. 0,5Ohm müssten also passen, da dann die 
Spannung gering genug ist. Beim Rest komme ich aber nicht mehr mit

Der Strom wird durch deinen Widerstand begrenzt, das stell ich außer 
Frage.
aaaaaber
Eine "Strombegrenzung" im klassischen Sinne ist eine ab einem gewissen 
Schwellwert einsetzende Begrenzung. Die Kennlinie von I-Sollwert zu 
I-Istwert sieht dann so aus:

1

 Ist

2

  ^

3

8 |      .

4

7 |      .----------

5

6 |     /.

6

5 |    / .

7

4 |   /  .

8

3 |  /   .

9

2 | /    .

10

1 |/     .

11

0 +------+----------> Soll

12

  0      7

Bei deinem Widerstand wird auch schon bei kleineren Strömen 
unnötigerweise Energie verheizt. Das Muss nicht sein, zumal in deiner 
Schaltung mit der PWM die Leistung des Motors über den Strom gesteuert 
werden kann.

mfg mf

Und was soll ich statt dessen tun?

Eine echte Regelung einbauen? Naja, wenn dir das recht ist mit dem 
Widerstand dann lass es so. Gute Nacht.

Jetzt habe ich definitiv keine Ahnung mehr was gemeint ist.

Könnte jemand vielleicht eine Schritt für Schrittanleitung schreiben? 
Soetwas würde mir enorm helfen. Bei den verschiedenen Möglcihkeiten quer 
durcheinandergewürfelt komm ich selbst unter großen Bemühungen nicht mit