Demultiplexer

[LotadaC]

Dino, immer wieder herrlich... wie schon letztens die Sache mit dem Hefeteig...

Etwas besser wird die Sache mit den beiden 8bit-Schieberegistern noch, wenn Du Dir die als 2 Bahnhöfe direkt hintereinander denkst. Nach 8 Schiebetakten steht der erste Wagen in Bahnhof 1 und der zweite noch "in der Botanik", wenn jetzt alle Fahrgäste ausgekippt werden, landen die vom 2ten im Nirvana, die vom ersten im falschen Bahnhof.

Mit /G=low werden die Rampen überhaupt erst an die Gleise gestellt, ohne könne die Fahrgäste nicht auf den Bahnsteig hopsen...

 

[IngoP]

@ DINO

SUPER Erklärung !!!


LotadaC und DINO vielen Dank, dass ich mich hier "erleuchtet".

 

[IngoP]

Nun zum I2C und den

Weiche = I2C-Adresse des Bausteins...
Gegenüber den Schieberegistern wird aber im Atmel eine andere Hardware benutzt. Damit benötigst du andere Befehle. Die Bausteine arbeiten auch etwas anders. Im Grunde aber alles vergleichbar.

I2Cstart = Alle Bausteine ACHTUNG!
I2Csend Schreibadresse = Weiche einstellen
I2Csend Datenbyte = Waagen in den Bahnhof schieben, Türen auf und Fahrgäste auf die Rampe schubsen
I2Cstop = Alle Bausteine wieder vom I2C-Bus "abkoppeln" ( so ungefähr) ... Übertragung beendet ... Sendung ist aus ... oder so


Gruß
Dino

OK, soweit so klar. Ich habe mal in der Befehlsreferenz nachgesehen:


I2cwbyte Addressw 'slave address >> die des ersten Schieberegistern ? Ist die NUmmer frei wählbar ? I2cwbyte Adres 'asdress of EEPROM >> die Adresse meines Atmel ist diese Adresse auch frei wählbar ?

Und wie verhält es sich dann mit meinem Display ? bzw. der Tastatur wenn ich den I2C initialisiere? stehen diese dann Still ?

Es wurde auch erähnt, dass ein Interrupt gesetzt werden muss. Warum ? Wenn ich den Code sequentiell durcharbeite, was könnte dann stören ? Eine Tasteneingabe verursacht einen INT0 ok., dies würde dann glaube ich stören?

Sollte dann ein INT0 für das Senden und INT1 für Tastaur genutzt werden ?

 

[LotadaC]

