Bascom Auslesen eines Messschiebers Bascom Glcd

[LotadaC]

Hmm... das ist auch ein Dinosaurier. Der hat quasi keine HW-Kommunikationsschnittstelle. (der "SPI" geht nur zum flashen des Controllers).
Ich würde das so angehen:
-einen µC als Master, wie schon gesagt. Irgendeinen geeigneten (neueren) Mega, wegen dem ganzen Displaykram und so einfachheitshalber in Bascom geproggt.
-Datenbus für die Slaves, wahrscheinlich TWI, ggf mit zusätzlichem "was neues"-Netz
-für jeden Slave einen kleinen µC, den ich in Assembler proggen würde. Aber ich würde eher den Tiny25/45/85 nehmen. Der hat zumindest schon USI an Board (für den TWI-Bus verwendbar, oder für SPI). Und den gibts auch als (einfach verlötbaren) SOIC8. 2 Pins Stromversorgung, 1 Pin Reset, 2 Pins zum MS, 2 Pins für den Bus. Bleibt einer für mein Netz, oder man schaltet mit dem die Stromversorgung des MS.

Interessant finde ich auch die anderen Modi der MS - die man mit den beiden Leitungen ... herbeiführen kann (-> 50 Ergebnisse/s und so).
Achso: Dieses 2te 24bit-Paket (LSB-first übertragen) ist (lt Nick) sowas wie eine vorzeichenbehaftete Binärzahl (Zweierkomplement) - damit kannst Du den Rechenzwerg direkt rechnen lassen. In welcher Form die Daten dann zum Master wandern sollen, ist auch noch zu überlegen - der Tiny hat ja genug Zeit zum Aufbereiten der Daten. Selbst im Fast-Mode des MS.

Zu Deinem Edit: der 26er geht auch, hat schon wieder mehr als der 25er (was Du nicht brauchst, egal). Und ich hab mir irgendwann mak das DB ausgedruckt gehabt.
Und ja, jeder µC braucht eine eigene Programmierschnittstelle (ok, mit den Resets könnte man vielleicht auch irgendwas ganz exotische machen... aber ... nee)
Ich würde jedem Slave eine eigene kleine Platine gönnen, und die zum Programmieren von der restlichen HW abziehen (also auch vom MS). Jede schleift den Kommunikationsbus (und die Stromversorgung) durch, dann kann man die einfach hintereinander stecken.

P.S.: zur Kommunikation mit dem MS dann vielleicht statt der Komperatoren bidirektionale Levelshifter? (CASSIOOOOOOOOOOO ? *hilferuf*)

 

[dino03]

Hi Matthias,

So werd jetzt mal schauen was mit nem Tiny 15 zum auslesen machbar ist und wenn mir das Datenblatt zusagt werd ich sie bestellen.

also diese 8Pin-Tinys sind mit den IO-Ports recht dünn versorgt. Du hast eigentlich nur ...
8 Pins
-2x Versorgung
-1x Reset
---------
=5 IO-Pins
-2x Quarz (für einen genauen Takt)
-----------
=3 IO-Pins.

und nun kommst du ... Was willst du mit 3 IO-Pins anfangen wenn du eventuell noch nen Quarz für ein genaues Timing benötigst ?

Meinst du mit dem Tiny15 den Tiny25 ? Den Tiny15 find ich bei Atmel nicht mehr. Ich tippe mal das der nicht mehr hergestellt wird und nur noch Restbestände vorhanden sind. Siehe auch "AVR501: Replacing ATtiny15 with ATtiny25". Gefunden habe ich bei Atmel noch ein "Mature Datasheet" was mir sagt das das Ding nur 1kFlash hat. Ich tippe also mal bei dir auf nen 8poligen mit 2kByte Flash (tiny25 = Nachfolger). Ich würde an deiner Stelle aber mindestens nen 14poligen Tiny verwenden. Alleine schon wegen der IO-Pins.

