Kombination UART / TIMER

wie überprüft ihr z.b. adc werte? via UART? oder gibt es noch bessere 
möglichkeiten sich die werte anzuzeigen?

@  Sven Weinmann (sickone4)

>    * Problem.txt (3,7 KB, 16 Downloads)

Warum postest du nicht einfach deinen C-Quelltext als .c Datei? Hat u.a. 
den Vorteil, dass die mit Syntax highlighting angezeigt wird.

>1. gibt es irgend einen Grund, warum ich den Quellcode eines
>funktionsfähigen Timers ( von Karl Heinz Buchegger korrigiert und für
>gut befunden) und die UART Routine von myAVR, welche auch voll
>funktionsfähig ist nicht kombinierbar sind?

Eigentlich nicht.

>Mit dem Timer erzeuge ich mir einen Takt für meinen Schrittmotor, mit
>dem UART möchte ich die Position überwachen,

???
Wie soll ein UART eine Position überwachen?

> welche ich durch eine ADC und einen POTI erfasse.

Dazu braucht man ber keinen UART.

>ADC Quellcode ist mehr oder weniger aus dem Tutorial (mehrfach ADC) und
>funktioniert in diversen Quellcodes auch einwandfrei.

>nur kombiniert funktioniert die Ausgabe, aber nicht der TIMER....

Naja, einfach planlos was zusammenkopieren führt selten zum Ziel.

1

  while(1)  // Endlosschleife

2

  {

3

4

    if (bit_is_clear(PINC,4))

5

      {

6

        cli();

7

        Schritte = 100;      // Motor Schritte = Schritte/2

8

        _delay_ms( 200 );

9

        sei();

10

      }

11

12

    print("Hallo myAVR! \n ");

13

14

  }  // Ende while(1)

15

}  // Ende main

AUA! _delay_ms von 200ms UND dabei gesperrte Interrupt? Das kann nicht 
gut gehen. Siehe Interrupt.

>2. gibt es eine Alternative zu dem Delay: _delay_ms(200) ?

Sicher. Dein Timer. Siehe Multitasking.

>Der Delay
>unterbricht ja meinen Timer für 200ms und im späteren Gebrauch wäre es
>sinnvoll, wenn der Timer trotzdem normal weiterliefe.

Eben.

@Sven Weinmann (sickone4)

>wie überprüft ihr z.b. adc werte? via UART?

Du meinst das Debugging? Ja, UART ist eine recht gute Möglichkeit.

> oder gibt es noch bessere
> möglichkeiten sich die werte anzuzeigen?

LCD, Ablegen im SRAM und per Debugger anschauen.

Sven Weinmann schrieb:
> Der Delay
> unterbricht ja meinen Timer für 200ms

Nö, tut er nicht. Die Delay Routine wird vom Timerinterrupt ebenso 
unterbrochen wie andere Programmteile auch. Nur das laufende 
(Haupt-)Programm wird für die 200 mS lahmgelegt. Du musst natürlich 
(sei) und (cli) vermeiden, ist hier aber eh unnötig.

Mach doch den Anhang bitte nicht als txt sondern als *.c, dann öffnet 
sich bei mir der richtige Editor.

hallo Leute,

ich dachte, dass das was ich meinte irgendwie klar wäre :) sorry -.-


ich möchte hier im beispiel mit einem taster  meinen schrittmotor 
X-Schritte fahren lassen. (funktioniert)

gleichzeitig habe ich mit einem getriebe einen poti mitgeschaltet, 
welcher mit einer ADC erfasst wird mit 10bit Auflösung 0-1023 Schritte 
ausgibt (funktioniert)

So kann ich die Position des Schlittens, welcher vom Schrittmotor 
angetrieben wird überwachen.

Um zu testen, wie groß meine Schrittweite ist möchte ich die ADC 
ausgegeben bekommen, damit ich weiß, wie weit sie die ADC verändert wenn 
ich zum beispiel 100 schritte fahre.

in kombination beider sachen funktioniert aber der timer nicht.

im beispielscript habe ich eine funktionsfähige UART Sendefunktion 
benutzt um euch zu zeigen, dass es kein fehler ist den ich gemacht habe.


was das delay angeht, so unterbricht das auch den timer!
wenn ich das delay weglasse, so wird der port nicht mit x- schritten 
getaktet sondern unendlich und hört nicht mehr auf. warum das so ist 
verstehe ich auch nicht.

EDIT

Im Beispiel der UART wird natürlich nicht die ADC ausgegeben sonder der 
Text Hallo myAVR diesen durch den ADC wert zu ersetzen ist kein problem 
und funktioniert auch, dennoch ist das kernproblem ja die kombination 
aus UART und TIMER

Platform:
Atmel Studio 6.0
Atmega 8

Sven Weinmann schrieb:

> getaktet sondern unendlich und hört nicht mehr auf. warum das so ist
> verstehe ich auch nicht.

das ist das eigentliche Problem.

Ich glaube ich hatte dir das schon mal gesagt:
Ohne funktionsfähige Tasten-Drück / Entprellroutine kommst du mit deinem 
Taster nicht mehr weiter.

Logisch Taktet dein Schrittmotor ständig weiter. Denn dein PINC/PC4 ist 
ja dauernd gedrückt. Und solange der gedrckt ist, wird die Anzahl der 
Schritte dauernd immer wieder auf 100 gesetzt. So schnell kann der Timer 
die gar nicht runterzählen, wie in der Hauptschleife bei gedrücktem 
Taster immer wieder alles auf 100 zurückgesetzt wird.


Falk hat schon ein wahres Wort gesprochen: Du kopierst Dinge zusammen 
ohne sie zu verstehen oder auch nur den Versuch zu machen sie zu 
verstehen. In der Programmierung geht das dann eben schief.

Den Delay hab ich in der Vorlage die ich dir gegeben habe, nur deswegen 
eingefügt, damit da ein wenig Zeit vergeht und der der µC Däumchen dreht 
und mittels Timer seine 100 Schritte machen kann, ohne dass ich dafür 
eine großartig komplizierte Steuerung brauche. Denn das Hauptaugenmerk 
lag auf der Fragestellung "Wie erzeugt man 100 Steps" und nicht "Wie 
programmiere ich Svens Programm"

