Bascom Auslesen eines Messschiebers Bascom Glcd

[Matthiasab64]

Hi Lotadac,


Also mit den Sockeln das find ich auch bescheiden, hab immer angst mir Haarrisse zuzuziehen wenn ich an dem Board hebel um den 16.er runterzuholen.

Für mein neues werd ich mir die Nullkraftsockel besorgen.

Usb on Board, ja das hab ich mich auch öfters gefragt warum man nicht wenigstens einen Standart setzt (Soft und Hardware), und eigenlich sollte es ja in der heutigen zeit möglich sein über USB, alle Schnittstellen anzusprechen ohne auf flexibelität verzichten zu müssen.
Ein konverter für alles RS232, ISP, JTAG ........

Schön erklärt das kam auch bei mir an mit den Adressen , Danke

gruss Matthias

 

[dino03]

Hallo,

also meiner Meinung nach wird das beim Einlesen der Daten vom MS nix mit shiftin. Der Befehl ist auf die Datenübertragung von 8Bit auf einer Leitung ausgelegt und nicht dafür das man irgendein 24Bit-Messschieber-Protokoll einlesen kann. Da wird man nicht um den Nachbau durch Software drum herum kommen. Aber wie gesagt. Das ist meine Meinung und ich laß mich gerne von was anderem überzeugen.

Gruß
Dino

 

[Matthiasab64]

Hi Dino,

ich glaub dir das schon, du bist schliesslich einer der Experten. Aber wie schon im allerersten beitrag geht es, siehe Foto´s.

Und laut Bascom Hilfe kann man angeben das bis zu 255 Bit´s gelesen werden können. Immer Byte für Byte.

Hab gerade bemerkt das man da noch Delay in µs angeben kann, mal schauen was das soll

gruss Matthias

 

[LotadaC]

...shiftin. Der Befehl ist auf die Datenübertragung von 8Bit auf einer Leitung ausgelegt und nicht dafür das man irgendein 24Bit-Messschieber-Protokoll einlesen kann...

naja, laut Online-Hilfe spielt die Anzahl der Bits nicht wirklich eine Rolle (aus Effizienzgründen, ok...).
Das wesentliche hier ist die "eine Leitung"- wenn die 3 MS potentiell gleichzeitig senden, und das mit einer Telegrammfrequenz (?) von ca 3Hz, ist nacheinander auslesen (selektiv) meiner Meinung nach keine Option mehr. Dann sollte man das simultan Auslesen lassen.
Eine Möglichkeit wäre noch, alle 3 clocks an verschiedene Pins eines gemeinsamen PinChangeInterrupts zu hängen, und in der ISR dann auf Veränderungen der 3 zu reagieren, und die Dataleitungen auszulesen - allerdings wird das mit dem schieben im Zeitfenster eng - erst recht unter Bascom.

Ob shiftin irgendwie auf die Präambel der clock synchronisiert, weiß ich nicht. Wenn nicht, ist es äusserst wahrscheinlich, daß früher oder später das einschieben woanders als am Anfang eines Telegrammes beginnt.
Nach dem Fehler alle 3-5s stimmt es dann aber wieder? Auch mit dem fixen Text bei der Drehzahl?

Was hast Du gegen die Lösung mit mehreren Controllern?

 

[Matthiasab64]

Hallo,

eigentlich hab ich rein gar nix gegen die lösung mit 3 Controllern, hab mich halt nur gewundert das es jetzt nicht mehr nur langsamer ist sondern auch störungen auftreten.

Ich habe jetzt mal vor der berechnung von der variablen "M" diese nochmal als Binausgegeben um zu sehen was da geschieht.
Habe die MS auf Werte eingestellt die sich nicht allzusehr unterscheiden also als Bsp. :

Muss an dieser stelle noch hinzufügen das ich hier die ganze Zeit eine Falsche vermutung hatte, und zwar das bit 1 zwischen mm und inch wechselt, momentan steht Bit 1 immer auf High(unabhängig von dem was ich eingestellt hab) ausgenommen ich werte nur die "2ten" 24 Bit aus da trifft das mit den Einheiten und Bit1 wieder zu - aber das ist auch egal es wird weggeschnitten weil es für meinen Zahlenwert nicht von bedeutung ist.

MS1 = 0,08mm = 1000 Anzeige =10001
MS2 = 0,09mm = 1001 Anzeige =10011

da ich beide werte in der do loop immer wieder übereinanderlege also an der selben stelle im Display
kann man die veränderungen sehen, die wiederholrate scheint recht hoch

zu anfang erkenne ich hauptsächlich 10011 auf dem Display dann sieht man langsam 10001 bis dann nur noch 10001 da steht und
dann schiesst dieser wert von rechts nach links durch die longvar und sorgt dann für die falschen anzeigewerte und dann gehts wieder von vorn los