EDIT: siehe auch Atmel AVR 8- and 32-bit Microcontrollers - Mature Devices
Devices not Recommended for New Designs
ATtiny15L . . . 8-bit AVR Microcontroller, 1KB Flash, 8-pin
Mature product; not recommended for new designs. Replaced by ATtiny25.

Gruß
Dino

 

[dino03]

hab ich wohl etwas lange zum schreiben gebraucht ...

edit:
Attiny 15 gibs nicht Schreibfehler, bin jetzt alle! Daten der Atmel reihen durch und werde wohl den Attiny 4 zum auslesen nehmen und mit 6 pins ist der gar noch kleiner wie die OAP´s davor .
Muss halt nur schauen ob ich mit die 512 Byte auskomme aber nur das auslesen und eventuell berechnen sollte sich ausgehen.

ATtiny4 ... 6Pins ... 512Byte ... Was willst du damit anstellen ? Ne LED blinken lassen ?

Du brauchst ...
2x Versorgungsspannung
2x IO-Pins für Messschieber
2x eventuell Quarz für nen sauberen Takt
1-2x IO-Pins zum Daten weitersenden
1x Reset (selbst für das neue TPI-Protokoll zum programmieren Reset/TPIclk/TPIdata)

Da fällt mir nur eins zu ein ... Du bist irre !

Nimm dir nen Atmel der genug Pins und Speicher hat. Wenn nicht dann brauchst du nachher auch nicht ankommen und rumheulen das es nicht klappt.

Gruß
Dino

 

[LotadaC]

Und weiter gehts mit dem Kontroller-Durcheinander. Hier werden ganze Generationen durcheinander geworfen.
-diese PinChangeInterrupts haben quasi alle moderneren 8bitAVR. Allerdings sind die anders zu handhaben, als die "normalen" externen Interrupt-Pins
-die meisten älteren Tinys besitzen keine HW-Kommunikationsschnittstelle (der SPI nur zum proggen - ISP). Die neueren haben USI, damit kann man in Grenzen TWI/SPI/UART(?) improvisieren (weitgehend in Hardware).
-einige neue Tinys (4/5/9/10) werden nicht mehr mit SPI-ISP programmiert, sondern mit TPI (TinyProgrammingInterrface oder so) - das muß der Programmer aber unterstützen (der AVRISP markII kanns).

Ich denke, daß es bei den Slaves nich auf exaktes Timing ankommt - sowohl die Kommunikation mit dem MS, als auch die mit dem Master soll ja je über clock-Leitungen synchronisiert werden. Insofern genüg sicher der interne Taktgeber. Meiner Meinung nach reicht da jeweils der 25er - ok, mit mehr I/Os kann man jedem Slave noch weitere (welche?) Funktionen verpassen.

 

[dino03]

Hallo,

irgendwie wird Matthias grade zum Nebendarsteller

Und weiter gehts mit dem Kontroller-Durcheinander. Hier werden ganze Generationen durcheinander geworfen.

stimmt.

-einige neue Tinys (4/5/9/10) werden nicht mehr mit SPI-ISP programmiert, sondern mit TPI (TinyProgrammingInterrface oder so) - das muß der Programmer aber unterstützen (der AVRISP markII kanns).

Aber selbst für die TPI-Schnittstelle benötigt man zwingend den Reset-Pin. Wieweit man TPIclk/TPIdata dann mit anderen Funktionen verquicken kann weiß ich jetzt nicht. Da hab ich mich noch nicht mit befaßt.
Das wären dann also mit der Versorgungsspannung zusammen schonmal mindestens 3 Pins.

Ich denke, daß es bei den Slaves nich auf exaktes Timing ankommt - sowohl die Kommunikation mit dem MS, als auch die mit dem Master soll ja je über clock-Leitungen synchronisiert werden. Insofern genüg sicher der interne Taktgeber. Meiner Meinung nach reicht da jeweils der 25er - ok, mit mehr I/Os kann man jedem Slave noch weitere (welche?) Funktionen verpassen.