bitte versteh mich nicht falsch, ich drücke den taster 1x und hab nicht 
den finger drauf! es ist ein taster, kein rast-schalter.

d.h. es kann ja zu "flattern" kommen das toleriere ich ja, das sagte ich 
dir auch, da es nur zum testen ist.
aber trotzdem muss nach meinem verständnis diese 100 irgendwann mal 
ablaufen.
wenn ich 1x drücke kann ja von miraus im schaltmoment oder wenn der 
taster sich löst noch x milli sekunden der wert immer wieder 100 sein, 
aber spätestens nach der letzten möglichen flanke sollten die 100 doch 
ablaufen.

wenn aber nach 5 min immernoch keine änderung aufgetreten ist, dann ist 
das kein flattern mehr

@  Sven Weinmann (sickone4)

>ich dachte, dass das was ich meinte irgendwie klar wäre :) sorry -.-

Das "denken" alle, die noch nicht über das Thema Netiquette gelesen 
haben.

>ich möchte hier im beispiel mit einem taster  meinen schrittmotor
>X-Schritte fahren lassen. (funktioniert)

Mit welchem Programm?

>So kann ich die Position des Schlittens, welcher vom Schrittmotor
>angetrieben wird überwachen.

Ja. Wenn gleich die Auflösung und Genauigkeit auf einem anderen Blatt 
steht.

>in kombination beider sachen funktioniert aber der timer nicht.

Kaum. Poste dein Originalquelltext als Anhang.

>im beispielscript habe ich eine funktionsfähige UART Sendefunktion

Was sollen wir mit dem Beispiel?

>benutzt um euch zu zeigen, dass es kein fehler ist den ich gemacht habe.

;-)
99% aller Programmfehler sind vom Programmierer. Erst recht bei 
Anfängern, da sind es gefühlt 110%.

>was das delay angeht, so unterbricht das auch den timer!

Eben, und genau DAS ist Unsinn. Da kann man sich den Timer sparen.

>wenn ich das delay weglasse, so wird der port nicht mit x- schritten
>getaktet sondern unendlich und hört nicht mehr auf. warum das so ist
>verstehe ich auch nicht.

Ich schon. Du brauchst eine Ablaufsteuerung per statemachine.

>und funktioniert auch, dennoch ist das kernproblem ja die kombination
>aus UART und TIMER

Das ist kein Problem.

Sven Weinmann schrieb:

> wenn aber nach 5 min immernoch keine änderung aufgetreten ist, dann ist
> das kein flattern mehr


Dann mach dir halt da

1

    if (bit_is_clear(PINC,4))

2

      {

mal eine Ausgabe rein um nachzusehen, ob du den Pin auch nach Loslassen 
des Tasters immer noch als 0 einliest oder nicht.
WEnn die Schritte nicht zurückgesetzt werden, dann müssen die irgendwann 
mal auf 0 herunten sein.

In deinem Testprogramm gibt es nach loslassen des Tasters keinen Grund, 
warum da laufend weiterhin SChritte erzeugt werden sollten. Selbst dann, 
wenn man den delay rausnimmt (was ja auch so sein sollte).

Und das nächste mal bitte eine ordentliche Fehlerbeschreibung.
'Funktioniert nicht' ist keine Fehlerbeschreibung.

"Ich drcke den Taster und nach dem Loslassen taktet der die ganze Zeit 
weiter" wäre eine Fehlerbeschreibung mit der man was anfangen kann.

Und zeig dein richtiges Programm. Es ist schön, wenn du im Text 
beschreibst, dass du mit dem ADC arbeiten willst. Wenn aber im ganzen 
Programm kein ADC vorkommt, dann interessiert das hier auch weiter 
keinen.

funktioniert = aufspielen des UART ohne den Timer -> Ausgabe Fehlerfrei
funktioniert = aufspielen des TIMERS ohne die UART -> TIMER taktet 
Fehlerfrei

funktioniert nicht = aufspielen des kombinierten Quellcodes -> Timer 
taktet nicht UART funktioniert noch immer Fehlerfrei!

TEST: auskommentieren der Zeile ->

1

print("Hallo myAVR! \n ");

RESULTAT: TIMER taktet wieder Fehlerfrei

deshalb die aussage beides zusammen funktioniert nicht. Keine weiteren 
Fehler aufgetreten.

die von mir genutzte nicht beispielhaft genutze UART ROUTINE sieht 
übrigends wie folgt aus:

1

  uint16_t position_Y;               // Variable für Y-Position ADC  

2

  char puffer[10];                   // Deklaration des Sendepuffers

3

4

5

void sende (char buffer[])           // Funktionsaufruf

6

{                                    // zum Übermitteln einer Zeichenfolge

7

   for (int i=0; buffer[i]!=0; i++)  // For-Schleife: Abbruch wenn Zeichenfolge

8

   {                                 // zu Ende ist, sonst "i" inkrementieren

9

      while (bit_is_clear(UCSRA,5))  // Solange Zeichen noch nicht vollständig...

10

        {  ;      }                  // ...übermittelt wurde, tue nichts! (warte)

11

      UDR=buffer[i];                 // Danach: Sende aktuelles ("i"-tes) Zeichen

12

   }

13

}

14

15

16

int main { 

17

  UBRRL = 23;                        // Quarz: 3.6864MHz, Baudrate 9600

18

  UCSRB = 0b10011000;                // Empfänger, Sender ein UCR = UCSRB

19

20

....

21

22

   sprintf (puffer, "Position: %d  \n", position_Y);

23

   sende (puffer);

24

25

... }

das nun nur die UART, welche ich benutze. Im Beispielcode hab ich eine 
genutzt (zusammenkopiert, welche auch 100% funktioniert. Die die ich 
nutze haben wir in der Schule programmiert und funktioniert auch)

so nachgereicht der quellcode den ich nutze.

gruß sven

1

char puffer[10];            // Deklaration des Sendepuffers

2

3

...

4

5

    sprintf (puffer, "Position: %d  \n", position_Y);

zähl mal nach, wieviele Buchstaben du in puffer schreibst :-)
Reicht da eine Arraygröße von 10?

