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.
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.
Angehängte Dateien:
-
03loktriebwerke1.jpg
49 KB
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.
Angehängte Dateien:
-
erste_Schritte.JPG
110 KB
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-Tutorial:_IO-Grundlagen 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:Atmega8_Taster_LEDs.png (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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.