 |
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
pebisoft gesperrt
Anmeldungsdatum: 28.11.2004 Beiträge: 131
|
Verfasst am: 09.10.2006, 14:24 Titel: |
|
|
wie sieht das aus, wenn ich jetzt hier einen pointer von freebasic übergebe?
wie sieht die initialisierung des pointer aus und wie sieht der eintrag in der declare aus?
declare function teststr cdecl Alias "teststr" ()
danke.
mfg |
|
Nach oben |
|
 |
terminate
Anmeldungsdatum: 12.09.2006 Beiträge: 56
|
Verfasst am: 09.10.2006, 14:31 Titel: |
|
|
pebisoft hat Folgendes geschrieben: | wie sieht das aus, wenn ich jetzt hier einen pointer von freebasic übergebe?
wie sieht die initialisierung des pointer aus und wie sieht der eintrag in der declare aus?
declare function teststr cdecl Alias "teststr" ()
danke.
mfg |
Wie in meinem ersten Beispiel:
Code: |
dll statisch laden
#inclib "mydllmain"
declare function mydllmain_show_str cdecl Alias "mydllmain_show_str" (byval my_string as zstring ptr)
'zstring mit der laenge 20 deklarieren
dim zs_teststring as zstring * 20
'zstring den Wert "freebasic zuweisen
zs_teststring= "freebasic"
'dll zeigt den Inhalt von zs_teststring an und verändert ihn
mydllmain_show_str(strptr(zs_teststring))
'neuen Inhalt von zs_teststring in FreeBasic anzeigen
print zs_teststring
sleep
end
|
|
|
Nach oben |
|
 |
