Ich konnte jetzt durch die Member im Forum hier ein selbständiges C++
Progi für die K8055 entwickeln und es unter Dos selbständig laufen,
regeln und beenden lassen.

Da ich auch im Besitz eines AVR STK 500 boards bin, dieses aber noch
nicht genutzt hatte, habe ich einige Fragen?

Kann ich mein C++ Progi einfach in dem mitgelieferten AT90S8515
übertragen?

Worauf muss ich achten?

Und wie kann der PIC selbständig laufen, ist zusätzlich eine äussere
Beschaltung notwendig?

Will mir die Automatisierung damit bauen auf einer LochrasterPlatine
oder vielleicht noch ne Platine dafür entwickeln?

(Info: Ich bin Radio und Fernsechtechniker)

Für jede Anregung bin ich sehr dankbar.

Habe auch mal den fertigen Code hochgeladen.

Ich denke das Übertragen der PC-Source in den AVR ist nicht ohne
weiteres möglich ist.

Die PC-Lösung setzt voraus, dass auf dem PC die eigentliche
K8055-Steuersoftware (DLL) vorhanden ist und dass der PC als USB-Host
für den als USB-Client programmierten PIC auf dem K8055 fungiert, d.h.
USB-Treiber vorhanden sind...

An die Source der DLL kann man noch rankommen und diese Funktionen
portieren. Aufpassen muss man beim Platzbedarf, es kann sein, dass der
AT90S8515 zu klein für alle Funktionen ist. Das grössere (und IMHO
unlösbare) Problem ist das Emulieren/Ersetzen der USB-Host-Aufgaben.

Aber ich würde das Vorhaben nochmal durchdenken, ob ohne PC die K8055 in
deinem Projekt überhaupt noch notwendig ist. Oder ob die Funktion des
K8055 nicht komplett durch ein AVR ersetzt werden kann. Ich halte das
für einen vielversprechenden und gangbaren Weg.

Es gibt leistungsfähige AVRs mit analogen Eingängen und mit digitalen
IOs, die die Steuerung komplett übernehmen könnten.

Und wenn es um die Kommunikation mit dem PC über USB geht, kann man
spezielle USB-fähige AVRs benutzen oder USB-Softwareroutinen auf einem
AVR einrichten. Andere attraktive Kommunikationswege könnten über RS232
Funkkommunikation oder TCP/IP oder... gehen. Viele Robotprojekte mit
AVRs könnten dir hier Anregung geben.

Genauso will ich das machen, den Pc und die K8055 entfernen und nur den
AT90S8515 benutzen, wenn das geht.

Mir ist schon klar dass ich dann eine neue C Datei erstellen muss, das
dürfte aber kein grosses Problem sein. Vor allem sind gute Tutorials auf
der Seite hier.

Kann der AT90S8515 denn mind. 5 DigitaleAusgänge, 2 AnalogeAusgänge
(Also 2 PWMs) setzen und 2 AnalogeEingänge einlesen?

Und ist das STK 500 für diesen Zweck geeignet?

Welchen Mikrocontroller kann ich denn sonst noch nehmen, wenn dieser
nicht ausreichen sollte? (Würde diesen dann bei Reichelt beziehen).

Der 8515 hat keine Analogeingänge. Für dich passend wäre zb der Mega8.

etwa dieser hier:

http://www.reichelt.de/?;ACTION=3;LA=4;GROUP=A363;...

So Board ist ausgepackt, habe neben dem AT90S8515 einen Atmega16 16PC
mit dabei. Der müsste doch jetzt klappen oder muss ich gleich nochmal
los einen anderen besorgen?

ATMega16 ist gut, wie dir ein Blick ins Datenblatt des Prozessors
zeigt.
Datenblatt kriegst du bei Atmel auf der Webseite. Hol es dir,
du wirst es brauchen.

hi du könntest den IC auf dem K8055 gegen einen 18f2550 tauschen sind
aber noch 3 Änderungen auf den Bord nötig dafür und vorher nen kleinen
usb Bootloader drauf schmeißen danach kanste den das board standalon
ohne pc nutzen mit eigender SW für den pic.

Hi, das werde ich wohl nicht machen, da der Lernerfolg mit dem STK 500
meiner Meinung grösser ist und die Platine mit einem Atmega16 weniger
Platz verbrauchen wird. Bei einer Modellbahn ist Platz sehr wichtig.

Siehe Bild

Datenblatt jetzt vorhanden, wollte aber gerne wissen ob der Atmega16
einen internen Quarz intergriert hat oder muss ich einen externen dazu
schalten?

Werde aus dem Datenblatt nicht so schlau, weil es auch auf Englisch ist.

Gibt es deutsche Datenblätter für die Atmel AVR's ?