Und da die Variable 'steps' dahinter im Speicher liegt, bügelst du dir 
hier den Speicher nieder und überschreibst dir steps laufend mit Werten 
ungleich 0.

Und genau deshalb ist es wichtig, dass du GENAU das Programm postest, 
welches du auch testest. Nicht irgendwas fürs Forum zurecht gemachtes, 
sondern exakt das Programm!

Danke für den Hinweis, aber was meinst du mit:
> Und da die Variable 'steps' dahinter im Speicher liegt,
?

Wieso liegt die dahinter? Was hat denn mein steps mit dem char zutun?

@  Sven Weinmann (sickone4)

>> Und da die Variable 'steps' dahinter im Speicher liegt,

>Wieso liegt die dahinter?

Weil der Cpompiler die Variablen einfach nacheinander in den Speicher 
platziert.

>Was hat denn mein steps mit dem char zutun?

Sie sind Nachbarn, im Speicher. Und wenn du in deinen 10 Byte String 
mehr als 10 Zeichen reinschreibst, werden die nachfolgenden 
Speicherzellen, die nicht mehr zum String gehören, überschrieben. 
Klassischer Pufferüberlauf. Es gibt keinen Programmierer, dem sowas noch 
nie passiert ist. ;-)

Sven Weinmann schrieb:
> Danke für den Hinweis, aber was meinst du mit:
>> Und da die Variable 'steps' dahinter im Speicher liegt,
> ?
>
> Wieso liegt die dahinter? Was hat denn mein steps mit dem char zutun?

1

uint16_t position_Y;          // Variable für Y-Position      

2

char puffer[10];            // Deklaration des Sendepuffers

3

volatile uint16_t steps;

irgendwie muss ja der Compiler die Variablen im speicher anordnen. Und 
der macht das nicht wahllos, sondern in der Reihenfolge in der du die 
Variablen anführst. Und er lässt auch keinen Platz dazwischen, sondern 
legt die Variablen nacheinander in dern Speicher.

Hat position_Y die Speicheradresse 100 und ist 2 Bytes groß, dann 
beginnt die Variable puffer an der Adresse 102. Und da das Array 10 
Bytes groß ist, kommt daher die Variable steps an der Speicheradresse 
112 zu liegen.

Schreibst du daher in puffer etwas rein, was mehr als 10 Bytes 
beansprucht, dann überschreibst du damit auch das Byte an der 
Speicheradresse 112. Dort liegt aber die Variable 'steps'. Ergo: mit dem 
sprintf hast du zwar in puffer einen String reingeschrieben, du hast 
aber auch steps verändert. Unabsichtlich zwar, aber du hast es 
verändert.

Ok das macht Sinn und das kenne ich auch von der SPS, wobei das dort 
z.b. im Datenbaustein sofort sichtbar ist! Da stehen die Adressen auch 
direkt daneben!

Was mir nun durch den Kopf geht ist folgendes:

erste Möglichkeit -> Char als letztes deklarieren, sodass platz für 
einen Überlauf wäre.

zweite Möglichkeit -> Wissen, wie groß der Char genau sein muss! Maximal 
kann der 256 Byte groß sein. Aber ihn so zu deklarieren ist auch 
quatsch.

Ist es beim µC auch so, dass er nicht 254 sondern 254 Byte Groß ist und 
die ersten zwei Byte für die Größe zuständig sind?

Sven Weinmann schrieb:
> Ok das macht Sinn und das kenne ich auch von der SPS, wobei das dort
> z.b. im Datenbaustein sofort sichtbar ist!

C ist nun mal nichts für Programmierer, mit denen die Tante Lulu ....


> erste Möglichkeit -> Char als letztes deklarieren, sodass platz für
> einen Überlauf wäre.

Nein.

> zweite Möglichkeit -> Wissen, wie groß der Char genau sein muss! Maximal
> kann der 256 Byte groß sein. Aber ihn so zu deklarieren ist auch
> quatsch.

Schätzen!
gezielt schätzen!

Für die Ausgabe von
Position:
mit einer Zahl dazu und einem Newline brauchst du keine 256 Zeichen, mit 
30 oder 40 bist du auf der sicheren Seite, selbst dann wenn du den Text 
später mal auf "Position Schlitten %d\n" erweiterst.

* Möglichkeit 3
Den AUfteilen in zb die konstanten Teile und die Zahl. Und da ein int 
nur bis 65535 gehen kann, weißt du, dass du dafür nicht mehr als 5+1 
Zeichen brauchen wirst.

> Ist es beim µC auch so, dass er nicht 254 sondern 254 Byte Groß ist und
> die ersten zwei Byte für die Größe zuständig sind?

Nein.
Sagte ich eigentlich schon mal, dass du ohne C-Buch nicht weit kommen 
wirst? Strings sind die erste große Hürde in C. Da warten noch viele 
weitere.

ich hab das nun geändert auf 40, aber ich es hat sich nichts geändert. 
der timer läuft nach wievor nicht beim aufspielen. ABER!

wenn ich nun das controlcenter starte UND verbinde, so startet der timer 
und auch das restliche programm funktioniert.

woran kann denn sowas nun liegen?

Sven Weinmann schrieb:
> ich hab das nun geändert auf 40, aber ich es hat sich nichts geändert.
> der timer läuft nach wievor nicht beim aufspielen. ABER!

Dann muss man eben weiter suchen.
Das war ja auch nur der erste Fehler. Sagt ja keiner, dass es nicht noch 
mehr gibt.

> wenn ich nun das controlcenter

Wer oder was ist das Controlcenter?

Das Control Center ist ein kleines Programm von myAVR
->
http://shop.myavr.de/index.php?ws=download_file.ws.php&dlid=263&filename=software/tool_ControlCenter_V200-b866_de.zip

einfach entpacken und starten. Ich hab keine Ahnung, welche Programme 
ihr benutzt für die Kommunikation zw µC und dem PC. Ich nutze Win7 64bit 
und das Programm läuft da drauf!

Sven Weinmann schrieb:

> einfach entpacken und starten. Ich hab keine Ahnung, welche Programme
> ihr benutzt für die Kommunikation zw µC und dem PC.

Ich starte dazu ein ganz gewöhliches Terminalprogramm.
Entweder Hyperterminal oder hTerm

Hyyperterminal kann Win7 leider nichtmehr und mit hTerm wurde ich nicht 
richtig warm... mal hat es Verbinden mal nicht. ControlCenter kannste ja 
mal ausprobieren. Für reine Textausgaben ist das eigentlich wunderbar. 
Da würde es meiner meinung nach mehr dem Hyperterminal gleichen.

ich habe gerade festgestellt, dass das programm, welches ich in den µC 
aufgespielt habe dann läuft, sobald ich im datenmodus bin.

bei hTerm benötige ich zumindest noch eine Zusatzsoftware, um in den 
Datenmodus umzuschalten, dabei ist mir das aufgefallen

kleine korrektur! falls es nicht aufgefallen ist. die zeite ADC_Init(); 
fehlt im main cycle! hab ich korrigiert

Langsam fange ich an zu Zweifeln....
Ich benutze einen USB-Programmer der verschiedene Modi zur Verfügung 
stellt.
Um z.b. UART zu nutzen muss man eben diesen Programmer in den Datenmodus 
umschalten. Das geht entweder vom Programm selbst oder man schaltet 
diesen manuell um.

Das Programm ControlCenter welches ich oben verlinkt hab macht das 
automatisch, hTerm macht das nicht automatisch.

Sven Weinmann schrieb:
> Langsam fange ich an zu Zweifeln....
> Ich benutze einen USB-Programmer der verschiedene Modi zur Verfügung
> stellt.

Tja. Den benutzt aber ausser dir keiner hier.
Daher sagt uns das alles nichts, was du da erzählst.

Wir brennen unsere Programme in den µC, der Brenner resettet den µC und 
danach lässt der Brenner die µC-Hardware wieder in Ruhe. Und dann läuft 
der auch ohne, dass man irgendwelche Modi ein-\aus-\umstellen muss.
Und wenn der µC  etwas auf der USART ausgibt, dann gibt der das einfach 
aus. Dem ist das nämlich völlig wurscht, ob da wer zuhört oder nicht.

ok und wie verbindet ihr den Käfer dann mit dem PC? Keinen Programmer 
dazwischen?

Sven Weinmann schrieb:
> ok und wie verbindet ihr den Käfer dann mit dem PC? Keinen Programmer
> dazwischen?

Selbstverständlich ist da auch ein Brenner.
Aber der hat keine Daten oder was weiß ich für welche Modi.

Brenner brennt das Programm rein - Brenner zieht sich elektrisch wieder 
vom der µC-Schaltung zurück - µC läuft.

langsam....

ich hab einen USB Programmer, welcher einen USB Anschluss hat, durch 
welchen ich mein Programm vom PC via Programmer auf den Chip Brennen 
kann. Auf gleichem Weg wird auch kommuniziert. Es würde mich sehr stark 
wundern, wenn dein Chip mit deinem Terminal übers Telefon kommuniziert.

Wie der Programmer nun auch immer aussieht das ist meiner ->
http://shop.myavr.de/Programmer%20und%20Bridges/mySmartUSB%20MK2%20%28Programmer%20und%20Bridge%29.htm?sp=article.sp.php&artID=42

vielleicht kann man sich dann damit mehr vorstellen. diese Platine sitzt 
auf einer weiteren ->

http://shop.myavr.de/Systemboards/myAVR%20Board%20MK2,%20best%C3%BCckt.htm?sp=article.sp.php&artID=40

und eben dieses Board "musste" man sich als ich die Schule begann 
kaufen.

Eine alternative, welche ich noch habe zu dem Systemboard ist ein Kabel, 
mit welchem ich von dem Programmer via Wannenstecker und Flachkabel 
direkt auf ein Breadboard an einen µC gehen kann. Dies ersetzt jedoch 
nur die Platine.

@  Sven Weinmann (sickone4)

>ich hab das nun geändert auf 40, aber ich es hat sich nichts geändert.

Logisch.

>der timer läuft nach wievor nicht beim aufspielen. ABER!

Ein Band spielt beim Oktoberfest auf. Mit Mikrocontrollern hat das nix 
zu tun. Die werden programmiert oder gebrannt.

>woran kann denn sowas nun liegen?

Willkommen bei der Fehlersuche.

Dein Programm hat wie bereits gesagt noch diverse grundlegende Fehler.

1.) Du musst deine Taster entprellen, das macht man einfach mit deinem 
1ms Timer und Entprellung per Software.

2.) Du musst den Flankenwechsel von "Taste nicht gedrückt" zu "Taste 
gedrückt" erkennen und nur DANN deinen Schrittzähler auf 100 setzen.

Versuchs mal mit dem Programm im Anhang.

Sven Weinmann schrieb:
> langsam....
>
> ich hab einen USB Programmer, welcher einen USB Anschluss hat, durch
> welchen ich mein Programm vom PC via Programmer auf den Chip Brennen
> kann. Auf gleichem Weg wird auch kommuniziert. Es würde mich sehr stark
> wundern, wenn dein Chip mit deinem Terminal übers Telefon kommuniziert.

Ich 'kommuniziere' überhaupt nicht über den Brenner.
Mein Brenner brennt Programme in den µC. Drumm heißt er Brenner.
Und ansonsten hält er sich aus allem raus, was mit dem µC zu tun hat.
Und das ist auch gut so.

Wahrscheinlich hat er einn Bootloader drauf, ohne das so zu wissen.

OK dann tu ich das mal. Und leider hast du auch ein Stückweit recht. Ich 
habe am 21 Januar jedoch Projektbesprechunng und außer ner Menge 
Problemen kann ich nichts vorweisen....

Platform: Win 7 64bit
Programme: Atmel Studio 6.0
           hTerm od. Control Center (link gepostet)
           ProgTool zum Brennen des Programmes

Chip: Atmega8
Systemboard: Board MK2 -> 
http://shop.myavr.de/Systemboards/myAVR%20Board%20MK2,%20best%C3%BCckt.htm?sp=article.sp.php&artID=40