mir kommt das ganze wie ne PWM vor die von low auf high geändert wird, Anzeigetechnisch betrachtet

erst überwiegt der teil von MS2 also Pulsdauer gegenüber MS1 hoch und dann mit jedem do loop durchlauf ändert sich das und für MS1 werden pulszeiten länger und für MS2 kürzer.
Dann scheint als wenn irgendwas "Überschwappt" und MS2 ist wieder vor wiegend zu sehen. Und das spiel läuft innerhalb der erwähnten 3-5sec.


ich werde später die 3 Controller verwenden, aber bis die da sind wollt ich noch experimentieren, immerhin machen andere es auch mit einem AVR

Gruss Matthias

 

[LotadaC]

...immerhin machen andere es auch mit einem AVR...

... aber sicherlich nicht mit shiftin. Wahrscheinlich nicht mal In Bascom.
Ok, der Mega16 hat 3 externe INTs. Damit sollte es auch gehen. Was wir bisher vergessen hatten, ist die HW-SPI. damit kannste einen MS weitgehend auslagern. Zumindest beim Mega88 könnte man zwar den UART auch als SPI arbeiten lassen, aber leider nur als Master. beim Mega16 scheint es das noch nicht gegeben zu haben - also egal. Bleiben 2 MS in SW.
In Beitrag 38 hatte ich schon mal einen möglichen Ansatz (in ASM) vorgeschlagen. Im Prinzip kannst Du das mit eingebettetem ASM mal mit 2 MS versuchen. Die ISRs mit nosafe. SREG und nur die verwendeten Rechenregister pushen und poppen. Da Du auf die gespeicherten 24bit-vars (und die Statusvariable) in Bascom zugreifen können willst, müssen sie dort auch definiert gewesen sein. Im SRAM. Meiner Meinung nach sollte man problemlos darauf zugreifen können, wenn man sie von Bascom in einem festgelegten SRAM-Register ablegen läßt. Wenn ich mich recht erinner mit

DIM Name AS Typ AT Adresse

.

 

[LotadaC]

Hallo nochmal,

ich habe mal aus Deinem letzten Code folgendes übernommen:

$regfile = "m16def.dat"
$crystal = 8000000
$hwstack = 40
$swstack = 16
$framesize = 32

Dim M As Long
Ddrc = 0 
Portc = &HFF

Do
   Pinc.0 , Pinc.1 , M , 6 , 24   'Auslesen 24 bit 
Loop
End

und das daraus von Bascom erzeugte Hexfile mal durchs AVRstudio gejagt.
Darf ich das Assemblerlisting hier zeigen? (und erklären?)
Kurz gesagt wartet shiftin auf die entsprechenden Flanken am Clock-Pin (*). Ausgewertet wird dann die entsprechende Anzahl von Bits. Es erfolgt keine weitere Synchronisation - wenn man also irgendwann mal was verschluckt hat, wird solange gewartet, bis wieder Clocks kommen. Also vom nächsten Telegramm (Dein "durchschiessen"). Aufgrund der langen Pausen zwischen den Telegrammen steigt irgendwann die Wahrscheinlichkeit, daß nach einem verstümmelten Fragment auf dem einen Kanal 'ne Pause auf dem anderen folgt - und folglich shiftin auf ein korrektes Telegramm wartet. Bis es wieder aus dem Ruder läuft.

Interessant am Rande:
-shiftin setzt selbst (nochmal) die Clock/Datenpins auf Eingang (DDRC1..0=0) - mit CBI. Aber da Du ja die Pullups aktivieren willst, mußt Du das trotzdem vorher schon machen - sonst wären die Pins ja solange direkt auf Vcc
-nach dem "loop" (Hauptschleife) hast Du ein unnötiges "end". (end deaktiviert global die Interrupts, und erzeugt eine leere Endlosschleife (Sprung auf sich selbst (RJMP 0)) -> das Programm kann diesen Teil aber nie erreichen, da das loop ja immer eine Sprung nach do auslöst (JMP Adresse(loop)))
-shiftin erzeugt sowas wie einen Countdown mit dem Z-Doppelregister (decrementiere Z bis es gleich null ist, dann Return) - wird hier aber nicht benutzt. Wahrscheinlich tritt das mit dem optionalen delay-Parameter in Aktion
-außerdem je eine Routine zum setzen bzw löschen von Bit 2 in R6. Über das T-Flag aus SREG. (SET/CLT und dann BLD R6, 2) Danach Return.

