Fingers elektrische Welt

Screenkey ist Taste mit LCD Display drinnen (& rot und grüne Tastebeleuchtung)

Schaltkontakt ist extern, getrennt von LCD Display. Display ist unidirektional, redet über Serielle Interface mit externe Takt, klassische SPI ohne MOSI und CS wird daran bedingt funktioniert. Grund: siehe nächste Zeile.

Aufmerksame Datenblattleser wird anmerken, dass LCD Display Betrieb ohne Takt nicht wirklich möge. Ich habe lang überlegen, wie ich das in AVR und co lösen werden.
Meine Mometane Idee: Timer-Interrupt erzeugen (100khz Interrupt = 50khz Takt) und holt Daten aus Ringbuffer, nur wenn es neue Daten hervorbringt. Einzig was Interrupt ständig auslöst: Flankenwechsel von Takt.

Auch echt gemein: Paritätsprüfung von Start & Stop-Byte und Commando & Daten ist unterschiedlich.

Meine aktuelle Stand ist bisher,dass SPI in Interrupt funktionsfähig ist. Ob ich den Switch & Case oder bit-shifterei nutzen sollen, ich wird beide aufbauen und eines anhand schnellste Laufzeit von interrupt auswählen. Nächste Schritte: Ringbuffer fertigmachen.

Grüss
Matt

Was die da machen ist eher ein USART.
Nur sind die so fies und brauchen auch Takte bei Start/Stop Bits, was ein USART eigentlich nicht vorsieht.
Das brauchen die wohl für den internen LCD Treiber Takt um die Pixel durchzuscannen.

Auch geil dass Start & Stop andere Paritätsberechnung erfordert. (even-Parität, sonst ist odd Parität angesagt)
Und der will pausenlose Takt sehen, auch wenn keine Daten übergetragt wird.

Ich habe da kommentiert: typical british engineering, als ich las, dass Display ohne Takt sich zerlegt wird.
Ich dachte da: Selbst freilaufende RC Oszillator ist für Display-scannen mehr als gut genug.

OB Display 16 bit oder 12 bit Takt für eine Byte-Übertragung braucht, ist da egal. Wichtig ist dass Start & Stop (2x) und Paritätsbit übergetragt werden sollen.
Wahrlich seltsame Ding.

Was is schlimmer? British oder French Engineering?

Von diesen Tastern will man ja eigentlich nicht immer nur einen betreiben, sondern eher so 8.
Daher wäre ein STM32 hier besser, denn der kann 1 bis 16 Bit per DMA auf GPIO direkt raushusten (also 1 bis 16 Taster bespaßen)
Der DMA ist Timergetriggert und dieser Timer generiert auch das CLK Signal.
Der DMA gibt einen Buffer aus, der passend vorberechnet ist.
Der genannte STM32 kann dann entweder auch die Systemlogik beinhalten oder bekommt selber nur Befehle per UART/I2C/SPI/whatever.

Ich hab ja auch welche von den Tastern, aber der Habenwillrefelex war stärker als das Ausdenken einer Anwendung.

Ok ok, ich gebe mich geschlagt. Hier ist auch habenwilleffekt stärker und dann habe ich eine Idee damit gehabt.

Ich habe eine französische Einbau-Instrument mit Nixie an jemand veraalt, nachdem ich festgestellt habe, dass Franzose nichtmal Überlauf-Schaltkreis verbaut hat. Ich kann 3x Überlauf auslösen, dann hängt der Ergebnisse fest irgendwas wie 3342, der auch von Netzspannung & Temperatur abhängt.

Ich hatte mit NEO6 GPS Module und alte 180kmh-Sperre-Entferner wegen ihre Display verheiratet. Dann habe ich mit auf Autobahn auf über 100knoten gebracht, um zu sehen, ob UART-Telegram bei Geschwindigkeit bei 99.99 knoten festhängt. Ne, da verschiebt GPS Modul Kommastelle um eine Stelle nach rechts.

Ja, was du mit STM schrieb, wird ich so ähnlich umsetzen, nur bloss werde ich Ringbuffer inkl. fertig berechnete Paritätsbit nutzen


Grüss
Matt

Bei zB 16MHz wird son AVR bei 100kHz IRQ Auslösung ganz schön ächzen.
Das sind nurnoch 160 Takte zwischen 2 IRQs!
Der kann dann wirklich nurnoch den LCD Controller machen.

Das hast du gut gemerkt, ich habe ebenso gemerkt. Optimerung kommt schon, wenn ich mal Brainfart habe.

Und wenn du den SPI am AVR als Slave fährst? Die 100khz einfach von extern durchprügeln lassen und das SPI Interface nur zum Daten senden scharf schalten. Ggf. einen Hardware Timer als Taktgeber verwenden und den SCK mittels Dioden Oder Gatter Taub schalten.

MfG

Ich denke, der USART im synchronen Modus löst dein Problem.
Ob der Takt beim Betrieb als Master dauerhaft an XCK anliegt, habe ich auf die Schnelle nicht herausgefunden. Als Slave müsste es aber mit einer Brücke gehen:
Man nehme einen Timer, der 100kHz Rechteck erzeugt, klemme den an XCK und an den Screenkey.
Dann werden Daten durch den USART gesendet; das Datenformat ist, so wie ich das sehe, direkt einstellbar.

Ich hab die Dinger einfach per SPI bespaßt, sogar (Fritzler: weghören) per Arduino und mit einem anderen C-Programm per AtMega32U4

Klar, das geht, nur wenn Takt dauerend da ist.. Sobald Takt weg ist, dann hört der auf zu arbeiten und zeigt ne Strich in Display.


Ich bin zurück, USART mit externe Taktgeber, ich habe bisher nicht zum laufen gebracht.

Egal, ich habe meine Interrupt-Geschichte bisserl umgebaut, denn der Screenkey braucht nicht Takt mit 50:50. (d.H. Interruptsverarbeitungsdauer = Taktpulsbreite) Taktfrequenz wird dadurch auch auf 100khz erhöht. Ich belasse so. Für erste.


Erste Lebesnzeichen

Wichtiger Hinweis:
Die mit der weissen Markierung werden wahrscheinlich Kontaktprobleme haben.
Zum testen also am besten eins verwenden, welches nicht markiert ist.

Das habe ich in deine Verkaufsangebot gelesen und diese gezeigte Exemplare ist von dir ausgelötet

Ich habe den Screenkey fast vergessen und kürzlich ist es wieder entdeckt und mit Code weitergemacht.

Einfach ekelhaft, dass Display alle 2te Zeile 4 bit offset hat.

Ist das normal das der DS18S20 mit 5V eine starke Eigenerwärmung 4-5°C hat?

Ich glaub, du hast es in falsche Theard gepostet .

Hightech hat geschrieben:Ist das normal das der DS18S20 mit 5V eine starke Eigenerwärmung 4-5°C hat?

Wenn du ihn nonstopp ausliest ja. Bei jedem mal auslesen wird er Wärmer beim daten zurücksenden. Wenn du nur 1x in der Minute liest ghet dass oder an einen Kühlkörper spaxen.

Matt hat geschrieben:Ich habe den Screenkey fast vergessen und kürzlich ist es wieder entdeckt und mit Code weitergemacht.

Einfach ekelhaft, dass Display alle 2te Zeile 4 bit offset hat.

Aber er läuft. Beim Anblink vom Traffo hätte es sicher für das Display auch böse ausgehen können wenn es sich quer gestellt hätte.