Bestückt mit der Bridge/Programmer

an das Board habe ich auf einem Breadboard eine Schaltung zur 
Schrittmotorsteuerung aufgebaut und einen Schrittmotor daran 
angeschlossen.

der Schrittmotor ist in einem Aluprofil eingebaut in welches ich ein 
Getriebe gebaut habe an welchem sich zur Positionsermittlung ein 
10stufiges Poti befindet. Dieses habe ich an den ADC Kanal 1 am Board 
angeschlossen. Am Board ist dies Pin C1 welcher ja laut Datenblatt vom 
Atmega8 einfach nur herausgeführt wurde auf einen Stiftsockel.



@Falk: Dein Quellcode in allen Ehren, aber das Resultat ist exakt das 
gleiche. Sobald ich "kommunizieren" will startet das Programm auf dem 
Chip. Starte ich nicht läuft da auch nichts ab.

und ja das teil hat einen Bootloader

@  Sven Weinmann (sickone4)

>ich hab einen USB Programmer, welcher einen USB Anschluss hat,

Der hat einen Namen und wahrscheinlich auch ein Datenblatt. Ein Link 
darauf wo diu ihn gekauft hast wäre auch gut. Siehe [[Netiquette].

>durch
>welchen ich mein Programm vom PC via Programmer auf den Chip Brennen
>kann. Auf gleichem Weg wird auch kommuniziert.

Das klingt nach Bootloader.

> Es würde mich sehr stark
>wundern, wenn dein Chip mit deinem Terminal übers Telefon kommuniziert.

Die coolen Sprüche solltest du dennen überlassen, die es drauf haben.

>Wie der Programmer nun auch immer aussieht das ist meiner ->
>http://shop.myavr.de/Programmer%20und%20Bridges/my...

Das ist so ein Multifunktionsadapter, der kann sowohl programmieren als 
auch kommunizieren.

>Eine alternative, welche ich noch habe zu dem Systemboard ist ein Kabel,
>mit welchem ich von dem Programmer via Wannenstecker und Flachkabel
>direkt auf ein Breadboard an einen µC gehen kann.

Das hat den Vorteil, dass Programmierung und Kommunikation getrennt sind 
und man nicht immer umschalten muss. Ist für sich vielleicht besser.

> Sobald ich "kommunizieren" will startet das Programm auf dem
> Chip. Starte ich nicht läuft da auch nichts ab.

Dann musst du rausfinden, was dieses ControlCenter bzw. dein Brenner da 
eigentlich veranstaltet. Die Antwort findest du aber nicht hier im Forum 
sondern in der myAVR Doku (oder bei jemandem, der auch diese 
Konfiguration benutzt).
Für mich sieht das momentan so aus, als ob dein Brenner den µC im Reset 
hält, solange bis er vom PC das Go bekommt. Das ist jetzt aber nur 
geraten und keineswegs eine Diagnose.

@  Sven Weinmann (sickone4)

>@Falk: Dein Quellcode in allen Ehren, aber das Resultat ist exakt das
>gleiche. Sobald ich "kommunizieren" will startet das Programm auf dem
>Chip.

Was soll es denn sonst machen!

> Starte ich nicht läuft da auch nichts ab.

Welch Überraschung! Mann O Mann!

Das Programm spuckt dauernd den ADC-Wert über Terminal aus. Wenn du die 
Taste drückst, sollte die Steuerung 100 Schritte machen.

Falk Brunner schrieb:
> Der hat einen Namen und wahrscheinlich auch ein Datenblatt. Ein Link
> darauf wo diu ihn gekauft hast wäre auch gut. Siehe [[Netiquette].

Das hatte ich bereits getan...

Falk Brunner schrieb:

> Das Programm spuckt dauernd den ADC-Wert über Terminal aus.

Genau das tut es ja bei ihm laut Fehlerbeschreibung erst mal nicht.
Die ganze Sache kommt erst dann ins laufen, wenn am PC in irgendwelche 
Datenmodi umgeschaltet wird.

Ob jetzt Bootloader oder Reset vom Brenner .... keine blasse Ahnung.
Und um ehrlich zu sein, ist es mir auch ziemlich ega..... Das Verhalten 
hat auf jeden Fall nichts mehr mit dem Programm zu tun sondern fällt 
unter die Kategorie "Kenne deine Entwicklungsumgebung".

welche Programmer benutzt ihr denn so, vielleicht sollte ich mri da 
einen anderen zulegen!

Ich finde die Datenblätter auf der Seite sehr undurchsichtig. Ich werde 
mich an deren Support wenden und dies erfragen.



Wenn ihr über eine andere Art und weise Kommuniziert also Sendet oder 
Empfangt wie macht ihr das? mit einer anderen Platine?

Sven Weinmann schrieb:
> welche Programmer benutzt ihr denn so, vielleicht sollte ich mri da
> einen anderen zulegen!
>
> Ich finde die Datenblätter auf der Seite sehr undurchsichtig. Ich werde
> mich an deren Support wenden und dies erfragen.
>
>
>
> Wenn ihr über eine andere Art und weise Kommuniziert also Sendet oder
> Empfangt wie macht ihr das? mit einer anderen Platine?

Der Brenner steckt am ISP Stecker
und von der UART geht ein anderes Kabel zum PC (mit einem FT232, der die 
USART/USB Umsetzung macht).

Das sind 2 voneinander getrennte Dinge. Der Brenner wird nur dann aktiv, 
wenn er tatsächlich was brennen soll. Ist das erledigt, dann schaltet er 
sich wieder weg, so als ob er nicht am µC angesteckt wäre.

Aber das soll ja jetzt keine Ausrede für dich sein.
Du weißt, was du tun musst, damit dein Programm anläuft und das ist 
schon mal die halbe Miete.

Weiter gehts mit der Programmentwicklung!
AUch im Hinblick darauf, dass deine Projektbesprechung schon in Bälde 
stattfindet.

Das zieht sich nämlich sowieso schon zu lange hin, wenn ich bedenke, 
dass die Frage nach der Kontrolle über die Steps Ende September gepostet 
wurde und du noch nicht mehr hast als das bischen zusammenkopierten 
Code.

anbei die beiden Bilder. Zum Versuchsaufbau.

Es existiert ein weiterer Alublock mit nahezu gleichem Aufbau, welcher 
jedoch mit einen einfachen DCMotor bestückt ist. Dies ist jedoch nicht 
im Quellcode enthalten derzeit, da ich mich hier speziell auf den 
Schrittmotor konzentriert habe!

Der DCMotor soll durch einen PI-Regler geregelt werden, dies ist eine 
andere Baustelle.

Naja, das Problem ist halt der Multifunktionsadapter, den kann man per 
Software zwischen Programmieradapter und UART-USB Adapter umschalten. 
Das wird aber beim Testen reichlich nervig. Da du ja anscheinen ZWEI 
Programmieradapter hast (einer ist beim myAVR Board MK2 dabei, einen 
hast du einzeln gekauft, richtig?), ist es SEHR empfehlenswert, einen 
davon als einfachen ISP-Programmieradapter zu nutzen (mit dem 10pol) 
Flachbandkabel und den anderen als UART-USB Adapter. Dann muss man nicht 
immer umschalten.

DAS musst du erstmal hinkriegen. Programmieren und UART-Anzeige, dazu 
reicht es "Hello World" dauerhaft zu senden.

nein ich habe nur einen, den, der auf dem Board ist. Ich hab nur den 
Link zu dem Programmer gepostet, da das Systemboard prinzipiell nichts 
anderes ist als das Breadboard. Die ISP Kontakte des Programmers sind 
auf dem Board zum µC geführt.

Ob ich nun ein Kabel nutze zum Breadboard oder die Platine, auf der das 
schon fertig ist, ist im Prinzip egal.

Frohes Neues zusammen!

@Falk:
Bei deiner Datei mit dem Script von PeDa hab ich ein Problem.

Derzeit nutze ich ja einen Taster für das Setzen der Schritte.
Dies soll allerdings später nichtmehr der Fall sein. Später wird die 
Flanke durch das Erreichen eines Bereiches erfasst.

D.h. der DC-Motor fährt zum Endschalter in eine Richtung und dann soll 
der Schrittmotor sich drehen.

Um aber Schäden vorzubeugen habe ich dem Endschalter keinen Wert sondern 
einen Bereich zugewiesen.

Das PeDa Script allerdings wertet eben nur den Taster aus. Macht es da 
überhaupt Sinn mit einer Entprellung zu arbeiten? Oder ist es nicht 
sinnvoller dann einfach ein flag zu setzen und nach dem die Schritte 
gefahren wurden UND der Bereich wieder verlassen wurde dieses wieder zu 
löschen?

@  Sven Weinmann (sickone4)

>Bei deiner Datei mit dem Script von PeDa hab ich ein Problem.

Script? Das ist ein Makro. Erfinde keine neuen Namen für bestehende 
Dinge, sonst versteht dich keiner.

Du hast noch viel mehr Probleme. Du beherrscht nicht mal das kleine 1x1, 
willst aber morgen die Fields-Medaillie gewinnen.

http://de.wikipedia.org/wiki/Fields-Medaille

Das klapppt nicht!

Erstmal musst du die Grundlagen verstehen und erfolgreich umstetzen. 
D.h. hier konkret.

1.) Programmierung und Kommunikation mit deinem AVR.

Dieser Multifunktionsadapter wird dich nicht glücklich machen fürchte 
ich. Denn beim Umschalten zwischen Programmiermodus und 
Kommunikationsmodus musst du wahrscheinlich in deinem Terminalprogramm 
immer wieder eine neue Verbindung aktivieren, weil der Treiber 
zwischendurch "weggeschaltet" wird.

Mein Tipp. Besorg dir einen 2. Adapter und nutze dann einen nur zum 
Programmieren und einen nur zum Kommunizieren.

Dann musst du sauber und problemlos Daten vom AVR empfangen können bzw. 
an ihn senden.

2.) Entprellung und Flankenauswertung des Tasters.