(*) genau genommen wird nicht auf die Flanke, sondern auf den jeweiligen Pinzustand (Clock) gewartet. Erst auf Clockpin=1, nach dem verarbeiten des Datenpins (auch mittels Carry und SBIC, ähnlich wie bei mir) dann auf Clockpin=0.

 

[Matthiasab64]

Hallo Lotadac,


Danke für deine mühe.
Ist das also der Assambler den Bascom daraus macht wenn man sich die Hex unter Studio anschaut?

Das mit den Port setzen hab ich auch schon vermutet da in vielen Codes die ich mir mit Shiftin angeschaut hatte das ddr und port setzen weggelassen wurden.

Das andere werde ich mir heut nach der Spätschicht mal in ruhe anschauen Parallel zum Hex in AVRst.
Warum soll das Assamblerlisting hier nicht gezeigt werden dürfen?

Das mit dem "END" am ende einer DO LOOP ist das erste was man mit auf dem Weg bekommt als anfänger, aber ich vermute mal es gehört ganz an das Ende des Codes , richtig?

Gruss
Matthias

 

[svenhummel]

Hallo ;
@Mattias:
erstmal sorry das ich hier so reinplatze ....

Also mit dem Auslesen von Digitalmessschiebern habe ich mich schon viel beschäftigt und muss gleich einige Feststellungen loswerden !
Mit Bascom und Shiftin ist das absolut kein Problem !!! Ich habe mal zu Testzwecken 5 Messschieber an einem ATMega88 angeschloßen und
an einem 4x20 Lcd die Werte ausgegeben , Auch in Fastread Mode mit 50 samples/sec hat das ganze einwandfrei funktioniert .
Der Mega88 lief allerdings übertaktet mit 22,184MHz , was aber bei 3 DMS nicht nötig ist , die laufen bei mir an der Fräse mit 18,432MHz und
einem Terminal Programm über die serielle Schnittstelle ohne Probleme , allerdings zucken die 100tel werte im fastread Mode etwas.
Zu deinem Problem mit dem periodisch falschen Messwerten :
Ich denke das dein µC einfach noch nicht fertig ist mit umrechnen .
versuch mal deine rechnerei zu separieren und erst nach erfolgreicher umrechnung ein neues shiftin auszuführen .

Du hast auch geschrieben, das du dir mit dem 2x24 bit protokoll nicht sicher bist .

Ich hatte jetzt mal einen DMS da gehabt , der hatte ein "neues" 6x4bit protokoll , da war die Datenausgabe wie von dir beschrieben direkt binär
und mußte nicht groß umgerechnet werden wobei die Ausgabegeschwindigkeit nicht veränderbar war , sie lag bei 7 Datenpaketen/secunde.
Fastread war nicht möglich und dieser DMS hat sich nach ca 2min abgeschalten und die Datenübertragung wurde unterbrochen .

Ich bin im Augenblick aber auch wieder etwas eingerostet was das Thema DMS auslesen anbelangt...

Hast du die Möglichkeit das Protokoll auf einen Oszi darzustellen ?
Grundvoraussetzung ist aber erstmal zu wissen um welches Protokoll es sich handelt bzw wie es "aussieht"

sorry wenn ich fragen stelle die schonmal gestellt worden sind , aber ich habe mir ehrlich gesagt jetzt nicht jede seite dieses Treads durchgelesen
und ich bin gerade hier drübergestolpert .
Im Netz findet man aber eigentlich recht viel zum Thema DMS auslesen !?
http://www.svens-projekte.de/3.html

LG

Sven

 

[svenhummel]

Nachtrag :

@Matthiasab64:

In Deinem letzten vollständig geposteten Programm (seite 6) sind meiner Meinung nach einige Fehler:
Wenn ich das richtig gesehen habe möchtest du ja mindestens 2 DMS auslesen ? oder ?
Die Shiftin Variable M kannst du nur für einen DMS verwenden da sie ja beim Shiftin des 2. DMS Überschrieben wird .
Besser du nutzt für jeden DMS eine eigene Long Variable , also z.B M_x , M_y , M_z , - welche dann zu einer RechenVariable
z.B. Wert_x = M_x übergeben und dann kann mit Wert_x gerechnet werden , damit ist M_x wieder frei für den nächten wert.

Zum anderen ist das permanente abfragen der Ports (If Pina.1 = 0 Then) ungünstig das verlangsammt das Programm enorm.
Besser wäre evtl eine Interrupt Routine zb über Int0 , Int1 , welche das Clocksignal erkennt und dann das shiftin ausführt.
Vorteil: du brauchst den Portpin nicht immer abzufragen ob ein DMS angeschloßen ist oder nicht - kein Clocksignal heißt kein Interrupt
und demzufolge auch kein angeschlossener DMS und deinem Prog bleibt mehr zeit zum rechnen ...