Sonst werde ich mich mal mit einem Wörterbuch da durchschlagen.

Lzaman wrote:
> Datenblatt jetzt vorhanden, wollte aber gerne wissen ob der Atmega16
> einen internen Quarz intergriert hat oder muss ich einen externen dazu
> schalten?

Quarz nicht. Einen RC-Oszillator.
Wenn du Datenübertragung nach aussen machst, zb über RS232, wirst
du mit dem RC-Oszillator nicht glücklich werden.

> Gibt es deutsche Datenblätter für die Atmel AVR's ?
Nein.

> Sonst werde ich mich mal mit einem Wörterbuch da durchschlagen.
Tu das. Datenblätter sind einfach geschrieben, keine komplizierten
Satzkonstruktionen. Sollte kein großes Problem sein, die mit
Schulenglisch + den notwendigen Fachausdrücken zu lesen.

Und ausserdem: Das Datenblatt wird dir die nächste Zeit ein treuer
Freund sein. Du wirst noch oft da drin nachschlagen. Also verschaff
dir gleich mal einen Überblick, was da so alles drinn steht.

Kann mir bitte jemand sagen ob das so richtig istwie auf dem Bild
verstanden?

Und wir kann ich PWM realisieren und an welchen Pins?

Morgen gibts mehr.

Vorab: Mit PWM habe ich noch nie was gemacht. Also Vorsicht bei meinen
Aussagen dazu!

Also ich würde mich an dem Artikel
http://www.mikrocontroller.net/articles/Pulsweitenmodulation und den
dort erwähnten Links orientieren.

Wenn du mit Hardware-PWN arbeiten willst, kämen dafür die Pins PD4
(OC1B) und PD5 (OC1A) in Betracht. Bei Software-PWM kannst du den Pin
weitgehend frei wählen.

Den PortB für die Digitalausgänge kann man nehmen. Musst halt aufpassen,
wie deine dort angeschlossene Hardware reagiert, wenn der
ISP-Programmieradapter die vier Leitungen zappeln lässt. Man kann da
aber mit JUmpern oder Wannensteckern die Hardware abklemmen, wenn man
programmiert. Es gibt auch eine Apllikationsnotiz von Atmel zu Hardware
am ISP-Anschluss.

Kannst du mir vielleicht einen kleinen code in c posten, der die PD4 und
PD5 auf einen Wert von 150 setzt (von max. 255). Verstehe das nicht so
ganz mit der 10 bit, 9 bit oder 8 bit Funktion. Ich brauche ja nur 8 bit
für einen max Wert von 255.

Danke

Keine Zeit und keine Ahnung.

Aber such doch mal nach den Stichworten ATmega8, PWM, OC1A, OC1B und du
wirst auf Seiten stossen, bei denen Hardware-PWM eingesetzt wird. Z.B.
auf dieser Seite zum Roboter ASURO:
http://www.henkessoft.de/Roboter/ASURO.htm

Dort gibt es auch gute Erklärungen und Sourcecode-Beispiele.

Stefan "stefb" B. wrote:
> Keine Zeit und keine Ahnung.

Das liest sich barscher, als es gemeint ist. Die Uhr tickt, nur noch ein
paar Stündchen bis zum langen Pfingsturlaub ohne
Rechner/Internet/AVRs...

Also mit dem folgenden Code aus dem AVR-GCC Tutorial leuchten bei mir
die LED's 2-7 und  nicht 0 und 1. Ist das ein Fehler im code oder flashe
ich falsch?

/* Alle Zeichen zwischen Schrägstrich-Stern
   und Stern-Schrägstrich sind lediglich Kommentare */

// Zeilenkommentare sind ebenfalls möglich
// alle auf die beiden Schrägstriche folgenden
// Zeichen einer Zeile sind Kommentar

#include <avr/io.h>          // (1)

int main (void) {            // (2)

   DDRB  = 0xff;             // (3)
   PORTB = 0x03;             // (4)

   while(1) {                // (5a)
     /* "leere" Schleife*/;  // (5b)
   }                         // (5c)

   /* wird nie erreicht */
   return 0;                 // (6)

In der mit (1) markierten Zeile, wird eine sogenannte Header-Datei
eingebunden. In io.h sind die Registernamen definiert, die im späteren
Verlauf genutzt werden.

Bei (2) beginnt das eigentliche Programm. Jedes C-Programm beginnt mit
den Anweisungen in der Funktion main.

(3) Die Anschlüsse eines AVR ("Beinchen") werden zu Blöcken
zusammengefasst, einen solchen Block bezeichnet man als Port. Beim
ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem
Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition
(Datenblatt) alle gesetzten Bits in einem Richtungsregister den
entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle
Anschlüsse des Ports B zu Ausgängen.

(4)stellt die Werte der Ausgänge ein. Die den ersten beiden Bits des
Ports zugeordnete Anschluss (PB0 und PB1) werden 1, alle anderen
Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1
oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt),
nicht-aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential).

