Hallo allerseits,
ich versuche mich gerade an einem kleinen Programm für den Attiny10.
Dieser soll später eine LED via PWM dimmen und per Taster gesteuert
werden.
Da dies mein erstes Projekt mit diesem µC ist, habe ich mir erst ein mal
ein "Test-Board" gebaut und versuche den Code "stückweise" zu
implementieren (daher die auskommentierten Bereiche...). Als IDE nutze
ich AVR-Studio 7.
Mein Problem: die LED leuchtet dauerhaft - so als würde der µC aus dem
Interrupt nicht wieder zurück in die main springen. Kann das sein? -
oder habe ich mich beim setzten der Interrupt-Register vertan?
PinX ist ein Eingangsregister, Ausgangsregister nennen sich PortX.
Außerdem hat das Ding einen kastrierten Registersatz, R1-R15 fehlen,
soweit ich erinnere sind auch ein paar Opcodes anders.
Da wird dem Compiler schlecht.
Nimm Assembler, damit klappt's.
Cyrill S. schrieb:> PINB = 0x00;
Die ISR toggelt per PINB = 0x02 PORT B1.
PINB = 0 hat keine Funktion, vielleicht meinst du PORTB = 0 oder PORTB
&= ~(1 << PB1) so dass nur das Bit wieder gelöscht wird oder per PORTB
|= (1 << PB1) wieder gesetzt wird.
Zudem wird die Aktion in main immer ausgeführt, also auch unmittelbar
nach der ISR. Daher ist das Flackern viel zu kurz um es mit dem Auge
erkennen zu können.
Johann L. schrieb:> vielleicht meinst du PORTB = 0 oder PORTB> &= ~(1 << PB1) so dass nur das Bit wieder gelöscht wird oder per PORTB> |= (1 << PB1) wieder gesetzt wird.
Ja, das meinte ich...
Aber auch mit den Änderungen bleibt die LED dauerhaft an.
MWS schrieb:> Außerdem hat das Ding einen kastrierten Registersatz, R1-R15 fehlen,> soweit ich erinnere sind auch ein paar Opcodes anders.> Da wird dem Compiler schlecht.> Nimm Assembler, damit klappt's.
Mein Problem: ich beherrsche kein Assembler... :-(
Die aktuelle Fassung vom Code:
Cyrill S. schrieb:> Mein Problem: ich beherrsche kein Assembler... :-(
Da hast Du gleich zwei Probleme, zum einen könntest Du Dir im Studio den
disassemblierten Code ansehen, dann sähst Du gleich, wo's klemmt und zum
anderen hast Du den falschen Controller für die gewählte
Programmiersprache.
Es ist einige Zeit her, dass ich festellten konnte, dass der AVR GCC bei
diesem Kontroller scheitert und ich bezweifele, dass mittlerweile viel
Energie in das Anpassen des GCC gesteckt wurde, damit der auf diesem
Winzteil läuft. Zumal SRam- und Flash-Ausstattung eher in Richtung
Assembler deutet.
Nimm einen Tiny13 oder 25, die gibt's auch in relativ kleinem Gehäuse
und die sind in C problemlos programmierbar.
Marc V. schrieb:> Johann L. schrieb:>> Die ISR toggelt per PINB = 0x02 PORT B1.>> Nein, tut es nicht.
Auszug DB ATiny10:
> However, writing '1' to a bit in the PINx Register will result in a toggle in
the
> corresponding bit in the Data Register.
MWS schrieb:> Auszug DB ATiny10:>> However, writing '1' to a bit in the PINx Register will result in a toggle in> the>> corresponding bit in the Data Register.
Ich bin nach meiner Liste gegangen.
AVRs mit Toggle Fähigkeit:
Beitrag "Re: Welche AVR besitzen die PIN Toggle Fähigkeit?"
Jedenfalls steht in ATTiny10.xml nichts von Tiny10 Pintoggle
Fähigkeiten.
Und da ATMEL regelmässig Mist baut mit DaBlas, bin ich geneigt,
.xml mehr Glauben zu schenken...
P.S.
Ich habe keine ATTINY10 um das zu prüfen, vielleicht kann das
jemand testen ?
MWS schrieb:> Außerdem hat das Ding einen kastrierten Registersatz, R1-R15 fehlen,> soweit ich erinnere sind auch ein paar Opcodes anders.
Und?
> Da wird dem Compiler schlecht.
Käse.
Der Code ist vielleicht nicht so gut wie für "normale" AVR, aber auch
nicht schlimmer als seinen AVR bit BASCOM zu traktieren oder
bloated[tm] C oder C++ zu fabrizieren.
MWS schrieb:> Cyrill S. schrieb:>> Mein Problem: ich beherrsche kein Assembler... :-(>> Da hast Du gleich zwei Probleme, zum einen könntest Du Dir im Studio den> disassemblierten Code ansehen, dann sähst Du gleich, wo's klemmt und zum> anderen hast Du den falschen Controller für die gewählte> Programmiersprache.
YMMV.
> Es ist einige Zeit her, dass ich festellten konnte, dass der AVR GCC bei> diesem Kontroller scheitert und ich bezweifele, dass mittlerweile viel> Energie in das Anpassen des GCC gesteckt wurde, damit der auf diesem> Winzteil läuft.
Der GCC läuft immer noch aufm PC. Und was du mit "scheiten" meinst weiß
ich auch nicht.
> Zumal SRam- und Flash-Ausstattung eher in Richtung> Assembler deutet.
Schon, aber das schließt C nicht aus. Das einzige ist die schlechtere
Unterstützung von Standard-Funktionen durch die avr-libc und teilweise
auch libgcc. Aber wenn float-Support ein Ausschlusskriterieum ist,
wirst du ihn für Tiny auch nicht in Assembler programmieren wollen.
Jedenfalls zeigt das, dass es Keute gibt, die zumindest GCC auf nem Tiny
versuchen, und dass es daher nicht vergemene Liebesmüh ist, den Support
in avr-gcc und avr-libc weiter auszubauen, was entgegen deine Unkenrufe
auch geschieht.
Sicher dass du Pin Change Interrupts ohne ISR-Routine verwenden
möchtest? Alternativ kannst du die Flags auch in der main pollen. Da der
Tiny10 anscheinend nur einen Timer hat, der wahrscheinlich für die PWM
draufgeht, ist die Generierung des 10ms-Tickes etwas schwieriger. Und
ein Zeitraster willst du haben, damit der debouncer ordentlich arbeitet
und diese unsäglichen _delay_ms() verschwinden.
Und schmeiß die Magic numbers raus, wenigstens mit #defines.
Johann L. schrieb:> MWS schrieb:>> Außerdem hat das Ding einen kastrierten Registersatz, R1-R15 fehlen,>> soweit ich erinnere sind auch ein paar Opcodes anders.>> Und?
Was und? Das Resultat war kaputter Maschinencode. Genug und?
>> Der Code ist vielleicht nicht so gut wie für "normale" AVR, aber auch> nicht schlimmer als seinen AVR bit BASCOM zu traktieren oder> bloated[tm] C oder C++ zu fabrizieren.
Zu dem Zeitpunkt, wo ich mir das Disassemblat des vom GCC erzeugten
Codes ansah, war's unbrauchbar, es wurden Register verwendet, über die
der Atiny10 nicht verfügte.
> MWS schrieb:>> Cyrill S. schrieb:>>> Mein Problem: ich beherrsche kein Assembler... :-(>>>> Da hast Du gleich zwei Probleme, zum einen könntest Du Dir im Studio den>> disassemblierten Code ansehen, dann sähst Du gleich, wo's klemmt und zum>> anderen hast Du den falschen Controller für die gewählte>> Programmiersprache.>> YMMV.
Merkwürdige Bemerkung zu meinem Argument.
>>> Es ist einige Zeit her, dass ich festellten konnte, dass der AVR GCC bei>> diesem Kontroller scheitert und ich bezweifele, dass mittlerweile viel>> Energie in das Anpassen des GCC gesteckt wurde, damit der auf diesem>> Winzteil läuft.>> Der GCC läuft immer noch aufm PC. Und was du mit "scheiten" meinst weiß> ich auch nicht.
Scheitert = Schrottcode, unbrauchbar, Absturz mit Reboot, ungültige
Opcodes, Verwendung nicht vorhandener Register. Sag mal, hast Du eine
Flasche Wein im Kopf? Ich schreib was von Energie reingesteckt, um den
Compiler auf den beschränkten Registersatz und abweichende Opcodes
anzupassen und bekomme als Antwort, dass der GCC auf dem PC läuft. Was
soll der Krampf, bist Du nicht in der Lage meine Aussage passend
verstehen?
>> Zumal SRam- und Flash-Ausstattung eher in Richtung>> Assembler deutet.>> Schon, aber das schließt C nicht aus. Das einzige ist die schlechtere> Unterstützung von Standard-Funktionen durch die avr-libc und teilweise> auch libgcc. Aber wenn float-Support ein Ausschlusskriterieum ist,> wirst du ihn für Tiny auch nicht in Assembler programmieren wollen.
Vielleicht erzeugt der GCC mittlerweile keinen fehlerhaften Code mehr,
das kann ich aber im Moment nicht nachvollziehen, da ich auf dem Tablet
schreibe und kein AVR Studio starten kann, um mir das Ergebnis mal
anzusehen.
> Jedenfalls zeigt das, dass es Keute gibt, die zumindest GCC auf nem Tiny> versuchen, und dass es daher nicht vergemene Liebesmüh ist, den Support> in avr-gcc und avr-libc weiter auszubauen, was entgegen deine Unkenrufe> auch geschieht.
Es ist schwer zu verstehen, dass Du nicht verstehst, ich hab' schon
wesentlich bessere Posts von Dir gesehen. Es geht nicht um Liebesmüh und
Tiny, sondern es geht um die grundsätzlichen Unterschiede der normalen
Tinys gegenüber den Tiny4/5/9/10.
Es soll hier nicht ge-unkt werden, sondern es geht darum den TE auf die
Möglichkeit hinzuweisen, dass der Compiler evtl. nicht das macht, was
man denkt. Ich muss ja nicht recht haben, wenn jedoch der TE alle
offensichtlichen Fehler ausgeräumt hat und es dann immer noch nicht
läuft, dann könnte man über meine Argumente nochmal nachdenken ;-)
malsehen schrieb:> Der Attiny10 ist nur begrenzt in C programmierbar,> da er keinen RAM hat
Das aktuelle DB sagt 32 Byte SRam.
Du meinst evtl. den Vorgänger ATiny10 , der unterscheidet sich
grundlegend vom Nachfolger.
MWS schrieb:> Das aktuelle DB sagt 32 Byte SRam.> Du meinst evtl. den Vorgänger ATiny10 , der unterscheidet sich> grundlegend vom Nachfolger.
Danke, die neue Reihe tiny4/5... war mir entfallen.
Ist aber auch blöd, zwei komplett unterschiedliche µC
gleich zu benennen.
MWS schrieb:> wenn jedoch der TE alle> offensichtlichen Fehler ausgeräumt hat
... genau da bin ich mir nicht so sicher.
Ich werde das Gefühl nicht los, irgend wo einen dämlichen Fehler gemacht
zu haben...
- verwende ich für die ISR den richtigen Vektor?
GCC gibt das als Assembler aus:
Von den Registern her, also dem Compilerergebnis sieht's gut aus, nichts
unter r16.
Nicht zu übersehen ist - wurde vorhin von "neuer PIC Freund" schon
erwähnt - dass Du keine ISR für PCINT0 hast, sondern nur für INT0.
Da Du einen Pullup auf PB0 legst, auch entsprechend im Kommentar, willst
Du Dein Signal dort zuführen, dort liegt aber der PCINT0, den Du auch
erlaubt hast, der aber ohne ISR ist und auf Bad Interrupt führt und für
Neustarts sorgt.
INT0, für den Du eine ISR angelegt hast, hängt dagegen (wohl floatend)
an PB2 und löst aufgrund des allgegenwärtigen Netzbrumms aus, während
ein Signal an PB0 zum sofortigen Neustart führt.
Hallo,
Ist das immer noch der aktuelle Code?
Cyrill S. schrieb:> ISR(INT0_vect)> {> //OCR0B = 1000;> PORTB &= (1 << 1);> _delay_ms(500);> }
Falls ja erübrigt sich die Diskussion über den "ach so schlechten" GCC
(jedes Argument von Johann ist sowieso mehr wert ;-) ).
Das delay in der ISR ist natürlich ein Designfehler, aber ich denke,
dass es eher aus Verzweiflung da rein gekommen ist.
Du löscht aber nicht PB1, sondern alle außer PB1.
Richtig wäre
PORTB &= ~(1 << 1); für den Fall, das der Pin in der ISR low werden
soll, sonst
PORTB |= (1 << 1);
Da du in der Main()-Funktion den Pin aber immer auf low setzt, wohl eher
Möglichkeit 2.
Des weiteren aktivierst du (laut deinen Kommentaren, ich hab die
Register jetzt nicht gegengecheckt) den Pin-Change Interrupt zusätzlich
zum normalen Externen Interrupt. Da es dazu keine ISR gibt wird der
Prozessor neu starten.
Mit freundlichen Grüßen,
N.G.
Ok. Ich hatte das Datenblatt so verstanden, dass durch die PCIN
Interrupts auch der INT0 interrupt getigert wird. (ja... das ergibt
keinen Sinn... ;-)
In der jetzigen Version funktioniert der Code! Vielen Dank euch allen!
Jetzt muss ich mir nur noch überlegen, wie ich im Interrupt auf die
OCR0B-Werte schreibend zugreifen kann ( ich meine ich muss das
Interrupt-Flag zurücksetzten bevor das geht...).
Ja, der Assembler-Code war von der vorherigen Version...
Thread beobachten
Seitenaufteilung abschalten