pebisoft gesperrt
Anmeldungsdatum: 28.11.2004 Beiträge: 131
|
Verfasst am: 09.10.2006, 16:07 Titel: |
|
|
hallo, dank deiner hilfe kann ich jetzt mit freebasic viele arten der dll ansprechen die ich mit purebasic erstellt habe .
und das schönste, ich kann jetzt in eins meine 16384byte von der gameboycam in einen seriellen buffer einlesen und mit freebasic auswerten, diese dll hatte ich mal als erste frage reingestellt.
die dll in purebasic
Code: |
Global test.w
Global test2.b
Global test1.s
Global z.w
eine wert wird übergeben, addiert und in der variablen test zurückgegeben !
ProcedureCDLL.w testzahl(wert.w)
test=wert+24
ProcedureReturn test
EndProcedure
der string test1 wird mit den ascii 33 -128 beschrieben und als string test1 zurückgegeben
ProcedureCDLL.s teststr()
test1=""
For z=33 To 128
test1=test1+Chr(z)
Next
ProcedureReturn test1
EndProcedure
es wird ein string übergeben, dazu wird der string test1 addiert und dann der string test1 zurückgegeben
ProcedureCDLL.s teststr1(wert.s)
test1=""
test1="pebisoft es geht "
test1=test1+wert
ProcedureReturn test1
EndProcedure
ein pointer (in freebasic mit allocate erstellt wird übergeben , dann in der dll mit werten beschrieben,
die übergabe findet nicht statt, weil ich den pointer von freebasic wieder auslesen kann.
ProcedureDLL mem(*BankPointer)
test2=23
PokeB(*BankPointer+3, test2.b)
test2=45
PokeB(*BankPointer+4, test2.b)
EndProcedure
|
das freebasicprogram mit den dll-aufrufen, alle funktionieren einwandfrei.
Code: |
#inclib "free"
dim p_mystring as zstring ptr
dim b as short
dim c as string *10
DIM AS byte PTR buffer
buffer = ALLOCATE(20)
SCREEN 18
declare function testzahl cdecl Alias "testzahl" (byval a as short) as long
declare function teststr cdecl Alias "teststr" () as zstring ptr
declare function teststr1 cdecl Alias "teststr1" (byval a as string) as zstring ptr
declare function mem cdecl Alias "mem" (byval a as byte ptr)
sleep 500
b=101
print testzahl(b)
sleep
p_mystring=teststr()
print *p_mystring
sleep
c="doch !!!"
p_mystring=teststr1(c)
print *p_mystring
SLEEP
mem(buffer)
print buffer[3]
print buffer[4]
SLEEP
|
|
|
Nach oben |
|
 |
terminate
Anmeldungsdatum: 12.09.2006 Beiträge: 56
|
Verfasst am: 09.10.2006, 20:17 Titel: |
|
|
pebisoft hat Folgendes geschrieben: | hallo, dank deiner hilfe kann ich jetzt mit freebasic viele arten der dll ansprechen die ich mit purebasic erstellt habe .
und das schönste, ich kann jetzt in eins meine 16384byte von der gameboycam in einen seriellen buffer einlesen und mit freebasic auswerten, diese dll hatte ich mal als erste frage reingestellt.
|
Schön, wenn mal was funktioniert
Stellt sich noch die Frage, warum du die Gameboycam nicht gleich in freebasic ausgelesen hast. Aber ist auch egal, immerhin sind solche Experimente auch immer dazu geeignet, das eigene Wissen zu erweitern
Hier ist mir noch eine kleine Diskrepanz zwischen zwei Deklarationen aufgefallen, die freebasic Deklaration verwendet C Konvention, die purebasic hingegen nicht, vermutlich macht das nichts aus, wenn man nur auf allozierten Speicher zugreift, sonst ist das aber immer eine unkalkulierbare Fehlerquelle, (Strings werden verändert, komische Zeichen werden gedruckt etc.)
Code: |
ProcedureDLL mem(*BankPointer)
declare function mem cdecl Alias "mem" (byval a as byte ptr)
|
|
|
Nach oben |
|
 |
pebisoft gesperrt
Anmeldungsdatum: 28.11.2004 Beiträge: 131
|
Verfasst am: 09.10.2006, 22:20 Titel: |
|
|
Stellt sich noch die Frage, warum du die Gameboycam nicht gleich in freebasic ausgelesen hast. ....
die gameboycam liefert 16384 byte in den seriellen buffer von purebasic in einem zug weil ich kein ram auf der avrplatine habe.
diesen seriellen buffer lese ich dann mit den freebasicpointer aus.
die com von freebasic hat max nur eine seriellen einstellbaren buffer von 4096. ich müsste den buffer mit der cam 4x füllen und in freebasic wieder 4x auslesen. ausserdem speichert die cam das bild nicht, sie liest in ihren zellen das bild was sie gerade sieht immer wieder neu ein.
in der zeit der datenübertragung darf der roboter sich auch nicht bewegen. |
|
Nach oben |
|
 |
terminate
Anmeldungsdatum: 12.09.2006 Beiträge: 56
|
Verfasst am: 09.10.2006, 22:52 Titel: |
|
|
pebisoft hat Folgendes geschrieben: | die gameboycam liefert 16384 byte in den seriellen buffer von purebasic in einem zug weil ich kein ram auf der avrplatine habe.
diesen seriellen buffer lese ich dann mit den freebasicpointer aus.
die com von freebasic hat max nur eine seriellen einstellbaren buffer von 4096. ich müsste den buffer mit der cam 4x füllen und in freebasic wieder 4x auslesen. ausserdem speichert die cam das bild nicht, sie liest in ihren zellen das bild was sie gerade sieht immer wieder neu ein.
in der zeit der datenübertragung darf der roboter sich auch nicht bewegen. |
Ok, poste doch mal den Code, mit dem seriellen Buffer der unter Freebasic problematisch war.
Und noch ne Bitte, benutz das nächste mal die Quotes, macht mich ganz meschugge jedes mal meinen eigenen Text noch mal lesen zu müssen. |
|
Nach oben |
|
 |
pebisoft gesperrt
Anmeldungsdatum: 28.11.2004 Beiträge: 131
|
Verfasst am: 09.10.2006, 23:09 Titel: |
|
|
habe in tb und rb 16300byte eingeben, wenn ich den buffer ausprinte, komme ich auf 4096 byte. ich sehe auch, das die letzen 4096byte von den 16000 byte nur drin stehen im buffer, es wird intern also 4x durch gezogen.
Code: |
screen 19,16
DIM test1 AS STRING * 10
DIM test2 AS STRING * 2
dim test as ubyte
dim zaehler as integer
open com "COM1: 19200, N, 8, 1,CS0,DS0,TB16300,RB16300" As #1
sleep 500
test1="los"+chr(13)
print #1,test1
sleep 8000
for zaehler=1 to 16000
test2=INPUT(1, #1)
PRINT zaehler,ASC(test2)
next zaehler
print "ende"
sleep 500
close #1
open com "COM1: 19200, N, 8, 1,CS0,DS0" As #1
print #1,""
close #1
DO
t$ = INKEY$
LOOP UNTIL t$ = CHR$(27)
|
|
|
Nach oben |
|
 |
terminate
Anmeldungsdatum: 12.09.2006 Beiträge: 56
|
Verfasst am: 09.10.2006, 23:50 Titel: |
|
|
pebisoft hat Folgendes geschrieben: | habe in tb und rb 16300byte eingeben, wenn ich den buffer ausprinte, komme ich auf 4096 byte. ich sehe auch, das die letzen 4096byte von den 16000 byte nur drin stehen im buffer, es wird intern also 4x durch gezogen.
|
Kann ich das so zusammenfassen:
rb ist auf 16300 Bytes eingestellt, es werden 16300 eingelesen, im Buffer sind aber hinterher nur die letzten 4096 Bytes zu finden von den 16300 die eigentlich eingelesen werden sollten?
Unabhängig davon kleine Unstimmigkeit noch: Du hast angegeben, dass die gameboycam 16384 Bytes liefert. |
|
Nach oben |
|
 |
pebisoft gesperrt
Anmeldungsdatum: 28.11.2004 Beiträge: 131
|
Verfasst am: 10.10.2006, 09:11 Titel: |
|
|
ca 180byte sind keine bilddaten sondern einstellungszahlen.
ich habe auch schon 17000byte eingestellt, kommt das gleiche resultat.
der buffer 4096 wird immer wieder im kreislauf aufgefüllt, bis das einlesen beendet ist und ich sehe nur die letzten 4096byte.
mfg |
|
Nach oben |
|
 |
terminate
Anmeldungsdatum: 12.09.2006 Beiträge: 56
|
Verfasst am: 10.10.2006, 14:28 Titel: |
|
|
Und wie sieht der Code zum öffnen des Com Ports und einlesen der Daten in Purebasic aus? |
|
Nach oben |
|
 |
pebisoft gesperrt
Anmeldungsdatum: 28.11.2004 Beiträge: 131
|
Verfasst am: 10.10.2006, 14:40 Titel: |
|
|
in der ersten procedure "com_open_" wird die schnittstelle geöffnet mit den benötigten daten. bufferin und bufferout kann riesengroß gestaltet werden. in "com_txd_text_" kann ich dann die daten eingeben die ich möchte.
Code: |
Global HCom.l
Global Chaine.s
Global los.s
ProcedureDLL.l com_open_(buffer.w)
BufferIn = buffer.w
BufferOut = buffer.w
Chaine="COM1:19200,N,8,1"
HCom=ComOpen(Chaine,0 ,BufferIn,BufferOut)
ProcedureReturn Hcom.l
EndProcedure
ProcedureDLL com_txd_text_(text.s)
los.s = text +Chr(13)
ComWrite(HCom,@los,Len(los))
EndProcedure
ProcedureDLL com_rxd_(*BankPointer,buffer.w)
ComRead(HCom,*bankpointer,buffer.w)
EndProcedure
|
|
|
Nach oben |
|
 |
volta
Anmeldungsdatum: 04.05.2005 Beiträge: 1876 Wohnort: D59192
|
Verfasst am: 10.10.2006, 14:54 Titel: |
|
|
pebisoft hat Folgendes geschrieben: | ca 180byte sind keine bilddaten sondern einstellungszahlen.
ich habe auch schon 17000byte eingestellt, kommt das gleiche resultat. | das Übertragungsprotokoll deines AVR müsstest du aber kennen!
pebisoft hat Folgendes geschrieben: | der buffer 4096 wird immer wieder im kreislauf aufgefüllt, bis das einlesen beendet ist und ich sehe nur die letzten 4096byte. | richtig, wenn du weißt welche Daten für dein Bild relevant sind, kannst du das mit dem Prog, welches ich dir im anderen Thread vorgeschlagen habe, auch ohne Zusatz-dll testen. 8 Sekunden warten bis der Buffer überläuft ist keine Lösung!  _________________ Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
Nach oben |
|
 |
pebisoft gesperrt
Anmeldungsdatum: 28.11.2004 Beiträge: 131
|
Verfasst am: 10.10.2006, 15:35 Titel: |
|
|
das bildübertragen, ca 16100byte dauert bei 19200baud ca 6,7 sec. später werde ich auf 115000baud erhöhen.
ich brauche das ganze bild(128+127pixel) zum auswerten, es wird dann im sreen dargestellt. mit meine puredll als serielle hilfe klappt es jetzt.
warum kann ich nicht tb und rb erhöhen über 4096byte in freebasic.
der serielle buffer wird nicht vom pc und nicht von windows fest vorgegeben.
wenn ich nichts festlege, dann wird er mit 4096byte bereitgestellt. wenn ich ihn aber festlege, was ja in purebasic und freebasic gemacht werden kann , habe ich so den neuen buffer zur verfügung. bloss das freebasic erkennt den wert größer 4096 nicht an,..hmmm...komisch und in pure geht es bis zum theoretischen freien speicher.
Zitat: | das Übertragungsprotokoll deines AVR müsstest du aber kennen! |
das übertragungsprotokoll ist das gleiche welches ich in freebasic oder pure benutze, kann es mit dem programm /fastavrbasic/ im avr vorgeben.
der avr schickt 16384byte von der cam zum pc, ca 16100byte sind bilddaten und der rest an bytes interne daten.
jedes byte ist ein bildpunkt , den ich dann mit pset von 1-128 im screen darstelle, bei dem ersten byte im buffer angefangen. wenn 128 pixel in einer reihe dargestellt sind , wird y um eins erhöht und der pset geht in der nächsten reihe weiter. irgendwann habe ich 126,5 bildreihen und die restlichen punkte machen keine aussage mehr über das bild und da breche ich auch ab.
das bild ist dann in 255 graustufen schön sichtbar auf dem screen. |
|
Nach oben |
|
 |
volta
Anmeldungsdatum: 04.05.2005 Beiträge: 1876 Wohnort: D59192
|
Verfasst am: 10.10.2006, 18:04 Titel: |
|
|
pebisoft hat Folgendes geschrieben: | warum kann ich nicht tb und rb erhöhen über 4096byte in freebasic.
der serielle buffer wird nicht vom pc und nicht von windows fest vorgegeben. | doch Windows legt den Buffer mit 4KB fest! pebisoft hat Folgendes geschrieben: | wenn ich nichts festlege, dann wird er mit 4096byte bereitgestellt. | eben, von Windows! pebisoft hat Folgendes geschrieben: | mit meine puredll als serielle hilfe klappt es jetzt.
....
..hmmm...komisch und in pure geht es bis zum theoretischen freien speicher. | schau mal in die Deklaration der dll, die legt einen eigenen (zweiten) Buffer dazu an. pebisoft hat Folgendes geschrieben: | das übertragungsprotokoll ist das gleiche welches ich in freebasic oder pure benutze, kann es mit dem programm /fastavrbasic/ im avr vorgeben. | das Übertragungsprotokoll meinte ich nicht. pebisoft hat Folgendes geschrieben: | der avr schickt 16384byte von der cam zum pc, ca 16100byte sind bilddaten und der rest an bytes interne daten.
jedes byte ist ein bildpunkt ,
....
irgendwann habe ich 126,5 bildreihen ... | Wie wird denn nun das Bild übertragen? 128x128 Punkte sind 16384Byte , ca 16100Byte das sind ? x ? Punkte?
126,5 Bildreihen? was ist das denn für ein Format?
pebisoft hat Folgendes geschrieben: | das bild ist dann in 255 graustufen schön sichtbar auf dem screen. | wenn es klappt ok.
Ich wollte dich nur darauf Aufmerksam machen, das du einen großen zeitlichen Umweg (über die dll) machst. 8 Sekunden wartest du, dass die dll die Daten in einen Buffer packt danach holst du die Daten Pixel für Pixel um sie anzuzeigen..... das geht nun wirklich einfacher und schneller, aber dafür muss man das Bildformat schon genauer kennen. _________________ Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
Nach oben |
|
 |
pebisoft gesperrt
Anmeldungsdatum: 28.11.2004 Beiträge: 131
|
Verfasst am: 10.10.2006, 23:10 Titel: |
|
|
das pixelformat ist ganz einfach.
die cam speichert pro pixel einen analogen spannungswert(wie ein condensator . für ca 20sec), der avr wandelt diesen analogen spannungswert um in einen digitalen wert von 0-255 und überträgt ihn dann über funk seriell zum pc. die übertragung dauert bei 19800baud bei ca 16000byte 6,7 sec.
ich warte halt 8sec um sicher zu sein das die daten da sind, weil ich keine if/then abfrage machen möchte pro pixel. wenn ich später auf 115000baud gehe , dauert es ca nur noch 1,2 sec. da die pixelwerte von der cam abgefragt werden über einen timer, muss bei der cam pro pixel ein bestimmter timerwert low sein und dann der timer eine bestimmte zeit high, erst dann meldet z.b. die cam den analogenwert an den adc des avr. das muss 16384mal durchgeführt werden, damit sie wieder bei eins anfängt.
die letzen werte sind nur interne belichtungswerte, die ich nicht brauche, aber trotzdem abgespult werden müssen. darum komme nur auf 126,5 y-werte und 128 x-werte. die werte muss ich dann erst einmal im buffer auffangen um sie dann auf den screen als pixel anzuzeigen, die werte brauche ich einmal um das bild anzuzeigen wo der robby steht und ein zweites bild um die pixel auszuwerten nach hindernissen. während ich das bild auswerte wird mir aber weiterhin das andere bild dargestellt als aktuelle positionsbestimmung. ich nehme weisse bälle, sind im graustufenbild gut zu erkennen um hindernisse darzustellen. so läuft das ganze ab.
die bilddarstellung klappt jetzt schon hervorragend dank eurer hilfe.
jetzt mache ich mich an das hindernisauswerten.
übrigens, das funkbild von der farbcmoscam wird noch zusätzlich über dein videocaptureprogramm dargestellt. werde später nur ein screenbild von der gameboycam zum auswerten haben und das videobild zur positionsbestimmung. |
|
Nach oben |
|
 |
terminate
Anmeldungsdatum: 12.09.2006 Beiträge: 56
|
Verfasst am: 11.10.2006, 02:30 Titel: |
|
|
Ist ja schon ein bisschen 'anders' dieses PureBasic, hab mir vorhin mal die Demoversion runtergeladen. Muß ja deswegen nicht schlecht sein, ich find halt einige Dinge etwas unkonventionell. Z.B. die Variablendeklaration mit dem Suffix '.<type>', oder auch die 'Funktions' bzw. Prozedurdeklaration, (sehr minimalistisch, ich würde mir schon wünschen, dass der Returntype im Header mit angegeben wird).
Ich war etwas verwundert, dass in der Hilfe gar nichts über ComOpen etc. steht, aber gut, hat sich geklärt, zum ansteuern des seriellen Ports benötigt man eine externe Library, (MVCOM), die nicht zu purebasic gehört.
Also hier wird der com port geöffnet
Code: |
ProcedureDLL.l com_open_(buffer.w)
...
HCom=ComOpen(Chaine,0 ,BufferIn,BufferOut)
...
|
Fragen dazu:
1. Schon mal probiert, was passiert, wenn du hier die Länge von BufferIn,BufferOut auf z.B. 1024 setzt.
2. Warum buffer.w, also warum gerade type .word, (-32768 bis +32767), ist doch eigentlich ein sehr eingeschränkter Bereich und vorzeichenbehaftet, jetzt mal nur im Vergleich zu long?
(ok, hat sich erledigt, in purebasic gibts kein integer).
Ich bin mir übrigens nicht sicher, dass BufferIn,BufferOut in Purebasic, die gleichen Buffer sind, wie TB und RB in Freebasic. Möglicherweise hat der MVCOM Programmierer da etwas in seine Library reingebastelt, das ihm praktisch erschien, während Freebasic TB und RB einfach standardmäßig an das Betriebssystem weiterreicht.
D.h. TB und RB ist nichts auf das man sich verlassen kann, bei Übertragungsschwierigkeiten, kann man zwar versuchen TB/RB zu vergrößern oder zu verkleinern, aber jedes Programm, das von einer bestimmten Größe dieser Buffer ausgeht, ist ein potentieller Wackelkandidat.
So wie ich das Konzept des seriellen Ports verstehe, ist der Empfangsbuffer auch nicht dafür da, um ihm eine bestimmte applikationsabhängige Größe zu geben, sondern um dem Rest des Programms etwas Zeit zwischen den einzelnen Aufrufen einer Portausleseroutine zu verschaffen.
Auch diese 'Polling' Geschichten in Zusammenhang mit dem seriellen Port sind ohnehin immer etwas problematisch. Imho ist für vernünftige Serialportprogramierung eine CallBackfunction äußerst hilfreich, so wird z.B. in VisualBasic jedesmal wenn Daten am seriellen Port anliegen ein Event ausgelöst, d.h. sobald Daten im Empfangsbuffer liegen wird eine beliebige Funktion im Programm aufgerufen, dann kann man die Daten kurz auslesen und weiter gehts. Dadurch wird natürlich die Größe des Empfangsbuffers völlig irrelevant, vermutlich würde man sie sogar auf 1 setzen.
O.k. hier liest du dann, den Port aus
Code: |
ProcedureDLL com_rxd_(*BankPointer,buffer.w)
ComRead(HCom,*bankpointer,buffer.w)
...
|
*BankPointer ist ein Zeiger auf einen Speicher, den du in Freebasic alloziert hast und buffer.w, (wie könnte es auch anders sein), hat die Größe von BufferIn, alles paletti.
Ich lasse mich gerne eines besseren belehren, aber ich halte es für möglich, dass du mit MVCOM eine der wenigen Serialport Libraries erwischt hast, mit der dein Programm so wie du es geschrieben hast, überhaupt läuft.
Ist ja auch o.k. '...was funktioniert, hat recht ...', aber dann geht es doch wohl eher darum in Freebasic eine eigene Serialport Library für 'spezielle' Fälle zu schreiben, anstatt sich zu fragen, was mit Open Com TB/RB in Freebasic 'nicht' in Ordnung ist.
However, ich hab auf jedenfall mal ein paar serielle Kabel rausgekramt und werde einige Experimente machen. |
|
Nach oben |
|
 |
pebisoft gesperrt
Anmeldungsdatum: 28.11.2004 Beiträge: 131
|
Verfasst am: 11.10.2006, 20:44 Titel: |
|
|
wenn ich die länge auf 1024 setze, wird der buffer vollgeschrieben und der rest kommt gar nicht in den buffer und wenn ich mehr als 1024 raushole kommen nicht mehr meine daten sondern der müll, der sich gerade in dem speicherbereich befindet der hinter dem buffer kommt.
ich kann den buffer auch mit einem anderen variablentyp to hoch setzen, soviel ram ich noch frei habe für daten.
Zitat: |
ist ja auch o.k. '...was funktioniert, hat recht ...', aber dann geht es doch wohl eher darum in Freebasic eine eigene Serialport Library für 'spezielle' Fälle zu schreiben, anstatt sich zu fragen, was mit Open Com TB/RB in Freebasic 'nicht' in Ordnung ist. |
hier hat einer mal was geschrieben über comport , läuft wahrscheinlich über eine windowsdll oder so, funktioniert aber mit pure, vielleicht kannst du das verwerten :
Zitat: |
; German forum: http://robsite.de/php/pureboard/viewtopic.php?t=2838&highlight=
; Author: Topsoft
; Date: 18. November 2003
Declare ResetDTR(hCom.l)
Declare SetDTR(hCom.l)
Declare ResetRTS(hCom.l)
Declare SetRTS(hCom.l)
Declare ResetTXD(hCom)
Declare SetTXD(hCom.l)
Declare.l GetCTS(hCom.l)
Declare.l GetDSR(hCom.l)
Declare.l GetRING(hCom.l)
Declare.l GetRLSD(hCom.l)
Declare SendChar(hCom.l, Wert.l)
Declare.l ReadChar(hCom.l)
Declare.l OpenCom(Nr.l, Baud.l, Bits.b, Stop.b, Parity.b)
Declare CloseCom(hCom.l)
Structure ComDCB
DCBlength.l
BaudRate.l
fBinary.l
fParity.l
fOutxCtsFlow.l
fOutxDsrFlow.l
fDtrControl.l
fDsrSensitivity.l
fTXContinueOnXoff.l
fOutX.l
fInX.l
fErrorChar.l
fNull.l
fRtsControl.l
fAbortOnError.l
fDummy2.l
wReserved.w
XonLim.w
XoffLim.w
ByteSize.b
Parity.b
StopBits.b
XonChar.b
XoffChar.b
ErrorChar.b
EofChar.b
EvtChar.b
wReserved1.w
EndStructure
Name.s = "Com1"
hCom.l = OpenCom(1,9600,8,#ONESTOPBIT, #NOPARITY)
If hCom > #INVALID_HANDLE_VALUE
ResetDtR(hCom)
SetRTS(hCom)
Delay(1000)
ResetRTS(hCom)
Delay(1000)
Text.s = ""
Zeichen.l = ReadChar(hCom)
While zeichen > - 1
temp.s = Hex(Zeichen)
If Len(temp) < 2
text + "0" + temp + " "
Else
text + temp + " "
EndIf
Zeichen = ReadChar(hCom)
Wend
Debug text
CloseHandle_(hCom)
EndIf
End
Procedure ResetDTR(hCom.l)
Status.l = #CLRDTR
EscapeCommFunction_ (hCom, Status)
EndProcedure
Procedure SetDTR(hCom.l)
Status.l = #SETDTR
EscapeCommFunction_ (hCom, Status)
EndProcedure
Procedure ResetRTS(hCom.l)
Status.l = #CLRRTS
EscapeCommFunction_ (hCom, Status)
EndProcedure
Procedure SetRTS(hCom.l)
Status.l = #SETRTS
EscapeCommFunction_ (hCom, Status)
EndProcedure
Procedure ResetTXD(hCom.l)
Status.l = #CLRBREAK
EscapeCommFunction_ (hCom, Status)
EndProcedure
Procedure SetTXD(hCom.l)
Status.l = #SETBREAK
EscapeCommFunction_ (hCom, Status)
EndProcedure
Procedure.l GetCTS(hCom.l)
ModemStatus.l = 0
GetCommModemStatus_ (hCom, @ModemStatus)
If ModemStatus & #MS_CTS_ON = #MS_CTS_ON
ProcedureReturn 1
Else
ProcedureReturn 0
EndIf
EndProcedure
Procedure.l GetDSR(hCom.l)
ModemStatus.l = 0
GetCommModemStatus_ (hCom, @ModemStatus)
If ModemStatus & #MS_DSR_ON = #MS_DSR_ON
ProcedureReturn 1
Else
ProcedureReturn 0
EndIf
EndProcedure
Procedure.l GetRING(hCom.l)
ModemStatus.l = 0
GetCommModemStatus_ (hCom, @ModemStatus)
If ModemStatus & #MS_RING_ON = #MS_RING_ON
ProcedureReturn 1
Else
ProcedureReturn 0
EndIf
EndProcedure
Procedure.l GetRLSD(hCom.l)
ModemStatus.l = 0
GetCommModemStatus_ (hCom, @ModemStatus)
If ModemStatus & #MS_RLSD_ON = #MS_RLSD_ON
ProcedureReturn 1
Else
ProcedureReturn 0
EndIf
EndProcedure
Procedure SendChar(hCom.l, Wert.l)
Anzahl.l = 0
Menge.l = 1
WriteFile_ (hCom, @Wert, Menge, @Anzahl, 0)
ProcedureReturn Anzahl
EndProcedure
Procedure.l ReadChar(hCom.l)
Wert.l = 0
Anzahl.l = 0
Status.l = 0
GetCommMask_ (hCom, @Status)
If Status And #EV_RXCHAR = #EV_RXCHAR
ReadFile_ (hCom, @Wert, 1, @Anzahl, 0)
If Anzahl
ProcedureReturn Wert
Else
ProcedureReturn -1
EndIf
Else
ProcedureReturn -1
EndIf
EndProcedure
Procedure.l OpenCom(Nr.l, Baud.l, Bits.b, Stop.b, Parity.b)
MyDCB.ComDCB
Name.s = "Com" + StrU(Nr,#Byte)
MyDCB\DCBlength = SizeOf(ComDCB)
MyDCB\BaudRate = Baud
MyDCB\fBinary = #True
MyDCB\fParity = #False
MyDCB\fOutxCtsFlow = #False
MyDCB\fOutxDsrFlow = #False
MyDCB\fDtrControl = #DTR_CONTROL_DISABLE
MyDCB\fDsrSensitivity = #False
MyDCB\fTXContinueOnXoff = #True
MyDCB\fOutX = #False
MyDCB\fInX = #False
MyDCB\fErrorChar = 0
MyDCB\fNull = #False
MyDCB\fRtsControl = #RTS_CONTROL_DISABLE
MyDCB\fAbortOnError = #False
MyDCB\XonLim = 4096
MyDCB\XoffLim = 4096
MyDCB\ByteSize = Bits
MyDCB\Parity = Parity
MyDCB\StopBits = Stop
MyDCB\XoffChar = $3F
MyDCB\ErrorChar = 0
MyDCB\EofChar = 0
MyDCB\EvtChar = 0
hCom.l = CreateFile_ (@Name, #GENERIC_READ | #GENERIC_WRITE, 0, 0, #OPEN_EXISTING, 0, 0)
If hCom = #INVALID_HANDLE_VALUE
ProcedureReturn -1
EndIf
If GetCommState_(hCom, @MyDCB) = 0
ProcedureReturn -1
EndIf
If SetupComm_ (hCom, 4096, 4096) = 0
ProcedureReturn -1
EndIf
If SetCommState_ (hCom, @MyDCB) = 0
ProcedureReturn -1
EndIf
Status.l = #EV_CTS | #EV_DSR | #EV_RING | #EV_RLSD | #EV_RXCHAR
If SetCommMask_ (hCom, Status) = 0
ProcedureReturn -1
EndIf
ProcedureReturn hCom
EndProcedure
Procedure CloseCom(hCom.l)
CloseHandle_(hCom)
EndProcedure
; ExecutableFormat=
; EOF
|
vielleicht hat einer verbindung zum freebasic-hersteller und schildert das problem mal. und es geht dann ohne ein eigenes erstelltes programm. das freebasic ist doch noch jung und steckt in den kinderschuhen version 0.17. |
|
Nach oben |
|
 |
Kai Bareis

Anmeldungsdatum: 10.09.2004 Beiträge: 545 Wohnort: Baden Würtemberg
|
Verfasst am: 11.10.2006, 21:16 Titel: |
|
|
Also ich weis ja nicht wo deine Probleme sind OPEN COM von Freebasic zu nutzten und jedes angekommene Byte an einen String zu hängen und das in einer schleife biss das letztes Byte da ist.
Ich habe auch schon das ein oder andere mit nem AVR und FB ausprobiert auch AD wnadler werte kontinuierlich lesen bzw in den ram vom AVR zu schreiben. _________________ MfG Kai Bareis
Es ist noch kein Meister vom Himmel gefallen! Warum einfach wens auch umständlich geht! |
|
Nach oben |
|
 |
pebisoft gesperrt
Anmeldungsdatum: 28.11.2004 Beiträge: 131
|
Verfasst am: 11.10.2006, 22:54 Titel: |
|
|
wenn es die buffereinstellung gibt, so muss es doch eine lösung geben den buffer grösser als 4096 zu setzen. da freebasic erst in den kinderschuhen mit 0.17, ist doch für den programmierer von freebasic ein leichtes, dieses mit reinzunehmen.
Zitat: |
Ich habe auch schon das ein oder andere mit nem AVR und FB ausprobiert auch AD wnadler werte kontinuierlich lesen bzw in den ram vom AVR zu schreiben.
|
woher hast du denn gewusst, das gerade in dem augenblick , wo du ein neues byte einlesen möchtest dieses byte bei freebasic-com anliegt?
so einfach geht es nicht. du müsste dann erst wieder ein abfrage der com machen ob ein neues byte anliegt, das kostet zeit.
dann lasse ich lieber einen buffer vollschreiben in eine bestimmte zeit, weil ich weiss, das 16384byte mit 19200baud 6,7sec brauchen und warte diese zeit ohne eine if/then-schleife.
Zitat: |
Also ich weis ja nicht wo deine Probleme
|
...dann arbeite mal mit einer gameboycam und einem avr mit adc und stelle mir das bild im screen dar, wie du es dir denken tust.
wenn du fertig bist, kannst du es ja mal hier reinstellen.
Zitat: |
den ram vom AVR zu schreiben.
|
du kannst nur werte in das eeprom vom avr schreiben während eines programablaufes und nicht in das ram. |
|
Nach oben |
|
 |
Jojo alter Rang

Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 12.10.2006, 00:21 Titel: |
|
|
also wenn noch nicht mal mehr zeit is, um zu prüfen ob ein byte da ist, ist dein pc WIRKLICH langsam! ich kanns ja nicht glauben, dass da 16kilobyte schon in so einer rasend schnellen geschwindigkeit verarbeitet werden müssen. deine kamera schjafft doch sicher keine 500fps, die bei dieser geschwindigkeit angebracht wären, oder?! _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
Nach oben |
|
 |
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|