(5) ist die so genannte Hauptschleife (main-loop). Dies ist eine
Programmschleife, welche kontinuierlich wiederkehrende Befehle enthält.
In diesem Beispiel ist sie leer. Der Controller durchläuft die Schleife
immer wieder, ohne das etwas passiert (außer das Strom verbraucht wird).
Eine solche Schleife ist notwendig, da es auf dem Controller kein
Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle
übernehmen könnte. Wäre die Schleife nicht vorhanden, würde der Zustand
des Controllers nach dem Programmende undefiniert.

(6) wäre das Programmende. Die Zeile ist nur aus Gründen der C-
Kompatibilität enthalten: int main(void) besagt, dass die Funktion einen
Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm
die Hauptschleife nie verlässt.

Lukas Piet wrote:
> Also mit dem folgenden Code aus dem AVR-GCC Tutorial leuchten bei mir
> die LED's 2-7 und  nicht 0 und 1. Ist das ein Fehler im code oder flashe
> ich falsch?

Du hast das Kleingedruckte nicht gelesen.
Eine LED leuchtet auf deinem Bord, wenn der entsprechende Ausgangspin
eine 0 aufweist.

  0x03  =      0000 0011

also soll LED 0 und 1 nicht leuchten und alle anderen schon.
Genauso ist dann auch bei dir.

Genau das ist mit 'Low-Aktiv' gemeint: Der aktive Zustand liegt
dann vor, wenn der Pin auf Low (=0) liegt.

Lukas Piet wrote:

> Also mit dem folgenden Code aus dem AVR-GCC Tutorial leuchten bei mir
> die LED's 2-7 und  nicht 0 und 1. Ist das ein Fehler im code oder flashe
> ich falsch?
> ...
>    DDRB  = 0xff;             // (3)
>    PORTB = 0x03;             // (4)

Dann sind deine LEDs wie in
http://www.mikrocontroller.net/articles/AVR-Tutori...
active-low angeschlossen. Das Leuchtmuster passt dann zum Code.

Eine active-high Schaltweise ist auch möglich. Das sieht dann wie in
http://www.mikrocontroller.net/articles/Bild:Atmeg...
(entsprechend an PORTB!) aus und mit obigem Code wurden dann die LEDs an
PB0 und PB1 leuchten.

So habe jetzt nochmal mit dem Multimeter am Atmega gemessen. An Pin 1
und Pin 2 liegen 5 Volt an (also High) und Pin 3 bis Pin 8 ist Low.
Wieso leuchten aber die LED's bei Low?

Sorry aber das verstehe ich nicht so ganz mit dem Active Low, ist leider
auch in Assembler erklärt.

Lukas Piet wrote:
> So habe jetzt nochmal mit dem Multimeter am Atmega gemessen. An Pin 1
> und Pin 2 liegen 5 Volt an (also High) und Pin 3 bis Pin 8 ist Low.
> Wieso leuchten aber die LED's bei Low?

Weil sie so verschaltet wurden!

Das ganze hat historische Ursachen. Ein µC Pin konnte mehr
Strom 'senken' als er 'sourcen' konnte.

Was'n das schon wieder?

Kurz gesagt: In den Port kann mehr Strom hineinfliessen (wenn
der Pin 0 ist) als der Pin liefern kann, wenn der Pin 1 ist.

Also schaltet man die Diode so


                 -----------+-------------  5V
                            |
                           LED
                            |
          µC Pin o----------+


Wenn der µC Pin 1 (also auf 5V) ist, dann läuft kein Strom
vom Pin nach +5V und daher leuchtet die Diode nicht.

Ist der Pin aber auf 0, so fliesst Strom von 5V in den Pin
hinein und die LED leuchtet.

Und da der Pin mehr Strom aufnehmen kann als er abgeben kann,
läuft man nicht so leicht Gefahr den Pin mit zuviel Strom zu
zerstören.

Achso ich habe dann falsch rum gedacht.  Die LED wird mit VCC versorgt
und nicht mit der Spannung vom Pin. Ist ja logisch sonst würde der
Atmega viel mehr Strom ziehen, aber das ist ja nicht Sinn der Sache,
richtig?

Wie oft kann ich eigentlich flashen und erasen? etwa 10000 mal?

> Wie oft kann ich eigentlich flashen und erasen? etwa 10000 mal?

Das ist die Zahl, die dir Atmel garantiert.
In der Praxis wirds aber wohl um einiges mehr sein.

Danke für alle Beiträge