Dann musst du schrittweise dein Programm erweitern. Möglicht nicht mit 
zusammenkopierten Quelltextfragmenten, sondern mit selbstgeschriebenen, 
verstandenen Funktionen. Das ist auch der Sinn von Schulprojekten. 
Verstehen, nicht kopieren.

Viel Erfolg.

ich fange echt an an mir zu zweifeln....

ich hab dir eine frage gestellt und du erzählst mir etwas völlig 
anderes....

ich will weder etwas über medallien noch möchte ich das thema von 
gestern erneut aufgreifen.
wir haben festgestellt, dass der programmer den ich nutze nicht das 
gelbe vom ei ist und ich mir auf kurz oder lang alternativen suchen 
sollte. gleichzeitig hab ich auch eine email an den support gesendet und 
dort nachgefragt bezüglich des programmers.

aber meine frage hat nun leider nichts mit deiner antwort zutun....

@  Sven Weinmann (sickone4)

>aber meine frage hat nun leider nichts mit deiner antwort zutun....

Deine Frage kann man diskutieren, wenn die die nötigen Grundlagen 
geschaffen hast. Alles andere ist nur heiße Luft. Eine weitere 
Baustelle, die du möglichst schnell grundlegen bearbeiten solltest, ist 
dein Versuchsaufbau. Steckbrett ist so lala, aber die vielen fliegenden 
Verbindungen werden dir viele Wackelkontakte und Probleme bereiten. Die 
muss man erstmal solide machen, sprich ordentlich Verbindungen schaffen.

Ausserdem kann sich bei deinen Infromationsfragmenten kein Mensch deinen 
realen Aufbau vorstellen. Ein gescheite Skizze inklusive Beschreibeung 
wäre dringend nötig, siehe Netiquette.

werde dir gerne eine Skizze liefern. Wenn ich dafür Zeit finde.

-> Netiquette
>  Tonfall und Inhalt sollten dem Zielpublikum gegenüber angemessen sein