OK. Dann also ohne Quarz. Das sind dann aber schonmal ...
2x MS-Interface (Clock/Daten)
2x Dateninterface (Clock/Daten) damit man synchron bleibt.
Bei asynchroner Übertragung benötigt man ja wieder einen genauen Takt
Das sind also weitere 4 Pins.
Macht dann zusammen also mindestens 7 Pins.
Wenn man dann bei dem Tiny noch nen Datentransfer von außen anschubsen will benötigt man beim Dateninterface noch nen weiteren Pin (also wie beim SPI - MISO/MOSI/SCLK). Damit sind die 8 Pins weg. Es bleibt nichts mehr übrig um eventuell auf ein anderes MS-Protokoll umzustellen oder irgendetwas anderes dranzusetzen.
Für meinen Geschmack ist das echt auf Kante genäht. Aber naja ...

Soll Matthias mal wieder ein wenig Senf dazugeben damit er nicht total aus seinem Thread rausgezwängt wird

EDIT: Ach ja ... SPI-Interface würde ich Richtung MS nicht einsetzen weil es immer 8Bit in einem haben will. Das ist bei so einer Schnittstelle wie sie bei Messschiebern eingesetzt wird alles andere als optimal. Man kann das Timing der Schnittstelle ganz schlecht nachbilden. Ich würde das mit Interrupt auf der Clock-Leitung und dann Abfrage der Clock und Datenleitung machen. Also so wie es sich auch langsam rauskristallisiert.

Gruß
Dino

 

[Matthiasab64]

Das liegt daran das ich nicht mitbekommen habe das eine 3 seite dazugekommen ist und ich noch auf seite 2 auf ne antwort gewartet hab jetzt muss ich erst mal lesen

gruss matthias

 

[Matthiasab64]

Hallo ihr beiden,


Das mit dem irre nehm ich als kompliement, sagen auf Arbeit auch alle also muss ja was Gutes haben.

Ein Quarz hatte ich nicht vorgesehen da wie ihr schon sagtet das ganze mit Clock Syn. wird.

Du hast recht Dino, ich hab mich da wohl ein bischen blenden lassen von der kleinen Bauform(ich liebe es wenn es alles so klein wie möglich ist, das hat damals meinem Lehrer in der Lehre schon gestört wenn ich mein lochraster nur zu 10% genutzt hab)
Also dann ne nummer grösser.

2x MS-Interface (Clock/Daten)
2x Dateninterface (Clock/Daten) damit man synchron bleibt.
Bei asynchroner Übertragung benötigt man ja wieder einen genauen Takt
Das sind also weitere 4 Pins.
Macht dann zusammen also mindestens 7 Pins.
Wenn man dann bei dem Tiny noch nen Datentransfer von außen anschubsen will benötigt man beim Dateninterface noch nen weiteren Pin (also wie beim SPI - MISO/MOSI/SCLK). Damit sind die 8 Pins weg. Es bleibt nichts mehr übrig um eventuell auf ein anderes MS-Protokoll umzustellen oder irgendetwas anderes dranzusetzen.
Für meinen Geschmack ist das echt auf Kante genäht. Aber naja ...

2x MS-Inteface brauch ich ja nicht, wenn ich die Tinys neme bekommt jeder MS einen also:

Tinyxx
2xPin (Clock/Data)
2xPin versorgung
und dann 2-3 Pin´s für die Daten zum Displaytreiber
und wenn ich es nicht per soft hin bekomme zu erkennen ob ein MS am Tiny hängt bräuchte ich noch einen weiteren Pin z.B. einen gesteckten Stecker =1 nicht gesteckt = 0 zur erkennung
und ich gehe auch nicht davon aus das ein MS mal kaputt geht, und wenn doch die Hardware bleibt die selbe und die software .......

