Hallo! Ich wollte mein altes Radio-Projekt wieder zum Leben erwecken und musste feststellen, das mein ATTiny2313 einen defekt hatte. Tausch kein Problem, aber ich konnte alleranschein nach nicht das passende Programm mehr richtig rekonstruieren. Die Alte ASM-Datei hatte einen kleinen Fehler, welcher sich nun im AVR äußert. Das Programm konnte compiliert werden im AVR-Studio mit 0 Fehler und 0 Warnungen, Jetzt steht im Display nur _. statt der Frequenzanzeige und das Teilerverhältnis zum LM7001 schaut auch nicht OK aus. Ich suche den Fehler schon seit 3 Tagen und komme einfach nicht weiter. Erkennt jemand, was in dem Code falsch läuft? Ich bedanke mich schon mal vorher.
Mediafox F. schrieb: > .INCLUDE "tn2313def.inc" ; Befehlsliste des ATMega328P Du solltest Dich erstmal entscheiden, welcher Typ. Und ohne Schaltplan wird das eh nichts. Wir sind nicht so die Hellseher. Mediafox F. schrieb: > Das Programm konnte compiliert > werden im AVR-Studio mit 0 Fehler und 0 Warnungen Das bedeutet gar nichts. Assembler sind recht schmerzbefreit, die assemblieren Dir selbst den größten Mist. Wenn Du eh keine Interrupts benutzt, dann erspar uns den ganzen Vectorschrunz. Fang einfach bei 0x0000 mit dem Main an.
:
Bearbeitet durch User
Es geht um den ATTiny2313. An PORTD angeschlossen sind: PD0 = AO vom 74HC139 für die Stellen PD1 = A1 vom 74HC139 für die Stellen PD2 = Oszillatorausgang 4MHz PD3 = DATA vom 74HC164 und LM7001 PD4 = CLK vom 74HC164 und LM7001 PD5 = LE vom LM7001 PD6 = LE vom 74HC573 An PORTB angeschlossen sind: PB0 = Taste LOW-Aktiv Frequenz runter PB1 = Taste LOW-Aktiv Frequenz rauf PB2 = Taste LOW-Aktiv Sender Speichern PB4 bis PB7 - Binäreingänge vom Empfänger / HEX-Schalter für die 16 Programmplätze. Die 7-Seg-Anzeige mit gemeinsamer Anode hängt am 74HC573, Q0 - Q7 entsprechen a-g, DP. An D0 bis D7 hängt das 74HC164. Hätte auch einen 4094 nehmen können, war damals nicht verfügbar. Q0 bis Q3 vom 74HC139 hänge die Anoden der Anzeige. A0 und A1 werden vom ATTiny2313 angesteuert, /CS liegt an GND. Der LM7001 ist standardmäßig angeschlossen. Alles in Allen keine gr0ßartige komplizierte Schaltung.
1 | ldi zl, low(digit_table) |
2 | ldi zh, high(digit_table) |
Muss an den drei Stellen nicht jeweils *2 stehen?
Mediafox F. schrieb: > Es geht um den ATTiny2313. > .............. > .............. > Alles in Allen keine gr0ßartige komplizierte Schaltung. Schaltpläne in Prosa sind echt scheisse.
S. L. schrieb: > ldi zl, low(digit_table) > > ldi zh, high(digit_table) > > Muss an den drei Stellen nicht jeweils *2 stehen? Wo soll "mal zwei" stehen. Die Digit-Tabelle besteht aus Bytes und selbst wenn nicht muss der Tabellenanfang unverändert geladen werden.
digit_table ist eine Wortadresse, lpm benötigt eine Byteadresse. Aus dem 'AVR Instruction Set Manual' unter lpm: "The Program memory is organized in 16-bit words while the Z-pointer is a byte address." Siehe auch das dortige Beispiel.
Mediafox F. schrieb: > Tausch kein > Problem, aber ich konnte alleranschein nach nicht das passende Programm > mehr richtig rekonstruieren. Hast Du Fuses auch richtig programmiert? Was "richtig" ist, kann ich Dir aber ohne Schaltplan nicht sagen. Default ist wohl ClkDiv8 aktiv, interner 8-MHz-RC-Oszillator aktiv und Brown-Out deaktiviert. Grüßle, Volker
:
Bearbeitet durch User
S. L. schrieb: > digit_table ist eine Wortadresse, lpm benötigt eine Byteadresse. Danke für die Erklärung. Dieses Detail der AVR-Programmierung war mir entgangen. Dann ist es ja komisch, dass der TO behauptet, das Programm hätte schon mal funktioniert.
In der Tat - bei drei Tagen Fehlersuche hätte er sich doch an diesen Sachverhalt erinnern müssen.
S. L. schrieb: > digit_table ist eine Wortadresse, lpm benötigt eine Byteadresse. Sicher, dass der Assembler das genauso sieht? Schließlich hat er offensichtlich die .db Anweisung verstanden. Warum sollte er das Label dann als Wort-Adresse interpretieren? Grüßle, Volker (der aus genau diesen Gründen lieber bei C bleibt :-)
Volker B. schrieb: > Sicher, dass der Assembler das genauso sieht? Schließlich hat er > offensichtlich die .db Anweisung verstanden. Warum sollte er das Label > dann als Wort-Adresse interpretieren? Weil im .cseg alle Label Wortadressen sind. Das merkt man auch sofort, wenn man nur testweise mal eine ungerade Zahl Bytes zwischen zwei Labeln platziert, dann setzt es nämlich eine Warnung, dass automatisch gepaddet (d.h.: ein Nullbyte eingefügt) wurde. > Volker (der aus genau diesen Gründen lieber bei C bleibt :-) Ach watt, in C ist der Hassel mit den Adressräumen des AVR fast noch schlimmer. Aber letztlich ist's genau so, wie in Assembler auch: man muß die einschlägige Syntax lernen. Das ist übrigens, streng genommen, nicht mal "C" und es gibt obendrein mehr als nur eine... Komplizierter als Assembler wird das in C eigentlich vor allem dadurch, dass der Scheiß letztlich genauso wenig typsicher ist wie Assembler. Das fällt besonders dann auf, wenn irgendwo mal das Attribut für den Speicherbereich vergißt. Der Compiler bemeckert das je nach Einstellung entweder garnicht oder nur mit einer Warnung. Es kommt aber letztlich genauso kaputter Code raus wie in diesem unsäglichen Assembler-Probestück. Fazit: man muss halt einfach wissen, was man tut. Ganz egal in welcher Sprache man programmiert.
Ob S. schrieb: > Weil im .cseg alle Label Wortadressen sind. Danke! Mit etwas nachdenken ist's auch logisch, denn der Assembler weiß ja nicht, was mit der Adresse geschehen soll, die in ein Registerpaar geladen wird. Dann muss es ggf. die Programmiererin konvertieren. Dann klingt's logisch, dass beim TO die Ausgabe der Bytekonstanten aus dem Code-ROM nicht den Erwartungen entspricht. Und meine Glaskugel meint, das Problem "Teilerverhältnis zum LM7001 schaut auch nicht OK aus", liegt an der ClkDiv8 Fuse. Wenn dann Klagen über falsche Daten im EEPROM kommen, wissen wir auch, dass er den Brown-Out Detektor nicht aktiviert hat. Grüßle, Volker
:
Bearbeitet durch User
Peter D. schrieb: > Assembler sind recht schmerzbefreit, die assemblieren Dir selbst den > größten Mist. Fehlermeldungen da kontrollieren nur, ob grobe Syntaxschnitzer gemacht wurden, sonst nichts. Bzw. der 2313 braucht beim lpm noch den tst auf Null. Oder kann kein Postincrement. Da muss dann immer noch adiw rein. beim 4313 gehts ohne den String. Ist beim def.inc die "falsche" aber fast richtig aussehende Datei genommen worden, gehts auch nicht. also tn2313def.inc oder nur 2313def.inc. Solche "Schnitzer" bewirken dann Fehlermeldungen. ciao gustav
:
Bearbeitet durch User
Ist das nicht Sparsamkeit an der falschen Stelle? Mit der ganzen nötigen Zusatzhardware (soger ein HC139 konnte sich der TE nicht verkneifen) wäre man doch mit dem Mega 328 aus der ersten Zeile des Programms gar nicht schlecht bedient. Man spart sich dann auch die Doppelbelegung von Pins zum HC595 und der PLL. Ich bin jedenfalls mit dem Mega 48/88/168 mit LCD und dem LM7001 immer gut gefahren.
Per Mail wurde mir dieses Programm empfohlen. Werd mal einen ATMEGA8 suchen und probieren.
Hi >ShowDigit: > lsl temp > ldi ZL, low(SEG_TABLE * 2) > ldi ZH, high(SEG_TABLE * 2) > add ZL, temp > adc ZH, r1 << > lpm temp, Z r1 ist in dem Programm kein Wert zugewiesen- MfG Spess
Ich hab alles neu zusammen geschrieben. Scheine es nun mit dem ATMEGA8 geschafft zu haben. Anzeige geht, sogar mit ZF-Offset und Programmspeicher, kein Flackern im Display und die Daten zum LM7001 schauen auch vernüftig aus. Sicher kann man noch was verbessern. Jetzt noch den passenden Tuner suchen und schauen ob dann alles geht.
Mediafox F. schrieb: > Jetzt noch den passenden Tuner suchen und schauen ob dann alles geht. Ich glaub, da kommst Du einige 10 Jahre zu spät. Es gibt doch fertige FM-ICs, z.B.: https://www.roboter-bausatz.de/p/fm-stereo-radio-rda5807m-funkmodul
Ich hab vor kurzen einen Frontend in Händen gehabt mit Tuner und LM7001, samt ZF-Demoulator aus einer alten Philipskombo. Den wollte ich gern verwenden. Das es etwas moderneres gibt, ist mir schon klar, aber wegwerfen möchte ich alte Teile, wenn sie nicht richtig defekt sind, auch nicht.
Mediafox F. schrieb: > Ich hab vor kurzen einen Frontend in Händen gehabt Nein! Sondern: "Ich hab vor Kurzem ein Frontend in Händen gehabt" Mediafox F. schrieb: > Das es etwas moderneres gibt, ..... Nein! Sondern: "Dass es etwas Moderneres gibt, ...."
Peter D. schrieb: > Es gibt doch fertige FM-ICs, z.B.: > > https://www.roboter-bausatz.de/p/fm-stereo-radio-rda5807m-funkmodul Klar, aber programmiert werden muss das externee IC doch noch. Und darum ging's in diesem Thread hier hauptsächlich. Gibt aber auch preiswerte "fertige" UKW/FM-Empfänger-Bausätze, ohne "Programmierarbeit". ciao gustav
Karl B. schrieb: > Klar, aber programmiert werden muss das externee IC doch noch. > Und darum ging's in diesem Thread hier hauptsächlich. > Gibt aber auch preiswerte "fertige" UKW/FM-Empfänger-Bausätze, ohne > "Programmierarbeit". Ohne Programmieren wärs doch langweilig. Einen Bausatz zu kaufen und zusammen zu bauen, mit einem Allerweltshalbleiter, wäre heute nichts mehr für mich.
Wastl schrieb: > Nein! Sondern: > "Ich hab vor Kurzem ein Frontend in Händen gehabt" Wenn du schon Oberlehrer spielst, dann bitte richtig. "Ich habe vor Kurzem ein Frontend in den Händen gehabt."
:
Bearbeitet durch User
Veit D. schrieb: > Wenn du schon Oberlehrer spielst Dem ist sowieso nicht mehr zu helfen. Mediafox F. schrieb: > Den wollte ich gern > verwenden. Viel interessanter ist es doch, einen UKW Sender zu bauen statt einem Radio :-P Dafür habe ich den LM7001 gerne benutzt.
Angehängte Dateien:
Matthias S. schrieb: > Viel interessanter ist es doch, einen UKW Sender zu bauen statt einem > Radio :-P Dafür habe ich den LM7001 gerne benutzt. Ja, hab ich auch schon gemacht, nur mit LC7215 aus einem alten analogen SAT-Receiver. War alles auf einer eigenen Modulplatine aufgebaut, deshalb konnte ich das Modul verwenden. Die Schaltung fand ich deshalb so interessant, weil auch viele TTL-ICs drauf waren. Ganz nach dem Motto von damals: "Je mehr TTL, desto besser, gell!" Angesteuert mit AT90S1200 ohne Display und nur für 3 Kanäle mit DIP-Schaltern.
:
Bearbeitet durch User
Mediafox F. schrieb: > hab ich auch schon gemacht Ach du meine Nase, das sieht sehr aufwendig aus :-P Das schöne am LM7001 ist ja, das sowas mit lediglich 2 ICs (PLL und MC) geht und nur noch den VCO zusätzlich braucht. Für den VCO habe ich ein Design aus dem 'Satellite, Cable & TV Handbook' von Plessey benutzt, der bis zu 2GHz spielt mit Standardbauteilen.
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.