... jeder fängt irgendwann mal mit BASCOM an ...

[dremler]

ich habe auch das Buch von rowalt und bin sehr zufrieden

[Bammel]

da kann ich mich auch nur anschließen das Buch ist top

[M*I*B]

... jo, danke Kinnaz; ist auf den Wunschzettel geschrieben

[M*I*B]

@for_ro u.a.:
Ich habe die Nummer mit dem PCINTx mal in Angriff genommen, aber irgendwie klappt das nicht; zumindest nicht im Simulator ...

Ich habe so getan:

Pcmsk0.0 = 1 : Pcmsk0.1 = 1 : Pcmsk0.2 = 1 : On Pcint0 Isr_input
Enable Interrupts

... blabla ...

Isr_input:
  Debounce Irs , 0 , Sub_input , Sub
  Debounce Ta1 , 0 , Sub_input , Sub
  Debounce Ta2 , 0 , Sub_input , Sub
Return

... blabla ...

Im Simulator erreicht der nimmernicht die ISR_input, egal was ich mache. Ist da was verquer oder kann das der Simulator nur nicht?

In dem Zusammenhang noch eine Frage: Es gibt doch bestimmt die Möglichkeit, den jetzt - Zustand eines PIN direkt abzufragen, also ohne Umweg über Register oder so?!? Dann würde ich mir die Sache einfacher machen und den jetzt- Zustand der PIN's via Timer0 in eine Byte- Variable kopieren und das Debouncing dort machen...

[Sauerbruch]

Also, erstmal muss ich mich den Aussagen zum Buch von Roland Walter uneingeschränkt anschließen (auch wenn´s schon auf Deinem Wunschzettel steht )

In Deinem PCINT-Code hast Du vergessen, den Pinchange-Interrupt auch freizugeben. Alle Interrupt-Routinen werden nur dann ausgeführt, wenn nicht nur die globale Interrupt-Freigabe erfolgt ist (enable Interrupts), sondern auch diejenige des speziellen Interrupts. In Deinem Fall also "Enable PCINT0". Der Tiny84 hat nämlich 2 Pinchange-Interrupts: PCINT0 fasst die Eingänge PCINT0...7 zusammen, und PCINT1 die Eingänge PCINT8...11.

Das gleiche gilt übrigens auch für Timer-Interrupts. "Enable timerX" aktiviert mitnichten den Timer als solches, sondern nur den Interrupt im Falle eines Timer-Überlaufes.

Die einzelnen Bits im PCMSK-Register kannst Du übrigens auch "am Stück" setzen:

PCMSK0 = &B00000111 ("&B" heißt binär)
oder
PCMSK0 = 7 (das gleiche in dezimal)

Es gibt doch bestimmt die Möglichkeit, den jetzt - Zustand eines PIN direkt abzufragen, also ohne Umweg über Register oder so?!?

Die einzelnen Bits der PIN-Register sind die Eingangszustände an den jeweiligen Anschlüssen - einfacher als über dieses Register geht´s also nicht!! Liegt am PinA0 ein H an, ist das Register PINA = 1. Liegt das H am Eingang A2, ist PINA = 4. Sind die Pins A1-A3 alle H, wäre PINA = 7.

Du kannst natürlich den Zustand der Eingangspins "konservieren", indem Du einer Byte-Variable den momentanen Wert des PINA-Registers zuweist.

Config Zahl as byte
Zahl = PINA
...
...

Dann wäre der momentane Status gespeichert, auch wenn sich in der Zwischenzeit etwas an den Eingängen ändert. Aber die direkteste Möglichkeit der Abfrage ist das Überprüfen entweder einzelner Bits des PINA-Registers (oder gleich des ganzen PINA-bytes).

Viel Spaß noch beim "simulieren"

Daniel

[M*I*B]

Logisch! Hab ich glatt übersehen; bei dem Timer hab ich es ja auch explizit eingeschaltet Das war jetzt echt Betriebsblind oder so

Nun hab ich es mal eingeschaltet, aber den Simulator juckt das nicht. Ich werde es noch mal in echt ausprobieren, sobald ich einen Tiny84 hier vor mir habe, um festzustellen, ob das tatsächlich nur am Simulator liegt.
Derweil werde ich mal in Verbindung mit der zweiten Frage bezüglich direkter Abfrage via PINx was anderes probieren; kann nicht schaden und übt

Also wenn ich das jetzt richtig verstanden habe, betrifft die Abfrage mit PINx.y immer den echten Zustand der Pins, mit PORTx.y den der Register, oder? oder?