EDIT: Ach ja ... SPI-Interface würde ich Richtung MS nicht einsetzen weil es immer 8Bit in einem haben will. Das ist bei so einer Schnittstelle wie sie bei Messschiebern eingesetzt wird alles andere als optimal. Man kann das Timing der Schnittstelle ganz schlecht nachbilden. Ich würde das mit Interrupt auf der Clock-Leitung und dann Abfrage der Clock und Datenleitung machen. Also so wie es sich auch langsam rauskristallisiert.

Mit der SPI würde ich die fertig berechneten Daten vom Tiny zum Mega senden.


-----------------------------------------________
MS1-----2--------Tinyxx1-----3------|----------|
----------------------------------------|----------| -------14------Display
MS2-----2--------Tinyxx2-----3------|----------|
----------------------------------------|----------|
MS3-----2--------Tinyxx3-----3------|----------|
----------------------------------------|----------|
Drehzahlmessung----xxxx-----------|----------|
----------------------------------------|----------|
Tastenfeld für Offset-----------------|----------|
----------------------------------------|_______|
----------------------------------------Megaxxx

Das mit dem Tiny 26 war darauf bezogen das es der einzige Tiny ist bei dem nicht alle I/O Pin´s INT´s sind.

Das blöde ist nur das meine Messschieber Exoten sind(umsteigen ist nicht, hab viele gekauft weil sie günstig waren) und eben nicht dieses 2*24 bit haben und auch keine möglichkeit irgend einen Modus zu wählen(Fast, Hold, Holdmax, Holdmin usw) vielleicht hat der hersteller diese möglichkeiten versteckt integriert und können nur über ne bestimmte Kombi aufgerufen werden aber wer weiss das schon, die Anleitungen beschränken sich darauf nem "Frisör" die Anzeige zu erklären.
Sonst, wenn ich den "Fast" Modus mit den 20 ms hätte würde wahrscheinlich auch die "Schiftin" variante ausreichende ergebnisse liefern mit einem AVR.

Ich werde mir erstmal was raussuchen was Pinmässig auch aussreicht und dann bestellen, der Tiny4 gefällt mir sowieso nicht mehr - zum einen bräuchte ich wieder nen anderen Programmer, dann wie Dino schon sagte reichen meine Pins gar nicht und man bekommt ihn schlecht und wenn dann ist der versand (ungelogen) 8X teurer als der Tiny selbst, schaut mal bei googel

Werde jetz mal folgendes ausprobieren:
Ich hab noch zwei Tiny2313 rumliegen, werde an den beiden mal MS dranhängen - auslesen und berechnen und entweder TWI oder SPI senden, zum Mega16(den hab ich eh grad auf dem Pollinboard) so aber später in der Schaltung nen kleinerer werden. Mal sehen ob ichs hin bekomme.

So nun wird David mal die beiden Goliath´s wieder ran lassen

Gruss Matthias

 

[dino03]

2x MS-Inteface brauch ich ja nicht, wenn ich die Tinys neme bekommt jeder MS einen

ich meinte damit ...
2 Pins MS-Interface

das 2x bezieht sich also auf 2 IO-Pins. Ich habe immer nur mit einem MS gerechnet.

 

[Matthiasab64]

Achso, sorry hab ich wohl falsch interpretiert.

Hab mir den Pegelschifter angeschaut P82B96.
Ja der würde auch gehen und bräuchte wahrschenlich keine externe Beschaltung und kostet ca. 1,20€.
Den Lm358 hab ich hier zig Stück und selbst wenn nicht der kostet 0,10€ und gut er Braucht noch 4 Widerstände.
Beim Lm hab ich 2 Oamp´s im gehäuse und kann vor jedem Tiny einen setzen und hab noch ne schöne Trennung Optisch und auch Elektrisch.
Beim P82B96 wäre dann bei seinem Preis entweder immer ein Baustein verschenkt oder ich muss zwei kanäle an diesem Baustein zusammen führen und hätte wahrscheinlich mehr Probleme beim Routen der Leiterbahnen.