So , ich hoffe ich konnte dir noch einen Gedankenanstoß geben.

Grüße

Sven

 

[svenhummel]

2. Nachtrag

@Matthias:
zur datenübertragung TWI / SPI :
Damit habe ich persönlich sehr schlechte erfahrungen gemacht , sobald du von deinem "experimentierplatz"
zu deiner Fräse kommst und diverse elektrische (stör)felder einwirken wirst du Wahrscheinlich dein blaues Wunder erleben ....
Ich persönlich verwende bei Zeitkritischen und Störungsemfindlichen Datenübertragungen die RS485 ( auch Profibus genannt ) Schnittstelle ,
Vorteil: sie ist unter Bascom sehr einfach und auch extrem schnell ( Interuptgesteuert) realisierbar , auch mehrere Master /slave sind
möglich . RS485 ist extrem Störunanfällig gegen einsteuungen zb von FU 's und Schweißanlagen , selbst mit relativ schwach geschirmten kabeln sind kabellängen
von über 10m und 115200 Baud ohne Probleme möglich ( Umsonnst wird dieses Bussystem nicht in Industrieanlagen eingesetzt ! )
Da hält kein TWI (I²C) oder SPI mit .

so , genug für heute

grüße
Sven

Sven

 

[LotadaC]

Das verstehe ich jetzt nicht...
Du zapfst einen SPI-ähnlichen bestehenden Kommunikationskanal an (Wofür ist der eigentlich wirklich gedacht? Für den Datentransfer von der eigentlichen Mess-Hardware zum Display im MS?) - legst da also quasi lange Antennen dran, läßt diese von einem AVR mitloggen, und machst Dir im lezten Beitrag Sorgen wegen der Störanfälligkeit des SPI?
Der elektrische Anschluß ist ja derselbe - ob ich den seriellen Datenstrom jetzt zu Fuß auswerte (pollen), Bascom das machen lasse (shiftin), oder die Aufgabe an die Prozessorhardware übergebe (HW-SPI) ist insofern egal. Aber beim erzeugten Code und der "Prozessorauslastung" kommts zu erheblichen Unterschieden.

1.: Abgesehen von Interrupts blockiert shiftin solange den Prozessor, bis die 24bit komplett eingeschoben sind.
2.: Wenn ich Matthias richtig in Erinnerung habe, hat er sich auf den "normalen" Mode mit 3Hz festgelegt.
3.: shiftin schiebt einfach nur die entsprechende Anzahl an Bits in eine Variable (mittels der beiden Leitungen) - es erfolgt keine weitere irgendwie geartete Synchronisation ("Startbedingung") und auch kein timeout (oder greift hier die delay Option?)
4.: Im worst case ist davon auszugehen, daß die 3 MS quasi gleichzeitig senden können -> mit 1. und 2. folgt also eine erreichbare Aktualisierungsfrequenz von einem Hertz
5.: Andererseits ist auch davon auszugehen, daß die 3 MS nicht synchron senden (müssen) - es könnte also durchaus vorkommen, daß der betreffende MS bereits gerade dann schon mitten im senden ist, wenn das Programm den µC mit shiftin dort horchen läßt. Wegen 3. liefert shiftin aber irgendwann trotzdem irgendein Ergebnis (solange der MS noch sendet) - nur eben halt irgendwelchen Müll.
Folglich muß also irgendwie synchronisiert werden - oder fehlt mir hier irgend'ne wichtige Info?

 

[dino03]

Hi,

3.: shiftin schiebt einfach nur die entsprechende Anzahl an Bits in eine Variable (mittels der beiden Leitungen) - es erfolgt keine weitere irgendwie geartete Synchronisation ("Startbedingung") und auch kein timeout (oder greift hier die delay Option?)
4.: Im worst case ist davon auszugehen, daß die 3 MS quasi gleichzeitig senden können -> mit 1. und 2. folgt also eine erreichbare Aktualisierungsfrequenz von einem Hertz
5.: Andererseits ist auch davon auszugehen, daß die 3 MS nicht synchron senden (müssen) - es könnte also durchaus vorkommen, daß der betreffende MS bereits gerade dann schon mitten im senden ist, wenn das Programm den µC mit shiftin dort horchen läßt. Wegen 3. liefert shiftin aber irgendwann trotzdem irgendein Ergebnis (solange der MS noch sendet) - nur eben halt irgendwelchen Müll.
Folglich muß also irgendwie synchronisiert werden - oder fehlt mir hier irgend'ne wichtige Info?