...
Auch beim TWI können am Bus andere ICs hängen, solange die Adressen sich nicht in die Quere kommen. Es stehen theoretisch 7 Bit als Adresse zur Verfügung (das LSB bestimmt die Kommunikationsrichtung, 'ne 0 steht für Schreiben (Master->Slave)). Adresse 0x00 ist der Generall Call an alle Slaves, natürlich Schreiben, es darf keiner drauf antworten. 0x01 existiert somit logischerweise nicht. Bei vielen I2C-ICs ist ein Teil der Adresse fest, einen Teil kannst Du selbst variieren - um eben mehrere ICs desselben Typs mit unterschiedlichen Adressen an ein und denselbem Bus zu betreiben zu können.

Genaueres steht im Datenblatt des ICs, beim verlinkten PCF... kannst Du die unteren 3 der 7 Adressbits vorgeben, indem Du 3 Beine (A3..A1 oder so) entsprechend auf Vcc oder Gnd legst.

Display und Tastatur: wie sind die denn angebunden, wie werden die angesteuert/ausgewertet?

 

[IngoP]

Hi.
also die Tastur soll über 7 normale PINs wie in dem Beitrag zur Tastaturmatrix beschrieben eingebunden werden.
Das Display soll über SPI am Mega 128 USB angeflanscht werden.

+ natürlich RESET PIN und 3 Backlicght "Switches"

 

[IngoP]

Genaueres steht im Datenblatt des ICs, beim verlinkten PCF... kannst Du die unteren 3 der 7 Adressbits vorgeben, indem Du 3 Beine (A3..A1 oder so) entsprechend auf Vcc oder Gnd legst.

Display und Tastatur: wie sind die denn angebunden, wie werden die angesteuert/ausgewertet?

Das mit den unteren Adressbits verstehe ich nicht.
Wie soll das denn geschehen ? Ich würde mich dann ja einiger Ausgänge des Registers berauben ?

deshalb die Frage nach der Slave adresse

 

[TommyB]

Ich komm hier jetzt auch grade durcheinander...

Also das mit Schieberegister ist doch für SPI gedacht gewesen. Das mit I²C/TWI mit PortExpander war doch nur als Alternative gedacht, oder nicht?
SPI nutzt keine Adressen. Nur Chip Enable Signale.

 

[dino03]

Hi Ingo,

I2cwbyte Addressw 'slave address >> die des ersten Schieberegistern ? Ist die NUmmer frei wählbar ? I2cwbyte Adres 'asdress of EEPROM >> die Adresse meines Atmel ist diese Adresse auch frei wählbar ?

theoretisch kannst du ne x-beliebige Adresse senden. So wie du auch irgendeine x-beliebige Adresse auf nen Brief schreiben kannst. Die Frage ist ob er da ankommt wo du willst.

Bei Mikrocontrollern, I2C, SPI, ... ist auf jeden Fall nichts mit Plug-n-Play

Jeder I2C-Baustein hat eine Basisadresse. Sozusagen die Straße. Dann kann man bei den meißten Bausteinen auch noch 1-3 Bit der Adresse über Pins am Baustein selber bestimmen. Das ist zB bei den PCF8574 Portexpandern wichtig. Alle mit der selben Adresse kann man ja nicht auseinanderhalten. Die stellen aber auch nicht zig verschiedene her nur weil man eventuell 2 oder 3 am Bus benötigt. Also mußt du einen Teil der Adresse über diese Pins am IC bestimmen. Das wäre dann sozusagen die Hausnummer. Die I2C-Adresse hat immer 7 Bit. Das letzte Bit ist für die Unterscheidung Lesen oder Schreiben. Also hat jeder Baustein eine Lese- und eine Schreibadresse.

Damit es fies wird geben manche Hersteller die I2C-Adresse ohne das Lese-/Schreibbit an und man muß es selber dazudenken. Die meißten geben es aber mit an.

Gruß
Dino

 

[LotadaC]

...Und wie verhält es sich dann mit meinem Display ? bzw. der Tastatur wenn ich den I2C initialisiere? stehen diese dann Still ?

Es wurde auch erähnt, dass ein Interrupt gesetzt werden muss. Warum ? Wenn ich den Code sequentiell durcharbeite, was könnte dann stören ? Eine Tasteneingabe verursacht einen INT0 ok., dies würde dann glaube ich stören?

Das Display zeigt immer solange ein statisches Bild an, bis Du neue Daten hinschicken läßt. Solange Du die Sendebefehle nicht durcheinanderschmeißt (zum Beispiel indem Du irgendwas aus einem Interrupt heraus sendest (was Du also nicht(!) tun solltest), kommt sich da nichts in die Quere. Beim SPI und TWI wartet Bascom immer, bis der entsprechende "Sendebefehl" abgearbeitet ist (auch wenn die Hardware das im Hintergrund allein senden könnte. Die meiste Zeit in Deinen "Messen->auswerten->steuern/darstellen"-Zyklen wird Dich der 1wire-Bus aufder anderen Seite kosten, und der IST zeitkritisch (weil die AVR selbst sowas in Hardware nicht unterstützen, Bascom sich also in Software drum kümmert).
Ich hab den jetzt konkret nicht im Kopf, wie ein Telegramm da aussah (irgendwas mit Puls-Pause-Modulation oder so, und es werden mehrere Adressbytes übertragen, und das ziemlich langsam ??)

Bleiben als Problem die (zu etprellenden?) Taster - ob da Interrupts Sinn machen, oder ob man die einfach im Programm regelmässig (zB zwischen 2 1wire-Sensoren) pollt, muß man mal genauer durchspielen (ggf hätten man dann da bereits die Entprellung erschlagen) - welche Reaktionszeiten forderst Du denn von den Tastern?

Pack doch einfach mal das ganze Projekt auf den Tisch...

 

[IngoP]

...
Pack doch einfach mal das ganze Projekt auf den Tisch...

sehr gerne, nur ich komme aktuell nicht dazu das ganze einmal zu Visualisieren(KICAD).
Ich versuche es mal mit dem nachfolgenden erweiterten Blockschaltbild




Die Tastatur soll dann akls Menüsteuerung dienen und die jeweiligen Parameter bzw. Sichten einstellen können. ( http://www.avr-praxis.de/forum/showthread.php?83-3x3-Tastenmatrix-inkl-Interrupt-mit-ATmega128-unter-BASCOM-AVR )

Ich hoffe das hilft schon einmal ein wenig weiter.
Das KICAD Schaltbild kommt ...

 

[LotadaC]

Die Schieberegister können sich den SPI-Bus mit dem Display teilen.
Ich würde jedoch überlegen, für die Tasten und die Relais über TWI zu gehen, und bei den Tasten den Interrupt-Ausgang zu nutzen (aber im AVR nicht unbedingt als Interrupt).
Display über SPI, die Sensoren über 1wire (Bascom).

Die Backlight-Farbe soll diskrete Werte bekommen, oder über 3 Hard-PWM gesteuert werden?

 

[IngoP]

Also Display SPI, klar. Was für einen Vorteil hätte es denn dann bei dem Output zu den Schieberegistern über TWI zu gehen ?
Ich habe mir die Doku mal angesehen, jedoch habe ich och nciht die Adresse gefunden über die wir redeten.

Tasten und die Relais über TWI zu gehen, und bei den Tasten den Interrupt-Ausgang zu nutzen (aber im AVR nicht unbedingt als Interrupt).

Die Tastatur hatte ich eben so geplant, dass ich sieben einzelne Pins nutze, wie es Markus in seinem Beispiel auch implementiert hat.
Wieso an der Stelle kein Interrupt im AVR? Wo ist da der Sinn -> Ressourcen ?

Die Sensoren über 1 Wire zu verdrahten ok. Somit würden dann alle DS18B20 auf dem BUS an TX senden die GND und VDD Anschlüsse kan man ja zusammenführen ...

Bei der Hintergrund beleuchtung möchte ich gerne 3 verschiedene Zustände alleine über die Backgroundbeleuchtung anzeigen. (ROT = Fehler, GRÜN = alles OK, WEISS = MENÜ / EINGABE) Hier also 3 PINS als OUTPUT mit den avisierten Transistoren. Keinen PWM nur ein oder aus.

 

[dino03]

Hi,

Die meiste Zeit in Deinen "Messen->auswerten->steuern/darstellen"-Zyklen wird Dich der 1wire-Bus aufder anderen Seite kosten, und der IST zeitkritisch (weil die AVR selbst sowas in Hardware nicht unterstützen, Bascom sich also in Software drum kümmert).
Ich hab den jetzt konkret nicht im Kopf, wie ein Telegramm da aussah (irgendwas mit Puls-Pause-Modulation oder so, und es werden mehrere Adressbytes übertragen, und das ziemlich langsam ??)

Die Sensoren über 1 Wire zu verdrahten ok. Somit würden dann alle DS18B20 auf dem BUS an TX senden die GND und VDD Anschlüsse kan man ja zusammenführen ...

mal was zum 1Wire ... Also das ganze ist komplett in Software und sehr zeitkritisch. Es kommt dabei auf die Low-Zeit des Signals an. Da können bereits ein paar Mikrosekunden Unterschied aus einer 1 eine 0 machen oder umgedreht. Die High-Zeit ist nach meiner Erinnerung nicht so das Problem.

;            __                  ___________              _________
; Init/Reset   |________________/           |____________/     :
;              :                :           :            :     :
;              |                |- 15-60us -|- 60-240us -|     |
;              |- >=480us ------|--------- >=480us ------------|
;              |- Master Tx ----|----------- Master Rx --------|
;
;
;           ___                             _______  <1us _______________________
; Master Tx    |___________________________/       |_____/  :        :        :
;              :        :        :        :        :        :        :        :
;              |- 15us -|- 15us -|- 30us -|        |- 15us -|- 15us -|- 30us -|
;              |----- 60-120us -----------|- >1us -|----- 60-120us -----------|
;              |     Slave-Sample^        |        |     Slave-Sample^        |
;              |- Master Write 0-Slot ----|        |- Master Write 1-Slot ----|
;
;
;           ___ >1us                        _______ >1us   ______________________
; Master Rx    |____ ________///////////////       |____ // : :               :
;              :    :   : :               :        :    :   : :               :
;              |- 15us ---|--- 45us ------|- >1us -|- 15us ---|--- 45us ------|
;              |    :   ^Master-Sample    |        |    :   ^Master-Sample    |
;              ##### vom Master generiert          ##### vom Master generiert
;

Das ist nen Stück aus nem älteren Assembler-Programm. Die Zeit zwischen den Bits muß lediglich >1µs sein. An der Stelle ist also Luft. Theoretisch könnte man also nach jedem 1Wire-Bit eine Interrupt-Routine zulassen. Da man bei Bascom aber keine einzelnen Bits senden kann wäre es eine Lösung zwischen den einzelnen 1Wire-Byte-Befehlen Luft für mögliche Interrupts zu lassen. Also nicht gleich nen Write oder Read mit 8 Bytes ausführen. Über die Möglichkeit könnte man dann Interrupts und 1Wire-Timing recht geschickt ineinanderschachteln.

Gruß
Dino

 

[LotadaC]

Meine Überlegung zielte darauf ab, einen I2C-Portexpander für die Taster (als Input) zu verwenden, und über den /INT-Ausgang 'ne Änderung der Taster an den µC zu signalisieren. Dieser Ausgang wird aber vom Expander wieder zurückgenommen, wenn die Eingänge wieder zurückgesetzt werden - bringt also nicht wirklich was...

Du kannst neben dem Display problemlos die 595-Schieberegister (kaskadiert) und ein 165-Schieberegister für 8 Taster am selben Bus betreiben. Mit je einer /CS Leitung für Display, Eingänge, Ausgänge. Und was das Display sonst noch so hat.

Zeitkritisch ist (mehr oder weniger) der 1wire-Bus. Bascom wartet da aber eh. Reihenfolge sollte in etwa sein:
-Sensor X adressieren (Reset+Kommando+ 8Byte-Adresse)
-Scratchpad auslesen (ggf nur die Temperatur-Bytes)
-Wert zwischspeichern
-weiter mit nächstem Sensor

Sind alle Durch, löst Du bei allen simultan 'ne neue Konversion aus, und hast jetzt etwa die Konversionszeit (abhängig von der geforderten/eingestellten Auflösung)für die Verarbeitung:
-gespeicherte Werte aufbereiten/auswerten
-Displayausgabe aktualisieren/Relais aktualisieren
-Taster abfragen (pollen) und ggf darauf reagieren.

Wenn man das mit der Konversionszeit gut zusammenbekommt, kann man damit gleich das Prellen mit erschlagen...

 

[IngoP]

Nun das klingt nicht gut. ;-) sonern Kompliziert !

Muss ich zwingend über den Portexpander gehen für die Tastatur gehen?
Für die Tastatur habe ich genügend Pins. und den 47HC11 als AND Gatter um den INT zu setzen.

Ich habe doch einen 1 Wire Bus bei dem ich nach einander einzelne Sensoren Abfrage. S1, Wert in die Varibale , S2 auslesen ... USW.
Nach der ersten "Abfrageschleife" geht es dann an die Auswertung der Messwerte, und im Nachgang dann an die Stellgleider...

Ich habe mal eine Schaltplanskizze angehangen. Vielleicht sollte ich erst einmal mit Display und Relais beginnen ... dann die Sensoren und dann die Tastatur ...

Die Tatsatur soll ohnehin nur für Menüs (Anzeige einzelner Werte, eingabe Hysteresen MAX und MIN) genutzt werden.

Was mich

 

[IngoP]

.....
-Sensor X adressieren (Reset+Kommando+ 8Byte-Adresse)

....

Könnte ich mir die Adresse "organisieren", wenn ich diese im Vorfeld an einem µC auslese und mir dann OLDschool like aufschreibe und an die jeweiligen Sensoren pinne ?
So weis ich dann welcher Sensor wie heißt und ich bekomme die Zuordnung zu den einzelnen Mess-Stellen hin.

 

[LotadaC]

...Muss ich zwingend über den Portexpander gehen für die Tastatur gehen?
Für die Tastatur habe ich genügend Pins. und den 47HC11 als AND Gatter um den INT zu setzen...

Nein, wenn Du genug Beine hast, kannst Du die Taster direkt auswerten. Ich würde da wie gesagt keine IRQs verwenden, sondern die Beine regelmäßig pollen. Du hast noch nicht gesagt, mit welcher Auflösung (Konversionszeit) die Sensoren fahren sollen - das läßt sich sicher unter einen Hut bekommen (Also vielleicht 2-4mal pro Sekunde 'ne neue Messung anstoßen, und eben auch die Taster abfragen usw - vereinfacht die Entprellung)

Wenn Du so'n Mords-Controller einsetzt, also genug Beine hast, kannst Du auch die Relais direkt ansteuern (mit Darlingtons oder so als Treiber für die Relais -> ULN2803 oder so - oder hattest Du da bereits was?)

Wenn Du bei den Schieberegistern bleibst, gehören die mit an den SPI-Bus (also MOSI->SER(IN) vom ersten, SCK->SRCK (beide), RCK auf einen beliebigen freien (nicht-SPI) Pin, und mit externem Pullup (10K oder so) auf Vcc gezogen).
SRCLR brauchst Du nicht -> muß Hi sein (glaub ich -> über 10K fest auf Vcc legen)

Als Beine für's Backlight würde ich bei dem Controller die OC-Pins von Timer3 nehmen. Kannst Du erst mal Deine diskreten Farben nutzen, später aber problemlos auf PWM umstellen, ohne an der Hardware was ändern zu müssen. Timer 3 wird Bascom mMn selbst wenig blockieren.

Dann stellt sich noch die Frage, wie Du Dein Menü aufbauen willst - irgendwer hatte hier mal ein sehr gutes Konzept vorgestellt - wo die Ganzen Unterpunkte direkt über Speicheradressen oder so umgesetzt wurde. Sehr gut umgesetzt, aber als Anfänger heftig da durchzusteigen.

Hast Du das irgendwo in der FAQ mit drin, Dino?

---

1wire-Adressen:
kannst Du natürlich zur Laufzeit ermitteln (quasi den Bus Scannen -> Adressen ausprobiere und merken (internes Eeprom)).
Oder Du gibst die Adressen im Code vor, dann mußt Du aber bei neuen Sensoren neu compilieren.
Sinnig wäre ein Menüpunkt, wo Du nach unbekannten Sensoren suchen kannst. Wenn Du Dich auf diese Sensoren beschränkst, ist der Family-Code immer der gleiche, die CRC ist konstruierbar. Ablegen müßte man also nur 6Byte pro Sensor. Andererseits stehen Dir 4K-Eeprom zur Verfügung.

 

[IngoP]

Hi,

sorry dass ich das überlesen habe.
Also der refresh der Temperatursensoren reicht alle 1-5 sec. aus.
Wir sprechen hier von einer Fussbodenheizung. Da ist die Reaktion eher träge.

Ich hatte ohnehin vor Messwerte zu sammeln und einen Durchschnitt zu bilden und dann zu entscheiden ob Grenzwerte erreicht wurden oder nicht.
So kann ich die Auswirkungen dann gegen Windzug etc. ein wenig abschotten.

Ich werde mal die Tastatur und Deine Vorschläge in meinen Plan integrieren und dann noch einmal posten.

 

[IngoP]

Wenn Du bei den Schieberegistern bleibst, gehören die mit an den SPI-Bus (also MOSI->SER(IN) vom ersten, SCK->SRCK (beide), RCK auf einen beliebigen freien (nicht-SPI) Pin, und mit externem Pullup (10K oder so) auf Vcc gezogen).
SRCLR brauchst Du nicht -> muß Hi sein (glaub ich -> über 10K fest auf Vcc legen)
.

Wieso muss der RCK nochmals EXTERN auf VCC gezogen werden? Ich habe das auf Grund Deiner Empfehlung seinerzeit mal so gemacht ... aber warum ist das so ?

 

[LotadaC]

Puh... das ist über'n Jahr hergewesen...
RCK war meiner Meinung nach sowas wie'n Latch-Impuls, oder? müßte ich jetzt nochmal ins Datenblatt schauen...
Zumindest habe ich in #16 damals sowas geschrieben.
Wenn das externe Schieberegister schneller aus dem Reset kommt als der Controller seine Beine initialisiert (der ja auch erstmal aus dem Reset kommen muß), hast Du auf der Leitung erstmal 'n undefinierten Zustand (die anderen Leitungen können also als Antennen lustig durch die Gegend zappeln, und irgendwas in die Register ein-/ausclocken -> der ebenso zappelnde RCK legt das dann auf die Ausgänge, macht es wirksam), bis der Controller das bein irgendwann auf einen Hi-Pegel setzt (was u.U. eine weitere steigende Flanke ist -> Clock). Solange wie der Controller vom PowerUp über den Reset bis zu der Stelle im Programm braucht, wo das Bein Hi gesetzt wird, ist es Tristate. Der Pullup sorgt also für geregelte Zustände beim PowerUp.

UND: bei einigen Controllern wird auch über den SPI geflasht. Dabei wird der Controller im Reset gehalten, während der Programmer mit dem Controller kommuniziert. Im Reset sind alle anderen Pins Tristate, die Schieberegister könnten also reagieren. Dabei kann's dann zu lustigen Effekten kommen, wie @TommyB bestätigen kann...