Aber wie bei Casio im Artikel erwähnt für sehr lange Übertragungswege nicht zu topen.

Gruss Matthias

 

[dino03]

Hab mir den Pegelschifter angeschaut P82B96.
...
Beim P82B96 wäre dann bei seinem Preis entweder immer ein Baustein verschenkt oder ich muss zwei kanäle an diesem Baustein zusammen führen und hätte wahrscheinlich mehr Probleme beim Routen der Leiterbahnen.
Aber wie bei Casio im Artikel erwähnt für sehr lange Übertragungswege nicht zu topen.

wofür willst du den denn einsetzen ?
Du weißt das I2C immer 2 Leitungen benötigt ? SCL + SDA.
Damit brauchst du auch die zwei Kanäle des P82B96. Da bleibt nichts übrig.

 

[Matthiasab64]

hmmm ... ja stimmt

den hatte Lotadac vorhin erwähnt.

Bin gerade am lesen was besser geeignet ist TWI oder SPI.

 

[dino03]

Bin gerade am lesen was besser geeignet ist TWI oder SPI.

Bei SPI benötigst du zusätzlich zu MOSI/MISO/SCK noch für jeden Slave ein Enable-Signal wenn du mehr als einen Slave verwenden willst. Das wären dann also 4 IO-Pins pro Slave (bei mehr als einem Slave). Also ...
- 3 IO-Pins pro Slave bei einem Slave
- 4 IO-Pins pro Slave bei mehr als einem Slave
- 3 IO-Pins am Master bei einem Slave
- 3 IO-Pins und für jeden Slave einen weiteren Pin (Enable) für mehr als einem Slave.
macht dann 2 Slaves = 5 Pins am Master, 3 Slaves = 6 Pins am Master, ...

Bei TWI wird das alles über die Adressen auf dem Bus gemacht. Du brauchst also immer nur SDA und SCL (2 IO-Pins).

 

[Matthiasab64]

Hab mich für SPI endschieden, weil für mich leichter Realisierbar, und da ich die MOSI nicht benötige sind es von jedem Tiny nur 3 Pin´s und am Mega dan halt 6 Pin´s

Frage mich grad ob es nicht auch möglich ist die SPI zu misbrauchen bzw eine TWI ohne adresse zum auslesen der Messschieber zu verwenden.

Mein Gedanke betrifft jetzt nur die Komunication zwisch MS und Tiny (ich nehm jetzt mal die Timings der Standart MS auch wenn meine anders sein werden)
- Clock überwachen, wenn länger auf High wissen wir ja das mit dem nächsten wechsel auf Low Daten kommen,
- also nach ca.53 µs High Interupt auslösen und die Daten im Takt in eine Variable schieben - entweder eine vorgegebene anzahl von Takten oder bis Clock wieder länger auf High ist


würde das gehen oder gibst da ein Befehl unter Bascom

gruss Matthias

 

[Matthiasab64]

da warst jetzt schneller

aber irgendwie ist mir der TWI noch nicht geheuer, hab mir die Beispiele unter Bascom angeschaut.
Und? Ich weiss jetzt weniger wie vorher. Alles zusammengeschmissen und man hat keinen Überblick mehr was da überhabt passiert.

Ich hatte gestern mal im Netz geschaut ob man mal in den compilierten Code von Bascom schauen kann, also mich hätte da Speziel mal die ASM variante von Shiftin interessiert.

gruss Matthias

 

[Matthiasab64]

Hallo,


So jetzt nochmal ein kurzer Zwischenbericht.

Ich habe festgestellt das ich mit Shiftin die Daten von nur einem MS inkl. Berechenen , genauso schnell auf dem Display habe wie der MS auf seinem eigenen also werden die 3 Tinys mit Shift in lesen den Wert berechnen und in einer Variable zum senden an den Mega bereit halten. Der dann nacheinander alle 3 Variablen anfordert und das sollte dann auch schnell genug sein.