Ich frage mich bei deinen Aussagen ob du das wirklich einhälst...
Ich bin weder ein Depp noch bin ich Dumm. Ich hab ein Schwachkopf als 
Lehrer, der Kopieren vor Kapieren schiebt. Das ist mein Problem. Und wie 
soll man innerhalb eines halben Jahres C lernen wenn man im Unterricht 
nichts als kopieren lernt?

Ich mache dir keinen Vorwurf damit, das ist alleine das Problem des 
Lehrers, denn ich kann nichts mehr machen als mich hier zu informieren 
und mein C-Buch da anzulesen, wo es meine Problemstellung gerade 
verlangt. Aber irgendwann finde ich diese "du kannst dies nicht und 
jenes nicht" nicht mehr nett.

Ich hab Ende Januar Projektbesprechnung für die Vornoten und wirklich 
besseres zutun als mich ständig zu erklären, wieso weshalb und waurm ich 
jene Grundlage nicht weiß.

Ich habe dich gefragt ob die Flankenerkennung wie sie in PeDas Makro 
verwandt wird auch für Bereiche funktioniert.

im kopf ja

im prinzip ist das auch relativ einfach wenn man sich die kiste 
anschaut.

es gibt eine X-achse und eine Y-Achse

an der x-achse ist ein schlitten dran, an welchem ein sensor dran 
"hängt"

es soll eine schneckenfahrt realisiert werden.

sprich -> fahre x nach x_hi dann schrittmotor y-schritte, dann x -> x_lo 
und wieder schritte nach y


also ein schneckenablauf:

1

 _   _

2

| | | | |

3

| | | | |

4

| | | | |

5

| |_| |_| ....

währenddessen soll der sensor werte erfassen und via UART an eine Excel 
Tabelle senden.

Damit das auch sinn macht hab ich einen Timer genommen, welcher mit 1ms 
getaktet ist.

damit soll sowohl die PI-Regelung der X-Achse (DC motor) als auch die 
Taktung des Schrittmotors UND die Taktung der Sensor-Werterfassung 
geregelt werden.

Prinzipiell soll damit eine Oberfläche analysiert werden können, was ich 
aber nicht als aufgabe habe, sondern nur die werterfassung.

der sensor selbst ist bisher nicht bestandteil des quellcodes, da ich 
zunächt die bahnsteuerung fertig machen möchte.

dass das nun kein richtiger ablaufplan ist weiß ich. und einen PAP mit 
einem programm habe ich noch nicht erstellt.

@Sven Weinmann (sickone4)

>werde dir gerne eine Skizze liefern. Wenn ich dafür Zeit finde.

Du musst nicht, aber erwarte dann auch keine große Hilfe.

>-> Netiquette
>>  Tonfall und Inhalt sollten dem Zielpublikum gegenüber angemessen sein

>Ich frage mich bei deinen Aussagen ob du das wirklich einhälst...

Angemessen heißt nicht automatisch kuschelweich.

>Ich bin weder ein Depp noch bin ich Dumm.

Hat keiner behauptet. Aber du bist eher chaotisch, willst zuviel zu 
schenll mit zuwenig Grundlagen. Vergiss es.

> Ich hab ein Schwachkopf als
>Lehrer, der Kopieren vor Kapieren schiebt. Das ist mein Problem. Und wie
>soll man innerhalb eines halben Jahres C lernen wenn man im Unterricht
>nichts als kopieren lernt?

Wenn das WIRKLICH so ist, ist das ein Problem. Das können wir aber nicht 
lösen.

>Lehrers, denn ich kann nichts mehr machen als mich hier zu informieren
>und mein C-Buch da anzulesen, wo es meine Problemstellung gerade
>verlangt.

FALSCH! Dieses Flickwerk geht schief. Man muss sicherlich nicht C aus 
dem FF beherrschen, aber man braucht definitiv ein gewisses Minimum an 
Programmierwissen, nicht nur einzelne Fragmente. Das wird nix. D.h. Du 
musst auch grundlegende Dinge dir erstmal aneignen, die du im Moment 
scheinbar noch nicht brauchst. Wenn gleich das als Schüler der 
(wievielten) Klasse in Grenzen im Selbststudium verlangt werden kann. 
Der Unterricht muss schon den deutlich größeren Anteil leisten.

> Aber irgendwann finde ich diese "du kannst dies nicht und
>jenes nicht" nicht mehr nett.

Das "bliebte" Thema Kritikfähigkeit. Jaja, wollten wir damals auch nicht 
hören, ist aber so. Was soll man mit dir über komplexere 
Programmstrukturen reden, wenn dir die Grundlagen fehlen?

>Ich hab Ende Januar Projektbesprechnung für die Vornoten

AHA! Ziel sind lediglich gute Noten, nicht solide Inhalte. Ok, damit 
bist du auf dem richtigen Weg zum BWLer oder Chef, nicht aber zum 
Ingenieur. Ist OK.

> und wirklich
>besseres zutun als mich ständig zu erklären, wieso weshalb und waurm ich
>jene Grundlage nicht weiß.

Richtig, du musst sie dir erarbeiten. Nur dann geht es weiter.

>Ich habe dich gefragt ob die Flankenerkennung wie sie in PeDas Makro
>verwandt wird auch für Bereiche funktioniert.

Was denn für Bereiche?

"Derzeit nutze ich ja einen Taster für das Setzen der Schritte.
Dies soll allerdings später nichtmehr der Fall sein. Später wird die
Flanke durch das Erreichen eines Bereiches erfasst."

Diesen Satz versteht kein Mensch! Eben weil es keine gescheite 
Beschreibung deines Aufbaus gibt. Und ohne verständliche Kommunikation 
mit anderen Leuten wird das nix. Da könnten wir genauso chinesisch 
reden.

"Um aber Schäden vorzubeugen habe ich dem Endschalter keinen Wert 
sondern
einen Bereich zugewiesen."

Wie soll man das verstehen? Ein Endschalter schaltet am Ende, wo sonst? 
Wie wird da ein Bereich draus?

"Das PeDa Script allerdings wertet eben nur den Taster aus. Macht es da
überhaupt Sinn mit einer Entprellung zu arbeiten?"

O Mann. Nun reden wir schon eine Halb Ewigkeit über die Notwendigkeit, 
Taster zu entprellen, und du stellst das einfach mal eben wieder in 
Frage. AUA!