genau darum hab ich damals gesagt das man es eigentlich nicht mit dem SPI oder ShiftIn machen kann weil man nur auf die Flanken des Taktes triggert. Wenn man also mitten im ersten Datagramm anfängt dann nimmt der Atmel die Pause zwischen den Datagrammen auch als ein Datenbit und ist dann mitten im zweiten Datagramm fertig. Er wird also nicht wirklich synchron sein. Aber wer weiß evtl irre ich mich ja auch. Ich finde die Lösung allerdings nicht wirklich stabil. Es gibt zu viele Unwägbarkeiten die nicht wirklich in der Software abgefangen werden.

Gruß
Dino

 

[svenhummel]

hallo ,

@LotadaC

Das verstehe ich jetzt nicht...
Du zapfst einen SPI-ähnlichen bestehenden Kommunikationskanal an (Wofür ist der eigentlich wirklich gedacht? Für den Datentransfer von der eigentlichen Mess-Hardware zum Display im MS?) - legst da also quasi lange Antennen dran, läßt diese von einem AVR mitloggen, und machst Dir im lezten Beitrag Sorgen wegen der Störanfälligkeit des SPI?

JA, genau , du gibst dir ja hier selbst die Antwort ....
eben weil dieses "Datentelegramm" der MS sehr "intabil" ist muß die Messhardware so nah wie möglich an die MS ran kommen und auf die Kabel sollte auch besonders geachtet werden und evtl auch noch mit einen extra EMV geflechtschlauch überzogen werden ( natürlich nur wenn starke Störquellen vorhanden sind )
Und die Schnittstelle am MS ist natürlich dazu da um die Daten extern weiter zu verarbeiten .
(übrigens sind Antennen ungeschirmt ... die Kabel vom MS zu Messhardware sollten , wie schon erwähnt , gut geschirmt sein )

keiner Spaß am Rand - mir ist schon klar wie du das meinst ... und wenn ein paar kräftige FU in der nähe sind ist das Wort (stör)Antenne genau richtig ....

Die Datenübertragung von der Messhardware zur Anzeige könnte dann eben per rs232 oder 485 erfolgen , SPI würde sicher auch gehen aber TWI (I²C) kannst du da knicken ...
(wenn des um längere wege geht von Messhardware zur Anzeige ( >0,5m))

Der elektrische Anschluß ist ja derselbe - ob ich den seriellen Datenstrom jetzt zu Fuß auswerte (pollen), Bascom das machen lasse (shiftin), oder die Aufgabe an die Prozessorhardware übergebe (HW-SPI) ist insofern egal. Aber beim erzeugten Code und der "Prozessorauslastung" kommts zu erheblichen Unterschieden.

ja , da hast Du recht , der Anschluß der MS ist immer der selbe , nur das du die 2x24 bit nicht mit Hardware SPI auslesen kannst , Hardware SPI ist meines wissens ( lass mich aber gerne berichtigen ) nur für bis zu 16 bit möglich !?
pollen ist eigentlich quatsch , da du deinen µC nur unnötig beschäftigst . allerdings gibt es bei der Methode auch Vorteile , du fragst shiftin-x ab - rechnest und überträgst , danach shiftin-y und shiftin-z , dann gibt es auch keine überschneidungen zwischen shiftin und datenoutput .

1.: Abgesehen von Interrupts blockiert shiftin solange den Prozessor, bis die 24bit komplett eingeschoben sind.

das soll ja auch so sein , du erwartest ja auch 24 bit , das bleibt ja immer gleich ....
Im "Notfall" kannst du ja noch einen Timer starten der ca 120us läuft und dann einen "shiftinreset" ausführt

2.: Wenn ich Matthias richtig in Erinnerung habe, hat er sich auf den "normalen" Mode mit 3Hz festgelegt.
3.: shiftin schiebt einfach nur die entsprechende Anzahl an Bits in eine Variable (mittels der beiden Leitungen) - es erfolgt keine weitere irgendwie geartete Synchronisation ("Startbedingung") und auch kein timeout (oder greift hier die delay Option?)

zu 2 :
das habe ich auch so rausgelesen , der Modus mit 3 Übertragungen /sec.
zu 3 :
das ist die aufgabe von Shiftin , was möchtest du denn noch ?
Das Messprotokoll ist nunmal so , da gibt es nunmal kein "Startbyte" oder "Stopbyte"
Du mußt hier immer auf die Flanke des ersten Clock reagieren , anders geht's nunmal nicht bei diesem Datentelegramm .