Wenn ich jetzt noch die Tiny´s mit einen externen Takt versorge also sie im Gleichtakt arbeiten kann ich alle Tinys an den selben Clock und Data eingang des Megas hängen und in den Tiny´s ein zeitfenster zum senden der Daten geben ohne das sie sich beeienflussen oder adressen vergeben werden müssen, denk ich mir jedenfals


gruss Matthias

 

[dino03]

Wenn ich jetzt noch die Tiny´s mit einen externen Takt versorge also sie im Gleichtakt arbeiten kann ich alle Tinys an den selben Clock und Data eingang des Megas hängen und in den Tiny´s ein zeitfenster zum senden der Daten geben ohne das sie sich beeienflussen oder adressen vergeben werden müssen, denk ich mir jedenfals

Nett gedacht aber zu kurz gedacht
Ein Zentraltakt stellt lediglich sicher das alle mit gleichem Takt und Phasenlage bei der Übertragung arbeiten. Nicht mehr und nicht weniger.

Wenn die jetzt alle ein paar Milli oder Microsekunden nacheinander aus der Reset-Phase kommen und starten dann hast du trotzdem zeitlich nicht synchronisierte Slaves. Die haben zwar alle den selben Takt aber kommen unterschiedlich schnell zur Übertragungsroutine und damit kloppt es dir die Bits auf deinem einen Datenpin durcheinander wenn sich die Übertragung von zwei Slaves überschneidet (zB. Ende von einem und Anfang vom nächsten).

Du bekommst sie nur wirklich synchron wenn du zusätzlich sowas wie Synchronpulse vom Master sendest auf die sich alle zeitlich einstellen (zB der erste sofort, der zweite 10ms nach dem Puls, der dritte 20ms nach dem Puls, ...) oder sie vom Master einzeln anschubst das sie senden sollen.

Alternativ machst du die Datenleitung bidirektional. Du hälst sie also zB beim Starten vom Master auf Low. Wenn die Slaves eine längere Zeit Low erkennen und selber nicht ändern können dann stoppen sie die Übertragung und warten. Wenn du die Leitung vom Master dann auf High ziehst dann erkennen das alle Slaves und synchronisieren sich damit auf dieses Startsignal. Dafür müßtest du aber die Datenleitung wie zB beim 1Wire-Bus mit OpenCollector und PullUp-Widerständen aufbauen. Das ist aber schlecht für die Störeinstrahlung.

Gruß
Dino

 

[Matthiasab64]

hi,


daran hab ich wirklich nicht gedacht, aber dafür bin ich ja hier gelmeldet, danke für eure gedult

Und wenn ichs mir recht überlege hab ich auch genug leitungen am Mega8 um die SPI mit 6 Leitungen zu realisieren.
Am Display kann ich auch noch eine Leitung weglassen da ich die Schriftgrösse nicht ändern werde.

gruss Matthias

 

[LotadaC]

Ohje...

...
- Clock überwachen, wenn länger auf High wissen wir ja das mit dem nächsten wechsel auf Low Daten kommen,
- also nach ca.53 µs High Interupt auslösen und die Daten im Takt in eine Variable schieben - entweder eine vorgegebene Anzahl von Takten oder bis Clock wieder länger auf High ist
...

