Seite 1 von 1
MVCom / PB Serial welche pro-contras ?
Verfasst: 09.07.2009 20:49
von Graffiti
Jetzt habe ich auch mal wieder ein paar Fragen:
1.
Welchen Vorteil / Nachteil hat MV Com zur PB eigenen seriellen Ansteuerung
2.
wie realisiere ich eine permanente Überwachung ob Daten ankommen, ohne PB darauf warten zu lassen ob sich was am ser. Port tut,
z.B. ein Programm wird ausgeführt kann ein Player oder sonstiges sein,
dann wird von einem Microcontroller 100 100 100 an den ser.Port gesendet, bedeutet eine xy Procedure soll ausgeführt werden.
dazu brauche ich AvailableSerialPortInput() in der Hauptschleife - richtig ?
3.
in einer Prüfung sende ich Daten an die Schnittstelle und vom Atmel soll eine Rückmeldung kommen, in einem x Zeitpunkt (For-To Schleife bei mir)
das funktioniert auch soweit super, nur ist es die eleganteste Lösung die ich verwende ?
Code: Alles auswählen
Dim Bufferx.c(1)
Dim Buffer.c(7)
Buffer(0) = 25
Buffer(1) = 55
Buffer(2) = wert1 ; Adresse MSB z.B. 256 = 1
Buffer(3) = wert2 ; Adresse LSB bis 255
Buffer(4) = daten ; gespeicherter Bildwert , INFO: ein Bild hat 14 Bytes
Buffer(5) = 0
Buffer(6) = wert4 ; berechnetes letztes LSB
Buffer(7) = 0
WriteSerialPortData(#serport, @Buffer(0), 8)
For i = 1 To 100
ReadSerialPortData(#serport, @Bufferx.c(0), 2)
If Bufferx.c(0) = 26 And Bufferx.c(1) = 0
Break
EndIf
gruß Gerhard
Verfasst: 11.07.2009 02:07
von Falko
Punkt 1
Was soll man da vergleichen? Es sind in der MVCOM gegenüber
PB mehr Funktionen enthalten. Aber PB hat das Wichtigste, das
man braucht.
Punkt 2
Ich würde das mit einem Thread versuchen, der z.B. in einer kurzen Zeit unabhängig vom Hauptprogramm den Input überprüft und puffert.
Das Hauptprogramm würde dann in größeren Abständen prüfen, wieviel Bytes im Puffer sind und diese dann auslesen.
Ich habe mal probiert, wie man es machen könnte. Evtl. müsste man den Thread nach dem Auslesen des Puffers beenden und dann wieder neu starten usw. .
Code: Alles auswählen
Procedure Timer(*MemoryID); Kein Delay verwendet, was den Thread anhalten würde!
Protected Time.l=1000
Protected bytes.b=0
Protected Text.s
start=ElapsedMilliseconds()
Repeat
Anzahl=ElapsedMilliseconds()-start-14
If Anzahl >=1000
;Debug Anzahl
Text+Str(Random(100))
PokeS(*MemoryID,Text)
bytes+1
start=ElapsedMilliseconds()
EndIf
ForEver
EndProcedure
*MemoryID=AllocateMemory(5000)
CreateThread(@Timer(),*MemoryID)
Repeat
Debug PeekS(*MemoryID)
Delay(5000)
ForEver
Ich hoffe es ist so korrekt mit dem gemeinsamen Speicher.
Gruß Falko
Verfasst: 24.07.2009 00:55
von Graffiti
Hallo Falko (irgendwie habe ich gewußt das du dich meldest
erstmal danke für deine Antwort, aber ich muß erstmal am Wochenende
einen Atmel proggen das ichs testen kann
kann ich eigentlich nicht in die Hauptschleife z.B. diesen Code ausführen,
denn im Normalfall wird ja nach dem auslesen der serielle Puffer auf null gesetzt von Windows
oder irre ich mich da
Code: Alles auswählen
if AvailableSerialPortInput(#SerialPort) > 0
proze_serial_auslesen()
endif
gruß Gerhard
Verfasst: 24.07.2009 13:05
von Falko
>>>kann ich eigentlich nicht in die Hauptschleife z.B. diesen Code ausführen, denn im Normalfall wird ja nach dem auslesen der serielle Puffer auf null gesetzt von Windows oder irre ich mich da
Hallo Gerhard,
Die Lösung mit der der IF-Abfrage in der Hauptschleife nutze ich bei der elektronischen Waage. Das geht prima. Wie das mit Windows funktioniert, kann ich leider nicht beantworten.
Diese PDF beschreibt die serielle Schnittstelle sehr gut.
http://www.designin.de/Artikel/PC-Schni ... C-MT04.PDF
Gruß Falko
Verfasst: 24.07.2009 13:42
von Graffiti
Danke Falko
sobald ich getestet habe melde ich mich wieder
gruß Gerhard
Verfasst: 28.07.2009 14:44
von super_castle
Du kannst doch mit Purebasic abfragen ob etwas im Buffer ist.
Die For-Schleife ist total ungünstig, zumal der Atmega keine Kontrollbytes über 2 zusätzlichen Leitungen rauschickt, bzw auf Empfang kontrolliert.
Oder muss diese zusätzlichen Leitungen vom Atmega an den Max anschliessen auf der Platine, die dann von Pure abgefragt werden.
mfg
Verfasst: 28.07.2009 15:48
von Graffiti
@super-castle
ich frage doch mit PB ab
Beispiel:
ich sende Daten an einen Controller, dieser gibt an PB eine OK Meldung zurück
danach sende ich die nächsten Daten warte auf die Antwort, danach weiter weiter weiter
es muß nach jedem gesendeten Datensatz eine OK-Meldung zurückkommen, ob die Daten korrekt im Controller gelandet sind
sollte der Port nicht funktionieren oder keine Meldung ankommen, wartet PB doch sonst ewig drauf und ich hänge in einer Endlosschleife.
mit der For-Next schleife gebe ich dem Controller die Möglichkeit in dem X-Zeitraum zu antworten,
kommt keine Antwort ... Abbruch
kommt eine Antwort springt er sofort aus der Schleife
ohne die For-Next habe ich schon erlebt das die Daten etwas zu spät kommen und dann hängts,
erfahrungsgemäß kommen korrekte Daten zwischen dem 1. und 10. Durchlauf der Schleife zurück
gruß Gerhard
Verfasst: 28.07.2009 21:47
von Falko
Leider kann ich das selbst nicht testen. Dazu müsste ich mir selbst was mit Atmel zurecht machen. Aber man kann auch prüfen, ob noch Daten vorhanden sind, die gelesen werden müssten. Die Abbruchbedingung habe ich so gelassen.
Hier dein Beispiel etwas abgeändert. Ist aber ungeprüft.
Code: Alles auswählen
Dim Bufferx.c(1)
Dim Buffer.c(7)
Buffer(0) = 25
Buffer(1) = 55
Buffer(2) = wert1 ; Adresse MSB z.B. 256 = 1
Buffer(3) = wert2 ; Adresse LSB bis 255
Buffer(4) = daten ; gespeicherter Bildwert , INFO: ein Bild hat 14 Bytes
Buffer(5) = 0
Buffer(6) = wert4 ; berechnetes letztes LSB
Buffer(7) = 0
WriteSerialPortData(#serport, @Buffer(0), 8)
;For i = 1 To 100
While AvailableSerialPortInput(#serport); oder While AvailableSerialPortInput(#serport) > 0
ReadSerialPortData(#serport, @Bufferx.c(0), 2)
If Bufferx.c(0) = 26 And Bufferx.c(1) = 0
Break
;EndIf
Wend
Gruß Falko
Verfasst: 29.07.2009 09:11
von Graffiti
Hi Falko
in meinem Fall kann ich mir das While AvailableSerialPortInput(#serport) schenken,
sollte nämlich die Schleife bis 100 durchgelaufen sein
und die zwei Buffer keinen oder einen falschen Wert haben,
kommt danach sowieso eine Fehlermeldung