Da drängt sich mir eine weitere Frage auf:
An PINA.0 hängt ein Helligkeitssensor und auf den Eingang ist ADC(0) aktiv. PINA.1, .2 und .3 sind im Grunde Taster (L-Aktiv).
Was ist denn dann PINA, wenn auf dem ersten BIT der ADC läuft? Wird das BIT bei der Abfrage ignoriert und als 0 oder 1 gewertet oder ist der Zustand undefiniert? Darüber habe ich keine Aussagen im Datenblatt finden können ...

Naj, ich probiere es halt mal...

[Sauerbruch]

Also wenn ich das jetzt richtig verstanden habe, betrifft die Abfrage mit PINx.y immer den echten Zustand der Pins, mit PORTx.y den der Register, oder? oder?

Nicht ganz

An die "echten" Pins (im Sinne des kleinen Anschlussbeinchens) kommst Du unmittelbar definitiv nicht ran!

Diese kleinen silbernen Beinchen sind entweder mit dem PIN-Register verbunden (in Richtung Beinchen -> Register) oder mit dem PORT-Register (in umgekehrter Richtung Register -> Beinchen). Entschieden wird das ganze über das DDR-Register (Data Directory Register). Steht ´ne 1 drin, ist der Anschluss ein Ausgang (PORT -> Anschluss); ist das DDR-Bit 0, ist der Anschluss als Eingang geschaltet (Anschluss -> PIN). Dies ist übrigens der Normalzustand nach dem Einschalten, einen Anschluss muss man also nicht extra als Eingang konfigurieren. Das ist er zunächst mal ganz von alleine.

Bei jedem Taktimpuls wird also entweder der "echte" Zustand am Anschluss in´s PIN-Register übernommen, oder aber der Zustand im PORT-Register auf den Anschluss gegeben; je nach DDR-Bit.

Wenn ein Anschluss als Eingang konfiguriert ist, ist das dazugehörige PORT-Bit nicht ganz unbeteiligt: Wird es auf H gesetzt, ist der interne PulUp-Widerstand für diesen Eingang aktiviert. Das kann eine sehr hilfreiche Angelegenheit sein.

Mit dem Befehl GETADC(x) wird der korrespondierende Anschluss mit dem AD-Wandler verbunden. Die Verbindung zum PIN-Register und vom PORT-Register sind dann unterbrochen. Du kannst das PORT-bit zwar setzen oder das PIN-bit abfragen - aber das ergibt keinen Sinn, weil der Anschluss nur dem ADC-Wandler gehört.

Ist es jetzt etwas klarer?

[M*I*B]

... jau Jetzt hat es geklingelt im Oberstübchen! Vielen Dank für deine Geduld!

[Besserwessi]

Schon eine gute Erklärung. Beim ADC Eingang aber noch nicht ganz korrekt:
Dir Port-funktion bleibt auch dann aktiv, wenn der Pin als ADC Eingang definiert ist. Die PIN Funktion (Digitaler Eingang) kann, und sollte man über ein extra Register abschalten. Beim Mega?8 ist das das Register DIDR0.

Es ist nur so, das es selten sinnvoll ist die digitalen Funktionen zu nutzen, wenn man den ADC nutzt. Man sollte dann den Pin als Einang definieren, und die Eingangsfunktion ausschalten.

[M*I*B]

... so ihr netten Leutz

Dank eurer Hilfe ist mir der Einstig in Bascom doch recht flott von der Hand gegangen.
Inzwischen bin ich fertig mit dem Code; zumindest läuft er im Simulator wie erwartet =D>
Sicherlich gibt es an dieser und jener Stelle noch Möglichkeiten, den Code intelligenter zu gestalten und Abläufe zu optimieren, aber Rom ist auch nicht an einem Tag erbaut worden...

Ein paar Fragen nicht direkt in diesem Zusammenhang hätte ich aber noch abschließend zu diesem Thread:

1. Konstanten und Variablen kann ich ja auch ins EEPROM schreiben an Stelle des FLASH... Wann resp. unter welchen Umständen macht das Sinn?

2. Ich möchte dieses System irgendwann mal in ein 1wire- Netz einbinden, aber als Slave. In der Hilfe zu Bascom habe ich zum Betrieb als Slave nichts finden können, auch nicht darüber, ob der/jeder AVR, der von Haus aus für 1wire ausgelegt ist, wo und ob es überhaupt eine UID gibt zur Identifikation auf dem Bus; ok, man könnte z.B. einen DS2401 an den AVR hängen, aber schöner wäre es natürlich, wenn das nicht nötig wäre...