machs nicht so kompliziert...
Ich beziehe mich jetzt auch auf die verlinkten Oszibilder.
Wenn ich mich recht erinner, ist die Clock erstmal (ewig) low. Die beiden Datenpakete beginnen und enden mit einem je ca 53µs langen high-Pegel der Clock. Die Clock-Impulse selbst waren 13µs. Ein AVR schafft bei 16MHz knapp 850 (53µs) bzw 210 (13µs) Takte. Jetzt nimm mal 4 Takte pro Instruktion an (zur Sicherheit), und nur das halbe Zeitfenster, da die Clock ja dann wieder hochgeht (und kurz danach das nächste bit bei data erscheint: Dann hast Du nach jeder fallenden Flanke also ca 25 Instruktionen Zeit, um den data pin zu lesen, und 25 weitere um die Schieberei zu vollenden. Das reicht doch locker (und ist bereits deutlich zu unseren Ungunsten geschätzt - hast also mehr Zeit). In den 53 µs und erst recht in den langen Pausen (die Kommunikation dauert kürzer als eine ms, die Messungen kommen aber nur mit ca 3 bzw max 50 Hz - kannst ja selber mal rechnen), kann man dann auf eventuelle Anfragen des Masters reagieren.
Also:
Die Clock kommt an einen interruptfähigen Pin, dieser ist auf steigende Flanke scharf gemacht (ok, bei 850 Takten reicht vielleicht auch pollen - vereinfacht die ISR etwas).
wenn die Flanke high geht, wird der Interrupt auf fallende Flanke scharf gemacht, und die Register, die den Datenfluß aufnehmen sollen, sowie ein Zähler für die bereits empfangenen Bits vorbereitet. Vielleicht sollte man jetzt auch andere IRQs abschalten (Comm vom Master).
In der ISR (Clock fallende Flanke) schiebst Du den Pegel des data-Pins quasi "von links" in das höchstwertigste Speicherregister. Dabei wandert das LSB ins Carry, also schiebst Du jetzt nicht, sondern Du rotierst (durchs carry), und zwar auch nach rechts ins 2te Speicherregister. Und das ganze nochmal mit dem dritten(*). Jetzt noch den Zähler weitergesetzt, und überprüft, ob das schon alles war -> dann den Clock IRQ deaktivieren, und den Status fürs Hauptprogramm ablegen. (Vorher und nachher müssen wahrscheinlich einige Rechenregister und das SREG gesichert/wiederhergestellt werden, klar)
(*) elegant könnte das in ASM so aussehen:

CLC                     ;Clear Carry Flag - Carry erstmal auf 0 - 1 Takt
SBIC  Dataport, Datapin ;Skip if Bit is cleared - wenn der Pin 0 ist, wird der nächste Befehl Übersprungen - 1 Takt (**)
SEC                     ;Set Carry Flag - Carry auf 1, Zustand des Datapin also im Carry  - 1 Takt
ROR   highregister      ;Carry von links ins erste Speicherregister, LSB ins Carry - 1 Takt
ROR   middleregister    ;dito zweites - 1 Takt
ROR   lowregister       ;und das dritte - 1 Takt

Weiter gehts dann wie oben beschrieben. Zähler setzen und checken, ggf Status für HP ablegen, Clock-IRQ aus, andere IRQs an, ggf Register wiederherstellen, Rückkehr aus der ISR.
(**):
Wenn SBIC nicht springt (Bit war eins), 1 Takt. Dann wird SEC ausgeführt, 1 weiterer Takt - zusammen also 2 Takte
Wenn SBIC springt, und der übersprungene Befehl ein Wort groß ist (wie SEC zB), 2 Takte - da SEC übersprungen wird bleibts dabei.
Dieser gesamte Teil braucht also 6 Takte.
Ich würde versuchen das allses direkt in den Rechenregistern ablaufen zu lassen (könnte eigentlich klappen, oder hat der Tiny nur 16 Stück - dann könnte es eng werden), ansonsten mußt Du vorher die 3 Speicherregister und den zähler aus dem SRAM laden - und hinterher wieder speichern.
Hinter Dataport und Datapin verbergen sich natürlich die echten I/O-Register und Bitnamen des Prozessorbeinchens, oder eben irgendein sinnig vergebener Name (-> ".equ")

Edit: Den bidirektionalen Levelshifter hatte ich eingeworfen, da man über die Leitungen des MS andere Modi erzwingen kann. Der geplante Komperator ist da 'ne Einbahnstraße.
Eigentlich könnte man die Prozessoren ja auch auf 1,5V (?) arbeiten lassen (Achtung! max Taktfrequenzen beachten), aber dann müßte auch das Display mit dieser arbeiten (oder Du verschiebst das Pegelproblem nur an eine andere Schnittstelle:
(MS<-->Tiny<-->Mega<-->Display))

 

[Matthiasab64]

Hallo,

Edit: Den bidirektionalen Levelshifter hatte ich eingeworfen, da man über die Leitungen des MS andere Modi erzwingen kann. Der geplante Komperator ist da 'ne Einbahnstraße.
Eigentlich könnte man die Prozessoren ja auch auf 1,5V (?) arbeiten lassen (Achtung! max Taktfrequenzen beachten), aber dann müßte auch das Display mit dieser arbeiten (oder Du verschiebst das Pegelproblem nur an eine andere Schnittstelle:
(MS<-->Tiny<-->Mega<-->Display))

Ja das kann sein, aber da mein MS diese möglichkeit nicht hat, brauch ich mir da keine Gedanken drüber machen.
Soweit ich gelesen hab ist es von MS zu MS auch verschieden wie diese Modi eingestellt werden, es gibt welche da wird Data bzw Clock kurz auf Vcc gelegt es gibt welche die werden auf Masse gelegt (in den meisten MS haben die Metallteile also der ganze Schieber + Potential der Batterie) und es gibt MS da wird die Clock und Data Leitung für ca. 60 ms zusammengeführt um den Modus "Fast" einzustellen. Gibt sicher noch mehr Varianten, die ich aber nicht kenne)