4.: Im worst case ist davon auszugehen, daß die 3 MS quasi gleichzeitig senden können -> mit 1. und 2. folgt also eine erreichbare Aktualisierungsfrequenz von einem Hertz
5.: Andererseits ist auch davon auszugehen, daß die 3 MS nicht synchron senden (müssen) - es könnte also durchaus vorkommen, daß der betreffende MS bereits gerade dann schon mitten im senden ist, wenn das Programm den µC mit shiftin dort horchen läßt. Wegen 3. liefert shiftin aber irgendwann trotzdem irgendein Ergebnis (solange der MS noch sendet) - nur eben halt irgendwelchen Müll.
Folglich muß also irgendwie synchronisiert werden - oder fehlt mir hier irgend'ne wichtige Info?

zu 4 :
Ja ,und ?
selbst wenn sie exakt zeitgleich senden würden könntest du niemals alle werte exakt zeitgleich auswerten und auf einem Display anzeigen ...
einer ist der erste und einer der letzte , auch wenn du 3 µC's bemühst zum einlesen , spätestens am "Anzeigecontroller (Master ???) müßen sie sich
in reihe anstellen um ihre daten loszuwerden .. oder sehe ich das falsch ?

zu 5:
hier muß ich dir auch recht geben , das datensenden und einlesen darf sich nicht überschneiden , das führt unweigerlich zu Problemen !!!
Aber bei einer Frequenz von 3 Hz je MS ( 9Hz für 3MS) wird sich wohl etwas zeit finden um daten zu übertragen .
zB.: nach den Systemstart die Pausen messen und danach den sendemodus einstellen.
oder shiftin immer auf 24 bit/zeit auswerten ,
oder die "Shiftin - pausenzeit" messen da gibt es schon lösungen ... denke ich .
Und bei einer Baudrate von zb 115200
sind die 4 Byte (eines MS - 1Adresse + 3Datenbytes) doch recht schnell zur Anzeige übertragen.

@ Dino

genau darum hab ich damals gesagt das man es eigentlich nicht mit dem SPI oder ShiftIn machen kann weil man nur auf die Flanken des Taktes triggert. Wenn man also mitten im ersten Datagramm anfängt dann nimmt der Atmel die Pause zwischen den Datagrammen auch als ein Datenbit und ist dann mitten im zweiten Datagramm fertig. Er wird also nicht wirklich synchron sein. Aber wer weiß evtl irre ich mich ja auch. Ich finde die Lösung allerdings nicht wirklich stabil. Es gibt zu viele Unwägbarkeiten die nicht wirklich in der Software abgefangen werden.

das stimmt schon , aber das Datenprotokoll lässt uns ja keine Andere Wahl als auf das Clock Signal zu reagieren , einen Anderen Anhaltspunkt habe wir ja nicht.
Um ein durcheinanderkommen zu vermeiden könnte man zb den timer nutzen und die übertragungslänge bestimmen um so ein überspringen zum nächten paket zu vermeiden.
an dieser stelle klemmt es bei mir bis jetzt auch noch etwas .
In meinem Sytem habe ich aber so gut wie keine Fehlerhafte anzeige , deshalbt habe ich hier noch nicht weiter gearbeitet .

schön mit euch darüber zu Diskutieren , da bekommt man direkt mal noch ein paar neue Ideen !
ich wünsche euch noch einen schönen Abend ...
grüße

Sven

 

[LotadaC]

Ja, ich habe ja nur befürchtet, daß die 13µs Zyklenzeit nicht grad viel sind - wenn man 3 MS quasi synchron auswerten lassen will. Wenn so'n "Fallende-Clock-Flanke-Interrupt" an allen 3 MS fast gleichzeitig erfolgt, würden schon allein die (32+1)*2*3 Pushs und Pops, die Bascom automatisch erzeugt über 12µs dauern (bei 16MHz - waren auch mal irgendwo gegeben). Und dann müssen auch die Datenpins ausgelesen, und in die entsprechenden Ergebnisbytes geschoben werden.
Also ohne Bascom das Register-retten (nosave oder so) abzunehmen, und eingebettetem ASM sehe ich da so kein Land (mit sollte es aber gehen).
Im Fast-Mode könnte man ja versuchen, auf die lange Pause zu syncen, und immer nur einen Kanal gleichzeitig auszulesen - Matthias hatte aber den slow-Mode festgelegt, oder? Dann wären wie gesagt so nur Aktualisierungsraten mit ca 1Hz drin.

Ich hab' mir jetzt nochmal die Oszibilder (Yadro) versucht anzusehen.
-die clock ist low (data auch)
-die clock geht high, und bleibt 53µs high (Präambel)
-die clock geht low - das ist bereits der erste von den 24 latches
-nach dem 24sten mal low (erstes 3-byte-word empfangen) geht die clock für 106µs high
-die nächste low-Flanke ist der erste latch von insgesamt 24 weiteren Datenbits.
-danach bleibt die Clock (erstmal) high

