Hallo, ich habe gerade von Pollin bezogen: 1 Atmel Evaluations-Board Version 2.0 1 Atmel Addon-Board V 1.0 Das Eval.-Board hab ich schon fertig gelötet. Das Addon-Board hab ich fertig bis auf den Einbau des LC-Displays. Wäre es nicht besser, dies steckbar/abnehmbar zu machen? Beide Boards finde ich gut vom Design, vielseitig und auch billig. Nun wundere ich mich, dass es offenbar kein Benutzerhandbuch gibt und offenbar auch keine Anleitung, wie beide Boards zusammenarbeiten sollen. Klar, das könnte ich sicher selbst rausfinden. Und natürlich würde ich mich freuen, wenn mir andere Nutzer der Pollin-Boards Tipps geben können, welcher Prozessor sich zum Einstieg und zum Üben empfiehlt. Vielleicht gibt es auch weitere Projekte und Beispiel-Software, die mir die Einarbeitung erleichtern könnten, ggf. mit Link? Gruß Dietrich
> ich habe gerade von Pollin bezogen: > > 1 Atmel Evaluations-Board Version 2.0 Damit hast du den Pollin-Bestand wohl leergekauft ;-) > Nun wundere ich mich, dass es offenbar kein Benutzerhandbuch gibt > und offenbar auch keine Anleitung, wie beide Boards zusammenarbeiten > sollen. Es gibt die Kurzbeschreibungen der Boards im Downloadbereich von Pollin, die auch die Schaltpläne enthalten. Wahrscheinlich musst du dir diese und das Datenblatt des verwendeten µC zu Gemüte führen, um zu erfahren, wie die Peripherie vom Programm aus anzusprechen ist. Nützliche Informationen allgemeiner Art findest du in den AVR-Artikeln auf dieser Web-Seite: http://www.mikrocontroller.net/articles/AVR > Und natürlich würde ich mich freuen, wenn mir andere Nutzer der > Pollin-Boards Tipps geben können, welcher Prozessor sich zum Einstieg > und zum Üben empfiehlt. Ich bin zwar kein Pollin-Board-Nutzer, aber der Einstiegs-AVR ist sicherlich der ATmega8. Der ist sehr preisgünstig, hat für den Anfang aureichend Flash und RAM, genügend I/Os, um auch Dinge wie LCDs ansteuern zu können, und ein breites Spektrum an unterschiedlichen Schnittstellen (Digital, Analog, synchron und asynchron seriell usw.), so dass man sich eine genze Weile damit austoben kann. Natürlich passt er auch in das Pollin-Board. Wenn du den ATmega8 beherrschst, wirst du auch problemlos alle anderen AVRs benutzen können, da Prozessorkern und On-Chip-Peripherie bei allen sehr ähnlich aufgebaut sind. Wenn du schon am Bestellen bist, würde ich neben dem Mega32 gleich noch einen kleinen (Tiny13 ode Tiny25) und einen gößeren (Mega32) nehmen. Dann hast du für die meisten Anwendungsfälle den richtigen Typ zur Hand. > Vielleicht gibt es auch weitere Projekte und Beispiel-Software, die > mir die Einarbeitung erleichtern könnten, ggf. mit Link? Ein paar Beispielprojekte mit AVRs gibt es in den o.g. AVR-Artikeln und in dem Subforum "Codesammlung".
Hi, Dietrich J. wrote: > > Das Addon-Board hab ich fertig bis auf den Einbau des LC-Displays. > Wäre es nicht besser, dies steckbar/abnehmbar zu machen? Auf jeden Fall. Ich hatte noch eine Buchsenleiste übrig und hab's steckbar gemacht. Mit den gelieferten Teilen wäre es eh nicht gegangen, da die Kondensatoren unter dem LCD zu hoch sind. Bei mir waren auch keine Jumper mit dabei ... > Nun wundere ich mich, dass es offenbar kein Benutzerhandbuch gibt und > offenbar auch keine Anleitung, wie beide Boards zusammenarbeiten sollen. Irgendwo muß der günstige Preis ja herkommen. Es ist aber nicht sehr schwer: 1. Ich habe die beiden Boards übereinander gebaut. Dazu nimmt man einfach 8 Stück "Distanzhülsen, Metall, 6-Kant, M3, 20mm" und 4 Stück M3 Muttern. 20mm sind aber ein bissl knapp - geht aber grade noch so. 2. Verbindung bekommen die beiden Boards über ein 40pol Flachbandkabel (früher hat man damit P-ATA (IDE) Ferstplatten angeschlossen. Dummerweise ist der Anschluß auf dem Board rechts, dagegen am Addon-Board links - so muß das Kabel zwischen den Platinen durch ... So, das zur Vorarbeit - Bilder hab ich auch gemacht: http://gallery.port23.de/v/bastard/atmel-board/ Nun zu den Möglichkeiten: Das LCD ======= Entweder man benutzt die Jumper um die LCD Pins auf PortA0..7 + PortB0..2 zu bekommen, oder man nimmt alle Jumper raus und muß stattdessen über Kabelbrücken die Portpins auf der linken Seite mit den entspr. LCD-Pins links neben den Jumpern stecken. Taster, LEDs, IR-Empfänger, Audio-Verstärker ============================================ Diese Verbindungen werden über Kabelbrücken gesteckt. Die Taster und LEDs sind durchnumeriert - es gibt jeweils eine Buchse die mit einem Portpin verbunden werden kann. Dito mit dem IR-Empfänger. Der Audio-Verstärker hat 8 Steckmöglichkeiten. Diese unterscheiden sich lediglich durch einen anderen Vorwiderstand. RS232-Anschluß, "untere Taster", "untere LEDs", Summer ====================================================== Will man die Komponenten der unteren Platine nutzen, muß man natürlich die unteren Jumper passend gesteckt haben! Umgekehrt macht es Sinn, die "unteren" Funktionen durch ziehen des entspr. Jumpers abzuschalten, damit nicht die "oberen" Funktionen beeinträchtigt werden. Ich bin noch am zusammenbasteln eines Testprogramms, damit man prüfen kann, ob man alles richtig gemacht hat. MfG Stefan
yalu wrote: >> ich habe gerade von Pollin bezogen: >> >> 1 Atmel Evaluations-Board Version 2.0 > > Damit hast du den Pollin-Bestand wohl leergekauft ;-) Ja, hab ich auch gerade gesehen. Ich gehe davon aus, dass die nachproduziert werden?! Danke für die Software-Tipps Gruß Dietrich
yalu wrote: >> ich habe gerade von Pollin bezogen: >> 1 Atmel Evaluations-Board Version 2.0 > > Damit hast du den Pollin-Bestand wohl leergekauft ;-) Habe gerade bei Pollin telefonisch nachgefragt. Das Atmel-Eval.Board Best.Nr. 810 038 und auch das Addon-Board Best.Nr. 810 053 werden bald wieder lieferbar sein und können einfach über Direktbestellung schon bestellt werden. Gruß Dietrich
Ich hoffe, du hast Recht. Warum muss das auch ausgerechnet dann ausverkauft sein, wenn ichs mir gerade kaufen will :'( Ich bin noch absoluter Neuling im Bereich Mikrocontroller, habe mir durch Zufall einige Videos bei youtube angeschaut und das hat mich extrem neugierig gemacht. Ich bin nämlich ein großer Fan von Elektronik und IT. Und das Evaluations Board mit Addon von Pollin hielt ich bis jetzt für die günstigste Möglichkeit, in die Materie einzusteigen. Ich hoffe, die beiden Boards sind bald wieder verfügbar.
UltraFX wrote: > Ich hoffe, du hast Recht. Warum muss das auch ausgerechnet dann > ausverkauft sein, wenn ichs mir gerade kaufen will :'( > > Ich hoffe, die beiden Boards sind bald wieder verfügbar. Das Atmel-Eval.Board Best.Nr. 810 038 ist gerade verfügbar. Ansonsten einfach nach Bestell-Nr. ordern. Gruß Dietrich
Hallo, eine Frage kann man der ATMEL Evaluations-Board Version 2.0 nur mit PonyProg Programmieren? oder geht auch z.B. mit "USB Atmel ISP Programmer" (http://www.ulrichradig.de/home/index.php/avr/usb-avr-prog) von Ulrich Radig ?? Gruß
Ich habe die Variante mit Funk, die ähnlich sein sollte, und da läßt sich ein externer Programmer (auch USBAVR-ISP) über 10polige Buchse anschließen. Umgekehrt kann man auf diese Weise den integrierten Programmer (ähnlich SI-Prog) an ein externes Board anschließen, solange auf dem Pollin-Board kein AVR gesteckt ist.
hallo,
Dietrich J. wrote:
> 1 Atmel Addon-Board V 1.0
hast du mir da ne Bestellnummer. Ich kann das Teil bei dem Lieferanten
nicht finden.
Gruss
Jürgen
yalu wrote: > Ich bin zwar kein Pollin-Board-Nutzer, aber der Einstiegs-AVR ist > sicherlich der ATmega8. [...] Mittlerweile vielleicht einen ATmega88 stattdessen. Der ist pinkompatibel, aber eine Weiterentwicklung: neuer RC-Oszillator, neuer Watchdog (damit lernt man zumindest gleich, damit umzugehen :), paar Funktionen mehr. debugWire, wenn man mal an dem Punkt ist, dass man seine Applikationen online mit einem AVR Dragon untersuchen will. Für die Entwicklungsarbeiten auch nicht schlecht: es gibt ihn auch als ATmega168 mit doppelt so viel ROM (künftig sogar als ATmega328P mit 32 KiB).
Jürgen Mayer wrote: > hallo, > > Dietrich J. wrote: > >> 1 Atmel Addon-Board V 1.0 > > hast du mir da ne Bestellnummer. Ich kann das Teil bei dem Lieferanten > nicht finden. Hallo, Jürgen, Bestellnummer ist 810053. Kannst du einfach bei "Direktbestellung" eingeben. Gruß Dietrich
Hallo, ich stell mal meine Frage gleich mit, ist ja dasselbe Thema. Bisher hab ich es noch nicht geschafft ein anderes LED als das NetzLED zum Leuchten zu bringen ;-) Die Frage wurde bestimmt auch shcon beantwortet und ich hab sie ganz sicher überlesen, aber kann ich irgendwie sicher gehen das das Board richtig angebaut ist ? Also irgendwie so ne Statusüberprüfung ? Oder muss ich dann "Programm übertragen - IC umbauen - Hardware zusammenstecken - testen" und kann es nur auf dem Wege herraus fidnen ob alles glatt läuft ? MfG
Hallo, hat sich erledig?? hast du die Fuse so eingestellt wie in der .pdf Datei von Pollin? wenn ja dann Löt Punkte nach prüfen und verbessern, Polarität von Dioden usw. prüfen. Wenn nicht dann .zip Datei entpacken, pdf lesen, PonyProg2000 runterladen, installieren und los wie in der .pdf Datei beschrieben ist. Gruß Gast
Hallo tobi, hat funktioniert? bitte hier mal posten so kann man weiter helfen bzw. ander auch damit helfen! Gruß
Angehängte Dateien:
-
ABCD0013.JPG
460 KB
Servus! Bei mir funzt´s leider noch nicht. Ich bekomm das Testprog nicht zum laufen. Hab aber auch einen anderen Atmel (AT90S8535) als in der pdf beschrieben. Kann mal jemand bitte ein Testprog für diesen Atmel online stellen, so das ich das nurnoch mit dem Ponyprog raufmachen kann? Weis grad nicht, ob´s am Board oder am Bascom liegt. Danke
Hallo Alois, ich glaube du kannst in der Board kein AT90S8535 programmieren, du kannst auf dem Board folgende Kontroller programieren bzw. steht auf dem .pdf drauf: --" Mit diesem Atmel-Evaluatios-Board können die Microcontroller der Atmel-Familien ATtiny12/, 15, ATtiny2313, ATmega8, ATmega16/32 sowie den ATmega8535 direkt auf der Platine programmiert werden "-- du muß dich eine von denen Kontroller besorgen und dann klapt es! Gruß Martin
Das Einzige, was den AT90S8535 von den genannten Controllern (ATmega16/32, ATmega8535) unterscheidet ist, dass er keinen internen RC-Oszillator hat, sodass man immer einen externen Takt oder Quarz benötigt. Da ich mal davon ausgehe, dass das Board irgendsowas bereit stellt, sollte der AT90S8535 also sehr wohl benutzbar sein. Alois, wenn du das Board so verdrahten kannst, dass eine LED an Port D5 hängt, dann sollte das beiliegende Hexfile (simple demo der avr-libc) diese LED in der Helligkeit auf- und abschwellen lassen.
Also ein 16 MHz Quarz ist zwischen Pin 12 und 13 drin und jeweils mit 22pF auf Masse gekoppelt. Ja D5 ist laut Datenblatt ATmega32 (hab grad kein anderes da :-)) Pin 19 und das geht laut Schaltplan Board eh zufällig an die LED1. Also, ich hab den hex-file in ponyprog geöffnet (chip ausgesucht) und rübergeblasen. Also mit dem AT90S8535 liefen zuerst die Ladebalken, dann verify und dann stand auf dem Bildschirm: "! write failed". Dann hab ich einen ATMEGA 8515 reingesteckt und versucht. Ergebnis war schon vor Ladebalken: "device missing or unknown device (-24)" Bei einem ATMEGA 32 dasselbe Ergebnis. Hat da evtl Ponyprog oder meine COM1 ein Problem? Danke derweil
Angehängte Dateien:
-
ABCD0014.JPG
460 KB
Ich hab auch hier noch einen anderen Programmer. Ist ein Noname (Rückseite steht was von Kanada Systems) glaub ich, aber den gleichen hatten wir in der Schule auch. Dummerweise wird der mit einem Flachbandkabel am Parallelport angesteckt und mein PC hat diese (altertümliche) Schnittstelle nichtmehr - Mist.
Das sieht mir sehr nach einem STK200 aus, Dokumentation sollte daher beschaffbar sein.
Alois Kraus wrote: > Also mit dem AT90S8535 liefen zuerst die Ladebalken, dann verify und > dann stand auf dem Bildschirm: "! write failed". ISP-Taktfrequenz zu hoch eingestellt? Sollte bei 16 MHz eigentlich eher kein Problem sein, da wären ja < 4 MHz OK. > Dann hab ich einen ATMEGA 8515 reingesteckt und versucht. Aua! Guckst du auch vorher mal ins Datenblatt bitte? Der ist jetzt hinüber. :-(
Danke, und schon hab ich ein PDF für das ding in angelsächsisch gefunden. Stimmt, sieht gut aus, aber ich hab da noch das Anschlussproblem. Kann ich das auch mit der com- Schnittstelle betreiben (hab keine parallele) Hat jemand für das STK200 eine deutsche Bedienugsanleitung? Danke
Tschuldigung die dumme Frage, aber wo stellt man diese "ISP Frequenz" denn ein? Und wie hinüber? Sollte ich da mal ein Datenblatt lesen?
Schau Dir (besser: lese) die Datenblaetter der verwendeten Controller! Und Google wirst Du ha hoffentlich bedienen koennen?
Alois Kraus wrote: > Tschuldigung die dumme Frage, aber wo stellt man diese "ISP Frequenz" > denn ein? Ich kenne Ponyprog nicht, weiß ich nicht. Bei avrdude wäre es die Option -i. > Und wie hinüber? Futsch, finito. > Sollte ich da mal ein Datenblatt lesen? Ja, insbesondere solltest du wohl mal die Pinouts zwischen ATmega8535 und ATmega8515 vergleichen...
Noch so allgemein zum Board: Es ist super lästig die Brücken zu stecken... Und das stet dann noch in einer extra Anleitung die man runterladen muss. Aber das Testprogramm läuft (Bis auf UART, hab kein CR+LF hinbekommen) Im Anhang ein Bild mit vollbestücktem Addon-Board und Evalution-Board.
Ist die Handycam vom W810i wirklich so besch..., oder warum sind die Fotos so unscharf und so verrauscht? Aber hauptsache in voller Auflösung hier veröffentlichen.
Bin absoluter Neuling, was AVR Prozessoren angeht. Hab mir ein AVR-BOARD 2.0.1 besorgt, hab aber keine Ahnung, wie man das Ding über RS232C anschließt, noch wie man die Sache zum Laufen bringt. bin schon etwas älter, habe damals noch mit 10ner Tastatur und Tasten von A bis F Maschunensprache fur 8080 8085 Prozessoren gelernt. Mit sämtlicher Berechnung der EInsprungadressen usw, usw. Bin Elektroniker, der gerne Anschluß finden möchte, hab die Faszination Micricontroller nie verloren, aber den Anschluß an die effektive Programmierung. Wer hilft mir, um zum Beispiel über BASIC- oder andere Sprachen und den entsprechenden Hilfsprogrammen den Weg ins Hobby zurück zu finden ?
Hi >habe damals noch mit 10ner Tastatur und Tasten von A bis F >Maschunensprache fur 8080 8085 Prozessoren gelernt. So habe ich auch mal angefangen, allerdings Z80. Damit hast du mehr Grundlagen als viele andere AVR-Starter. Wenn du erst mal kostenlos reinschnuppern willst, dann lade dir das aktuelle AVR-Studio, ein paar Datenblätter und das Instruction Set-pdf von der Atmel-Webseite. Mit dem AVR-Studio hast du einen sehr guten Assembler incl. Simulator. Für Basic gibt es BASCOM mit Simulator. C ist mit AVR-GCC verfügbar. Alles kostenlos verfügbar. Die Atmel-Webseite stellt auch eine grosse Anzahl von Application Notes zur Verfügung, die viele Lösungen enthalten. MfG Spess
Hallo leute Hab eure Beiträge mir gut zu gemüte geführt. Habe bisher auf einem STK500 programmiert. War auch echt zufrieden, leider hat mein Kollege den IPS Port zerschossen und der Oszilator spinnt. Weiß immer noch nicht wie er das geschafft hat. Naja . Suche nach ner guten, jedoch preiswerten Alternative und so bin ich im Netz beim stöbern auf das Pollin Board gestoßen. Ich möchte damit hauptsächlich ATTINY 13 und AT90S8535 programmieren. Schätze dann kommt bestimmt auch die Frage warum kein MKII? Bin halt von dem Ding nicht überzeugt. Also geht das sauber mit dem Board. Läuft das Board sauber mit dem AVR Studio? Bin halt noch Schüler und überdenke die Investition noch Soll ich mir, wenn es lieferbar ist bestellen?? Danke schon mal für die Antworten Lg Josef
> Also geht das sauber mit dem Board. Wenn Du einen alten PC mit echter serieller Schnittstelle (kein USB) hast, könntest Du Freude an dem Board haben. > Läuft das Board sauber mit dem AVR Studio? Nein, AVR-Studio unterstützt keine primitiven Bitbanging-ISP-Adapter, wie einer auf dem Board vorhanden ist. Das Board ist mit dem STK500 absolut nicht vergleichbar. ...
Hi, auch ich habe mir das Pollin Board mit Addons bestellt. Nach dem zusammenbau habe ich das Testprogramm von Pollin auf einen Atmega8 geschrieben. Zunächst läuft auch alles wie gewünscht. Ich hänge jedoch an der IR-Funktionalität. Ich habe jetzt alle Fernbedienungen meines Haushaltes ausprobiert (ca. 7Stk) jedoch erfolglos. Benötige ich für RC5 eine spezielle Fernbedienung? Was mich auch irritiert, ist das am dem IR-Port ein dauerhaftes High anliegt und bei empfang eines IR Signals auf Low geschaltet wird. Is das richtig? Ich habe bereits penibel alle Bauteile kontrolliert jedoch keinen Fehler beim zusammenbauen feststellen können. Bin für jede Hilfe dankbar.
Sebastian Kusch schrieb: > Zunächst läuft auch alles wie gewünscht. Ich hänge jedoch an der > IR-Funktionalität. Ich habe jetzt alle Fernbedienungen meines Haushaltes > ausprobiert (ca. 7Stk) jedoch erfolglos. Benötige ich für RC5 eine > spezielle Fernbedienung? Ich hatte mir deswegen eine programmierbare/einstellbare Universalfernbedienung für 9,95€ gegönnt. Conrad Artikel-Nr.: 340720 http://www.mikrocontroller.net/articles/Pollin_Funk-AVR-Evaluationsboard#RC5_Empf.C3.A4nger > Was mich auch irritiert, ist das am dem IR-Port ein dauerhaftes High > anliegt und bei empfang eines IR Signals auf Low geschaltet wird. Is das > richtig? Richtig.
Ich habe auch Probleme mit dem IR_Empfänger (TSOP 1136). Wenn ich das Addonboard mit Spannung versorge kann ich auf meinen Oskar kurze Spannungs flips nach Masse sehen. Woher kommt das?<
Hi Jungs, noch ein Neuling in der Welt der Mikroelektronik ;) Hab das Board nun auch seit zwei Tagen, korrekt aufgebaut, auch zum laufen gebracht... Natürlich erstmal in die typische Falle mit Rs232 reingefallen und dann noch die Fusebits -_- Testprogramm ist drauf! Aber das Ding läuft, hab gerade ein Atmega16 drin. Nunja jetzt wollt ich mal schauen was das Ding über Hyperterminal von sich gibt. Also mit 9600 Baud, 8 Databits, 1 Stopbits, Parity und Flow control auf none macht der bei Windows (XP) Hyperterminal nichts, erst bei 1200 Baud, und da zeigt der mir, nur wenn ich den Taster 3 (Schalter für diesen Brummer) irgendwas an... PuTTy zweigt bei 9600 Baud auch nur beim Brummer was an. Alle Jumper sind drauf! Normalerweise müsste ich, für alles was ich da mache irgendein Signal, Ausruf wie auch immer sehen, gell? Was könnte hier der Fehler sein? Vielen Dank schonmal
Es ist richtig, dass bei dem Pollin Testtool nur beim Drücken von Taster3 das Board etwas über die serielle Schnittstelle sendet. Das steht jedenfalls so in der Beschreibung des Testtools. Hast du die gesetzten AVR Fuses genau kontrolliert? 9600/1200 = 8 und es gibt eine Fuse CKDIV8, die - wenn aktiviert und das ist sie im Auslieferungszustand! - den anliegenden Takt durch 8 teilt... Tipp: "irgendwas" ist für eine Fehlerbeschreibung Sch**sse. Gib dir Mühe, die Helfer nicht raten zu lassen.
Wenn der Atmeg16 keine CKDIV8 Fuses hat (es gibt AVRs die diese Fuse nicht haben!), dann die Fuses für die Taktquelle kontrollieren. Das Testtool setzt eine externe Taktquelle 8 MHz und korrekt darauf eingestellte Fuses voraus. Wenn die externe Taktquelle zwar vorhanden ist, aber die Fuses noch mit der internen RC-Oszillator-Taktquelle 1 MHz arbeiten hast du auch den Faktor 8 MHz/1 MHz = 8 drin.
Also mit 1200 Baud zeigt dieser "±þ" an, bei 9600 Baud "FCÏ( æÇá¤Dó" Programm PuTTy. Ok, hatte irgendwie im Hinterkopf gehabt das alle Tasten angezeigt werden, nicht nur die Taste 3. Wer lesen kann ist klar im Vorteil :) Deswegen wars mir erstmal Wurscht was der angezeigt hat, hauptsache was sehen können ;) nichtsdesto trotz hast du Recht Stefan! Dennoch wärs interessant zu wissen, warum der bei verschiedenen Baudeinstellungen so nen Heckmeck macht. Mit den Fusebits werde ich mich gleich auseinander setzen. Vielen Dank für die Antworten
Stefan B. schrieb:
> http://www.mikrocontroller.net/articles/Pollin_Fun...
was ist eigentlich zu beachten, wenn ich für diese Beispielprogramme
nicht das Pollin-Fun-Board, sndern das Pollin ATMEL-Evaluations-Board
2.0 verwenden will?
Gruß
Dietrich
Ich habe die Schaltpläne beider Boards nicht genau verglichen. Bei dem Pollin Funk-AVR-Evaluationsboard sind, wenn nach Pollin aufgebaut: - Drei unterschiedliche Quarze: Kleinste Fassung (Attiny2313 und Co.) 8 MHz mittlere Fassung (Atmega9 und Co.) 12 MHz große Fassung (Atmega16 und Co.) 16 MHz - Nur ein Taster active high geschaltet an PB1 - Nur zwei rote LEDs active high geschaltet an PD5 und PD6 - Kein Summer/Buzzer - In meiner älteren Version: keine Jumper Wenn du Hilfe bei der Umsetzung brauchst, frage einfach. Normalerweise lese ich alle Beiträge mit Pollin im Betreff. Die meisten beantworte ich auch.
Hallo, Ich habe mir auch das Evaluationsboard und das Addon Board von Pollin zugelegt. Leider habe ich bisher noch nichts hingekriegt, da ich weder mit PonyProg noch mit avrdude an den AtTiny2313 drankomme. Ich habe schonmal alle Kontakte nachgelötet. Kann mir jemand einen Tipp geben, wie ich weiter komme? Wollte erstmal nur die beiden LEDs einschalten...:
1 | #include <avr/io.h> |
2 | |
3 | int main (void) { |
4 | |
5 | DDRD = 0b00110000; |
6 | PORTD = 0b00110000; |
7 | |
8 | while(1) { |
9 | /* "leere" Schleife*/
|
10 | }
|
11 | |
12 | return 0; |
13 | }
|
LG
ich schiebe nochmal eben den avrdude Aufruf nach. Ist unter Linux.
1 | linux-x34h:/home/jw-lighting # avrdude -p t2313 -P /dev/ttyS0 -c siprog -U flash:w:main.hex |
2 | avrdude: AVR device not responding |
3 | avrdude: initialization failed, rc=-1 |
4 | Double check connections and try again, or use -F to override |
5 | this check. |
6 | |
7 | |
8 | avrdude done. Thank you. |
Hast du das Board selbst gelötet? AVR aus der IC Fassung nehmen. Drahtbrücke an der Fassung zwischen MISO und MOSI setzen (s. [[AVR In System Programmer]]). AVRDUDE mit zusätzlicher Option -vvv (vielleicht reicht auch -vv oder -v) laufen lassen. AVRDUDE sollte jetzt jedes gesendete Byte auch zurückbekommen. Das erscheint in der ausführlichen (verbose) Ausgabe von AVRDUDE. Das mitschneiden und hier als Text anhängen. Dann sieht man, ob die Kommunikation zur IC-Fassung und zurück funktioniert. SpionLEDs (Low-current-LED mit Vorwiderstand) an die SCK Leitung hängen. Alternativ eine der LEDs auf dem Board entsprechend brücken (Vorwiderstand so groß wähen, dass man gerade nmoch ein Leuchten sieht, denn das sind keine low-Current-LEDs) Diese LED muss blinken (ggf. Baudrate in AVRDUDE mit -b Option auf sehr langsam stellen z.B. 2400 BAUD). Beim Programmieren Spannung zwischen RESET und GND messen; die sollte ca. 0 V sein. Alle Tests zeigen, ob überhalt was vom Programmer an der IC-Fassung ankommt. Vcc und GND an der Fassung auch mit dem Voltmeter kontrollieren.
Hallo Stefan, erstmal vielen Dank für deine Hilfe. Hier mal die Ausgabe von avrdude mit -vvv:
1 | linux-x34h:/home/jw-lighting # avrdude -p t2313 -P /dev/ttyS0 -c siprog -U flash:w:main.hex -vvv |
2 | |
3 | avrdude: Version 5.5, compiled on Dec 3 2008 at 17:06:50 |
4 | Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ |
5 | |
6 | System wide configuration file is "/opt/cross/etc/avrdude.conf" |
7 | User configuration file is "/root/.avrduderc" |
8 | User configuration file does not exist or is not a regular file, skipping |
9 | |
10 | Using Port : /dev/ttyS0 |
11 | Using Programmer : siprog |
12 | AVR Part : ATtiny2313 |
13 | Chip Erase delay : 9000 us |
14 | PAGEL : PD4 |
15 | BS2 : PD6 |
16 | RESET disposition : possible i/o |
17 | RETRY pulse : SCK |
18 | serial program mode : yes |
19 | parallel program mode : yes |
20 | Timeout : 200 |
21 | StabDelay : 100 |
22 | CmdexeDelay : 25 |
23 | SyncLoops : 32 |
24 | ByteDelay : 0 |
25 | PollIndex : 3 |
26 | PollValue : 0x53 |
27 | Memory Detail : |
28 | |
29 | Block Poll Page Polled |
30 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
31 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
32 | eeprom 65 6 4 0 no 128 4 0 4000 4500 0xff 0xff |
33 | Block Poll Page Polled |
34 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
35 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
36 | flash 65 6 32 0 yes 2048 32 64 4500 4500 0xff 0xff |
37 | Block Poll Page Polled |
38 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
39 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
40 | signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 |
41 | Block Poll Page Polled |
42 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
43 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
44 | lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
45 | Block Poll Page Polled |
46 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
47 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
48 | lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
49 | Block Poll Page Polled |
50 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
51 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
52 | hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
53 | Block Poll Page Polled |
54 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
55 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
56 | efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
57 | Block Poll Page Polled |
58 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
59 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
60 | calibration 0 0 0 0 no 2 0 0 0 0 0x00 0x00 |
61 | |
62 | Programmer Type : SERBB |
63 | Description : Lancos SI-Prog <http://www.lancos.com/siprogsch.html> |
64 | |
65 | avrdude: Calibrating delay loop... calibrated to 381 cycles per us |
66 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
67 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
68 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
69 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
70 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
71 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
72 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
73 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
74 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
75 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
76 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
77 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
78 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
79 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
80 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
81 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
82 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
83 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
84 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
85 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
86 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
87 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
88 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
89 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
90 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
91 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
92 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
93 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
94 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
95 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
96 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
97 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
98 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
99 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
100 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
101 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
102 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
103 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
104 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
105 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
106 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
107 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
108 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
109 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
110 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
111 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
112 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
113 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
114 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
115 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
116 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
117 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
118 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
119 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
120 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
121 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
122 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
123 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
124 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
125 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
126 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
127 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
128 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
129 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
130 | bitbang_cmd(): [ AC 53 00 00 ] [ 00 00 00 00 ] |
131 | avrdude: AVR device not responding |
132 | avrdude: initialization failed, rc=-1 |
133 | Double check connections and try again, or use -F to override |
134 | this check. |
135 | |
136 | |
137 | avrdude done. Thank you. |
Die LED blinkt. Ich könnte mir denken, dass das Bitgewackel am seriellen Ausgang zu schnell ist. Habe mit -i auch schon zwischen 1 und 900ms mal durchprobiert, weiss aber nicht welchen Wert ich dort verwenden soll. Kannst du mir einen Tipp geben, welche Einstellungen da gut wären? LG: Jan
Wenn das die Ausgabe ohne AVR und mit MISO-MOSI Drahtbrücke ist, dann stimmt was grundsätzlich nicht: AVRDUDE sendet ([ AC 53 00 00 ]) bekommt aber quasi nix ([ 00 00 00 00 ]) zurück. Welches Kabel benutzt du zwischen PC und dem Pollinboard? Das muss ein 1:1 geschaltetes Kabel sein, kein sog. Nullmodemkabel mit gekreuzten Leitungen. Sicher ist sicher: Das Kabel muss an der DB9-Buchse für den Programmer angeschlossen sein, nicht an der DB9-Buchse für die RS232-Übertragung.
Hallo Stefan, Ich habe den richtigen Anschluss gewählt ;) Ich habs grade nochmal gemacht - selbe Ausgabe. Das Kabel habe ich von einem Freund bekommen, ist aus einen Franzislernpaket für Experimente mit der seriellen Schnittstelle. Ich messe das Kabel jetzt mal durch... LG und nochmal vielen Dank ;) jan EDIT: Negativ. das Kabel ist 1:1 belegt. Wie siehts mit den Delayzeiten aus?
Wenn du das Franzis Mikrocontrollerpaket mit dem Attiny13 meinst, müsste das 9-polige Kabel ein 1:1-Kabel sein (lt. Foto und Schaltplan auf http://www.elo-web.de/elo/mikrocontroller-und-programmierung/avr-grundlagen/lernpaket-mikrocontroller-fehlersuche). Messen schadet aber nicht.
Ich habe im Moment keine anderen Ideen, sorry. Ich könnte heute abend versuchen, die Windows- und die Linuxversion von AVRDUDE mit meinem Pollin-Funk-Board zu testen. Welches Linux hast du im Einsatz? Wenn es eine Live-Version davon gibt, würde ich das dann auch für diesen Test nehmen.
Habe SuSE 11.1. Könnte mir noch vorstellen, das die settings im BIOS nicht stimmen. Dort kann ich mehrere Busaddressen auswählen. Vielleicht kann ja jmd. einen Tipp geben, was dort meist richtig ist. LG: jan
Das spielt IMHO beim seriellen Programmer keine Rolle, letztendlich kapselt das Device /dev/ttyS0 diesen Lowlevelkram. Opensuse 11.2 habe ich als LiveCD rumliegen, allerdings ist diese Distro bei mir ätzend lahm. Mal sehen.
Der Grund, weshalb ich das nicht längst geupdated habe. (Und weil ich KDE4..., naja, nicht so mag) Ich messe jetzt das Kabel von der Steckerleiste auf dem Motherboard auf eine Blende mit D-Sub9 durch, was den COM-Port rausführt. Anderer Tipp war noch, statt siprog mal ponyser zu benutzen, hat bisher aber auch nicht funktioniert... naja, vielleicht geschieht ja noch ein Wunder ;) LG
Wenn du die Einträge in der avrdude.conf vergleichst, siehst du: siprog ist das gleiche wie ponyser. Ich dachte zuerst auch, dass es daran hängen könnte. Bei Opensuse habe ich aufgegeben ;-( Ich hatte den Willen. Aber in 1,5h habe ich es nicht geschafft, AVRDUDE im LiveCD-System zu installieren. Nachdem ich den dicken Klopper überwunden hatte (die LiveCD wollte sich ein >570 MB Update gönne, bevor es das Paket AVRDUDE installiert) fror mein Rechner nach ca. 80% Fortschritt bei der AVRDUDE-Installation ein.
Hi Mal eine Frage, seid ihr sicher, kein Null.Modem Kabel? Also, ich habe auch das Pollin-Board, eigentlich beide, Funk-AVR-Evaluations-Board und ATMEL Evaluations-Board V2.0.1, wobei ich bisher nur letzteres benutzt habe. Dazu benutze ich ein Null-Modem Kabel, also RxD und TxD gekreuzt. Damit hab ich bisher keinerlei Probleme, weder beim flashen noch bei der seriellen Datenübertragung. Bin davon ausgegangen, das beide Board's zumindest von den Schnittstellen gleichermaßen beschaltet sind. Ich benutze unter Win AVR Studio und PonyProg. Bisher keinerlei Problem. Gruß oldmax
Also ich hab das Evolution Board und da brauchst du auf jeden Fall ein 1:1 Kabel.
@oldmax: Wo hast du denn das Kabel her? Es braucht ja ein männliches und ein weibliches Ende. Die fertig zu kaufenden Nullmodemkabel haben m.W. durchweg 2xWeibchen, da sie zwei DTE verbinden (z.B. PC mit 9-pol. männlich).
Hi Also, das Kabel hab ich mir selbst angefertigt, m/w alles 1:1 bis auf TxD und RxD, Die sind gedreht. am PC natürlich eine saubere Com1, wie sich's gehört. Aber ihr verwirrt mich etwas. Da ich jetzt keinen Zugriff auf mein Kabel zur Kontrolle meiner Aussage habe, werd ich's heut nachmittag noch mal prüfen. Ich könnt jedoch schwören, die sind gekreuzt.... da ich das Kabel auch für direkte Kommunikation mit PC benutzt hab. Asche auf mein Haupt... ich hab mir grad mal die Schaltpläne und die Belegungen angesehen. Danach ist 1:1 Beschaltung erforderlich. Ich glaub, ich werd alt....... Gruß oldmax
Moin, vielen Dank für die vielen Antworten. Leider ist das Problem noch nicht gelöst, und ich komme nicht weiter dabei die Belegung von dem kabel vom Board nach aussen zu prüfen, da die Bezeichnungen der Pins verschieden sind. Hier mal die Tabelle aus dem MoBo Handbuch. Hoffentlich kann mir von euch jmd. sagen, was welcher Bezeichnung in den anderen Definitionen entspricht, und welcher Pin das sein müsste: 1: NDCD- 2: NSIN 3: NSOUT 4: NDTR- 5: GND (Ground) 6: NDSR- 7: NRTS- 8: NCTS- 9: NRI- (10: No Pin) Von der Pfostenleiste (s.o.) 1:1 auf den D-Sub. ich habe auch mal einen anderen AVR reingesetzt, bisher kein Erfolg... LG: jan
No panic! Lass das PC-Mainboard in Ruhe ;) Das wird schon stimmen. Wenn du einen Multimeter hast, dann an dem Kabelstecker die Spannung zwischen Pin 3 und Pin 5. Schwarze (COM) Leitung vom Multimeter auf Pin 5. Spannungsbereich DC ca. 20V. Hast du inzwischen weitere Messergebnisse zu den vorgeschlagenen Tests aus Beitrag "Re: Pollin Atmel Evaluations-Board & Co. - Fragen" mit der MOSI-MISO-Brücke Also die Messung am RESET-Pin der IC-Fassung steht aus. Und - oben nicht erwähnt - die Messung der Vcc und GND an der IC-Fassung Du hast ja die Spion-LED. Die hängst du von der Verbindung R2/D2 kommend an die MOSI-Leitung an verschiedene Punkte bis zur IC-Fassung und dann von dort kommend an der MOSI-Leitung zurück zur J3-Buchse. Andere Leitung der SpionLED an ein GND, z.B. Pin5 der J3 oder GND der IC-Fassung. Pin5 und GND an der IC-Fassung sollten beide gleiches Ergebnis bringen. Wenn nicht ist was mit GND faul. Jetzt immer wieder AVRDUDE senden lassen. Vielleicht findest du eine Stelle, an de dein Signal verloren geht (LED flackert nicht mehr). Zum Anpieken einer Leiterbahn oder eines Lötpads eignet sich was Spitzes wie eine Stecknadel. Stahl lässt sich aber sehr schlecht löten, also die eine Seite der SpionLED mit einer Krokoklemme o.ä. an der Stecknadel festmachen.
So ich habe jetzt ein anderes LiveCD Linux genommen: RCOS http://wiki.rcos.eu/index.php/RCOS-LiveCD Das ist eine angenehm schlanke Debian-LiveCD mit etlichen Toolchains extra für die µC Arbeit. Auf der LiveCD ist auch ein AVRDUDE 5.5 drauf. 1. Test: Pollin Funk AVR Board avrdude -v -P /dev/ttyS0 -p t2313 -c siprog Gleicher Fehler wie bei dir :( Freude kann Fehler reproduzieren. 2. Test: Zurück zu Windows 98SE. AVRDUDE (auch 5.5) ausprobiert. avrdude -v -P COM1 -p t2313 -c siprog Gleicher Fehler wie bei dir :( PANIK! Ponyprog2000 ausprobiert. Gleicher Fehler wie bei dir :( Noch mehr PANIK! 3. Test: Hardware überprüft. An 2. ISP Anschluss habe ich ja noch einen STK200-kompatiblen ISP-Adapter angesteckt! Diesen habe ich abgezogen. AVRDUDE ausprobiert. avrdude -v -P COM1 -p t2313 -c siprog Kein Fehler mehr :) 4. Test: Zurück zur Linux/RCOS LiveCD AVRDUDE ausprobiert. avrdude -v -P /dev/ttyS0 -p t2313 -c siprog Kein Fehler mehr :) Fazit 1. Die Kombination Bitbang-Programmer (serbb im AVRDUDE Sprachgebrauch) von Pollin und AVRDUDE 5.5 ist grundsätzlich lauffähig 2. Der Pollin serbb lässt sich durch einen angeschlossenen Programmer am zweiten ISP Port stören Vorschläge 1. Kontrolliere die Hardware wie oben vorgeschlagen. 2. Achte zusätzlich auf die Leiterbahnen und Lötstellen in Richtung des zweiten ISP-Anschlusses. Messe die Pins am zweiten ISP Anschluss durch, ob du eventuell dort Verbindungen hast.
Versorgungungsspannung zwischen Pin 20 und Pin 10: 5V -> OK Spannungsabfall an Reset: nicht feststellbar -> !Fehler! -> Verwendeter Befehl: avrdude -p t2313 -P /dev/ttyS0 -c siprog -U flash:w:main.hex -v -F -b 2400 Spion LED an Miso: Blink auf der ganzen Strecke, bis Pin 17 am IC-Sockel. Verschiedene Stellen für GND getestet, alle funktionieren. Verbindungen zwischen den Polen an J1 (ISP), kein AVR eingesetzt: [---- (Format: Pin; 1/0 für Piepst/Piepst nicht zahlenwert von der Diodenmessung (Messgerät: Peaktech 2010)) Beispiel: 3; 1,765 hat gepiepst, Display zeigt 765, Messung an Pin 3 Von Pin an Mess-COM, zu Pin an Messleitung rot ----] Von Pin2 (VCC) aus zu 6,8,10; 1, Overload 1; 0, Overload 5; 0, 1937 7; 0, Overload 9; 0, Overload Von Pin 6,8,10 (GND) aus zu 1; 0, 757 5; 0, 805 7; 0, 756 9; 0, 1836 Von Pin 1 aus zu 5; 0, 470 7; 1, 26 9; 0, 1593 Von Pin 5 aus zu 7; 0, Overload 9; 0, Overload Von Pin 7 aus zu 9; 0, 1600 Gefundene Verbindungen: 7 -> 1 (SCK -> Mosi) !!! Wie soll ich weitermachen? Die Platine hat keine sichtbaren Fehler. Als Ersatz für den Reset-Transistor hätte ich BC547 da. LG: Jan EDIT: Die Belegung MoBo > SubD ist doch NICHT 1:1. Ich bin mir auch nicht sicher das das unbedingt richtig belegt ist, da ich das Kabel mal bei reichelt nachgekauft habe, und diese Verwendung dort nicht angegeben war (aber einige andere) MoBo > SubD 1 > 1 2 > 6 3 > 2 4 > 7 5 > 3 6 > 8 7 > 4 8 > 9 9 > 5 10 > NC
Bei diesem Anschluss 1: NDCD- 2: NSIN 3: NSOUT 4: NDTR- 5: GND (Ground) 6: NDSR- 7: NRTS- 8: NCTS- 9: NRI- (10: No Pin) bedeuten MoBo Bedeutung Pin an DB9 ------------------------------ NSIN RXD 2 NSOUT TXD 3 GND GND 5 ... Die anderen habe ich nicht geprüft, schätze aber die kann man 1:1 der RS232 Pinbelegung einer DB9 zuordnen. Dies: MoBo > SubD 1 > 1 2 > 6 3 > 2 4 > 7 5 > 3 6 > 8 7 > 4 8 > 9 9 > 5 10 > NC verstehe ich komplett nicht. Bist du sicher, dass du die Pinnummerierung beim Betrachten der Pins richtig gemacht hast? Normalerweise ist das "narrensicher" Auf dem Mainboard ist entweder die DB9 fest verlötet oder es gibt einen z.B. 2x5 Stecker mit Flachbandkabel und DB9-Buchse (männlich), den man auf einen Wannenbuchse auf dem MoBo aufsteckt. > Versorgungungsspannung zwischen Pin 20 und Pin 10: 5V -> OK Gut. > Spannungsabfall an Reset: nicht feststellbar -> !Fehler! Schlecht. Das verhindert jedes ISP-Programmieren! Die Resetsteuerung könnte an T1 nicht ankommen, T1 könnte defekt sein oder die Resetleitung könnte noch eine andere Verbindung zu Vcc als über R3 haben. Hier ansetzen. RS232 Kabel von J6 abziehen. Spannung zwischen Pin3 (TXD) und GND am Stecker messen. Mutimeter DC Messung 20V Bereich. Ruhespannung ohne AVR hat bei mir ca. -10 V. Bei Aktion von AVRDUDE ändert sich der Messwert kurzzeitig. Mal messe ich -8V, mal -2V mal. Wichtig ist, dass sich was ändert. RS232-Kabel auf J6 aufstecken. Die Änderung durch den AVRDUDE Befehl muss synchron auch an der Basis des Transitors T1 ankommen und an den beiden Enden der Verbindung zwischen T1 und R3 (Resetwiderstand) und letztendlich auch an Pin1 von IC3 (Resetpin) R3 einseitig auslöten. Spannung auf der Resetleitung messen. Ohne den Pullup R3 sollte die 0 sein. > Verwendeter Befehl: avrdude -p t2313 -P /dev/ttyS0 -c siprog -U > flash:w:main.hex -v -F -b 2400 Solange RESET nicht funktioniert hat das Reinflashen keinen Zweck. Solange der Programmer nicht 100% funktioniert nichts in den AVR schreiben. Funktion von AVRDUDE / ISP-Programmer teste ich oben mit avrdude -v -p t2313 -P /dev/ttyS0 -c siprog allein. Es besteht dann keine Gefahr, dass der AVR verhunzt wird. > Verbindungen zwischen den Polen an J1 (ISP), kein AVR eingesetzt: > Gefundene Verbindungen: 7 -> 1 (SCK -> Mosi) !!! Geh dieser Sache nach. Versuche herauszufinden, wo die beiden Verbindung haben. Vergiss die J4 Buchse nicht, dort liegen SCK und MOSI auf Pin 16/14 direkt nebeneinander. Die Wahrscheinlichkeit einer Lötbrücke ist dort höher. Andere IC Fassungen auch checken (Durchgangsprüfer). Und das Gebiet um die Bauteile des RS232-ISP. Hast du das Board selbst gelötet? > Spion LED an Miso: Blink auf der ganzen Strecke, bis Pin 17 am > IC-Sockel. Verschiedene Stellen für GND getestet, alle funktionieren. Und Rückweg bei eingesetzter MOSI/MISO Brücke? Ist aber weniger wichtig, konzentriere dich erstmal auf das RESET und das SCK-MOSI Problem.
Bezüglich der Wannenbuchse auf dem MoBo > DB9: Steinigt mich, ich habe die Pins an der Wannenbuchse wie bei einem IC durchgezählt. Sorry. Ist dann wohl 1:1 Meinst du wirklich J6? Das ist der RS-232 Anschluss zur Kommunikation mit einem PC, nicht der ISP Anschluss für den Anschluss an seriell zum programmieren (der wäre J3). J4 sieht ok aus. Die IC Sockel auf der Lötseite auch. Ich habe das Board selbst gelötet, würde mich aber eindeutig nicht als schlechten Löter bezeichnen. Wenn es weiterhilft kann ich mal Fotos von der Unterseite der Platine machen. Die anderen Sachen werde ich später mal nachmessen. Schreibe morgen eine Arbeit, daher habe ich heute nicht soviel Zeit. Noch zur Info: Mit dem Resettaster kann ich die Spannung problemlos auf 0V runterziehen. Kann ich den Transistor mit einem BC547 austauschen? Dann würde ich das gleich mal machen. Habe BC547 und BC557 da. Vielen Dank nochmal für die Hilfe!! LG: jan
> Kann ich den Transistor mit einem BC547 austauschen? Ja, BC546, 547 und 548 sind praktisch identisch, nur die zulässige Kollektor-Emitter-Spannung ist unterschiedlich. Also kein Problem. Noch was: Ich habe dieses Board auch, und hatte damit auch mal ein Problem: Da die D-Sub-Stecker doch recht schwergängig sind, ist mir mal nach einigen Steckzyklen eine der Lötstellen gerissen und hatte keinen Kontakt mehr. Nachlöten löste dieses Problem dann erstmal.
> Meinst du wirklich J6? Das ist der RS-232 Anschluss zur Kommunikation > mit einem PC, nicht der ISP Anschluss für den Anschluss an seriell zum > programmieren (der wäre J3). J3, sorry. > Noch zur Info: Mit dem Resettaster kann ich die Spannung problemlos auf > 0V runterziehen. Kann ich den Transistor mit einem BC547 austauschen? > Dann würde ich das gleich mal machen. Habe BC547 und BC557 da. Dann könntest du mal den RESET gedrückt halten und AVRDUDE ausführen. Wenn nur der T1 nicht funktioniert, also vom PC der AVR nicht in den RESET zu bringen ist, sollte der AVR bei gedrücktem RESET erkannt werden. Kontrolliere in dem Fall auch mal den Wert von R3. Vielleicht ist der zu niederohmig.
Reset Taster drücken bringt es nicht. Das Problem bleibt. Teste ich mit eingestecktem AVR bei einem anderen Sockel mit der Spion-LED, habe ich folgendes Ergebnis: SCK: Leuchten Mosi: Blinken (Flackern) Miso: Nichts Wenn ich während des Programmierens die Spannung an der Transistorbasis messe, sind das durchgängig 0V. Die Spannung an Reset sind 5V (es sei den ich drücke den Taster), und die Spion-LED 'glimmt' daran sogar R3 sind nur 7,9k Ich habe 10k Widerstände da, soll ich den austauschen?? Nachgelötet habe ich eigentlich schonmal, aber es kann ja nicht schaden ;) LG: jan
> Reset Taster drücken bringt es nicht. Das Problem bleibt. War nur eine schwache Hoffnung. SCK-MOSI ist ja auch noch ein Problem. > Teste ich mit > eingestecktem AVR bei einem anderen Sockel mit der Spion-LED, habe ich > folgendes Ergebnis: > SCK: Leuchten > Mosi: Blinken (Flackern) > Miso: Nichts Kann am SCK-MOSI Problem liegen. Nur um das abzusichern: Alle Kabel abgezogen, kein AVR drin. Jetzt mit Multimeter den Widerstand zwischen SCK und MOSI an einer der IC Fassungen messen. Wenn du schon dabei bist: Widerstand zwischen MISO und MOSI auch messen. Die Widerstände sollten im Idealfall unendlich sein. > Wenn ich während des Programmierens die Spannung an der Transistorbasis > messe, sind das durchgängig 0V. Die Spannung an Reset sind 5V (es sei > den ich drücke den Taster), Dann ist zwischen PC und T1 nachzuforschen. Entweder kommt vom PC kein Steuersignal an die Basis von T1, um den aufzumachen und dadurch die RESET-Leitung auf LOW zu ziehen. Die Spannungsmessung zwischen Pin3 (TXD) und Pin5 (GND) am Kabelende (J3) wäre ein erster Hinweis. Oder es kommt ein Steuersignal, aber das wird durch eine starken Pulldownverbindung auf LOW gezogen, so dass es T1 auch nicht aufsteuert. > R3 sind nur 7,9k Ich habe 10k Widerstände da, soll ich den austauschen?? Wenn du eh lötest, schadet es nicht. Wird aber auch nicht viel helfen. Mit 7K9 sollte es auch gehen. Ich warte mal auf den Test mit Drahtbrücke statt AVR, wenn du mit der SpionLED der MISO Leitung nachgegangen bist. Die sollte gleiches Verhalten wie die MOSI Leitung zeigen. Aussagekräftig ist dieser Test allerdings nur, wenn das SCK-MOSI Problem nicht vorliegt oder gefixt ist.
Hallo, ich habe jetzt mal die Spannung zwischen Pin 3 und 5 am RS-232 Anschluss gemessen (Pin 3 und GND): 0V ! Alle anderen Pins auch 0V. AVR ist nicht drin. Ich vermute fast schon, das ich die serielle Schnittstelle geschossen habe. Ich habe noch einen anderen Rechner da, auf den ich mich mit NFS drauf komme. Ich versuche mal avrdude dort zu installieren, und probiers damit. LG: Jan
So, bei dem anderen Rechner habe ich jetzt zwischen Pin 3 und 5 auf jeden Fall schonmal -10V. Den Rest werde ich ja gleich erleben. So, ich habe ihn erlebt: Ging sofort. Es lag also wohl die größte Zeit lang am Motherboard oder doch dem Kabel dazwischen. Vielen Dank nochmal allen die geholfen haben!! Einen Lerneffekt hinterlassen hat es auf jeden Fall. Nun habe ich ein paar andere Fragen. 1. Wenn ich an einem AVR einen Port mit weniger als 8 I/O habe, wie spreche ich die Pins dann an. Bei meinem Beispiel oben, habe ich jetzt PD4 und PD5 auf high, also nicht PD5 und PD6 obwohl ich ja die Bits 5 und 6 auf high habe. 2. Ich habe mir KontrollerLab runtergeladen, finde aber keine Datei configure im Gesamten Paket, daher kann ich nicht kompilieren. was tun? 3. Angenommen ich arbeite ohne spezielle AVR GUI. libc, gcc und avrgcc sind auf meiner Linux Kiste installiert. Wie kann ich die Quellcodedatein kompilieren? (Einmal der ganze Weg von xyz.c bis zur fertigen xyz.hex) LG: Jan
Jan W. schrieb: > 1. Wenn ich an einem AVR einen Port mit weniger als 8 I/O habe, wie > spreche ich die Pins dann an. Bei meinem Beispiel oben, habe ich jetzt > PD4 und PD5 auf high, also nicht PD5 und PD6 obwohl ich ja die Bits 5 > und 6 auf high habe. Wenn ich die Verworrenheit der Frage angemessen würdige und nicht dir die Schuld dafür gebe, erinnert es mich daran, daß die Pins auf dem Atmel-Board ziemlich krank beschriftet sind. PD1 auf dem Board hat nicht viel mit PD1 am AVR zu tun. Schaltplan nehmen, darin Gedanken den aktuellen MC einsetzen und die Leitungen verfolgen, ist das einig Sinnvolle.
Jan W. schrieb: > 3. Angenommen ich arbeite ohne spezielle AVR GUI. libc, gcc und avrgcc > sind auf meiner Linux Kiste installiert. Wie kann ich die > Quellcodedatein kompilieren? (Einmal der ganze Weg von xyz.c bis zur > fertigen xyz.hex) Die Headerdateien und Libs des Linuxsystems sind nicht die, die du für AVR-Programme brauchst. Wenn man gcc aufruft, wird für Linux kompiliert. Mit avr-gcc dagegen werden (wenn alles ordentlich installiert ist) nicht nur ein anderer gcc genommen, sondern auch die dafür passenden *.h und Libs. Für die Einzelschritte am besten ein funktionierendes makefile anschauen und daraus die Aufrufe klauen.
Sorry, aber wenn ich an Pin 8 und Pin 9 des AtTiny2313 messe, habe ich 5V, alle anderen I/O 0V. Im Schaltplan aus der Anleitung vom Eval.-Board sind diese beiden Pins mit PD4 und PD5 beschriftet. PD7 gibt es nicht. warte.. Während des darüber Nachdenkens fällt mir grade auf, dass ich da einen Denkfehler begangen habe. Stimmt ja alles.. Mensch, mensch. Sorry. Muss mich erstmal gewöhnen von 0 zu zählen.. Ich gehe also recht in der Annahme, das ich die oberen, nicht belegten Bits des Registers einfach ignorieren muss? Dann wären jetzt nurnoch Punk 2 und 3 über. LG
Puh, da bin ich echt erleichtert, dass diese Sache aufgeklärt ist. war ja echt eine lange Nummer ;) > Obere Bits Ja einfach ignorieren. Am einfachsten finde ich die Bitmanipulation aus dem gleichnamigen Artikel. Bit setzen: PORTx |= (1<<Pinnummer) Bit löschen: PORTx &= ~(1<<Pinnummer) Bit toggeln: PORTx ^= (1<<Pinnummer) Bei dem Linux... sorry damit arbeite ich nicht. Du könntest dir aber die RCOS LiveCD ansehen. Dort ist die AVR Toolchain bereits installiert (und andere Toolchains). http://www.rcos.eu => Wiki => LiveCD. Vielleicht hilft das die eine Toolchain auf deinem Linux hochzuziehen.
Hallo, hatte demnächst vor ein paar ATtiny13-20 zu programmieren. Auf Arbeit habe ich eines dieser besagten Atmel Evaluationsboards V2.0.1. Kann ich damit den ATtiny13-20 ohne Probleme beschreiben, da in der Info zum Board nur ATtiny12 & 15 aufgeführt sind. Besten Dank. Grüße George
Stefan B. schrieb: > Bei dem Linux... sorry damit arbeite ich nicht. Du könntest dir aber die > RCOS LiveCD ansehen. Dort ist die AVR Toolchain bereits installiert (und > andere Toolchains). http://www.rcos.eu => Wiki => LiveCD. Vielleicht > hilft das die eine Toolchain auf deinem Linux hochzuziehen. Das Image habe ich schon länger runtergeladen. dann werde ich mal gucken, ob ich mir daraus was ableiten kann ;) LG: Jan
Ich verzweifel grade mit dem root Passwort. Sonst kann ich meinen Rechner zum flashen nicht mounten :p Habe schon alles möglich ausprobiert, und google weiß auch keinen rat... lg. jan
Hatte ich auch. Du musst zuerst über sudo ein Passwort für root mit passwd setzen. Dann erst kannst du es im su benutzen. Also so etwa: $ sudo passwd (bzw. vielleicht auch sudo passwd root, Mist ist erst paar Tage her) ... Passwort ändern bzw. neu eingeben ... $ su Passwort: ... hier das neue Passwort eingeben ...
Nachtrag: Also einmal in die Usershell von RCOS einloggen musst du schaffen, damit obiges klappt.
reicht es nicht, wenn ich einfach die konsole aufmache und sudo ausführe? Entschiuldige die dumme Frage, aber wie logge ich mich den in die Usershell ein? Ich kenne den Begriff einfach nicht -.- Btw. Ich mache hier seltsame Beobachtungen: Ich habe das Programm von oben etwas umgeschrieben, sodass es beide LEDs benutzt an sind und man mit Taster1 Led1 austasten kann:
1 | #include <avr/io.h> // (1) |
2 | |
3 | int main (void) { // (2) |
4 | |
5 | DDRD = 0b01100000; // (3) |
6 | PORTD = 0b01000000; // (4) |
7 | |
8 | while(1) { // (5a) |
9 | if((PIND & 0b00000010) != 0){ |
10 | PORTD = 0b01000000; |
11 | }
|
12 | else{ |
13 | PORTD = 0b01100000; |
14 | }
|
15 | } // (5c) |
16 | |
17 | /* wird nie erreicht */
|
18 | return 0; // (6) |
19 | }
|
Allerdings habe ich andauernd das Gefühl, der µC hängt sich auf, und reagiert nicht auf das drücken des Tasters. Drücke ich die beiden anderen Taster gleichzeitig, tut es nur noch ein Reset über mehrere Sekunden. Ich habe sogar festgestellt, das die LED immer ausgeht wenn ich an dem Board, was auf dem Tisch liegt, vorbeigehe... Kommt mir ein wenig mystisch vor. Bringt es vielleicht schon was, wenn ich alle nicht gebrauchten IOs als Out definiere, sodass dann keine Signale von aussen mehr beeinflussen werden? lg. jan
Konsole ist das was ich mit Usershell meine, die Shell in der der User Kommandos eintippt. Leider hast du im Quellcode keine Markierung welche Änderungen du gemacht hast. Das macht Erklärungen schwer. Gemäß Zeile (4) sollte anfangs nur eine LED an sein, die LED an PD6. Die LED an PD5 sollte aus sein. Du arbeitest mit dem Taster an PD1. Wenn der gedrückt wird, soll die LED an PD5 ausgeschaltet. Wenn der losgelassen ist, werden die LEDs an PD6 und PD5 angeschaltet. Weil du sehr schnell in die Endlosscheife while(1) gelangst und dort bei Losgelassenem Taster beide LEDS angeschaltet werden, kannst zu die Aktion aus Zeile (4) nicht sehen. Die Geistereffekte.... Es kann an den Kondensatoren bei den Tastern hängen. Dazu ist in den Artikeln zum Pollin-Board hier im Wiki einiges geschrieben worden. Kurzfassung beim Klimpern auf den Tastern können diese C zuviel Strom ziehen und den µC in den Reset treiben. Wenn ausschliesslich die LED an PD5 flackert, dann zappeln vielleicht die Tasterkontakte durch deine Schritte. Testen durch auf den Tisch hauen. Taster ggf. ersetzen Wenn auch die LED an PD6 flackert hast du ein elektrisches Problem auf dem Board. Tippe auf eine faule Lötstelle, die mal Kontakt hat und mal nicht. Im Gegenteil. Nicht benutzte I/O Leitungen besser als Eingänge lassen. Dann ziehen die auch keinen (kaum) Strom.
Zeile (4) war auch nicht als Effekt vorgesehen, sondern vielmehr ein kleiner Fehler - oder eben auch nicht. Was mir immer noch seltsam erscheint, ist das Reagieren auf ein dran vorbeigehen, und die Reaktion auf das drücken der beiden anderen Taster. Den diese sollten ihren Strom ja über den Taster bekommen, da die Spannung ja sonst über den Widerstand zu GND gezogen wird, sprich auf 0V. Direkt nach dem einschalten funktioniert es meistens auch nicht, der Controller reagiert gar nicht auf mein tasten. Nach einem reset ist es manchmal ähnlich. meist dauerd es dann ca. 10 tastendrücke bis der Controller so langsam mal reagiert. Oft geht die LED auch aus, und erst nicht wieder an. ohne das Board zu berühren geht sie nach einer Zeit dann doch wieder. Bei all diesen Vorgängen bleibt die zweite LED immer an. Was ich vergessen hatte ist, dass ich derzeit den internen Takt benutze. Bevor ich mir das Ding verfuse Frage ich lieber nochmal nach: Wie genau errechne ich mir die HEX-Werte, um die Fuses auf den Quarz umzusetzen und welche Parameter brauche ich für avrdude?
Ich ahbe grade nochmal nachgemessen, der Taster hat definitiv keinen Wackler, der Pin geht sofort auf low zurück, wenn ich den taster loslasse. Die LED ist trotzdem an.
> der Pin geht sofort auf low zurück, wenn ich den taster > loslasse. Die LED ist trotzdem an. Das steht auch so im Programm: Wenn der Pin am active-high Taster an PD1 nicht LOW ist, werden die active-high geschalteten LEDs an PD5 und PD6 angeschaltet andernfalls wird die active-high geschaltete LED an PD5 ausgeschaltet und die LED an PD6 angeschaltet. Die Bedeutung von active-high steht im AVR-GCC-Tutorial im Abschnitt über IO. Die Schaltungsart der Taster und LEDs beim Pollinboard steht im Datenblatt. Kuckt man sich das an, sieht man, dass bei der IC3 Fassung für den AtTiny2313 der Taster1 an PD2 hängt. Dein Code fragt also den falschen Pin ab. Statt if((PIND & 0b00000010) != 0){ sollte es heissen if((PIND & 0b00000100) != 0){ oder IMHO lesbarer if( !(PIND & (1<<PD2)) ){
Falle, selber reingefallen!
statt
if( !(PIND & (1<<PD2)) ){
natürlich
if( (PIND & (1<<PD2)) ){
wegen dem vorherigen != 0
Oh Mann was mache ich dann Wenn der Pin am active-high Taster an PD1 nicht LOW ist, wird die active-high geschaltete LED PD6 angeschaltet und die active-high geschaltete LED an PD5 ausgeschaltet andernfalls wird die active-high geschaltete LED an PD5 angeschaltet und die active-high geschaltete LED an PD6 angeschaltet. Haben wir's jetzt? Ich sollte heute besser nicht mehr basteln :)
Sorry, es sollte heissen, die LED ist trotzdem aus, und geht nicht wieder an. Rein theoretisch hast du recht - ich habe das falsch programmiert - aber warum funktioniert es dann, zumindest teilweise ???? An Pin 3 tut sich nämlcih gar nichts - trotzdem gehts aus... Oh mann, wird ja immer schlimmer. dann werde ich das jetzt mal umschreiben, und gucken, was raus kommt. Oje. lg. jan
so, mein code sieht jetzt so aus. im moment erkennt avrdude die hexfile nicht an, ich versuchs morgen nochmal.
1 | #include <avr/io.h> // (1) |
2 | |
3 | int main (void) { // (2) |
4 | |
5 | DDRD = 0x60; // (3) |
6 | PORTD = 0x60; // (4) |
7 | |
8 | while(1) { // (5a) |
9 | if(PIND & (1<<PD2)){ |
10 | PORTD = 0x40; |
11 | }
|
12 | else{ |
13 | PORTD = 0x60; |
14 | }
|
15 | } // (5c) |
16 | |
17 | /* wird nie erreicht */
|
18 | return 0; // (6) |
19 | }
|
Hallo, nach langer Zeit melde ich mich mal wieder. Alle unter SuSE mit YaST installierten Kompiler und Linker spucken anscheinet keinen brauchbaren Hexcode aus, der avr-gcc im rCOS schon :( dann muss ich jetzt eben immer die vBox anschmeissen, um zu kompilieren und mein LAMP-System zum Dateitransport auf HTTP-Ebene missbrauchen. Mit dem neuen Code tut es der Attiny wie er soll, keine Geistereffekte mehr ;) Ich hatte schonmal etwas mit den Delayfunktionen versucht, bekomme aber immer nur Kompilerfehler, die ich nicht nachvollzieghen kann. Werde ich demnächst noch hier posten. Was mir jetzt noch fehlt ist das Fusebit setzen für den Externen Quarz mit avrdude. ich habe ein bisschen Angst, dass ich ihn verfuse. LG: Jan
Super, danke. ich arbeite grad an einem zahlenschloss, sozusagen Passworteingabe bevor ich ein Relais einschalte, das dann eine andere Schaltung versorgt. Für andere simple Aufgaben zum üben, die ich mit dem Ebval und Addonboard von Pollin machen kann bin ich jederzeit offen ;) LG: Jan PS: Danke für die superschnelle Antwort ;)
Mist statt Bearbeiten Löschen erwischt... Dann schreibe vorher deine herausgesuchten Einstellungen (AVR-Typ, Quarz-Typ und geplante Fuses) hierher und warte bis sich jemand :) die Zeit nimmt, die zu kontrollieren. Vier (und mehr) Augen sehen mehr als zwei... Danke für das Feedback zu Suse. Damit habe ich den Artikel [[AVR und Linux]] erweitert.
> Danke für die superschnelle Antwort
Ich bin aber auf dem Sprung. Wenn du Fuses zur Kontrolle schickst, dann
wird es morgen abend bis ich da mit der nötigen Sorgfalt ran kann.
Angehängte Dateien:
-
attiny2313.png
84 KB
Stefan B. schrieb: > Danke für das Feedback zu Suse. Damit habe ich den Artikel AVR und > Linux erweitert. Hey, super. So tatkräftige User findet man leider immer seltener in Foren. Dickes Lob. Ich habs mit den Fuses mal mit dem Online Burn-o-mat versucht. Hier das Ergebnis: efuse=FF hfuse=DF lfuse=FF Ich habs als Screenshot auch nochmal angehängt. Welche Vor oder Nachteile hat es denn, den Takt durch 8 teilen zu lassen? Ich bin mir nicht sicher, ob ich das nun machen soll, oder nicht. Mein Zahlenschloss funktioniert schon :) Ich werde den Code noch mal optimieren, und dann mal einen neuen Thread aufmachen. Ich möchte gerne wissen, was ich besser machen kann, oder wie ich vllt noch ein paar übliche Design Patterns anwenden kann. Wenn jmd jetzt schon am Hexcode interessiert ist, kann ich den ja mal hochladen und die Pinbelegungen durchgeben. Als nächstes mache ich mich dann an eine digitale Laustärkesteuerung mit dem LCD für einen TDA7053A. Das macht echt Spaß. Für Buchempfehlungen bin ich auch immer offen ;) LG: jan EDIT: Ich nehme an, CLKOUT ist sinnvoll wenn man 2 AVRs miteinander koppeln will, um dann einen exakt gleichen Arbeitstakt zu haben, oder?
Jan W. schrieb: > Ich habs mit den Fuses mal mit dem Online Burn-o-mat versucht. Hier das > Ergebnis: > > efuse=FF hfuse=DF lfuse=FF Kannst du verwenden. Ist für Quarz Q1 8 MHz und mehr. Ich habe bei meinen Boards noch den Brownout bei <=4.3V eingestellt. > Welche Vor oder Nachteile hat es denn, den Takt durch 8 teilen zu > lassen? Habe ich keine großen Gedanken zu. Ist für mich nur eine Option, um im Anwendungsfall möglichst nahe an die im Programm benötigte Taktrate zu kommen. > Ich bin mir nicht sicher, ob ich das nun machen soll, oder nicht. Dann erstmal nicht. Wenn du das brauchst, kannst du das immer noch ändern. > Mein Zahlenschloss funktioniert schon :) > Ich werde den Code noch mal optimieren, und dann mal einen neuen Thread > aufmachen. Ich möchte gerne wissen, was ich besser machen kann, oder wie > ich vllt noch ein paar übliche Design Patterns anwenden kann. > Wenn jmd jetzt schon am Hexcode interessiert ist, kann ich den ja mal > hochladen und die Pinbelegungen durchgeben. Mach doch einen Artikel für dein Projekt. Dort hast du mehr Möglichkeiten das Projekt schön darzustellen und kannst es selbst oder mit Hilfe anderer kontinuierlich verbessern. Und es macht Spaß das Ergebnis wachsen zu sehen. > EDIT: Ich nehme an, CLKOUT ist sinnvoll wenn man 2 AVRs miteinander > koppeln will, um dann einen exakt gleichen Arbeitstakt zu haben, oder? Habe ich auch keine großen Gedanken zu. Deine Idee hört sich vernünftig an. Man kann die Ausgabe der Taktfequenz auch als Trigger z.B. für einen Logikanalyzer oder ein Oszilloskop nutzen.
Gut, ich probier es gleich aus. Den Takt lasse ich dann erstmal ungeteilt, und CLKOUT brauche ich ja auch nicht, wollte es nur wissen ;) Stefan B. schrieb: > Mach doch einen Artikel für dein Projekt. Dort hast du mehr > Möglichkeiten das Projekt schön darzustellen und kannst es selbst oder > mit Hilfe anderer kontinuierlich verbessern. Und es macht Spaß das > Ergebnis wachsen zu sehen. Die Idee einen Artikel dafür zu öffnen klingt gut. Ist es denn dort auch gut möglich über Verbesserungsmöglichkeiten im Code zu diskutieren? Ich möchte ja vorallem daraus lernen. Evtl. macht es dann mehr Sinn, beides parallel zu machen. Unterdessen habe ich mal versucht, den Code zu optimieren und mich dabei auch mit ein paar mehr Funktionen versucht. Ich habe aber noch Probleme mit der Registerübergabe, obwohl ich mich schon mehrfach durch AVR-GCC Tutorial gekämpft habe, zumindest durch die relevanten Teilabschnitte. Zumindest denke ich das es daran liegt. Die alte und die neue Quellcode Datei habe ich mal angehängt. Die Pinbelegung: PB0-6: Taster 0-6 für den Code PD0: Grüne LED (entsperrt) PD1: Rote LED (gesperrt) PB7: Relais schalten, wenn entsperrt. PD5+6: LED1+2 auf dem Evalboard PD2+3: Taster 1+2 um LED 1+1 austasten PD4: Eingegebenen Code löschen (Taster3 auf dem Evalboard) Der Code: 36615642 Interessant ist vllt noch, dass ich mein ganzes C-Können aus PHP 'portiert' habe - vllt kommen daher ein paar Fehler. Wie gesagt, Buch für µC Programmierung mit C hätte ich schon gerne.
Mach für die Diskussion deines speziellen Projekts Zahlenschloss (Codeschloss) besser einen neuen Thread auf. Dieser Thread hier "gehört" Dietrich J. und es geht um "Pollin Atmel Evaluations-Board & Co. - Fragen". Der Thread ist IMHO auch schon zu lang. Wenn du den Artikel schreibst, dann dort einen Link auf deinen neuen Diskussionsthread einfügen. Im Quelltext selbst kann man einiges µC-typischer schreiben. Man muss nicht so "aasen" mit Datentypen (int) und mit Funktionen. Makros oder inline Funktionen sind meist günstiger. Die Bitschreibweise mit symbolischen Namen (1<<irgendwas) ist mir am liebsten und am besten wird das durchgängig angewendet. Zur Hardware - die meiste Zeit ist das Codeschloss sicher "inaktiv", d.h. man kann über einen Sleep-Modus in der Software nachdenken insbesondere, wenn das Codeschloss per Akku/Batterie versorgt wird. Das Relais sollte selbsthaltend sein. Und die Sperr-LED sollte im Sleepfall leuchten und von AVR aktiv ausgeschaltet werden. Wenn das Codeschloss an eine Tür soll, dann den Notfall einplanen. Wie bekommt man die Tür im Fluchtfall beim Stromausfall auf. Wenn das Codeschloss an einen Tresor oder eine Schatztruhe soll, dann überlegen, wie man die Kiste aufbekommt, wenn die Batterie/Akku leer.
Gut, du hast recht! ;) Deine Überlegungen gehen schon ein wenig weiter. ich mache dann jetzt ein neues Thema dafür auf. Deine Vorschläge kann ich dort schonmal reinzitieren. Den Link dazu poste ich dann auch hierrein.
Hier der Link: Beitrag "[AVR|C] Codeschloss Projekt - wie den Code verbessern" ich hoffe mal ich komme da voran ;) LG: jan
Thread beobachten
Seitenaufteilung abschaltenBitte 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.