So und jetzt glaub ich Reden wir wieder vom selben, nur das ich es nicht so schön wiedergeben konnte wie du. Die Takte die ich zwischen den Impulsen noch zeit habe zum Rotieren usw , das meinte ich die ganze Zeit das ich zwischen den bytes bei einem mit 8MHz getaktetem Tiny genug zeit sein müsste alles zu erlediegen ohne das etwas verloren geht.


Da werd ich jetzt auch erstmal ansetzen um hier auch mal wieder was sinnvolles schreiben zu können.

@Lotadac
Bist du jetzt auch schon am bauen oder willst du es irgendwann mal machen?

Ich bin bemüht das ganze auch in ASM zu realisieren aber vorerst mache ich erstmal alles in Bascom. (bin noch fleizig am lernen, ich glaub irgendwann werd ich mich mit der Hardware dierekt unterhalten ohne Compeiler in Hex )

Wie kann ich herausfinden wie lange ein Basicbefehl braucht bzw wieviel Takte?

gruss Matthias

 

[Matthiasab64]

Hallo,


ich habe mir das was Lotadac oben beschrieben hat mal sorgfältig durch den kopf gehen lassen, und habe da noch ein paar Fragen dazu.

Ich bin immer noch fleißig am Assambler lernen bevor ich jetzt was neues Versuche.

Wenn ich wie oben beschrieben so viel Zeit hab, die rede war von ca. 25 Instrucktionen zwischen jedem gesendetem Bit, sollte ich ja auch rein Theoretisch mit einem AVR(Mega 16 oder so) in reinem Assembler auskommen oder?
Werde aber sicher trotzdem die Variante mit mehreren AVR´s nehmen um Bascom und Assambler zu trennen.

Dann würde es mir sehr helfen wenn es ein Programm bzw Editor gibt der mir Bascom befehle mal in Assambler aufschlüsselt, zum einen um zu sehen wie ein Bascom-Befehl in Assambler aussieht und zum anderen würde es mir in beide Richtungen helfen, denn es gibt sachen die verstehe ich nur in Bascom und sachen die ich mir nur unter Assambler erklären kann. Was ich schon Versucht habe ist eine hex in AVR-Studio zu laden und als Assambler anzuzeigen, aber das ergebniss war ein so unübersichtlicher code das geht gar nicht oder ist der Bascom Compiler so "schlampig"

Gruss Matthias