bis hier sollte das also für den HW-SPI (interruptbasiert) kein Problem sein - dummerweise geht die clock aber zwischen 2 kompletten Datagrammen auf low - diese Flanke muß mitberücksichtigt werden (übrigens auch bei der Methode zu Fuß). Am sinnigsten sollte man also den HW-SPI direkt nach dem 2ten 24bit-Paket abschalten (SPE in SPCR löschen, in der ISR), und irgendwann in der Hauptprogramm-Schleife wieder anschalten (gelegentlich pollen ob SPE gelöscht und die Clock low ist, dann SPE wieder setzen - sollte sich ja bei fast 300ms Pause irgendwann mal'n Moment finden lassen).
_______________Bezog sich auf Dinos Post__________________

Edit: der HW-SPI ist Byteweise, aber eben während des Bytes im Hintergrund - shiftin arbeitet ja sogar nur Bitweise und komplett im Vordergrund.

Wenn alle Kanäle quasi gleichzeitig ausgelesen werden sollen, muß man per Interrupt auf die entsprechenden Flanken (die Anforderungsflags bleiben ja solange stehen) der Clocks reagieren, und zwar bei jedem eingehenden Bit. Außerdem müssen alle 3 ISR (im worst case) nacheinander innerhalb dieser Zykluszeit (13µs) ausgeführt werden können.

noch'n Edit: genau genommen hat man sogar nur 6,5 µs Zeit, da sich dann bereits der Zustand am Datenpin wieder ändern kann.
und zu 4. und 5.: Doch, genau darum geht es uns (zumindest mir), also jedes Telegramm jedes ms zu erfassen. Die Telegramme der verschiedenen Kanäle nacheinander zu erfassen ist ja fast trivial die sichere Erkennung einer ausreichend langen Pausenzeit des grad aktuellen Kanals läßt sich ja mehr oder weniger elegant mit einem Timer und den clock-Pins realisieren - ggf dort auch mit IRQs, um nicht auf die Pause warten zu müssen. Und natürlich könntest Du in einer 300ms-Pause die Daten aller 3 MS (9 Bytes) irgendwohin senden lassen - 1 MS sendet Dem µC schliesslich auch innerhalb von weniger als 1ms 6 Bytes... - die Frage ist eher, wieviel Datenverkehr dazu zum Display gesendet werden muß.

 

[svenhummel]

Hallo LotadaC,

Wenn alle Kanäle quasi gleichzeitig ausgelesen werden sollen, muß man per Interrupt auf die entsprechenden Flanken (die Anforderungsflags bleiben ja solange stehen) der Clocks reagieren, und zwar bei jedem eingehenden Bit. Außerdem müssen alle 3 ISR (im worst case) nacheinander innerhalb dieser Zykluszeit (13µs) ausgeführt werden können.

JA, ganz genau , so sollte es sein ... , da sind wir uns ja einig

das klappt aber nur wenn der µC schnell genug ist , mit 8MHz wird das nichts ...
(Matthias hatte ja 8MHz , dachte ich ..? )

Doch, genau darum geht es uns (zumindest mir), also jedes Telegramm jedes ms zu erfassen. Die Telegramme der verschiedenen Kanäle nacheinander zu erfassen ist ja fast trivial

ja , so tivial das es immer wieder Probleme gibt ....

Machen wir mal kurz einen Ausflug an die Maschine ( Fräse / Drehbank)
Dafür wird ja das Messsystem gebraucht ...

Wir reden hier von einem Messsystem das bei guten MS fast die 1/100mm Genauigkeit erreichen kann , wenn ihr wirklich
mit "NUR" 3 Messungen / sekunde arbeitet schießt ihr aber am Ziel weit vorbei.

Bei einer Maschine mit 100mm Vorschub / min ( das ist jetzt nicht sonderlich schnell ) entspricht das 1,6mm/sec
und demzufolge 0,533 mm/ Messung
logischerweise , und da muß ich dir uneingeschränkt 100% zustimmen , wäre hier eine verpasste Messung sehr verherrend , für das Werkstück ,
also liegt die Genauigkeit wirklich nicht dort wo wir sie haben wollen .

Und glaube mir , ich komme aus der Praxis und habe selbst auch schon so gearbeitet , es ist sehr nervig wenn man die letzten 1mm mit
3 messungen / secunde "abknabbern" muß , das macht dann nicht wirklich Spaß .

Beim Fastread Mode sieht die Sache schon anders aus
da haben wir ein verfahrweg von 0,032mm / messung , also selbst bei einem Messerfolg von 50% liegen wir noch bei 0,064mm messgenauigkeit ,
damit kann man schon gut an den Maschinen arbeiten .

Bei Maschinen wo der Vorschub per Hand betätigt wird mag das noch gehen , aber bei maschinellem Vorschub ist es nicht praktikabel .

naja , das ist nunmal nicht ganz so einfach ...

übrigens , das bis jetzt stabilste und genauste system habe ich (für mich) bis jetzt ( mit 3 MS im System) ganz "trivial" im Fastread Modus und shiftin in der
Hauptschleife erreicht .

Aber genau wie du schon erwähnt hast , ist es wahrscheinlich die beste Lösung auf jede einzelne "clockflanke" per Interrupt zu reagieren und in der ISR mitzuzählen .
mal sehen wer den ersten "code" nach deisem Schema hier ins Forum gibt ...

wenn ich im Augenblick etwas mehr zeit hätte würde ich gleich "losbasteln" , bin aber im augenblick an meiner 4A NC Steuerung und einem "Rostschaden" an Opa's
Wagen voll eingespannt ...leider

einen schönen Abend wünsch ich euch

grüße

Sven

 

[LotadaC]

Mangels digitaler MS und eines ordentlichen Oszilloskopes/Logicanalyzers ist das für mich alles nur Theorie.
Kannst Du mal was genaueres zu denTelegrammen im FastRead sagen. Ändert sich da was, oder bleibts bei einem 850µs Telegramm, bestehend aus 2 Paketen à 24 bit (bzw 3 Byte). Clockzyklen 13µs, vor und nach den Paketen ist/bleibt die clock 53µs high (also insgesamt zwischen den beiden Paketen eines Telegrammes 106µs).
Ändert sich hier was, oder nur in der Pausenlänge zwischen 2 Telegrammen (ca 332ms -> ca 19ms - Telegramm in beiden Fällen ca 1ms (850µs))?

Man kann bei Bascom ja eine Variable an einer festgelegten SRAM-Adresse definieren (mit Dim name As typ At adresse). Damit sollte es eigentlich möglich sein, diese Variable nur mit ASM-Instruktionen zu manipulieren (im die ISRs zu optimieren).

Ich hatte vor meinem Umzug schon mal das wesentliche so einer ISR in code gepresst - muß das nur wieder finden...

naja, ich nehm mir morgen einfach mal wieder'n Stift und'n Zettel mit in die Bahn - hab da ja reichlich Zeit...

 

[svenhummel]

Hallo LotadaC,

bin gerade erst von der Arbeit rein , werde mich dann gleich mal drüber machen und Oszibilder hochladen.

bis dann

Sven

 

[svenhummel]

2x24 Bit Protokoll für Digitalmessschieber

Hallo LotadaC

Im normalen Modus ist die Pausenzeit zwischen den Datenpaketen ca 320ms , das Datenpaket selbst ist ca 830µs lang,
das Clocksignal liegt auf low und wird vor den ersten clock für 50µs auf High gesetzt , dann kommt das erste paket mit ca 300µs länge.
die Pause zwischen den paketen ist ca 110µs lang , das zweite paket ist dann wieder ca 300µs lang , danach bleibt clock noch ca 60µs high
bevor es wieder abfällt.

Im Fastread modus bleibt das Datenpaket unverändert nur die Pausenzeit wird von ca 320ms auf 25ms reduziert.
jeder clock zyklus ist ca 13µs lang
Im Anhang sind ein paar oszi bilder , ich hoffe sie nutzen dir was .

Anhang anzeigen MAP011.BMPAnhang anzeigen MAP022.BMPAnhang anzeigen MAP033.BMPAnhang anzeigen MAP044.BMPAnhang anzeigen MAP055.BMP

fazit die Pakete bleiben 100% gleich , da ändert sich nichts.

Ich hatte vor meinem Umzug schon mal das wesentliche so einer ISR in code gepresst - muß das nur wieder finden...

Ich bin zwar noch nicht groß mit meiner "Technik" umgezogen , aber bei mir war auch schon so einiges verschollen ,
ich glaube bei Genie's ist das wohl so ...... , oh hier stinkts ....

versuch mal dein glück , allerdings kann ich mit assembler nicht mithalten , kann nur ein bischen Bascom Basic ...

grüße

Sven

 

[Cassio]

Hallo Sven!

Nimm das nächste Mal doch bitte GIF-Bilder!

Zum Einen kannst du sie hier dann direkt einbinden und zum Anderen kannst du dann eine höhre Auflösung verwenden!


Ich habe deine BMP-Bilder mal konvertiert und stelle sie hier nun als GIF-Bilder ein.
Auf diese Weise kann jeder schneller einen Blick darauf werfen und muss nicht jedes Bild erst einzeln herunter landen.






Grüße,
Cassio