"Oder ist es nicht
sinnvoller dann einfach ein flag zu setzen und nach dem die Schritte
gefahren wurden UND der Bereich wieder verlassen wurde dieses wieder zu
löschen?"

Das versteht keiner, eben weil niemand ausser dir deinen Aufbau kennt, 
ebenso wie das Ziel des Projekts! Jaja, i letzten Posting hast du etwas 
dazu geschrieben, reicht aber nicht.

In der einen Achse habt ihr einen Schrittmotor und in der anderen einen 
normalen Motor?

Wer hat sich denn das ausgedacht, oder soll das gar kein reales Projekt 
werden sondern nur Übungszwecken dienen?


Da hast du ja noch einiges vor dir.

>>und mein C-Buch da anzulesen, wo es meine Problemstellung gerade
>>verlangt.
>
>FALSCH! Dieses Flickwerk geht schief.

Seh ich ganz genau so.
Auf der einen Seite sollten wir uns zu diesem Zeitpunkt bereits über 
'Konzepte' (am Beispiel Malerei) wie Bildkomposition und Lichteinfall 
unterhalten, auf der anderen Seite sollten wir dir erst mal Pinsel 
auswaschen beibringen. Da klafft eine enorme Lücke dazwischen und ich 
weiß ehrlich gesagt nicht, wie man die von unserer Seite aus überbrücken 
soll.
Denn das nächste Problem ist ja, dass es mit den Kentnissen aus dem 
C-Buch nicht getan ist. Denn was ein C-Buch nicht vermitteln kann, das 
ist die Praxis.

Sven Weinmann schrieb:

> dass das nun kein richtiger ablaufplan ist weiß ich. und einen PAP mit
> einem programm habe ich noch nicht erstellt.

Brauchst du auch nicht 'mit einem Programm machen'.
Ganz im Gegenteil. 'Mit einem Programm machen' bedeutet in der Praxis, 
dass man 90% der Zeit damit vertrödelt, irgendwelche Programmfunktionen 
zu verstehen, Menüpunkte zu suchen, bzw. 100-tausend mal Fonts umstellt, 
Texte anders einfärbt etc. etc.

Papier, Bleistift und Radiergummi. Mehr braucht man nicht.
Du wärst überrascht, wenn du die Schreibtische der Profis sehen 
könntest. Ich kennen KEINEN, bei dem nicht neben der Tastatur ein Stapel 
Schmierpapier und Kugelschreiber liegen würde. In den letzten 3 Jahren 
hab ich mindestes 5 Collage-Blocks mit Notizen, Debug-Werten, 
skizzierten Abläufen, Algorithmentests, .... vollgeschrieben. Und die 
Wand hinter mir ist tapeziert mit Skizzen, in denen spezielle 
CAD-Situationen, Variablen und deren Zusammenhänge, Formelwerk etc. 
festgehalten sind. Mit einer Textverarbeitung würde ich heute noch 
zeichnen, was ich mit Bleistift in 10 Minuten skizzieren kann.

Sven Weinmann schrieb:
> wir haben festgestellt, dass der programmer den ich nutze nicht das
> gelbe vom ei ist und ich mir auf kurz oder lang alternativen suchen
> sollte.

Der Programmer ist schon okay. Ihn nur abewechselnd auch für die 
UART-Übertragung zu nutzen ist Käse.

Kauf Dir das noch dazu:

http://shop.myavr.de/Programmer%20und%20Bridges/myUSBtoUART.htm?sp=article.sp.php&artID=200024

Kostet 7,95 EUR und Du hast einen extra UART für Deine Kommunikation. 
Dann musst Du nicht umschalten, sondern kannst von Anfang an beobachten, 
was sich auf dem UART tut. Bis Du umgeschaltet hast, ist für den µC 
schon eine Ewigkeit vergangen.

@ Frank:
wie soll es denn möglich sein die uart zu trennen?

klar bei meinem kombinierten programmer garnicht erst in den UART Modus 
um zuschalten...
ABER wenn das programm doch erst läuft wenn ich den datenmodus aktiviere 
dannstimmt da doch irgendwas anderes nicht.

ich kann mit dem uart to USB adapter ja viaRxD und TxD auf meinen Atmega 
zugreifen, aber der Programmer ist ja hardwaretechnisch immernoch 
verbunden.

Irgendwie macht das keinen Sinn für mich, da sich ja eigentlich nur 
folgende Situation einstellen wird:

Programmer(Kombiniert) -> brennen
UART_USB -> Kommunizieren

was aber wenn der Programmer dennoch das Programm nicht freigibt?

@  Sven Weinmann (sickone4)

>wie soll es denn möglich sein die uart zu trennen?

Indem man ZWEI Adpater nutzt. Einen für's Programmieren, einen für's 
UART.

>ABER wenn das programm doch erst läuft wenn ich den datenmodus aktiviere
>dannstimmt da doch irgendwas anderes nicht.

Sieht so aus.

>ich kann mit dem uart to USB adapter ja viaRxD und TxD auf meinen Atmega
>zugreifen, aber der Programmer ist ja hardwaretechnisch immernoch
>verbunden.

Das stört nicht, der hält ruhig.

>Irgendwie macht das keinen Sinn für mich, da sich ja eigentlich nur
>folgende Situation einstellen wird:

>Programmer(Kombiniert) -> brennen
>UART_USB -> Kommunizieren

Passt doch.

>was aber wenn der Programmer dennoch das Programm nicht freigibt?

Dann hat der Programmer ein Problem. DAS musst du zuerst lösen.

Falk Brunner schrieb:
> Indem man ZWEI Adpater nutzt. Einen für's Programmieren, einen für's
> UART.

Ja völlig klar! werde ich in Zukunft auch machen!


hab das gute Teil mal bestellt und werde es testen und hoffe schon 
jetzt, dass ich mit dem Programmer keine weiteren Kuriositäten mehr 
haben werde

So da sind mal zwei Dateien mit dem eigentlichen Programm, wie es 
derzeit in meinem kopf rumschwirrt.

Das ist sozusagen Version 1